> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Consentimento biométrico para BIPA, CUBI e Colorado > O Didit recolhe consentimento biométrico explícito antes da selfie para o Illinois, Texas e Colorado: acionadores, SDK 4.10.0 e campos de decisão. O Illinois (BIPA), o Texas (CUBI) e o Colorado exigem um aviso e uma autorização explícita antes de uma empresa recolher a geometria facial, a partir de uma selfie ou da fotografia de um documento de identificação. A Didit pode apresentar um passo de consentimento antes da primeira captura de rosto às pessoas abrangidas por essas leis, e mantém a resposta na sessão como prova. Esta página explica quando o passo é apresentado, quais as aplicações que o podem apresentar e como a resposta chega à sua decisão e aos webhooks. > [!WARNING] > > A Didit apresenta o passo e regista a resposta. Você decide se o percurso do utilizador cumpre as leis biométricas aplicáveis à sua empresa. Esta página não constitui aconselhamento jurídico: reveja a sua implementação com o seu consultor jurídico. ## Quando o passo é apresentado Uma sessão apresenta o passo de consentimento quando ambas as seguintes condições se verificam: 1. **O fluxo captura um rosto.** Um passo de Prova de vida, Correspondência facial ou Estimativa de idade, a selfie da câmara frontal capturada pelo passo de Verificação de identidade (a menos que a tenha desativado), ou a gravação de vídeo de toda a sessão. 2. **O modo de consentimento da aplicação o solicita.** No modo **Automático**, aplica-se um dos [acionadores](#o-que-aciona-o-passo-no-modo-automático) abaixo. No modo **Sempre**, todas as sessões que capturam um rosto solicitam-no. O passo surge antes da primeira captura facial. Quando apenas o documento de identificação indica um estado abrangido, o passo surge logo após a captura do documento e antes da selfie, e nenhuma geometria facial é calculada a partir das imagens capturadas do documento até que a pessoa concorde. A Didit verifica o requisito quando a pessoa abre o fluxo e novamente em cada passo até que este se aplique. Assim que uma sessão exige consentimento, continua a exigi-lo. ### Modos de consentimento Escolha o modo na consola, nas **Settings > Data and privacy > Biometric consent** da aplicação. Cada alteração é registada no [registo de auditoria](https://docs.didit.me/pt/console/audit-logs.md). | Modo | O que acontece | | - | - | | **Automático** (predefinição, recomendado) | Apresenta o passo apenas quando um [acionador](#o-que-aciona-o-passo-no-modo-automático) se aplica. Todos os restantes veem o aviso padrão de uma linha. | | **Sempre** | Todas as pessoas cujo rosto seja capturado veem o passo, onde quer que estejam. A decisão regista `trigger: "forced"`. | | **Nunca** | A Didit nunca apresenta o passo. Onde a legislação estadual exigir consentimento, recolhe-o por sua conta antes da selfie e mantém o registo. | ### O que aciona o passo no modo Automático A Didit verifica estas regras por ordem e regista a primeira aplicável em `biometric_consent.trigger`: | Acionador | Quando se aplica | | - | - | | `declared_state` | Declarou um estado abrangido ao criar a sessão: `user_state`, ou uma morada dos EUA em `expected_details`. | | `ip_state` | O IP da pessoa localiza-se no Illinois, Texas ou Colorado. | | `ip_unknown` | A pessoa aparenta estar nos EUA (um IP dos EUA, um documento dos EUA ou dados dos EUA enviados por si), mas não é possível determinar o respetivo estado: o IP situa-se nos EUA sem indicação do estado, ou não pode ser localizado enquanto os seus dados ou o documento situam a pessoa nos EUA. | | `document_issuer` | O documento de identidade lido na captura do documento foi emitido por um estado abrangido. | **VPNs, proxies e redes de alojamento não acionam o passo por si sós.** A Didit localiza o IP da pessoa como qualquer outro: um localizado no Illinois, Texas ou Colorado apresenta o passo; um localizado em qualquer outro lugar não o apresenta. O passo só é solicitado mediante evidência clara de um estado abrangido (o IP, o estado emissor do documento ou um estado por si declarado), ou quando a pessoa é situada nos EUA sem indicação do estado (`ip_unknown`). Uma pessoa num estado abrangido que utilize uma VPN com saída noutro local, com um documento que não foi emitido por nenhum estado abrangido, não é solicitada; utilize o modo **Sempre**, ou envie `user_state`, se necessitar de cobrir esse caso. Dois valores adicionais descrevem como o consentimento de uma sessão foi resolvido, em vez do motivo pelo qual foi solicitado: | Acionador | Significado | | - | - | | `forced` | O modo da aplicação é **Sempre**. | | `customer_collected` | Enviou o consentimento que já tinha recolhido ao criar a sessão (ver abaixo). | ## Indique à Didit o que já sabe A operação [Create Session](https://docs.didit.me/pt/sessions-api/create-session.md) aceita dois campos opcionais para o efeito: | Campo | O que faz | | - | - | | `user_state` | Onde a pessoa reside, quando o souber: um código de subdivisão ISO 3166-2 (`US-IL`, `ES-M`) ou o código ou nome de um estado dos EUA (`IL`, `Illinois`). Um estado abrangido apresenta o passo com `trigger: "declared_state"`. Um valor desconhecido devolve `400`. | | `biometric_consent` | Consentimento que já recolheu: `{ "given_at": "", "text_version": "" }`. O fluxo não volta a solicitá-lo, e a decisão regista `status: "given"` com `trigger: "customer_collected"`. `given_at` não pode estar no futuro. | ```json theme={null} { "workflow_id": "YOUR_WORKFLOW_ID", "vendor_data": "user-42", "user_state": "US-IL", "biometric_consent": { "given_at": "2026-10-13T09:12:00Z", "text_version": "consent-v3" } } ``` ## Quais são as aplicações que mostram o passo O passo necessita de uma aplicação que o consiga apresentar. A Didit decide isto em cada pedido que a aplicação faz: | Onde a pessoa realiza a verificação | Mostra o passo | | - | - | | O fluxo de verificação alojado: um navegador, o [Web SDK](https://docs.didit.me/pt/integration/web-sdks/overview.md) ou uma WebView | Sim | | [Native SDK](https://docs.didit.me/pt/integration/native-sdks/overview.md) 4.10.0 ou posterior (iOS, Android e versões de React Native ou Flutter que incluam a versão nativa 4.10.0 ou posterior) | Sim | | Um SDK nativo anterior à versão 4.10.0, ou um que não reporte a sua versão | Não | ### SDKs nativos anteriores à versão 4.10.0 Os SDKs nativos lançados antes da versão 4.10.0 não conhecem o passo de consentimento, pelo que a Didit nunca lhes pede isso. A verificação decorre exatamente como antes: a selfie e as outras capturas faciais são aceites e processadas, e a sessão chega à sua decisão como habitualmente. A Didit nunca regista consentimento que não tenha sido dado. Quando a sessão exigia consentimento e um SDK mais antigo capturou um rosto, a decisão apresenta: ```json theme={null} "biometric_consent": { "required": true, "trigger": "ip_state", "status": "pending", "given_at": null, "reason": "BIOMETRIC_CONSENT_UNSUPPORTED_SDK" } ``` > [!WARNING] > > **Atualize para o SDK nativo 4.10.0 ou posterior se verificar pessoas em Illinois, Texas ou Colorado numa aplicação nativa.** Até que o faça, essas sessões terminam sem consentimento explícito, e recolhê-lo antes da selfie é da sua responsabilidade. Se a pessoa continuar a mesma sessão no fluxo alojado (noutro dispositivo ou numa WebView que a aplicação abre para alguns tipos de prova de vida), o fluxo alojado mostra o passo e não captura nenhum rosto aí até que ela responda. O consentimento dado aí mantém `reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"`, porque já tinham sido capturados rostos sem consentimento. ## O que a pessoa vê O passo informa a pessoa sobre o que é recolhido, porquê, quem o tem e durante quanto tempo é conservado, e inclui uma ligação para a [Política de dados biométricos](https://didit.me/legal/biometric-data-policy). Tem um botão: **Aceito e continuo**, que permanece desativado até que a pessoa assinale a caixa de concordância. A Didit guarda a resposta como prova: quando foi dada, a versão e o hash do texto apresentado, o idioma, o passo do fluxo e o IP, a localização e o agente do utilizador do pedido. Uma vez dado o consentimento pela pessoa, a resposta é final. ## Quando a pessoa não aceita O passo não tem um botão de recusa. Uma pessoa que não pretenda aceitar sai do fluxo: nenhum rosto é capturado e a sessão termina como `Abandoned`, como qualquer outra sessão que a pessoa não conclua (consulte [Estados da verificação](https://docs.didit.me/pt/integration/verification-statuses.md)). Disponibilize-lhe outra forma de verificação. ### Consentimento recusado na API A decisão mantém um estado `declined` e o motivo `BIOMETRIC_CONSENT_DECLINED` como valores da API. Nenhum ecrã da Didit oferece uma opção de recusa atualmente, pelo que o fluxo alojado e os SDKs nativos não a registam. Uma sessão que registe uma recusa: * Termina como `Declined`, e o webhook `status.updated` é disparado como para qualquer outra recusa. * Apresenta `biometric_consent.status` como `declined`, `reason` e `decline_reason` como `BIOMETRIC_CONSENT_DECLINED`, e `declined_at` com a hora. * Não captura nenhum rosto após a recusa. Todas as imagens faciais e templates biométricos que a sessão já possui são eliminados: selfies, a selfie da câmara frontal da captura do documento de identificação, o recorte facial do retrato do documento, vídeos de prova de vida e vídeos da sessão completa. O campo `face_data_deleted_at` regista a data e hora. A decisão deixa de os devolver e a eliminação é irreversível. * Mantém as imagens dos documentos e os dados lidos a partir deles: a recusa não os afeta. ## Na decisão e nos webhooks Cada decisão de Verificação de utilizadores contém um objeto `biometric_consent`, em [Retrieve Session](https://docs.didit.me/pt/sessions-api/retrieve-session.md) e no campo `decision` dos [webhooks de sessão](https://docs.didit.me/pt/integration/webhooks.md). Fica a `null` quando a sessão nunca foi avaliada, por exemplo, num fluxo sem captura de rosto. | `status` | Significado | | - | - | | `not_required` | A sessão não exigia consentimento. | | `pending` | O consentimento é obrigatório e não foi dado. Consulte `reason` para distinguir um SDK mais antigo de uma pessoa que ainda não respondeu. | | `given` | A pessoa aceitou no fluxo, ou enviou `biometric_consent` aquando da criação. | | `declined` | Foi registada uma recusa e a sessão terminou como `Declined`. Nenhum ecrã da Didit oferece uma recusa atualmente (consulte [acima](#consentimento-recusado-na-api)). | | `reason` | Significado | | - | - | | `BIOMETRIC_CONSENT_UNSUPPORTED_SDK` | Um SDK nativo anterior à versão 4.10.0, ou um que não reportou a sua versão, capturou um rosto sem o passo. | | `BIOMETRIC_CONSENT_DECLINED` | Foi registada uma recusa. Nenhum ecrã da Didit oferece uma recusa atualmente. | | `null` | Nada a explicar. É sempre `null` quando a sessão não exigia consentimento. | Uma sessão onde a pessoa aceitou no fluxo alojado: ```json theme={null} "biometric_consent": { "required": true, "trigger": "declared_state", "status": "given", "given_at": "2026-10-13T18:31:07.412000Z", "declined_at": null, "text_version": "bio-consent-2026-10-12", "locale": "en", "policy_url": "https://didit.me/legal/biometric-data-policy", "step": "LIVENESS", "ip_address": "198.51.100.23", "ip_country_code": "ES", "detected_ip_address": "198.51.100.23", "detected_country_code": "ES", "jurisdictions": ["IL"], "retention_months": 36, "reason": null, "decline_reason": null, "face_data_deleted_at": null } ``` O exemplo foi abreviado. Todos os campos, com os respetivos tipos, encontram-se em [Modelos de dados](https://docs.didit.me/pt/reference/data-models.md#consentimento-biométrico). ## Conteúdo relacionado * [Create Session](https://docs.didit.me/pt/sessions-api/create-session.md): `user_state` e `biometric_consent`. * [Retrieve Session](https://docs.didit.me/pt/sessions-api/retrieve-session.md): a decisão que inclui `biometric_consent`. * [SDKs nativos](https://docs.didit.me/pt/integration/native-sdks/overview.md): versões e passos de atualização. * [Segurança e conformidade](https://docs.didit.me/pt/getting-started/security-compliance.md): as suas responsabilidades nos fluxos de verificação. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.