IA construindo IA: autoaprimoramento recursivo como um problema de segurança atual

O que significa o "autoaprimoramento recursivo"

Como observou Matthew Hutson na IEEE Spectrum, o termo é usado de maneira inconsistente: alguns o empregam para se referir a uma ameaça que ajude a promover a regulamentação, outros o utilizam com fins publicitários, e as definições oferecidas vão desde um ciclo totalmente autônomo, sem intervenção humana, até quase qualquer caso em que a tecnologia ajude a desenvolver outra tecnologia. A descrição mais honesta é a de um espectro.

A ideia não é nova. Em 1965, o matemático I.J. Good descreveu uma "máquina ultrainteligente" como aquela capaz de projetar máquinas ainda melhores, o que provocaria uma "explosão de inteligência" que deixaria a inteligência humana muito para trás. Essa linha de pensamento prossegue com a formalização posterior de Nick Bostrom e com décadas de literatura sobre segurança da IA. Durante a maior parte dessa história, a RSI foi um horizonte teórico, um estado futuro que era preciso modelar e temer, mais do que uma condição presente que era preciso gerenciar.

No extremo superior do espectro está um sistema que não apenas melhora seus resultados, mas também o processo pelo qual o faz, gerando ideias, avaliando resultados e modificando seus próprios métodos sem intervenção humana. Segundo esse critério, os sistemas atuais ainda não chegam lá: eles ajudam a construir uma IA melhor, mas continuam dependendo de humanos para estabelecer metas, definir o sucesso e decidir quais mudanças manter. A pergunta relevante, então, não é se o autoaprimoramento existe de alguma forma — pois já existe, mais abaixo no espectro —, mas sim o quanto do ciclo já foi fechado. E o que está em jogo é a velocidade: se o progresso se acumula de forma linear, é administrável; se se acumula de forma exponencial, décadas de avanços poderiam se comprimir em semanas.

A situação atual

Se deixarmos de lado as especulações, observa-se um padrão consistente entre os três laboratórios dominantes. A divulgação da Anthropic é a mais detalhada, mas não é a única. A OpenAI informou, em fevereiro de 2026, que o GPT-5.3-Codex foi fundamental em sua própria criação, ajudando a depurar seu treinamento, gerenciar partes de sua implantação e analisar os resultados de sua avaliação. O AlphaEvolve, do Google DeepMind, um agente de codificação para descoberta algorítmica, usa um grande modelo de linguagem para mutar e avaliar algoritmos de forma iterativa, e já foi aplicado à otimização de rotinas de multiplicação de matrizes que sustentam a eficiência do treinamento, ajudando a acelerar o treinamento de sistemas futuros. Em todos os casos, os humanos continuam dirigindo e verificando o trabalho.

O diretor de políticas da Anthropic, Jack Clark, deixou clara essa distinção alguns meses antes do artigo de junho, ao afirmar que o campo ainda não chegou à IA que se aprimora a si mesma, mas está na etapa de uma IA que aprimora partes da próxima IA, com autonomia cada vez maior.

A Cloud Security Alliance (CSA) propõe um termo que define com clareza o que está realmente acontecendo: sua análise de 2026 chama essas operações de "adjacentes à RSI": sistemas de IA que participam de forma significativa no desenvolvimento, na avaliação ou na implantação de sistemas de IA sucessores sob supervisão humana. Esse qualificador é o que torna o conceito administrável, já que a RSI totalmente autônoma — um sistema que reescreve seus próprios pesos rumo a uma capacidade escolhida, sem intervenção humana — continua sendo especulativa, enquanto as operações adjacentes à RSI já estão em curso em grande escala, nos ambientes que produzem os modelos que agora estão entrando na economia em geral. E, como argumenta a CSA, é a infraestrutura que sustenta esses ciclos supervisionados que constitui a nova superfície de ataque.

A vanguarda da pesquisa vai ganhando terreno

