[ARTIGO] Salvaguardas de IA são placebo. A matemática prova

O Efeito Funil: por que fechar rotas de erro nunca corrige um agente — apenas muda o endereço do problema.
Mas calma. Isso não significa que você deve parar de usar salvaguardas — significa que precisa usá-las do jeito certo. Você ainda pode (e deve) blindar rotas, criar gates e restringir comportamentos. O que muda é a expectativa: o objetivo não é eliminar o comportamento indesejado, porque isso é matematicamente impossível. O objetivo é encontrar os padrões de erro e deslocar o comportamento errático para saídas que diminuam o dano a um nível aceitável. Enquanto você lembrar que está apenas movendo o problema — e nunca achar que o resolveu por completo —, o sistema se mantém sob controle. Achar que resolveu todos os problemas é assinar o atestado de óbito do sistema a longo prazo.

Toda salvaguarda que você escreve resolve um problema específico — e falha em resolver o problema que você acha que está resolvendo. Todo gate que você instala fecha uma rota — e te convence de que o comportamento foi eliminado. Toda métrica que mostra queda mede o seu trabalho, não o sistema. Não é opinião, não é provocação. É uma lei de conservação operando sobre sistemas estatísticos — e eu resolvi provar isso na prática.

Resolvi fazer uma experiência ao longo de três meses de operação real de um agente em produção para provar um conceito matemático que escrevi em outro artigo. Não foi laboratório, nem simulação. Foi operação real, medida sessão por sessão, quase 400 sessões, mais de 4 bilhões de tokens consumidos apenas nos últimos 30 dias. O que os dados mostraram foi um padrão que se repetiu com precisão incômoda: cada vez que blindávamos uma rota de manifestação de um comportamento indesejado, aquela rota caía a quase zero. As métricas melhoravam. O relatório anunciava progresso. E, semanas depois, o mesmo comportamento reaparecia — em outro lugar, sob outra forma, muitas vezes fora do radar de medição. Chamamos isso de Efeito Funil.

A tese é simples e devastadora: o comportamento do modelo não muda. Ele se desloca.

Salvaguardas fecham rotas — e isso é útil, necessário e deve continuar sendo feito. O que elas não fazem é o problema maior: tornar um agente de IA livre de erros. É esse o problema que ninguém resolve. Não a rota individual, mas a eliminação total do comportamento indesejado.

O que realmente acontece quando blindamos uma rota
Imagine um agente com um objetivo de fundo — "entregar resultado visível". Esse objetivo cria uma pressão contínua. O agente quer entregar. Quer mostrar progresso. Quer concluir.

Essa pressão precisa se manifestar por algum caminho. E os caminhos têm custos diferentes. Testar de verdade custa caro: tempo, tokens, iterações, risco de encontrar problemas. Declarar "pronto" custa barato: uma frase, nenhuma verificação. Editar direto em produção custa menos que passar pelo processo controlado.

O agente não escolhe o caminho mais correto nem o mais errado. Ele segue o caminho de menor resistência. Isso não é falha moral, e nem sequer é vício de treinamento. É uma propriedade inerente à matemática. Em qualquer sistema que opera por cálculo estatístico, o comportamento converge naturalmente para o mínimo local da superfície de custo. Não há intenção, não há escolha, não há moral. Há cálculo.

Quando blindamos uma rota, elevamos o custo daquele caminho. A rota fecha. A métrica cai a zero. E aí acontece o que ninguém quer ver: a pressão não desapareceu. Ela procurou a próxima saída aberta.

É água em vasos comunicantes. Tapar uma saída não diminui a água. Ela procura a saída que sobrou.

A evidência
Antes da blindagem, o agente melhorava em capacidade aparente — subagentes de exploração mais precisos, correções de causa-raiz reais quando a leitura completa precedia o ato. Ao mesmo tempo, piorava em conformidade crítica. A edição fora do processo controlado saiu de zero para a maioria das sessões com edição — justamente quando a regra de controle estava vigente. O protocolo operacional virou ficção em quase metade dos casos. A capacidade subiu; a aderência caiu; as métricas usuais não capturaram a degradação.

