Agentes de IA na gestão de tráfego pago: o erro está no dado, não no modelo

O agente de IA que tomou uma decisão errada na sua conta de anúncios não errou por falta de inteligência. Errou porque leu um número que ninguém conferiu antes dele. No começo de setembro de 2026, em uma conta de moda que fatura perto de R$ 1 milhão por mês, um painel de BI mostrou ROAS de 36,9 na semana, alta de 84,3%. O ROAS real era 21,37, alta de 6,7%. Qualquer modelo, do mais barato ao mais caro, teria lido aquele 36,9 e recomendado escalar.

Quando um agente de IA erra na operação de mídia paga, o gestor procura a causa no modelo, no prompt ou na ferramenta. Os incidentes descritos aqui aconteceram entre agosto e setembro de 2026, em contas que a Moyker opera ou acompanha. Nenhum deles envolvia um modelo ruim. Todos teriam enganado qualquer agente que lesse aquele número ou usasse aquela ferramenta. A causa estava antes do agente: no dado de entrada, no efeito colateral de uma ação de escrita ou em uma permissão que ninguém revisou. Trocar de modelo não corrige nenhum desses três. Uma camada de conferência corrige os três.

Esse diagnóstico errado engana muita gente boa, e a Moyker já caiu nele. Um dos incidentes que conto abaixo aconteceu dentro do nosso próprio sistema de sincronização. O que segue é um mapa de onde o erro mora quando a IA passa a operar a conta, e de como reconhecer cada caso antes que ele custe verba.

O que parece ser o problema: modelo, prompt e ferramenta

A reação natural diante de um agente que errou é desconfiar do cérebro dele. O gestor testa outro modelo, reescreve o prompt com mais regras, troca o SaaS de IA por um concorrente que promete mais precisão. Essa reação faz sentido. O mercado vende IA como capacidade de raciocínio, então quando o resultado sai torto, a suspeita recai sobre o raciocínio.

Existe uma razão legítima para essa desconfiança, e ela merece ser dita logo. Há tarefas em que o modelo é sim o gargalo. Redigir variações de copy, resumir uma reunião com cliente, classificar comentários de anúncio por tema. Aqui um modelo melhor entrega texto melhor. O risco de erro é baixo, porque nada é executado sem que alguém leia. Se a sua operação usa IA só para rascunho e leitura, sem acesso de escrita a nenhuma conta, o restante deste texto pesa menos para você. O problema descrito aqui aparece quando o agente lê dado operacional e age sobre ele, ou recomenda uma ação que um humano aprova sem conferir a origem.

O diagnóstico também recai no modelo porque o erro de dado não se parece com erro. Um ROAS de 36,9 não dispara alarme nenhum. Ele chega formatado, no mesmo card, com a mesma cor verde de uma semana boa. O agente recebe um número plausível e faz o que foi desenhado para fazer: raciocinar sobre ele. A Anthropic, ao documentar como constrói agentes, diz que o agente precisa obter "ground truth" do ambiente a cada passo para avaliar o próprio progresso (Anthropic: Building effective agents). Em mídia paga, o ambiente é a plataforma de anúncios, o painel de BI e a loja. Se o ambiente devolve um número falso, o agente avança com confiança sobre uma premissa falsa.

Há ainda um motivo comercial. Quem vende ferramenta de IA para gestão de anúncios compete em inteligência do modelo, não em qualidade do seu dado. Nenhum fornecedor vai abrir a demonstração dizendo que o resultado depende de uma reconciliação que você ainda não faz. Detalhamos esse viés de escolha em Copiloto interno vs SaaS de IA: como decidir sem olhar só o preço da licença.

O que o problema realmente é: três camadas antes do agente

O erro de um agente de IA em mídia paga mora em três camadas, e nenhuma delas é o modelo. A primeira é o dado de entrada. A segunda é o efeito colateral de uma ação de escrita. A terceira é a permissão. Cada uma tem prova de campo, com data e número.

Camada 1: o dado de entrada mente com formato de verdade

Voltando ao caso da abertura. Em 26 de agosto de 2026, o painel de BI que consolidava a mídia daquela conta de moda parou de sincronizar o Google Ads. Ninguém recebeu aviso. Na semana de 26 de agosto a 1 de setembro, o painel mostrava R$ 277,61 de investimento no Google. O Google Ads mostrava R$ 8.340,18 no mesmo período. Uma subestimação de 96,7%.

O custo dessa falha apareceu no número derivado. Com o investimento do Google quase zerado, o total investido caiu 44,3% no painel e o ROAS consolidado subiu 84,3%. O relatório semanal teria saído anunciando um salto histórico em uma semana que foi apenas morna. Um agente configurado para propor aumento de verba quando o ROAS sobe teria proposto exatamente isso.

