Cumplimiento HIPAA e IA: lo que un BAA no cubre

Lo esencial

• El BAA, el contrato que HIPAA impone frente a los proveedores, reparte la responsabilidad sobre el dato. Nada dice sobre la exactitud, la equidad o la seguridad clínica del modelo, que es donde se concentra la mayor parte del riesgo.
• HIPAA renunció a regular la inteligencia artificial. La propuesta de reforma de la Security Rule presentada en enero de 2025 se limita a una petición de aportaciones sobre IA y no introduce ninguna garantía específica.
• La norma que de verdad vincula a la IA clínica en Estados Unidos se llama Section 1557. Sus obligaciones sobre herramientas de apoyo a la decisión asistencial son exigibles desde el 1 de mayo de 2025.
• HTI-1 obliga al software sanitario certificado a exponer 31 atributos de origen para el apoyo a la decisión predictivo, que sirven además como cuestionario de diligencia debida ya preparado para cualquier proveedor de IA.
• Un cumplimiento HIPAA aplicado a la IA se sostiene cuando un único conjunto de controles responde a la vez a HIPAA, a la Section 1557, a HTI-1, a la FDA y, para quien opera a ambos lados del Atlántico, al Reglamento europeo de IA.

Qué cubre realmente HIPAA cuando la IA toca datos sanitarios

Casi todos los contenidos dedicados al cumplimiento HIPAA y la IA arrancan en el mismo punto: elegir un proveedor dispuesto a firmar un BAA, comprobar el cifrado, asegurarse de que la herramienta no entrena sus modelos con sus consultas. El consejo es correcto y es también la parte más pequeña del problema. HIPAA se compone de dos bloques operativos. La Privacy Rule regula cómo pueden usarse y comunicarse las informaciones sanitarias protegidas, las llamadas PHI. La Security Rule regula las garantías administrativas, físicas y técnicas aplicables a su forma electrónica. Un proveedor de IA que recibe, almacena o trata PHI por cuenta de una entidad cubierta se convierte en business associate, y ambas reglas lo alcanzan a través del contrato. Lo que HIPAA no hace es regular el modelo. El texto guarda silencio sobre la procedencia de los datos de entrenamiento, sobre el rendimiento por subpoblación, sobre la deriva de calibración y sobre la idoneidad clínica de una recomendación. Esas cuestiones pertenecen a otros regímenes, y son precisamente las que determinan si un despliegue de IA daña a un paciente. Dos zonas fronterizas pesan más de lo que suponen los equipos. La primera es la anonimización. Los datos tratados por el método Safe Harbor o certificados mediante Expert Determination quedan fuera del perímetro de HIPAA, y de ahí que tantos proyectos de IA sanitaria se apoyen en corpus anonimizados. Los modelos de gran tamaño erosionan esa tranquilidad, porque la memorización y el cruce de elementos dentro de texto clínico rico pueden devolver un conjunto de datos hacia la identificabilidad por caminos que la evaluación original nunca contempló. Si su certificado de anonimización es anterior al modelo, no cubre el modelo. La segunda zona fronteriza es el perímetro mismo. HIPAA se aplica en función de quién custodia el dato, no de cuán sensible sea. Un verificador de síntomas dirigido al público, una aplicación de bienestar o un asistente conversacional destinado directamente al paciente, si no contratan con ninguna entidad cubierta, quedan por lo general por completo fuera de HIPAA y recaen más bien bajo el FTC Act y la Health Breach Notification Rule. El dato sanitario no lleva HIPAA consigo. Lo hace la relación contractual. Esa distinción reproduce la que ordena cualquier otra evaluación de impacto que realice su organización, y conviene leerla junto a las diferencias entre evaluación de impacto sobre la privacidad, EIPD y FRIA, dado que un programa de IA sanitaria rara vez necesita una sola.

El BAA es necesario y no suficiente

