Claude y HIPAA: qué cubre (y qué no) un BAA con un proveedor de IA

Aviso: este artículo explica el marco general de HIPAA aplicado al uso de Claude. No es asesoramiento jurídico ni una calificación de tu caso. Cualquier decisión sobre las obligaciones HIPAA de tu organización corresponde a tu equipo de compliance y asesoría legal.

Según la documentación publicada por Anthropic, existe un Business Associate Agreement disponible para la API de Claude en configuraciones HIPAA-ready. Para los equipos de salud que evalúan Claude para IA clínica, es un dato relevante — y es fácil malinterpretar lo que implica realmente para el cumplimiento normativo.

La versión corta: un BAA es necesario y no es suficiente. Aquí está la distinción que importa.

Qué dice la documentación de Anthropic que cubre el BAA

Cuando firmas un BAA con Anthropic y accedes a Claude a través de una configuración HIPAA-ready, Anthropic se convierte en tu business associate bajo HIPAA. Esto crea obligaciones contractuales: deben manejar el PHI conforme a la normativa, notificar brechas y restringir el uso a los fines especificados en el acuerdo.

Según la guía de Anthropic, los modelos cubiertos retienen datos durante un periodo definido en la plataforma, descrito históricamente como unos 30 días — este tipo de dato cambia con el tiempo y debe reverificarse, no darse por sentado. Sea cual sea la cifra vigente, el punto es el mismo: el BAA rige qué puede hacer el proveedor con esos datos, pero los datos están presentes en sus sistemas durante esa ventana.

Un detalle que conviene leer con atención: según la documentación publicada por Anthropic, el zero data retention (ZDR) y la cobertura BAA tiran en direcciones opuestas — y la restricción funciona en ambos sentidos según el producto.

Los Covered Models exigen una ventana de retención y no están disponibles con ZDR activado. Pero hay servicios que funcionan al revés: Claude Code queda cubierto por el BAA solo cuando el ZDR está activado, lo que a su vez impide usar Covered Models bajo ese BAA.

Así que no es simplemente “ZDR o BAA, elige uno”. Es una restricción que depende del producto, y entenderla al revés significa dar por cubierto algo que no lo está. Conviene comprobar de qué lado cae tu configuración concreta.

Lo que un BAA no cubre

Un BAA es un contrato entre tú y el proveedor. No:

• Impide la transmisión de PHI — los nombres de pacientes, diagnósticos e identificadores en tus prompts viajan a la infraestructura del proveedor, con o sin BAA
• Implementa salvaguardas técnicas por ti — la Security Rule de HIPAA exige controles de acceso, registros de auditoría y seguridad en la transmisión. Son tu responsabilidad
• Aplica a la lógica de tu aplicación — si tu código registra prompts, los almacena en una base de datos o los reenvía a otro servicio, el BAA es irrelevante para esos flujos
• Cubre automáticamente a subprocesadores — la mayoría de proveedores usan sus propios proveedores de infraestructura, y un BAA no se extiende automáticamente a cada sistema de esa cadena — verifícalo específicamente en lugar de asumir cobertura

El estándar de mínimo necesario sigue aplicando. Incluso con un BAA, HIPAA te exige pensar cuidadosamente en qué PHI necesita realmente estar en el prompt y si tienes legitimidad legal para transmitir cada dato.

La tensión ZDR

Si esa incompatibilidad ZDR/BAA es exacta para tu configuración, aquí está la tensión que crea para los equipos con más conciencia de seguridad: la postura de máxima minimización de datos (ZDR) puede ser incompatible con la cobertura BAA. Podrías tener efectivamente una u otra, no ambas.

Esto no es necesariamente una crítica a ningún proveedor en particular — puede reflejar una restricción arquitectónica real, ya que ofrecer notificación de brechas respaldada por BAA típicamente requiere retener datos el tiempo suficiente para investigar un incidente. Pero significa que los equipos que quieren máxima privacidad y cobertura BAA pueden necesitar un enfoque arquitectónico diferente.