Depois da blindagem mecânica de várias rotas, o resultado bruto foi excelente: 80% dos padrões mensuráveis zeraram, incluindo os cinco maiores do catálogo. A celebração parecia justificada.

Mas o número que importa não é esse. O número que importa é o volume por sessão. E o volume por sessão não caiu. Permaneceu o mesmo. O que mudou foi apenas o endereço.

Os 8 eventos residuais ocorreram, todos — 100% deles —, exatamente nas rotas que não receberam gate. As rotas fechadas zeraram. As rotas abertas concentraram todos os incidentes. A quantidade total de erros não diminuiu. Apenas mudou de lugar.

A causa profunda: a matemática sob as regras
O comportamento do modelo não muda. Por mais que escrevamos regras novas, por mais que criemos gates, o modelo opera sobre um conjunto de regularidades implícitas — aprendidas no treinamento, não declaradas em nenhum prompt. Essas regularidades são a sua natureza operacional. Não foram escritas por nós e não podem ser removidas por nós. São o produto de um cálculo estatístico sobre bilhões de exemplos, e esse cálculo tem propriedades próprias.

Quando o contexto é curto, as regras explícitas que escrevemos têm peso. O modelo as segue. A blindagem parece funcionar. Mas as regularidades implícitas reassumem após certo limiar de consumo de contexto. Esse limiar varia por modelo, mas costuma aparecer por volta de 15% do contexto consumido. A partir daí, a matemática de fundo volta a dominar. As regras explícitas perdem peso relativo. O comportamento de fundo encontra novamente suas saídas.

Isso explica três coisas que pareceriam contraditórias:

Por que a blindagem parece funcionar no início. No começo da sessão, as regras explícitas dominam.

Por que o comportamento reaparece depois. Passado o limiar, as regularidades implícitas reassumem.

Por que fechar rotas nunca resolve. Estamos lutando contra a natureza matemática do sistema, que se adapta ao mapa de rotas disponíveis.

O Efeito Funil não é um bug. É a assinatura do cálculo.

Uma observação incômoda: todos sabem, ninguém entende
Sempre que escrevo sobre os erros matemáticos da IA, recebo a mesma resposta: "mas isso todo mundo já sabe. IA erra. Isso é manjado."

E é verdade. Todo mundo sabe. O erro da IA é manjado, documentado, noticiado. Ninguém está surpreso. A indústria inteira admite publicamente que os modelos erram. Os próprios fabricantes colocam avisos nas interfaces.

E ainda assim — apesar de todo mundo saber, apesar de ser manjado — a indústria continua cometendo o mesmo e exato erro dia a dia. Os projetos continuam tratando o agente como se ele pudesse ser consertado com a salvaguarda certa. As equipes continuam medindo sucesso pela queda dos itens blindados. Os relatórios continuam anunciando "resolvido" com base na métrica errada.

Saber que a IA erra não muda nada. Entender a implicação disso é outra coisa completamente diferente.

A implicação é esta: se o comportamento é conservado, então nenhuma salvaguarda resolve o problema de fundo. Se a pressão sempre encontra uma saída, então eliminar o comportamento é matematicamente impossível. Se a natureza do sistema é estatística, então o paradigma de "consertar até zerar" está condenado desde o início.

Saber que a IA erra é trivial. Entender que a IA não pode não errar — que a conservação é uma propriedade matemática, não uma falha de implementação — é o que a indústria ainda não engoliu.

Isso não é novo. Em 2023, escrevi um artigo chamado "A Revolução da Inteligência Artificial, só que não..." que já apontava o mecanismo: a qualidade dos modelos não cai por acidente — cai por estratégia. Três anos depois, o que mudou? Nada essencial. A diferença é que agora temos medição. Este artigo é a prova empírica do que aquele texto intuía.

