Un desarrollador de una healthtech me hizo la pregunta más honesta que he escuchado sobre esta ley: «Sé que los datos de salud son más delicados, y sé que en diciembre de 2026 esto se pone serio. Pero cuando busco qué tengo que hacer yo, con mi sistema, encuentro puros artículos legales que explican la ley en abstracto.» Tenía razón. Hay decenas de guías sobre la Ley 21.719 en general, y casi ninguna responde la pregunta operativa: si mi empresa o mi software trata información de salud, ¿qué me exige la ley y cómo lo implemento?
Ese vacío es el que este artículo viene a llenar. No es una explicación de la ley completa (para eso tienes la guía general de la Ley 21.719). Es la vista específica para quien procesa el tipo de dato más protegido que existe: la información de salud de una persona.
Y hay un detalle que casi nadie menciona, aunque es el que más incidentes causa. La ley te obliga a cifrar la historia clínica en la base de datos, a pedir consentimiento, a documentar cada tratamiento. Todo correcto. Pero el dato clínico no vive solo en el servidor. Vive en el notebook del médico que revisa fichas desde la casa, en la tablet de la enfermera en urgencias, en el equipo de recepción que agenda pacientes. Puedes cifrar cada columna de la ficha clínica y aun así incumplir la ley cuando una tablet con esa ficha abierta desaparece de la sala.
Este artículo cubre las dos capas: las obligaciones que la ley pone sobre tus datos y tu software, y el punto ciego del endpoint que las guías legales no tocan. Con lo que arriesgas si lo ignoras, que en información de salud no es menor.
Por qué la Ley 21.719 trata los datos de salud distinto
Los datos de salud son una categoría de dato sensible bajo la Ley 21.719, y eso cambia todo lo que puedes y no puedes hacer con ellos. Tratarlos exige, por regla general, consentimiento explícito del titular y medidas de seguridad proporcionalmente más estrictas que las de un dato común como un nombre o un correo. No es una diferencia de matiz: es un régimen legal aparte.
La ley agrupa la salud junto a otras categorías de máxima protección: origen, vida sexual, datos biométricos, afiliación sindical y datos genéticos (puedes revisar el texto oficial de la Ley 21.719 en la Biblioteca del Congreso). Lo hace porque una filtración de estos datos no se repara. Si se filtra tu correo, cambias de correo. Si se filtra tu historia clínica o tu condición de salud, el daño es permanente y la persona no tiene forma de deshacerlo. Esa es la lógica detrás del trato reforzado, y conviene entenderla antes de ver los requisitos.
Para el jefe de TI de una clínica o el CTO de una healthtech, el punto práctico es este: no puedes tratar la ficha clínica de un paciente con el mismo estándar con el que tratas la base de datos de tu newsletter. Si hoy tu sistema mezcla ambos tipos de dato bajo los mismos controles, ese es tu primer gap. La clasificación de qué es exactamente un dato sensible la desarrollamos en la guía de datos personales vs. datos sensibles; aquí asumimos que la salud entra en la categoría reforzada y nos concentramos en qué hacer con ella.
¿Qué te exige la Ley 21.719 si tratas datos de salud?
Si tratas datos de salud, la ley te exige cuatro cosas: base de licitud válida (casi siempre consentimiento explícito), evaluación de impacto previa cuando el tratamiento es a gran escala, medidas de seguridad reforzadas, y un registro de actividad que puedas mostrar. Cada una deja rastro verificable.
Empecemos por el consentimiento. Para un dato común, la ley admite varias bases de licitud. Para información de salud, el estándar sube: necesitas consentimiento explícito, informado y específico, salvo excepciones legales acotadas (por ejemplo, una urgencia médica que impide pedirlo). «Explícito» significa que no sirve una casilla premarcada ni un consentimiento genérico enterrado en los términos y condiciones. El paciente tiene que entender qué dato tratas y para qué.
La segunda exigencia es la evaluación de impacto, o DPIA. La ley la vuelve obligatoria cuando tratas datos sensibles a gran escala, y una clínica, un laboratorio o un sistema de gestión clínica caen de lleno en ese supuesto. La DPIA va antes de implementar el tratamiento, no como un trámite posterior. El paso a paso lo cubrimos en la guía de evaluación de impacto (DPIA); lo que importa aquí es que para salud dejó de ser opcional.
La tercera son las medidas de seguridad. La ley exige que sean proporcionales al riesgo, y el riesgo de un dato clínico es alto por definición. Esto se traduce en controles concretos que veremos en la próxima sección. La cuarta es el registro de actividades de tratamiento (RAT): un inventario de qué datos tratas, con qué finalidad, por cuánto tiempo y con qué medidas. Es el documento que la Agencia te va a pedir primero, y puedes armarlo siguiendo la guía para crear tu RAT desde cero.
Quick win: Toma tu tratamiento de datos de salud más importante y responde tres preguntas en una hoja: ¿tengo consentimiento explícito y puedo probarlo? ¿hice una DPIA antes de empezar? ¿está en mi RAT? Si alguna respuesta es «no» o «no estoy seguro», ahí empieza tu plan.
¿Qué requisitos técnicos exige la ley a un software de salud?
A un software que procesa datos clínicos, la ley le exige cuatro controles: cifrado en reposo de los campos sensibles, minimización de lo que recolectas y muestras, retención que borre o anonimice al vencer el plazo, y registros de actividad sin datos identificables. Un auditor espera verlos funcionando, no solo declarados.
El cifrado en reposo es el más concreto. Los campos que almacenan RUT, nombre, historia clínica, diagnósticos o datos de contacto asociados a un tratamiento médico deben ir cifrados en la base de datos. En un sistema nuevo, esto es estándar desde el primer commit. En uno existente, el trabajo real es identificar qué campos son sensibles y priorizarlos, porque casi nunca están todos donde deberían. La minimización complementa esto: no recolectes ni muestres más información de la que la finalidad exige. Si tu pantalla de agenda muestra el diagnóstico completo cuando solo necesitas el nombre y la hora, tienes exposición innecesaria.
La retención es donde más sistemas fallan. La ley no te deja guardar información clínica indefinidamente: cada finalidad tiene un plazo razonable, y cuando vence, el sistema tiene que poder eliminar o anonimizar ese dato de forma sistemática, no con alguien borrando registros a mano un viernes. Y los logs de actividad que tu aplicación genera para depurar no pueden contener datos personales identificables. Un log que registra «el paciente Juan Pérez, RUT 12.345.678-9, consultó por...» es en sí mismo una filtración esperando ocurrir.
El caso de la healthtech que lanza un EMR
Una startup desarrolla un sistema de ficha clínica electrónica para consultas médicas. Antes de conectar el primer paciente real, el equipo se topa con la lista completa: DPIA previa obligatoria, cifrado en reposo de los campos sensibles, retención automatizada por tipo de dato, y un acuerdo de tratamiento (DPA) con el proveedor cloud donde corre la base de datos. Lo que suele quedar fuera del radar es el equipo de los propios desarrolladores y del soporte: esos notebooks acceden a datos de producción, y entran en el mismo perímetro de cumplimiento que el servidor.
Quick win: Si desarrollas o administras software de salud, corre un chequeo de cifrado en reposo esta semana. Lista los campos que guardan información clínica y verifica cuáles están efectivamente cifrados en la base de datos. Los que aparezcan en texto plano son tu prioridad uno.
¿Qué pasa si se pierde un dispositivo con acceso a fichas clínicas?
Si un equipo con acceso a datos de salud se pierde y esos datos quedan expuestos, la Ley 21.719 lo trata como una brecha de datos sensibles: con deber de notificar a la Agencia y exposición a sanción. No importa que el servidor estuviera cifrado; importa el dato accesible desde ese equipo. Ese es el punto ciego.
Piensa dónde vive realmente el dato de salud durante un día de trabajo. El médico que revisa exámenes desde su casa el domingo. La enfermera de urgencias que consulta la ficha en una tablet compartida. La recepcionista que agenda pacientes con diagnósticos a la vista. El dato está cifrado en la base de datos, sí, pero en cada uno de esos equipos hay una sesión abierta, una caché, un archivo descargado, una pantalla que muestra información sensible. El servidor es la parte fácil de proteger. Los cientos de dispositivos que acceden a él son la parte difícil, y son justo los que se pierden.
Escenario: la tablet de urgencias
Una enfermera deja la tablet con una ficha clínica abierta sobre el mesón de la sala mientras atiende una emergencia. En el movimiento, el equipo desaparece. Para el equipo de TI, esto no es «se perdió una tablet». Es un dispositivo con datos clínicos accesibles fuera del control de la organización, y bajo la ley eso puede constituir una brecha de dato sensible que hay que evaluar y, si corresponde, notificar la brecha. La pregunta que define el resultado es simple: ¿pueden bloquear y borrar ese equipo de forma remota, y demostrar cuándo lo hicieron?
Aquí el instinto de la mayoría de los jefes de TI en salud es correcto: ante un equipo perdido con datos de pacientes, importa más borrar el dato que recuperar el aparato. El hardware se reemplaza. La filtración de una historia clínica, no. Los controles técnicos mínimos que la ley espera sobre estos dispositivos incluyen precisamente cifrado de disco, capacidad de bloqueo remoto y borrado a distancia.
Quick win: Haz un inventario esta semana de todos los equipos que acceden a datos de salud (notebooks, tablets, equipos de recepción) y responde por cada uno: ¿tiene cifrado de disco activo? ¿puedes bloquearlo y borrarlo de forma remota hoy? Cualquier equipo donde la respuesta sea «no» es una brecha esperando ocurrir.
Cómo demostrar el cumplimiento ante la Agencia
Cumplir no es suficiente: la Ley 21.719 te exige poder demostrar que cumples. La diferencia es enorme en la práctica. Tener los dispositivos cifrados no vale ante un auditor si no puedes mostrar el registro que lo prueba. La ley se apoya en el principio de responsabilidad proactiva, y eso significa que la carga de la evidencia es tuya.
Cuando la Agencia o un auditor te pide demostrar tus medidas sobre datos de salud, no acepta una declaración. Espera evidencia verificable: el reporte de estado de cifrado de tus equipos, el inventario de dispositivos que acceden a datos clínicos, el registro de qué acciones se tomaron sobre un equipo perdido y cuándo, el historial de accesos. Un DPA firmado hace tres años que nadie volvió a revisar no es evidencia de cumplimiento; es evidencia de que hubo una intención en algún momento.
Aquí es donde muchas organizaciones de salud descubren su verdadero gap. No es que no tengan controles. Es que no pueden probarlos. El cifrado existe pero nadie exporta el reporte. El borrado remoto se hizo pero no quedó registrado con fecha y hora. La evidencia operativa (el rastro que convierte «creo que estábamos protegidos» en «aquí está el log que lo demuestra») es lo que la ley premia y lo que la mayoría no tiene ordenado. Cómo construir ese rastro para TI lo desarrollamos en la guía de evidencia operativa. Si partes de cero, la guía de implementación del gobierno ofrece un marco general de referencia.
Quick win: Simula la pregunta del auditor. Elige una medida que declaras tener sobre datos de salud (cifrado, borrado remoto, control de acceso) e intenta exportar hoy la evidencia que la prueba. Si no puedes generar el registro en minutos, la medida existe pero tu capacidad de demostrarla no.
Cómo el control de endpoints cierra el gap en salud
Todo lo anterior converge en un punto: los datos de salud son tan seguros como los dispositivos desde donde se acceden. Ahí es donde una plataforma de gestión y seguridad de endpoints deja de ser un lujo de TI y pasa a ser parte de tu cumplimiento.
En la práctica, el flujo se ve así. Cada notebook, tablet o equipo que accede a datos clínicos queda inventariado, con su estado de cifrado de disco visible en un solo panel. Si un equipo se pierde, TI puede bloquearlo al instante y, si tiene información de salud accesible, ejecutar un borrado remoto sin esperar a que el dispositivo vuelva a la oficina. Y cada una de esas acciones queda registrada con fecha y hora, lista para exportar como evidencia. Prey es una de las plataformas que operan este modelo en flotas mixtas (Windows, macOS, Linux, Android, iOS, Chromebook), que es justo lo que una clínica o una healthtech suele tener.
El valor no está en una función aislada, sino en cerrar el ciclo que la ley exige: ver el estado de cada endpoint, actuar sobre el que representa un riesgo, y dejar la evidencia de que lo hiciste. Volviendo a la tablet de urgencias: con control de endpoint, el incidente pasa de «un dispositivo con fichas de pacientes anda suelto» a «el equipo se bloqueó y borró a las 14:37, aquí está el registro». Esa es la diferencia entre una brecha que notificar con exposición a sanción y un incidente contenido que puedes documentar.
Conclusión
La Ley 21.719 pone el estándar más alto sobre los datos de salud, y con razón: es el dato que no se puede reparar cuando se filtra. Las obligaciones son claras y verificables: consentimiento explícito, DPIA antes de tratar, cifrado en reposo, retención acotada, y la capacidad de demostrar cada control con evidencia. Ese es el trabajo que tu software y tus procesos tienen que absorber antes de diciembre de 2026.
Pero el error más caro es creer que el trabajo termina en la base de datos. El dato de salud no vive solo en el servidor cifrado. Vive en el notebook del médico, en la tablet de urgencias, en el equipo de recepción. Puedes hacer todo bien en la capa de datos y aun así enfrentar una brecha de dato sensible porque un dispositivo con una ficha abierta desapareció y nadie pudo actuar sobre él. La ley no distingue entre el dato en reposo y el dato en el endpoint; tú tampoco deberías.
El próximo paso concreto: haz el inventario de los equipos que tocan datos de salud en tu organización y responde, por cada uno, si puedes verlo, bloquearlo y borrarlo de forma remota hoy. Esa lista es tu mapa de cumplimiento real, y probablemente el gap más grande que no habías mirado.
Preguntas frecuentes
¿Los datos de salud son datos sensibles bajo la Ley 21.719?
Sí. La Ley 21.719 clasifica los datos de salud como datos sensibles, una categoría de máxima protección junto a los datos biométricos, genéticos, de vida sexual y origen. Tratarlos exige, por regla general, consentimiento explícito del titular y medidas de seguridad reforzadas respecto de un dato personal común.
¿Necesito una DPIA para tratar datos de salud?
En la mayoría de los casos, sí. La ley vuelve obligatoria la evaluación de impacto (DPIA) cuando se tratan datos sensibles a gran escala, supuesto en el que caen clínicas, laboratorios y sistemas de gestión clínica. La DPIA debe realizarse antes de implementar el tratamiento, no como un trámite posterior.
¿Qué requisitos técnicos exige la ley a un software que procesa datos clínicos?
La ley espera medidas proporcionales al riesgo: cifrado en reposo de los campos sensibles, minimización de los datos recolectados y mostrados, una política de retención que elimine o anonimice cuando vence el plazo, y registros de actividad que no contengan datos personales identificables. Estas medidas deben poder demostrarse con evidencia, no solo declararse.
¿Necesito consentimiento explícito para tratar datos de salud?
Por regla general, sí. Para datos de salud el estándar es consentimiento explícito, informado y específico, salvo excepciones legales acotadas como una urgencia médica que impide obtenerlo. Una casilla premarcada o un consentimiento genérico enterrado en los términos y condiciones no cumple ese estándar.
¿Qué pasa si se pierde un dispositivo con acceso a fichas clínicas?
Si el equipo tenía datos de salud accesibles y quedan expuestos, puede constituir una brecha de datos sensibles, con deber de evaluarla y, si corresponde, notificarla a la Agencia. Que la base de datos del servidor estuviera cifrada no elimina la exposición del dato accesible desde ese dispositivo. La capacidad de bloquear y borrar el equipo de forma remota, y de registrar cuándo se hizo, es lo que contiene el incidente.
¿Desde cuándo aplica la Ley 21.719 y qué multa arriesga una clínica?
La ley entra en plena vigencia el 1 de diciembre de 2026. Las infracciones graves pueden alcanzar hasta 20.000 UTM, y en casos de reincidencia la sanción puede llegar hasta el 4% de los ingresos anuales por ventas y servicios en Chile. Poder demostrar controles operativos sobre los datos y los dispositivos es lo que reduce esa exposición.
Controla los endpoints que tocan datos clínicos.
Ve en un solo panel qué equipos acceden a datos de salud, su estado de cifrado, y bloquéalos o bórralos de forma remota si se pierden. Agenda una demo o cotiza para tu organización.
