O que um Business Associate Agreement realmente obriga o fornecedor a fazer
Um BAA assinado não é certificado de conformidade. O que ele compromete no seu fornecedor de software, o que não cobre e o que perguntar antes de assinar.
"Somos compatíveis com HIPAA" é uma frase sem significado jurídico. Não existe certificação HIPAA, não existe órgão emissor e não existe auditoria que produza um selo. O que existe é um conjunto de obrigações sob as regras de Privacidade, Segurança e Notificação de Violação, e um contrato que repassa parte delas aos fornecedores.
Esse contrato é o Business Associate Agreement. Se você está contratando software que vai tocar informação de saúde protegida, entender o que o BAA faz e não faz é mais útil do que qualquer página de conformidade de fornecedor.
Para que serve o BAA
Sob a HIPAA, a entidade coberta (um prestador, um plano de saúde, uma câmara de compensação) continua responsável pela informação de saúde protegida mesmo quando um fornecedor a manipula. O BAA é o instrumento que torna o fornecedor diretamente responsável por um conjunto definido de obrigações, em vez de deixar toda a exposição com a entidade coberta.
Na prática ele compromete o business associate com cinco coisas:
- Usar e divulgar a informação apenas como o contrato permite. Não para fins próprios, não para melhorar o produto, não para treinar modelo, a menos que o contrato diga isso explicitamente.
- Aplicar as salvaguardas da Regra de Segurança. Administrativas, físicas e técnicas. O fornecedor fica diretamente sujeito a elas, não apenas prometendo por contrato.
- Reportar violações e incidentes de segurança. Dentro de uma janela definida, que é um termo negociado e merece leitura atenta.
- Repassar as obrigações aos subcontratados. Quem quer que o fornecedor use e toque a informação precisa de um contrato equivalente. É aqui que a corrente costuma arrebentar.
- Devolver ou destruir a informação ao término. Com processo documentado, não com promessa.
O que ele não faz
Um BAA não é prova de que qualquer coisa disso é verdade. É um contrato que cria responsabilidade caso não seja.
Especificamente, um BAA assinado não diz:
- Se as salvaguardas estão de fato implementadas. Para isso servem uma avaliação independente, um relatório SOC 2 ou uma revisão técnica.
- Onde o dado mora. Residência de dados é negociação separada. Se os backups saem do país, também.
- Quem no fornecedor consegue ver. A Regra de Segurança exige controle de acesso; o BAA não enumera quais. Pergunte.
- O que acontece com dado derivado. Estatísticas agregadas, embeddings, ajustes finos de modelo e logs de auditoria derivados da informação protegida são uma lacuna real em muitos contratos. Se dá para reidentificar, ainda é informação protegida.
Esse último ponto ficou muito mais importante com IA no meio da pilha. Um provedor de modelo que retém prompts para monitorar abuso está retendo informação protegida, e precisa estar sob BAA como qualquer outro subcontratado. Nossa posição sobre isso está escrita na política de IA.
Perguntas que valem a pena antes de assinar
Estas produzem respostas úteis, e não tranquilizadoras.
| Pergunta | Como soa uma boa resposta |
|---|---|
| Quais subcontratados tocam a informação? | Uma lista nomeada, com BAAs arquivados e disponíveis |
| Qual é a janela de notificação de violação? | Um número específico de dias, e quem é notificado |
| Quem no seu time acessa dado de produção? | Um papel nomeado, acesso por tempo limitado e registrado |
| A informação é cifrada em repouso e em trânsito? | Sim, com o mecanismo nomeado, incluindo backups |
| Como é a devolução ao encerrar? | Um formato, um prazo e um certificado de destruição |
| Alguma informação é usada para melhorar o produto? | Não, sem qualificação, ou uma exceção específica e estreita |
Para times de engenharia: o que muda na construção
Se informação protegida está no escopo, o contrato muda a arquitetura, não só a papelada. As especificidades estão nas salvaguardas técnicas, mas três consequências aparecem em todo projeto:
Log de auditoria vira funcionalidade, não lembrança tardia. Você precisa conseguir responder quem acessou qual registro e quando, e reter essa resposta.
Todo serviço de terceiro vira uma decisão. Rastreadores de erro, analytics, gravação de sessão e agregadores de log capturam alegremente o que estiver na tela. Cada um precisa estar sob BAA ou receber dado já higienizado.
O mínimo necessário molda o modelo de dados. A regra não é "cifre tudo". É que cada papel só alcance a informação necessária à sua função, o que é uma questão de esquema e permissões a resolver cedo.
Encaixar isso depois num sistema em funcionamento é uma das formas mais caras de descobrir um requisito, e é por isso que conformidade pesa tanto em o que move o custo de software sob medida.
Aceitamos projetos HIPAA sob BAA assinado, e como tratamos acesso, log e subcontratados está nas nossas práticas de segurança.