Degradação silenciosa: a falha oculta da IA em produção

Existe uma pergunta que todo gestor faz sobre seu sistema de IA: "está no ar?". É a pergunta errada. Sistemas de IA em produção quase nunca caem de forma espetacular. Eles fazem algo pior: continuam respondendo com status HTTP 200, latência aceitável, dashboard verde — enquanto a qualidade das respostas despenca sem que nenhum alarme dispare.

A tese é simples: o modo de falha dominante da IA em produção não é a indisponibilidade. É a degradação silenciosa. E a maioria das empresas está instrumentada para detectar exatamente o problema que não vai acontecer.

A falha que não dispara alerta

Em aplicações tradicionais, três métricas resolvem quase tudo: disponibilidade, taxa de erro e tempo de resposta. Se o sistema responde rápido e sem erro, está funcionando. Com IA, esse raciocínio quebra. Uma resposta pode chegar em dois segundos, sem exceção, perfeitamente formatada — e estar menos fundamentada, menos precisa ou simplesmente errada de um jeito convincente.

As causas dessa deriva são mundanas: a base documental mudou e o sistema segue respondendo com fontes velhas; um ajuste no prompt passou a induzir respostas mais longas e vagas; o provedor alterou o comportamento do modelo sem avisar; os avaliadores automáticos não cobrem os casos novos que os usuários passaram a trazer. Nenhum desses eventos gera erro HTTP. Todos degradam o produto.

Esse descompasso entre "sistema funcionando" e "sistema entregando valor" ajuda a explicar um número incômodo: segundo a McKinsey, em sua pesquisa de 2025 sobre o estado da IA, mais de 80% das organizações não relataram impacto tangível da IA no EBIT — e apenas 17% disseram que a IA generativa representava ao menos 5% do resultado. A Gartner, na mesma linha, projetou que pelo menos 30% dos projetos de IA generativa seriam abandonados após a prova de conceito até o fim de 2025, por qualidade de dados, controles insuficientes ou valor pouco claro. É uma previsão, não uma medição — mas aponta para o mesmo diagnóstico: muitos desses projetos não morrem porque a IA para. Morrem porque ninguém consegue provar que ela está funcionando.

O fallback é onde o contrato quebra primeiro

O exemplo mais claro de degradação invisível é o fallback mal medido. Fallback é necessário: provedores ficam indisponíveis, limites de taxa estouram, modelos falham. Uma arquitetura séria combina retry com limite, troca de provedor, modelo menor, resposta de cache, conteúdo determinístico ou transferência para um humano.

O problema é que fallback preserva disponibilidade, não necessariamente o contrato funcional. Se sua aplicação promete respostas fundamentadas em documentos internos e o fallback cai para um modelo sem acesso a esse contexto, o uptime continua impecável — e a confiabilidade foi embora. Em setores regulados, é preferível uma resposta de escopo reduzido, baseada apenas em dados validados, do que uma geração livre e não verificável.

Daí a regra que defendo: taxa de fallback é métrica de qualidade do produto, não detalhe operacional. Um sistema pode passar boa parte do tempo operando na rota degradada sem que ninguém no negócio saiba. Se sua equipe não sabe dizer, hoje, qual percentual das respostas veio da rota principal e qual veio do plano B, você não tem observabilidade — tem um dashboard decorativo.

Telemetria por requisição, não fatura por mês

A correção exige instrumentar cada requisição individualmente, registrando no mínimo:

modelo e versão utilizados, e qual versão do prompt gerou a resposta;
tokens de entrada e saída, com custo estimado da requisição;
documentos recuperados e ferramentas chamadas;
se houve fallback, e qual;
avaliação automática da resposta e, por amostragem, avaliação humana.

A Deloitte, em seu relatório de 2026 sobre IA empresarial, é direta: arquiteturas legadas de dados e infraestrutura não sustentam sistemas de IA autônomos e em tempo real. A telemetria deixa de ser infraestrutura auxiliar e vira parte do produto.

O mesmo vale para custo. A Gartner afirma que o custo de IA generativa varia de valores insignificantes a muitos milhões, dependendo de caso de uso, escala e requisitos. Com essa amplitude, olhar a fatura mensal agregada é gestão às cegas. O custo real inclui embeddings, reranking, consulta vetorial, reprocessamento causado por falhas e o próprio fallback — e ele também degrada em silêncio. O sistema deve registrar custo por requisição, por fluxo e por resultado. Só assim você descobre qual fluxo consome orçamento sem entregar valor proporcional.

Prompt é código — e quem não versiona não faz rollback

A degradação silenciosa só é diagnosticável se você souber o que mudou. E aqui entra o hábito mais negligenciado do mercado: tratar prompt como texto editável, não como artefato de software. Uma versão de produção precisa de identificador imutável, modelo e parâmetros associados, casos de avaliação, responsável pela alteração e possibilidade de rollback.

Mudanças aparentemente triviais — reorganizar o contexto, trocar um delimitador de documentos, ajustar uma instrução — alteram comportamento, custo e segurança. Sem versionamento, quando a qualidade cai, sua equipe não consegue responder à pergunta mais básica de qualquer incidente: "o que mudou?". Com versionamento, a resposta é um diff.

O fecho desse sistema é a avaliação em três camadas: offline, com um conjunto fixo de casos antes de cada publicação; online, com amostragem do tráfego real e testes A/B; e operacional, cruzando custo, latência e taxa de fallback com impacto no negócio. Avaliação automática por outro modelo escala bem, mas não substitui amostras rotuladas por especialistas do domínio — o avaliador automático pode carregar os mesmos vieses do sistema que avalia.

O que isso significa para empresas brasileiras

No Brasil, essa engenharia deixou de ser apenas boa prática técnica — está virando evidência regulatória. A ANPD colocou IA e tecnologias emergentes em seu mapa de temas prioritários para o biênio 2026–2027, divulgou em julho de 2026 o primeiro relatório parcial de seu sandbox regulatório de IA e publicou notas técnicas envolvendo possíveis violações da LGPD por sistemas de IA. E o Projeto de Lei nº 6.237/2025, ainda em tramitação, atribui à ANPD competência regulatória e sancionatória sobre modelos e aplicações de IA em áreas sem regulador setorial, prevendo investigações conjuntas com autoridades setoriais.

Traduzindo: quando um regulador — ou um cliente em disputa — perguntar por que o sistema respondeu o que respondeu, "o dashboard estava verde" não é resposta. Registro de versão de prompt, documentos que fundamentaram cada resposta, trilha de fallback e avaliação amostrada são exatamente o material que demonstra controle, rastreabilidade e capacidade de contestação — requisitos que a LGPD já impõe para decisões automatizadas em crédito, saúde, seguros e contratação.

Para o gestor, três perguntas separam operação real de teatro de disponibilidade: qual a taxa de fallback do sistema e o que ela significa para o usuário final? Qual versão de prompt está em produção e quem aprovou a última mudança? Qual o custo por resultado entregue, não por mês faturado? Quem não consegue responder às três não tem um sistema de IA em produção. Tem um protótipo com uptime alto — e um passivo esperando a primeira pergunta difícil.

HTTP 200 não é sucesso: a falha de IA que seu dashboard nunca vai mostrar