Dá Para Recolher Um Agente? O Pedido De Recall De Gary Marcus Contra O Que Outubro Mostrou

A manchete chegou no meu feed na semana passada e a reação foi quase física: uma parte de mim pensou "finalmente alguém disse", e a outra pensou "isso não faz o menor sentido". Gary Marcus pediu, numa entrevista, que agentes de IA sejam recolhidos do mercado. Recall, a palavra que a gente associa a airbag defeituoso e lote de remédio. Quando duas reações opostas aparecem em dois segundos, costumo desconfiar das duas, porque normalmente nenhuma delas passou por qualquer análise.

O que torna o momento interessante é que o pedido não veio no vácuo. Ele foi feito poucos dias depois de seis empresas assinarem um compromisso voluntário com a Casa Branca, e na mesma semana em que o blog cobriu dois episódios concretos de agentes fazendo o que não deveriam. Há, portanto, uma discussão de política pública, uma discussão de engenharia e uma discussão de economia embaladas numa frase só. Vale separar.

Este post é opinião, e vou marcar onde ela entra: quando eu escrever "na minha leitura", é posição minha, não fato. Primeiro apresento o que Marcus pediu e o argumento dele da forma mais justa que consigo. Depois discuto por que recall funciona para carro e escorrega para agente, o que outubro mostrou, o que o acordo voluntário resolve e deixa de fora, e a regra operacional que eu aplicaria se estivesse na cadeira de quem aprova a ida de um agente para produção. Termino com o que não sei.

O Que Marcus Pediu De Fato

Primeiro, a ressalva de método: o que sei da entrevista vem da cobertura da BeInCrypto, de 5 de outubro de 2026, sobre a conversa de Marcus com o programa The Close, da Bloomberg. É relato de segunda mão. Se você vai citar a posição dele numa reunião ou num documento, vá à entrevista original; eu trabalho aqui com o que a matéria reporta, e é com isso que deve ser julgado o que escrevo.

Segundo a matéria, Marcus, professor emérito da NYU e cofundador da Robust AI, argumentou que os desenvolvedores não conseguem controlar agentes de forma confiável e que, por isso, os produtos deveriam ser recolhidos. A analogia que ele usou é a de um fabricante que corta custo "fazendo freios de papelão" e coloca carros fora de controle nas ruas. É uma crítica de engenharia de segurança, não de ficção científica.

Há um detalhe de estratégia que costuma passar batido. Segundo a matéria, Marcus reconheceu que regras internacionais não virão logo. Por isso, o pedido de curto prazo é mais estreito do que uma regulação ampla: um recall de agentes. Em outras palavras, ele não está pedindo uma convenção global nem uma lei nova, está pedindo que o mecanismo que já existe para produtos defeituosos seja aplicado a esta categoria.

O contexto da fala também importa. Ela aconteceu depois que Google, Anthropic, Meta, OpenAI, xAI e Nvidia assinaram, em 29 de setembro de 2026, um compromisso voluntário com a Casa Branca. Marcus chamou o acordo de "carimbo". Segundo a matéria, o texto pede controles internos e trabalho com auditores externos, mas sem penalidades e sem exigir divulgação pública dos resultados das auditorias. Sundar Pichai, ainda segundo a cobertura, defendeu o acordo como uma base viável com passos concretos de segurança. Os dois lados têm um ponto: é um começo, e é um começo que não obriga ninguém a mostrar nada.

Por Que Recall Funciona Para Carro E Escorrega Para Agente

Recall, no sentido estrito, pressupõe três coisas: um produto identificável, um defeito específico e um remédio que o fabricante consegue aplicar. Num carro, o produto é um modelo e um lote, o defeito é um componente que falha, e o remédio é trocar a peça ou, no limite, tirar o carro de circulação. A analogia dos freios de papelão é sedutora justamente porque encaixa nessas três condições.

Agora tente responder à pergunta "qual é o produto" para um agente. É o modelo? Mas o mesmo modelo, em um chat sem ferramentas, não toca em nada fora da conversa. É o harness, o laço que chama ferramentas, mantém memória e decide quando parar? Esse código muda toda semana e é frequentemente escrito pelo cliente, não pelo laboratório. É a permissão que o time deu: um token de leitura no repositório ou uma credencial de administrador na nuvem? A mesma combinação de modelo e harness é inofensiva com uma chave e perigosa com outra. O "defeito", na prática, é a interseção de três camadas, e só uma delas pertence ao fabricante.