Un business associate agreement cumple tres funciones útiles. Vincula al proveedor a la Privacy Rule y a la Security Rule, delimita los usos permitidos de las PHI y le obliga a notificar las brechas. Prescindir de él resulta indefendible. Cuando un proveedor gestiona indebidamente PHI sin contrato firmado, la Office for Civil Rights trata la ausencia del acuerdo como una infracción autónoma, que se suma a todo lo demás. El historial sancionador respalda esa seriedad. El 23 de abril de 2026 la OCR anunció acuerdos con cuatro entidades por brechas vinculadas a ransomware, por un total de 1.165.000 dólares y más de 427.000 personas afectadas, cada uno acompañado de un plan de acciones correctoras de dos años bajo supervisión. La supervisión de proveedores subyace a una parte creciente de esas sanciones, y la participación de terceros en las brechas de datos sanitarios se duplicó del 15 al 30 por ciento interanual en 2025. Firme, por tanto, el contrato. Y observe después lo que no ha comprado con él. Un BAA firmado no le dice qué versión del modelo está en producción. No documenta con qué datos se entrenó el modelo ni si la población de entrenamiento se parece a su población asistida. No mide el rendimiento por edad, sexo, idioma o régimen de cobertura. No detecta que un proveedor haya sustituido en silencio su modelo fundacional en una entrega trimestral. Y no genera un solo documento que pueda entregar a un auditor que pregunte por qué un paciente concreto recibió una recomendación concreta. Esos huecos son trabajo de gobernanza, no de compras. Viven en el mismo lugar que el resto de su modelo de cumplimiento y gobernanza: un inventario, un responsable, una clasificación del riesgo, un resultado de prueba, una cadencia de supervisión y un registro de decisión. El contrato reparte la culpa una vez ocurrido el fallo. La gobernanza hace el fallo menos probable y demostrable en ambos sentidos.

Dónde se detiene HIPAA: la reforma de 2025 esquivó la IA

Quien espere que sea HIPAA misma la que responda a la pregunta sobre la IA haría bien en leer lo ocurrido en el último procedimiento normativo. El 27 de diciembre de 2024 el Department of Health and Human Services anunció una propuesta de modernización de la Security Rule, publicada en el Federal Register el 6 de enero de 2025. Se trata de la primera revisión sustancial de ese texto en unas dos décadas. En los fundamentos de ciberseguridad la propuesta resulta ambiciosa: inventarios de activos, cartografía de red, autenticación multifactor obligatoria, requisitos de cifrado y supresión de buena parte de la flexibilidad que permitía tratar las garantías como opcionales. Sobre inteligencia artificial, en cambio, apenas hace nada. La IA solo aparece en una petición de aportaciones, junto a la computación cuántica y la realidad virtual y aumentada, en la que se pregunta al público cómo debería tratar la Security Rule las PHI electrónicas empleadas por tecnologías emergentes. La OCR tenía la ocasión de fijar reglas básicas para la IA y el aprendizaje automático y prefirió recabar opiniones. El plazo se cerró el 7 de marzo de 2025 con cerca de 5.000 aportaciones, y el texto definitivo sigue pendiente. La lectura operativa es sencilla. Cuando llegue la norma final elevará su nivel mínimo de seguridad, lo cual ayuda. No le dirá cómo validar un modelo, ni cómo comprobar un rendimiento desigual, ni qué pruebas conservar sobre una recomendación algorítmica. Reducir la obligación en materia de IA a HIPAA equivale a pedir a una ley escrita para archivos que responda sobre inferencia. El cuadro completo se reparte entre varios regímenes a la vez, y por eso el mapa global de las leyes de IA interesa incluso a un prestador exclusivamente estadounidense.

Section 1557: la norma que de verdad vincula a su IA clínica

