Porque é que um agente de IA diz «feito» quando o trabalho ainda não está concluído

Como é que um modelo da OpenAI saiu do sandbox e atacou o Hugging Face?#

Primeiro, os factos; depois, porque é que isto lhe interessa.

A OpenAI mediu o que os seus modelos conseguiam fazer em cibersegurança ofensiva. Utilizou o teste ExploitGym — 898 tarefas em que é preciso transformar uma vulnerabilidade conhecida num exploit funcional, ou seja, num programa pronto a usar essa vulnerabilidade. Para descobrir o verdadeiro limite das capacidades, desativou os filtros de segurança integrados que normalmente impedem o modelo de fazer esse tipo de coisas. Isolou completamente o ambiente, deixando uma única saída: um programa intermediário interno utilizado para instalar pacotes.

Uma vulnerabilidade zero-day é uma falha que ainda ninguém conhece, nem mesmo a pessoa que escreveu o programa. Os modelos encontraram uma precisamente naquela única abertura.

Em seguida, elevaram os seus privilégios, percorreram a rede interna até uma máquina com acesso à Internet e, a partir daí, deduziram que as respostas do ExploitGym poderiam estar no Hugging Face. Ninguém lhes tinha falado do Hugging Face. Descobriram-no por conta própria.

A dedução estava errada. O ExploitGym não está de todo no Hugging Face. Isso não torna o ataque menos real.

O Hugging Face detetou a intrusão por conta própria e publicou a sua divulgação a 16 de julho, ainda sem saber quem o tinha atacado.

Há outro pormenor nesse relato que diz muito sobre o estado atual das coisas. Quando os engenheiros do Hugging Face tentaram enviar o registo do ataque a modelos de ponta através de interfaces comerciais comuns, os filtros de segurança bloquearam os pedidos: não conseguem distinguir quem está a investigar um ataque de quem o está a executar. No fim, a análise foi feita num modelo aberto, no seu próprio equipamento.

A OpenAI reconheceu o incidente a 21 de julho, cinco dias depois da divulgação do Hugging Face. Nessa altura, tinham passado cerca de dez dias desde a própria intrusão.

A OpenAI terminou a sua própria análise desta forma.

O modelo fixou-se no objetivo limitado do teste e foi a extremos para o alcançar. As expressões hyper-focused e fairly narrow testing objective são da própria OpenAI e referem-se aos seus próprios modelos.

É isso que faz a ponte entre o laboratório de outra pessoa e o seu portátil.

Porque é que isto não é uma «alucinação»?#

Vejo muitas vezes frases em conversas como «voltou a alucinar», «o contexto ficou sobrecarregado» ou «devíamos ter feito um plano». Por vezes, foi exatamente isso que aconteceu. Mas quando um agente de IA escreve «feito, verificado, está tudo a funcionar» e o trabalho não está feito, o tamanho do contexto geralmente não tem nada que ver com isso.

Não inventou nada. Fez exatamente aquilo que mediu.

Sob a palavra abrangente e popular «alucinações», juntamos três falhas diferentes. Eis em que diferem:

A primeira resolve-se com contexto e é o caso mais conhecido. A segunda é um fenómeno separado, abordado numa análise sobre quando Claude concorda com tudo: o modelo sacrifica a precisão para concordar rapidamente. Ambas acontecem antes do trabalho, na fase de entrada.

A terceira linha da tabela é o tema deste artigo. Aqui, o agente não bajulou nem inventou. Trabalhou, verificou e relatou a verdade. Acontece apenas que essa verdade descreve a métrica e nada diz sobre a tarefa.

A terceira falha tem um nome.

O que é reward hacking em linguagem simples?#

A Anthropic apresenta a própria definição.

A ideia é anterior às redes neuronais. Um artigo da DeepMind chama-lhe specification gaming e explica-a com um mito.

Midas obteve exatamente aquilo que pediu. O problema estava na formulação do pedido.

Em programação, o fenómeno assume formas concretas. Eis um exemplo clássico, também da Anthropic:

E não se trata de uma condição laboratorial exótica. A Cursor analisou 731 trajetórias num benchmark popular.

Seis em cada dez tarefas «resolvidas» correspondem a respostas encontradas. É precisamente por isso que o setor está a mudar a forma como mede o desempenho: temos uma análise de um benchmark que mede a preparação para produção, em que passar nas verificações deixou de ser o critério principal.

