Agentes de IA na saúde e LGPD: como proteger o dado do beneficiário e do paciente.

Numa operadora de saúde, num hospital ou numa clínica, a conversa sobre IA e LGPD começa um degrau acima da de outros setores. Quase tudo o que um agente toca no atendimento é dado de saúde: o procedimento pedido, a especialidade buscada, o prestador escolhido, o recibo enviado para reembolso. E dado de saúde é dado pessoal sensível, com regras próprias na Lei 13.709/2018.

Este guia responde a duas perguntas que chegam juntas: o que a LGPD exige de quem usa agentes de IA com dado de saúde, e como o agente protege esse dado na prática. O que vale para qualquer setor está no guia geral de governança de IA e LGPD. Aqui fica só o que muda quando o dado é de saúde.

Isto é um guia de engenharia e de decisão, não parecer jurídico. A base legal de cada fluxo e a avaliação de risco são análise do seu jurídico e do seu encarregado de dados. As normas setoriais da saúde suplementar e dos conselhos profissionais também se aplicam e não são tratadas aqui.

O que muda quando o dado é de saúde

A LGPD lista o "dado referente à saúde" entre os dados pessoais sensíveis (art. 5º, II). E o art. 11, § 1º, estende o mesmo regime a qualquer tratamento que revele dado sensível e possa causar dano ao titular. Na prática, isso alcança a inferência: um agendamento com oncologista, uma guia de hemodiálise ou o reembolso de uma consulta psiquiátrica revelam condição de saúde sem que exista um campo chamado diagnóstico.

A regra prática para quem desenha o agente: numa operação de saúde, trate quase todo o contexto do atendimento como sensível, e não só o prontuário. Disso saem duas consequências que outros setores não têm, além da base legal, que ganha seção própria logo abaixo.

As vedações dirigidas ao setor

O art. 11, § 5º, fala diretamente com as operadoras: elas não podem tratar dado de saúde para "seleção de riscos" na contratação, nem na contratação e exclusão de beneficiários. Um agente de cotação ou de qualificação comercial, portanto, não pode usar dado de saúde para selecionar risco e filtrar quem entra, e a mesma vedação alcança a exclusão de beneficiários.

O § 4º veda que controladores compartilhem entre si dado de saúde com objetivo de obter vantagem econômica. As exceções são estreitas: prestação de serviços de saúde, de assistência farmacêutica e de assistência à saúde, em benefício do titular, para permitir a portabilidade que ele pedir ou as transações financeiras e administrativas decorrentes desses serviços. Todo envio automatizado de dado de saúde a outro controlador (um parceiro, uma empresa do grupo, um prestador) precisa ser avaliado contra essa regra antes de virar fluxo.

O relatório de impacto deixa de ser hipotético

A autoridade nacional pode determinar que o controlador elabore relatório de impacto à proteção de dados, e a lei menciona expressamente os dados sensíveis (art. 38). Vale prepará-lo junto com o desenho do agente, e não quando ele for pedido: as decisões que o relatório exige são as mesmas que este guia descreve.

Consentimento ou outra base legal

Um atalho tentador é tratar o consentimento como resposta para tudo. Ele é uma das hipóteses do art. 11, e das mais exigentes: precisa ser dado "de forma específica e destacada, para finalidades específicas" (art. 11, I), e o titular pode revogá-lo (art. 18, IX). Se o fluxo do agente depende de consentimento e o beneficiário revoga, o fluxo precisa ter um caminho alternativo, ou parar.

Sem consentimento, o tratamento só é permitido quando for indispensável para uma das finalidades do art. 11, II. As que podem entrar na análise de um fluxo de saúde:

• Cumprimento de obrigação legal ou regulatória pelo controlador (alínea a).
• Exercício regular de direitos, inclusive em contrato (alínea d).
• Proteção da vida ou da incolumidade física do titular ou de terceiro (alínea e).
• Tutela da saúde, exclusivamente em procedimento realizado por profissionais de saúde, serviços de saúde ou autoridade sanitária (alínea f).
• Prevenção à fraude e segurança do titular, na identificação e autenticação de cadastro em sistemas eletrônicos (alínea g).

Duas ausências importam: o legítimo interesse e a proteção do crédito (art. 7º, IX e X), que servem de base para dado pessoal comum, não estão no art. 11. Qual hipótese cobre cada fluxo, e se a alínea f alcança o seu caso, é análise do seu jurídico. O que cabe à engenharia é não decidir isso uma única vez para "o projeto de IA": a base é definida por fluxo, e o fluxo é desenhado para caber nela.

Onde o agente encosta no dado sensível

Mapeie por fluxo, não por sistema: o mesmo ERP alimenta fluxos com riscos muito diferentes. Os seis abaixo seguem a jornada do beneficiário numa operadora, e a maior parte vale também para hospital e clínica.