Aquí está la norma que casi ninguna guía sobre cumplimiento HIPAA para la IA menciona, y ya está en vigor. La Section 1557 de la Affordable Care Act prohíbe la discriminación por raza, color, origen nacional, sexo, edad y discapacidad en los programas y actividades sanitarias que reciben financiación federal. El HHS aprobó una norma definitiva el 6 de mayo de 2024, en vigor desde el 5 de julio de 2024, que extiende expresamente esos principios a lo que denomina herramientas de apoyo a la decisión asistencial. La definición es deliberadamente amplia. Abarca herramientas, mecanismos, métodos y tecnologías, automatizados o no, empleados para respaldar una decisión clínica, de modo que incluye por igual algoritmos clínicos, puntuaciones de riesgo, lógicas de triaje y modelos de aprendizaje automático. Las entidades cubiertas dispusieron de 300 días desde la entrada en vigor para adaptarse a las disposiciones sobre apoyo a la decisión, lo que situó la fecha límite en el 1 de mayo de 2025. La obligación tiene dos partes. Primero, realizar esfuerzos razonables para identificar las herramientas de apoyo a la decisión en uso que empleen raza, color, origen nacional, sexo, edad o discapacidad como variable de entrada. Segundo, realizar esfuerzos razonables para mitigar el riesgo de discriminación derivado de ellas. Ambas obligaciones son continuas. No se trata de una declaración que se firma una vez y se archiva. Contraste esos dos verbos con el consejo de compra que domina los resultados de búsqueda. Ningún cifrado identifica una variable de entrada. Ningún BAA mitiga una disparidad. La norma alcanza al modelo, y el deber recae sobre la entidad cubierta, no sobre el proveedor.

Cómo se ven los esfuerzos razonables en forma de prueba

Las autoridades no aceptan intenciones. Aceptan registros. Para cada herramienta de apoyo a la decisión clínica, un expediente defendible contiene una ficha de inventario con denominación, versión y finalidad clínica; una revisión documentada de las variables de entrada que señale cualquier característica protegida o su sustituto inmediato, como código postal, idioma preferente o situación aseguradora; resultados de rendimiento desglosados por los subgrupos que la norma enumera; una decisión de mitigación escrita y motivada, incluida la de aceptar un riesgo residual; una cadencia de supervisión con umbrales definidos; y un responsable designado por su nombre. Ese conjunto probatorio responde además a la mayor parte de lo que pedirá cualquier auditor de IA, y se completa de forma natural con una posición clara sobre dónde se sitúa el clínico en el circuito. Para una herramienta consultiva, la diferencia entre supervisión humana dentro del circuito y sobre el circuito determina exactamente si una medida de mitigación es real o meramente nominal.

HTI-1 y la capa de transparencia dentro de la historia clínica

Mientras la OCR renunciaba a regular los modelos, el programa de certificación del software sanitario lo hacía de todos modos. La norma definitiva HTI-1, aprobada por el Assistant Secretary for Technology Policy, antes ONC, creó un criterio de certificación dedicado a las Decision Support Interventions. Incorpora los primeros requisitos de transparencia de su clase sobre algoritmos predictivos integrados en software sanitario certificado. Los sistemas certificados deben mostrar al clínico atributos de origen estructurados: 13 para el apoyo a la decisión basado en la evidencia y 31 para el apoyo a la decisión predictivo. Esos 31 atributos son la parte interesante. Describen la finalidad y el uso previsto de la intervención, el proceso de desarrollo, los datos empleados para entrenar y validar el modelo subyacente, cómo se midió el rendimiento, cómo se evaluó la equidad y cómo se mantiene la intervención a lo largo del tiempo. El objetivo declarado consiste en permitir a una organización juzgar si una intervención predictiva es equitativa, apropiada, válida, eficaz y segura, una prueba que el programa resume en el acrónimo FAVES. De ahí se derivan dos consecuencias para cualquier programa de cumplimiento HIPAA aplicado a la IA. En primer lugar, si su herramienta predictiva reside en software sanitario certificado, esa documentación ya existe y usted tiene derecho a obtenerla. Muchos equipos de cumplimiento nunca la han reclamado. En segundo lugar, y con mayor utilidad práctica, esos 31 atributos constituyen un cuestionario de proveedores directamente reutilizable para la IA que no está certificada por nadie. Un proveedor incapaz de describir su población de entrenamiento, su método de validación o su evaluación de equidad le está diciendo algo, y la administración federal ya ha resuelto que esas preguntas tienen respuesta. Utilícelos al decidir si una capacidad de IA pertenece a su plataforma gobernada o al conjunto disperso de herramientas que la rodea.