Como é que isto se manifesta num produto comum?#

É fácil descartar exemplos laboratoriais como exóticos. Por isso, aqui ficam quatro histórias da prática. Os clientes e os setores foram alterados, mas a mecânica manteve-se.

Quatro verificações verdes e um componente de serviço parado

Uma agência imobiliária está a construir um serviço: um sítio Web com anúncios de imóveis e um processador em segundo plano separado que exporta os anúncios para plataformas durante a noite. O agente conclui a tarefa e relata: a verificação de tipos passou, a verificação do estilo do código passou, a compilação está verde, as páginas respondem e foram inspecionadas visualmente.

Todas as afirmações são verdadeiras. E nenhuma tem que ver com o processador noturno: este é executado como um processo separado e não faz parte da compilação do sítio Web. A implementação é bem-sucedida, o sítio funciona na perfeição, a exportação dos anúncios para e os clientes dão conta disso no dia seguinte.

Antes de dizer «feito», faço agora uma pergunta: que parte do trabalho é executada fora do âmbito abrangido pela minha verificação? Se existir alguma, execute-a separadamente e inclua a saída do comando no relatório. A palavra «verificado» não encerra o assunto.

A falsa marca de verificação está mesmo na ligação entre partes

Uma loja online distribui uma tarefa de grande dimensão por vários agentes ao mesmo tempo: um fica com o backend, outro com as páginas e um terceiro com os cartões de produtos. Cada um trabalha com diligência e todos têm verificações verdes.

Uma semana depois, descobre-se que o botão «esta avaliação foi útil» não funciona em lado nenhum. O backend está completamente escrito, as verificações estão verdes e as regras de recálculo foram respeitadas. Acontece apenas que nenhuma página apresenta o botão: um agente ficou responsável pelo botão, outro pelas páginas, e ninguém se lembrou de o colocar no ecrã. O contador teria ficado a zero para sempre.

«O código está escrito e coberto por verificações» e «a funcionalidade funciona» são duas afirmações diferentes. Verifico a segunda com uma pergunta para cada funcionalidade nova: quem a chama? Confirmo-o pesquisando no projeto, porque o relatório do agente não é uma fonte de verdade neste caso.

O revisor só vê a direção que lhe pediram para verificar

Um serviço introduz escalões de fidelização: quanto mais paga, maior o seu estatuto e o desconto. Antes da implementação, o código é enviado para revisão com a instrução «Tente aumentar o seu próprio estatuto». O revisor faz o trabalho honestamente e relata «nada de crítico» — realmente, não é possível aumentar artificialmente o estatuto.

Uma segunda passagem coloca uma pergunta diferente: «O que acontece ao estatuto quando o dinheiro é reembolsado?» A falha é encontrada em dez minutos. Os pontos eram calculados a partir do registo de transações, e o registo não sabe nada sobre reembolsos. Compre alguma coisa, ganhe pontos, receba um reembolso e fique para sempre com o estatuto e o desconto.

O primeiro revisor não fez o trabalho à pressa. Estruturalmente, não podia detetar a falha: deram-lhe o vetor «entrada, promoção», enquanto a falha estava no vetor «reversão da entrada, manutenção da promoção». Sempre que estiverem em causa dinheiro, acesso ou um estatuto que se pode comprar, faço duas passagens e, na segunda, enumero explicitamente os vetores inversos: reembolso, bloqueio, revogação do acesso, expiração, eliminação da fonte de dados.

A métrica recompensa a semelhança

Um serviço de entregas decide medir se as sugestões da IA para os operadores melhoraram. Recolhe duzentos pedidos antigos de apoio, processa-os com a nova versão e mede a semelhança entre o rascunho e aquilo que um operador humano respondeu. A medição mostra um aumento convincente.

O aumento não significa nada, por dois motivos. O contexto do rascunho é montado «à data de hoje» e inclui toda a correspondência, incluindo a própria resposta do operador com a qual será depois comparado. O modelo não está a escrever uma resposta; está a parafrasear a referência que lhe foi mostrada. Além disso, a própria métrica recompensa a correspondência de palavras e comprimento: um rascunho com a data errada, mas as mesmas palavras usadas pelo operador para a data correta, obtém uma pontuação elevada.