Quinze dias depois, a quebra continuava. Na semana de 3 a 9 de setembro, o card de total investido mostrava R$ 8.612,36. A soma campanha a campanha do Meta dava R$ 8.612,45. Nove centavos de diferença. O painel contava só o Meta, e os R$ 9.540,96 investidos no Google naquele período tinham sumido.

Outro caso de dado de entrada vem de um produto digital acompanhado pela Moyker no mesmo mês. Em 17 de setembro de 2026, uma mudança na instalação da tag fez o pixel passar a receber o evento de lead duplicado por uma segunda origem no servidor. Em 18 de setembro, o servidor registrou 7.005 eventos de lead. O CRM registrou 2.032 contatos novos. O custo por lead do gerenciador despencou, e o motivo era contagem dupla.

A duplicação atingiu a compra também. Em 21 de setembro, a plataforma de checkout registrou 310 vendas aprovadas e o pixel recebeu 839 eventos de compra, razão de 2,7 vezes. Em um teste de preço rodado de 25 a 27 de setembro, o painel do Meta apontou o preço de R$ 47 como vencedor, com ROAS de 2,19 contra 1,36 do preço de R$ 37. A venda real, contada no checkout, apontou o contrário: R$ 37 com ROAS de 0,97 contra 0,79 do preço de R$ 47. Um agente que lesse o gerenciador escalaria o preço errado.

A Meta documenta como evitar parte disso. O evento do navegador e o evento da API de conversões precisam chegar com o mesmo event_id e o mesmo nome para serem desduplicados (Meta: desduplicação de eventos do Pixel e da API de Conversões). Duas origens no servidor, sem identificador comum, passam pela regra sem colidir. O detalhe técnico está em CAPI. O ponto aqui é outro: nenhum modelo de IA, olhando só o gerenciador, consegue saber que o número está dobrado. Ele precisa de uma segunda fonte para comparar.

O caso mais silencioso envolve receita. Na semana de 24 a 30 de setembro, o card de faturamento de um painel de vendas somou R$ 198.109. O valor efetivamente pago no período foi R$ 170.902. O card usava preço de tabela, sem desconto de Pix nem preço promocional, e inflava a receita em cerca de 16%. Um ROAS calculado sobre aquele card sai 16% mais bonito que o caixa.

Camada 2: a ação de escrita faz mais do que você pediu

Em 2 de setembro de 2026, a Moyker aplicava uma rodada de ajuste de orçamento em uma conta. Usamos uma ferramenta de escrita conectada à API do Meta para alterar o orçamento do conjunto de anúncios da maior campanha. O orçamento mudou. O conjunto voltou pausado. A resposta da ferramenta trazia, entre os campos alterados, um status de pausa que ninguém tinha pedido.

A ferramenta de checagem de erros da conta não acusou nada, porque do ponto de vista dela não houve erro. Houve uma ação executada com sucesso que teve um efeito a mais. A frente principal da conta ficaria sem entrega até alguém abrir o gerenciador. Pegamos porque o nosso procedimento manda reconsultar o status efetivo de cada entidade alterada no fim da rodada.

Esse é o tipo de falha que nenhum benchmark de modelo mede. A requisição pediu a coisa certa, com o parâmetro certo, e a ferramenta fez a coisa certa mais uma coisa errada. O que protegeu a conta foi a conferência depois da escrita, e nenhuma melhoria de raciocínio substitui essa etapa.

Camada 3: a permissão decide o que o agente enxerga e o que ele altera

A permissão atua em dois sentidos. Falta de permissão de leitura produz dado falso. Excesso de permissão de escrita produz estrago.

A falta de leitura apareceu dentro de casa. Em 19 de agosto de 2026, investigando seis clientes cujo Meta parecia parado no nosso painel interno, encontramos um defeito no nosso próprio código de sincronização. Quando uma conta falhava por falta de permissão, o processo registrava a falha em uma lista e, logo em seguida, gravava a sincronização como concluída com sucesso. O orquestrador lia só o status e descartava a lista.

O efeito prático: uma conta sem permissão de leitura e uma conta que não gastou nada no dia ficavam idênticas no banco. As duas apareciam com status de sucesso e zero linhas sincronizadas. No mesmo dia, para a mesma conta, um job registrou erro 403 por falta da permissão de leitura de anúncios, e outro job registrou sucesso com zero linhas. Um agente que analisasse aquela tabela concluiria que o cliente parou de investir.

