Por que sistemas de apoio à decisão clínica com IA falham — e como projetá-los melhor

O desempenho do modelo não basta. Entenda como dados, fluxo clínico, explicabilidade, validação e governança determinam se uma IA será útil ou ignorada.

Um sistema de apoio à decisão clínica com inteligência artificial pode analisar dados do paciente, estimar riscos e sugerir uma próxima ação. O sistema, porém, não substitui o julgamento profissional: sua função é apresentar informação relevante, no momento adequado, para apoiar uma decisão que continua sujeita à avaliação clínica.

A principal causa de fracasso desses projetos raramente é apenas um algoritmo impreciso. Sistemas de apoio à decisão clínica falham quando a recomendação não corresponde aos dados disponíveis, ao fluxo real de atendimento ou à responsabilidade de quem precisa agir. Um modelo sofisticado pode produzir pouco valor se interromper profissionais em excesso, não explicar o motivo do alerta ou depender de informações que chegam atrasadas.

Por que uma IA clinicamente promissora pode falhar na prática?

O primeiro problema costuma estar nos dados. Prontuários eletrônicos contêm informações registradas por pessoas e sistemas diferentes, com variações de preenchimento, terminologia, unidade de medida e momento da coleta. Ausência de um dado também não significa necessariamente ausência de uma condição: pode indicar que o exame não foi solicitado, que o resultado ainda não chegou ou que a informação foi registrada em outro lugar.

O modelo aprende essas características do ambiente de origem. Quando é transferido para outra instituição, mudanças no perfil dos pacientes, nos protocolos, nos equipamentos e nas práticas de registro podem alterar seu desempenho. Uma variável aparentemente objetiva, como a frequência de determinados exames, pode refletir tanto o estado do paciente quanto a conduta habitual da equipe. O algoritmo corre, então, o risco de reproduzir padrões operacionais em vez de identificar precocemente um evento clínico.

A segunda fonte de falha é o desalinhamento com o trabalho assistencial. Um alerta só é útil quando chega a uma pessoa capaz de interpretá-lo e agir. Uma recomendação exibida depois da decisão, enviada a um profissional sem autonomia para executar a conduta ou desacompanhada de uma ação viável apenas acrescenta ruído. Alertas frequentes e pouco específicos também favorecem a dessensibilização: recomendações relevantes passam a competir com interrupções de baixo valor.

O que torna um alerta clínico realmente acionável?

Um alerta acionável identifica o risco, apresenta os elementos que sustentam a recomendação e deixa claro qual decisão pode ser tomada. A interface deve informar quais dados foram considerados, quais dados relevantes estão ausentes, o grau de incerteza e o que mudou desde a avaliação anterior. A explicação precisa ser compatível com o tempo disponível no atendimento, sem exigir que o profissional interprete uma saída técnica do modelo.

O momento do alerta deve ser definido a partir da jornada clínica, e não apenas da disponibilidade do cálculo. Uma recomendação sobre prescrição pode fazer sentido durante a escolha ou revisão do medicamento; uma sinalização de deterioração pode exigir comunicação imediata e regras claras de escalonamento. Em ambos os casos, o projeto precisa responder quem recebe a informação, quem pode agir, como registrar a decisão e o que acontece quando o alerta é rejeitado.

O objetivo também não deve ser maximizar a quantidade de notificações. A configuração adequada depende do dano associado a um caso não detectado, do custo clínico de uma sinalização incorreta e da capacidade operacional da equipe. Em situações críticas, maior sensibilidade pode ser justificável, desde que exista um processo para avaliar os casos sinalizados. Em decisões rotineiras, recomendações mais específicas e menos interruptivas podem preservar melhor a atenção dos profissionais.

Qual arquitetura favorece integração, rastreabilidade e evolução?

Padrões interoperáveis, como FHIR, ajudam a representar e trocar dados clínicos entre sistemas. Mecanismos baseados em contexto, como CDS Hooks, permitem solicitar apoio à decisão em pontos definidos do fluxo, por exemplo durante a abertura de um prontuário ou a preparação de uma prescrição. A adoção desses padrões não corrige dados ruins por conta própria, mas reduz integrações excessivamente dependentes de formatos proprietários e facilita a identificação da origem de cada informação.

Uma arquitetura orientada a eventos pode separar a captura de fatos clínicos, a preparação dos dados, a execução do modelo e a entrega da recomendação. Essa separação favorece rastreabilidade e manutenção, mas aumenta a necessidade de controlar duplicidade, ordem dos eventos, indisponibilidade e latência. Microsserviços também não devem ser adotados como regra: um sistema modular mais simples pode ser preferível quando a equipe, a escala e a operação não justificam a complexidade distribuída.

A trilha de auditoria deve registrar a versão do modelo, os dados usados na inferência, o resultado apresentado, o contexto da exibição e a resposta do usuário. Informações de saúde exigem controles de acesso, minimização de dados, gestão de consentimento quando aplicável e proteção durante armazenamento e transmissão. No Brasil, a adequação à Lei Geral de Proteção de Dados precisa considerar a finalidade do tratamento, os papéis dos agentes envolvidos e as salvaguardas apropriadas ao risco. Dependendo da finalidade pretendida e do funcionamento do produto, também pode ser necessária uma análise regulatória específica para software utilizado em saúde.

Como validar o sistema antes e depois da implantação?

A validação deve começar com uma pergunta clínica delimitada e um resultado mensurável. “Prever deterioração” é amplo demais se não houver definição do evento, população, horizonte de previsão e conduta esperada. O desempenho técnico precisa ser analisado junto com utilidade clínica: uma previsão pode discriminar casos razoavelmente em dados históricos e ainda assim chegar tarde, concentrar erros em um subgrupo ou não alterar decisões.

Antes da ativação, convém testar o modelo com dados locais e executar uma fase silenciosa, na qual previsões são registradas sem interferir no atendimento. Essa etapa permite observar disponibilidade das variáveis, latência, volume potencial de alertas e diferenças entre a população local e a base de desenvolvimento. A introdução no fluxo deve ser gradual, com participação de profissionais da assistência, tecnologia, segurança da informação, qualidade, privacidade e áreas responsáveis por risco clínico.

Após a implantação, o monitoramento precisa detectar mudanças na distribuição dos dados, falhas de integração e alterações no comportamento do modelo. Também deve acompanhar aceitação, justificativas de rejeição, tempo até a ação e possíveis diferenças de desempenho entre grupos clinicamente relevantes. Recalibrar ou substituir um modelo exige nova validação, porque uma mudança estatística pode alterar o comportamento do sistema e as decisões apoiadas por ele.

Na experiência profissional da Phurshell, acumulada em mais de 15 anos de mercado e mais de 100 aplicativos entregues para empresas brasileiras, decisões de produto e integração costumam determinar a viabilidade do software tanto quanto a tecnologia central. Em saúde, essa observação prática ganha peso adicional: responsabilidades mal definidas, exceções não mapeadas e interfaces desconectadas do atendimento podem neutralizar até uma boa modelagem. Temas relacionados, como descoberta de produto, arquitetura de software, segurança e governança de dados, merecem ser tratados como partes do mesmo projeto.