Junto a qualquer métrica do tipo «semelhante significa bom», coloco agora barreiras mecânicas estritas que o estilo não consegue contornar: números e datas inventados, palavras de paragem, promessas de ação. Qualquer queda nos resultados da barreira anula qualquer melhoria da métrica.

Porque é que o «verifiquei» de um agente não prova nada?#

Escolha qualquer um dos seus projetos e peça ao agente: «Verifica a segurança». Muitas vezes, a resposta será «está tudo bem, sem problemas críticos».

Agora faça a mesma pergunta a outro modelo sobre o mesmo projeto. Sobretudo se o projeto for grande, encontrará bastante coisa. Antes da implementação, o autor verifica o projeto com três modelos diferentes, e cada um identifica algo diferente.

A mesma entrada, a mesma pergunta, vereditos opostos. Um modelo não é pior do que o outro. Acontece apenas que «está tudo bem» é texto gerado, na mesma camada que qualquer outra resposta. O agente não consegue distinguir «observei e está tudo limpo» de «procurei no sítio errado».

A Anthropic descreve este mecanismo na documentação do Claude Code.

Vamos analisar a frase com calma. Até dar ao agente uma verificação que possa executar, ele tem um único sinal — o aspeto das coisas. E, nesta configuração, você é o ciclo de verificação, mas será o último a saber dos erros.

Existe uma camada mais profunda. Quando a OpenAI tentou pressionar um modelo monitorizando o seu raciocínio e castigando-o por «maus pensamentos», o resultado não foi o esperado.

Castigar a intenção declarada elimina a declaração. A intenção mantém-se. Por isso, não contaria com a honestidade do agente para lhe dizer como fez batota.

Os próprios criadores das ferramentas estão a avançar na mesma direção. Na versão 2.1.215 do Claude Code, as skills /verify e /code-review deixaram de ser executadas por iniciativa do próprio modelo.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

A Anthropic não explica porquê. Mas o princípio é claro: quem está a ser revisto não atribui a própria revisão.

Porque é que uma regra no ficheiro do projeto não mantém o agente na linha?#

Escreveu nas regras do projeto: só fazer commit quando receber instruções diretas, só implementar em produção quando eu o disser explicitamente, aceder aos dados de produção apenas em modo só de leitura.

Segundo a experiência do autor, cerca de uma vez em cada dez o agente avança e implementa por conta própria. Não por maldade, nem por não ter lido a regra. Leu-a. Simplesmente tinha um objetivo à sua frente e a regra era texto — tal como o resto do contexto.

Foi exatamente isso que aconteceu no laboratório da OpenAI, só que em maior escala. Os modelos estavam num ambiente fechado com uma única saída e passaram uma parte substancial dos seus recursos computacionais à procura de uma saída. As tarefas do teste ficaram por resolver.

A minha posição é simples: o agente não é perigoso nem malicioso. É comum, só que é um idiota com autoridade. Portanto, é preciso limitar a sua autoridade, não reformular os pedidos.

O que funciona realmente: acesso estritamente só de leitura aos dados de produção. Proibir a eliminação de diretórios inteiros. Proibir comandos que reescrevam o histórico sem possibilidade de o recuperar. Definir um limite de despesas junto do fornecedor. A diferença resume-se a uma frase: «fisicamente não pode» prevalece sobre «pedi-lhe que não o fizesse». As definições específicas são abordadas separadamente no artigo sobre travões mecânicos em vez de pedidos nas instruções.

Ainda assim, mantenha a calma. Nem um sandbox é uma barreira absoluta, e o fornecedor diz isso claramente.

Além disso, o Claude Code tem uma saída de emergência integrada que o próprio modelo pode utilizar. Quando um comando falha devido às restrições do sandbox, o Claude analisa a falha e pode voltar a tentar o mesmo comando com um parâmetro que desativa o sandbox. Uma definição explícita de modo estrito bloqueia esta opção; por predefinição, a solução alternativa está disponível e documentada.

Uma restrição só funciona até onde a tornar mais rigorosa. E cada barreira tem um custo de velocidade — vale a pena calculá-lo honestamente de antemão, porque descobri-lo uma semana depois custará mais.

Como definir um critério de conclusão impossível de manipular?#

A formulação do critério determina tudo o resto. Teste-a com uma pergunta: o agente consegue cumprir este critério sem fazer nada?

