Mapeo de protección de datos de la Ley 19.628 de Chile

Documentación de referencia: no es un dispositivo médico

Esta documentación describe una implementación de referencia cuyo corpus conversacional y de evaluación es 100% sintético. Es una referencia de capacidades y preparación, no una certificación de cumplimiento ni asesoría legal, y no es un dispositivo médico. No está validada clínicamente y no maneja PHI de producción.

Esta demo trata datos personales reales

A diferencia del plano conversacional, el plano de contacto / embudo de la demo alojada recolecta y persiste datos personales reales (correo, nombre, organización) cuando un visitante solicita una clave de demostración. Dado que el responsable está establecido en Chile, ese tratamiento está sujeto a la Ley 19.628. Esta página se corrigió para describir ambos planos con exactitud; la afirmación anterior de que “no maneja datos personales y, por lo tanto, no está sujeta a la Ley 19.628” era inexacta y se eliminó. Para la declaración completa de responsable, base de licitud, retención y derechos, consulta el Aviso de Privacidad de la Demo.

Mapea la demo alojada ai-agent-eval-harness-healthtech frente a la Ley 19.628 (Ley chilena sobre Protección de la Vida Privada), con sus modificaciones, y la modernización alineada con el GDPR que introduce la Ley 21.719. Describe cómo se tratan los dos planos de datos de la demo y qué añadiría un despliegue de producción más amplio.

Léase junto con el Aviso de Privacidad de la Demo, la postura regulatoria y la evaluación de preparación para HIPAA.

Contexto legislativo

La Ley 19.628 regula el tratamiento de datos personales en Chile. Entre los hitos clave se cuentan el reconocimiento constitucional de la protección de datos en 2018 (Ley 21.096) y la modernización alineada con el GDPR de 2024 (Ley 21.719, publicada el 13 de diciembre de 2024 y vigente desde el 1 de diciembre de 2026), que refuerza los requisitos de consentimiento, los derechos de los titulares y las disposiciones sobre transferencias transfronterizas, y crea la Agencia de Protección de Datos Personales (APDP). La ley aplica al tratamiento de datos personales cuando el responsable (controlador de datos) está domiciliado en Chile o cuando el tratamiento utiliza medios situados en territorio chileno.

Esta demo está claramente dentro del ámbito de aplicación: el responsable está establecido en Chile.

Los dos planos de datos

La demo alojada trata datos en dos planos distintos. La Ley 19.628 aplica de forma diferente a cada uno, por lo que se evalúan por separado a lo largo de esta página.

Plano	Qué contiene	¿Datos personales?	Dónde se trata
(a) Plano conversacional (tu chat con el agente)	El texto del turno que escribes. Los identificadores directos (correo, teléfono, identificaciones gubernamentales, números de tarjeta) se redactan antes de que el turno se use para cualquier cosa que no sea producir la respuesta; los nombres se conservan deliberadamente dentro del hilo para personalización. No se conserva ningún registro de la conversación; las direcciones IP y los User-Agent en bruto no se almacenan. La demo está diseñada para entradas sintéticas y prohíbe datos reales de pacientes / PHI.	Datos operativos seudonimizados. El corpus es sintético por diseño, pero los nombres conservados en el hilo hacen que este plano se trate mejor como datos personales seudonimizados, no como datos plenamente anónimos.	Se transmite a subprocesadores de IA externos nombrados en Estados Unidos en cada turno (transferencia transfronteriza).
(b) Plano de contacto / embudo (tu solicitud de clave)	El correo, el nombre y la organización que envías, además de tu finalidad declarada y el registro de consentimiento.	Sí — datos personales reales.	Se almacena en Supabase (PostgreSQL gestionado, región US East — us-east-2, Ohio); la aplicación corre en Google Cloud Run (región de EE. UU.). Esta PII no se reenvía a los subprocesadores de chat.

El resto de esta página evalúa las obligaciones de la Ley 19.628 frente a estos dos planos tal como opera la demo hoy, no frente a un sistema hipotético exclusivamente sintético.

Responsable, ley aplicable y base de licitud

