Anexo de Protección de Datos (DPA)
Versão 2026-07-11 · Vigente desde 11 de julho de 2026
Rillis — Anexo de Protección de Datos (DPA)
Versión: 2026-07-11 · Vigente desde: 11 de julio de 2026 Este DPA se incorpora a los Términos Maestros y los complementa. En caso de conflicto sobre tratamiento de datos personales, prevalece este DPA.
Marco. Rillis opera como red multi‑jurisdiccional en las Américas (con vocación global). Este DPA está construido sobre el esqueleto del art. 28 del RGPD (portable a la mayoría de regímenes), con un rider por jurisdicción (Apéndice 3) que activa requisitos locales (LGPD Brasil, Ley 21.719 Chile, nueva LFPDPPP México, Ley 1581 Colombia, Ley 25.326 Argentina, CCPA/BIPA y leyes estatales de EE. UU.) y un rider de resiliencia (Apéndice 4) para clientes financieros regulados (p. ej. DORA).
1. Definiciones y roles
1.1 Términos. “Responsable” (controller), “Encargado” (processor), “Sub‑encargado”, “Titular”, “Datos Personales”, “Datos Sensibles/Categoría Especial”, “Tratamiento”, “Brecha de Datos Personales” y “Transferencia Internacional” tienen el significado de la normativa de protección de datos aplicable.
1.2 Roles ordinarios. Respecto de los Servicios de verificación y screening prestados por cuenta del Cliente, el Cliente es el Responsable y Rillis es el Encargado. Rillis trata los Datos Personales únicamente conforme a las instrucciones documentadas del Cliente (estos Términos, el DPA, el Formulario de Pedido y la configuración de la Plataforma).
1.3 Roles en la Red de Verificación Única. Para cada operación de reuso: (a) el Donante y el Receptor actúan como responsables independientes entre sí; (b) Rillis actúa como Encargado de cada uno respecto de los datos que trata por su cuenta, y como responsable independiente únicamente de la infraestructura de Red (matching por identificador verificado, registro de consentimientos, registros de auditoría inmutables y atestación de integridad). El detalle se establece en el Apéndice 2.
1.4 Rillis como Responsable independiente. Rillis actúa como Responsable propio solo respecto de datos que trata para sus fines legítimos de operación, seguridad, facturación, cumplimiento propio y mejora de los Servicios con datos desidentificados/agregados, conforme a su Política de Privacidad.
2. Objeto, duración, naturaleza y finalidad del tratamiento
Los detalles exigidos por el art. 28(3) RGPD y equivalentes constan en el Apéndice 1 (objeto; duración; naturaleza y finalidad; tipos de Datos Personales, incluidos datos biométricos como categoría especial/sensible; y categorías de Titulares).
3. Obligaciones del Encargado (Rillis)
Rillis se obliga a:
3.1 Instrucciones documentadas. Tratar los Datos Personales solo conforme a las instrucciones documentadas del Cliente, incluidas las transferencias internacionales, salvo obligación legal (en cuyo caso informará al Cliente antes de tratar, salvo prohibición legal por interés público).
3.2 Confidencialidad. Asegurar que las personas autorizadas a tratar los Datos Personales se hayan obligado a confidencialidad o estén bajo deber legal equivalente.
3.3 Seguridad (art. 32). Implementar medidas técnicas y organizativas apropiadas (Apéndice 5), incluyendo cifrado en tránsito y en reposo, RBAC, autenticación reforzada, registro de auditoría, minimización, y protección de plantillas biométricas (irreversibilidad, no vinculación y renovabilidad conforme a ISO/IEC 24745; detección de ataques de presentación conforme a ISO/IEC 30107-3; y métricas de exactitud/PAD documentadas de acuerdo con NIST SP 800-63A/B e ISO/IEC 19795-1, incluida prueba de diferencial demográfico).
3.4 Sub‑encargados. Cumplir las condiciones del art. 28(2) y (4): el Cliente otorga autorización general para el uso de Sub‑encargados listados en el Apéndice 6; Rillis informará con antelación razonable la adición o sustitución de Sub‑encargados, dando al Cliente la oportunidad de objetar por motivos razonables de protección de datos; impondrá a cada Sub‑encargado obligaciones equivalentes por contrato; y permanecerá plenamente responsable ante el Cliente por su desempeño.
3.5 Asistencia con derechos de los Titulares. Asistir al Cliente, mediante medidas técnicas y organizativas apropiadas y en la medida de lo posible, para responder a solicitudes de ejercicio de derechos (acceso, rectificación, supresión, oposición, portabilidad, limitación y derechos sobre decisiones automatizadas).
3.6 Asistencia con seguridad, brechas y evaluaciones (arts. 32–36). Asistir al Cliente en el cumplimiento de sus obligaciones de seguridad, notificación de brechas y evaluaciones de impacto (DPIA) y consultas previas, considerando la naturaleza del tratamiento y la información disponible.
3.7 Notificación de brechas. Notificar al Cliente sin dilación indebida y, en todo caso, dentro de 72 horas desde que tenga conocimiento de una Brecha de Datos Personales, con la información razonablemente disponible para que el Cliente cumpla sus propios plazos regulatorios.
3.8 Devolución o supresión. A elección del Cliente, devolver o suprimir los Datos Personales al término de los Servicios y suprimir las copias existentes, salvo obligación legal de conservación (véase Sección 6).
3.9 Demostración y auditoría. Poner a disposición del Cliente la información necesaria para demostrar el cumplimiento y permitir y contribuir a auditorías e inspecciones del Cliente o de un auditor por él designado (y de las autoridades competentes, según el Apéndice 4).
3.10 Deber de advertencia. Informar de inmediato al Cliente si, a su juicio, una instrucción infringe la normativa de protección de datos aplicable.
4. Obligaciones del Responsable (Cliente)
El Cliente: (a) garantiza contar con base jurídica válida y con los consentimientos y avisos necesarios respecto de los Titulares, incluidos los datos biométricos; (b) impartirá instrucciones lícitas; (c) es responsable de la exactitud y licitud de los Datos del Cliente; (d) cumplirá sus propias obligaciones de notificación de brechas, DPIA y atención de derechos como Responsable; y (e) para decisiones que produzcan efectos jurídicos o significativos, mantendrá revisión humana significativa y ofrecerá los mecanismos de intervención humana que exija la normativa (art. 22 RGPD y análogos).
5. Base legal del dato biométrico y decisiones automatizadas
5.1 Base biométrica. El tratamiento de datos biométricos requiere una excepción del régimen de categoría especial/sensible. Según la jurisdicción (Apéndice 3), la base podrá ser el consentimiento explícito del Titular (universal), y/o —donde la ley lo permita y como base alternativa o concurrente— la prevención del fraude y la seguridad en los procesos de identificación y autenticación (p. ej. art. 11 II(g) de la LGPD de Brasil) o el interés público sustancial con base legal (p. ej. art. 9(2)(g) RGPD). El Cliente determina y documenta la base aplicable; Rillis registra y versiona el consentimiento para dar prueba auditable.
5.2 Decisiones automatizadas. Cuando los Resultados alimenten decisiones que produzcan efectos jurídicos o significativos (p. ej. aprobación/rechazo de onboarding, offboarding, o scoring del que el Responsable “se sirva de forma determinante”), el Cliente asegurará la existencia de una base habilitante y de salvaguardas (información significativa sobre la lógica, intervención humana, expresión de punto de vista e impugnación). Rillis proveerá artefactos de transparencia (tarjetas de modelo, factores y lógica a nivel inteligible), registros/logs y herramientas de re‑revisión para que el Cliente cumpla dichas obligaciones.
6. Retención y supresión — conciliación con la conservación regulatoria (GAFI)
6.1 Tensión AML/minimización. Las normas de PLA/FT (estándar GAFI/FATF, Recomendación 11) exigen conservar los registros de identidad/KYC por al menos cinco (5) años desde el fin de la relación o de la operación ocasional, pudiendo el plazo local llegar a diez (10) años (p. ej. Circular BCB 3.978/2020 en Brasil; art. 115 de la Ley de Instituciones de Crédito y disposiciones CNBV en México; extensión de 5 a 10 años bajo el paquete AML de la UE — Reg. (UE) 2024/1624, aplicable desde el 10-jul-2027; 31 CFR 1010.430/1020.220/1020.320 en EE. UU.). La minimización y el derecho de supresión conviven con esa obligación mediante:
(a) Retención por finalidad, por Responsable y anclada en obligación legal. Cada Responsable determina y conserva la evidencia según SU plazo regulatorio (configurable por organización en la Plataforma; por defecto 5 años GAFI, ajustable hasta 10 según jurisdicción/sector), sobre la base jurídica de obligación legal (no consentimiento), de modo que la conservación sobrevive al retiro del consentimiento. La supresión a solicitud del Titular no prevalece sobre esa obligación; en tal caso, los datos se trasladan a un almacén de retención legal (“legal hold”) segregado y de acceso restringido, se bloquean/restringen para todo uso distinto de la conservación legal, y se suprimen o anonimizan de forma irreversible al vencer el plazo. Esta salvedad se refleja en la cláusula de devolución/supresión (art. 28(3)(g) RGPD: el Encargado suprime o devuelve al término del servicio “salvo que la ley exija conservar los datos”).
(b) Minimización biométrica. Rillis deriva y conserva plantillas biométricas irreversibles/renovables y suprime las muestras crudas (imágenes/audio) una vez completada la verificación, salvo instrucción de conservación del Responsable. Auto‑supresión al cumplirse la finalidad y, en todo caso, dentro de los límites externos más estrictos aplicables (p. ej. 1 año Texas / 3 años BIPA para posesión biométrica; y “no más de lo necesario” bajo RGPD/leyes locales).
(c) Política pública de retención/destrucción biométrica. Rillis mantiene y pone a disposición una política de retención y destrucción de identificadores biométricos con calendario, y ofrece al Cliente ventanas configurables y certificados de destrucción/borrado criptográfico.
6.2 Interacción con el sello blockchain. El hash on‑chain no se elimina (imposibilidad técnica). Cada sello incorpora un valor aleatorio (“salt”) conservado fuera de la cadena; eliminados la evidencia y el salt off‑chain, el hash residual deja de ser referible a persona identificable y no constituye dato personal, conforme al criterio de las autoridades de protección de datos sobre blockchain. Los registros de auditoría inmutables se conservan sin datos personales en claro. (Nota: el tratamiento del hash como dato personal cuando carece de salt debe validarse contra la guía vigente de la autoridad aplicable; véase el memo de fundamentos.)
7. Transferencias internacionales
7.1 Principio. Toda Transferencia Internacional se realizará con un mecanismo válido conforme a la ley del país exportador (Apéndice 3), entre ellos: decisiones de adecuación; cláusulas contractuales tipo (SCC de la UE — Decisión (UE) 2021/914; SCC brasileñas — Resolución CD/ANPD 19/2024, obligatorias tras el fin del período de gracia; IDTA/Adenda del Reino Unido); reglas corporativas vinculantes; o, de forma excepcional y no repetitiva, derogaciones (p. ej. consentimiento explícito para la transferencia).
7.2 Evaluación de transferencia. Cuando se usen SCC/IDTA, la parte exportadora realizará la evaluación de impacto/riesgo de la transferencia y adoptará medidas suplementarias cuando sea necesario.
7.3 Reuso cross‑border en la Red. Cuando un reuso implique transferencia internacional, esta se cubrirá con el mecanismo aplicable por par de jurisdicciones (matriz documentada por red, Apéndice 2/3) y quedará previamente reflejada en el consentimiento de la Persona Verificada.
8. Apéndices
- Apéndice 1 — Detalles del tratamiento (art. 28(3)): objeto, duración, naturaleza/finalidad, tipos de datos (incl. biométricos), categorías de Titulares.
- Apéndice 2 — Anexo de la Red de Verificación Única (reuso): categorías, operación de comunicación Donante→Receptor, roles por operación, base legal, transferencias, retención y sello blockchain, seguridad de red, atención de derechos.
- Apéndice 3 — Rider por jurisdicción (Brasil, Chile, México, Colombia, Argentina, EE. UU., UE/RU).
- Apéndice 4 — Rider de resiliencia para clientes financieros (DORA / externalización / auditoría de reguladores).
- Apéndice 5 — Medidas técnicas y organizativas de seguridad.
- Apéndice 6 — Lista de Sub‑encargados.
Apéndice 2 — Anexo de la Red de Verificación Única (los 5 puntos del reuso)
(1) Categorías de datos y operación nueva. Se incorpora como categoría el “conjunto de evidencia de verificación” (datos identificatorios declarados; imágenes de documento; imagen/plantilla facial — dato biométrico/sensible; metadatos de captura; identificador de red verificado = email) y como operación nueva la “comunicación Donante→Receptor previa coincidencia por identificador verificado y consentimiento del Titular”. Los Resultados quedan expresamente FUERA de toda comunicación.
(2) Roles por operación. (a) Verificación normal: Cliente = Responsable, Rillis = Encargado. (b) Reuso: Donante y Receptor = responsables independientes entre sí; Rillis = Encargado de cada uno + responsable independiente de la infraestructura de red. Se especifica quién atiende cada derecho del Titular (regla: cada Responsable atiende los derechos respecto del tratamiento bajo su control; Rillis asiste técnicamente y atiende lo relativo a la infraestructura de red).
(3) Base legal y transferencias. Consentimiento explícito del Titular como base de la comunicación y del dato biométrico; para reusos cross‑border, el mecanismo de transferencia aplicable por par de jurisdicciones, documentado por red. El consentimiento es por reuso y por receptor; su retiro apaga reusos futuros sin afectar tratamientos ya perfeccionados ni la conservación legal del Receptor.
(4) Retención y borrado (incl. sello blockchain). (a) Cada Responsable conserva según su plazo (default 5 años GAFI). (b) El borrado a solicitud del Titular opera off‑chain: se elimina la evidencia y se notifica a los Responsables. (c) El hash on‑chain no se elimina; eliminados la evidencia y el salt off‑chain, deja de ser referible a persona. (d) Registros de auditoría inmutables sin datos personales en claro.
(5) Sub‑encargados y seguridad de red. Sub‑procesadores del flujo de reuso: proveedor OCR/biometría; proveedor de email para el código OTP; nube; (la blockchain se declara como tecnología de registro destinataria de un hash NO personal, no como Sub‑encargado). Medidas propias de la red: match biométrico 1:1 con umbral mínimo y detección de vida; anti‑enumeración (el código se pide antes de revelar si existe coincidencia; respuestas uniformes); cifrado en reposo; acceso sin duplicar datos; y registro de auditoría inmutable por reuso.