Marco de gobernanza de IA para salud: HIPAA, FDA SaMD y requisitos de supervisión clínica

La IA en salud no es un desafío teórico de gobernanza. Es un requisito de cumplimiento regulatorio con estándares específicos, expectativas de auditoría e implicaciones de responsabilidad. Las organizaciones de salud que despliegan IA enfrentan un entorno regulatorio estratificado: HIPAA gobierna el manejo de datos, la FDA regula el software que califica como dispositivo médico, y la clasificación de alto riesgo del EU AI Act captura los sistemas de apoyo a la decisión clínica usados en operaciones europeas.

Este marco cubre las estructuras de gobernanza, mecanismos de supervisión y prácticas de documentación que los despliegues de IA en salud requieren.

Panorama regulatorio: qué aplica a tu sistema de IA

Antes de diseñar la gobernanza, establece qué regulaciones aplican.

HIPAA aplica si tu sistema de IA procesa, almacena o transmite información de salud protegida (PHI). Esto incluye sistemas que reciben datos del paciente como entrada (notas clínicas, metadatos de imagen, valores de laboratorio) o que producen salidas que contienen PHI. Las reglas de seguridad, privacidad y notificación de brechas de HIPAA se extienden a los sistemas de IA que tocan PHI.

El marco de Software como Dispositivo Médico (SaMD) de la FDA aplica si tu sistema de IA cumple la definición de dispositivo médico bajo 21 USC 321(h): software destinado a diagnosticar, curar, mitigar, tratar o prevenir enfermedades, o a afectar la estructura o función del cuerpo. El software de apoyo a decisión clínica que proporciona recomendaciones específicas para el paciente basadas en datos del paciente típicamente califica. La IA administrativa (programación, facturación, resumen de documentación sin recomendaciones clínicas) típicamente no.

La clasificación de alto riesgo del EU AI Act aplica a sistemas de IA destinados para uso en dispositivos médicos y sistemas de apoyo a decisión clínica cubiertos por las regulaciones de dispositivos médicos de la UE, desplegados dentro de la UE o para pacientes de la UE. La clasificación de alto riesgo requiere sistemas de gestión de riesgos, documentación de gobernanza de datos, transparencia para los implementadores, capacidad de supervisión humana y registro en la base de datos de la UE.

Los estándares de Joint Commission y CMS abordan cada vez más la IA en criterios de acreditación y certificación, particularmente alrededor de la gobernanza de apoyo a decisión clínica y requisitos de capacitación del personal clínico.

Determina cuáles aplican a cada sistema de IA en tu entorno antes de construir la estructura de gobernanza. La carga de cumplimiento difiere sustancialmente entre estos marcos.

Diseño humano-en-el-loop clínico

Para sistemas de IA que informan decisiones clínicas, la arquitectura humano-en-el-loop no es gobernanza opcional — es la línea base de diseño. Tres preguntas estructurales deben responderse para cada despliegue de IA clínica:

¿Qué decisiones informa la IA? Define el alcance de decisión con precisión. "Asiste con la estratificación de riesgo de sepsis" es lo suficientemente específico para diseñar gobernanza. "Asiste en la toma de decisiones clínicas" es demasiado amplio y crea responsabilidad sin claridad.

¿Quién revisa la salida de la IA antes de que afecte la atención del paciente? Identifica el rol específico (médico tratante, enfermera, farmacéutico) responsable de la revisión. El revisor debe tener la autoridad clínica para aceptar, modificar o rechazar la recomendación de IA. Si la única persona que revisa la salida es la misma que ingresó los datos, eso no es supervisión significativa.

¿Qué pasa cuando la IA y el clínico están en desacuerdo? El flujo de trabajo de anulación es tan importante como el flujo de trabajo predeterminado. Documenta el mecanismo de anulación, requiere documentación de la justificación clínica cuando no se sigue la recomendación de IA, y rastrea los patrones de anulación como señal de calidad.

Umbrales de confianza y escalamiento

Los sistemas de IA clínica bien diseñados no presentan todas las salidas de la misma manera. Construye umbrales de confianza en la capa de presentación:

