Cumplimiento
Esta sección describe mecanismos: qué hace el sistema con los datos de identidad, con qué frecuencia y con qué resguardos. Cada afirmación acá está pensada para que puedas contrastarla contra el código corriendo o contra la configuración.
Qué NO es esta sección
Veridia no está certificada, auditada ni aprobada contra ningún estándar. No hay reporte SOC 2, no hay certificación ISO, no hay auditoría de seguridad externa, y ningún regulador revisó ni aprobó este sistema.
Estas páginas no dicen que Veridia "cumple con" GDPR, SEPRELAD, LGPD ni nada por el estilo. El cumplimiento es una propiedad de tu actividad regulada, no de la página de producto de un proveedor. Lo que sí podemos decirte es exactamente qué hace el software, para que vos y tu asesoría legal decidan si encaja con tus obligaciones.
Si buscás un documento para entregarle a un auditor como evidencia de certificación, no existe. Si buscás una descripción precisa de cómo se manejan los datos de identidad para poder completar tu propia evaluación, para eso es esta sección.
Las páginas
| Página | Qué cubre |
|---|---|
| Retención de datos | Cuánto tiempo se guardan las imágenes, por jurisdicción; qué se borra y qué sobrevive para siempre; el barrido diario que lo hace |
| SEPRELAD y AML | Qué hace realmente el screening de sanciones, y por qué Veridia no produce ningún reporte regulatorio |
| GDPR | Qué datos personales fluyen a dónde, y qué derechos del titular no tienen hoy ningún mecanismo implementado |
| Seguridad | Firma de webhooks, la protección contra SSRF, tipos de clave y almacenamiento, aislamiento entre tenants, rate limits, y los controles que no existen |
La versión corta
Hay cuatro cosas que conviene saber antes de seguir leyendo.
Solo se borran las imágenes. El barrido de retención elimina del almacenamiento los archivos del documento y de la selfie. La fila de la base de datos — veredicto, campos de identidad extraídos, traza de auditoría — sobrevive indefinidamente, por diseño, porque esa fila es el registro de la verificación de identidad. Ver Retención de datos.
Tu endpoint de webhook recibe PII de identidad. El payload incluye fieldsExtracted con nombre completo, número de documento y fecha de nacimiento. Eso convierte a tu endpoint, y a cualquier cosa que loguee los cuerpos de sus requests, en un almacén de datos personales. Planificalo.
Un hit de sanciones nunca rechaza automáticamente. Una coincidencia fuerte contra las listas de screening fuerza la verificación a review para que decida una persona. El sistema no va a rechazar a alguien solo por una coincidencia de nombre.
Varias cosas que quizás asumas que existen, no existen. No hay acuerdo de tratamiento de datos ofrecido, no hay captura de consentimiento en el widget, no hay borrado ni exportación self-service, no hay cifrado a nivel de aplicación de las columnas de identidad, y no hay generación de reportes SEPRELAD. Cada una está dicha en claro en la página correspondiente, en vez de dejarte que la descubras.
Dónde hace falta criterio legal
Lo siguiente requiere asesoría de un profesional que conozca tu actividad regulada — esta documentación no puede reemplazarla:
- Qué plazo de retención te obliga realmente. Los plazos implementados acá los definió el negocio; tu obligación puede diferir según la actividad, no solo según el país.
- Si sos responsable del tratamiento y Veridia encargado, y qué acuerdo exige eso.
- En qué base legal te apoyás para tratar datos biométricos, y cómo la obtenés. El widget no captura consentimiento.
- Si las listas de screening cubiertas acá alcanzan para tus obligaciones. Son solo listas de sanciones — sin lista PEP, sin adverse media.
Reportar un problema de seguridad
Si encontrás una vulnerabilidad, por favor reportala en privado en lugar de abrir un issue público. Ver Soporte para los datos de contacto.