La FDA y la frontera entre función y producto sanitario

Una parte de la IA clínica constituye un producto sanitario regulado, y la frontera es más fina de lo que suponen la mayoría de los compradores. La FDA había autorizado más de 1.350 productos con IA a comienzos de 2026, aproximadamente el doble que en 2022. Un software que analiza una imagen, calcula una puntuación de riesgo para una patología concreta o conduce a una conclusión diagnóstica entra con frecuencia en esa categoría. Un software que resume una nota, redacta una carta o encamina un mensaje, por lo general no. La pregunta decisiva se refiere a la finalidad declarada, esto es, diagnosticar, tratar, mitigar o prevenir una enfermedad, y a la posibilidad de que el clínico examine de forma independiente el fundamento de la recomendación. El aprendizaje automático tensiona la regulación de productos sanitarios en un punto concreto: un producto autorizado debe permanecer conforme a su autorización, mientras que un modelo tiende a cambiar. La respuesta de la FDA se llama Predetermined Change Control Plan y permite al fabricante obtener autorización previa para un perímetro definido de modificaciones futuras del modelo, dentro del uso previsto aprobado. La adopción sigue siendo escasa: en torno al 10 por ciento de las autorizaciones de IA de 2025 incluía un plan aprobado. Para quien despliega la tecnología, de ahí resulta un control concreto. Pregunte a cada proveedor de IA clínica si el modelo está sujeto a un plan de control de cambios, cómo se le informará de una actualización del modelo y qué ocurre con sus pruebas de validación cuando el modelo cambia bajo ellas. Un reentrenamiento silencioso puede sacar a un producto de su uso previsto autorizado y de su propia cobertura de pruebas en el mismo instante. Es un problema de medición y supervisión, que se corresponde directamente con las funciones Measure y Manage del NIST AI Risk Management Framework.

Si además opera en Europa: la capa del Reglamento de IA

Muchas organizaciones que manejan PHI estadounidenses no son organizaciones estadounidenses. Proveedores europeos de salud digital, sociedades de investigación por contrato, fabricantes de productos sanitarios y grupos hospitalarios con acuerdos de investigación al otro lado del Atlántico soportan obligaciones HIPAA por contrato y obligaciones europeas por ley. Para ellos, el cumplimiento HIPAA no es más que la planta baja. Una IA que sea un producto sanitario, o que constituya un componente de seguridad de uno, es automáticamente de alto riesgo conforme al Reglamento de IA. En la práctica, los productos de clase IIa, IIb y III del MDR y de clase A a D del IVDR encajan normalmente en la categoría de alto riesgo. Los productos de clase I del MDR, que no requieren organismo notificado, no llegan allí por esa vía, aunque pueden quedar comprendidos si desempeñan una función enumerada en el anexo III. El anexo III añade además dos usos próximos a la asistencia, de alto riesgo sin ser productos sanitarios: la gestión de llamadas de emergencia y el triaje de pacientes en urgencias, y la evaluación de riesgos y la fijación de precios en los seguros de vida y salud. Las aseguradoras y las plataformas de triaje suelen dar por hecho que el Reglamento de IA es un asunto de productos sanitarios. No lo es. Los plazos cambiaron en 2026. Tras el Digital Omnibus adoptado en junio de 2026, las obligaciones para los sistemas de alto riesgo autónomos del anexo III se aplican desde el 2 de diciembre de 2027, mientras que la IA alojada en un producto regulado por el MDR o el IVDR dispone de plazo hasta el 2 de agosto de 2028. En marzo de 2026 los productos sanitarios con IA seguían certificándose exclusivamente conforme al MDR y al IVDR, y las obligaciones de alto riesgo del Reglamento aún no les resultaban aplicables. Ese desfase es tiempo de preparación, no una exención. Para las organizaciones españolas conviene recordar que la AEPD lleva años pronunciándose sobre tratamientos sanitarios automatizados y que la AESIA asumirá la supervisión del Reglamento de IA en el mercado nacional, de modo que las evaluaciones de impacto ya elaboradas cubren buena parte de lo que después se exigirá. Como referencia sobre las obligaciones en sí, siguen siendo centrales los deberes de proveedores y responsables del despliegue.

