Fallback de IA sem teste não é plano B — é fé

Pergunte a qualquer time que colocou IA em produção qual é o plano de contingência. A resposta vem rápida e confiante: "se o modelo principal cair, roteamos para outro provedor". Agora faça a segunda pergunta: quando foi a última vez que esse caminho alternativo rodou com tráfego real, contra o mesmo dataset de avaliação, com as mesmas ferramentas habilitadas e os mesmos limites de segurança?

O silêncio que se segue é o assunto deste artigo.

A tese é simples: fallback que nunca foi testado não é redundância. É uma segunda forma de falhar — geralmente mais silenciosa que a primeira, porque ninguém está olhando para ela. Em sistemas determinísticos, um servidor reserva idêntico ao principal é contingência de verdade. Em sistemas probabilísticos, trocar o modelo muda o comportamento do produto. E quase ninguém trata essa mudança com a seriedade que ela exige.

Quatro planos B, não um

O primeiro erro é achar que fallback significa uma coisa só. Na prática, existem pelo menos quatro estratégias distintas:

Fallback de modelo: rotear para um modelo alternativo quando o principal está indisponível, lento ou acima do orçamento.
Fallback de capacidade: manter o mesmo modelo, mas reduzir contexto, desabilitar ferramentas ou entregar uma resposta resumida.
Fallback determinístico: recorrer a busca, regras de negócio, templates ou dados estruturados.
Fallback humano: encaminhar casos de alto risco ou baixa confiança para uma pessoa.

A maioria das empresas implementa apenas o primeiro — e implementa mal. Configura um segundo provedor no roteador, marca o checkbox de resiliência e segue em frente. O problema é que o modelo alternativo pode ter taxa de erro maior, pode não suportar a ferramenta que o fluxo principal usa, pode tratar dados sob regras diferentes. Nada disso aparece até o dia em que o caminho alternativo assume o tráfego.

O plano B é um produto com versão própria

Aqui está a mudança de mentalidade que separa arquitetura madura de improviso: o fallback precisa ser testado como uma versão própria do produto, com seus próprios limites de qualidade e segurança.

Isso conecta fallback a uma disciplina que o mercado ainda trata como detalhe: versionamento. Prompt não é texto editado direto em produção. A prática robusta versiona o template do prompt, o modelo e a versão da API, os parâmetros de geração, as ferramentas e seus schemas, o dataset de avaliação e os limites de custo e latência — e registra qual versão produziu cada resposta, permitindo auditoria e rollback.

Se você versiona o caminho principal mas não o caminho degradado, você tem um produto auditável e um produto fantasma rodando no mesmo endpoint. Quando o fallback assume, suas métricas de qualidade passam a medir um sistema que nunca passou por teste de regressão. O dashboard continua verde. A qualidade, não necessariamente.

A ilusão da redundância

Existe um segundo problema, mais estrutural: concentração operacional. Se prompts, índices, pipelines de avaliação e telemetria estão presos a um único provedor, o fallback tecnicamente existe — e é ilusório na prática. Todos os caminhos dependem da mesma infraestrutura, do mesmo fornecedor ou do mesmo conjunto de dados. A redundância está no diagrama de arquitetura, não na operação.

E há casos em que o melhor plano B nem é outro LLM. Em fraude, crédito e operações de alta criticidade, o fallback mais sensato tende a ser um modelo estatístico ou uma regra de negócio que já existia antes da IA generativa. A vantagem é previsibilidade; a desvantagem é menor cobertura para casos novos. A decisão não é ideológica — é econômica: qual o custo de um falso positivo, de um falso negativo e de uma indisponibilidade? Quem não fez essa conta está escolhendo fallback por conveniência de integração, não por gestão de risco.

Por que isso vale dinheiro

Alguém pode argumentar que isso é perfeccionismo de engenharia. Os números dizem o contrário.

Segundo a pesquisa global The State of AI 2025, da McKinsey, 39% dos respondentes atribuem algum impacto de EBIT à IA — e, entre esses, a maioria reporta que menos de 5% do EBIT vem do uso de IA. Ou seja: o valor capturado ainda é fino. Um sistema que degrada silenciosamente toda vez que o caminho alternativo assume não corrói uma margem gorda; corrói exatamente a fatia estreita de valor que justifica o investimento.

A Deloitte, no relatório State of Generative AI in the Enterprise, aponta a passagem de experimentos para implantação e escala como um desafio central das empresas, com foco em investimento, governança e geração de valor. A Gartner observa que o custo da IA generativa pode variar de valores pequenos a milhões, dependendo da escala e dos requisitos corporativos — e projeta que pelo menos 30% dos projetos de IA generativa serão abandonados após a prova de conceito até o fim de 2025, por dados ruins, controles de risco insuficientes, custos crescentes ou valor de negócio pouco claro. Fallback mal desenhado mora nas duas contas: um roteamento ingênuo para um modelo mais caro em momento de pico é exatamente o tipo de custo que ninguém projetou, e retries sem idempotência podem significar documentos processados duas vezes e ações duplicadas em sistemas externos.

A regulação vai perguntar pelo caminho degradado

No Brasil, o Projeto de Lei nº 2.338/2023 — tratado pelo MCTI como a principal proposta para um regime regulatório de IA baseado em risco, aprovado no Senado e em tramitação na Câmara — aponta para obrigações de rastreabilidade, registro de versões e supervisão proporcional ao risco. Numa abordagem baseada em risco, a pergunta do regulador não será apenas "como seu sistema funciona", mas "como ele funciona quando algo dá errado". O caminho degradado é parte do sistema, não um anexo.

E há a camada de proteção de dados, que já vale hoje: se o fallback envia dados pessoais para um provedor alternativo cujo contrato, jurisdição ou política de retenção são diferentes do principal, o que você chama de contingência pode ser, juridicamente, um incidente. Fallback para fora do perímetro contratado não é resiliência — é vazamento com boas intenções.

O que isso significa para empresas brasileiras

O país vai injetar dinheiro pesado nessa agenda: o Plano Brasileiro de Inteligência Artificial, do MCTI, prevê até R$ 23 bilhões em investimentos ao longo de quatro anos, incluindo um eixo específico de adoção de IA por empresas de diferentes portes e setores. Vai haver capital, infraestrutura e pressão competitiva para colocar IA em produção. A diferença entre quem captura valor e quem vira estatística de projeto abandonado estará nos detalhes operacionais que ninguém posta no LinkedIn.

Para o gestor, o teste de maturidade cabe em quatro perguntas. Primeiro: você consegue listar todos os caminhos degradados dos seus fluxos de IA — modelo alternativo, capacidade reduzida, regra determinística, humano? Segundo: cada um desses caminhos tem avaliação própria, com dataset de referência e limites mínimos de qualidade? Terceiro: você já forçou o fallback a rodar de propósito, em horário de produção, para ver o que acontece — ou está esperando o incidente fazer esse teste por você? Quarto: o contrato de dados do provedor alternativo é equivalente ao do principal?

Quem responde não a duas ou mais dessas perguntas não tem plano B. Tem uma esperança com nome de arquitetura. E esperança, em sistema probabilístico rodando dinheiro de verdade, é o componente mais caro do stack.

Seu fallback de IA nunca rodou em produção. Isso não é plano B — é fé.