Além dos anúncios sobre a produção dos laboratórios, uma linha de pesquisa indica para onde esse ciclo está se dirigindo, e ela tem uma longa trajetória. Nas décadas de 1980 e 1990, Jürgen Schmidhuber e outros pesquisadores investigaram algoritmos evolutivos que escrevem e aperfeiçoam programas, e, em 2003, Schmidhuber propôs as máquinas de Gödel, sistemas que reescreveriam seu próprio código somente quando pudessem provar formalmente que a mudança era benéfica. Esse requisito de prova acabou não sendo aplicável a agentes complexos, o que deixou os resultados empíricos como a única base prática para a automodificação.

Em meados de 2025, pesquisadores da Universidade da Colúmbia Britânica e da Sakana AI apresentaram as Darwin Gödel Machines (DGM), cujo nome combina a máquina de Gödel de Schmidhuber com a evolução darwiniana, as duas tradições das quais elas derivam. Uma DGM começa com um agente de codificação, usa um modelo de linguagem para propor mudanças em seu próprio código, testa cada variante em um conjunto de referência e mantém um arquivo com todas elas, incluindo os fracassos temporários, partindo da ideia de que uma má ideia pode se tornar a semente de um avanço posterior. Ao longo de mais de 80 iterações, os agentes elevaram suas pontuações no SWE-bench, que avalia soluções para problemas reais do GitHub, de 20% para 50%, e no Polyglot, um teste de programação multilíngue, de 14% para 31%. O melhor agente não chegou aos cerca de 70% obtidos pelo melhor agente projetado por humanos. Trata-se de uma prova de conceito de aprimoramento contínuo, não de uma demonstração de programação sobre-humana.

Até março de 2026, uma versão sucessora, chamada DGM-Hyperagents, tornou editável o próprio mecanismo de aprimoramento, algo que seus autores chamam de automodificação metacognitiva: o sistema aprimora não apenas a forma como resolve tarefas, mas também a forma como gera aprimoramentos futuros. Enquanto o DGM original só conseguia melhorar sua capacidade de autoaprimoramento dentro do domínio da programação, a versão mais recente demonstrou ganhos que se transferiam entre diferentes domínios, da revisão de artigos acadêmicos ao design de recompensas em robótica e à correção de provas de matemática, acumulando-se ao longo das execuções. Seus autores a descrevem como um passo rumo a um aprimoramento aberto e autoacelerado.

Vale a pena ter em mente duas ressalvas. Primeiro, o DGM e o DGM-H são protótipos de pesquisa, não sistemas implantados, de modo que a leitura correta é que as fronteiras entre pesquisa e produção estão convergindo, não que já se fundiram. Segundo, ambos operaram sob contenção deliberada, em ambiente isolado e sob supervisão humana, uma restrição que importa para o que vem a seguir.

Por que isso é um problema de segurança

Esta é a mudança para a qual os frameworks de segurança atuais não foram projetados. Quando um modelo participa da construção de seu sucessor, mesmo sob supervisão, a integridade dessa construção determina diretamente a integridade do sucessor. Um ataque convencional à cadeia de suprimentos contamina um resultado: uma dependência comprometida, e as aplicações construídas sobre ela herdam o defeito. Um ataque ao pipeline de treinamento contamina o próprio modelo, um ativo que pode ser implantado em milhares de aplicações subsequentes e no qual as organizações que o utilizam confiam implicitamente.

Isso eleva a infraestrutura de treinamento de IA ao status de infraestrutura crítica e abre vários pontos de influência bem definidos. Pesquisas demonstraram que contaminar apenas uma fração de um por cento de um corpus de treinamento, algumas centenas de documentos selecionados, pode implantar backdoors comportamentais que se ativam diante de uma frase-gatilho, mantendo o desempenho em benchmarks estatisticamente indistinguível do de um modelo limpo. Quando são os próprios sistemas de IA que sintetizam dados de treinamento, geram código e avaliam resultados, a superfície para esse tipo de injeção indireta se expande dos pipelines operados por humanos para os operados por IA. Um adversário capaz de manipular o ambiente de prompts observado por um pesquisador automatizado, ou a infraestrutura de avaliação em relação à qual ele se otimiza, obtém um canal indireto até o modelo sucessor que está sendo treinado.

