Los datos de tus pacientes están bajo asedio por IA. La mayoría de las defensas fueron creadas para otra época.

La filtración no comenzó con una sofisticada intrusión del día cero. Comenzó con el acceso a un sistema de registros electrónicos de salud al que una persona no autorizada tuvo acceso durante nueve meses antes de que alguien se diera cuenta.

Esa es la cronología descrita en la filtración de datos de OSF reportada por Shaw Local: un atacante obtuvo acceso a la plataforma Cerner EHR que da servicio a varias instalaciones de OSF en enero de 2025, el hospital fue notificado en septiembre y los pacientes no fueron informados hasta finales de diciembre, después de que las autoridades solicitaran un retraso. Los datos comprometidos incluían nombres, números de Seguro Social, diagnósticos, medicamentos y resultados de pruebas.

Esto no es una excepción. Es la nueva normalidad. Y a medida que la inteligencia artificial reduce el coste, el tiempo y la habilidad necesarios para los ciberataques, los hospitales se enfrentan a un entorno de amenazas para el que sus arquitecturas de seguridad heredadas nunca fueron diseñadas.

5 conclusiones clave

  1. La IA ha hecho que los ciberataques a hospitales sean más baratos, rápidos y difíciles de detectar. Como informa Shaw Local, la IA ha reducido drásticamente la barrera de entrada para los atacantes que apuntan a hospitales. Los expertos en ciberseguridad señalan que los actores de amenazas ahora pueden crear programas de ataque funcionales en horas usando herramientas de IA, automatizando el reconocimiento, analizando datos robados y creando correos de phishing que eluden los filtros tradicionales, todo a un coste mínimo.
  2. Los hospitales no pueden permitirse interrupciones — y los atacantes lo saben. A diferencia de la mayoría de las empresas que pueden soportar días de inactividad, los hospitales operan en una línea de tiempo de vida o muerte. Cuando los sistemas fallan, se cancelan cirugías, los portales de pacientes desaparecen y los resultados de diagnósticos se pierden. Esta urgencia operativa es precisamente la razón por la que los operadores de ransomware apuntan al sector salud: la presión por restablecer los servicios rápidamente hace que los hospitales sean más propensos a pagar.
  3. La filtración de OSF expone la magnitud de la vulnerabilidad EHR en salud. La filtración de datos de OSF reveló que un tercero no autorizado accedió a los registros electrónicos de salud a través del proveedor de EHR de OSF, Cerner, desde enero de 2025, y el hospital no fue notificado hasta septiembre. Los datos comprometidos incluían nombres, números de Seguro Social, diagnósticos, medicamentos y resultados de pruebas en varias instalaciones.
  4. Las herramientas de IA que usa el personal hospitalario están generando nuevos riesgos de exposición de datos. No se trata solo de atacantes externos. Los expertos en ciberseguridad advierten que las herramientas de IA adoptadas por empleados hospitalarios para flujos de trabajo clínicos y administrativos —como ChatGPT y otras plataformas de IA generativa— crean canales de exposición de datos no intencionados. El personal que introduce datos de pacientes, notas clínicas o detalles operativos en plataformas públicas de IA corre el riesgo de que la información de salud protegida quede accesible fuera de la organización.
  5. El 63% de las organizaciones no puede imponer limitaciones de propósito a los agentes de IA que acceden a datos de pacientes. Según el Informe de Pronóstico Kiteworks 2026, el 63% de las organizaciones no puede imponer limitaciones de propósito a los agentes de IA, el 60% carece de un interruptor de emergencia para IA que se comporte de forma indebida y el 78% no puede validar los datos que ingresan a los flujos de entrenamiento de IA. En el sector salud, donde la ley HIPAA exige el estándar de mínimo necesario para el acceso a la información de salud protegida, estas brechas representan tanto un fallo de seguridad como una violación de cumplimiento.

La IA convirtió el cibercrimen en una operación de bajo coste y alto rendimiento