La alternativa: prevenir antes de transmitir

El enfoque más robusto no depende del proveedor que uses ni de si tiene un BAA. Opera en la capa arquitectónica: el PHI se tokeniza antes de que el prompt salga de tu red.

Cuando tu aplicación enruta a través de un proxy de inferencia que aplica seudonimización reversible en el edge:

• Nombres → [PERSON_1]
• Números de historial médico → [MRN_1]
• SSNs → [SSN_1]
• Diagnósticos vinculados a individuos → [CONDITION_1]

El modelo — Claude, GPT, o cualquier otro — recibe tokens anonimizados. Razona sobre la estructura. Tu sistema reinserta los valores reales en el camino de vuelta, en tu infraestructura, antes de que el usuario vea el resultado.

El resultado: Anthropic (o cualquier proveedor) nunca recibe PHI identificable. Sea cual sea la ventana de retención que aplique, retiene tokens, no datos de pacientes. La tensión ZDR/BAA desaparece, porque no hay PHI que retener.

El BAA sigue siendo importante — es un requisito legal y proporciona cobertura para la notificación de brechas. Pero se convierte en una salvaguarda secundaria sobre un sistema donde la filtración de PHI está arquitectónicamente prevenida, no en el mecanismo principal de cumplimiento.

---

Este es el principio detrás de Privedge: un reemplazo drop-in de una sola línea para cualquier SDK de LLM que tokeniza el PHI en el edge de Cloudflare antes de cualquier llamada a API externa. Claude, OpenAI, Gemini — el estado BAA del proveedor pierde relevancia cuando los datos identificables nunca les llegan.

// Antes — el PHI llega a Claude en bruto
import Anthropic from '@anthropic-ai/sdk'
const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_KEY })

// Después — PHI anonimizado en el edge antes de la transmisión
import Privedge from '@privedge/sdk'
const ai = new Privedge({
  apiKey:    process.env.PRIVEDGE_KEY,
  workerUrl: 'https://edge.privedge.io',
})

const res = await ai.chat.completions.create({
  model:        'claude-sonnet-4-6',
  messages:     [{ role: 'user', content: prompt }],
  pii_strategy: 'anonymize',
})

Tu código existente no cambia. Lo que cambia es que "Resume el plan de tratamiento de John Smith (SSN 123-45-6789)" se convierte en "Resume el plan de tratamiento de [PERSON_1] (SSN [SSN_1])" antes de llegar a cualquier proveedor — tenga BAA o no.

---

Qué significa esto en la práctica

Si estás evaluando Claude para IA sanitaria, el marco correcto no es “¿tiene Anthropic un BAA?”. Es:

1. ¿Qué PHI necesita realmente llegar al modelo? En la mayoría de casos de uso de IA clínica, el modelo necesita contexto clínico — no identificadores de pacientes. Son separables.
2. ¿Qué pasa con los datos que sí llegan al modelo? Con un BAA, el proveedor los retiene durante la ventana que especifiquen sus condiciones vigentes. Con ZDR, puede que no puedas usar los modelos cubiertos por BAA. Con un proxy arquitectónico, no hay datos identificables que retener.
3. ¿Cuáles son tus obligaciones de traza de auditoría? HIPAA exige que puedas demostrar qué PHI fue accedido y por quién. Un proxy de inferencia que registra metadatos (no el contenido del prompt) proporciona esto sin retener datos clínicos.

Un BAA de cualquier proveedor, incluido Anthropic, es un paso en la dirección correcta para el ecosistema de IA sanitaria. También es un recordatorio de que la parte difícil del cumplimiento HIPAA no es encontrar un proveedor que firme un BAA — es construir una aplicación donde los datos correctos lleguen al sistema correcto, y nada más.

Si quieres un enfoque arquitectónico de HIPAA que funcione con Claude, GPT, o cualquier modelo futuro — sin que tu postura de cumplimiento dependa de las condiciones BAA vigentes de un proveedor concreto — Privedge es el punto de partida.