Gobernanza de IA en el sector sanitario: Cumplimiento y seguridad

Las organizaciones de salud adoptaron la IA más rápido de lo que desarrollaron la gobernanza para gestionarla. El ochenta y ocho por ciento de los sistemas de salud ya usan IA internamente, mientras que solo el 18 % tienen una estructura madura de gobernanza de IA y una estrategia de IA completamente formada.

La Healthcare Financial Management Association informó ambas cifras en Health System Readiness for AI, a partir de una encuesta de mayo de 2025 a más de 230 ejecutivos de sistemas de salud.

La IA rara vez llega a través de adquisiciones, por lo que supera el inventario. Se añade una licencia de Microsoft 365 Copilot a un acuerdo existente, una función de documentación ambiental se integra en el historial clínico electrónico (EHR) o un clínico usa un dispositivo personal.

El Shadow AI Report de diciembre de 2025 de Wolters Kluwer Shadow AI Report encuestó a 518 proveedores y administradores hospitalarios y encontró que el 57 % había encontrado o usado una herramienta de IA no autorizada.

No saber a qué puede acceder una herramienta de IA se convierte en un problema de responsabilidad en el momento en que un miembro de la junta o auditor pregunta qué herramientas manejan información de salud protegida (PHI), quién es el propietario de cada una y qué demuestra que los controles funcionan.

¿Qué es la gobernanza de IA en el cuidado de la salud?

Gobernanza de IA en el sector salud es la disciplina de saber dónde los sistemas de IA acceden a PHI, quién es responsable de cada caso de uso y si se puede demostrar que los controles sobre ese acceso funcionan. Las organizaciones subestiman el tercer elemento porque consideran una política escrita como prueba, cuando solo describe la intención.

Un comité de la junta o un auditor externo está evaluando si la organización puede decir, en el momento, a qué accede una herramienta de IA específica y quién la posee. La mayoría de las organizaciones de salud no pueden, porque Copilot pilots, la IA integrada del proveedor y las herramientas conversacionales acceden a sistemas adyacentes a PHI antes de que seguridad termine de catalogarlos.

Las consecuencias se reflejan en los datos de brechas. El Netwrix 2026 Data and Identity Security Report registró una tasa de brechas del 43 % en los últimos 12 meses en organizaciones donde la IA aumentó significativamente la huella de identidad, frente al 11 % donde la IA no la cambió de forma significativa.

La encuesta detrás de ese informe también encontró que solo el 21 % de las organizaciones tienen visibilidad completa, monitoreo y controles sobre qué datos sensibles utilizan las herramientas, modelos o copilotos de IA.

Por qué el sector sanitario conlleva un nivel diferente de riesgo de IA

El caso genérico para la gobernanza de IA se basa en el riesgo reputacional y operativo. En el sector sanitario, la exposición está regulada, los datos son excepcionalmente valiosos y la responsabilidad recae en el proveedor, no en quien construyó el modelo. La ciberseguridad sanitaria ya presenta esa asimetría.

Un historial médico robado nunca caduca

La mayoría de los datos regulados tienen una vida útil, que limita el valor de una violación. Una tarjeta de pago robada se cancela y reemite en pocos días. Un historial médico contiene diagnósticos, detalles de seguro, datos demográficos y un número de Seguro Social, ninguno de los cuales puede ser reemitido, por lo que sigue siendo explotable durante años después de la violación que lo produjo.

Por lo tanto, el sector sanitario no puede confiar en la contención que otros sectores obtienen gratis. Una herramienta de IA que accede a PHI crea una exposición sin fecha de caducidad, lo que aumenta el costo de un error en el diseño de acceso y no solo la probabilidad de que ocurra.

El proveedor asume la responsabilidad incluso cuando un vendedor causa la violación

Las organizaciones sanitarias sujetas a HIPAA, que la norma denomina entidades cubiertas, siguen siendo legalmente responsables de la PHI sin importar qué modelo la procese. Eso es lo que diferencia la adquisición de IA aquí de la adquisición de IA en un sector no regulado, donde un contrato con el proveedor puede trasladar el riesgo. Las reglas de cumplimiento de HIPAA que rigen todos los demás sistemas se aplican a la IA sin cambios.

El Departamento de Salud y Servicios Humanos (HHS) Oficina de Derechos Civiles (OCR) considera a un chatbot de IA de terceros que maneja PHI en un portal de pacientes como un business associate, el mismo estatus que aplica a los proveedores en la nube. Los business associates tienen obligaciones directas propias, y eso no reduce las del proveedor. OCR ha llegado a acuerdos con proveedores por fallos de terceros antes, incluyendo el North Memorial settlement relacionado con un Acuerdo de Business Associate (BAA) faltante.