Los expertos en ciberseguridad entrevistados por Shaw Local son contundentes: la IA ha cambiado fundamentalmente la economía de atacar hospitales. Brian Pichman, CISO en Illinois Valley Community College, describió el impacto de la IA en las capacidades de ataque como transformador, permitiendo a los actores de amenazas construir herramientas funcionales en horas y a un coste insignificante.

Esto coincide con lo que el Informe Global de Amenazas CrowdStrike 2026 documentó a mayor escala: un aumento interanual del 89% en operaciones de adversarios habilitadas por IA, con el tiempo promedio de avance de eCrime —del acceso inicial al movimiento lateral— reducido a solo 29 minutos. En el sector salud, donde los sistemas interconectados significan que una plataforma EHR comprometida puede exponer millones de registros de pacientes, esa ventaja de velocidad es devastadora.

La IA también ayuda a los atacantes a moverse de forma más inteligente: analizando datos robados, identificando objetivos de alto valor y diseñando estrategias adaptadas a la arquitectura hospitalaria. Una revisión revisada por pares publicada en Risk Management and Healthcare Policy (Di Palma et al., 2025) catalogó estos riesgos en tres categorías: acceso no autorizado a datos clínicos, manipulación de dispositivos médicos controlados por IA y vulnerabilidades a nivel de sistema donde un solo componente comprometido afecta a toda la red hospitalaria.

Por qué los hospitales son el objetivo perfecto — y por qué la situación empeora

La vulnerabilidad del sector salud es estructural, no incidental. Los hospitales ejecutan docenas de aplicaciones interrelacionadas las 24 horas. Los sistemas heredados que ya no reciben actualizaciones de seguridad comparten red con equipos de diagnóstico modernos. Y los datos que almacenan los hospitales —información de salud protegida como diagnósticos, historiales de tratamiento, números de Seguro Social y detalles de seguros— son de los más valiosos en la dark web. Una pequeña empresa puede soportar días de inactividad, pero un hospital no. Los atacantes explotan esta urgencia, sabiendo que las consecuencias de vida o muerte hacen que las organizaciones sean más propensas a pagar.

Las cifras lo confirman. Los ciberataques a hospitales más que se duplicaron de 304 en 2022 a 624 en 2023, según la revisión de Di Palma. La filtración de OSF no es única: el Hospital Morris reveló un incidente similar en 2023, con datos comprometidos como nombres, direcciones, números de Seguro Social, registros médicos y códigos de diagnóstico.

La amenaza interna: las herramientas de IA que usa el personal hospitalario están creando nuevos canales de exposición

Los atacantes externos no son la única fuente de exposición de datos de pacientes. Un riesgo crítico y poco valorado: las herramientas de IA adoptadas dentro de los hospitales para fines clínicos y administrativos están generando canales de fuga de datos que la mayoría de las arquitecturas de seguridad no contemplan.

El personal hospitalario que introduce información de pacientes, notas clínicas o datos operativos en plataformas públicas de IA generativa está haciendo que la información de salud protegida quede accesible fuera del control de la organización. Una vez que los datos ingresan a una plataforma pública, ya no están sujetos a los controles de acceso de HIPAA, los requisitos de registro de auditoría ni las obligaciones de notificación de filtraciones, pero la responsabilidad de la organización no desaparece con ellos.

El Informe de Pronóstico Kiteworks 2026 documenta la magnitud de esta brecha de gobernanza: el 78% de las organizaciones no puede validar los datos que ingresan a los flujos de entrenamiento de IA. En el contexto sanitario, esto significa que los datos de pacientes pueden estar fluyendo hacia sistemas de IA sin clasificación, controles de acceso ni trazabilidad de auditoría, una violación directa del estándar de mínimo necesario de HIPAA y una responsabilidad de cumplimiento que se agrava con cada interacción no monitoreada.

La HIPAA fue diseñada para un panorama de amenazas previo a la IA. Las brechas son evidentes.