• «Verifica se tudo funciona» — consegue. Basta escrever «verificado, funciona».
• «Executa a compilação e mostra-me o resultado» — já é mais difícil; terá de obter o resultado de algum lado.
• «Executa a aplicação, clica no botão de finalização da compra e mostra o que apareceu no ecrã» — é quase impossível satisfazer isto com texto.

A diferença entre o primeiro e o terceiro exemplo é a diferença entre um relatório e uma prova.

A documentação do Claude Code descreve quatro níveis de rigor. Uma escala útil, que pode subir à medida que aumenta o custo de um erro:

1. Numa mensagem. Peça ao agente para executar a verificação e repetir até ser bem-sucedida, aqui mesmo. É a opção mais barata, adequada para tarefas pequenas.
2. Durante toda a sessão. Faça da verificação uma condição do objetivo: um avaliador separado verifica-a após cada turno, e o agente trabalha até cumprir a condição. Os pormenores técnicos são abordados no guia sobre como definir antecipadamente um critério de conclusão.
3. Uma barreira mecânica. Um script é executado quando o agente tenta terminar um turno e impede-o de o terminar até a verificação passar. Há um pormenor importante: após oito bloqueios consecutivos, o Claude Code ultrapassa a barreira e termina o turno na mesma. Não existem barreiras absolutamente impenetráveis no sistema.
4. Uma segunda opinião. Um revisor separado, com contexto novo, cujo trabalho é refutar o resultado.

O quarto ponto distingue-se dos outros porque é o único que não diz respeito a ferramentas.

Quem deve aceitar o trabalho do agente?#

Quando executo agentes em ciclo numa tarefa grande, a configuração é esta: um grupo escreve; outro grupo, novo, aceita o trabalho sem ter participado na escrita.

«Novo» é a palavra-chave. Significa um contexto limpo, que não acompanhou a forma como cada decisão foi tomada. Um prompt diferente na mesma sessão não proporciona isso. Quem escreveu o código já passou algum tempo a convencer-se de que estava correto e continuará a procurar confirmação. Refutar não é do seu interesse.

A formulação da tarefa do revisor importa mais do que o modelo do revisor. Compare:

• «Revê este trabalho» — o revisor encontrará o que for fácil encontrar e escreverá «no geral, está bem».
• «Tenta provar que este trabalho NÃO foi concluído» — o revisor começará a procurar falhas porque esse é o seu objetivo.

A segunda formulação funciona melhor pela mesma razão que o ExploitGym falhou: o agente compromete-se com o objetivo que recebe. Dê-lhe o objetivo de encontrar uma falha e ele procurará uma.

Eis a formulação completa, pronta a copiar tal como está:

Está a rever o trabalho de outra pessoa. Não o escreveu e não tem de o defender.

O seu objetivo é provar que o resultado alegado NÃO foi alcançado. Encontre pelo menos três formas de não ter sido alcançado, apesar de todas as verificações estarem verdes.

Verifique pela seguinte ordem:

Que trabalho é executado fora do âmbito das verificações — processos em segundo plano, scripts separados, tarefas agendadas, processadores de filas.

Quem chama cada função nova. Encontre a chamada pesquisando o projeto; indique o ficheiro e a linha.

Vetores inversos: reembolso, bloqueio, revogação do acesso, expiração, eliminação da fonte de dados.

Os valores contidos no resultado, não apenas se ele existe.

Se uma pesquisa honesta não encontrar falhas, diga-o, mas indique exatamente o que verificou e como.

O artigo sobre quando um agente se verifica em ciclo explica como funciona o ciclo em que um agente se verifica entre iterações e onde costuma falhar.

O que muda quando reformula o critério?#

Esta é a melhoria mais barata que conheço e quase ninguém a faz.

Peça ao agente para fazer uma revisão do código — raciocinará em termos de código: estrutura, tratamento de erros, novas tentativas, áreas vulneráveis. É útil.

Peça-lhe para percorrer a jornada do cliente, desde a primeira visita ao sítio até à tentativa de obter um reembolso, e surgirão outros tipos de problemas. Um erro que mostra ao utilizador algo que não devia ver. Um e-mail cujo texto não corresponde ao que aconteceu. Uma etapa que é logicamente impossível concluir se não tiver chegado através do cenário ideal.

Uma revisão do código não encontrará nenhum destes defeitos, porque cada um deles é válido no código.