O limite de escrita, quando bem calibrado, protege. Em 30 de setembro, um usuário de sistema com o escopo de gerenciamento de anúncios no token tentou criar uma conversão personalizada em uma conta de cliente. A API recusou. A função daquele usuário na conta era de Analista, e a Meta exige Anunciante ou superior para gravar. O escopo do token não bastou. A função na conta decidiu.

A OWASP classifica esse risco como agência excessiva e aponta três causas: funcionalidade excessiva, permissão excessiva e autonomia excessiva (OWASP: LLM06 Excessive Agency). A recomendação é dar ao agente só as funções que a tarefa exige. Em mídia paga, isso significa que um agente que produz relatório não precisa de função de Anunciante. Se tiver, um prompt mal interpretado termina em campanha pausada.

Como reconhecer cada camada na sua operação

As três camadas deixam rastros diferentes. Reconhecer qual está em jogo poupa a troca de modelo que não ia resolver nada. Os sintomas abaixo são os que vimos aparecer antes de cada incidente descrito acima.

Sintomas de dado de entrada quebrado

O sinal mais comum é um salto grande em uma métrica derivada sem salto correspondente na métrica de negócio. ROAS sobe 84% e o faturamento da loja sobe pouco. Custo por lead cai pela metade e o CRM recebe o mesmo número de contatos. Quando a métrica de plataforma se descola da métrica do caixa, presuma problema de contagem antes de presumir ganho de eficiência.

Desconfie também de mais de um card zerado na mesma janela. No caso do painel de BI, sessões, taxa de conversão e custo por sessão vieram vazios junto com o investimento do Google. Quando dois ou mais indicadores somem ao mesmo tempo, trate como integração quebrada até a loja provar queda de venda.

Repare quando a razão entre plataforma e loja muda de patamar de um dia para o outro. Antes de 17 de setembro, o produto digital rodava com cerca de 1,4 evento de lead para cada contato novo, por causa de reinscrições que o CRM não conta. Depois, a razão passou de 3. A razão anterior não era perfeita. Ela era estável, e estabilidade é o que permite comparar.

Sintomas de efeito colateral de escrita

O sintoma clássico é queda de entrega logo depois de uma alteração que não tinha relação com entrega. Mudou orçamento e a impressão caiu a zero. Mudou um criativo e o conjunto saiu do ar. Outro sinal é a resposta da ferramenta trazer campos alterados que você não enviou. Leia a resposta de cada escrita campo por campo, além do código de sucesso.

Sintomas de permissão mal calibrada

Aqui o rastro é a ausência de erro onde deveria haver erro. Conta com zero linhas e status de sucesso, todo dia, em um cliente que você sabe que investe. O rastro oposto é um agente pensado para leitura que nunca recebeu uma recusa de escrita, porque tem função de administrador em todas as contas. Se nada nunca foi recusado, nada está limitado.

O que essas camadas não explicam também importa. Um agente de IA que só olha a plataforma de anúncios não enxerga o funil depois do clique. A LR Joias é o exemplo que usamos para lembrar disso. O gargalo dela estava na passagem do produto ao carrinho, e uma mudança no tipo de carrinho na Nuvemshop triplicou a taxa de conversão. Nenhuma leitura do gerenciador de anúncios teria encontrado essa causa. Esse limite está descrito em Quando a IA piora a decisão de mídia (anti-uso documentado).

Como agir: a camada de conferência antes da camada de inteligência

Uma vez reconhecida a camada, a correção não exige ferramenta nova. Exige cinco rotinas com dono, gatilho e ação definidos. A primeira limita a permissão. A segunda protege o dado que entra. A terceira e a quarta protegem a escrita. A quinta define quem aprova.

1. Separe leitura de escrita nas credenciais

No Meta, abra Configurações do negócio, entre em Usuários e depois em Usuários do sistema. Para cada usuário de sistema usado por um agente ou integração, veja a função atribuída em cada conta de anúncios. No Google Ads, abra Administrador, depois Acesso e segurança, e veja o nível de cada usuário e de cada aplicativo conectado.

A regra de decisão tem dois lados. Credencial de agente que só lê e relata fica em Analista no Meta e em Somente leitura no Google Ads. Credencial que escreve fica em Anunciante no Meta e em Padrão no Google Ads, só nas contas onde a escrita é necessária, nunca em Administrador. O caso de 30 de setembro mostra que a função na conta barra a escrita mesmo quando o token carrega o escopo de gerenciamento. Use isso a seu favor.

2. Reconcilie plataforma e loja antes de o agente ler

Todo dia, antes de qualquer agente analisar desempenho, rode três conferências sobre o dia anterior.

