Cuando una norma internacional define cómo se estructura una pieza concreta de información, normalmente se vuelve infraestructura invisible: la mayoría de las personas usan el formato sin saber que existe. Eso pasó con los certificados X.509, con los archivos PDF/A para preservación documental, con el protocolo HTTPS. Pasó también con los recibos de consentimiento, aunque en ese caso el estándar es relativamente nuevo y todavía no ha aterrizado fuera de los círculos técnicos.
Hablamos de ISO/IEC TS 27560:2023 — Privacy technologies — Consent record information structure, publicada en 2023, y de su antecesora directa, la Kantara Consent Receipt v1.1.0, especificación abierta publicada en 2018 por la Kantara Initiative. Las dos resuelven la misma pregunta: ¿cómo registramos un consentimiento de forma que sea legible para humanos, procesable por máquinas, interoperable entre sistemas y oponible más allá de la jurisdicción donde se capturó?
El problema que el estándar resuelve
Antes de los estándares, cada empresa registraba el consentimiento como podía. Una columna en una tabla, un PDF firmado, un correo. Cuando llegaba el momento de demostrar el consentimiento ante una autoridad o un titular, los registros eran difíciles de auditar, imposibles de mover entre sistemas y no contemplaban los matices que el derecho exige: qué finalidad concreta se aceptó, qué versión del texto se mostró, qué base de licitud se invocó, si hubo decisiones automatizadas, si los datos viajaron a otra jurisdicción.
El estándar codifica todo eso en una estructura. Cuando una empresa adopta ISO 27560, su registro de consentimiento contiene los mismos campos, en los mismos lugares, con los mismos significados que un registro emitido por cualquier otra empresa que también lo adopte. Y eso hace que el consentimiento se vuelva un activo portátil, no un cautivo del sistema que lo capturó.
Qué es un Consent Receipt
El estándar distingue entre dos cosas: el Consent Record, que es el registro internal del consentimiento que la empresa mantiene, y el Consent Receipt, que es la versión legible y verificable que se le entrega al titular o que se exhibe ante una autoridad. Ambos comparten la misma estructura de campos.
Un Consent Receipt mínimamente válido contiene:
- Identificadores: del recibo, del titular (idealmente hasheado), del responsable, del DPO si lo hay.
- Tiempo: marca de tiempo del evento, idealmente con sello criptográfico bajo RFC 3161.
- Acto: tipo de evento (otorgamiento, revocación, renovación, expiración), canal de captura.
- Política: referencia a la política de tratamiento mostrada, con su versión y su hash.
- Finalidades: cada propósito por separado, con su nombre, descripción, base de licitud (consent, contract, legal_obligation, legitimate_interest, public_interest, vital_interest), categorías de datos involucradas, destinatarios, plazos de conservación, transferencias internacionales con sus garantías, indicación de si el tratamiento incluye decisiones automatizadas.
- Idioma y jurisdicción: en qué idioma se mostró la política y bajo qué ley se rige el acto.
Estructuralmente queda parecido a esto:
"schema_version": "ISO/IEC TS 27560:2023",
"receipt_id": "VL-RID-9F2C8A41B3D0E5F2",
"receipt_timestamp": "2026-04-29T14:42:18Z",
"controller_name": "Equifax Servicios Chile S.A.",
"controller_tax_id": "99.500.840-K",
"subject_identifier_hash": "a3f2c8...d471",
"event_type": "grant",
"channel": "web",
"policy": { "version": "v4.2", "hash_sha256": "9c1a...e2b3" },
"purposes": [
{ "code": "identity.biometric", "legal_basis": "contract", ... },
{ "code": "marketing.email", "legal_basis": "consent", ... }
],
"language": "es-CL", "jurisdiction": "CL"
}
Ese JSON es un objeto canónico. Sobre él se calcula un hash, sobre el hash se sella el tiempo, y sobre el sello se construye la cadena de evidencia. El recibo es legible para el titular, procesable por sistemas y verificable por terceros sin acceso al sistema que lo emitió.
El vocabulario semántico que falta: W3C DPV
Una pieza complementaria del estándar es el W3C Data Privacy Vocabulary (DPV), un vocabulario semántico que define formalmente qué significa cada base de licitud, cada categoría de datos, cada finalidad, cada derecho. Sin DPV, dos sistemas pueden usar la misma palabra para referirse a cosas distintas. Con DPV, "interés legítimo" significa lo mismo en un sistema chileno que en uno alemán, y un consentimiento es portable de forma robusta.
¿Y qué tiene que ver esto con la Ley 21.719?
La Ley 21.719 no exige ISO 27560. La Ley exige consentimiento libre, informado, específico e inequívoco, y que el responsable pueda probarlo. Pero la estructura que el estándar propone es la mejor herramienta práctica para cumplir esa exigencia, porque:
- El estándar obliga a registrar la granularidad por finalidad, que es exactamente lo que la Ley pide. Un consentimiento ISO 27560 con un solo bloque para tres finalidades distintas es inválido por construcción.
- El estándar exige registrar la base de licitud de cada finalidad. Las seis bases de la Ley 21.719 (consentimiento, contrato, interés legítimo, obligación legal, interés vital, interés público) coinciden con la taxonomía DPV.
- El estándar contempla decisiones automatizadas y transferencias internacionales como campos de primera clase, igual que los Arts. 8 bis y 27 de la Ley 21.719.
- El estándar genera evidencia portable, lo que permite al titular ejercer su derecho de portabilidad del Art. 9 de la Ley 21.719 sin esfuerzo.
Adoptar ISO 27560 nativamente desde el día uno es, en la práctica, la forma más eficiente de aterrizar el cumplimiento de la Ley 21.719 sin reinventar la rueda y sin atarse a un proveedor específico.
Por qué pocos productos chilenos lo implementan
Por simple inercia. Las herramientas globales (OneTrust, TrustArc, Didomi, Usercentrics) lo soportan parcialmente, pero su foco sigue siendo cookies web y GDPR. Los productos chilenos existentes nacieron antes de que el estándar madurara, y arrastran modelos de datos propios que pueden mapearse a ISO 27560 con esfuerzo, pero no nacen alineados con él.
Para una empresa que va a empezar de cero su sistema de consentimiento bajo la Ley 21.719, la decisión correcta es elegir un proveedor que implemente ISO 27560 nativamente. Esto cuesta lo mismo en licencia y se nota la diferencia el día que la Agencia llega a fiscalizar o cuando un titular pide su recibo de consentimiento en formato exportable.
Cómo lo hace Voluntas
Voluntas, la plataforma de Nortika, implementa ISO/IEC TS 27560:2023 como representación canónica de cada evento de consentimiento, complementada con Kantara Consent Receipt v1.1.0 para interoperabilidad con sistemas que solo entienden Kantara, y con W3C DPV en la taxonomía de bases de licitud y finalidades. El payload ISO 27560 se genera al momento de la captura, se sella con TSA acreditada y se ancla en una cadena privada de bloques con publicación periódica en blockchain pública. El titular puede pedir su recibo y Voluntas se lo entrega como JSON exportable o como PDF firmado. Si el titular cambia de proveedor, su consentimiento es portable.
El estándar es una decisión técnica con consecuencia comercial: implementarlo bien hoy significa que mañana el sistema sigue siendo válido cuando la Agencia publique sus criterios y cuando el resto del mercado se vea forzado a alinearse.