O mecanismo de alerta de sepse da Epic falhou em uma validação de 2021 no Michigan Medicine, deixando passar dois terços dos pacientes que posteriormente desenvolveram sepse, enquanto disparava um alerta para 18% de todas as internações. O erro remonta a um clássico problema de vazamento de dados (data leakage): o modelo contabilizou a prescrição de antibióticos de um médico — que já é um sinal de suspeita de infecção — como um preditor, essencialmente ecoando uma decisão que o clínico já havia tomado.

Por que o modelo falhou

A equipe de Michigan examinou 38.455 internações hospitalares, o tamanho de um projeto típico de melhoria de qualidade de vários anos. Os benchmarks internos da Epic prometiam alta precisão, mas o teste independente mostrou o oposto. Os alertas de "alto risco" do modelo foram disparados em quase um quinto dos pacientes, mas dois terços dos casos reais de sepse passaram despercebidos. Na prática, o sistema gritava "cuidado" com frequência excessiva, enquanto perdia justamente os eventos que deveria detectar.

A causa raiz não foi uma falha no próprio algoritmo de machine learning, mas nos dados que o alimentavam. Ao usar a presença de uma prescrição de antibióticos como um dado de entrada, o modelo aprendeu a prever uma escolha que o clínico já havia feito. Quando o algoritmo sinalizava um paciente, muitas vezes o fazia porque o médico já havia prescrito antibióticos, e não porque a fisiologia do paciente indicava uma sepse iminente.

Um problema mais amplo na IA hospitalar

O modelo de sepse da Epic tem sido implantado em centenas de hospitais há anos, mas o erro de vazamento permaneceu oculto até que um esforço de validação focado o trouxesse à tona. O episódio ilustra uma fraqueza sistêmica: a maioria dos projetos de IA em sistemas de saúde carece das verificações operacionais necessárias para detectar tais problemas precocemente.

  • Sem testes externos – Os hospitais não realizaram testes externos.
  • Sem monitoramento contínuo – Não havia monitoramento.
  • Sem responsabilidade clara – Sem uma equipe designada para a qualidade dos dados e o desempenho do modelo, os problemas acabam passando despercebidos.

Essas lacunas mantêm muitas iniciativas de IA presas no "purgatório dos pilotos", nunca avançando além de uma fase de prova de conceito.

O custo oculto de dados fragmentados

O caso da sepse também mostra como ecossistemas de TI em saúde fragmentados sabotam a IA. Obstáculos comuns incluem:

  • Registros de pacientes presos em módulos de EHR legados que não trocam dados automaticamente.
  • Sistemas de imagem e laboratório que não conseguem se comunicar, forçando transferências manuais de arquivos.
  • Identificadores de pacientes duplicados que dividem os dados de uma única pessoa em vários prontuários.
  • Notas clínicas e sinais vitais armazenados em silos separados, nunca mesclados para o treinamento do modelo.

Quando um modelo é treinado em um conjunto de dados limpo e curado, mas depois recebe dados reais e desorganizados, o desempenho degrada silenciosamente. Os clínicos perdem a confiança rapidamente; um enfermeiro que precisa perseguir alertas através de múltiplas telas irá ignorá-los, mesmo que o algoritmo subjacente seja tecnicamente sólido.

Quatro fundamentos "tediosos" para uma IA confiável

Uma implantação funcional de IA baseia-se em quatro capacidades práticas que raramente viram manchetes:

  1. Interoperabilidade – Os dados devem fluir entre EHRs, laboratórios, plataformas de imagem e ferramentas de suporte à decisão sem etapas manuais de exportação e importação.
  2. Governança – Uma pessoa ou equipe responsável deve ser dona da qualidade dos dados e monitorar os resultados do modelo ao longo do tempo.
  3. Integração ao fluxo de trabalho – Os alertas precisam aparecer dentro da fila de trabalho existente do clínico; cliques ou telas extras matam a adoção.
  4. Operações escaláveis – Monitoramento automatizado, análise de fadiga de alertas e pipelines de retreinamento periódico são essenciais antes que o modelo chegue à produção.

Pular qualquer uma dessas etapas deixa um projeto vulnerável ao tipo de falha silenciosa observada no modelo de sepse da Epic.

Perguntas a fazer antes de comprar uma solução de IA

Os hospitais podem evitar erros dispendiosos exigindo respostas concretas:

  • Vocês conseguem rastrear os dados de um único paciente em todos os sistemas que o modelo utilizará?
  • Quem, nominalmente, é responsável por manter a qualidade dos dados e supervisionar o desempenho do modelo?
  • Os alertas foram testados com clínicos durante um turno real, e não apenas em um ambiente de sandbox?
  • Existe um plano de monitoramento documentado que especifique como o desvio de desempenho (performance drift) será identificado e tratado?

Se o fornecedor não conseguir apontar uma pessoa, um processo ou um painel de monitoramento, a organização deve pausar e reavaliar.

Conclusão

O modelo de sepse da Epic não falhou porque o machine learning seja inadequado para hospitais; ele falhou porque faltavam o pipeline de dados e as estruturas de governança ao seu redor. Um modelo que prevê a própria decisão de um médico serve de alerta de que a camada de engenharia de dados, e não o algoritmo, é o que precisa de melhorias. Construir uma IA confiável na área da saúde exige a mesma infraestrutura “tediosa” que mantém qualquer sistema de TI crítico funcionando: dados limpos e conectados, responsabilidade clara, alertas integrados ao fluxo de trabalho e monitoramento proativo. Sem isso, mesmo o modelo mais sofisticado acabará gritando avisos errados para as pessoas erradas.