Qué obliga realmente un Business Associate Agreement al proveedor
Un BAA firmado no es un certificado de cumplimiento. A qué compromete a tu proveedor de software, qué no cubre y qué preguntar antes de firmarlo.
"Cumplimos con HIPAA" es una frase sin significado jurídico. No existe una certificación HIPAA, ni un organismo emisor, ni una auditoría que produzca un sello. Lo que existe es un conjunto de obligaciones bajo las reglas de Privacidad, Seguridad y Notificación de Brechas, y un contrato que traslada parte de ellas a los proveedores.
Ese contrato es el Business Associate Agreement. Si estás comprando software que va a tocar información de salud protegida, entender qué hace y qué no hace el BAA es más útil que cualquier página de cumplimiento de un proveedor.
Para qué sirve el BAA
Bajo HIPAA, la entidad cubierta (un prestador, un plan de salud, una cámara de compensación) sigue siendo responsable de la información de salud protegida incluso cuando la maneja un proveedor. El BAA es el instrumento que hace al proveedor directamente responsable de un conjunto definido de obligaciones, en lugar de dejar toda la exposición en la entidad cubierta.
En la práctica compromete al business associate con cinco cosas:
- Usar y divulgar la información solo como el contrato permite. No para fines propios, no para mejorar su producto, no para entrenar un modelo, salvo que el contrato lo diga explícitamente.
- Aplicar las salvaguardas de la Regla de Seguridad. Administrativas, físicas y técnicas. El proveedor queda directamente sujeto a ellas, no solo prometiéndolas por contrato.
- Reportar brechas e incidentes de seguridad. Dentro de una ventana definida, que es un término negociado y merece leerse con atención.
- Trasladar las obligaciones a los subcontratistas. Cualquiera que el proveedor use y toque la información necesita un acuerdo equivalente. Aquí es donde la cadena se rompe más seguido.
- Devolver o destruir la información al terminar. Con un proceso documentado, no con una promesa.
Qué no hace
Un BAA no es prueba de que nada de eso sea cierto. Es un contrato que crea responsabilidad si no lo es.
En concreto, un BAA firmado no te dice:
- Si las salvaguardas están realmente implementadas. Para eso sirven una evaluación independiente, un informe SOC 2 o una revisión técnica.
- Dónde viven los datos. La residencia de datos es una negociación aparte. Si los respaldos salen del país, también.
- Quién dentro del proveedor puede verlos. La Regla de Seguridad exige controles de acceso; el BAA no los enumera. Pregunta.
- Qué pasa con los datos derivados. Estadísticas agregadas, embeddings, ajustes de modelo y registros de auditoría derivados de la información protegida son una brecha real en muchos acuerdos. Si se puede reidentificar, sigue siendo información protegida.
Ese último punto se volvió mucho más importante con IA en la pila. Un proveedor de modelos que retiene prompts para monitorear abusos está reteniendo información protegida, y necesita estar bajo BAA como cualquier otro subcontratista. Nuestra posición está escrita en la política de IA.
Preguntas que vale hacer antes de firmar
Estas producen respuestas útiles, no tranquilizadoras.
| Pregunta | Cómo suena una buena respuesta |
|---|---|
| ¿Qué subcontratistas tocan la información? | Una lista con nombres, con BAAs archivados y disponibles |
| ¿Cuál es tu ventana de notificación de brechas? | Un número concreto de días, y a quién se notifica |
| ¿Quién de tu equipo accede a datos de producción? | Un rol con nombre, acceso por tiempo limitado y registrado |
| ¿La información se cifra en reposo y en tránsito? | Sí, con el mecanismo nombrado, incluidos los respaldos |
| ¿Cómo es la devolución al terminar? | Un formato, un plazo y un certificado de destrucción |
| ¿Se usa alguna información para mejorar tu producto? | No, sin matices, o una excepción concreta y estrecha |
Para equipos de ingeniería: qué cambia en la construcción
Si hay información protegida en el alcance, el acuerdo cambia la arquitectura, no solo el papeleo. Los detalles están en las salvaguardas técnicas, pero tres consecuencias aparecen en todos los proyectos:
El registro de auditoría se vuelve una funcionalidad, no un añadido. Tienes que poder responder quién accedió a qué registro y cuándo, y conservar esa respuesta.
Cada servicio de terceros se vuelve una decisión. Rastreadores de errores, analítica, grabación de sesión y agregadores de logs capturan alegremente lo que esté en pantalla. Cada uno necesita estar bajo BAA o recibir datos ya depurados.
El mínimo necesario moldea el modelo de datos. La regla no es "cifra todo". Es que cada rol solo alcance la información que su función necesita, lo cual es una cuestión de esquema y permisos que conviene resolver temprano.
Encajar esto después en un sistema en funcionamiento es una de las formas más caras de descubrir un requisito, y por eso el cumplimiento pesa tanto en lo que mueve el costo del software a medida.
Tomamos proyectos HIPAA bajo BAA firmado, y cómo manejamos acceso, registro y subcontratistas está en nuestras prácticas de seguridad.