• Responsable: Waldemar Szemat, establecido en Chile. Contacto de privacidad y derechos del titular: waldemar@szemat.pro.
• Ley aplicable: la Ley 19.628 (Chile) es la ley rectora principal, porque el responsable está establecido en Chile. El GDPR aplica para los titulares en la UE/EEE; la CCPA/CPRA aplica para los residentes de California.
• Base de licitud: consentimiento explícito y granular, registrado antes del tratamiento. Para el plano de contacto / embudo, la barrera de la solicitud de clave se niega a persistir cualquier PII salvo que el titular haya aceptado los términos de privacidad (la barrera de base de licitud GOVR-05; el indicador de consentimiento, la versión del aviso y una marca de tiempo de consentimiento estampada en el servidor se almacenan con la fila). El contacto de marketing es un consentimiento separado, no agrupado y opcional que nunca es obligatorio para usar la demo y puede retirarse en cualquier momento. El responsable no se basa en el interés legítimo para estos datos personales.

Evaluación de los principios sobre datos personales

La Ley 19.628 vigente contiene definiciones en su Art. 2 en lugar de un catálogo de principios al estilo del GDPR; el catálogo siguiente corresponde al marco alineado con el GDPR que introduce la Ley 21.719 (vigente desde el 1 de diciembre de 2026), leído junto con las obligaciones que la Ley 19.628 ya impone.

Principio (Ley 21.719)	Estado actual — tal como opera la demo hoy	Camino a producción (despliegue más amplio)
Licitud	La PII del plano de contacto se trata sobre consentimiento explícito y granular registrado antes de la escritura (barrera GOVR-05; sin consentimiento, no hay fila). El plano conversacional opera con entradas redactadas y seudonimizadas.	Base de licitud documentada para cada actividad de tratamiento; revisión periódica de la base legal.
Limitación de la finalidad	La PII de contacto se usa solo para procesar la solicitud de clave y, con un consentimiento separado, para conversar sobre un piloto pagado. La pista de triaje de leads del lado del operador es meramente indicativa y nunca condiciona el acceso.	Vinculación explícita de finalidad por campo; limitación de la finalidad aplicada en el diseño del sistema.
Minimización de datos	Solo se recolectan correo, nombre, organización y finalidad en el plano de contacto. En el plano conversacional, no se conserva ningún registro de la conversación, los identificadores directos se redactan antes de que el turno se use para cualquier cosa que no sea producir la respuesta y la telemetría excluye el texto del usuario.	Revisión periódica de los campos recolectados; eliminación de los datos que ya no se necesitan.
Exactitud	Los titulares pueden corregir su registro contactando al responsable; los datos de contacto se autodeclaran al momento de la solicitud.	Mecanismo de corrección autoservicio; procedimientos de revisión de la calidad de los datos.
Limitación del almacenamiento	Aplica una retención definida (ver la sección Retención más abajo): los contactos con opt-in se conservan hasta que se solicite su eliminación; los contactos sin opt-in tienen un tope de 12 meses; los registros de chat redactados son eliminables previa solicitud.	Aplicación automatizada de la retención y eliminación segura al vencimiento.
Seguridad	Redacción de identificadores directos en entrada/salida; el correo en bruto nunca se duplica para el enlace (un SHA-256 con sal, subject_email_hash, vincula al titular entre tablas); las rutas de derechos del titular son de alcance por clave y a prueba de IDOR; los códigos de verificación se almacenan solo como hashes con sal; los secretos se mantienen fuera del repositorio; HTTPS en la demo alojada.	Medidas técnicas y organizativas apropiadas al riesgo; cifrado en reposo, controles de acceso formales, procedimientos de notificación de brechas; ejecución de los DPA de los proveedores.
Transparencia	El Aviso de Privacidad de la Demo se presenta antes de la recolección y se enlaza desde la barrera de consentimiento; la barrera registra qué versión del aviso vio el titular.	Avisos por capas; lenguaje claro sobre finalidades, retención y derechos (ya sustancialmente cumplido).

Derechos de los titulares de datos

La demo implementa los derechos del titular dentro de la sesión (de alcance por clave, a prueba de IDOR) y mediante una vía por correo del operador. Nunca se honra un identificador suministrado por el cliente; el solicitante se resuelve a partir de su clave de demostración.

