Retención de datos
A un proveedor de KYC lo tiran de dos lados al mismo tiempo. Las reglas AML exigen conservar la evidencia de una verificación de identidad durante años. Los principios de protección de datos exigen no conservar datos biométricos ni un día más de lo que haya base para hacerlo.
La única forma de satisfacer ambas cosas es borrar de forma programada. Esta página describe esa programación, qué elimina y — igual de importante — qué deja deliberadamente intacto.
Los plazos de abajo los definió el negocio y están implementados en código. No establecen tu obligación. El requisito exacto varía según la actividad regulada de tu organización, no solo según el país. Confirmalo con asesoría legal antes de apoyarte en ellos.
Los plazos
| Jurisdicción | Imágenes conservadas por |
|---|---|
| Paraguay | 5 años |
| Resto de LatAm | 8 años |
| Desconocida | 8 años |
Se miden desde submitted_at — el momento en que se envió la verificación, no el momento en que se completó.
Por qué "desconocida" recibe el plazo más largo, no el más corto
Esta es la parte que la mayoría espera al revés, así que vale explicarla en lugar de solo enunciarla.
Los dos errores no son simétricos:
- Borrar demasiado pronto destruye evidencia que estás legalmente obligado a conservar. Es irrecuperable. En el momento no falla nada visible; te enterás durante una auditoría, cuando piden el registro y no está.
- Conservar demasiado tiempo es un costo y una cuestión de protección de datos. Se corrige mañana.
Por eso, todo caso donde la jurisdicción no es certera recibe el plazo más largo.
No es cautela teórica. La nacionalidad sale del OCR del documento, y sobre tráfico real 9 de 21 verificaciones no traían ninguna nacionalidad, mientras que una leyó PYG — el código de la moneda paraguaya, que el modelo confundió con una nacionalidad. Una política apoyada en ese campo sin un default seguro habría borrado silenciosamente registros reales tres años antes de tiempo.
Por la misma razón, varias grafías mapean al plazo paraguayo y no solo el código ISO alpha-2: PY, PRY, PYG, PARAGUAY, PARAGUAYA, PARAGUAYO. Cualquier otra cosa — incluido un campo vacío — toma el default de 8 años.
El piso
Los dos plazos se leen del entorno (VERIDIA_RETENTION_DAYS_PY, VERIDIA_RETENTION_DAYS_DEFAULT), pero después de leer el entorno se aplica un piso duro de 5 años. Ningún valor de configuración, por más equivocado que esté, puede hacer que se borre algo más joven que eso. Un error de tipeo en una variable de despliegue no puede borrar evidencia viva.
El piso solo sube; nunca baja. Configurar un plazo mayor a 8 años funciona. Configurar uno menor a 5 años no tiene efecto.
Qué se borra y qué no
El barrido borra solo los objetos de imagen: el frente del documento, el dorso del documento y la selfie.
La fila de la base de datos sobrevive. Eso es deliberado — la fila es el registro de la verificación de identidad, y destruirla anularía el sentido de retener cualquier cosa. Lo que sobrevive, indefinidamente, es:
| Categoría | Campos |
|---|---|
| Identidad | extracted_name, extracted_document_number, extracted_date_of_birth, extracted_nationality, extracted_document_type |
| Resultado | status, verdict, confidence, scores, flags, breakdown, errors |
| Vinculación | id, tenant_id, user_ref |
| Traza de auditoría | submitted_at, completed_at, images_deleted_at, reviewed_by, reviewed_at, review_note |
| Contexto del request | client_ip, user_agent, latency_ms |
client_ip y user_agent son datos personales y no forman parte del registro de verificación de identidad que la retención busca preservar. Hoy se conservan indefinidamente porque no hay nada que los purgue ni los anonimice. No existe ningún mecanismo para eliminarlos.
El outbox de entrega de webhooks guarda el payload completo de cada evento, incluido fieldsExtracted (nombre, número de documento, fecha de nacimiento). Esas filas tampoco las toca el barrido de retención. Si estás armando un inventario de dónde viven los datos de identidad, incluí las dos cosas.
Cómo corre el barrido
Un timer de systemd en el host del backend ejecuta el barrido una vez por día.
| Horario | 04:30 hora local del servidor (actualmente America/Argentina/Buenos_Aires, UTC−3) |
| Desfase aleatorio (jitter) | Hasta 10 minutos después del horario programado |
| Ejecuciones perdidas | Se recuperan en el siguiente arranque (Persistent=true) — un reinicio no saltea un día |
| Tope por lote | 200 verificaciones por corrida |
El barrido trabaja en dos etapas, a propósito. Un filtro SQL selecciona candidatas usando el plazo configurado más corto, de modo que nunca se pierda nada elegible; la decisión por jurisdicción se toma después en el código de aplicación, donde la política se escribe una sola vez y se puede testear.
Por cada verificación vencida borra los objetos de imagen y luego:
La fila se marca como borrada solo si todos los objetos fueron efectivamente eliminados. Si falla un solo borrado, la marca queda sin poner y el barrido del día siguiente reintenta.
Esto importa más de lo que parece. La alternativa — marcar la fila igual — produce una base de datos que certifica una destrucción que no ocurrió, mientras el archivo sigue en el almacenamiento. Un registro falso de borrado es peor que no borrar, porque no se puede detectar mirando la base de datos.
Estado actual
Ninguna verificación en el sistema tiene todavía la antigüedad suficiente para vencer, así que el barrido no borró nada hasta la fecha. Corre a diario, en modo de borrado, reportando cero filas elegibles. Se habilitó ahora y no dentro de unos años partiendo de que un control que alguien tiene que acordarse de encender más adelante no es un plan.
Borrado a pedido
No hay ningún mecanismo implementado para borrar los datos de una persona específica a pedido. No hay endpoint de API, no hay control en el panel, no hay camino self-service.
Un pedido de ese tipo hoy implica una operación manual sobre la base de datos y el almacenamiento, hecha por un operador. Si tus obligaciones incluyen atender pedidos de supresión dentro de un plazo fijo, tenelo en cuenta: mirá GDPR para ver qué existe y qué no.
Notá además que la supresión y la retención AML tiran en sentidos opuestos. Borrar un registro que estás legalmente obligado a conservar crea un problema distinto al de conservarlo. Cuál de los dos te obliga es una pregunta legal, no técnica.
Tu propia retención
La retención del lado de Veridia no dice nada sobre las copias que vos tengas.
Cada webhook que recibís contiene PII de identidad. Si guardás el payload, logueás el cuerpo del request, o lo reenviás a un servicio de analytics o de tracking de errores, esas copias son tuyas para inventariar y expirar. Lo mismo aplica a cualquier veredicto que cachees desde GET /v1/verify/{id}.