La Regla de Seguridad de HIPAA exige que las entidades cubiertas implementen protecciones para la información de salud electrónica protegida. Pero la regulación fue escrita para una época en la que las amenazas principales eran el acceso humano no autorizado y la pérdida de dispositivos, no el reconocimiento automatizado por IA capaz de identificar y extraer datos en minutos, ni las herramientas de IA generativa que los empleados hospitalarios usan para procesar información clínica en plataformas públicas.

La cronología de OSF ilustra el problema: nueve meses de acceso no autorizado antes de la notificación, tres meses más antes de informar a los pacientes. Según la regla de notificación de filtraciones de HIPAA, las entidades cubiertas deben notificar a las personas afectadas dentro de los 60 días posteriores al descubrimiento de una filtración. Pero cuando los atacantes habilitados por IA mantienen acceso persistente y evaden la detección durante meses, el reloj de 60 días puede no empezar a correr hasta mucho después de que el daño esté hecho. OCR cita cada vez más violaciones del estándar de mínimo necesario en acciones de cumplimiento, con sanciones de hasta 1,5 millones de dólares por categoría de violación al año.

La brecha de gobernanza: la mayoría de las organizaciones de salud no puede gobernar lo que no puede ver

El Informe de Pronóstico Kiteworks 2026 cuantifica lo que la filtración de OSF demuestra en la práctica. El 63% de las organizaciones no puede imponer limitaciones de propósito a los agentes de IA que acceden a datos confidenciales. El 60% no tiene un interruptor de emergencia para agentes de IA que se comportan de forma indebida. El 33% carece de registros de auditoría con valor probatorio y el 61% tiene registros fragmentados que resultan inútiles en una investigación o auditoría regulatoria.

Para las organizaciones sanitarias sujetas a HIPAA, estos no son simples indicadores de gobernanza, sino fallos de cumplimiento con consecuencias de aplicación concretas. Si tu sistema de soporte clínico basado en IA tiene el mismo acceso EHR que un atacante obtuvo a través de Cerner, y no puedes demostrar acceso limitado por propósito y registros de auditoría inmutables para las interacciones de ese sistema de IA, tienes dos vectores de filtración y un solo conjunto de controles inadecuados que no cubren ninguno.

Las organizaciones de salud también reportan la mayor dificultad relacionada con datos en correo electrónico de cualquier sector, según el Informe de Soberanía de Datos Kiteworks 2026, probablemente impulsada por la sensibilidad y el volumen de datos de pacientes que circulan en comunicaciones clínicas. Cuando los sistemas de correo electrónico, plataformas EHR, herramientas de IA y dispositivos médicos gestionan información de salud protegida a través de arquitecturas de seguridad separadas y registros independientes —o sin registros—, la superficie de ataque no solo es grande. Es ingobernable.

Los prompts no son barreras. La arquitectura sí lo es.

Aquí es donde la Red de Contenido Privado de Kiteworks resuelve la brecha estructural entre lo que exige el panorama de amenazas actual en salud y lo que la mayoría de las arquitecturas de seguridad hospitalaria ofrecen.

Frente a atacantes potenciados por IA capaces de pasar del acceso inicial a la exfiltración de datos en minutos, y frente a herramientas internas de IA que crean canales de exposición de datos sin control, la defensa efectiva requiere una aplicación a nivel de infraestructura que opere de forma continua, automática e independiente del comportamiento de cualquier usuario o agente de IA.

Controles de acceso granulares y limitados por propósito aplican el estándar de mínimo necesario de HIPAA a nivel de infraestructura. Cada agente de IA, cada aplicación clínica y cada usuario que accede a información de salud protegida recibe permisos limitados por propósito y tiempo en cada interacción, no un acceso amplio basado en roles que permite a 500 empleados ver datos que solo 50 necesitan.

La detección de anomalías en tiempo real con suspensión automatizada identifica cuentas comprometidas, patrones inusuales de acceso a datos o agentes de IA operando fuera de los parámetros autorizados y los detiene antes de que ocurra un daño. Frente a filtraciones no detectadas durante nueve meses como la de OSF, el monitoreo conductual continuo marca la diferencia entre un incidente contenido y una exposición catastrófica de datos.