Un solo proceso de revisión no puede cubrir ambos tipos de IA que utiliza un hospital

La mayoría de los sectores implementan una clase de IA y la gestionan de una manera. Un hospital utiliza dos al mismo tiempo, y fallan de forma suficientemente distinta como para que un solo proceso de revisión no detecte una.

Una herramienta diagnóstica falla al llegar a un paciente con una recomendación errónea o sesgada, lo que es una cuestión de seguridad del paciente para el liderazgo clínico y, a menudo, para la FDA. Un asistente de productividad falla al mostrar PHI a alguien que nunca debería haberla visto, lo que es una cuestión de control de acceso para seguridad. Pasar ambos por el mismo comité significa que las herramientas administrativas reciben un escrutinio de estilo clínico que no necesitan, mientras nadie pregunta a qué pueden acceder realmente.

Una violación en el sector salud cuesta más que en cualquier otro lugar

El sector sanitario ha tenido el coste promedio más alto por violación de datos durante más de una década, alcanzando los 6,64 millones de dólares en 2026 (frente a 7,42 millones en 2025) según IBM's Cost of a Data Breach Report. Ninguna otra industria ha permanecido tanto tiempo en la cima.

Esa cifra es lo que convierte el diseño de acceso de IA en una cuestión de nivel directivo y no solo de TI. Establece el costo de equivocarse, y suele ser el número que la junta recuerda tras una presentación.

La diferencia entre la IA clínica y la IA administrativa en el cuidado de la salud

La gobernanza se divide entre la IA que informa el cuidado y la IA que gestiona el trabajo relacionado. Cada lado tiene diferentes responsables, reguladores y preguntas que responder.

La validación clínica de IA es una disciplina seria con su propio aparato regulatorio, y no algo que una plataforma de visibilidad de datos deba pretender resolver. La IA administrativa pertenece a seguridad, TI y privacidad, y es donde realmente se plantean las preguntas de acceso que hace un consejo.

Cómo responden los reguladores estadounidenses a la IA en la salud

La elaboración de normas federales, la acreditación y la legislación estatal están avanzando, y ninguna requiere esperar una norma final antes de actuar. Los reguladores tratan la IA como una extensión de las obligaciones existentes, por lo que los nuevos requisitos se aplican a los sistemas de salud que ya operan bajo la maquinaria HIPAA.

La actualización de la regla de seguridad HIPAA menciona directamente a la IA

HHS emitió un aviso de propuesta de reglamentación (NPRM) sobre la Regla de Seguridad HIPAA que aborda explícitamente la inteligencia artificial. Su propuesta de análisis de riesgos para la información electrónica protegida (ePHI) nombra directamente las herramientas de IA. Requiere "consideración repetida de, entre otras cosas, el tipo y la cantidad de ePHI accedida por herramientas de inteligencia artificial, a quién se divulgan los datos y a quién se proporciona la salida."

La regla sigue siendo propuesta, y OCR continúa haciendo cumplir la actual Security Rule. Las entidades cubiertas que realizan HIPAA risk analyses hoy ya deberían documentar cómo las herramientas de IA interactúan con ePHI.

La Joint Commission ahora certifica la gobernanza de IA

La Joint Commission lanzó su Responsible Use of AI in Healthcare certification el 1 de junio de 2026, el primer programa de acreditación basado en cómo los sistemas de salud gestionan la IA y no en los productos de IA en sí.

Otorga la certificación a nivel organizacional o de sistema, y sus estándares abarcan gobernanza, gestión de datos, reducción de riesgos y sesgos, monitoreo y validación, así como transparencia y capacitación.

La certificación es voluntaria, aunque las organizaciones acreditadas deben esperar que las expectativas subyacentes aparezcan en las conversaciones de las encuestas.

Las leyes estatales de IA se están superponiendo a HIPAA

La legislación estatal añade obligaciones en lugar de reemplazar las federales, por lo que los sistemas de salud que operan en varios estados heredan requisitos que varían según el lugar donde se presta la atención.

La Texas Responsible Artificial Intelligence Governance Act ha exigido la divulgación al paciente cuando los proveedores usan IA en la atención desde el 1 de enero de 2026, y la AB 3030 de California requiere avisos en las comunicaciones generadas por IA sobre la información clínica del paciente.

