Ley N° 21.719 · plena vigencia el 1 de diciembre de 2026
Ante un incidente, es la organización la que debe acreditar que sus medidas de seguridad existían y funcionaban. Consta deja esa constancia en cada acceso a datos personales.
Ley N° 19.628, art. 14 quinquies, inciso final
El problema
La ley invirtió la carga de la prueba. Eso convierte el cumplimiento en un problema de ingeniería: hay que poder mostrar hechos, no intenciones.
Un documento de políticas describe lo que debería ocurrir. No puede demostrar que un control estuvo activo un martes de madrugada. Un sistema que registra cada decisión, sí.
Ley N° 19.628, art. 14 quinquies, inciso final
Un registro de accesos guarda un usuario y una hora. La ley exige que todo tratamiento tenga una finalidad. Si la finalidad no quedó anotada junto al acceso, después no hay cómo mostrar que ese acceso correspondía.
Ley N° 19.628, art. 3° letra b)
La ley prohíbe tratar datos de salud recolectados en ciertos ámbitos, como el laboral o el de seguros. Los sistemas guardan el dato, no su origen. Sin el origen, esa prohibición no se puede aplicar, y menos demostrar que se respetó.
Ley N° 19.628, art. 16 bis, inciso 3°
Consta decide si un acceso a datos personales es lícito, entrega sólo los campos que corresponden a la finalidad invocada y deja constancia verificable de cada decisión.
Datos de salud
Son tres exigencias distintas sobre los datos de salud, que el reglamento europeo no contiene. Un sistema que controla sólo quién accede no ve ninguna de las tres.
Inciso 1°
Aunque el titular haya consentido expresamente, sus datos de salud sólo pueden tratarse para los fines previstos por las leyes especiales en materia sanitaria. El consentimiento no basta: este filtro opera siempre.
Toda solicitud declara su finalidad. Sin una finalidad admisible se deniega, y la denegación queda registrada.
Ley N° 19.628, art. 16 bis, inciso 1°
Inciso 2°
Fuera del consentimiento, la ley enumera de forma taxativa cuándo se puede tratar un dato de salud:
Lista blanca con denegación por defecto: lo que no está habilitado expresamente se rechaza. La denegación también es evidencia.
Ley N° 19.628, art. 16 bis, inciso 2°, letras a) a f)
Inciso 3°
Se prohíbe tratar datos de salud y muestras biológicas recolectados en el ámbito laboral, educativo, deportivo, social, de seguros, de seguridad o de identificación, salvo que una ley lo autorice expresamente.
El origen de cada dato lo resuelve el agente en la fuente. Quien pide no puede declararlo: elegiría bajo qué régimen se evalúa su propia solicitud.
Ley N° 19.628, art. 16 bis, inciso 3°
En el inciso 2° es una finalidad: medicina laboral, el para qué. En el inciso 3° es una procedencia: ámbito laboral, el de dónde. Se puede hacer medicina laboral, pero no con datos de salud que recolectó el empleador.
Por eso no basta con clasificar el dato. Cada acceso se evalúa por la finalidad que se invoca y por el contexto en que el dato se recolectó.
Cómo funciona
Dos piezas separadas por una frontera. El agente decide y registra dentro de la organización. La consola muestra el estado de cumplimiento con metadatos, sin recibir un solo dato personal.
Cero datos personales en la consola. Lo verifica una prueba que compara todo lo que la consola recibe contra cada valor de la fuente. Si la consola guardara los datos, sería el repositorio único de información sensible de varias organizaciones: el riesgo que este proyecto existe para evitar.
Medido con datos sintéticos · caso de prueba CP-10Núcleo y paquetes
La ley es modular: un régimen común más regímenes especiales por categoría de dato y por sector. Todos comparten la misma forma lógica.
Cada régimen se reduce a tres cosas: qué finalidades admite, qué procedencias prohíbe y qué combinaciones habilita, con denegación por defecto. El artículo 16 bis es el caso más estricto de ese patrón, no una excepción.
De ahí la arquitectura. Un núcleo genérico que no conoce ningún dominio: transporta, compara y registra. Y paquetes normativos declarativos, un archivo por régimen, donde cada regla lleva su artículo. Un paquete sin artículo no carga.
La política es el archivo. Se puede leer, auditar y versionar sin tocar el código, y cada decisión registra qué paquete y qué versión la tomó.
paquete: clinguard
version: 0.7.1
finalidades_admisibles:
- id: asistencia_sanitaria
articulo: "Ley 19.628, art. 16 bis inc. 2° letra e)"
procedencias_declaradas:
seguros:
prohibida: true
articulo: "Ley 19.628, art. 16 bis inc. 3°"
alcance: [salud, perfil_biologico]
matriz_habilitacion:
- rol: medico_tratante
finalidad: asistencia_sanitaria
categoria: salud
procedencia: clinica
campos: [diagnostico, alergias, medicamentos]Paquete · salud
Las tres capas del artículo 16 bis para un prestador de salud: finalidades sanitarias, las siete procedencias prohibidas y la habilitación por rol.
Ley N° 19.628, art. 16 bis
Paquete · personas
El mismo inciso 3° visto desde el empleador: los datos laborales son propios, pero los de salud ocupacional quedan prohibidos salvo autorización legal expresa.
Ley N° 19.628, art. 16 bis, inciso 3° · Ley N° 16.744
Cero líneas del núcleo modificadas para incorporar el segundo paquete. Todo lo que se agregó fue configuración. Una prueba que corre en cada cambio verifica que el núcleo no mencione ningún dominio: si falla, el cambio no entra.
Medido · caso de prueba CP-11Integración
El sistema le pregunta al agente antes de entregar un dato. Aquí, un médico pide un diagnóstico que llegó por convenio con una aseguradora: la respuesta es una denegación que cita su artículo.
curl -s -X POST https://agente.interno/v1/authorize \
-H "Content-Type: application/json" \
-H "X-Consta-Key: $CONSTA_AGENT_KEY" \
-d '{
"actor": {
"id": "prof_alfa_07",
"rol": "medico_tratante",
"organizacion": "org_alfa"
},
"finalidad": "asistencia_sanitaria",
"titular": "pac_00042",
"recurso": {"tipo": "condicion", "id": "cnd_00042"},
"campos": ["diagnostico"]
}'{
"decision": "denegar",
"motivo": "procedencia_prohibida",
"articulo": "Ley 19.628, art. 16 bis inc. 3°",
"detalle": [],
"paquete": "clinguard@0.7.1",
"registro": {
"id": 34,
"hash": "a7217279…8c7e54"
}
}
# La petición no decía de dónde vino el dato.
# El agente lo resolvió en la fuente: "seguros".
# La decisión ya quedó anexada a la cadena:
# registro.id es su posición; registro.hash,
# la huella que la encadena con la anterior.Ejemplo ilustrativo con datos sintéticos: la posición y la huella del registro son de muestra. Los identificadores son opacos, nunca un RUT ni un nombre.
El agente se conecta con un rol que no puede escribir. Lo comprueba al arrancar, y si el rol puede escribir, no arranca.
La decisión es campo por campo. Lo que la finalidad no habilita no se pide a la base: no hay nada que filtrar después.
Si el registro no está disponible, el agente responde que no puede decidir. Ningún acceso ocurre sin quedar anotado.
En una demostración vemos el recorrido completo con datos sintéticos: una solicitud, la decisión con su artículo, la constancia en la cadena y el expediente que se entrega en una fiscalización.
Consta produce evidencia, no certificación. Certificar el cumplimiento es una atribución que la ley reserva a la Agencia de Protección de Datos Personales. Lo que Consta entrega es el registro que permite acreditar, ante ella o ante un tribunal, que las medidas existían y funcionaban.
Ley N° 19.628, art. 51