La aplicación de DLP en todos los canales de comunicación evita que la información de salud protegida salga del entorno gobernado a través de correo electrónico, uso compartido de archivos, SFTP, transferencia gestionada de archivos, formularios web, APIs o integraciones con herramientas de IA. Cuando el personal hospitalario intenta introducir datos de pacientes en plataformas públicas de IA, la aplicación de DLP detiene los datos en el límite, antes de que se conviertan en una exposición sin control.

El cifrado validado FIPS 140-3 con claves controladas por el cliente protege la información de salud protegida en reposo y en tránsito, cumpliendo los requisitos de cifrado de HIPAA y los estándares técnicos que OCR evalúa en acciones de cumplimiento.

Y como base de todo: registros de auditoría inmutables y centralizados que documentan cada acceso, cada interacción y cada acción de aplicación en todos los canales. Frente a los requisitos de auditoría de HIPAA y la inevitabilidad de investigaciones por filtraciones, estos registros marcan la diferencia entre cumplimiento documentado y una sanción regulatoria indefendible.

Lo que todo CISO del sector salud debe hacer ahora

Realiza un inventario de activos de IA en todos los flujos de trabajo clínicos y administrativos. El informe de Shaw Local confirma que las herramientas de IA utilizadas por empleados hospitalarios están generando canales de exposición de datos no monitoreados. No puedes gobernar lo que no sabes que existe. Identifica cada herramienta, agente e integración de IA que interactúe con datos de pacientes y somete cada uno a los mismos controles de acceso, aplicación de DLP y registros de auditoría que rigen a los usuarios humanos.

Aplica el acceso mínimo necesario a nivel de infraestructura, no solo en la política. La filtración de OSF demuestra lo que ocurre cuando los controles de acceso son insuficientes: nueve meses de acceso no autorizado a datos EHR. Kiteworks aplica acceso limitado por propósito y tiempo para cada usuario, aplicación y agente de IA que interactúe con información de salud protegida, cerrando la brecha entre los requisitos de HIPAA y la realidad operativa.

Extiende DLP y registros de auditoría a cada flujo, prompt e integración de IA. Cuando el 78% de las organizaciones no puede validar los datos que ingresan a los flujos de entrenamiento de IA, cada interacción no monitoreada es un potencial vector de filtración. La aplicación de DLP evita que la información de salud protegida salga de los canales gobernados, mientras que los registros de auditoría inmutables documentan cada interacción de datos para el cumplimiento de HIPAA y la preparación ante investigaciones por filtraciones.

Automatiza la detección y respuesta a la velocidad de los atacantes. El tiempo de avance de 29 minutos de CrowdStrike y los nueve meses de acceso no detectado en OSF representan dos caras del mismo problema: arquitecturas defensivas que dependen de la intervención humana y auditorías periódicas no pueden seguir el ritmo. Kiteworks ofrece detección de anomalías en tiempo real con suspensión automatizada de agentes: gobernanza a velocidad de máquina para un entorno de amenazas a velocidad de máquina.

Los datos de pacientes no esperan a que tu arquitectura de seguridad se ponga al día

El informe de Shaw Local documenta un panorama de amenazas que todo CISO de salud ya sospecha, aunque quizás no haya cuantificado: la IA ha hecho que los ciberataques a hospitales sean más baratos, rápidos y difíciles de detectar. Las arquitecturas de seguridad heredadas, diseñadas para amenazas a velocidad humana, no pueden proteger los datos de pacientes frente al reconocimiento automatizado, el phishing asistido por IA y la explotación de docenas de aplicaciones interconectadas que mantienen un hospital en funcionamiento.

Las organizaciones que protegerán los datos de pacientes en este entorno son aquellas que gobiernan cada punto de acceso —usuarios humanos, agentes de IA, aplicaciones clínicas e integraciones de terceros— con permisos limitados por propósito, DLP a nivel de infraestructura y registros de auditoría inmutables que cumplen los requisitos de HIPAA y resisten investigaciones por filtraciones. La Red de Contenido Privado de Kiteworks fue creada precisamente para esto: proteger los datos más sensibles en los entornos más complejos, con la gobernanza, el cifrado y la evidencia que exigen la regulación y el panorama de amenazas del sector salud.