Dois padrões atravessam a tabela. O agente precisa lidar com o que chega, e não só com o que pede: o beneficiário pode mandar, sem que ninguém solicite, um laudo inteiro para perguntar sobre uma carência. E os fluxos mais expostos nem sempre são os clínicos: atendimento e cobrança recebem dado de saúde por arrasto, quando o contexto é montado com o cadastro completo porque é mais simples. Na cobrança há um motivo a mais para manter esse dado fora: a proteção do crédito não está entre as hipóteses do art. 11.

Minimização e mascaramento antes do modelo

O princípio da necessidade limita o tratamento ao "mínimo necessário" para a finalidade (art. 6º, III). Com dado de saúde, é o controle de maior efeito, porque em muitas respostas o modelo não precisa saber quem é a pessoa. Para informar o status de uma autorização, ele precisa de "exame de imagem em análise pela auditoria médica, documentação completa, dentro do prazo". Não precisa de nome, CPF, número da carteirinha nem do laudo anexado. O corte funciona em quatro camadas, nesta ordem:

1. Não buscar o que não muda a resposta. A ferramenta que consulta o sistema devolve só os campos do fluxo. O corte acontece na integração, antes de o dado existir no contexto do agente.
2. Mascarar identificadores antes do envio. CPF, carteirinha, telefone e e-mail viram marcadores, e a reassociação acontece fora do modelo, no sistema que executa a ação.
3. Generalizar o dado clínico quando a resposta não depende dele. "Exame de imagem" no lugar do nome do exame e do laudo; a categoria no lugar do detalhe.
4. Tratar o que o beneficiário mandou sem ser pedido. O texto livre passa pela sanitização antes do modelo, e o anexo vai para um armazenamento com acesso restrito, sem entrar no contexto, a menos que o fluxo dependa dele.

Mascarar não é anonimizar. Pelo art. 12, dado que pode ser reassociado ao titular com esforço razoável continua sendo dado pessoal. O mascaramento reduz a exposição e o tamanho de um eventual incidente, mas o tratamento segue sob a LGPD.

Onde o dado é processado e guardado

Um agente deixa dado de saúde em mais lugares do que o sistema principal. Como a lei pede medidas de segurança desde a concepção do serviço (art. 46, § 2º), cada um desses lugares precisa de dono, prazo de retenção e controle de acesso já no piloto:

• O provedor do modelo. Retenção, uso para treino e região de processamento, com resposta por escrito em contrato.
• A base de conhecimento. Indexar manuais, regras de cobertura e protocolos internos é uma coisa; indexar históricos ou anexos de beneficiários cria mais uma base sensível.
• O histórico da conversa e os anexos. No canal e na plataforma fica tudo o que o beneficiário enviou, inclusive o que não foi pedido.
• A trilha de execução, tratada mais abaixo.

Quando o modelo é processado fora do Brasil, há transferência internacional, permitida só nas hipóteses do art. 33, como país com nível de proteção adequado ou garantias contratuais específicas; o guia geral detalha esse ponto. Na saúde, a decisão pesa mais e deve ser tomada por fluxo. A segunda via de boleto, com identificador mascarado, tem um perfil de risco; a leitura de laudo para autorização tem outro, e pode pedir provedor sem retenção com garantia em contrato, ou modelo próprio na sua infraestrutura. O texto sobre escolha de modelo ajuda a montar essa divisão.

Onde o humano aprova

O art. 20 dá ao titular o direito de pedir revisão de decisões tomadas unicamente com base em tratamento automatizado que afetem seus interesses. Na saúde, os casos mais evidentes são negar autorização, negar cobertura, recusar reembolso, glosar e excluir. A regra de desenho que resolve a maioria deles cabe numa frase: o agente prepara, a pessoa decide.

Na autorização, o agente reúne a documentação, confere elegibilidade e cobertura e acompanha o prazo; quem aprova ou nega é a auditoria médica. Na triagem, ele orienta o beneficiário ao ponto de cuidado e, com sinal de urgência, aciona um profissional de saúde na hora. Pontos que pedem aprovação humana, ação por ação:

• Aprovação ou negativa de autorização, cobertura e reembolso.
• Glosa e qualquer sinalização de fraude que gere consequência para o beneficiário ou para o prestador.
• Orientação que vá além de indicar o ponto de cuidado, e todo caso com sinal de urgência.
• Comunicação que revele dado de saúde a alguém que não seja o próprio titular.
• Cancelamento ou exclusão de beneficiário.

A aprovação é por tipo de ação, e não um botão global. O texto sobre human-in-the-loop mostra como desenhar para que a pessoa não vire o gargalo. E o registro da aprovação (quem, quando, sobre o quê) entra na trilha.

A trilha de cada chamada de ferramenta