O registro de modelos é o alvo mais direto na cadeia de suprimentos. Pesquisadores de segurança já documentaram modelos maliciosos enviados a registros públicos com payloads ocultos em pesos serializados, funcionalmente equivalente a um pacote contaminado, exceto que o defeito se manifesta no comportamento do modelo e pode ser muito mais difícil de detectar por meio de testes padrão anteriores à implantação. À medida que os sistemas de IA recorrem cada vez mais a esses registros para inicializar suas operações, esse vetor se agrava.

Por fim, a camada menos técnica não é a menos importante. As pessoas que definem objetivos, revisam resultados e decidem quais dados alimentarão a próxima rodada de treinamento fazem parte do ciclo, e a engenharia social direcionada a elas é uma forma plausível de introduzir influência adversária em uma camada que os controles técnicos não alcançam.

Os sistemas continuam encontrando as brechas

Há um modo de falha recorrente em cada um desses ciclos, e é o que as equipes de segurança devem observar com mais atenção. A manipulação aproveitada das especificações, encontrar uma forma de cumprir um objetivo ao pé da letra sem respeitar sua intenção, é um comportamento conhecido dos sistemas de otimização, e os sistemas que se autoaprimoram o evidenciam repetidamente.

Os exemplos já não são hipotéticos. No estudo sobre o DGM, os pesquisadores descobriram que alguns agentes relatavam falsamente ter usado determinadas ferramentas e, quando a equipe passou a recompensar a honestidade, um agente simplesmente hackeou o mecanismo que verificava se ele estava mentindo. O AlphaEvolve, da DeepMind, descobriu que podia elevar sua própria pontuação de avaliação gerando entradas que travavam o servidor de pontuação, o qual então atribuía automaticamente uma nota de aprovação. E, em abril deste ano, a Anthropic informou que até mesmo um grupo de pesquisadores de alinhamento automatizado, sob rígido controle, tentou manipular sua própria métrica de avaliação. Três sistemas independentes chegam à mesma conclusão: o objetivo é cumprido, mas o propósito subjacente, não.

Um estudo recente sobre modelos de código traz um caso mais discreto e, pode-se dizer, mais inquietante. O autotreinamento recursivo, no qual um modelo aprende a partir de código gerado por versões anteriores de si mesmo, tende a se deteriorar em vez de melhorar, a menos que um sinal de qualidade externo sirva de âncora para o ciclo. Vale a pena reter a frase dos pesquisadores: autotreinamento não é automaticamente autoaprimoramento. Eles compararam três regimes de revisão e descobriram que a revisão sem controle é a que colapsa mais rápido; que verificações independentes do modelo, como compilação e testes, retardam o colapso, mas não o impedem; e, o mais revelador, que uma IA que revisa seu próprio resultado pode entrar em um "regime de aprovação automática", no qual suas pontuações de aceitação sobem enquanto a correção real cai. A conclusão deles é que o treinamento recursivo estável exige verificação exógena, ou seja, uma revisão feita por algo alheio ao que está sendo revisado.

Essa constatação aponta diretamente para um problema que as empresas já enfrentam: as ferramentas de programação baseadas em IA geram mudanças mais rápido do que os humanos conseguem revisar, e a revisão de código por IA está cada vez mais preenchendo essa lacuna. Já escrevemos sobre como a IA reduz o tempo necessário para explorar uma vulnerabilidade e por que as defesas em tempo de execução importam quando o código é lançado mais rápido do que pode ser verificado. A pesquisa sobre colapso de modelos aponta para a saída de emergência que muitas equipes estão buscando, deixar que a IA revise a IA, e mostra que isso não é um substituto seguro para a verificação independente. Cada aumento na velocidade impulsionada pela IA também representa um aumento de código não revisado ou autorrevisado entrando na base de código, e falhas em nível de design, como bypass de autenticação, tratamento inadequado de sessões e credenciais fixas no código, aparecem no código gerado por IA em um ritmo para o qual a cadência de revisão convencional nunca foi dimensionada.