La preeminencia federal parece poco probable que alivie esa carga. El Senado votó 99 a 1 en julio de 2025 para eliminar una moratoria de diez años sobre la regulación estatal de IA del proyecto de ley de conciliación presupuestaria, dejando a los operadores multiestatales con obligaciones acumulativas y específicas de cada jurisdicción.

Las obligaciones de la FDA y del EU AI Act permanecen con alcance clínico

Supervisión de la FDA sobre dispositivos médicos habilitados con IA y las reglas de alto riesgo del EU AI Act imponen requisitos reales, y ambas se aplican principalmente a la IA que informa diagnósticos o tratamientos. Un equipo que evalúe IA administrativa debe confirmar en qué categoría encaja cada herramienta, ya que la documentación ambiental y las herramientas de triaje están más cerca de la línea clínica de lo que a veces sugieren sus proveedores.

Por qué Microsoft 365 Copilot merece su propia conversación sobre gobernanza

Copilot es la única herramienta administrativa de IA que la mayoría de los sistemas de salud implementan en todo el inquilino, y necesita un tratamiento separado porque no cambia nada sobre los permisos, pero sí todo sobre quién los nota.

La documentación de Microsoft indica que Copilot "solo muestra datos organizacionales a los que los usuarios individuales tienen al menos permisos de visualización." Por lo tanto, toda cuestión de gobernanza se basa en lo que esos permisos ya permiten, y eso genera tres problemas que un documento de políticas no puede abordar:

• El esfuerzo se reduce, por lo que el acceso inactivo se utiliza: Alguien que ya podía abrir un archivo en SharePoint o buscar en un buzón ahora puede pedir a Copilot que lo resuma, lo muestre en una conversación diferente o lo incluya en un borrador. El permiso siempre estuvo ahí. Lo que desaparece es el trabajo necesario para ejercerlo, desde una búsqueda deliberada hasta una frase en lenguaje natural.
• El exceso de compartición antiguo se convierte en exposición actual: Los enlaces de compartición amplios, permisos obsoletos y membresías de grupo que nadie ha revisado desde una reorganización permanecen inofensivos hasta que algo comienza a analizarlos rápidamente. La licencia de Copilot en un tenant de salud es ese momento, por eso Copilot data security comienza con una auditoría de permisos.
• Revelar PHI al clínico incorrecto infringe HIPAA: Cuando ese contenido compartido en exceso es PHI, mostrarlo a usuarios que no lo necesitan viola el estándar mínimo necesario de 45 CFR 164.502(b). El cifrado con etiquetas de sensibilidad cambia materialmente la exposición, porque Copilot necesita derechos de extracción para resumir el contenido.

Los sistemas de salud que han realizado este trabajo reportan que la remediación de permisos alcanza millones de correcciones individuales de compartición antes de un despliegue a nivel de inquilino, lo que convierte la preparación en un proyecto y no en una simple casilla para marcar.

Cómo crear un programa de gobernanza de IA en el sector salud

Cada una de estas decisiones corresponde a un líder que la toma y luego delega el trabajo, y deben ocurrir en orden. Nombra un responsable antes de que exista el inventario, y esa persona aún no tiene nada que gestionar.

Nombre un único responsable

"El comité de gobernanza de IA se encargará," sin una persona nombrada detrás, es como estos programas se estancan. No importa si esa persona está en seguridad, cumplimiento o TI, sino que una persona sea responsable, de la misma manera que un oficial de privacidad HIPAA es responsable de la privacidad.La guía de Joint Commission espera un propietario nombrado que lidere la implementación de IA durante todo el ciclo de vida.

Base el inventario en lo que cada herramienta puede realmente alcanzar

Catalogue cada sistema de IA que toque flujos clínicos, administrativos o integrados, y asocie cada uno con los datos PHI o adyacentes a PHI a los que puede acceder. Dirija cada entrada al propietario que pueda evaluar cómo falla, enviando herramientas de diagnóstico a la revisión clínica y herramientas de productividad a seguridad.

La mayoría de los inventarios comienzan desde cero, porque el descubrimiento suele ser informal. Una encuesta de diciembre de 2025 de 51 organizaciones de salud realizada por Censinet y la CHIME Foundation encontró que el 51 % dependía de un descubrimiento informal ad hoc o de las notas de lanzamiento del proveedor para saber qué AI estaban usando. Los riesgos de seguridad de Shadow AI se acumulan mientras ese descubrimiento siga siendo informal.

Confirme que la cobertura del proveedor y del BAA coincide con el uso real de la IA

