Quando o algoritmo erra: a responsabilidade do engenheiro na era da regulação médica com IA

O erro que não é só do médico

Imagine o seguinte: um radiologista utiliza um sistema de IA para triagem de mamografias. O modelo, treinado com milhares de imagens, aponta um nódulo suspeito como benigno com alta confiança. O médico confia, registra a conclusão e o caso é encerrado. Seis meses depois, o paciente retorna com um câncer em estágio avançado. A família processa o médico, o hospital e o desenvolvedor do software. De quem é a responsabilidade? A Resolução CFM 2.454/2026 tenta responder a essa pergunta, mas o que realmente muda para quem constrói esses sistemas?

Como engenheiro de software especializado em arquiteturas de IA e sistemas distribuídos, vejo essa resolução não como uma mera burocracia clínica, mas como um marco técnico que redesenha contratos, pipelines de dados e, principalmente, os requisitos não funcionais dos sistemas de apoio à decisão. Não se trata apenas de saber quem assina o laudo – trata-se de garantir que a decisão do algoritmo possa ser auditada, contestada e explicada em um tribunal. Isso impõe desafios profundos ao design de produto e à infraestrutura que sustentam a inteligência artificial na medicina.

O coração técnico da nova responsabilidade

Segundo o portal ConJur, a resolução estabelece que o médico mantém a responsabilidade civil pelos atos praticados com auxílio de sistemas de IA, mesmo quando a ferramenta opera de forma autônoma. Do ponto de vista da engenharia, isso significa que o sistema precisa ser observável e determinístico em suas respostas – ou, pelo menos, ter um registro forense que permita reconstruir o raciocínio do modelo em um dado momento. Modelos de deep learning, por natureza, são caixas-pretas. Um radiologista não enxerga os neurônios que ativaram a classificação “benigno”. A resolução, na prática, força a adoção de técnicas de IA explicável (XAI) não como um extra, mas como um requisito legal de produção.

Para uma equipe de engenharia, isso se traduz em decisões concretas: versionar todos os parâmetros do modelo e do pré-processamento, armazenar logs de inferência com metadados completos (timestamp, versão, confiança, e até mesmo os mapas de saliência gerados), e implementar mecanismos de rollback que respeitem a rastreabilidade. Sistemas que antes podiam ser atualizados “quentes” – substituindo um modelo de classificação sem interromper o serviço – agora precisam manter uma cadeia de auditoria contínua, o que eleva significativamente a complexidade de infraestrutura e o custo de armazenamento em nuvem.

Trade-offs entre desempenho e auditabilidade

Um dos maiores dilemas que enfrento na prática é o conflito entre acurácia e explicabilidade. Modelos mais simples – como regressão logística ou árvores de decisão rasa – oferecem total transparência, mas geralmente com desempenho inferior em tarefas de imagem e linguagem. Redes neurais profundas alcançam resultados superiores, porém sacrificam a capacidade de gerar explicações diretas. A resolução não obriga a escolha de um tipo de modelo, mas a responsabilidade civil recai sobre o profissional que utiliza a ferramenta. Isso cria um incentivo perverso: o médico pode optar por modelos mais explicáveis e menos precisos para se proteger juridicamente, em detrimento da qualidade do diagnóstico.

Cabe ao engenheiro projetar soluções que equilibrem esses fatores. Uma abordagem que implementei em um sistema de suporte à decisão para um hospital foi a adoção de modelos híbridos: uma rede neural para detecção de características visuais, combinada a um classificador explicável (como uma Random Forest) que opera sobre essas características. O resultado final mantém boa acurácia, mas permite rastrear quais padrões visuais contribuíram para a decisão. Além disso, é crucial que o sistema apresente ao médico não apenas o laudo, mas também um painel de incertezas – por exemplo, destacando os casos com confiança abaixo de um limiar, que exigem revisão manual obrigatória. Isso não é feature, é exigência de compliance.

Infraestrutura para registro forense: lições de campo

Construir uma camada de auditoria para sistemas de IA em saúde não é trivial. Em um projeto recente, precisei projetar um pipeline que armazenasse, para cada consulta, o payload completo de entrada (exame, histórico, dados demográficos), os resultados intermediários de cada camada do modelo e a saída final com a confiança associada. Tudo isso precisa ser imutável, indexado por paciente e por sessão clínica, e acessível por até dez anos – prazo típico de prescrição de ações civis. A escolha de um banco de dados de séries temporais combinado com um data lake em cloud permitiu atender aos requisitos, mas multiplicou o custo de armazenamento por um fator de cinco.

Outra lição importante é a necessidade de logs de “quem viu o quê”. O sistema deve registrar não só a decisão do algoritmo, mas também a interação do médico: ele aceitou a recomendação? Rejeitou? Modificou o laudo? Ignorou o alerta de baixa confiança? Essas ações precisam ser capturadas de forma granular, pois o tribunal pode querer saber se o médico exerceu seu julgamento crítico ou apenas “copiou” a resposta da IA. Isso exige instrumentação pesada na interface do usuário, que deve ser desenhada em conjunto com as equipes de produto e jurídico desde o início.

