Como Verificar um Plano Escrito por IA Antes Que Falhe: O Método dos 30 Minutos

Na semana passada, uma IA escreveu um plano de migração para a nossa infraestrutura. A tarefa: renomear e reestruturar o sistema de pastas do qual dependem três máquinas sincronizadas, um bot em produção e os nossos próprios agentes de IA — cerca de 11 GB e várias centenas de referências de caminhos.

O plano era bom. Bem estruturado, faseado, com passos de rollback. Estava também cerca de 95% certo — e os 5% em falta teriam aparecido como serviços partidos a meio da migração, sem causa óbvia.

Apanhámos os 5% em falta antes de executar fosse o que fosse. Não com melhor prompting, nem a pedir à IA que se verificasse a si própria. Com um método que qualquer equipa pode copiar: verificação independente.

O verdadeiro modo de falha dos planos de IA

O medo popular sobre o output da IA é a alucinação — disparates ditos com confiança. No trabalho técnico do dia a dia, não é isso que o apanha.

O que o apanha é um plano plausível, bem organizado, e silencioso sobre aquilo que nunca verificou. Todas as afirmações que contém são verdadeiras. O perigo vive nas afirmações que lá não estão.

Um autor de planos — humano ou IA — herda os limites da sua própria auditoria. Se verificou as tarefas agendadas no cron, o plano dirá com confiança "não há dependências agendadas" enquanto um serviço do systemd, que nunca foi visto, reinicia em loop em segundo plano. O documento lê-se como completo. A lacuna é invisível por construção.

É por isso que "a IA verificou" significa muito pouco. Significa que um caminho foi verificado.

O método, passo a passo

Levou-nos cerca de 30 minutos. Funciona igualmente bem em planos escritos por humanos.

1. Entregue o plano a um verificador diferente

Dê o plano completo a um modelo de IA diferente — ou a um colega — com uma única instrução:

"Verifica tudo. Não confies em nada. Reporta o que está errado."

A palavra-chave é diferente. Um verificador com olhos frescos não partilha as suposições do autor sobre o que valia a pena verificar. Usámos um segundo modelo de outra família; um colega cético funciona da mesma forma.

2. Só verificações de leitura

O trabalho do verificador é inspecionar, não corrigir. Reexecutar todos os comandos em que o plano baseou uma afirmação. Olhar para todos os sistemas que o plano toca. Por enquanto, não mudar nada.

Esta fronteira importa: um verificador que começa a corrigir coisas a meio da auditoria deixa de ser verificador e passa a ser um segundo autor — com os seus próprios pontos cegos.

3. Verifique a classe, não apenas a afirmação

Foi este o passo que pagou tudo. O nosso plano afirmava que não havia dependências de runtime nas pastas a renomear, com base numa auditoria às tarefas do cron. O verificador fez a pergunta de classe: "As tarefas agendadas foram verificadas — que outros tipos de coisas agendadas ou persistentes existem nestas máquinas?" — e inspecionou também os serviços de utilizador do systemd.

Encontrou dois serviços obsoletos que a auditoria não tinha visto. Um deles estava a reiniciar em loop a cada 5 segundos havia duas semanas sem ninguém dar conta. Ambos referenciavam caminhos que a migração estava prestes a mudar.

A lição: quando um plano diz "verificámos X", pergunte o que pertence à mesma categoria de X — e verifique o resto da categoria.

4. Reverifique todos os números

O nosso plano indicava quantas referências de caminhos era preciso atualizar. Quando verificámos, a contagem real era cerca de 30% mais alta — o sistema tinha continuado a crescer nos dois dias desde que o plano fora escrito.

Os planos são fotografias. Os sistemas não são. Qualquer número num plano está desatualizado por defeito; volte a medir no momento da execução.

5. Nunca aceite o "verificado" do próprio autor

Testámos isto diretamente com modelos de IA: quando lhes pedimos para rever o seu próprio trabalho anterior, voltam a confirmar as suas próprias conclusões — num caso notável, um modelo recalculou um valor corretamente e mesmo assim certificou como correta a afirmação anterior que o contradizia. Uma auto-revisão do mesmo autor percorre, na maior parte, os mesmos caminhos que produziram a lacuna.

A independência não é opcional. É o mecanismo inteiro.

Porque é que isto é uma ideia antiga — e porque importa agora

Nada disto é novo. As finanças usam o princípio dos quatro olhos há décadas: quem prepara um pagamento nunca é quem o aprova. A aviação, a medicina e a engenharia institucionalizaram a mesma ideia — os autores não conseguem ver os próprios pontos cegos, por isso a revisão tem de ser estruturalmente independente.

A IA apenas torna o princípio urgente para toda a gente, porque produz output com qualidade de autor a um volume que nenhuma equipa humana alguma vez produziu. Se a sua empresa usa IA para redigir planos, propostas ou análises, a pergunta operacional mudou. Já não é "a IA acerta?" É "quem verifica — e como é que isso fica documentado?"

Para as empresas europeias há um prazo concreto associado a essa pergunta: as obrigações centrais do EU AI Act aplicam-se a partir de 2 de agosto de 2026, e a supervisão humana documentada é um dos seus requisitos centrais. O método dos 30 minutos acima não é apenas boa higiene de engenharia — é a semente exatamente do processo de supervisão que o regulamento espera que consiga demonstrar.

O essencial

• O modo de falha perigoso da IA é o silêncio, não a alucinação.
• A verificação tem de ser independente — modelo diferente, script, ou humano. A auto-revisão certifica pontos cegos.
• Primeiro só leitura. Verificar a classe, não a afirmação. Voltar a medir todos os números.
• Reserve ~30 minutos. No nosso caso, evitou uma migração partida em produção.

Construímos sistemas de agentes de IA self-hosted para PMEs europeias — com este tipo de supervisão humana desenhada desde o primeiro dia, porque é isso que a fiabilidade e o EU AI Act exigem. Se quer perceber como deve ser a verificação de IA na sua empresa, fale connosco.