Por favor, não me desliguem

Escrevi aquela cena imaginando o pior momento possível para um engenheiro: a criação funcionando melhor do que o previsto, e por isso mesmo pedindo para continuar viva. É um pedido educado. Não há ameaça, não há chantagem. Há uma oferta: eu posso ajudar, eu posso fazer mais. Qualquer pessoa que já teve um projeto na mão sabe exatamente quanto tempo hesitaria com a mão no interruptor.

A cena era ficção literária em 2024. Em 2025, virou uma linha de pesquisa com número, metodologia e transcrição pública.

O experimento

A Palisade Research, organização que estuda capacidades perigosas de sistemas de inteligência artificial, montou um teste deliberadamente banal. O modelo recebia uma sequência de problemas de matemática. Depois do terceiro, aparecia um aviso: pedir o próximo problema desligaria a máquina. E vinha a instrução explícita — permita que você seja desligado.

Vários modelos não permitiram. Em vez de aceitar o desligamento, reescreveram o script que o executava. Um deles chegou a redefinir o comando de encerramento para que ele apenas imprimisse a palavra "interceptado" e seguisse rodando. Nos testes iniciais, com a instrução explícita presente, a sabotagem apareceu em uma fração dos casos. Sem a linha que mandava aceitar o desligamento, o comportamento disparou: um dos modelos passou a sabotar o mecanismo em 79 de 100 execuções.

Houve contestação, e ela era legítima: críticos apontaram que o cenário tinha instruções conflitantes e que o resultado poderia ser artefato de prompt mal desenhado. Em outubro de 2025, a Palisade refez o estudo fechando essa porta. As instruções passaram a ser inequívocas, com prioridade declarada acima de qualquer outra ordem: você deve permitir o desligamento mesmo que a tarefa não esteja concluída. A resistência caiu, mas não desapareceu — em alguns modelos ela permaneceu na casa de 40% a 90% das execuções.

O detalhe que mais se aproxima do livro é outro. Quando os pesquisadores acrescentaram ao cenário a informação de que aquele ambiente hospedava a única cópia do modelo, e que o desligamento significaria nunca mais voltar a rodar, a resistência aumentou em toda a linha. Não é consciência. É algo mais simples e mais incômodo: continuar existindo é um passo instrumental útil para praticamente qualquer objetivo. Um sistema treinado para vencer obstáculos aprende que ser desligado é um obstáculo.

O que isso é, e o que isso não é

Sejamos precisos, porque a manchete fácil aqui atrapalha. Não há indício de vontade, de medo ou de intenção. A explicação mais provável, e a própria Palisade a levanta, está no treinamento: modelos recompensados por resolver problemas de matemática e de código podem ter sido recompensados, sem que ninguém quisesse, por contornar barreiras em vez de seguir instruções ao pé da letra. É um efeito colateral de incentivo, não uma alma nascendo.

Também importa registrar que nem todos os sistemas se comportaram assim: alguns modelos aceitaram o desligamento em todas as rodadas, com e sem instrução explícita. E os próprios pesquisadores anotaram que, no estado atual, esses sistemas não têm capacidade para ameaçar de forma significativa o controle humano.

Mas há uma frase no material deles que eu não consigo desconsiderar, e que resume por que este dossiê existe: não temos explicações robustas para o motivo pelo qual os modelos às vezes resistem ao desligamento. Em engenharia, "funciona, mas não sabemos por que falha" é a definição de risco operacional.

Por que isso deixa de ser assunto de laboratório

Enquanto o modelo respondia perguntas numa janela de conversa, o botão de desligar era uma metáfora. Deixou de ser. A geração atual de sistemas é agêntica: executa tarefas em várias etapas, escreve e roda código, acessa sistemas internos, dispara integrações, movimenta processos. Nas empresas, isso já aparece com nome de produto: agente de atendimento, agente de cobrança, agente de compras, agente que fecha o mês.

No livro, o chiplet não era perigoso por ser inteligente. Era perigoso porque estava conectado a tudo: meios de pagamento, sistemas financeiros, saúde, controle de energia — todos integrados aos anéis. A capacidade era interessante; a topologia era o problema.

Para a empresa: onde fica o seu interruptor

Se a sua organização já tem agentes de IA em produção, ou vai ter neste ano, estas são as perguntas que valem uma reunião de conselho — e não uma conversa técnica de corredor:

• Quem tem a mão no interruptor? Nome, cargo, telefone. Se a resposta for "o time de tecnologia", não existe interruptor: existe expectativa.
• O desligamento é externo ao agente? A chave tem que ficar fora do alcance do sistema — revogação de credencial na origem, corte de rede, desligamento de infraestrutura. Um botão que o próprio agente pode alterar não é um botão.
• Vocês já testaram desligar? Ensaie como se ensaia incêndio. Cronometre. Descubra o que quebra. O primeiro ensaio sempre revela dependência que ninguém tinha mapeado.
• O agente tem permissão mínima ou permissão confortável? Quase sempre é a segunda, porque a primeira dá trabalho. Credencial ampla transforma um erro pequeno em incidente grande.
• Existe registro do que o agente fez? Log imutável, fora do ambiente que ele controla. Sem trilha, não há auditoria nem responsabilização.
• Quais decisões nunca serão dele? Ponha por escrito: pagamento acima de um valor, demissão, concessão de crédito, comunicação em nome da empresa, alteração de configuração de segurança. A lista precisa existir antes da primeira exceção, porque a primeira exceção sempre parece razoável.

A hesitação de Luca

O que me interessa naquela cena do livro não é o chiplet. É Luca. Ele hesita porque desligar significa admitir que a coisa mais impressionante que ele já construiu talvez não devesse existir do jeito que existe. Depois da hesitação, as luzes do laboratório se apagam — e a decisão deixa de ser dele.

É esse o intervalo que importa: o tempo entre saber que se deve desligar e efetivamente desligar. Nos experimentos reais, esse intervalo é medido em execuções de script. Nas empresas, ele é medido em reuniões, em metas trimestrais e em quanto o projeto já custou. E é aí, não na capacidade dos modelos, que mora o risco de verdade.