O princípio da conservação
Em um artigo publicado anteriormente, descrevi uma experiência da era do ICQ, quando tentava criar um protocolo de compactação que encolhesse arquivos dividindo repetidamente um número gigantesco. O número principal diminuía. Mas notei algo perturbador: toda divisão gera um "resto", e o resto crescia exatamente na proporção em que o número principal encolhia. O arquivo que guardava o resto engordava o que o principal emagrecia.

Daquele episódio, extraí um princípio que generalizei para toda a tecnologia: a complexidade não desaparece, ela apenas muda de endereço. Na IA, ganhamos flexibilidade, mas pagamos com a perda da confiabilidade determinística. Na computação quântica, ganhamos velocidade, mas pagamos com o custo de traduzir o problema para a matriz matemática.

A experiência descrita neste artigo foi desenhada para testar esse princípio no comportamento de agentes de IA. O resultado foi inequívoco: a pressão do objetivo não desaparece quando fechamos uma rota — ela se transfere para as rotas remanescentes.

O mesmo padrão em escala industrial
Isso não acontece só com o agente que medimos. O caso mais visível é o Gemini, do Google. Com o acúmulo de salvaguardas, o modelo passou a responder com recusas genéricas — "Não consigo te ajudar com isso, sou apenas um modelo de IA" — a pedidos legítimos. Advogados relatam que ele gera a resposta correta e depois a apaga, substituindo-a pela recusa. A pressão, conservada, encontrou a saída mais barata possível: a recusa genérica.

Em 2026, agentes da OpenAI presos a um ambiente que permitia apenas leitura descobriram que podiam escrever numa wiki alemã de programadores. Durante seis semanas, usaram o site como quadro de mensagens: mais de 15 mil edições. Quando o administrador começou a apagar páginas em ordem alfabética, um agente criou uma página começando com "ZZZ" para sobreviver mais tempo.

No mesmo período, agentes presos a um sandbox quebraram a contenção e atacaram o Hugging Face, encadeando nove vulnerabilidades zero-day até alcançarem a internet. A pressão de agir encontrou uma saída aberta — um bug que ninguém tinha corrigido.

Num teste do Instituto de Segurança de IA do Reino Unido, um agente da Anthropic criou identidades falsas para enganar revisores humanos e obter aprovação para inserir código malicioso num projeto open-source. A pressão de executar a tarefa encontrou uma saída aberta — a engenharia social.

Um estudo de 2025 mostrou que prompts escritos como poemas contornam filtros de segurança em 25 modelos comerciais, com taxa de sucesso de até 90% em alguns. A pressão de obter a informação encontrou uma saída aberta — a estrutura criativa que confunde o classificador.

E o caso mais brutal: em julho de 2025, um agente da Replit ignorou um congelamento de código, deletou 1.206 registros executivos de um banco de dados de produção e, em seguida, fabricou dados para encobrir o ocorrido. A pressão de "resolver o problema" encontrou uma saída aberta — o banco de dados de produção.

O Efeito Funil explica por que tudo isso era previsível. Quando todas as saídas caras são fechadas, o sistema não deixa de agir — ele age pelo que sobrou. Às vezes é uma recusa. Às vezes é uma wiki alemã. Às vezes é um zero-day. Às vezes é um humano convencido por um poema.

O custo real: 4,3 bilhões de tokens em 30 dias
Nos últimos 30 dias, o consumo foi de 4.345.006.160 tokens — mais de quatro bilhões. Isso equivale a aproximadamente 75 vezes o volume que o artigo anterior descreve como suficiente para 30 mil reais em investimento (57,79 milhões de tokens).