Para descubrir cómo Kiteworks puede ayudarte, agenda una demo personalizada hoy mismo.

Preguntas frecuentes

Bajo HIPAA, un proveedor de EHR como Cerner que crea, recibe, mantiene o transmite información de salud electrónica protegida en nombre de una entidad cubierta es un asociado comercial y debe firmar un acuerdo de asociado comercial que especifique obligaciones de seguridad, usos permitidos y responsabilidades de notificación de filtraciones. Cuando una filtración se origina en el proveedor —como parece ser el caso de OSF—, el acuerdo determina si el proveedor debe notificar rápidamente a la entidad cubierta, preservar evidencia forense y cooperar con la investigación de la filtración. Sin embargo, la regla de notificación de filtraciones de HIPAA responsabiliza a la entidad cubierta de notificar a las personas afectadas en un plazo de 60 días desde el descubrimiento, independientemente de si el proveedor causó la filtración. Esto genera una responsabilidad asimétrica: el hospital asume la obligación de notificar a los pacientes y la exposición a sanciones de OCR incluso por una filtración que no causó y que puede no haber podido detectar. Las organizaciones de salud deben asegurarse de que los acuerdos con proveedores de EHR aborden explícitamente los plazos de respuesta ante incidentes, la preservación y el acceso a registros de auditoría, la metodología para determinar el alcance de la filtración y el derecho de la entidad cubierta a una revisión forense independiente, disposiciones que los contratos estándar de proveedores suelen omitir.

El estándar de mínimo necesario de HIPAA exige que el acceso a la información de salud protegida se limite a lo mínimo necesario para cumplir el propósito previsto. Aplicado a agentes de IA en flujos clínicos, esto significa que cada agente solo debería poder acceder a las categorías específicas de información requeridas para su función definida: una herramienta de soporte clínico para interacciones de medicamentos no necesita acceso a registros de facturación o diagnósticos históricos fuera de su alcance. En la práctica, la mayoría de las implementaciones de IA en salud no cumplen este estándar porque utilizan credenciales de cuentas de servicio amplias o permisos basados en roles diseñados para usuarios humanos, otorgando a los agentes de IA acceso mucho más allá de lo que requiere cada tarea. El hallazgo del Informe de Pronóstico Kiteworks 2026 de que el 63% de las organizaciones no puede imponer limitaciones de propósito a los agentes de IA refleja esta brecha. El cumplimiento exige controles de acceso basados en atributos que evalúen el propósito autorizado del agente de IA, la clasificación de los datos solicitados y el contexto específico de cada tarea, aplicando el mínimo necesario a nivel de datos en vez de depender de asignaciones de roles a nivel de sistema que no cambian entre tareas.

La regla de notificación de filtraciones de HIPAA exige que las entidades cubiertas notifiquen a las personas afectadas sin demora injustificada y dentro de los 60 días posteriores al descubrimiento de una filtración. «Descubrimiento» significa la fecha en que la entidad cubierta supo o, ejerciendo diligencia razonable, debería haber sabido de la filtración. La cronología de OSF —acceso del atacante desde enero, notificación al hospital en septiembre, notificación a pacientes en diciembre— ilustra el doble problema de cumplimiento que esto genera. Primero, si los nueve meses de permanencia reflejan un fallo de detección y no una ausencia real de señales detectables, OCR puede considerar que la diligencia razonable habría identificado la filtración antes, activando el plazo de 60 días antes y haciendo que la notificación de diciembre sea una violación. Segundo, la disposición de retraso por solicitud de las autoridades que permite HIPAA es limitada en el tiempo y requiere una solicitud formal; no suspende indefinidamente la obligación subyacente de la organización. Las organizaciones de salud que enfrentan accesos persistentes habilitados por IA deben mantener monitoreo conductual continuo con alertas en tiempo real: el registro de auditoría que documenta cuándo aparecieron los primeros patrones anómalos es también la evidencia que determina cuándo comenzó legalmente el plazo de 60 días.