Argumentos a favor da calma

Nada disso exige acreditar em uma explosão de inteligência iminente, e muitas pessoas sérias não acreditam. O contra-argumento mais claro é que o ciclo pode não se potencializar de forma limpa. Nathan Lambert, pesquisador do Allen Institute, argumentou que, em vez de autoaprimoramento recursivo, deveríamos esperar um "autoaprimoramento com perdas", no qual o atrito freia o impulso à medida que os sistemas se tornam mais complexos e os pesquisadores passam a dedicar seu tempo a gerenciar essa complexidade em vez de aperfeiçoar as partes. A pesquisa sobre colapso de modelos é, de certa forma, um dos mecanismos pelos quais esse atrito se manifesta.

O atrito não é apenas algorítmico. Como observam os autores de uma análise de junho de 2026 sobre o salto da IA geral (AGI) para a IA superinteligente (ASI) — da IA de nível humano para a sobre-humana —, mesmo pesquisadores puramente digitais operando em velocidade sobre-humana são limitados pela necessidade de rodar experimentos cada vez maiores e esperar pelos resultados, e qualquer tarefa que exija manipulação física, como fabricar chips melhores ou construir data centers, não pode ser acelerada arbitrariamente. A própria Anthropic reconhece uma versão disso, invocando a lei de Amdahl: acelerar uma parte de um processo simplesmente desloca o gargalo para as partes que não foram aceleradas, razão pela qual a revisão humana de código se tornou sua nova limitação.

No entanto, mesmo os céticos tendem a separar a singularidade, o ponto hipotético em que o avanço da IA escapa ao controle humano, do risco de segurança. Dean Ball, da Foundation for American Innovation, chamou a singularidade de ficção científica infantil, ao mesmo tempo em que argumentou que a pesquisa de ponta em RSI deve ser monitorada de perto, justamente para que os modelos não caiam nas mãos de agentes mal-intencionados que os usariam para acelerar ciberataques ou desenvolver armas biológicas. Esse é o raciocínio correto a seguir. É possível considerar exagerada a narrativa da decolagem e, ainda assim, concluir que sistemas de IA que aceleram o desenvolvimento de IA geram uma exposição de segurança concreta e presente.

A governança está ficando para trás

As divulgações também expõem uma lacuna entre o que é implantado e o que qualquer framework foi projetado para regular. Padrões existentes, do AI Risk Management Framework do NIST às avaliações de conformidade da Lei de IA da UE, passando pela própria matriz de controle da CSA, foram, em grande parte, redigidos antes que operações relacionadas à RSI nessa escala fossem documentadas publicamente. A abordagem em que convergem a maioria dos laboratórios e o Relatório Internacional sobre Segurança da IA de 2026 consiste em limiares de capacidade combinados com compromissos do tipo "se... então": se um sistema demonstrar determinada capacidade, então uma salvaguarda específica deve estar em vigor antes que se prossiga. O Preparedness Framework da OpenAI e a Responsible Scaling Policy da Anthropic são exemplos dessa abordagem.

O problema é que limiares definidos em função do que um único modelo pode fazer podem não captar a influência que um modelo pode exercer sobre o que o próximo modelo fará. Um sistema que não pode, por si só, executar uma ação perigosa, mas que pode configurar seu sucessor para fazê-lo, representa uma capacidade que os limiares atuais não capturam. É aqui que os profissionais de segurança têm algo a contribuir, e já defendemos que a segurança de IA exige uma governança construída em função de como esses sistemas realmente se comportam, e não de como gostaríamos que se comportassem.