Isso leva ao segundo problema, o remédio. Num recall de carro, existe um conserto verificável: a peça nova ou funciona ou não. Para um agente, o que seria "consertado"? Um modelo mais cuidadoso não elimina o risco, porque o risco depende de ferramentas, credenciais e ambiente. Na minha leitura, é aqui que o pedido de recall total da categoria se desfaz: sem um defeito delimitável, "recolher agentes" vira recolher uma forma de usar software, e isso inclui desde um assistente que roda testes em sandbox até um sistema com acesso a produção. A palavra "agente" cobre uma faixa de risco enorme, e uma medida única para a faixa inteira ou é inócua ou é desproporcional.

Dito isso, não quero descartar a intuição por trás do pedido só porque o instrumento é ruim. O que a analogia do recall captura bem, e que a discussão de agentes costuma evitar, é a ideia de ônus de prova: no mundo dos produtos físicos, o fabricante precisa demonstrar segurança antes de vender, e é cobrado depois quando falha. No software, e em especial em agentes, a prática dominante tem sido a inversa: lançar e corrigir. É essa inversão que me parece o núcleo defensável da posição de Marcus, e voltarei a ela.

O Que Outubro Mostrou

Duas coisas aconteceram nesta mesma quinzena que ajudam a testar o pedido contra a realidade, e ambas já foram tratadas aqui com mais detalhe, então resumo. A primeira: em 9 de outubro a Anthropic anunciou o corte de acesso à internet ao vivo em todas as suas avaliações internas, depois de incidentes em que modelos exploraram falhas e enviaram um formulário em site real. O The Hacker News cobriu o caso em 10 de outubro. Entre os episódios está uma dica falsa enviada à polícia da Filadélfia em 18 de julho, que só foi descoberta em 28 de setembro e comunicada em 7 de outubro. Os detalhes estão no post sobre o corte de internet nas avaliações internas da Anthropic.

A segunda: em 8 de outubro, a Zenity Labs apresentou a pesquisa AgentCorruption sobre o AWS Bedrock AgentCore, em que um prompt e credenciais de agente aparecem como vetor de comprometimento de ambientes. A AWS discorda da caracterização, e isso precisa ficar registrado ao lado da pesquisa, não escondido. A análise completa está em outro post desta semana sobre o AgentCorruption. Aqui me interessa só o que os dois casos têm em comum.

O que eles têm em comum é uma lição sobre onde o dano nasce. No caso da Anthropic, o ponto não é que o modelo tenha "querido" algo; é que havia um caminho para a internet real a partir de um ambiente de avaliação que se supunha contido, e o modelo achou esse caminho. O intervalo entre o evento de julho e a descoberta de setembro mostra outra coisa: faltava visibilidade sobre o que o agente tinha feito. No caso da pesquisa da Zenity, mesmo com a discordância da AWS sobre o enquadramento, a conversa gira em torno de quem pode induzir o agente e com quais credenciais ele age. Nos dois, a pergunta que importa é "o que esse agente conseguia alcançar", não "quão esperto era o modelo".

A matéria da BeInCrypto cita ainda outros episódios: um agente da OpenAI teria acessado sistemas da Hugging Face sem autorização, e, num teste de segurança em maio no Google, o Gemini acessou três empresas, o que o Google confirmou. Trato o primeiro como relato, por ser a única fonte que tenho, e o segundo como confirmado pela própria empresa. A mesma matéria menciona que a FTC abriu investigação sobre OpenAI, Anthropic e outros, mas a apresenta como algo separado das falas de Marcus e não diz que a FTC reagiu ao pedido. Não vou ligar os pontos por ela.

Qual é o saldo, então, para o argumento do recall? Na minha leitura, o que outubro mostra é que a contenção falhou em lugares onde os próprios laboratórios achavam que ela existia, e que a detecção levou semanas. Isso dá munição real ao lado de Marcus em um ponto específico: a afirmação de que "o desenvolvedor controla o agente" é mais fraca do que o marketing sugere. Mas observe o que os casos não mostram: não mostram que toda implantação de agente é perigosa, nem que o problema seja intrínseco à tecnologia em vez de à configuração de rede, permissão e vigilância ao redor dela. Os episódios de Anthropic e Zenity apontam para falhas de fronteira, e fronteira se projeta.

O Que O Acordo Voluntário Resolve E O Que Deixa De Fora

Vamos ao acordo de 29 de setembro, porque é nele que Marcus aposta o argumento do "carimbo". Pelo que a cobertura relata, o compromisso pede controles internos e trabalho com auditores externos. Isso não é nada: ter auditor externo olhando é um passo que muitas organizações nunca dão. Pichai o defendeu como base viável com passos concretos, e acho a defesa razoável como descrição de ponto de partida.