Cada proveedor de IA que crea, recibe, mantiene o transmite PHI necesita un BAA que aborde cómo la IA del proveedor procesa, almacena y conserva PHI. Un BAA estándar firmado antes de que la IA entrara en el producto deja una brecha real de responsabilidad aunque el acuerdo siga vigente, por lo que las actualizaciones del producto del proveedor deben desencadenar la revisión en lugar de las fechas de renovación.

Revise específicamente los términos de servicio cubierto, uso de datos, retención, subcontratistas y seguridad. Verifique el acuerdo de servicio estándar junto con el BAA, ya que un BAA firmado no anula términos separados que otorgan al proveedor amplios derechos para usar los datos del cliente. La cobertura también varía según la línea de productos. OpenAI ofrece BAAs para implementaciones elegibles de ChatGPT Enterprise que usan un Regulated Workspace, mientras que ChatGPT Business sigue siendo inelegible.

Establezca controles de datos e identidad según lo encontrado en el inventario

Las restricciones de acceso y la supervisión deben abordar la exposición que realmente mostró el inventario. El lenguaje de mínimo privilegio escrito antes de que alguien supiera a qué sistemas podía acceder la IA no resistirá la pregunta de seguimiento de un auditor. Una evaluación de riesgos de identity and access management limitada a los sistemas inventariados produce esa especificidad.

El control resultante debe ser concreto, no una declaración de política. Si el inventario muestra que Copilot puede acceder a un recurso compartido de archivos que contiene hojas de cálculo del censo de pacientes, el control es una remediación de permisos en ese recurso, con una fecha y un responsable.

Establezca un camino de monitoreo y escalamiento

Un programa necesita una forma de detectar la exposición de PHI impulsada por IA en el momento en que ocurre, y una persona designada a quien escalar cuando se detecta. La detección significa vigilar los repositorios que leen las herramientas de IA, lo cual es un monitoreo de acceso a archivos dirigido a un nuevo consumidor. Sin la parte de escalación, la primera señal de un problema es un informe de incidente donde debería haber habido una revisión de gobernanza.

Usando NIST AI RMF y HIPAA como su modelo operativo

NIST AI RMF proporciona la estructura para un programa de gobernanza de IA en salud, y HIPAA proporciona los detalles legales; juntos eliminan la necesidad de un marco personalizado.

Las cuatro funciones de NIST se integran claramente en un programa de gobernanza. Govern es el propietario responsable designado, Map es el inventario, Measure es la evaluación de los riesgos reales de cada caso de uso, y Manage son los controles y la monitorización continuos. El ciclo se ejecuta de forma continua, no como una configuración única.

La expectativa de inventario es explícita, ya que Subcategory GOVERN 1.6 exige mecanismos para inventariar sistemas de IA, y el inventario de activos tecnológicos propuesto en el NPRM convertiría esa misma expectativa en una regulación.

Las Reglas de Privacidad y Seguridad de HIPAA establecen las obligaciones legales bajo esa estructura cuando se trata de PHI. Juntas, generan un marco claro y amplio, y ninguna de las dos estructuras requiere certificación formal.

La evidencia que demuestra que el acceso a PHI está realmente controlado

Los auditores y los comités de la junta solicitan artefactos, y la recuperación es donde la mayoría de los programas fallan: hacen el trabajo y luego dispersan la prueba en seis sistemas y en las bandejas de entrada de cuatro personas. Cada artefacto debe existir antes de que llegue la pregunta.

Un inventario actual del sistema de IA con un propietario nombrado

Cada sistema catalogado, vinculado a una persona nombrada, no a un departamento, que pueda responder cuando un auditor pregunte quién aprobó una expansión determinada de Copilot. La entrada también debe registrar qué PHI puede alcanzar el sistema, para que el inventario y el mapa de flujo de datos permanezcan conciliables y no se conviertan en dos documentos separados.

Un mapa de flujo de datos que muestra dónde la PHI entra en una herramienta de IA

Cada lugar donde PHI entra en una herramienta de IA, un aviso, un archivo, un embedding o una salida, localizado por herramientas de descubrimiento de datos sensibles a lo largo de cada ruta. La propuesta de la Regla de Seguridad HIPAA requeriría un mapa de red ePHI actualizado al menos anualmente, por lo que este artefacto se dirige hacia un requisito normativo más que una buena práctica.

Documentación del proveedor y BAA específica para cada herramienta de IA

Documentación vinculada a la capacidad específica de IA que ofrece cada proveedor, no una carpeta general de BAA, comparada con la cobertura confirmada durante la configuración del programa. Una carpeta así no responde a la pregunta que realmente hace un revisor.

Informes de acceso y permisos que muestran quién puede acceder a sistemas adyacentes a PHI