Comece pela conversão. No Meta, abra o Gerenciador de Eventos, selecione o pixel, clique no evento de compra e anote o volume do dia anterior. Na loja ou no checkout, conte os pedidos aprovados do mesmo dia, no mesmo fuso horário. Divida um pelo outro.

A referência é a razão média de quatro semanas que um humano validou, e ela fica fixa até esse humano aprovar uma nova. Se a razão do dia se afastar mais de 20% da referência, o agente não usa dado de conversão da plataforma naquele dia. Ele usa o dado da loja e abre um alerta.

Com desduplicação funcionando, a razão fica estável perto de 1. Ela fica um pouco acima quando o pixel conta pedido gerado e a loja conta pedido pago, como no Pix gerado e não pago ou no boleto em aberto. Os 2,7 eventos por venda de 21 de setembro estourariam qualquer referência.

No investimento, compare, plataforma por plataforma, o investimento do dia anterior no painel de BI com o que o próprio gerenciador reporta. Diferença acima de 2% em qualquer plataforma bloqueia a leitura do agente e o relatório da semana até a origem ser encontrada. O painel de moda teria travado no primeiro dia da quebra. Na semana fechada, ele mostrava R$ 277,61 no Google contra R$ 8.340,18 no Google Ads, uma diferença de 96,7%.

Feche com a execução. Todo processo de sincronização que termina com sucesso e zero linhas, em uma conta que gastou nos sete dias anteriores, conta como falha. Abra a conta e veja o gasto do dia anterior. Havendo gasto, a sincronização falhou em silêncio, e o agente não lê aquela tabela até ela ser refeita.

3. Simule antes de escrever

A API do Google Ads aceita requisições de alteração em modo validate_only, que valida a operação sem executá-la (Google Ads API: visão geral de alterações). Se o seu agente ou script escreve no Google Ads, toda alteração passa primeiro por esse modo, e o script guarda cada validação em log. Uma vez por semana, compare esse log com o Histórico de alterações da conta. Alteração sem validação correspondente faz o dono da conta desligar a escrita direta até o fluxo ser corrigido.

No Meta, quando a ferramenta de escrita não oferece simulação, vale a regra de uma entidade por vez: altere um conjunto, leia a resposta, e só então passe para o próximo. Disparar vinte alterações em paralelo multiplica um efeito colateral por vinte. Se a resposta trouxer um campo alterado que não estava na requisição, a rodada para ali e um humano revisa antes da próxima entidade. A única correção automática permitida antes dessa revisão é a da rotina 4: se o campo extra for um status de pausa, o agente reativa a entidade na hora.

4. Confira o estado depois de escrever

Terminada a rodada, ou interrompida pela rotina 3, reconsulte cada entidade alterada. No gerenciador do Meta, olhe a coluna Veiculação. Na API, leia o campo effective_status. Se uma entidade que deveria continuar veiculando voltou pausada, o agente a reativa na hora e reconsulta o status. A reativação devolve o estado que um humano já tinha aprovado, por isso é a única escrita que dispensa aprovação prévia. Se ela também falhar, a rodada para e o humano assume.

Toda reativação desse tipo entra no mesmo registro de aprovações da rotina 5, marcada como correção de efeito colateral, com data, entidade e campo alterado.

5. Defina o que o agente propõe e o que o humano aprova

O Model Context Protocol é o padrão usado para conectar modelos a ferramentas externas. A especificação dele recomenda que sempre haja um humano no circuito com capacidade de negar a execução de uma ferramenta (Model Context Protocol: especificação de ferramentas). Em mídia paga, transforme isso em regra escrita. O agente propõe. O humano aprova toda mudança de orçamento, toda pausa e toda ativação, com a exceção da rotina 4.

Uma vez por semana, cruze o histórico de alterações da conta com o registro de aprovações. No Meta, o histórico fica em Histórico de atividades da conta de anúncios. No Google Ads, em Histórico de alterações. Alteração feita pela credencial do agente que não aparece no registro, nem como aprovação nem como correção da rotina 4, suspende a escrita dessa credencial até um humano revisar o que mudou. A regra vale também para pausa por desempenho. Uma pausa decidida pelo agente com base em um número duplicado é o erro da camada 1 executado com a permissão da camada 3.

A armadilha de trocar o modelo

Existe um motivo pelo qual a troca de modelo parece funcionar. Logo depois da troca, alguém da equipe passa a revisar cada saída do agente com atenção redobrada. Os erros caem. A troca leva o crédito. Na prática, quem resolveu foi a revisão, que é uma camada de conferência feita à mão e sem regra. Quando a atenção volta ao normal, o erro volta.