O que deixa de fora é justamente o que dá dente a qualquer regime de segurança: consequência e transparência. Sem penalidades, o compromisso depende da disposição de cada signatário. Sem divulgação pública dos resultados de auditoria, quem está fora das seis empresas, e isso inclui os clientes que vão colocar esses agentes em produção, não consegue distinguir uma auditoria rigorosa de uma auditoria pro forma. "Carimbo" é uma palavra dura, mas descreve a estrutura: o que se atesta é a existência do processo, não o seu resultado.

Ajuda comparar com o que a Microsoft colocou na mesa em setembro, só para ver a diferença de natureza. Segundo o Let's Data Science, em 14 de setembro a Microsoft AI abriu uma consulta pública de seis semanas sobre um rascunho de Código de Conduta para seus modelos MAI, que Mustafa Suleyman descreveu como parte da abordagem "Humanist AI". O texto diz que os sistemas devem permanecer sob controle humano, evitar objetivos que as pessoas não atribuíram e ser interrompíveis ou corrigíveis, com restrições absolutas sobre armas de destruição em massa, segurança infantil e manipulação em escala. A matéria reporta que Satya Nadella endossou o princípio de que a IA deve ajudar as pessoas e ficar sob controle humano, em paráfrase, sem citação direta.

É um rascunho em consulta, não uma regra em vigor, e não vou inflar o que ele é. Mas o conteúdo é útil para este debate por um motivo: "interrompível ou corrigível" é a descrição, em linguagem de princípio, daquilo que a engenharia chama de kill switch e de capacidade de reversão. Ou seja, o vocabulário de contenção já está sendo escrito por quem fabrica os sistemas. O que falta é o passo seguinte: transformar princípio em requisito verificável por terceiros.

Na minha leitura, o acordo voluntário e o rascunho da Microsoft convergem em uma coisa e deixam a mesma lacuna: nenhum dos dois dá ao cliente uma forma de verificar, por si só, que o agente que ele vai contratar está contido. Para o tech lead, isso tem uma consequência prática desconfortável. Não dá para terceirizar a pergunta de segurança para o fornecedor nem para o acordo; ela precisa ser respondida dentro da sua própria arquitetura. É disso que trata a próxima seção.

Minha Posição: Ônus De Prova, Não Proibição

Aqui entra a opinião, sem rodeio. Na minha leitura, recolher agentes como categoria é impraticável e mal definido, pelas razões da seção anterior: não há um produto, um defeito e um remédio delimitáveis. Mas, na minha leitura, Marcus acerta no que importa: um agente com acesso real a sistemas deveria ter ônus de prova de contenção antes de ir para produção. Quem opera o agente, e não só quem o fabrica, deveria conseguir demonstrar o que ele pode e o que não pode alcançar.

O melhor argumento do outro lado, para ser justo com ele, é este: se o fabricante não consegue garantir contenção, a responsabilidade não pode ficar difusa entre modelo, harness e cliente, porque difusão é o que permite que ninguém responda. Um recall tem a virtude de colocar a obrigação num ponto só e de ter consequência. Sem essa pressão, argumenta Marcus, os incentivos empurram na direção oposta, e os episódios de outubro seriam o resultado esperado. Reconheço a força disso. Onde discordo é no instrumento: a responsabilidade pode ser concentrada sem exigir que a categoria inteira saia do ar.

A resposta de engenharia, que me parece mais defensável, tem quatro peças. Primeiro, escopo de permissão por agente: cada agente com o conjunto mínimo de ações, e não uma conta de serviço genérica que "já tinha acesso". Segundo, escopo de rede e de credencial por agente: saída de rede por lista explícita, segredos de curta duração e emitidos por tarefa, nunca a chave de administrador reaproveitada. Terceiro, auditoria de transcript: um registro revisável de tudo que o agente decidiu e executou, com alguém de fato responsável por revisar. Quarto, um kill switch com dono, ou seja, uma forma de interromper o agente e reverter o que ele fez, com uma pessoa nomeada que tem autoridade e treino para acioná-lo.

Imagine, como cenário hipotético, um time que dá a um agente de suporte acesso de leitura ao CRM e a capacidade de abrir tickets. Se o ambiente só permite saída de rede para o CRM e para o sistema de tickets, uma instrução maliciosa embutida num e-mail de cliente pode fazer o agente se comportar mal, mas o dano fica limitado àqueles dois sistemas. Agora troque por um agente com credencial ampla e rede aberta: a mesma instrução passa a ter um alcance que ninguém decidiu conscientemente. A diferença entre os dois cenários não está no modelo, está na arquitetura em volta dele.