Derecho (Ley 19.628, Art. 12)	Estado actual — tal como opera la demo hoy	Notas
Acceso	El titular puede recuperar sus filas almacenadas dentro de la sesión (GET /data/export), o solicitarlas al responsable por correo.	La exportación es completa-o-rechazada (nunca un parcial silencioso).
Rectificación	Se gestiona contactando a waldemar@szemat.pro; los datos de contacto se autodeclaran y pueden volver a solicitarse.	A la escala actual de la demo, la vía por correo es el canal de rectificación aceptado; un control de rectificación autoservicio dentro de la sesión se difiere a un despliegue de producción más amplio.
Cancelación (eliminación)	El titular puede eliminar todos sus datos dentro de la sesión (DELETE /data), lo que cascada sobre las tablas de su propiedad y la fila de captura de lead; un runbook del operador y un script cubren la vía fuera de banda (por ejemplo, una clave expirada).	Una clave revocada por abuso es rechazada para la eliminación, de modo que no pueda borrar su propio rastro de abuso; el acceso, la exportación y la exclusión sobreviven a la revocación.
Bloqueo / exclusión (opt-out)	El titular puede detener el registro futuro de interacciones dentro de la sesión (POST /opt-out) sin terminar la sesión; el consentimiento de marketing puede retirarse.	El Art. 12 de la Ley 19.628 confiere el “bloqueo” (suspensión temporal).
Portabilidad (Ley 21.719)	La exportación dentro de la sesión devuelve las filas del titular en una carga JSON estructurada.	La portabilidad pasa a ser un derecho legal explícito con la Ley 21.719 (vigente desde el 1 de diciembre de 2026).

Ley 21.719 (vigente desde el 1 de diciembre de 2026) añade el derecho de oposición al tratamiento por motivos legítimos y el derecho a la portabilidad de los datos, y crea la Agencia de Protección de Datos Personales (APDP) como autoridad de protección de datos de Chile. Conforme a la Ley 19.628 vigente, el Art. 12 confiere acceso, rectificación, cancelación (eliminación) y bloqueo; no establece una autoridad de protección de datos.

Disposiciones sobre datos sensibles

La Ley 19.628 establece protecciones reforzadas para los datos personales sensibles (datos de salud, datos biométricos, entre otros). Conforme al Art. 10, los datos sensibles solo pueden tratarse cuando la ley lo autorice, cuando el titular consienta, o cuando sean necesarios para la determinación u otorgamiento de beneficios de salud que correspondan a sus titulares.

Aspecto	Estado actual — tal como opera la demo hoy	Camino a producción
Datos de salud	No se recolectan datos de salud reales. Todo el contenido clínico es sintético; los términos de uso prohíben ingresar datos reales de pacientes o PHI, y los identificadores directos en el chat se redactan.	Consentimiento expreso para el tratamiento de datos de salud; limitación de la finalidad al contexto de la atención de salud; seguridad reforzada; acceso restringido a personal autorizado.
Sensibilidad de la PII de contacto	El correo, el nombre y la organización son datos personales ordinarios, no datos sensibles / de categoría especial, por lo que el régimen de datos sensibles del Art. 10 no se activa con el plano de contacto.	Si campos futuros fueran sensibles, aplicarían las condiciones del Art. 10.
Datos biométricos	No se recolectan ni se tratan datos biométricos (las funciones de voz, cuando se activan, se divulgan por separado y están desactivadas por defecto).	Consentimiento expreso; limitación de la finalidad; seguridad reforzada; eliminación cuando se cumple la finalidad.
Gestión del consentimiento	Se registra un consentimiento granular y no agrupado antes del tratamiento (GOVR-05); el canal de marketing es un opt-in separado y opcional; se almacenan la versión y la marca de tiempo del consentimiento.	Plataforma de gestión del consentimiento; mecanismo de retiro; traza de auditoría del consentimiento (sustancialmente cumplido hoy a escala de demo).

Transferencia transfronteriza de datos