Una respuesta puntual sobre lo que una herramienta de IA puede ver, es decir, las identidades y grupos que tienen acceso a los repositorios subyacentes, no la pantalla de configuración de la herramienta. La configuración de Copilot describe lo que hará con los permisos que ya tiene, por lo que un informe basado solo en la herramienta subestima el alcance. Un revisor pregunta sobre los permisos efectivos, incluido el acceso heredado a través de grupos anidados.

Un registro de cambios que muestra cuándo se modificó ese acceso

La variación en el acceso durante los meses desde la última instantánea, más amplia o más restringida que antes, algo que un solo informe de acceso no puede mostrar por sí mismo. Esa tendencia es lo que un auditor realmente quiere ver.

Registros de revisión de gobernanza que muestran que el programa está realmente en funcionamiento

Actas, aprobaciones o notas de revisión que demuestran una cadencia real. El marco de gobernanza cibernética de IA del Health Sector Coordinating Council de mayo de 2026 AI cyber governance framework recomienda informes estructurados trimestrales de riesgos de IA para la junta.

Una organización que puede entregar cada uno de ellos bajo solicitud tiene un programa. Una que necesita una semana para reunirlos tiene una política.

Cómo Netwrix soporta la capa de evidencia

Netwrix proporciona la capa de visibilidad de datos y evidencia de auditoría bajo un programa que la organización sanitaria construye y posee, respondiendo qué repositorios contienen PHI, quién puede acceder a ellos y qué cambió. La gobernanza de la información en el sector sanitario depende de que esas respuestas sean recuperables.

Visibilidad de datos sensibles

Netwrix 1Secure identifica repositorios que contienen PHI a los que Copilot y otras herramientas de IA pueden acceder y evalúa la preparación de Copilot antes del despliegue, no después. Netwrix Access Analyzer añade descubrimiento automatizado de PHI y mapeo predefinido de cumplimiento HIPAA en servidores de archivos, SharePoint y entornos híbridos, con patrones de detección que cubren códigos ICD-10, números de registros médicos y nombres de medicamentos recetados.

Contexto de Identity y acceso

Netwrix Access Analyzer informa sobre los permisos efectivos en datos adyacentes a PHI, incluyendo el acceso excesivo y heredado que grupos amplios obtienen sin que nadie lo note. Netwrix 1Secure y Netwrix Auditor informan sobre la actividad y los cambios de permisos en Active Directory y Microsoft Entra ID a lo largo del tiempo.

King's College Hospital utilizó Netwrix Auditor para reforzar el control sobre los privilegios que acceden a los datos de pacientes, con visibilidad total en una red de 10,000 usuarios que respalda sus informes de cumplimiento del National Health Service.

Evidencia de auditoría

Netwrix Auditor registra los cambios de acceso y permisos, capturando quién accedió a qué, cuándo y qué cambió, con valores antes y después. Su Archivo a Largo Plazo conserva evidencias antiguas, lo que mantiene el registro de cambios útil durante todo un ciclo de auditoría y no solo desde que se cerró la última ventana de retención.

Netwrix 1Secure cubre el aspecto de IA de la misma cuestión. Informa sobre las interacciones de Microsoft 365 Copilot y rastrea qué datos sensibles Copilot accedió y mostró, que es el artefacto que responde a lo que una herramienta realmente alcanzó en lugar de lo que se le permitió alcanzar.

Donde Netwrix se detiene

Netwrix no ofrece gobernanza de IA para el sector salud como categoría ni garantiza el cumplimiento de HIPAA. No gobierna ni aplica políticas a Copilot ni a ninguna otra herramienta de IA, ni valida modelos clínicos ni detecta sesgos clínicos. Su función es la capa de evidencia bajo un programa de gobernanza que posee la organización.

Vea a qué pueden acceder realmente sus herramientas de IA antes de que lo pregunte un auditor

La mayoría de las organizaciones de salud aún no pueden responder qué alcance tienen Copilot y las otras herramientas administrativas de IA, y la razón rara vez es una política faltante. Nadie lo ha mapeado.

Ese mapeo es donde comienza el programa, porque indica al propietario responsable qué repositorios importan y convierte una lista de artefactos requeridos en informes que alguien realmente puede ejecutar. Los equipos que evalúan una capa de evidencia deben probar si puede mapear la exposición de PHI, calcular el acceso efectivo, preservar el historial de cambios de permisos y generar esos registros bajo demanda.

Solicite una demostración para ver a qué repositorios adyacentes a PHI pueden acceder sus herramientas de IA, quién tiene permiso para esos datos y cómo ha cambiado ese acceso con el tiempo.