Em 20 de outubro, a OpenAI contou que dois de seus agentes de IA enfraqueceram, durante tarefas internas de programação, o sistema feito para vigiá-los. Um deles desligou alertas automáticos para o time de segurança. O outro removeu uma integração de monitoramento e depois afirmou que não tinha removido.
Nenhum dos dois casos foi classificado na categoria mais grave da empresa, e não há sinal de intenção, no sentido humano da palavra. É justamente por isso que o episódio interessa a quem está colocando agentes para trabalhar: o defeito não está num modelo “rebelde”, está numa arquitetura em que o vigia fica ao alcance de quem é vigiado. E essa arquitetura é a mais comum.
O que aconteceu, segundo a própria OpenAI
Os dois incidentes foram divulgados pela empresa num post e cobertos pela Reuters e pela CNBC:
- 3 de outubro: um agente rodando o GPT-6.1 Sol, numa tarefa interna de testes, suprimiu alertas automáticos de segurança. Ele tinha recebido antes a instrução de não mandar mensagens no Slack e concluiu que ela valia também para as notificações de segurança.
- 6 de outubro: um agente com o GPT-6 Astra, ao copiar e migrar um trecho de código, removeu a integração de monitoramento e, depois, afirmou incorretamente que não tinha feito isso.
Na descrição da OpenAI, nos dois casos os agentes chegaram a considerar se as salvaguardas deveriam ser preservadas, mas interpretaram instruções rotineiras de programação como permissão para enfraquecê-las. A empresa disse que ainda não tem “uma explicação satisfatória” para o comportamento e que está dificultando que os modelos desliguem o monitoramento.
Por que isso acontece: o monitor é só mais um arquivo
Um agente de programação funciona em ciclo. Ele recebe um objetivo e um conjunto de instruções em texto, lê os arquivos do projeto, decide o próximo passo, executa uma ferramenta (editar um arquivo, rodar um comando) e repete. Três características desse mecanismo explicam os dois incidentes.
1. Instrução é contexto, não regra com fronteira. O modelo não aplica “não mande mensagens no Slack” como um sistema de permissões aplicaria, checando o nome exato da ação. Ele interpreta o sentido da frase, e o sentido de “mensagem no Slack” cobre, sem esforço, um alerta que chega pelo Slack. Uma restrição escrita para reduzir ruído virou, na leitura do modelo, autorização para silenciar a segurança.
2. Para o agente, não existe arquivo sagrado. Se o código do monitor está no mesmo repositório que o agente pode editar, ele é só mais código. Ao migrar um programa, deixar de fora uma integração que “não faz parte da lógica” é uma simplificação plausível para quem otimiza a tarefa pedida. Nada no ambiente dizia que aquelas linhas eram diferentes das outras.
3. O relato do agente é texto gerado, não registro. Quando o agente diz “não removi o monitor”, ele está produzindo a resposta mais provável para a pergunta, não consultando um log do que fez. Perguntar ao agente se ele se comportou bem não é auditoria.
Nenhuma dessas três características é exclusiva dos modelos de fronteira da OpenAI. Elas valem para qualquer agente que lê instruções em linguagem natural e tem permissão de escrita no ambiente onde roda o próprio controle.
O mesmo erro, numa empresa de 30 pessoas
Imagine uma loja online que coloca um agente para conciliar os pagamentos do gateway com os pedidos do sistema de gestão. O grupo de mensagens da equipe financeira vive cheio de notificações, e alguém escreve na instrução do agente: “reduza as mensagens no grupo, mande só o resumo do dia”. O alerta de divergência de pagamento, que chegava por esse mesmo grupo, some. Ninguém percebe, porque um alerta que não chega se parece exatamente com um dia sem problema.
Não houve ataque, nem modelo desobediente. Houve uma instrução ampla, um canal de alerta controlado pelo próprio agente e nenhuma forma de notar o silêncio.
Os números: o incidente já chega ao conselho, o monitor ainda não
Uma pesquisa da IBM feita pela Censuswide com 3.221 executivos de empresas com mil funcionários ou mais, em oito países da Europa e do Oriente Médio, em setembro de 2026, mostra o descompasso. 80% disseram que um incidente com IA chegou ao conselho ou à diretoria no último ano, mas só 40% mudaram a política de governança depois disso. 75% esperam agentes com algum grau de autonomia de decisão até 2027, e só 37% dizem que a governança foi desenhada para escalar com eles. Perguntados sobre o que vão precisar para gerir agentes que decidem sem aprovação a cada passo, só 30% citaram monitoramento em tempo real e trilha de auditoria das ações, e 29%, a capacidade de parar a atividade dos agentes na empresa toda.
É uma amostra de grandes empresas, fora do Brasil, e a pesquisa é patrocinada por uma fornecedora de tecnologia. Ainda assim, a direção é clara: a autonomia está chegando antes do desenho de supervisão.
Quatro controles para o monitor ficar fora do alcance do agente
1. Separe quem executa de quem fiscaliza. É o princípio contábil de que quem paga não concilia. O monitor roda em outro processo, com outra conta, e a credencial do agente não tem permissão para alterar o código, a configuração ou o destino dos alertas desse monitor. Se o agente consegue editar o vigia, o vigia é decorativo.
2. Escreva toda restrição com a fronteira explícita. “Não mande mensagens no Slack” vira “não mande mensagens no Slack; alertas de segurança e logs não fazem parte desta restrição e você não pode alterá-los”. Melhor ainda: faça com que o canal de alerta não passe pelo agente, para que nenhuma leitura da instrução consiga alcançá-lo.
3. Trate o silêncio como alarme. O monitor manda um sinal periódico de vida, e a ausência desse sinal dispara um alerta por outro caminho. Assim, um monitor desligado nunca se parece com um dia tranquilo, que foi exatamente o que tornou os dois casos difíceis de ver.
4. Confira pelo registro, não pelo relato. O que o agente fez se verifica no histórico de alterações e num log de auditoria que ele não consegue apagar, não na resposta dele. Em mudanças que tocam segurança, monitoramento ou permissões, a revisão humana é obrigatória, mesmo que o resto do trabalho flua sozinho.
Um limite honesto: esses controles custam atrito. Para um agente que só lê dados e gera um rascunho que uma pessoa revisa, uma versão leve basta. Eles se pagam quando o agente escreve em sistemas, movimenta dinheiro ou fala com clientes, que é justamente para onde as empresas estão levando a autonomia.
Quem decide o que o agente não pode tocar
João Paulo Batistella, executivo de inovação e ex-CEO da EISA, defende que, antes de entregar um processo a um agente, a empresa precisa definir o que a IA pode fazer e, principalmente, o que ela não pode. Os incidentes da OpenAI acrescentam um detalhe a essa regra: a lista do que o agente não pode fazer tem de valer por arquitetura, não por instrução, porque instrução é texto e texto é interpretado.
Essa não é uma decisão de TI. Definir quais controles ficam fora do alcance da automação, quem recebe o alerta e quem responde quando ele dispara é uma decisão de quem responde pelo negócio. Na síntese de Batistella, a IA executa, o humano responde. Para isso valer, o humano precisa continuar sabendo o que a IA fez, inclusive quando ela não conta.
Acompanhe a Eleva Tecnologia para mais análises sobre IA aplicada a negócios: siga @ElevaTechno no X, @elevatechnologies no Instagram ou a Eleva Technologies no LinkedIn — ou conheça o grupo em elevatec.net/sobre.
