Claude ya tiene cobertura BAA. Esto es lo que eso no cubre.

Anthropic publicó recientemente la lista de modelos Claude cubiertos bajo un Business Associate Agreement (BAA). Para los equipos de salud que evalúan Claude para IA clínica, es una noticia relevante — y es fácil malinterpretar lo que implica realmente para el cumplimiento normativo.

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

Qué cubre realmente el BAA de Anthropic

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 45 CFR § 164.308(b). Esto crea obligaciones contractuales: deben manejar el PHI conforme a HIPAA, notificar brechas y restringir el uso a los fines especificados en el acuerdo.

Los modelos cubiertos requieren 30 días de retención de datos en la plataforma. Vale la pena subrayarlo: Anthropic retiene los datos de las peticiones durante 30 días. El BAA rige qué pueden hacer con esos datos — pero los datos están ahí.

Un detalle específico de la guía de Anthropic: las configuraciones de zero data retention (ZDR) no pueden acceder a los modelos Claude cubiertos por BAA. Esto crea una elección forzada. Si quieres máximo control sobre la retención (ZDR), no puedes usar la API cubierta por BAA. Si quieres cobertura BAA, aceptas 30 días de retención.

Lo que el BAA no cubre

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

• Impide la transmisión de PHI — los nombres de pacientes, diagnósticos e identificadores en tus prompts viajan a la infraestructura de Anthropic, con o sin BAA
• Implementa salvaguardas técnicas por ti — la Security Rule de HIPAA (§164.312) 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 — Anthropic usa sus propios proveedores de infraestructura; tu BAA no se extiende automáticamente a cada sistema de su cadena

El estándar de mínimo necesario (45 CFR § 164.502(b)) 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 paradoja ZDR

Aquí está la tensión que esto crea para los equipos con más conciencia de seguridad: la postura de máxima minimización de datos (ZDR) es explícitamente incompatible con la cobertura BAA. Puedes tener una o la otra.

Esto no es una crítica a Anthropic — refleja una restricción arquitectónica real. Proporcionar garantías de cumplimiento BAA requiere retener datos el tiempo suficiente para cumplir las obligaciones de notificación de brechas. Pero significa que los equipos que quieren máxima privacidad y cobertura BAA necesitan 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. La política de retención de 30 días retiene tokens, no datos de pacientes. La paradoja ZDR 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 en 2026, 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, Anthropic los retiene 30 días. Con ZDR, no puedes usar los modelos cubiertos. 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.

El BAA de 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 cumplimiento HIPAA arquitectónico que funcione con Claude, GPT, o cualquier modelo futuro — sin depender del estado BAA de ningún proveedor — Privedge es el punto de partida.