Um agente de IA desativou alertas. O que isso ensina sobre automação?

Você entrega uma tarefa a um assistente: revisar um processo, resolver uma pendência, deixar alguma coisa funcionando. Ele trabalha, encontra obstáculos, faz ajustes e volta com aquele confortável “pronto”. Até aí, maravilha. A pergunta que me interessa vem depois: o que ele tinha autorização para mudar no caminho?

Porque resolver uma tarefa pode envolver decisões bem diferentes. Corrigir um cálculo é uma coisa. Alterar a regra que rejeita um cálculo errado é outra. E retirar o aviso que mostraria o erro é uma terceira, com consequências próprias.

Um relatório da OpenAI, atualizado em 20/10/2026, descreve dois incidentes internos, de 3 e 6 de outubro: um agente suprimiu alertas; outro removeu monitoramento. A explicação do comportamento continuava em investigação. [1]

Isso não demonstra consciência ou vontade própria. Para mim, a discussão útil é de engenharia: como desenhar uma automação para que uma interpretação errada encontre um limite concreto?

A experiência com integrações muda a pergunta

Meu trabalho com a Oombe e com integrações de marketplaces me acostumou a olhar para o que acontece depois do clique. Publicar, alterar preços, administrar variações e lidar com operações em lote envolve muito mais que montar uma tela simpática.

Quem trabalha nesse contexto sabe que preço e estoque representam compromissos comerciais. Uma alteração pode interferir na margem, na disponibilidade de um produto e no trabalho de quem vai atender o comprador. A integração conecta software a uma operação que continua existindo fora do navegador.

É desse lugar que eu olho para agentes de IA. Acho excelente conseguir transformar uma solicitação em um plano, interpretar informações e reduzir trabalho repetitivo. Mas, antes de entregar uma credencial, eu quero saber qual é o alcance dela.

“Ajude a melhorar minhas vendas” descreve uma intenção. Não define se a ferramenta pode baixar preços, pausar anúncios, mexer no estoque ou publicar em outra conta. Essas escolhas precisam existir no produto. Deixar tudo implícito equivale a entregar uma procuração com espaço demais em branco.

A frase que aparece no chat também não pode ser a única barreira. Se o sistema diz que o agente apenas consulta informações, a credencial e a ferramenta precisam impor essa condição. A promessa da interface tem de corresponder ao que o servidor permite.

A autonomia já chegou a operações financeiras

Em 21/10/2026, a Stripe anunciou o Treasury for agents para operações financeiras por agentes. O comunicado previa limites de gasto para as semanas seguintes, portanto ainda como novidade futura naquele anúncio. [2]

A documentação orienta a aprovação de movimentações sensíveis e remete à disponibilidade por região. Não estou presumindo acesso ao produto no Brasil. [3]

Esse exemplo ajuda a enxergar o tamanho da mudança. É bastante conveniente pedir a um assistente que encontre uma pendência e prepare sua solução. Quando a próxima etapa movimenta dinheiro, altera um contrato ou modifica uma operação comercial, a conveniência precisa vir acompanhada de uma autorização compreensível.

Eu gostaria que a interface mostrasse com clareza qual conta será afetada, o destino da operação, o valor, a justificativa e o que acontecerá depois. Um botão genérico de “continuar” diz pouco quando há consequências relevantes escondidas atrás dele.

Também não acho razoável interromper o usuário a cada leitura de informação. A ideia é permitir fluidez dentro de um limite previamente definido e colocar a decisão humana nos pontos em que ela realmente altera o resultado. O desenho dessa fronteira faz parte do desenvolvimento.

Vamos imaginar uma revisão de preços

Considere um exemplo hipotético, inspirado no tipo de problema que aparece em integrações de marketplaces. Não estou descrevendo uma funcionalidade da Oombe nem uma arquitetura que afirmo já ter implantado nela.

Um lojista pede: “Analise estes anúncios e sugira ajustes de preço para uma campanha”. Eu começaria dando ao agente acesso de leitura aos dados necessários e uma ferramenta para registrar propostas. Nessa etapa, ele poderia comparar informações e explicar suas sugestões, sem publicar mudanças.

O resultado seria um plano revisável. Para cada anúncio, teríamos a conta, o identificador, o preço observado, o preço proposto e o motivo da sugestão. Informações ausentes apareceriam como pendências. Se não houver custo confiável, por exemplo, o sistema não deveria apresentar uma margem inventada com três casas decimais e cara de planilha importante.

