← Resources
USECASE · 2026-03-12
IA privada para sanidad: workspaces alineados con HIPAA sin bloqueo en la nube
La IA alineada con HIPAA no requiere enviar PHI a un modelo de terceros. Un workspace que prioriza la ejecución en el dispositivo con fallback opcional BYOK en la nube, logs de auditoría, RBAC y un BAA firmado cuando se toque cualquier nube puede satisfacer la mayoría de los requisitos de las entidades cubiertas.
Lo que HIPAA realmente exige de un asistente de IA
*Este artículo es una orientación general y no constituye asesoramiento legal ni de cumplimiento; el responsable de privacidad de tu entidad cubierta tiene la última palabra.*
HIPAA se redactó en torno a los datos, no a la herramienta que los lee, así que un asistente de IA se trata como cualquier otro miembro de la plantilla o socio de negocio que toca información sanitaria protegida. La Privacy Rule rige los usos y divulgaciones permitidos de PHI y el estándar de mínimo necesario. La Security Rule exige salvaguardas administrativas, físicas y técnicas, incluyendo control de acceso, controles de auditoría, integridad, seguridad de transmisión y un análisis de riesgos documentado. La Breach Notification Rule establece el deber de notificar a las personas afectadas, a HHS y, en incidentes mayores, a los medios cuando se divulgue PHI no asegurada sin autorización.
La normativa reciente de HHS ha señalado que los sistemas de IA que crean, reciben, mantienen o transmiten ePHI deben inventariarse y someterse a análisis de riesgos como cualquier otro activo, con cifrado en tránsito y en reposo, autenticación multifactor y respuesta a incidentes oportuna. La obligación no cambia porque la entidad que lee el historial sea un modelo.
Dónde se quedan cortos ChatGPT, Copilot y Gemini para PHI
De fábrica, los niveles de consumidor de ChatGPT, Microsoft Copilot y Google Gemini no son apropiados para PHI. Las suscripciones gratuitas y estándar no vienen con un BAA, y los prompts pueden retenerse o utilizarse para mejorar el modelo bajo los términos predeterminados.
El matiz que conviene tener claro: cada proveedor ofrece configuraciones empresariales que pueden incluirse bajo un BAA. OpenAI firma BAA para la API y para ChatGPT Enterprise o Edu a través de cuentas gestionadas por ventas. Microsoft ofrece cobertura BAA para Azure OpenAI Service y ciertos tenants de Microsoft 365 Copilot, aunque GitHub Copilot y otras superficies de consumidor quedan excluidas. Google soporta un BAA para Gemini dentro de los niveles de Workspace que lo permiten, pero excluye explícitamente NotebookLM y la superficie de Gemini en Chrome.
El riesgo práctico es la deriva de la plantilla. Un clínico que pega un resumen de alta en una pestaña de chatbot gratuita en un navegador es, por defecto, una divulgación fuera de cualquier BAA, independientemente de lo que diga el contrato empresarial.
La arquitectura on-device-first: modelo local + BYOK opcional
Una arquitectura que minimiza la exposición HIPAA invierte el patrón SaaS habitual. El modelo predeterminado se ejecuta en el dispositivo del usuario, normalmente un LLM open-weights cuantizado servido localmente, de modo que los prompts y las generaciones nunca abandonan el endpoint. Cuando un clínico necesita un modelo de razonamiento más fuerte, el workspace puede recurrir a un proveedor cloud usando la clave API propia de la organización, bajo el BAA de ese proveedor, con un opt-in explícito por petición o por workspace.
Este es el patrón que hay detrás de osFoundry: un runtime local de llama.cpp es el predeterminado de primera clase, y cualquier llamada cloud es bring-your-own-key contra un proveedor que la entidad cubierta ha contratado de forma independiente. No hay un pool de inferencia multi-tenant compartido entre el clínico y el modelo.
El beneficio de cumplimiento es concreto. Las cargas que pueden manejarse localmente nunca generan un evento de divulgación cloud. Las que requieren capacidad cloud son rastreables, atribuibles y están sujetas al BAA que la entidad cubierta ya validó.
Auditoría, RBAC, DLP y mínimo necesario en la práctica
Las salvaguardas técnicas son donde la mayoría de los pilotos de IA fallan su primera auditoría interna. Cuatro controles hacen el trabajo pesado.
Los logs de auditoría deben capturar quién emitió el prompt, qué modelo respondió, qué fuentes de datos se adjuntaron y qué se devolvió, con almacenamiento a prueba de manipulación y una ventana de retención que coincida con tu política de retención de registros. RBAC debe vincular el acceso al modelo, a los datasets y a las herramientas con el rol del puesto, de modo que una cuenta de recepción no pueda consultar un corpus de oncología y un rol de facturación no pueda activar un generador de notas clínicas.
DLP pertenece al límite del prompt. La redacción basada en patrones y clasificadores de identificadores antes de cualquier llamada cloud aplica el estándar de mínimo necesario de forma programática en lugar de únicamente mediante formación. La residencia de datos por workspace evita que los datos de una consulta se mezclen con los de otra.
Nada de esto es una invención específica de IA, pero juntos son lo que permite a un responsable de privacidad firmar la aprobación de un modelo que toca un historial.
Tres flujos: notas de admisión, autorización previa, Q&A de operaciones
Las notas de admisión y de visita son la carga local de mayor valor. Un clínico dicta, un modelo local redacta una nota estructurada y nada sale del dispositivo hasta que el clínico firma y el EHR recibe un registro publicado a través de su interfaz existente. La latencia es aceptable en un portátil moderno y la superficie de PHI es solo el dispositivo.
La autorización previa se beneficia de la recuperación. El modelo ensambla una carta borrador a partir del historial del paciente y los documentos de política médica publicados por el pagador, con citas. Si se invoca un modelo cloud más fuerte para la redacción, el extracto del historial se desidentifica en el límite del prompt y se vuelve a identificar en el dispositivo después de que regrese la respuesta.
La Q&A operativa sobre política de RR. HH., códigos de facturación y SOPs rara vez necesita PHI en absoluto y puede ejecutarse completamente en modelos locales o cloud con DLP bloqueando PHI en su sitio. Dividir las cargas de esta forma mantiene el tráfico de mayor riesgo en el dispositivo y el de menor riesgo en la nube.
BAA y riesgo de proveedor: qué preguntar a cualquier vendor de IA
Antes de firmar, recorre una lista corta. ¿El proveedor ejecutará un BAA que cubra la superficie exacta del producto que vas a usar, no un producto hermano? ¿Qué endpoints, modelos y consolas específicas están dentro del alcance, y cuáles quedan excluidos por escrito? ¿Cuál es la retención de datos por defecto para prompts, respuestas, embeddings y artefactos de fine-tuning, y puede establecerse en cero?
Pide la lista de subprocesadores y el mecanismo de notificación cuando cambie. Confirma cifrado en tránsito y en reposo, postura de gestión de claves y si las claves gestionadas por el cliente están disponibles. Exige plazos de notificación de incidentes que te permitan cumplir con tu propio plazo de 60 días para notificar a los pacientes con margen.
Solicita el SOC 2 Type II más reciente y cualquier atestación HITRUST, la cadencia de pentesting y el runbook de respuesta a incidentes. Por último, confirma por escrito que el proveedor no entrenará modelos compartidos con los datos de tu tenant.
Despliegue piloto en 30 días
La semana uno es de alcance. El responsable de privacidad, un patrocinador clínico y TI eligen dos o tres flujos, escriben el diagrama de flujo de datos y actualizan el análisis de riesgos. Identifica qué pasos pueden ser solo locales y cuáles requieren cloud, y confirma la cobertura BAA para cualquier superficie cloud.
La semana dos es de aprovisionamiento. Levanta el workspace con roles RBAC mapeados a los puestos, activa el logging de auditoría hacia tu SIEM, configura reglas de redacción DLP en el límite del prompt y carga el modelo local en los dispositivos del piloto. Documenta el plan de rollback.
La semana tres es un piloto supervisado con cinco a diez clínicos. Registra el tiempo ahorrado, la tasa de error frente a un conjunto gold revisado por humanos y cualquier disparo de DLP. Mantén una revisión a media semana con el responsable de privacidad.
La semana cuatro es la decisión de seguir o no. Actualiza los materiales de política y formación, finaliza la divulgación de uso de IA a los pacientes cuando aplique y decide los criterios de expansión para la siguiente cohorte.
Frequently asked questions
- ¿Ejecutar un modelo en el dispositivo elimina la necesidad de un BAA por completo?
- Para la propia inferencia local, sí, porque no se divulga PHI a un tercero. Aun así debes tener en cuenta el papel del proveedor de software. Si el runtime local, el shell del workspace o cualquier plano de gestión pudiera recibir PHI a través de telemetría, logs o sesiones de soporte, el proveedor actúa como socio de negocio y un BAA es apropiado. El patrón seguro es confirmar por escrito que el proveedor no recibe PHI del dispositivo por defecto y deshabilitar cualquier telemetría opcional que pudiera transportar contenido. Los fallbacks cloud siempre requieren un BAA con el proveedor del modelo cloud.
- ¿Podemos usar ChatGPT, Copilot o Gemini en un flujo HIPAA en absoluto?
- Sí, pero solo en las configuraciones empresariales específicas que el proveedor ha acordado cubrir bajo un BAA, y solo para las superficies nombradas explícitamente en ese acuerdo. OpenAI cubre la API y ciertos tenants de ChatGPT Enterprise o Edu. Microsoft cubre Azure OpenAI Service y los tenants de Copilot que califican. Google cubre Gemini en los niveles de Workspace que califican mientras excluye NotebookLM y Gemini en Chrome. Los niveles gratuitos y estándar de consumidor no están cubiertos. El problema más difícil es el comportamiento de la plantilla: bloquear las superficies de consumidor en la capa de red o de navegador importa tanto como el contrato.
- ¿En qué se diferencian los logs de auditoría para IA frente al acceso tradicional al EHR?
- Los logs de auditoría tradicionales del EHR capturan el acceso a registros por usuario, tiempo y acción. Los logs de auditoría de IA necesitan capturar el prompt, el modelo y la versión, el contexto recuperado, la respuesta, el usuario, el workspace y cualquier herramienta que el modelo haya invocado. También necesitan capturar las decisiones de enrutamiento cloud cuando se usa un fallback BYOK. Retenlos junto a los logs del EHR bajo la misma política de retención, almacénalos en un store a prueba de manipulación y aliméntalos en el mismo SIEM que tu equipo de seguridad ya monitoriza para que la actividad de IA forme parte de la respuesta normal a incidentes en lugar de ser un silo paralelo.
- ¿Y los nuevos cambios de la Security Rule de 2026?
- La normativa reciente de HHS mueve varias salvaguardas previamente abordables a la categoría de requeridas, con un énfasis más fuerte en cifrado, autenticación multifactor, inventario de activos que incluya sistemas de IA que manejan ePHI y plazos más estrictos de reporte de incidentes. Trata cualquier asistente de IA como un activo dentro del alcance del análisis de riesgos, documenta los flujos de datos y confirma que tu runbook de respuesta a incidentes puede cumplir con las ventanas de notificación más cortas. Coordínate con tu responsable de privacidad sobre las fechas de entrada en vigor exactas y las expectativas de transición aplicables a tu organización, ya que la postura de aplicación y cualquier extensión pueden cambiar tras la publicación.
Sources