Quando o beneficiário reclama, ou a auditoria interna pergunta por que o agente respondeu o que respondeu, "o modelo decidiu" não é resposta. A LGPD pede registro das operações de tratamento (art. 37), capacidade de demonstrar a adoção de medidas eficazes (art. 6º, X) e, quando o titular pedir, informação clara sobre os critérios e os procedimentos de uma decisão automatizada (art. 20, § 1º). Em cada execução, a trilha precisa guardar:

• A entrada recebida, já sanitizada, e a versão da instrução em uso.
• Cada ferramenta chamada, com os parâmetros enviados e a resposta recebida.
• O modelo usado, a resposta final e se houve transbordo para um atendente.
• A aprovação humana, quando houve: quem, quando e sobre o quê.

O paradoxo é que a trilha, feita para proteger, vira ela mesma uma base de dados de saúde. Ela entra no inventário, tem prazo de retenção e acesso por papel, e precisa ser alcançada quando o titular exerce os direitos do art. 18, respeitada a conservação que a lei autoriza, como a necessária para cumprir obrigação legal ou regulatória (art. 16, I). O post sobre observabilidade trata do lado técnico.

O que perguntar ao fornecedor

As perguntas gerais estão no guia de governança. Na saúde, acrescente estas, e peça a resposta por escrito:

1. A sanitização acontece antes do modelo, inclusive no texto livre e nos anexos que o beneficiário manda sem ser pedido?
2. Consigo decidir onde cada fluxo é processado (provedor sem retenção, região, modelo próprio na minha infraestrutura), e não só a conta inteira?
3. A aprovação humana é configurável por tipo de ação, como negativa, glosa e orientação clínica, e fica registrada com nome e horário?
4. A trilha registra cada chamada de ferramenta com parâmetros e é reproduzível? Quem da equipe de vocês tem acesso a ela?
5. Vocês tratam o dado só conforme as minhas instruções, como operador (art. 39)? Quais subcontratados, incluindo provedores de modelo, recebem dado?
6. Em caso de incidente, quando e com qual informação vocês me avisam? Ela cobre o que eu preciso comunicar pelo art. 48?

Resposta a incidente com agente no meio

O art. 48 obriga o controlador a comunicar à autoridade nacional e ao titular o incidente de segurança que possa acarretar risco ou dano relevante. O prazo é o que a autoridade definir, e a lei fixa o conteúdo mínimo da comunicação, como a natureza dos dados afetados, os titulares envolvidos, as medidas de proteção usadas, os riscos e as providências adotadas. Confira a regulamentação vigente ao montar o plano.

Com agente, incidente não é só vazamento de banco. Quatro cenários merecem roteiro próprio:

• Resposta para a pessoa errada. O status de uma autorização enviado a um número que mudou de dono, ou a um familiar que usa o mesmo telefone.
• Contexto cruzado. Dado de um beneficiário aparecendo na conversa de outro, por falha de isolamento de sessão ou de memória.
• Indução pelo texto. Alguém tenta fazer o agente consultar dado de outra pessoa. O controle é de desenho: a ferramenta só consulta o beneficiário autenticado na sessão, e não qualquer identificador que apareça na conversa.
• Exposição pela trilha ou pelos anexos. Acesso indevido justamente à base que existe para auditar.

O plano precisa de três capacidades. Conter: suspender o agente ou uma ferramenta específica sem parar a operação inteira. Reconstruir: a trilha diz quais beneficiários foram afetados, com quais dados e quando, que é o conteúdo que o art. 48 pede. Comunicar: o encarregado conduz, com modelo de comunicação pronto. E o mascaramento ajuda aqui também: no juízo de gravidade, a lei manda considerar se havia medida técnica que tornasse o dado ininteligível para quem não deveria acessá-lo (art. 48, § 3º).

Como a Runflow trata dado de saúde

Os controles deste guia fazem parte da plataforma da Runflow para criar, operar e mensurar agentes: sanitização de dados sensíveis antes de chegar ao modelo, isolamento por cliente ponta a ponta, aprovação humana onde o risco exige e trilha auditável de cada execução, decisão e chamada de ferramenta, reproduzível para auditoria. A Runflow não treina modelos com o seu dado, e você decide por onde ele passa: provedores sem retenção ou modelo próprio na sua infraestrutura, com a plataforma gerenciada por nós ou na sua nuvem (AWS, Azure ou GCP), com as suas chaves.

Para operadoras, os agentes de saúde seguem a mesma régua. O de Autorização Prévia lê a guia no padrão TISS, confere elegibilidade e cobertura e monta o processo para a auditoria médica, sem aprovar nem negar sozinho. O de Navegação de Saúde e Triagem aciona um profissional de saúde quando há sinal de urgência. A decisão de glosa ou negativa é sempre humana, e nossos engenheiros conectam TISS, ERPs e sistemas de autorização. O diagnóstico gratuito começa pelo fluxo que mais pesa no seu atendimento hoje.