Por qué 'tenemos un BAA' no equivale a cumplimiento HIPAA en IA

Hay una simplificación que circula en los equipos de tecnología sanitaria y que necesita ser corregida: la idea de que tener un Business Associate Agreement con tu proveedor de IA significa que tu aplicación cumple con HIPAA. No es así. Ni de lejos.

El BAA es un prerrequisito legal — uno de los cinco o seis elementos necesarios para alcanzar un cumplimiento real. Tratarlo como suficiente crea una postura de compliance frágil que puede derrumbarse por completo en una investigación de brecha.

Esto no solo afecta a empresas estadounidenses. Cualquier empresa española que opere con clientes de salud en EE.UU., gestione datos de pacientes americanos, o sea filial de una organización sanitaria norteamericana, está sujeta a HIPAA. Y en 2026, las aplicaciones de IA son el vector de riesgo que más atención regulatoria está recibiendo.

Qué es realmente un BAA (un contrato, no un control)

Un Business Associate Agreement es un contrato. Bajo 45 CFR § 164.308(b), las covered entities (proveedores de salud, planes de salud, clearinghouses) están obligadas a tener un BAA con cada business associate que crea, recibe, mantiene o transmite PHI en su nombre.

El BAA obliga contractualmente al business associate a:

• Usar el PHI solo para los fines especificados en el contrato
• Implementar las salvaguardas adecuadas
• Notificar brechas a la covered entity
• Devolver o destruir el PHI al terminar el contrato

Lo que el BAA no hace:

• Impedir que el PHI se transmita en primer lugar
• Especificar cómo los sistemas de inferencia del business associate manejan realmente los datos
• Garantizar la eliminación del PHI de contextos de modelos, logs o pipelines de entrenamiento
• Proteger frente a accesos no autorizados dentro de los sistemas del business associate
• Darte capacidad de auditoría técnica sobre la infraestructura del proveedor

El BAA hace de OpenAI (o cualquier otro proveedor de IA con el que firmes) tu business associate. No hace que la transferencia de datos sea segura. No hace que el procesamiento sea adecuado. Crea una relación legal — útil para responsabilidad y notificación de brechas, insuficiente para salvaguardas técnicas.

45 CFR § 164.312 — Las salvaguardas técnicas que debes implementar tú

Los requisitos de salvaguardas técnicas de la HIPAA Security Rule son donde la teoría choca con la realidad. La Sección 164.312 exige a las covered entities implementar:

Controles de acceso (§ 164.312(a)(1)): Identificación única de usuario, procedimiento de acceso de emergencia, cierre automático de sesión, cifrado/descifrado. Deben implementarse en tus sistemas, no delegarse mediante un BAA.

Controles de auditoría (§ 164.312(b)): Mecanismos hardware, software y procedimentales que registren y examinen la actividad en sistemas que contienen o usan ePHI. Si tu aplicación de LLM no genera audit logs con suficiente granularidad para reconstruir qué PHI fue accedido y por quién, estás fuera de cumplimiento — independientemente de tu BAA.

Controles de integridad (§ 164.312(c)): Protección frente a alteración o destrucción indebida del ePHI. En el contexto de IA, esto significa que el PHI que entra en un prompt debe llegar sin alterar al LLM, y necesitas una forma de verificarlo.

Seguridad en la transmisión (§ 164.312(e)(1)): Protección frente a acceso no autorizado al ePHI transmitido por redes electrónicas. TLS es necesario pero no suficiente — protege el canal de transmisión, no el contenido.

Un BAA no dice nada sobre ninguno de estos puntos en tu código.

Dónde filtra PHI aunque tengas un BAA

Puedes tener un BAA válido con cada proveedor de tu stack y aun así tener PHI filtrándose en múltiples puntos. Así ocurre:

Contenido del prompt: La vía más directa. Un chatbot de atención al paciente que recibe “Hola, soy el Dr. García, paciente Ana López (DNI 12345678A), diagnóstico código J45.40…” envía ese PHI textualmente a OpenAI en el momento en que se lanza la petición. Tu BAA está en algún PDF. Los datos de Ana López ya están en servidores de EE.UU.

Logs de inferencia: La mayoría de proveedores de LLM registran peticiones y respuestas por defecto, incluso con un BAA. El BAA puede restringir el tiempo de retención, pero los logs existen. ¿Quién en el proveedor tiene acceso? ¿En qué circunstancias? Estas preguntas importan bajo el estándar de “minimum necessary” de HIPAA, y tu BAA debería especificarlo — pero la mayoría no lo hace en detalle.

Embeddings: Si construyes un sistema RAG que embede registros de pacientes, la llamada a la API de embeddings transmite el texto en bruto. El vector resultante es opaco, pero la llamada a la API contenía PHI. Tu BAA cubre esto. Tu obligación de minimización de datos todavía pregunta si enviaste más de lo necesario.

