O que a HIPAA exige de um sistema telefônico
Um paciente divulga informações de saúde protegidas no momento em que dá um nome e um motivo para a ligação. Isso coloca o serviço de atendimento dentro da regulamentação, como business associate, e daí decorrem quatro obrigações.
Um BAA assinado é o primeiro e o que as pessoas pulam. Depois, a criptografia dos dados em trânsito e em repouso — o áudio, a transcrição e tudo o que for gravado nos seus sistemas. Depois, o controle de acesso com trilha de auditoria, para que você possa dizer quem leu determinado registro. Depois, uma política de retenção com um mecanismo por trás, porque uma política declarada sem uma rotina de exclusão é uma declaração de intenção.
Duas coisas que a HIPAA não exige, mas que fornecedores costumam sugerir que sim: um relatório SOC 2 e qualquer certificação específica. São evidências úteis de boa prática geral de segurança, mas não são a regulamentação.
O BAA e quem o assina
A entidade coberta — sua clínica — assina com cada business associate que toca em PHI. Isso inclui o serviço de atendimento e inclui qualquer um a quem o serviço de atendimento repassa os dados, que é o elo em que a maioria das avaliações para de seguir a cadeia. Um agente de IA tem um provedor de modelo por trás, e o comportamento de retenção dele faz parte da sua exposição, apareça ou não no seu contrato.
A Finn assina BAAs para contratos empresariais que processam PHI, por contrato e não como cláusula geral em todos os planos, solicitados pelo trust centre. Assine antes que qualquer dado de paciente circule. Um BAA acordado depois não cobre retroativamente o que já aconteceu.
Vale deixar claro onde fica a linha: o fornecedor é responsável pelos controles da plataforma, e você continua responsável pelo que faz com ela — quais chamadas você faz, com que fundamento, para quem. Essa divisão está descrita no guia de consentimento e aspectos legais, e nenhum fornecedor pode assumir essa metade por você.
PHI em transcrições e gravações
É aqui que os serviços de atendimento com IA diferem materialmente dos humanos, e onde a avaliação deve se concentrar. Um serviço humano produz uma mensagem: uma nota curta e curada que alguém digitou. Um serviço de IA produz uma transcrição literal de tudo o que o paciente disse, mais o áudio, mais quaisquer dados estruturados que foram extraídos — várias cópias do mesmo PHI em sistemas diferentes, cada uma com seu próprio comportamento de retenção.
Mais dados não é automaticamente pior; uma transcrição é genuinamente mais útil e mais auditável que uma paráfrase. Mas é mais superfície de exposição, e deve ser tratada como tal. A Finn criptografa gravações, transcrições e PII com AES-256 em repouso e TLS 1.3 em trânsito por padrão, e pode redigir automaticamente números de cartão, CPFs e IDs de conta das transcrições, com padrões personalizados para o que for específico da sua organização — de modo que algumas categorias nunca chegam a persistir em forma legível.
A camada do modelo é a parte que a maioria das análises deixa passar. A Finn não treina com dados de clientes e usa APIs de modelo com retenção zero, o que significa que o áudio não fica retido pelo provedor do modelo após a ligação. Faça essa pergunta especificamente a todo fornecedor, porque "não treinamos com seus dados" e "nossos subprocessadores não os retêm" são duas afirmações diferentes, e normalmente só uma delas é feita.
Retenção e controle de acesso
O controle de acesso vale apenas o que você consegue provar. A Finn registra cada acesso a dados em um log de auditoria imutável e exportável, junto com chamadas de API e mudanças de configuração, que é o artefato que importa em uma investigação — a pergunta nunca é "vocês têm controles de acesso", e sim "mostre quem abriu este registro".
Sobre certificações, sem rodeios: a Finn possui ISO/IEC 27001:2022 e ISO/IEC 20000-1:2018. A Finn não tem atestação SOC 2 hoje — uma auditoria está em andamento com a A-LIGN e o relatório é esperado para agosto de 2026. Isso está dito aqui pelo mesmo motivo que esta página existe: um guia que manda você questionar as afirmações dos fornecedores não pode ser vago sobre as próprias.
Checklist
Seis perguntas para fazer a qualquer fornecedor, inclusive a Finn. As respostas revelam mais do que a página de conformidade.
- 1
Vocês assinam um BAA, e em qual plano?
Se a resposta envolve um upgrade, isso é preço, não postura de conformidade. Peça o tier por escrito.
- 2
O que exatamente é criptografado, e onde ficam as chaves?
"Criptografado" sem complemento não é resposta. Pergunte sobre áudio, transcrições, backups e logs separadamente.
- 3
Por quanto tempo as gravações e transcrições ficam armazenadas, e o que as apaga?
Uma política de retenção sem mecanismo de exclusão é uma declaração de intenção.
- 4
Seus provedores de modelo retêm ou treinam com o áudio?
Os subprocessadores do seu fornecedor são a sua exposição. Pergunte especificamente sobre a camada do modelo, não apenas sobre a plataforma.
- 5
Vocês conseguem gerar um log de acesso para um registro específico?
O teste é se eles conseguem mostrar quem leu uma determinada transcrição, não se o registro de logs existe em princípio.
- 6
Quais certificações vocês têm hoje, e quais estão em andamento?
"Em andamento" é aceitável e comum. "Compliant" usado para dar a entender uma auditoria que ninguém concluiu, não.