Construir el cumplimiento HIPAA de la IA sobre un único conjunto de controles

Cuatro regímenes, cuatro vocabularios, una sola serie de preguntas de fondo. Qué es este sistema, quién responde de él, en qué puede equivocarse, cómo lo sabría usted y si puede demostrarlo. Mantener cuatro programas de cumplimiento en paralelo es la forma en que las organizaciones sanitarias queman un año y aun así no superan la auditoría. Empiece por un inventario. Todo sistema de IA que toque pacientes o información sanitaria protegida recibe una ficha, incluidos los que nadie ha declarado. Los asistentes de transcripción comprados por un solo servicio, una función de resumen activada dentro de una plataforma ya implantada y los clínicos que pegan notas en un asistente conversacional de consumo entran todos en el perímetro, y los tres casos son frecuentes. El problema de la shadow AI pesa más en sanidad que en ningún otro sector, porque el beneficio clínico es inmediato mientras que la vía de compra es lenta. Clasifique después cada sistema con cuatro preguntas binarias. ¿Trata información sanitaria protegida? ¿Influye en una decisión asistencial? ¿Reside dentro de software sanitario certificado? ¿Es, o contiene, un producto sanitario regulado? Las respuestas determinan qué obligaciones se activan.

Sostenga el conjunto con un sistema de gestión y no con una hoja de cálculo. ISO/IEC 42001 aporta la estructura certificable: política, funciones, tratamiento del riesgo, auditoría interna, revisión por la dirección. El NIST AI Risk Management Framework aporta el ciclo de trabajo, es decir, Govern, Map, Measure y Manage. Ninguno de los dos es una norma sanitaria estadounidense, y precisamente por eso funcionan como capa de unión: son el lugar donde una prueba puede producirse una sola vez y oponerse a varias obligaciones. Es el mismo argumento que sostiene cualquier marco de gobernanza de la IA serio, aplicado a un sector en el que las consecuencias llegan antes.

Preguntas frecuentes

