Agente de IA não resolve tudo: o checklist técnico antes de implementar um

O framework que chegou ao board, mas a decisão é de arquitetura

Marcelo Palladino, diretor de AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → & Modernization e líder do Dati Labs na Dati, publicou nesta semana um texto na Exame com três perguntas que todo executivo deveria fazer antes de aprovar orçamento para um agente de IA. Lido do lado de quem assina o cheque, é um texto de contenção de gastos. Lido do lado de quem desenha o sistema, é outra coisa: um checklist de arquitetura disfarçado de pauta de board.

Minha posição aqui é direta. As três perguntas de Palladino não são originais nem revolucionárias, qualquer arquiteto sênior já fazia duas delas antes de a palavra "agêntico" existir. O valor do framework está em forçar o board a ouvir, em linguagem de negócio, o que o time técnico já sabia e raramente conseguia vender para cima.

Pergunta 1: você precisa de um agente ou de um if

A primeira pergunta do framework é: o que aconteceria com uma automação tradicional de regras fixas? Na prática, isso significa comparar o custo de rodar um modelo de linguagem a cada execução com o custo (quase zero, depois de escrito) de um fluxo determinístico.

Se o processo tem passos claros do início ao fim, regra fixa ganha em três frentes: custo por execução, latência e, principalmente, auditabilidade. Um agente que decide o próprio caminho a cada chamada produz uma saída diferente a cada tentativa para o mesmo input, o que é uma vantagem em contexto ambíguo e um problema sério quando compliance pede para reproduzir exatamente o que aconteceu num caso específico.

Palladino também nomeia o meio-termo que muita equipe já usa sem rótulo: um fluxo fixo que chama um modelo só num ponto específico, para classificar um e-mail ou extrair campos de um documento. Isso não é um agente, é uma função com um LLM dentro, e a diferença de custo e de superfície de risco entre as duas abordagens é enorme.

Pergunta 2: seu sistema legado é idempotente, ou isso nunca foi testado

A segunda pergunta é a que, na minha leitura, mais expõe dívida técnica antiga sendo cobrada com juros. Um agente que conversa com um sistema legado lento vai, em algum momento, reenviar uma requisição que não recebeu resposta a tempo. Se o backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → não sabe identificar que aquele pedido já foi processado, o resultado é cobrança duplicada, nota fiscal duplicada, pagamento duplicado.

O ponto central aqui não é sobre IA. É sobre o seu sistema ter, ou não, uma chave de idempotência (idempotency key) nos endpoints críticos, algo que times de pagamento já tratam há anos com padrões como o do Stripe. A diferença é que, antes, essa falha só aparecia em pico de tráfego ou em retry de cliente com conexão ruim. Com um agente no meio, ela aparece toda vez que o modelo decide tentar de novo.

Se a resposta sincera for "não sei se nosso sistema trata isso", a prioridade de engenharia não é desenhar o agente. É instrumentar o legado antes.

Pergunta 3: o agente reúne os três ingredientes da trinca letal

A terceira pergunta é a de segurança, e é a que eu mais recomendo levar literalmente para uma reunião de arquitetura. Palladino cita o termo cunhado pelo pesquisador independente Simon Willison, conhecido por criar o framework Django: a "trinca letal" (lethal trifecta, no original). Ela descreve a combinação de três fatores num mesmo agente:

1. Acesso a dados privados ou confidenciais da empresa.
2. Capacidade de ler conteúdo externo não confiável (e-mail, página web, formulário recebido de fora).
3. Algum canal de comunicação para fora, mesmo que seja só carregar uma imagem com dados embutidos na URL.

Quando os três coexistem no mesmo agente, um ataque de prompt injection escondido num e-mail ou numa página pode instruir o modelo a vazar dados internos sem que ninguém perceba em tempo real. A resposta de Palladino para isso é correta e é a mesma que eu daria: a mitigação não pode depender de treinar a equipe para "tomar cuidado". Tem que estar na arquitetura, impedindo estruturalmente que um único agente acumule os três fatores ao mesmo tempo.

Há um detalhe técnico no texto que merece destaque: se você divide o trabalho entre vários agentes especializados para separar os três fatores, a comunicação entre eles precisa ser por dados estruturados (JSON, formulário, schema definido), nunca por texto livre. Passar texto livre de um agente para outro é reabrir a porta para a mesma instrução maliciosa atravessar a fronteira que você acabou de desenhar.

O contra-argumento: "mas os guardrails de plataforma já resolvem isso"

O ponto mais forte contra esse framework é dizer que as grandes plataformas de agentes já oferecem camadas de permissão granular, sandboxing e políticas de function calling que mitigam a trinca letal por padrão, tornando a checagem manual redundante. Não é um argumento fraco: ferramentas assim reduzem a superfície de ataque, e ignorá-las seria retrocesso.

O problema é que guardrail de modelo é probabilístico, não determinístico. Ele reduz a chance de um ataque funcionar, não a elimina, porque continua dependendo do modelo interpretar corretamente uma instrução adversarial escrita justamente para enganar essa interpretação. Arquitetura que impede a combinação dos três fatores na estrutura do sistema é determinística: não existe uma versão de prompt injection que quebre uma permissão que o agente simplesmente não tem.

Em resumo: guardrail de plataforma é camada adicional, não substituto da decisão de arquitetura. As duas coisas deveriam coexistir, mas se o board só financiar a primeira porque é mais barata de explicar numa reunião, o risco real não caiu, só ficou invisível.

Onde o agente realmente paga a conta

O próprio Palladino é honesto sobre o outro lado: processos com documentos não padronizados, contratos longos, notas fiscais inconsistentes e atendimento que exige julgamento sobre um histórico específico de cliente são exatamente onde regra fixa não escala e o agente compensa o custo mais alto por execução.

A diferença prática para quem constrói é que esse contexto não é raro, mas também não é a maioria dos processos de uma empresa típica. O erro que o framework ajuda a evitar não é usar agentes, é usar agente como resposta padrão para qualquer ticket que mencione automação, sem antes rodar as três perguntas pela arquitetura que já existe.

Fonte: Exame