GDPR y protección de datos
Veridia no afirma cumplir con el GDPR, y esta página no es una evaluación legal. Describe qué hace el sistema con los datos personales para que vos y tu asesoría legal puedan hacer la propia.
Varias cosas de las que un programa de GDPR normalmente depende todavía no existen acá. Están listadas en vez de dejadas para que las descubras más adelante.
Tené en cuenta que el GDPR no suele ser el régimen operativo para el mercado LatAm al que Veridia sirve principalmente — la LGPD de Brasil, la Ley 25.326 de Argentina y la ley paraguaya tienen cada una sus propios requisitos. La mecánica de abajo es la misma sin importar qué régimen te aplique; las obligaciones no. Cuál te obliga es una pregunta para tu asesoría legal.
Qué datos personales se tratan
| Categoría | Campos | Fuente |
|---|---|---|
| Imágenes faciales | Selfie; cuadros del reto de prueba de vida (liveness) | Captura de cámara |
| Imágenes del documento | Frente, y dorso donde se requiera | Cámara o galería |
| Campos de identidad | Nombre completo, número de documento, fecha de nacimiento, nacionalidad, tipo de documento | OCR del documento |
| Evaluación | Veredicto, confianza, scores por control, flags | El pipeline de verificación |
| Vinculación | Tu userRef, si mandás uno | Vos |
| Contexto del request | Dirección IP, user agent, tiempos | El request |
Las imágenes faciales tratadas para contrastar a una persona contra un documento generalmente se consideran datos biométricos, con requisitos reforzados asociados. Confirmá esa caracterización y sus consecuencias con tu asesoría legal — no es una determinación que esta página pueda hacer por vos.
A dónde van los datos
- El navegador o la app móvil captura las imágenes y las sube a la API de Veridia — no directamente al almacenamiento de objetos. Ver Seguridad.
- La API escribe las imágenes en el almacenamiento de objetos y encola la verificación.
- Un pipeline de backend realiza OCR, comparación facial, evaluación de prueba de vida (liveness) y screening de sanciones, escribiendo los resultados en una base de datos MySQL.
- Si configuraste un webhook, el resultado — incluidos los campos de identidad — se entrega a tu endpoint.
- Las imágenes se borran según el calendario de retención. La fila de la base de datos se conserva. Ver Retención de datos.
Tu endpoint se convierte en un almacén de datos personales
El payload del webhook incluye fieldsExtracted: nombre completo, número de documento, fecha de nacimiento, nacionalidad, tipo de documento.
Eso tiene consecuencias que la mayoría de los integradores nota recién después. Si tu handler loguea los cuerpos crudos de los requests, o reenvía errores a un servicio externo de tracking de errores, o escribe los payloads a una cola con su propia retención, entonces se copió PII de identidad a cada uno de esos sistemas. Incluilos en tu propio inventario de tratamiento y en tu plan de retención.
Residencia de datos
No hay ninguna garantía documentada de residencia de datos, ni una lista formal de subencargados publicada hoy. El tratamiento abarca la infraestructura edge de Cloudflare y un host de backend que corre el pipeline de ML y la base de datos. Si tu evaluación depende de conocer las ubicaciones de tratamiento y los subencargados involucrados, preguntá antes de integrar en lugar de inferirlo de esta página.
Derechos del titular: qué existe
Esta es la sección para leer con atención, porque la respuesta honesta para la mayoría de los derechos es "no hay mecanismo".
| Derecho | Estado |
|---|---|
| Acceso | Parcial. GET /v1/verify/{id} con una clave secreta devuelve el status, el veredicto, los scores y los flags de la verificación. No es una exportación completa de todo lo que se guarda sobre una persona, y está indexado por verificación, no por persona. |
| Supresión | Sin mecanismo. No hay endpoint, no hay control en el panel. Un pedido implica una operación manual sobre base de datos y almacenamiento hecha por un operador. |
| Portabilidad | Sin mecanismo. No se produce ningún formato de exportación estructurado. |
| Rectificación | Sin mecanismo. Los campos extraídos no se pueden corregir por la API. |
| Limitación / oposición | Sin mecanismo. |
| Decisiones automatizadas | Ver más abajo. |
No hay camino self-service para ninguno de estos, ni un tiempo de respuesta comprometido para hacerlo manualmente. Si tus obligaciones incluyen responder pedidos dentro de un plazo fijo, esa restricción la tenés que gestionar vos, y deberías plantearla antes de depender de ella.
La supresión choca con la retención
Vale señalarlo porque sorprende: un pedido de supresión y una obligación de retención AML pueden apuntar en sentidos opuestos. Borrar un registro que estás legalmente obligado a conservar crea un problema distinto al de conservarlo. Cuál obligación prevalece es una pregunta legal — el sistema no la va a resolver por vos, y deliberadamente no borra filas de la base de datos en el calendario de retención por esta razón.
Decisiones automatizadas
Una verificación produce uno de tres veredictos: approved, review o rejected. Dos de ellos se pueden alcanzar sin un humano.
Dos cosas lo acotan:
- Una falla dura nunca aprueba automáticamente, sin importar qué tan alto sea el score de confianza.
- Una coincidencia fuerte de sanciones nunca rechaza automáticamente. Fuerza la verificación a
reviewpara que decida una persona. Ver SEPRELAD.
El veredicto review se deriva a una cola humana en el panel, y la decisión se registra con la identidad del revisor, el timestamp y la nota.
Si tu uso de estos veredictos constituye una decisión automatizada con efecto jurídico o similarmente significativo — y qué le debés en consecuencia al titular en materia de información, intervención humana o impugnación — depende de qué hacés vos con el veredicto, no de qué hace Veridia. Si condicionás el acceso a la cuenta en función de él, asumí que la pregunta te aplica y buscá asesoramiento.
Consentimiento
No hay pantalla de consentimiento, no hay checkbox, no hay aceptación registrada, y no hay timestamp de ningún acuerdo en ninguna parte del widget ni de la API. El flujo de captura empieza cuando el usuario lo inicia.
Si tu base legal requiere consentimiento — y para el tratamiento biométrico habitualmente lo requiere — tenés que obtenerlo y registrarlo vos, antes de montar el widget. Veridia no guarda ninguna evidencia de que se haya dado consentimiento, y no puede producir ninguna si te la piden.
Del mismo modo, el widget no le presenta ningún aviso de privacidad al usuario final. Todo lo que haya que decirle a la persona sobre quién trata su cara y su documento, y para qué, se lo tiene que decir tu interfaz.
Acuerdo de tratamiento
Hoy no se ofrece ningún acuerdo de tratamiento de datos. No hay plantilla de DPA, no hay paquete de cláusulas contractuales tipo, y no hay términos de encargado firmados.
Si tu programa requiere un acuerdo escrito con un encargado antes de poder compartir datos personales — que es la posición normal — ese hueco está entre vos y producción. Plantealo comercialmente en lugar de asumir que el documento existe.
Notificación de brechas
No hay procedimiento documentado de respuesta a incidentes ni de notificación de brechas, y no hay ventana contractual de notificación. Si necesitás una, hay que acordarla en lugar de darla por sentada.
Resumen de huecos
Para checklists de evaluación:
- Sin DPA ni términos de encargado
- Sin captura de consentimiento ni aviso de privacidad en el widget
- Sin mecanismo de supresión, portabilidad ni rectificación
- Sin residencia de datos documentada ni lista de subencargados publicada
- Sin procedimiento ni plazo de notificación de brechas documentado
- Sin cifrado a nivel de aplicación de las columnas de identidad (Seguridad)
- Dirección IP y user agent conservados indefinidamente sin mecanismo de purga (Retención de datos)
- Sin auditoría ni certificación externa de ningún tipo