Consentimiento biométrico para BIPA, CUBI y Colorado

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.

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:

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.
El modo de consentimiento de la aplicación lo pide. En el modo Automático, se aplica uno de los desencadenantes 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.

Modo	Qué ocurre
Automático (por defecto, recomendado)	Muestra el paso solo donde se aplica un desencadenante. 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 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": "<ISO 8601>", "text_version": "<your version id>" }`. 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.

{
  "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 o un WebView	Sí
SDK nativo 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:

"biometric_consent": {
  "required": true,
  "trigger": "ip_state",
  "status": "pending",
  "given_at": null,
  "reason": "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"
}

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. 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). 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 y en el decision de los webhooks de sesión. 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).

`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:

"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.

Relacionado

Crear sesión: user_state y biometric_consent.
Recuperar sesión: la decisión que incluye biometric_consent.
SDK nativos: versiones y pasos de actualización.
Seguridad y cumplimiento: tus responsabilidades en los flujos de verificación.

Visión general

Flujos y verificación

Entidades (usuarios y empresas)

Ajustes y personalización

Seguridad y cumplimiento

Recursos

Consentimiento biométrico para BIPA, CUBI y Colorado

Cuándo aparece el paso

Modos de consentimiento

Qué activa el paso en el modo Automático

Dile a Didit lo que ya sabes

Qué aplicaciones muestran el paso

SDK nativos anteriores a la 4.10.0

Lo que ve la persona

Cuando la persona no acepta

Consentimiento rechazado en la API

En la decisión y en los webhooks

Relacionado

​Cuándo aparece el paso

​Modos de consentimiento

​Qué activa el paso en el modo Automático

​Dile a Didit lo que ya sabes

​Qué aplicaciones muestran el paso

​SDK nativos anteriores a la 4.10.0

​Lo que ve la persona

​Cuando la persona no acepta

​Consentimiento rechazado en la API

​En la decisión y en los webhooks

​Relacionado

Cuándo aparece el paso

Modos de consentimiento

Qué activa el paso en el modo Automático

Dile a Didit lo que ya sabes

Qué aplicaciones muestran el paso

SDK nativos anteriores a la 4.10.0

Lo que ve la persona

Cuando la persona no acepta

Consentimiento rechazado en la API

En la decisión y en los webhooks

Relacionado