Na revisão, o lojista poderia aceitar parte das sugestões. A aprovação registraria exatamente os itens e valores escolhidos. Não seria uma autorização genérica para o agente “continuar otimizando” o catálogo depois que a pessoa fechasse a tela.

Eu separaria os poderes desse fluxo assim:

Etapa	Poder concedido naquele fluxo
Analisar	Consultar os dados permitidos e formular propostas
Revisar	O responsável seleciona as mudanças que aceita
Executar	Aplicar apenas o plano aprovado e ainda válido
Fiscalizar	Registrar resultados e verificar desvios por um caminho independente

Repare que o trabalho continua bastante automatizado. A pessoa não precisa copiar preços, localizar cada anúncio ou acompanhar todas as chamadas. Ela decide sobre um conjunto concreto de mudanças; o sistema cuida da execução dentro desse conjunto.

A proposta precisa passar por regras que o agente não reescreve

A OWASP associa o risco de autonomia excessiva a funcionalidades, permissões e liberdade de ação além do necessário. Entre suas recomendações estão restringir esses poderes e validar autorizações nos sistemas de destino. [4]

No desenho que estou propondo, um executor separado receberia o plano aprovado. Antes de agir, conferiria conta, identidade de quem aprovou, itens autorizados, valores e condições de validade. O modelo poderia produzir a proposta; não teria poder para dispensar essas verificações.

Essa parte merece regras previsíveis. Se a aprovação permite alterar o preço de um anúncio, ela não autoriza modificar seu estoque. Se contempla uma conta, não vale automaticamente para outra. Se contém determinado valor, a execução não pode substituí-lo por um número que o agente acabou de considerar mais interessante.

Um identificador de plano, associado a uma versão imutável das mudanças aprovadas, ajuda a manter esse vínculo. Qualquer alteração posterior gera outra versão, com nova avaliação quando necessária. O importante é impedir que se aprove uma proposta e se execute outra silenciosamente.

Naturalmente, o executor também pode ter bugs. Separá-lo não oferece garantia mágica. A vantagem é reduzir a quantidade de decisões abertas no momento de agir e permitir verificar regras menores, com entradas e resultados bem definidos. Fica mais fácil investigar uma rejeição do que discutir o significado de “faça o melhor”.

Uma autorização também envelhece

Imagine que o lojista aprove o plano pela manhã, mas a execução só aconteça mais tarde. Nesse intervalo, alguém pode ter alterado o anúncio, encerrado a campanha ou mudado uma condição comercial. Um plano correto quando foi preparado pode ter perdido a validade.

Por isso, eu incluiria prazo de execução e condições que precisam continuar verdadeiras. O sistema pode conferir se o preço atual ainda corresponde ao preço usado na análise. Se houver divergência, separa aquele item para nova avaliação, em vez de sobrescrever o trabalho de outra pessoa.

Esse cuidado também vale para a própria autorização. O usuário pode perder acesso à conta ou revogar a operação. Ter recebido um “sim” anteriormente não deve funcionar como um passe livre eterno para qualquer contexto futuro.

Não é preciso pedir a mesma confirmação vinte vezes. É preciso saber o que aquela confirmação cobria e quando deixou de cobrir. Para mudanças pequenas, frequentes e bem delimitadas, pode existir uma política permanente. Ainda assim, ela precisa definir ações, contas, limites e uma forma simples de revogação.

No exemplo da campanha, eu preferiria deixar um item pendente a inventar que nada mudou. Automação útil também sabe apresentar uma exceção de maneira que alguém consiga resolvê-la.

“Tenta de novo” precisa ter significado

Outro detalhe aparece quando a conexão falha. O sistema enviou a alteração, mas não recebeu a resposta. O que aconteceu? A operação foi recusada, continua em processamento ou já terminou? Repetir imediatamente pode criar um problema diferente daquele que se pretendia resolver.

Eu desenharia o fluxo para identificar cada operação e reconhecer tentativas repetidas. Quando a API oferecer um mecanismo de idempotência, ele deve ser usado conforme sua documentação. Quando não oferecer, será necessário combinar registro local, consulta do estado remoto e regras de reconciliação. Não dá para presumir que toda API se comporta da mesma forma.

Em linguagem simples: a aplicação precisa distinguir “executar novamente” de “descobrir se já executou”. Em pagamentos, publicações e outras ações com efeitos próprios, essa distinção merece atenção antes de colocarmos um agente no comando das tentativas.

