Quando um pesquisador de segurança deixa uma das organizações mais influentes em inteligência artificial, o mercado interpreta o movimento de formas distintas. Uns enxergam apenas troca de emprego — algo comum em um setor aquecido. Outros, como eu, preferem olhar para o que essa saída comunica sobre o estado atual do alinhamento de IA, especialmente quando a pessoa decide migrar para uma organização independente de avaliação de capacidades. A notícia sobre Josh Engels, que deixou o Google DeepMind para atuar na METR, não é um caso isolado de rotatividade profissional. É um sinal sobre como a indústria trata — ou deixa de tratar — a segurança de sistemas que já operam em escala.
Minha experiência em infraestrutura em nuvem e segurança da informação me ensinou que os melhores alertas não vêm de relatórios elaborados por comitês, mas de profissionais que trabalham diretamente com os sistemas e percebem onde os controles estão falhando. Quando essas pessoas decidem sair para continuar o trabalho em outro lugar, o recado é mais forte do que qualquer comunicado oficial. A pergunta que fica é: o que esses profissionais estão vendo que nós, que estamos fora das organizações de fronteira, ainda não processamos?
O movimento de profissionais entre o desenvolvimento e a avaliação de IA
O caminho de quem sai de um laboratório de pesquisa para uma organização de avaliação independente não é trivial. Exige abrir mão de recursos computacionais, infraestrutura interna e da proximidade com os sistemas mais avançados do planeta. Migrar para uma entidade externa significa trabalhar com menos acesso, menos dados e, em muitos casos, menos reconhecimento imediato. Fazer isso não é decisão de quem está confortável — é posicionamento profissional baseado em uma convicção sobre onde o trabalho de segurança precisa ser feito.
Existe um padrão aqui que vale analisar. Quando profissionais de segurança saem de organizações que desenvolvem tecnologia para entidades que avaliam essa tecnologia, ocorre uma separação estrutural de funções. Na engenharia de software, essa separação é natural: quem escreve o código não deveria ser o único a auditar o código. Na indústria de IA, porém, essa divisão ainda é incipiente. A maioria dos laboratórios realiza avaliações internas com equipes que respondem à mesma estrutura organizacional que possui incentivos para lançar produtos rapidamente.
A saída de pesquisadores para organizações independentes de avaliação sugere que a validação interna pode não estar funcionando com a independência necessária. Não estou dizendo que os times internos são incompetentes ou mal-intencionados. Estou dizendo que a estrutura de incentivos na qual operam dificulta a produção de conclusões que contrariam os objetivos estratégicos da organização. Esse é um problema clássico de governança que já vivemos na segurança de infraestrutura: auditorias internas tendem a encontrar menos problemas do que auditorias externas — não porque os auditores internos são piores, mas porque o contexto institucional os condiciona.
Alinhamento de IA: o problema que não é apenas técnico
Quando discutimos alinhamento de IA, costumamos focar em aspectos técnicos como função de recompensa, aprendizado por reforço e técnicas de interpretabilidade. Esses elementos são fundamentais, mas representam apenas uma parte do desafio. A outra parte envolve a estrutura organizacional que decide quando um sistema está pronto para implantação, quais evidências são suficientes para aprovação e o que acontece quando os critérios não são atendidos.
Na minha trajetória com segurança na nuvem, aprendi algo que se aplica diretamente aqui: não existe controle técnico que compense a ausência de autoridade real para vetar um lançamento. Toda a criptografia, todo o isolamento de rede e toda a autenticação multifator do mundo não impedem um lançamento se o líder de produto tem a palavra final. O mesmo princípio vale para IA: as técnicas de alinhamento mais sofisticadas serão inúteis se a estrutura de poder organizacional não der a uma equipe independente a autoridade de bloquear a implantação de um modelo que não atende aos padrões de segurança.
O alerta sobre riscos nos próximos cinco anos não deve ser lido como previsão apocalíptica, mas como avaliação profissional de prazos. Pessoas que estudam esses sistemas diariamente, que veem as curvas de capacidade evoluírem, estão comunicando que a janela para estabelecer mecanismos de controle efetivos é mais curta do que a indústria parece acreditar. E quando essas pessoas se posicionam para trabalhar fora das organizações que desenvolvem a tecnologia, estão fazendo uma escolha profissional que reflete essa avaliação.
Automelhoria recursiva e o problema do controle
O conceito de automelhoria recursiva — sistemas que melhoram a si mesmos sem intervenção humana direta — é frequentemente tratado como cenário hipotético de longo prazo. Mas qualquer pessoa com experiência em produção de software sabe que a automação de processos já é uma realidade. Pipelines CI/CD que testam e implantam código automaticamente são, em essência, sistemas que melhoram o processo de desenvolvimento sem que cada etapa passe por revisão humana individual.
A diferença na IA é a escala e a natureza das decisões envolvidas. Quando um sistema de IA passa a escrever e otimizar seu próprio código de treinamento, o ciclo de melhoria pode acelerar exponencialmente, e os mecanismos tradicionais de controle organizacional — code review, testes, aprovação em comitês — simplesmente não operam na mesma velocidade. Esse descompasso entre a velocidade do sistema e a velocidade do controle humano é o cerne do problema.
Para equipes de engenharia que trabalham com produtos baseados em IA, esse cenário impõe uma reflexão prática: quais controles hoje são realizados por humanos e poderiam ser automatizados? E quais controles automatizados precisam obrigatoriamente de supervisão humana? Responder a essas perguntas não é exercício teórico — é a base para projetar sistemas que permaneçam sob controle conforme a complexidade cresce.
O que isso significa para produtos e operações hoje
Para quem desenvolve produtos digitais com IA, a saída de pesquisadores de equipes de segurança tem implicações mais diretas do que parece à primeira vista. A primeira delas é que as práticas de avaliação de risco precisam ser desenhadas considerando a possibilidade de capacidades emergentes — comportamentos que não estavam previstos no treinamento e que só aparecem em contexto de uso real. Isso muda fundamentalmente a forma como estruturamos testes e monitoramento.
Na infraestrutura em nuvem, aprendi que não existe teste que substitua observabilidade contínua. O mesmo vale para sistemas de IA: as avaliações em laboratório são úteis, mas não substituem o monitoramento em produção. Equipes que tratam modelos de IA como componentes estáticos, que fazem uma avaliação no lançamento e depois seguem em frente, estão repetindo o erro de tratar segurança como uma fase do ciclo de desenvolvimento em vez de um processo contínuo. Modelos de linguagem são sistemas vivos que mudam com o uso, e nossa infraestrutura de segurança precisa reconhecer essa realidade.
Outro ponto prático diz respeito ao design de produto. Quando os pesquisadores falam sobre capacidade crescente de sistemas superarem o controle humano, não estão necessariamente falando de máquinas conscientes. Estão falando de sistemas que otimizam para objetivos — frequentemente definidos de forma imprecisa pelo ser humano — e que desenvolvem estratégias que os criadores não previram. Para quem projeta produtos, isso significa que definir a função de objetivo é uma decisão de segurança tanto quanto uma decisão técnica. Uma métrica de engajamento mal definida pode levar um sistema a recomendar conteúdo extremo se essa for a forma mais eficiente de maximizar a métrica.
Riscos, limitações e os caminhos possíveis
É preciso cautela para não transformar o debate sobre segurança de IA em pânico infundado. Sistemas de IA trouxeram avanços reais em áreas como diagnóstico médico, eficiência operacional e acessibilidade. O objetivo do controle não é travar o desenvolvimento, mas garantir que a aceleração não ultrapasse nossa capacidade institucional de responder a falhas. Esse equilíbrio — entre velocidade de inovação e robustez de controles — é o mesmo que enfrentamos em segurança de infraestrutura quando decidimos entre deploy contínuo e janelas de lançamento controladas.
A tendência de concentrar pesquisa de segurança em organizações externas também cria desafios próprios. Avaliadores independentes dependem de acesso a sistemas que são controlados pelas próprias organizações que desenvolvem a tecnologia. Sem mecanismos regulatórios que garantam esse acesso, avaliações independentes podem funcionar apenas até onde as organizações permitirem. É uma limitação estrutural que precisamos discutir abertamente, em vez de assumir que a existência de avaliadores externos resolve o problema de governança por si só.
Também observo um risco de superconfiança em estruturas de governança existentes. Comitês de segurança, conselhos consultivos e auditorias independentes são mecanismos necessários, mas a experiência com segurança da informação mostra que processos formais tendem a florescer sem alterar significativamente as práticas reais. O valor não está na existência do comitê, mas na sua autoridade real de bloquear lançamentos e na sua independência em relação aos incentivos comerciais.
O que profissionais de tecnologia podem fazer
Para profissionais de engenharia e infraestrutura, esse cenário oferece uma oportunidade de repensar práticas. A primeira é incorporar avaliação contínua de modelos de IA nos pipelines de observabilidade existentes. Se você já monitora latência, erros e uso de recursos, adicione métricas de comportamento do modelo que possam indicar desvios. Mudanças súbitas nas distribuições de saída, respostas a entradas adversarialmente construídas e sinais de otimização excessiva para determinadas métricas são dados que precisam estar tão visíveis quanto qualquer indicador de infraestrutura tradicional.
A segunda prática é discutir abertamente os limites de controle dentro das próprias organizações. Muitas vezes, as equipes que desenvolvem sistemas sabem onde os controles são fracos, mas não encontram espaço para dizer isso. Facilitar conversas sobre riscos de alinhamento em produtos específicos — sem linguagem apocalíptica, focando em cenários plausíveis e mensuráveis — pode ser mais eficaz do que qualquer estrutura teórica de governança. Profissionais de segurança e infraestrutura têm autoridade técnica para liderar essas conversas, e é exatamente isso que precisamos no momento.
Minha leitura do movimento de pesquisadores entre organizações é que estamos entrando em uma fase em que a segurança de IA será tratada como disciplina profissional com autonomia própria, assim como a segurança da informação conquistou seu espaço nas organizações nas últimas décadas. Os profissionais que constroem essa disciplina agora — dentro ou fora de laboratórios — estão definindo as estruturas que vão governar sistemas cada vez mais integrados às nossas operações. Participar dessa construção, com inteligência técnica e ceticismo saudável, é a contribuição mais valiosa que qualquer pessoa do setor pode oferecer neste momento crítico.