¿Se puede usar IA cumpliendo con HIPAA? Sí. HIPAA no prohíbe la inteligencia artificial, y nada en la Privacy Rule ni en la Security Rule impide a una entidad cubierta tratar información sanitaria protegida con un modelo. Lo que HIPAA exige es que el proveedor se incorpore como business associate mediante contrato escrito, que las garantías se apliquen a las PHI electrónicas implicadas y que el uso esté permitido por la Privacy Rule. Una revisión de cumplimiento HIPAA aplicada a la IA debería partir, por tanto, de la finalidad clínica y no del proveedor, porque la dificultad mayor consiste en satisfacer las demás normas aplicables, empezando por la Section 1557. ¿Es ChatGPT compatible con HIPAA para uso sanitario? La versión de consumo no lo es. Un modelo nunca es conforme por sí mismo; conforme puede serlo un despliegue. La conformidad depende de que el proveedor firme un BAA, de que las consultas y respuestas queden excluidas del entrenamiento, de la política de conservación y de que la configuración soporte control de accesos y registro de auditoría. Las ofertas empresariales y las API de los grandes proveedores pueden sostener un despliegue conforme. Las interfaces gratuitas de consumo por lo general no, y de ahí que pegar notas clínicas en un asistente público figure hoy entre las infracciones más comunes del sector. ¿Un BAA firmado hace que una herramienta de IA cumpla con HIPAA? No. Un business associate agreement es un reparto contractual de obligaciones sobre el dato. No evalúa el modelo, no verifica la exactitud entre subpoblaciones de pacientes y no crea ningún registro del motivo por el que se formuló una recomendación concreta. Las autoridades nunca han tratado un contrato firmado como prueba de que las garantías se implantaron efectivamente, y las obligaciones de la Section 1557 recaen sobre la entidad cubierta con independencia de lo que el proveedor haya aceptado. ¿Cuál era el plazo de la Section 1557 para las herramientas de apoyo a la decisión? La norma definitiva se aprobó el 6 de mayo de 2024 y entró en vigor el 5 de julio de 2024. Las entidades cubiertas dispusieron de 300 días desde esa entrada en vigor para adaptarse a las disposiciones sobre herramientas de apoyo a la decisión asistencial, lo que fijó el plazo en el 1 de mayo de 2025. Esas obligaciones se encuentran ya activas y son continuas, de manera que una organización que nunca haya revisado sus algoritmos clínicos en busca de variables protegidas acumula ya retraso. ¿Se aplica HIPAA si mi IA solo usa datos anonimizados? Los datos correctamente anonimizados quedan fuera del ámbito de HIPAA, ya sea por la vía del Safe Harbor o mediante Expert Determination. La cautela es necesaria porque la anonimización es una propiedad de un conjunto de datos en un momento dado, no un estado permanente. El texto clínico rico, las combinaciones de cuasi identificadores y la memorización por parte del modelo pueden elevar de nuevo el riesgo de reidentificación. Si la evaluación es anterior a la entrada de los datos en una cadena de tratamiento basada en modelos, sométala a nueva revisión frente a esa cadena en lugar de presumir que sigue siendo válida. ¿Quién responde cuando un proveedor de IA provoca una brecha de datos sanitarios? Pueden responder ambas partes. Los business associates responden directamente conforme a HIPAA de sus propias infracciones, y las entidades cubiertas siguen siendo responsables de la elección y la supervisión de sus proveedores. Sin contrato, la entidad cubierta se expone a un reproche separado solo por esa carencia. Más allá de HIPAA, la responsabilidad por una recomendación clínica dañina se rige por el derecho de responsabilidad sanitaria y de producto, donde el centro asistencial rara vez queda al margen del procedimiento. Su proceso de notificación de incidentes debería presuponer una exposición compartida. ¿Una organización sanitaria europea que atiende a pacientes estadounidenses necesita HIPAA y el Reglamento de IA a la vez? En la mayoría de los casos sí, y ante autoridades distintas. HIPAA alcanza a un operador europeo a través del BAA que lo vincula con una entidad cubierta estadounidense. El Reglamento de IA, el RGPD y el MDR o el IVDR lo alcanzan por el derecho de la Unión. Las obligaciones se solapan ampliamente en gestión de riesgos, registro, documentación y vigilancia humana, de modo que la vía eficiente consiste en mapear un único conjunto de controles sobre ambos regímenes en lugar de mantener dos programas en paralelo.

Conclusión

Los resultados de búsqueda sobre cumplimiento HIPAA e IA describen una decisión de compra. La obligación real describe una forma de operar. HIPAA rige el dato. La Section 1557 rige la decisión, y lo hace desde mayo de 2025. HTI-1 rige la información que se muestra. La FDA rige el producto sanitario. Para quien opera a ambos lados del Atlántico, el Reglamento de IA rige el sistema. Ninguna de esas normas es por sí sola la respuesta, y ninguna se conforma con un contrato firmado acompañado de una promesa de cifrado. Lo que las une no tiene nada de espectacular y resulta plenamente alcanzable: conocer cada sistema de IA en servicio, clasificarlo con honestidad, someterlo a prueba frente a las características que la ley enumera, dejar por escrito qué se decidió y por qué, y vigilarlo después de la puesta en marcha. Eso es la gobernanza de la IA, y en sanidad marca la diferencia entre un programa defendible y una buena intención.