Salidas de alta confianza (el modelo opera dentro de su rango validado): presentar al clínico responsable con una acción recomendada clara
Salidas de confianza moderada (el modelo está en los bordes de su rango validado): señalar para revisión explícita del clínico antes de la acción
Salidas de baja confianza (entradas fuera de distribución): escalar a un clínico senior o señalar para evaluación solo humana, no presentar la recomendación de IA como guía

La calibración de umbrales debería validarse contra tu población clínica, no solo contra datasets de referencia. El cambio de distribución es un fenómeno real — un modelo entrenado en la población de un hospital puede tener diferentes características de confianza en la de otro.

Cumplimiento HIPAA para sistemas de IA

El cumplimiento HIPAA para sistemas de IA tiene varios componentes que los marcos estándar de manejo de datos no cubren completamente.

Estándar de mínimo necesario

El estándar de mínimo necesario de HIPAA (45 CFR §164.514) requiere limitar el acceso a PHI al mínimo necesario para cumplir el propósito previsto. Para IA, esto significa:

El sistema de IA debería recibir solo los elementos de datos que realmente necesita para realizar su función. Un modelo de predicción de sepsis no necesita la información de seguro del paciente ni códigos de facturación. Diseña los pipelines de datos para pasar solo los campos necesarios.
Controles de acceso basados en roles en el propio sistema de IA: un codificador de facturación debería poder consultar la IA para asistencia de codificación pero no debería poder consultar la IA clínica para evaluaciones clínicas específicas del paciente.
Auditoría a nivel de consulta: cada consulta de IA que incluya PHI debe registrarse con la identidad del usuario y la autorización de rol que permitió la consulta.

Requisitos de control de auditoría

El estándar de control de auditoría de HIPAA (45 CFR §164.312(b)) requiere mecanismos que registren y examinen la actividad en sistemas que contienen PHI. Los sistemas de IA que contienen o procesan PHI deben producir registros de grado de auditoría que incluyan:

Identidad y rol del usuario en el momento de la consulta
Marca de tiempo en UTC
Elementos de datos presentes en la consulta (no necesariamente el contenido completo de la consulta para sistemas de alto volumen, pero suficiente para identificar qué PHI estuvo involucrada)
Versión del modelo consultada
Salida entregada
Si la salida se usó en una decisión clínica (si tu sistema captura esto)

Estos registros deben retenerse según tu cronograma de retención HIPAA y deben ser producibles en respuesta a una investigación de brecha o auditoría del OCR.

Acuerdos de asociado comercial

Si tu proveedor de IA procesa PHI en tu nombre, se requiere un Acuerdo de Asociado Comercial (BAA) bajo HIPAA. Esto aplica a:

Proveedores de API de IA en la nube que reciben prompts que contienen PHI
Plataformas de fine-tuning que entrenan con datasets que contienen PHI
Proveedores de alojamiento de inferencia donde se ejecuta tu modelo de IA

Si ajustas con PHI y despliegas localmente, la capa de inferencia no requiere un BAA (tú eres tu propio asociado comercial). El paso de entrenamiento sí lo requiere si involucra un proveedor externo de cómputo.

Requisitos de gobernanza FDA SaMD

Si tu sistema de IA califica como Software como Dispositivo Médico, los requisitos de gobernanza de la FDA aplican además de HIPAA.

Plan de control de cambios predeterminado

La guía de IA/ML SaMD de la FDA enfatiza un Plan de Control de Cambios Predeterminado (PCCP) — documentación de cómo gestionarás actualizaciones del modelo, reentrenamiento y cambios de rendimiento después de la autorización inicial. El PCCP debería describir:

Métricas de rendimiento y umbrales que activan la revisión del modelo
El proceso para evaluar si un cambio de modelo constituye una modificación que requiere nueva presentación regulatoria
Requisitos de validación clínica antes de desplegar un modelo reentrenado
Cómo comunicarás los cambios a los usuarios clínicos

Para modelos ajustados que posees: controlas el proceso de reentrenamiento. Documéntalo. Para sistemas basados en API en la nube: tu PCCP debe tener en cuenta las prácticas de actualización de modelos del proveedor, que pueden estar fuera de tu control — una razón por la cual muchos desarrolladores de SaMD prefieren infraestructura de modelos propia.

Transparencia del algoritmo

La guía de la FDA sobre SaMD basado en IA/ML incluye requisitos de transparencia. Los usuarios clínicos y tomadores de decisiones clínicas deben tener acceso a:

Qué está haciendo la IA (su función clínica)
Con qué datos fue entrenada (a nivel de categoría)
Sus características de rendimiento conocidas (precisión, sensibilidad, especificidad por subgrupo relevante)
Sus limitaciones conocidas (poblaciones de pacientes donde el rendimiento es menor, condiciones de entrada donde el modelo puede tener bajo rendimiento)

Esta información debería documentarse en una tarjeta del modelo y hacerse accesible al personal clínico que usa el sistema.

Vigilancia post-comercialización

SaMD requiere programas de vigilancia post-comercialización. Para sistemas de IA, esto significa rastrear:

Rendimiento del modelo contra resultados clínicos del mundo real (no solo predicho vs. observado en datos retenidos)
Reportes de eventos adversos donde la IA pueda haber contribuido a un error clínico
Patrones de anulación como señal de rendimiento
Monitoreo de rendimiento demográfico para detección de sesgos

Especificación de rastro de auditoría para IA en salud

Un rastro de auditoría de IA en salud debe capturar suficiente información para reconstruir cada decisión clínica influenciada por IA. Registro mínimo por consulta:

Campo	Valor
ID de evento	Identificador único por consulta
Marca de tiempo	UTC, precisión de milisegundos
ID de usuario	Vinculado al sistema de RRHH/credenciales
Rol de usuario	Según autorización en el momento de la consulta
ID de paciente	Desidentificado o pseudonimizado según política de registro
Elementos de datos incluidos	Categorías (labs, signos vitales, notas) sin PHI completa en el registro
ID de modelo	Versión específica del modelo y versión del adaptador
Salida entregada	La recomendación presentada al clínico
Acción del clínico	Aceptado / Modificado / Rechazado (si se captura)
Razón de anulación	Texto libre si se rechazó (si se captura)

Retención: El mínimo de HIPAA es 6 años para entidades cubiertas. Las leyes estatales pueden extender esto. Los sistemas de alto riesgo del EU AI Act requieren retención de registros por 10 años.

Estructura del comité de gobernanza

La gobernanza de IA en salud requiere rendición de cuentas multifuncional. Un comité de gobernanza mínimo viable incluye:

Campeón clínico: Un médico o proveedor de práctica avanzada que pueda evaluar la validez clínica de las recomendaciones de IA y servir como enlace entre la gobernanza y el personal clínico que usa el sistema.

Oficial de cumplimiento o privacidad: Responsable de la revisión de cumplimiento HIPAA y regulatorio de cada despliegue de IA.

Seguridad de la información: Responsable del control de acceso, integridad del registro de auditoría y seguridad de datos de la infraestructura de IA.

Asesor legal: Revisión del estado regulatorio FDA, contratos de proveedores (BAAs, indemnización) e implicaciones de responsabilidad.

TI/ingeniería: Responsable de infraestructura, despliegue de modelos e implementación de registros.

Este comité debería reunirse como mínimo trimestralmente, y antes de cada nuevo despliegue de IA, actualización de modelo o cambio significativo en el alcance de IA.

Infraestructura on-premise para IA en salud

Las organizaciones de salud con requisitos estrictos de manejo de PHI tienen razones estructurales para preferir la inferencia de IA on-premise. Cuando los modelos de IA se ejecutan en tu infraestructura:

La PHI nunca sale de tu red para llegar a un endpoint de API en la nube
Tus controles de acceso de red existentes aplican al sistema de IA
Tu infraestructura de registro de auditoría captura las consultas de IA de la misma manera que captura cualquier otra consulta de sistema clínico
No dependes de un BAA con un proveedor de inferencia externo para cada consulta de producción

El modelo de despliegue: ajusta en GPUs en la nube usando datos de entrenamiento desidentificados o sintéticos, exporta a formato GGUF, despliega la inferencia localmente vía Ollama o llama.cpp en tu red clínica. Nube para entrenamiento, on-premise para inferencia.

Agenda una llamada de descubrimiento con Ertas →

Ertas Data Suite se ejecuta completamente en tu infraestructura — sin egreso de datos durante la operación, sin llamadas de inferencia a la nube, y registro de cada paso de procesamiento con identidad del operador. Para organizaciones de salud donde el manejo de PHI no es negociable, la arquitectura on-premise es la base que hace la gobernanza de IA manejable.