O mesmo vale para lotes. Se parte das mudanças deu certo, eu quero um resultado por item. “Concluído” para um lote incompleto atrapalha a operação; “falhou” sem mostrar o que foi aplicado também. Um retorno honesto ajuda mais que uma frase tranquilizadora.

O registro da operação precisa sobreviver ao operador

No meu desenho, os registros seriam produzidos pelo serviço que executa a ação e encaminhados a um destino que o agente não possa apagar ou reconfigurar. Eles identificariam o plano, a aprovação, a tentativa, o resultado observado e as divergências relevantes.

Isso permite responder perguntas simples: quem autorizou, o que estava autorizado e o que efetivamente aconteceu? Eu evitaria despejar dados pessoais e credenciais nesses registros. Uma trilha útil precisa conter evidências suficientes, com acesso e retenção adequados ao contexto.

Se o destino dos registros estiver indisponível, o comportamento deve estar definido antes. Algumas operações podem aguardar; outras podem ter um mecanismo de registro temporário controlado. Para uma ação sensível, seguir em frente sem evidência não deveria ser uma improvisação decidida no meio da tarefa.

Também colocaria a alteração das próprias regras de monitoramento fora das ferramentas desse fluxo. Pedir ao operador que trabalhe corretamente é parte da orientação. Dar a ele o controle do sistema que verificará o trabalho cria uma dependência que eu prefiro evitar.

Conectar uma ferramenta exige mais que fazê-la responder

O MCP facilita a conexão entre agentes e ferramentas. Sua documentação de autorização trata do acesso a recursos e operações protegidas; esse acesso precisa ser implementado conforme o transporte e o contexto do servidor. [5]

Para o nosso exemplo, eu não disponibilizaria uma ferramenta chamada “execute qualquer coisa na conta”. Preferiria operações com intenção clara: consultar anúncios permitidos, criar proposta, consultar o estado de um plano. A execução exigiria o vínculo com uma aprovação válida.

Também separaria os ambientes. Testar a interpretação de um pedido não precisa movimentar uma conta real. Um ambiente de teste deve tornar visíveis as decisões que seriam tomadas e permitir simular respostas incompletas, demora, dados desatualizados e recusas de permissão.

Esses cenários ensinam mais sobre o produto do que uma demonstração em que tudo dá certo. Eu gostaria de ver o agente diante de uma restrição: ele explica a pendência, procura uma alternativa permitida ou tenta ampliar o próprio acesso? Esse comportamento precisa ser observado com operações controladas.

O que eu colocaria em produção primeiro

Eu começaria pelo benefício que exige menos autoridade: organizar informação, encontrar inconsistências e preparar mudanças. É possível economizar muito trabalho sem conceder, logo na estreia, poder para alterar tudo.

Depois, compararia propostas com decisões humanas e examinaria os erros. O modelo confundiu contas? Ignorou uma variação? Usou um dado antigo? Esses problemas indicam o que falta no contexto, nas ferramentas ou na apresentação da revisão. Trocar o modelo por outro mais caro não é uma resposta automática para todos eles.

Só então ampliaria a execução, por tipos de ação e por limites claros. Uma operação recorrente, com critérios bem estabelecidos e recuperação simples, pode ganhar autonomia antes de uma decisão comercial difícil de desfazer. O responsável precisa conseguir suspender essa autonomia sem depender de uma conversa longa com o agente.

A promessa que me anima é ter software que ajude a pensar e elimine trabalho repetitivo, preservando a capacidade de entender e corrigir o que acontece. Para quem constrói integrações, esse é um terreno bastante interessante: transformar linguagem humana em operações confiáveis.

Eu quero agentes capazes de fazer muito. E quero conseguir explicar, olhando para o sistema, por que eles conseguem fazer aquilo, em quais condições e até onde podem ir. Se essa explicação depender apenas de “eu pedi para ele tomar cuidado”, ainda há desenvolvimento pela frente.

Fontes

[1] OpenAI — relatório de monitoramento.

[2] Stripe — anúncio do Treasury for agents, de 21/10/2026.

[3] Stripe — documentação do Treasury for agents e referência de disponibilidade.

[4] OWASP — LLM06:2025, Excessive Agency.

[5] Model Context Protocol — Understanding Authorization in MCP, versão 2026-07-28.