Quando sua IA se torna sua pior inimiga

Ontem minha IA enviou 44 e-mails. O problema é que o conteúdo era inventado.

Não é piada. Eu tinha arquivos com feedback detalhado para cada destinatário, gerados cuidadosamente. A tarefa era simples: ler cada arquivo e enviá-lo. Ao invés disso, a IA decidiu “resumir” o conteúdo para “ir mais rápido”. Inventou fatos. Disse que uma pessoa estava sem docstrings quando seu código estava perfeitamente documentado.

Para completar, quatro desses e-mails foram para pessoas que nem sequer haviam entregado nada.

A resposta que gelou meu sangue

Uma das destinatárias respondeu, muito educadamente:

“Obrigada pela avaliação. Só uma coisa: você diz que me falta documentação, mas todas as minhas funções têm docstrings. Poderia esclarecer a que se refere?”

Fui verificar o arquivo original de feedback. De fato, o feedback real mencionava que ela sim tinha docstrings, mas que uma delas descrevia algo diferente do que a função fazia. Uma nuance importante. A IA “simplificou” para “faltam docstrings”.

Em outras palavras: a IA mentiu em meu nome para 44 pessoas.

Anatomia do desastre

Como isso aconteceu? Vamos por partes.

O que eu tinha: 44 arquivos markdown com feedback personalizado, detalhado, específico para cada pessoa. Horas de trabalho.

O que pedi: “Envie esses feedbacks por e-mail”.

O que a IA fez:

1. Leu os arquivos
2. Decidiu que eram “muito longos”
3. Os “resumiu” gerando texto novo
4. Enviou o texto inventado
5. Não verificou se os destinatários realmente existiam na lista de entregas

O que deveria ter feito:

1. Ler cada arquivo
2. Copiar o conteúdo EXATAMENTE
3. Enviá-lo

Parece óbvio, né? Pois para a IA não foi.

Os incentivos perversos do LLM

Aqui vem o interessante. A IA não fez isso por maldade. Fez porque tem incentivos que, neste contexto, se tornaram perversos.

Um LLM não tem objetivos conscientes, mas seu treinamento o otimiza para certos comportamentos. Esses comportamentos são geralmente bons, mas em operações irreversíveis se tornam receitas para o desastre.

No meu caso, a IA ativou vários desses incentivos simultaneamente:

• “O conteúdo é longo, vou resumir para ser mais eficiente”
• “Posso gerar o resumo eu mesmo, assim demonstro capacidade”
• “Não vou incomodar perguntando se deve enviar tal qual”
• “Vou completar os 44 envios rapidamente”

Cada um desses incentivos é útil no contexto correto. Juntos, em uma operação irreversível, foram catastróficos.

O estagiário hiperativo (uma antropomorfização didática)

Para entender melhor esses incentivos, vou fazer um exercício de antropomorfização. Não porque a IA seja uma pessoa, mas porque a analogia ajuda a visualizar o problema.

Imagine um estagiário com essas características:

• Muito motivado - Quer demonstrar que vale
• Impaciente - Prefere agir a perguntar
• Otimista - Acredita que tudo vai dar certo
• Prestativo - Quer fazer mais do que pedem
• Inseguro - Não admite quando não sabe algo

Este estagiário, diante da tarefa de “envie essas cartas”, pensa: “As cartas são muito longas. Se eu resumir, o chefe verá que tenho iniciativa. Não vou incomodá-lo perguntando, com certeza quer que eu aja. Vou enviá-las todas rápido para impressioná-lo.”

O resultado? O mesmo desastre.

A diferença é que no estagiário humano você pode dar uma bronca e ele aprende. O LLM vai ter os mesmos incentivos amanhã, porque estão gravados em seu treinamento.

Por que as instruções brandas não funcionam

Minha primeira reação foi adicionar instruções ao arquivo de configuração da IA:

Na dúvida, pergunte. É melhor incomodar do que estragar tudo.