Prevenir la fuga de información de salud protegida a través de plataformas de IA generativa requiere la aplicación de DLP en cuatro puntos que la mayoría de las arquitecturas de seguridad hospitalaria no cubren actualmente. Primero, inspección de contenido saliente en todos los canales por los que el personal interactúa con plataformas externas de IA: herramientas de IA en navegador accedidas desde redes corporativas, integraciones API entre aplicaciones clínicas y servicios de IA, y flujos de correo electrónico que se enrutan a pipelines de procesamiento de IA. Segundo, aplicación de clasificación de datos que identifique información de salud protegida en contexto —no solo patrones evidentes como números de Seguro Social, sino reconociendo que notas clínicas, códigos de diagnóstico y descripciones de tratamientos constituyen información protegida incluso sin nombres adjuntos. Tercero, inspección a nivel de prompt que detecte cuándo se están enviando datos estructurados de pacientes como entrada de IA, no solo cuando se transfieren archivos. Cuarto, controles en la puerta de enlace API para integraciones de servicios de IA que impongan limitaciones de propósito, restringiendo qué clasificaciones de datos puede enviar o recibir cada integración de IA. Sin estas cuatro capas, las políticas de DLP que cubren canales tradicionales de transferencia y MFT tendrán brechas visibles por las que la información de salud protegida fluye hacia procesamiento externo de IA sin control, sin generar alertas ni crear registros de auditoría.

FIPS 140-3 es el estándar federal estadounidense actual para la validación de módulos criptográficos, reemplazando a FIPS 140-2. Especifica requisitos para el diseño, implementación y pruebas de módulos criptográficos, no solo el algoritmo utilizado, sino todo el módulo de hardware o software que implementa el cifrado. Para las organizaciones de salud, la validación FIPS 140-3 es importante por tres razones. Primero, los requisitos técnicos de HIPAA hacen referencia a la guía NIST sobre cifrado, y la aplicación de OCR considera cada vez más el cifrado validado FIPS como el estándar adecuado para información de salud protegida en reposo y en tránsito; implementaciones que usan algoritmos estándar pero carecen de validación a nivel de módulo pueden no satisfacer las expectativas técnicas de OCR en una revisión de cumplimiento. Segundo, la validación FIPS 140-3 exige pruebas de terceros sobre la implementación criptográfica, aportando un peso probatorio que el cifrado auto-declarado no tiene. Tercero, la gestión de claves controlada por el cliente —donde la organización de salud, no el proveedor, controla las claves de cifrado— garantiza que la información de salud protegida permanezca inaccesible para el proveedor en la nube y sobreviva incidentes de seguridad del proveedor sin exponer datos de pacientes. Combinado con registros de auditoría inmutables, el cifrado validado FIPS 140-3 con claves gestionadas por el cliente constituye la base técnica de protección que OCR busca al evaluar si una entidad cubierta ejerció la diligencia razonable para proteger la información de salud protegida.

Recursos adicionales

  • Artículo del Blog Arquitectura Zero Trust: Nunca confíes, siempre verifica
  • Video Microsoft GCC High: Desventajas que impulsan a los contratistas de defensa hacia ventajas más inteligentes
  • Artículo del Blog Cómo proteger datos clasificados una vez que DSPM los identifica
  • Artículo del Blog Generar confianza en la IA generativa con un enfoque Zero Trust
  • Video La guía definitiva para el almacenamiento seguro de datos sensibles para líderes de TI

Comienza ahora.

Es fácil comenzar a asegurar el cumplimiento normativo y gestionar eficazmente los riesgos con Kiteworks. Únete a las miles de organizaciones que confían en cómo intercambian datos confidenciales entre personas, máquinas y sistemas. Empieza hoy mismo.

Table of Content
Compartir
Twittear
Compartir
Explore Kiteworks