IA na saúde: o que é permitido e o que ainda exige o profissional

Existe uma linha prática que separa o que é seguro do que é arriscado ao usar inteligência artificial em saúde: de um lado, tudo que é administrativo, documental e de organização de informação; do outro, tudo que toca diagnóstico, conduta, prescrição e laudo. O primeiro grupo já dá retorno hoje e envolve principalmente cuidado com dado pessoal. O segundo grupo é ato de profissional habilitado e, quando o software se propõe a fazer parte dele, entra em regime regulatório próprio.

O território seguro: onde IA já se paga em clínica e hospital

Estes são usos que não interferem no ato clínico e resolvem problemas reais de operação:

Repare em uma característica comum: em todos os casos a IA organiza, extrai ou sugere, e um humano decide. É essa relação que mantém o uso fora do terreno regulatório mais pesado.

Um detalhe importante sobre sugestão de código de faturamento: a sugestão precisa ser sempre confirmada por quem executou o procedimento. Codificação inflada, mesmo por erro de modelo, é problema sério com operadora e pode ser tratada como irregularidade.

O território regulado: quando o software vira dispositivo

No Brasil, software destinado a finalidade diagnóstica, terapêutica ou de monitoramento pode se enquadrar como dispositivo médico e ficar sujeito à regulamentação sanitária da Anvisa, incluindo classificação de risco e registro ou notificação conforme o caso. Isso vale para software que analisa imagem, que interpreta sinal biológico, que calcula dose ou que emite conclusão diagnóstica.

Não é uma formalidade que se resolve depois. Se a empresa está construindo algo nessa direção, a análise regulatória precisa entrar no início do projeto, junto com assessoria especializada, porque ela influencia arquitetura, documentação, validação e ciclo de atualização do produto.

Do lado profissional, os conselhos tratam diagnóstico, prescrição, laudo e conduta como atos privativos. A responsabilidade continua sendo do profissional que assina, independentemente do que o sistema sugeriu. Isso tem uma consequência de projeto: a interface nunca deve apresentar a saída do modelo como conclusão pronta. Ela deve apresentar como achado a ser verificado, com a evidência que sustenta e com a possibilidade de discordar registrada.

Como as normas dos conselhos e da agência sanitária são revisadas com frequência, qualquer decisão concreta deve ser validada com o conselho da área e com assessoria jurídica antes da implantação.

LGPD: dado de saúde não é dado comum

Dado sobre saúde é categorizado como sensível pela LGPD, o que restringe as bases legais disponíveis e aumenta a exigência de segurança. Alguns pontos práticos que aparecem em quase todo projeto:

• Base legal precisa ser escolhida com critério. Tutela da saúde por profissional ou serviço de saúde é diferente de uso para pesquisa ou para marketing. Consentimento genérico raramente cobre tudo.
• Finalidade limitada. Dado coletado para atendimento não vira automaticamente base de treinamento de modelo. Uso secundário exige análise própria e, em muitos casos, anonimização robusta.
• Onde o dado é processado importa. Enviar prontuário para um serviço de IA de uso geral, sem contrato adequado, é exposição. Ou o dado vai desidentificado, ou o serviço precisa oferecer garantias contratuais e técnicas compatíveis.
• Log de acesso é obrigatório na prática. Precisa ser possível dizer quem acessou qual prontuário, quando e por quê.
• Compartilhamento com operador exige contrato que defina responsabilidades, prazo de retenção e o que acontece no encerramento.

Uma técnica que reduz risco de forma significativa e é subutilizada: desidentificar antes de enviar. Boa parte dos usos administrativos não precisa de nome, documento nem endereço. Um pipeline que remove identificadores antes de chamar o modelo, e recompõe o resultado localmente, muda a natureza do risco.

Transcrição de consulta: o caso que mais gera dúvida

É o uso de melhor relação entre esforço e retorno em consultório, e o que mais gera pergunta. Os cuidados que fazem diferença:

1. Informar o paciente com clareza que o atendimento será transcrito, para que serve e como o áudio é tratado. Informar não é enterrar no termo de aceite.
2. Definir se o áudio é guardado ou descartado depois da transcrição. Descartar reduz risco e raramente prejudica o uso.
3. Tratar o texto gerado como rascunho. O prontuário é o que o profissional revisou e assinou, não o que o modelo escreveu.
4. Controlar o modelo de evolução, para que a transcrição vire campo estruturado e não parágrafo solto.
5. Registrar no log que aquela evolução teve apoio de transcrição automática.

O ponto 3 é onde a maior parte dos problemas nasce. Modelo de transcrição erra nome de medicamento, dosagem e número. Em contexto clínico isso não é detalhe, é risco. Revisão antes de salvar não é burocracia opcional.

Como desenhar o projeto para não ficar refém do modelo

Uma recomendação de arquitetura que vale para qualquer projeto de IA em saúde: o sistema precisa funcionar sem a IA. O prontuário estruturado, a agenda, o faturamento e o controle de acesso são a espinha dorsal. A IA entra como camada de aceleração em cima disso.

Isso protege de três coisas ao mesmo tempo: mudança regulatória que restrinja algum uso, indisponibilidade ou mudança de preço do provedor do modelo, e queda de qualidade de saída, que acontece e nem sempre é anunciada.

Vale também definir desde o início como se mede qualidade. Em transcrição, isso é uma amostra revisada semanalmente com contagem de erro relevante. Em sugestão de código, é a taxa de aceitação pelo profissional e a taxa de glosa por código sugerido. Sem métrica, ninguém percebe degradação até o problema aparecer no faturamento ou no atendimento.

Resumo prático da linha

A Retti Tech, estúdio de Natiam Gabriel, trabalha com e sem IA justamente porque, em setores regulados, a parte que gera retorno estável quase sempre é o processo bem desenhado, e o modelo é o que acelera depois que o processo já está de pé.