Aspecto	Estado actual — tal como opera la demo hoy	Camino a producción
Plano conversacional -> subprocesadores de IA	La entrada de chat se envía a subprocesadores de LLM, incrustaciones y reordenamiento nombrados en Estados Unidos en cada turno. Es una transferencia transfronteriza de contenido de entrada redactado. Voyage AI tiene una postura de entrenamiento por defecto; la exclusión a nivel de administrador de la organización no está activada para esta demo.	Evaluación de la transferencia y salvaguardas apropiadas; activar la exclusión de Voyage y ejecutar los DPA de los proveedores (condición previa para operar con datos reales). La transferencia se sustenta en el consentimiento explícito e informado del titular a la transferencia transfronteriza a Estados Unidos, divulgado en el Aviso de Privacidad de la Demo y registrado en la barrera de consentimiento antes de cualquier tratamiento; los DPA de los proveedores se ejecutan como salvaguarda complementaria.
Plano de contacto / embudo -> Supabase	La PII de contacto se almacena en Supabase (PostgreSQL gestionado, región US East — us-east-2, Ohio); la aplicación corre en Google Cloud Run (región de EE. UU.). Esta PII no se reenvía a los subprocesadores de chat.	La transferencia transfronteriza de la PII de contacto a Estados Unidos se sustenta en el consentimiento explícito del titular registrado en la barrera de solicitud de clave; la región de Supabase (us-east-2, Ohio) se refleja en la divulgación de subprocesadores.
Telemetría	Solo se exportan atributos de traza redactados al sink de telemetría en vivo (Langfuse Cloud); el texto de chat previo a la redacción nunca se le envía.	Ejecutar el DPA del proveedor de telemetría; confirmar la ventana de retención y la región de alojamiento antes de operar con datos reales.

Retención

• Los datos de contacto enviados con una solicitud de clave, cuando el titular dio el consentimiento de marketing por separado, se conservan indefinidamente hasta que se solicite su eliminación (“indefinido-hasta-la-eliminación”). Los contactos consentidos no se eliminan automáticamente; la eliminación previa solicitud siempre se respeta.
• Los datos de contacto enviados sin el consentimiento de marketing se conservan solo el tiempo necesario para procesar la solicitud, con un tope de 12 meses, tras lo cual son eliminables.
• Los registros de chat redactados son datos operativos de la demo y son eliminables previa solicitud mediante los controles de derechos del titular.

Qué añadiría la producción completa

La demo ya cumple las obligaciones centrales de la Ley 19.628 para los datos personales que trata (base de licitud, aviso, derechos del titular, retención). Un despliegue de producción más amplio que tratara datos personales o de salud reales a escala requeriría además:

1. Registro del responsable ante la Agencia de Protección de Datos Personales (APDP), la autoridad supervisora creada por la Ley 21.719 (operativa desde el 1 de diciembre de 2026), si se requiere para la actividad de tratamiento específica. A la escala actual de la demo, este registro no es exigible; se reevaluaría para un despliegue de producción más amplio que trate datos personales o de salud reales a escala.
2. Un Delegado de Protección de Datos o representante, si se requiere por la escala y la naturaleza del tratamiento. No se exige un Delegado de Protección de Datos ni representante para el responsable a la escala y naturaleza actuales del tratamiento; se reevaluaría para un despliegue de producción más amplio.
3. DPA de proveedores ejecutados (incluida la exclusión de Voyage AI y un DPA del proveedor de telemetría) antes de operar con datos reales.
4. Procedimientos formales de notificación de brechas y evaluaciones de seguridad periódicas.
5. Controles reforzados de datos sensibles (Art. 10) si el sistema alguna vez trata datos de salud reales, incluido el consentimiento expreso y por escrito y la limitación de la finalidad a la gestión de la atención de salud.
6. Aplicación automatizada de la retención (el cron de eliminación autoejecutable está diferido para después del lanzamiento; la postura de lanzamiento es el runbook documentado más el script de eliminación del operador).

Véase también

• Aviso de Privacidad de la Demo — responsable, base de licitud, subprocesadores, retención y derechos
• Postura regulatoria — límite regulatorio
• Plan de registro de auditoría — qué se registra y persiste
• Evaluación de preparación para HIPAA — evaluación de preparación para HIPAA
• Documentación de redacción de PII — documentación de redacción de PII
• Diseño de observabilidad — diseño de observabilidad