Fine-tuning: Si entrenas un modelo con notas clínicas — incluso con un BAA vigente — necesitas garantías extraordinarias sobre segmentación de datos, retención y eliminación. El proceso estándar de fine-tuning de OpenAI no fue diseñado pensando en datos médicos. ¿Qué ocurre con esos datos después de que el job de fine-tuning termina? ¿Se usan para mejorar el modelo general?

Subprocesadores: ¿Tu proveedor de IA usa subprocesadores? La mayoría sí — proveedores cloud de GPU, servicios de monitorización, redes de inferencia distribuida. Tu BAA con OpenAI no crea automáticamente un BAA entre tú y cada empresa de su cadena de suministro.

Logs de tu propia aplicación: Tu propia infraestructura a menudo lo registra todo. El riesgo HIPAA no es solo el proveedor del modelo — son tu propio middleware de logging de peticiones/respuestas, los logs de acceso de tu CDN, tu balanceador de carga, tu servicio de rastreo de errores.

---

Este es exactamente el problema que Privedge fue construido para resolver. Privedge es un proxy de inferencia de IA que se sitúa entre tu aplicación y OpenAI (o cualquier proveedor de LLM). Antes de que un prompt llegue a la API, Privedge lo intercepta, tokeniza cada dato personal o PHI mediante anonimización reversible, y reenvía solo la versión anonimizada. La respuesta vuelve con los mismos tokens, que Privedge sustituye por los valores originales — en tu entorno, nunca en el suyo.

El cambio en tu código es de una sola línea:

// Antes — el PHI llega textualmente a OpenAI
const openai = new OpenAI({ apiKey: process.env.AI_KEY })

// Después — el PHI es interceptado antes de la transmisión
const openai = new OpenAI({
  apiKey: process.env.AI_KEY,
  baseURL: 'https://api.privedge.io/v1',
  defaultHeaders: { 'X-Privedge-Key': process.env.PRIVEDGE_KEY },
})

Tu código existente no cambia. Tus llamadas al SDK no cambian. Lo que cambia es que “Analiza los resultados de laboratorio de Ana López, NHC 48291” se convierte en “Analiza los resultados de laboratorio de [PERSONA_1], NHC [NHC_1]” antes de salir jamás de tu red.

---

El gap crítico: business associate vs. prevención técnica

La distinción que la mayoría de guías de compliance ignoran: firmar un BAA con OpenAI hace de OpenAI tu business associate. No impide que el PHI esté en los datos que les envías.

La Privacy Rule de HIPAA (45 CFR § 164.502) exige uso mínimo necesario. Se supone que debes enviar solo el PHI necesario para cumplir el propósito. En la práctica, con aplicaciones de LLM, el “propósito” es responder preguntas clínicas complejas — lo que a menudo sí requiere contexto. Pero ¿requiere el nombre real del paciente? ¿Su dirección? ¿Su número de seguro social? Casi nunca.

El estándar de minimum necessary no trata sobre lo que el modelo necesita. Trata sobre qué PHI tienes base legal para transmitir.

Cumplimiento práctico: lo que realmente necesitas

Una aplicación de IA genuinamente conforme con HIPAA en 2026 requiere:

1. Un BAA con cada servicio que toque ePHI — sí, incluyendo OpenAI
2. Controles técnicos que hagan cumplir el minimum necessary — anonimización o filtrado estricto de datos antes de la transmisión
3. Audit logging en tu lado — quién envió qué, cuándo, con qué propósito
4. Un mapa de flujo de datos — cada sistema que toca los datos, con controles documentados para cada salto
5. Procedimientos de respuesta a incidentes — qué ocurre cuando algo va mal

El BAA es el punto uno de una lista de cinco. Sin los puntos dos a cinco, el punto uno proporciona cobertura legal que no coincide con tu realidad técnica — y esa desconexión es donde viven las violaciones de HIPAA.

Conclusión

Un BAA es la condición mínima de entrada. Es obligatorio por ley, y absolutamente debes tenerlo. Pero en 2026, “tenemos un BAA” como respuesta completa a “¿cómo protegéis el PHI en vuestro sistema de IA?” no es aceptable — ni para los reguladores, ni para los compradores enterprise que realizan security reviews, ni para los pacientes cuyos datos gestionas.

Los controles técnicos son tu responsabilidad. La minimización de datos es tu responsabilidad. La decisión arquitectónica sobre qué PHI llega realmente al proveedor de LLM es tuya — y en 2026, la respuesta correcta es: el mínimo posible, idealmente ninguno.

Si estás desarrollando IA clínica y quieres el BAA más la prevención técnica, Privedge proporciona tanto la infraestructura de proxy como la documentación DPA para completar la historia de compliance.