O papel do engenheiro na definição dos limites do sistema

A resolução reforça algo que muitos times de desenvolvimento ignoram: a responsabilidade pela decisão final não é do algoritmo, mas do humano que o utiliza. Cabe a nós, engenheiros, estabelecer limites claros de atuação do sistema. Isso significa implementar barreiras técnicas que impeçam o uso da IA fora do escopo clínico validado. Por exemplo, um modelo treinado apenas para detectar nódulos pulmonares não deve ser aplicado a outros órgãos – e o sistema deve, de forma forçada, recusar a inferência se o campo “região anatômica” não corresponder ao domínio do treinamento.

Esse tipo de salvaguarda exige uma engenharia de dados rigorosa: os conjuntos de treino e validação precisam ser rotulados com metadados de domínio, e o modelo deve incluir uma camada de validação de entrada que bloqueie qualquer solicitação fora do escopo. Não é apenas uma questão de qualidade, é uma questão de mitigação de responsabilidade. Se o hospital permitir que o sistema opere fora da indicação aprovada, a responsabilidade pode recair também sobre o desenvolvedor, dependendo do contrato e da regulação. Engenheiros que negligenciam esse ponto expõem a empresa a riscos jurídicos enormes.

Implicações para o ciclo de vida do produto

Para times de produto, a resolução muda a prioridade de funcionalidades. Antes, velocidade de entrega e acurácia reinavam. Agora, “rastreabilidade” e “explicabilidade” se tornam features críticas, com peso igual ao de performance. Isso impacta o roadmap: é preciso reservar sprints inteiros para implementar logs forenses, desenvolver dashboards de auditoria para médicos e criar relatórios de explicabilidade em formato legível por humanos. O custo de desenvolvimento pode aumentar entre 20% e 40%, estimo com base em projetos similares. Mas não fazer isso pode significar inviabilidade jurídica do produto no mercado brasileiro.

Outra consequência é a necessidade de testes clínicos contínuos. Um modelo de IA para diagnóstico não pode ser “treinado e esquecido”. A resolução, na prática, exige que o sistema seja constantemente reavaliado para detectar degradação de desempenho – o chamado data drift. Um sistema de monitoramento em produção, com alertas para queda de acurácia em subgrupos populacionais, torna-se indispensável. Isso não é barato: envolve a coleta de novos dados rotulados (com curadoria de especialistas), re-treinamento periódico e testes de validação antes do deploy. Engenheiros precisam projetar pipelines de MLOps que suportem esse ciclo, com separação clara entre dados de treino, validação e produção.

Riscos e limitações que não podemos ignorar

É tentador acreditar que, com logs e explicabilidade, a responsabilidade estará plenamente coberta. Mas a realidade é mais complexa. Modelos de linguagem natural, por exemplo, não produzem explicações causais genuínas – elas geram textos que parecem explicar, mas são apenas simulações estatísticas. Um médico pode ser levado a confiar em uma justificativa plausível, porém incorreta. A resolução não aborda essa nuance, e cabe à engenharia destacar as limitações nos manuais de uso e nas interfaces.

Outro risco é a falsa sensação de segurança por parte dos médicos. Se o sistema exibe um nível de confiança alto, o profissional tende a diminuir a vigilância mesmo quando o modelo está errado. Esse viés de automação é bem documentado na psicologia da tomada de decisão. A engenharia pode mitigá-lo desenhando interfaces que mostrem incertezas de forma clara, como intervalos de confiança ou cenários alternativos, e que exijam ação explícita do médico antes de finalizar o laudo. Mas o efeito real depende de treinamento e cultura organizacional.

Uma perspectiva pessoal sobre o futuro

A Resolução CFM 2.454/2026 não é um obstáculo, é um convite à maturidade técnica. Para engenheiros que constroem produtos de IA em saúde, ela impõe um padrão mais elevado de responsabilidade profissional. Sistemas que não forem projetados com auditabilidade, explicabilidade e limites claros de escopo simplesmente não poderão ser comercializados. Isso vai privilegiar equipes que já praticam MLOps maduro, versionamento de modelos e testes contínuos – práticas que, em outras indústrias, já são pré-requisito.

Como arquiteto de sistemas, vejo um campo fértil para inovação em ferramentas de IA explicável, bancos de dados imutáveis para auditoria clínica e plataformas de monitoramento de drift adaptadas ao domínio médico. A regulamentação, longe de frear a inovação, cria um mercado para soluções que equilibrem potência preditiva e transparência. Aos engenheiros que atuam nessa área, sugiro: invistam em instrumentação desde o primeiro dia de código, participem das discussões clínicas sobre os limites de uso e, acima de tudo, documentem cada trade-off técnico com justificativas claras. O tribunal – seja ele jurídico ou técnico – examinará cada detalhe. E é melhor que ele encontre um rastro limpo e intencional.