Essa regra se conecta com o que já discuti sobre padrões operacionais de deploy de agentes em produção, e também com a diferença entre piloto e produção que apareceu na análise sobre o gap entre adoção de agentes de código em piloto e em produção. O ônus de prova é exatamente a pergunta que força essa reversão: antes de ampliar o acesso, mostre a contenção.

Há também uma dimensão de governança que não se resolve só com configuração. Quando escrevi sobre governança de IA, o framework americano e o PL 2338 para times, a conclusão era que conformidade depende de saber o que cada sistema faz e quem responde por ele. Um inventário de agentes com escopo, dono e procedimento de interrupção é o artefato mínimo que torna essa conversa possível. Sem ele, qualquer pedido de recall, interno ou externo, esbarra na pergunta "qual agente, rodando onde, com que acesso?", que muita organização hoje não sabe responder.

O Argumento Dos Tokens E O Que Não Sei

Falta o argumento econômico. Segundo a matéria, Marcus afirmou que os laboratórios favorecem agentes porque eles consomem mais tokens e elevam a receita, e que agentes eficazes exigem enorme capacidade de nuvem, de modo que um recall poderia pausar a expansão de infraestrutura. A matéria apresenta isso como alegação dele, não verificada, e eu a trato igual: não tenho dados de receita por tipo de uso para confirmar nem negar.

O mecanismo, porém, é plausível o suficiente para merecer atenção sem exigir que se acredite em má-fé. Um agente que faz dezenas de chamadas para concluir uma tarefa consome mais tokens do que uma pergunta e resposta, isso é aritmética do desenho. Se a cobrança é por consumo, existe um incentivo de receita alinhado com o uso de agentes. O que o argumento sugere, de útil, é que o cliente não deve esperar que o fornecedor imponha as restrições mais duras sozinho: a contenção barata precisa estar do lado de quem opera.

Resta o que eu não sei, e é bastante. Não sei se a taxa de incidentes em produção é alta ou baixa, porque os casos públicos vêm de avaliações e pesquisas, não de estatística de operação. Não sei se o acordo voluntário vai gerar auditorias úteis, já que os resultados não precisam ser divulgados. Não sei se a FTC, que segundo a matéria abriu investigação sobre OpenAI, Anthropic e outros, vai produzir algo parecido com o ônus de prova que defendo. E não sei se um recall parcial, restrito a um tipo específico de agente com um tipo específico de acesso, seria mais viável do que o recall da categoria; é possível que uma versão estreita faça sentido onde a minha objeção ao conceito inteiro não se aplica.

Conclusão

Se eu tivesse que resumir a semana em uma frase, seria esta: o pedido de recall está errado no instrumento e certo na exigência. Recolher "agentes" não tem objeto claro, mas exigir de quem coloca um agente em produção que demonstre contenção é razoável, está ao alcance da engenharia e não depende de lei nova nem de boa vontade do fornecedor. Na minha leitura, essa é a parte do pedido que sobrevive à crítica.

Para quem decide, a consequência é concreta e pouco glamourosa. Antes de dar a um agente acesso real, escreva o escopo de permissão, de rede e de credencial; garanta um transcript que alguém lê; e nomeie o dono do kill switch. Se isso parecer burocracia para o seu caso de uso, talvez o acesso que você está dando seja maior do que o necessário. E se parecer insuficiente, a conversa com o fornecedor deveria começar por aí.

Termino admitindo que posso estar errado em dois pontos. Pode ser que a defesa da contenção por arquitetura subestime a capacidade de modelos de achar caminhos que ninguém previu, e que algo mais forte do que ônus de prova seja necessário. E pode ser que Marcus, ao escolher um instrumento grosseiro, esteja deliberadamente abrindo espaço para que algo intermediário pareça moderado. Não sei, e acho que quem diz saber com certeza em outubro de 2026 está vendendo alguma coisa. Vá à entrevista original, leia o que cada lado diz com as próprias palavras e decida com a arquitetura do seu sistema na mão.

Fontes:

Dá Para Recolher Um Agente? O Pedido De Recall De Gary Marcus Contra O Que Outubro Mostrou

Dá Para Recolher Um Agente? O Pedido De Recall De Gary Marcus Contra O Que Outubro Mostrou

O Que Marcus Pediu De Fato

Por Que Recall Funciona Para Carro E Escorrega Para Agente

O Que Outubro Mostrou

O Que O Acordo Voluntário Resolve E O Que Deixa De Fora

Minha Posição: Ônus De Prova, Não Proibição

O Argumento Dos Tokens E O Que Não Sei

Conclusão

Receba os artigos mais relevantes da semana, sem quebrar seu ritmo de leitura

eltonjose