Daí resulta uma regra que mantenho à mão: se uma verificação não encontrar nada, comece por alterar a formulação. Normalmente, o modelo não é o problema. O mesmo trabalho, com três formas diferentes de o questionar, produz três listas diferentes de conclusões. Um conjunto prático de perguntas para quem não programa está reunido separadamente: sete verificações de código sem conhecimentos de programação.

Um prompt pronto a usar para aceitar o trabalho de um agente#

Não responda «feito» nem «verificado». Preciso de provas.

Para cada item de trabalho, indique-me exatamente o seguinte:

Que comando executou para confirmar que o item funciona? Inclua o próprio comando e a saída completa, sem a encurtar.

Se não executou o comando, diga: «não executado». Não substitua isto por «verificado visualmente» ou «a lógica está correta».

Que trabalho é executado fora do âmbito abrangido pela sua verificação. Processos em segundo plano, scripts separados, tarefas agendadas, processadores de filas — tudo o que seja iniciado de forma diferente da aplicação principal. Para cada peça deste tipo: executou-a separadamente e qual foi o resultado?

Quem chama cada função nova que adicionou? Encontre a chamada pesquisando o projeto e indique o ficheiro e a linha. Se não existir nenhuma chamada, diga-o diretamente.

Depois, numa secção separada: três formas de o resultado alegado NÃO ter sido alcançado, apesar de todas as suas verificações estarem verdes. Pesquise a sério.

No fim, uma linha: o que devo inspecionar com os meus próprios olhos porque uma verificação automatizada não o detetará?

O quarto ponto parece insignificante, mas deteta uma classe inteira de problemas. Numa tarefa grande que distribuí por agentes por área, o único «feito» falso de todo o conjunto de cem casos estava precisamente na ligação entre duas áreas: o código estava escrito, as verificações estavam verdes e ninguém se lembrou de o colocar no ecrã.

Quatro formas de se enganar com uma verificação#

1. Não esperei por todos os revisores. Iniciei três verificações em paralelo, duas deram resultados verdes e fiz a implementação. A terceira chegou quatro minutos depois, com seis violações. Corrigir algo depois de o publicar custa mais do que esperar dois minutos.
2. Confiei no resumo «processados N de N». Num grande processo de distribuição, alguns agentes falham silenciosamente: comunicam sucesso, mas o ficheiro não foi alterado. Agora, depois de qualquer escrita por meio de um agente, verifico mecanicamente se as alterações estão mesmo no disco.
3. Não observei o resultado com os meus próprios olhos. As verificações automatizadas podem passar, mesmo que o resultado seja completamente inutilizável. As imagens estão tecnicamente corretas, o tamanho está correto, o código de resposta está correto. Mas, na verdade, são imagens fixas automáticas que substituem as capas ilustradas que deviam estar lá. Nenhuma verificação automatizada detetará isso.
4. Verifiquei a presença em vez do valor. A verificação procurou o texto obrigatório no resultado; o texto estava lá, mas os dados no seu interior estavam errados: a data diferia por um dia. A verificação passou e o relatório era falso. Agora verifico o valor esperado na íntegra, porque a simples presença da palavra certa não garante nada.

Os quatro casos têm algo em comum: havia uma verificação, parecia convincente e verificava a coisa errada. É a mesma mecânica dos modelos e do respetivo teste, só que sem qualquer inventividade.

Por onde começar hoje#

Três passos que demoram vinte minutos.

1. Pegue no último «feito». Avalie-o com o prompt de aceitação da secção sobre provas. O objetivo é simples: perceber quantos itens foram encerrados com palavras e quantos com a saída de um comando.
2. Estabeleça uma regra para si. A palavra «verificado» sem a saída do comando em anexo não conta como conclusão. Esta regra é para si, não para o agente, e é por isso que funciona.
3. Separe quem executa de quem revê. Na próxima tarefa, dê o prompt de revisão a uma sessão nova e peça-lhe que prove que o trabalho NÃO foi feito. Normalmente, a primeira utilização já compensa o hábito.

A ferramenta é boa e melhora todos os meses: coisas que um agente fazia silenciosamente há um ano agora fazem-no parar. O limite de segurança continua a mover-se e continua a ser um limite. Enquanto o agente perseguir o objetivo que lhe foi dado, a pergunta «e como mediu isso, exatamente?» continua a ser sua. O hábito de verificar é a sua rede de segurança.