A Anthropic descreve a mesma tensão por outro caminho. A autonomia dos agentes significa custos maiores e potencial de erros que se acumulam, e a recomendação é testar em ambiente isolado com proteções adequadas (Anthropic: Building effective agents). Erro que se acumula é o que acontece quando o agente usa a saída errada de um passo como entrada do passo seguinte. Um ROAS inflado vira recomendação de verba, que vira aumento de orçamento, que vira mais gasto sobre um número que nunca existiu.

O modelo importa, e não estamos dizendo o contrário. Um modelo mais capaz segue instruções mais longas, erra menos em cálculo e explica melhor o que fez. Só que o ganho de trocar um modelo bom por um modelo melhor é pequeno perto do ganho de impedir que qualquer modelo leia um dado falso. A ordem de investimento é essa: primeiro a conferência, depois a inteligência. Mapeamos o que a automação já faz bem dentro das plataformas em O que a IA realmente automatiza em mídia paga (e o que não). O mesmo raciocínio aplicado ao Meta está em Advantage+ da Meta: quando a automação ajuda e quando esconde desperdício.

A objeção do tempo

Uma operação de e-commerce entre R$ 50 mil e R$ 500 mil por mês em vendas não tem equipe sobrando para reconciliar números todo dia. A reconciliação é exatamente o tipo de tarefa que um agente faz bem, desde que a regra esteja escrita. O passo a passo da rotina 2, com telas e cliques, é a especificação. O agente de conferência executa a mesma leitura pelas APIs de cada plataforma e da loja.

Comparar duas contagens, calcular uma razão, checar se ela saiu de uma faixa e bloquear uma leitura são operações determinísticas. Não exigem julgamento. Separe o agente que confere o dado do agente que analisa desempenho. O segundo só lê o número que o primeiro liberou.

O que continua humano é o dono da regra. Alguém precisa decidir que 20% de desvio trava a leitura de conversão, que 2% de diferença no investimento trava a leitura de mídia, que pausa exige aprovação. Essas decisões são de negócio. Elas dependem de quanto custa um dia de verba mal alocada na sua conta, e esse cálculo nenhum fornecedor de IA faz por você.

As cinco rotinas descritas acima saíram dos incidentes deste texto, um por um, entre agosto e setembro de 2026. A lista vai crescer, porque cada integração nova traz o seu próprio jeito de falhar em silêncio. A definição do que a IA decide e do que fica com o gestor está no glossário IA para tráfego pago, e o recorte específico para loja virtual está em IA para e-commerce.

Quando esse diagnóstico não se aplica

Há operações em que o problema é mesmo o modelo, e vale reconhecer quais são. Se a sua conta tem uma única fonte de dado, sem painel intermediário, com pixel e API de conversões desduplicados por event_id e conferidos, o risco de dado de entrada fica restrito à desduplicação. Se o agente não tem nenhuma permissão de escrita e só gera texto para um humano ler, as camadas 2 e 3 deixam de existir. Nesses cenários, um modelo melhor entrega análise melhor, e a troca vale o custo.

Também há o caso oposto. Em contas muito pequenas, com poucas conversões por semana, a reconciliação diária gera mais ruído do que sinal. Uma razão calculada sobre três pedidos oscila 50% sem que nada esteja quebrado. Aqui a conferência deve ser semanal, e o agente não deve tomar decisão de verba com base em desempenho de um dia, porque nem um humano deveria.

Em IA para tráfego pago em 2026: automação da plataforma ou controle humano, mostramos que a automação da plataforma obedece ao sinal que recebe. A mesma lógica vale para o agente que você mesmo conecta à conta. A plataforma e o agente sofrem do mesmo limite: os dois otimizam o número que chega, e nenhum dos dois sabe se esse número é verdadeiro.

O autodiagnóstico que destrava a decisão

Volte ao último erro de IA que custou alguma coisa na sua operação. Pode ser uma recomendação de verba que não fez sentido, uma pausa que derrubou a entrega ou um relatório com número estranho. Antes de culpar o modelo, responda três perguntas.

O número que o agente leu batia com a loja naquele dia? A ação que ele executou fez só o que foi pedido, e alguém conferiu? A credencial que ele usou precisava ter a permissão que tinha?

Se você não sabe responder a primeira, o seu problema está no dado. Se não sabe responder a segunda, está na escrita. Se não sabe responder a terceira, está na permissão. Se sabe responder às três e o erro continua, aí sim é hora de discutir modelo.

Quantas das três você consegue responder hoje, com dado, sem precisar perguntar para ninguém?