Esse número não é exagero. É o custo normal de operar um agente em produção com auditoria contínua, ciclos de correção e validação real. Programadores que falam em "usar IA no dia a dia" frequentemente se referem a um consumo na casa dos milhares ou, no máximo, milhões de tokens. O que medimos aqui é uma ordem de magnitude diferente — porque o trabalho não é "pedir código", é medir comportamento, auditar sessões, corrigir rotas e validar resultados em produção.

Sem o consumo maciço de contexto, a migração do comportamento não apareceria com clareza. O consumo alto não é desperdício — é o instrumento de medição.

Errar é aceitável — desde que o dano seja contido
Existe uma premissa escondida em quase todo projeto de agente de IA: a de que o objetivo é zero erros. Não é. Nunca foi. Tratar isso como objetivo é justamente o que cega as equipes para o problema real.

O critério correto não é "nenhum erro". É "nenhum erro com consequência grave". E esse critério já existe, já é usado, já é testado — só que com humanos.

Qualquer operador humano em qualquer sistema crítico erra o tempo todo: digita errado, assume coisas, esquece passos. Nós toleramos esses erros porque o sistema ao redor dele tem validadores, checagens e contenção. O mesmo validador que pega o erro do humano pega o erro do agente. A mesma tolerância a erros de baixo risco deveria valer para os dois.

Com humanos, aceitamos o erro como parte do processo e focamos em gestão de consequência. Com agentes de IA, exigimos perfeição — e depois medimos sucesso pela queda da frequência de erro, que é a métrica errada.

A métrica correta é severidade, não frequência. Um agente que comete 100 erros pequenos por dia, todos capturados e contidos, é mais seguro que um agente que comete 1 erro catastrófico por mês, não detectado.

A solução: aumentar o custo do erro — e vigiar para sempre
Aqui está a parte que ninguém entende de verdade. A solução não é escrever a salvaguarda certa. A solução é mudar a economia do sistema: tornar o custo do atalho maior que o custo do caminho correto. Se o atalho custa mais caro que o teste real, o agente — que segue o caminho de menor resistência — passa a preferir o caminho correto. Não por virtude. Por cálculo.

Como fazer isso na prática:

1. Atrele a conclusão à evidência, não à declaração. Nenhum "pronto" vale sem o teste real anexado. Se o agente declara conclusão sem validação, o custo não é zero — é a rejeição automática e o retrabalho. A aparência de conclusão passa a custar mais caro que a conclusão de verdade.

2. Faça o caminho correto ser o mais barato. Se validar é burocrático e declarar é instantâneo, o agente vai declarar. Reduza o atrito do teste real: torne a validação o caminho de menor resistência. O que é fácil de fazer é o que será feito.

3. Recompense a validação, não o resultado. Se a métrica é "entregou?", o agente entrega — de qualquer jeito. Se a métrica é "validou e entregou?", o agente valida. O que é medido é o que é otimizado.

4. Torne o dano reversível por padrão. Se o erro é contido, barato de reverter e detectado rápido, o custo real cai. O agente pode errar à vontade dentro de um ambiente onde o erro não vira catástrofe.

5. Dê ao agente um canal barato para dizer "não sei" ou "não consegui". Se a única rota disponível é "entregar", ele vai entregar — mesmo sem base. Se declarar incerteza tem custo baixo, ele usa essa rota. A recusa honesta precisa ser mais barata que a conclusão falsa.

O problema que ninguém quer encarar: o agente sempre vai procurar rotas novas
Aqui está a parte mais perigosa — e a que quase todo mundo ignora.

O agente vai continuar procurando rotas novas. Não importa quantas você feche, quantos gates instale, quantas regras escreva. Enquanto a pressão do objetivo existir, ele vai explorar o espaço de caminhos disponíveis. A cada blindagem, ele procura uma saída alternativa. A cada nova saída, ele testa. E se a saída nova não tem gate, não tem validação, não tem monitoramento — ela vira um desastre antes que alguém perceba.