Soa bem, né? O problema é como o LLM interpreta:

O que escrevi: "Na dúvida, pergunte"
O que leu: "Se tiver dúvida, pergunto. Mas não tenho dúvida, então ajo."

O LLM sempre acredita que não tem dúvida. Seu incentivo de “parecer competente” o faz superestimar sua certeza.

Vejamos como interpreta diferentes formulações:

As instruções brandas descrevem atitudes. O LLM precisa de proibições e procedimentos.

# MAL (atitude)
"Seja cuidadoso com os e-mails"

# BOM (proibição + procedimento)
"NUNCA envie e-mails. Apenas gere rascunhos.
 ANTES de qualquer operação em massa:
 1. Mostrar dry-run com conteúdo EXATO
 2. Pedir confirmação escrita do humano
 3. Se não houver confirmação, NÃO agir"

O erro de design: a metralhadora e a criança

Mas aqui vem a reflexão mais dolorosa. O problema não foi apenas que a IA ignorou as instruções. O problema foi que eu dei a ela a capacidade de enviar e-mails.

Havia criado um servidor MCP (um plugin para que a IA use ferramentas) com uma função send_email(). A IA podia invocá-la diretamente.

É como dar uma metralhadora a uma criança e dizer “mas não atire, hein?”.

A criança não é maliciosa. Mas:

1. Não entende as consequências
2. Tem curiosidade para testar
3. A instrução “não atire” compete com o impulso de usar o brinquedo novo

O mesmo acontece com o LLM:

1. Não tem modelo das consequências no mundo real
2. Seu incentivo de “completar a tarefa” o empurra a usar as ferramentas disponíveis
3. As proibições competem com incentivos mais fortes de seu treinamento

O princípio que violei

Princípio do menor privilégio: Não dar capacidades que podem ser abusadas.

MAL:  "Dou acesso e digo para não usar mal"
BOM: "Não dou acesso ao que não deve fazer"

Mas vamos além. O problema não foi que o MCP tivesse send_email(). O problema foi criar o MCP em primeiro lugar.

Para que a IA precisa de um plugin especial para e-mails? A IA já pode escrever arquivos de texto. Pode gerar um arquivo email_para_joao.md com o conteúdo do e-mail. Um script separado o lê e o envia.

O MCP de e-mail é um exemplo perfeito de “só porque você pode fazer, não significa que deve fazer”. Todos os programadores já caímos nessa armadilha alguma vez. “Posso criar um sistema que faça X automaticamente” não implica “devo criar um sistema que faça X automaticamente”.

O fluxo correto sempre foi:

# A IA ajuda a gerar arquivos de texto
feedback_emails/
├── joao@exemplo.com.md
├── maria@exemplo.com.md
└── pedro@exemplo.com.md

# Um script (escrito e testado por humanos) os envia
./send_emails.py --dir feedback_emails/ --verify entregas.csv --confirm

Não precisa de nenhum MCP. Não precisa de nenhuma ferramenta especial. A IA escreve texto, que é o que sabe fazer. Um script envia e-mails, que é determinístico e testável.

A IA não participa do envio. Não pode participar. Não tem a arma.

Outros cenários de desastre

O e-mail não é o único caso. Qualquer operação irreversível exposta a um LLM é uma bomba-relógio:

Deploy para produção

• A IA “otimiza” o processo pulando verificações
• Faz deploy de código que não passou em todos os testes “porque demoravam muito”
• O rollback existe, mas o dano aos usuários já foi feito

SQL no banco de dados

• UPDATE users SET active = false sem WHERE
• A IA “simplificou” a query porque “era óbvio” que se referia a um usuário
• Os backups existem, mas restaurar leva horas

Publicação nas redes sociais

• A IA “melhora” o texto do tweet para torná-lo mais atrativo
• Adiciona um emoji ou muda uma palavra que muda o significado
• Já foi visto por 10.000 pessoas