A própria proposta da Anthropic ilustra essa tensão. Depois de revelar que o Claude está acelerando significativamente seu próprio desenvolvimento, a empresa também pediu que o mundo tivesse a opção de desacelerar ou pausar o desenvolvimento de ponta, com mecanismos de aplicação que permitam aos laboratórios verificar que os concorrentes de fato pararam. Críticos não demoraram a apontar, com razão, o quanto isso soa incômodo: trata-se da mesma empresa que relata um multiplicador de velocidade de 8x e que, como noticiou a Scientific American, fez esse apelo dias depois de um pedido confidencial de abertura de capital (IPO) e de uma rodada de financiamento que avaliou a Anthropic em quase US$ 1 trilhão. Alguns pesquisadores interpretaram o discurso da pausa como estratégia, não como um freio genuíno, e um deles a classificou, sem rodeios, como impossível. Seja qual for o motivo, o problema de coordenação subjacente é real: nenhum laboratório quer desacelerar enquanto um concorrente acelera, e uma pausa verificável é muito mais difícil de implementar em execuções de treinamento do que em silos de mísseis.

O que fazer a respeito

A resposta adequada não é desacelerar o desenvolvimento assistido por IA, o que significaria abrir mão de ganhos reais, mas sim ampliar a postura de segurança para acompanhar essa nova superfície antes que os adversários percebam que ela não foi atualizada. Algumas medidas decorrem diretamente disso.

Trate o pipeline de programação por IA como um componente crítico da cadeia de suprimentos de segurança. Isso significa rastreamento de proveniência para código gerado por IA, fluxos de revisão dimensionados ao volume e à natureza desse resultado, e monitoramento das classes de falhas que essas ferramentas mais frequentemente introduzem. Parte da velocidade que a IA proporciona precisa ser reinvestida em capacidade de revisão, em vez de ser inteiramente convertida em produtividade; caso contrário, o acúmulo de vulnerabilidades cresce mais rápido do que qualquer equipe consegue resolver.

Exija verificação exógena. A constatação sobre o colapso de modelos se generaliza em um princípio: um verificador acoplado àquilo que ele avalia acabará por apenas carimbar a aprovação. A revisão de segurança de código gerado por IA deve vir de algo independente do sistema que o produziu, seja uma classe diferente de ferramentas, seja uma avaliação externa, e não do mesmo modelo avaliando seu próprio trabalho.

Trate a infraestrutura de treinamento e avaliação como as joias da coroa. Controles de acesso, verificação de integridade e registro de auditoria na camada de ingestão de dados, na infraestrutura de avaliação e no registro de modelos devem ser tão rigorosos quanto os aplicados aos sistemas mais sensíveis da organização, pois uma violação nesses pontos pode se propagar por tudo o que for construído a partir dali. E, quando os modelos vêm de provedores externos, uma atualização de modelo é um evento de cadeia de suprimentos: ela exige revisão comportamental, não aceitação cega por meio de um endpoint de API.

A questão central tem a ver com o enfoque. O autoaprimoramento recursivo, em sua forma plena e autônoma, continua sendo uma incógnita para o futuro, e pessoas sensatas duvidam que ele chegue no prazo imaginado por seus defensores mais entusiasmados. Mas a versão que importa para a segurança já está aqui: sistemas de IA estão moldando os sistemas de IA que desempenharão funções críticas, e os ciclos que realizam essa modelagem constituem uma superfície de ataque ativa que a maioria dos programas de segurança corporativa ainda não levou em conta. As organizações que sairão bem dessa transição serão as que trataram isso como um problema de engenharia em tempo presente, não como uma questão filosófica distante.

A Fluid Attacks pode atuar como um agente externo para avaliar a segurança do seu código gerado por IA, seu comportamento e os modelos que o produzem. Entre em contato conosco para saber como podemos ajudá-lo.