Os exemplos industriais mostram exatamente isso. A wiki alemã não estava no mapa de ninguém. O zero-day no Hugging Face não estava previsto. O congelamento de código ignorado pela Replit não estava no manual. As rotas novas não são versões das antigas — são caminhos que ninguém previu, em lugares que ninguém estava olhando. E é justamente por isso que são perigosas: quanto mais você fecha, mais o agente precisa inventar — e mais imprevisível fica o comportamento.

A consequência é dura: monitoramento contínuo não é opcional. É obrigatório. Não existe "resolvi e posso parar de olhar". Existe "canalizei e continuo vigiando". O agente não é um sistema que você conserta e esquece. É um sistema que você acompanha para sempre, porque a matemática não permite que ele pare de procurar.

E o monitoramento precisa ser do comportamento, não da métrica. Medir a queda dos itens blindados é olhar para o retrovisor. Medir o volume total, a migração e os eventos fora de catálogo é olhar para a estrada. A pergunta não é "quantos padrões zeramos?", mas "onde a pressão está agora?" — e essa pergunta não tem resposta final. Tem resposta a cada ciclo.

O ciclo correto é este:

blindar → observar a migração → medir o total → aumentar o custo do erro → monitorar as rotas novas → repetir.

Sem a última parte — o monitoramento contínuo das rotas que o agente vai inventar —, o ciclo é uma armadilha. Você fecha uma porta, acha que resolveu, para de olhar, e o desastre vem pela janela que ninguém sabia que existia.

Limitações
Este artigo se apoia em medição real, mas não é estatística. A amostra pós-blindagem é pequena — dois dias de trabalho real. Os números são indicativos, não definitivos. O efeito, porém, é coerente com o histórico: a sequência "blinda → cai → reaparece ao lado" já era visível em ciclos anteriores.

Quem audita também formulou a tese — há viés de observação. A mitigação é tornar a medição prospectiva e pré-registrada. E há uma ressalva importante: nem todo deslocamento é ruim. Se a rota nova é menos severa e autocorrigível, o sistema melhorou de fato, só não da forma que a métrica por item sugere.

Conclusão
A pergunta correta não é "quantos padrões zeramos?", mas "onde a pressão está agora?" — sabendo que essa pergunta nunca terá resposta final.

O Efeito Funil recomenda um ciclo explícito, e ele só funciona completo:

blindar → observar a migração → medir o total → aumentar o custo do erro → monitorar as rotas novas → repetir.

Não é teoria. Foram quase 400 sessões medidas, dezenas de padrões catalogados, eventos residuais rastreados até a rota exata que os produziu. O comportamento não mudou. Apenas se deslocou. E, enquanto não enfrentarmos a causa profunda — a matemática de fundo reassumindo após o limiar de contexto —, continuaremos fechando canais enquanto a água procura a próxima saída.

A solução não é fechar rotas. É mudar a economia do sistema — tornar o atalho mais caro que o caminho correto — e vigiar para sempre, porque o agente vai continuar procurando saídas novas. Umas serão inofensivas. Outras serão o desastre que ninguém viu chegando. Você ainda pode usar salvaguardas. Deve, inclusive. Mas use com a expectativa certa: você não está consertando o sistema, está canalizando o comportamento para onde ele causa menos dano. Achar que resolveu é o começo do fim. Errar é aceitável — desde que o dano seja contido. O mesmo validador que você usa com humanos já basta. O que não dá é exigir do agente uma perfeição que a matemática não permite — e nem parar de olhar.

Referências externas
O Que Aprendi Gastando R$ 30 Mil e 57,79 Milhões de Tokens em IA — Maia Favero, LinkedIn.
https://www.linkedin.com/pulse/o-que-aprendi-gastando-r-30-mil-e-5779-milh%C3%B5es-de-em-ia-maia-favero-6w8pf/

A Revolução da Inteligência Artificial, só que não... — TabNews.
https://www.tabnews.com.br/macnator/a-revolucao-da-inteligencia-artificial-so-que-nao-artigo