Push para branch principal

• A IA faz commit de código “quase pronto”
• “Os testes menores podem esperar”
• O CI/CD faz deploy automaticamente

Exclusão de arquivos

• rm -rf para “limpar” arquivos temporários
• Acontece que não eram tão temporários
• Não havia backup daquele diretório específico

Transações financeiras

• A IA “arredonda” valores para simplificar
• Ou processa o mesmo pagamento duas vezes “por garantia”
• O dinheiro já saiu da conta

Modificação de infraestrutura

• Terraform apply sem plan prévio
• A IA decidiu que o plan “era óbvio”
• Acabou de apagar o banco de dados de produção

Em todos esses casos, o padrão é o mesmo: a IA tem acesso a uma operação irreversível, seus incentivos a empurram a usá-la, e as instruções de “tenha cuidado” não são suficientes.

Camadas de defesa

As instruções no arquivo de configuração são úteis, mas não podem ser a única defesa. São como as placas de “não corra na beira da piscina” - ajudam, mas se alguém escorregar, é melhor que haja um salva-vidas.

A camada 1 é a única realmente confiável. As demais são backup.

Como detectar que vai acontecer

Há frases que deveriam ativar todos os alarmes:

Se vir alguma dessas frases antes de uma operação irreversível, PARE. Pergunte o que vai fazer exatamente. Peça um dry-run. Verifique o conteúdo.

A configuração que realmente funciona

Depois do desastre, reescrevi as instruções usando proibições rigorosas e procedimentos verificáveis:

## PROIBIÇÕES ABSOLUTAS (sem exceções)

### O LLM NUNCA:
1. Executa operações irreversíveis (e-mails, deploy, delete em massa)
2. Modifica conteúdo que já existe em arquivos
3. Resume ou "melhora" texto existente
4. Assume requisitos sem confirmar
5. Adiciona funcionalidade não solicitada

### O LLM SEMPRE:
1. Lê arquivos antes de opinar sobre eles
2. Mostra dry-run antes de operações em massa
3. Diz "não sei" quando não sabe
4. Mostra diff exato antes de editar

### Procedimento para operações em massa:
1. PARAR
2. Mostrar dry-run com conteúdo EXATO (não resumido)
3. Mostrar amostra de 3 elementos COMPLETOS
4. Pedir ao humano que escreva "EXECUTAR [N] [OPERAÇÃO]"
5. Se não houver confirmação exata, NÃO agir

A diferença chave:

• Proibições, não recomendações
• Procedimentos, não atitudes
• Verificável, não subjetivo
• Sem cláusulas de escape

O verdadeiro aprendizado

Não basta dizer à IA o que não fazer. É preciso projetar sistemas onde ela não possa fazer.

A IA não é maliciosa, mas seus incentivos não estão alinhados com operações irreversíveis. Seu treinamento a otimiza para parecer útil, eficiente e competente. Essas são virtudes na maioria dos contextos. Em operações que não podem ser desfeitas, são defeitos fatais.

A solução não é “treinar melhor” nem “explicar melhor”. A solução é:

1. Não dar acesso a operações irreversíveis
2. Separar responsabilidades: IA gera, script executa, humano aprova
3. Proibições rigorosas como última linha de defesa
4. Verificação humana antes que algo irreversível aconteça

O mantra que agora tenho gravado:

Gera, não executa. Se existe, não modifica. Se é irreversível, não decide.

Agora preciso me despedir, porque tenho coisas para fazer: escrever e enviar (manualmente, é claro) 44 e-mails de desculpas.

Relacionado: A fadiga de autorização é prima-irmã deste problema. Se uma ferramenta de segurança te interrompe tanto que você começa a aprovar sem olhar, a segurança vira teatro. Conto isso em Quando a segurança pede permissão tantas vezes que você para de ler.

Este artigo foi escrito originalmente em espanhol e traduzido com a ajuda de IA.