> ## 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. # Consentimiento biométrico para BIPA, CUBI y Colorado > Consentimiento biométrico explícito antes del selfie en Illinois, Texas y Colorado: cuándo aparece, SDK nativo 4.10.0 y campos de la decisión. Illinois (BIPA), Texas (CUBI) y Colorado exigen un aviso y una autorización explícita antes de que una empresa recoja la geometría facial, ya sea de un selfie o de la foto de un documento de identidad. Didit puede mostrar un paso de consentimiento antes de la primera captura facial a las personas que cubren esas leyes, y guarda la respuesta en la sesión como prueba. Esta página explica cuándo aparece el paso, qué aplicaciones pueden mostrarlo y cómo llega la respuesta a tu decisión y a tus webhooks. > [!WARNING] > > Didit muestra el paso y registra la respuesta. Tú decides si el recorrido de tus usuarios cumple las leyes biométricas que se aplican a tu empresa. Esta página no es asesoramiento jurídico: revisa tu implementación con tu asesor legal. ## Cuándo aparece el paso Una sesión muestra el paso de consentimiento cuando se cumplen las dos condiciones siguientes: 1. **El flujo captura un rostro.** Un paso de prueba de vida, de coincidencia facial o de estimación de edad, el selfie de la cámara frontal que toma el paso de verificación de identidad (salvo que lo hayas desactivado) o la grabación de vídeo de la sesión completa. 2. **El modo de consentimiento de la aplicación lo pide.** En el modo **Automático**, se aplica uno de los [desencadenantes](#qué-activa-el-paso-en-el-modo-automático) de abajo. En el modo **Siempre**, lo pide toda sesión que captura un rostro. El paso aparece antes de la primera captura facial. Cuando solo el documento de identidad muestra un estado cubierto, aparece justo después de la captura del documento y antes del selfie, y no se calcula ninguna geometría facial a partir de las imágenes de la captura del documento hasta que la persona acepta. Didit comprueba el requisito cuando la persona abre el flujo y de nuevo en cada paso hasta que se aplica. Una vez que una sesión exige consentimiento, lo sigue exigiendo. ### Modos de consentimiento Elige el modo en la consola, en **Configuración > Datos y privacidad > Consentimiento biométrico** de la aplicación. Cada cambio queda registrado en el [registro de auditoría](https://docs.didit.me/console/audit-logs.md). | Modo | Qué ocurre | | - | - | | **Automático** (por defecto, recomendado) | Muestra el paso solo donde se aplica un [desencadenante](#qué-activa-el-paso-en-el-modo-automático). Todos los demás ven el aviso estándar de una línea. | | **Siempre** | Toda persona cuyo rostro se captura ve el paso, esté donde esté. La decisión registra `trigger: "forced"`. | | **Nunca** | Didit nunca muestra el paso. Donde la ley estatal exige consentimiento, lo recoges tú antes del selfie y conservas el registro. | ### Qué activa el paso en el modo Automático Didit comprueba estas reglas por orden y registra la primera que se aplica en `biometric_consent.trigger`: | Desencadenante | Cuándo se aplica | | - | - | | `declared_state` | Declaraste un estado cubierto al crear la sesión: `user_state`, o una dirección de EE. UU. en `expected_details`. | | `ip_state` | La IP de la persona está localizada en Illinois, Texas o Colorado. | | `ip_unknown` | La persona parece estar en EE. UU. (una IP de EE. UU., un documento de EE. UU. o datos de EE. UU. que enviaste) pero no se puede saber su estado: la IP está en EE. UU. sin estado, o no se puede localizar mientras tus datos o el documento sitúan a la persona en EE. UU. | | `document_issuer` | El documento de identidad leído en la captura lo emitió un estado cubierto. | **Las VPN, los proxies y las redes de alojamiento no activan el paso por sí solos.** Didit localiza la IP de la persona como cualquier otra: una en Illinois, Texas o Colorado muestra el paso, y una en cualquier otro lugar no. El paso solo se pide con pruebas claras de un estado cubierto (la IP, el estado que emitió el documento o un estado que declaraste), o cuando la persona se sitúa en EE. UU. sin un estado (`ip_unknown`). A una persona de un estado cubierto detrás de una VPN que sale en otro lugar, con un documento que no emitió ningún estado cubierto, no se le pide; usa el modo **Siempre**, o envía `user_state`, si necesitas cubrir ese caso. Otros dos valores describen cómo se resolvió el consentimiento de una sesión, no por qué se pidió: | Desencadenante | Significado | | - | - | | `forced` | El modo de la aplicación es **Siempre**. | | `customer_collected` | Enviaste, al crear la sesión, un consentimiento que ya habías recogido (ver abajo). | ## Dile a Didit lo que ya sabes [Crear sesión](https://docs.didit.me/sessions-api/create-session.md) admite dos campos opcionales para esto: | Campo | Qué hace | | - | - | | `user_state` | Dónde vive la persona, cuando lo sabes: un código de subdivisión ISO 3166-2 (`US-IL`, `ES-M`) o un código o nombre de estado de EE. UU. (`IL`, `Illinois`). Un estado cubierto muestra el paso con `trigger: "declared_state"`. Un valor desconocido devuelve `400`. | | `biometric_consent` | Consentimiento que ya recogiste: `{ "given_at": "", "text_version": "" }`. El flujo no vuelve a preguntar y la decisión registra `status: "given"` con `trigger: "customer_collected"`. `given_at` no puede estar en el 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" } } ``` ## Qué aplicaciones muestran el paso El paso necesita una aplicación capaz de mostrarlo. Didit lo decide en cada solicitud que hace la aplicación: | Dónde se verifica la persona | Muestra el paso | | - | - | | El flujo de verificación alojado: un navegador, el [SDK web](https://docs.didit.me/es/integration/web-sdks/overview.md) o un WebView | Sí | | [SDK nativo](https://docs.didit.me/es/integration/native-sdks/overview.md) 4.10.0 o posterior (iOS, Android y las versiones de React Native o Flutter que incluyen el nativo 4.10.0 o posterior) | Sí | | Un SDK nativo anterior a la 4.10.0, o uno que no informa de su versión | No | ### SDK nativos anteriores a la 4.10.0 Los SDK nativos publicados antes de la 4.10.0 no conocen el paso de consentimiento, así que Didit nunca se lo pide. La verificación se ejecuta exactamente como antes: el selfie y las demás capturas faciales se aceptan y se procesan, y la sesión llega a su decisión como de costumbre. Didit nunca registra un consentimiento que no se dio. Cuando la sesión exigía consentimiento y un SDK antiguo capturó un rostro, la decisión muestra: ```json theme={null} "biometric_consent": { "required": true, "trigger": "ip_state", "status": "pending", "given_at": null, "reason": "BIOMETRIC_CONSENT_UNSUPPORTED_SDK" } ``` > [!WARNING] > > **Actualiza al SDK nativo 4.10.0 o posterior si verificas a personas de Illinois, Texas o Colorado en una aplicación nativa.** Hasta que lo hagas, esas sesiones terminan sin consentimiento explícito, y recogerlo antes del selfie es tu responsabilidad. Si la persona continúa la misma sesión en el flujo alojado (en otro dispositivo o en un WebView que la aplicación abre para algunos tipos de prueba de vida), el flujo alojado muestra el paso y no captura ningún rostro allí hasta que la persona responda. El consentimiento dado ahí conserva `reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"`, porque ya se habían capturado rostros sin él. ## Lo que ve la persona El paso le dice a la persona qué se recoge, por qué, quién lo tiene y durante cuánto tiempo se conserva, y enlaza a la [política de datos biométricos](https://didit.me/legal/biometric-data-policy). Tiene un solo botón: **Acepto y continúo**, que permanece deshabilitado hasta que la persona marca la casilla de aceptación. Didit guarda la respuesta como prueba: cuándo se dio, la versión y el hash del texto mostrado, el idioma, el paso del flujo y la IP, la ubicación y el agente de usuario de la solicitud. Cuando la persona acepta, la respuesta es definitiva. ## Cuando la persona no acepta El paso no tiene botón de rechazo. Una persona que no quiere aceptar abandona el flujo: no se captura ningún rostro y la sesión termina como `Abandoned`, igual que cualquier otra sesión que la persona no termina (consulta [Estados de verificación](https://docs.didit.me/integration/verification-statuses.md)). Ofrécele otra forma de verificarse. ### Consentimiento rechazado en la API La decisión conserva un estado `declined` y el motivo `BIOMETRIC_CONSENT_DECLINED` como valores de la API. Hoy ninguna pantalla de Didit ofrece rechazar, así que el flujo alojado y los SDK nativos no registran ninguno. Una sesión que registra un rechazo: * Termina como `Declined`, y el webhook `status.updated` se dispara como en cualquier otro rechazo. * Muestra `biometric_consent.status` como `declined`, `reason` y `decline_reason` como `BIOMETRIC_CONSENT_DECLINED`, y `declined_at` con la hora. * No captura ningún rostro tras el rechazo. Se eliminan todas las imágenes faciales y plantillas faciales que la sesión ya conserva: selfies, el selfie de la cámara frontal de la captura del documento, el recorte facial del retrato del documento, y los vídeos de prueba de vida y de sesión completa. `face_data_deleted_at` registra cuándo. La decisión ya no los devuelve, y la eliminación es irreversible. * Conserva las imágenes del documento y los datos leídos de ellas: el rechazo no las afecta. ## En la decisión y en los webhooks Cada decisión de verificación de usuario incluye un objeto `biometric_consent`, en [Recuperar sesión](https://docs.didit.me/sessions-api/retrieve-session.md) y en el `decision` de los [webhooks de sesión](https://docs.didit.me/integration/webhooks.md). Es `null` cuando la sesión nunca se evaluó, por ejemplo en un flujo sin captura facial. | `status` | Significado | | - | - | | `not_required` | La sesión no exigía consentimiento. | | `pending` | Se exige consentimiento y no se dio. Lee `reason` para distinguir un SDK antiguo de una persona que aún no ha respondido. | | `given` | La persona aceptó en el flujo, o enviaste `biometric_consent` al crear la sesión. | | `declined` | Se registró un rechazo y la sesión terminó como `Declined`. Hoy ninguna pantalla de Didit ofrece rechazar (consulta [arriba](#consentimiento-rechazado-en-la-api)). | | `reason` | Significado | | - | - | | `BIOMETRIC_CONSENT_UNSUPPORTED_SDK` | Un SDK nativo anterior a la 4.10.0, o uno que no informó de su versión, capturó un rostro sin el paso. | | `BIOMETRIC_CONSENT_DECLINED` | Se registró un rechazo. Hoy ninguna pantalla de Didit ofrece rechazar. | | `null` | No hay nada que explicar. Siempre es `null` cuando la sesión no exigía consentimiento. | Una sesión en la que la persona aceptó en el flujo 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 } ``` El ejemplo está abreviado. Todos los campos, con su tipo, están en [Modelos de datos](https://docs.didit.me/reference/data-models.md#biometric-consent). ## Relacionado * [Crear sesión](https://docs.didit.me/sessions-api/create-session.md): `user_state` y `biometric_consent`. * [Recuperar sesión](https://docs.didit.me/sessions-api/retrieve-session.md): la decisión que incluye `biometric_consent`. * [SDK nativos](https://docs.didit.me/es/integration/native-sdks/overview.md): versiones y pasos de actualización. * [Seguridad y cumplimiento](https://docs.didit.me/es/getting-started/security-compliance.md): tus responsabilidades en los flujos de verificación. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.