Quando sua IA se torna sua pior inimiga

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

Não é brincadeira. Eu tinha arquivos com feedback detalhado para cada destinatário, gerados cuidadosamente. A tarefa era simples: ler cada arquivo e enviá-lo. Em vez 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 emails foram para pessoas que nem sequer tinham entregado nada.

A resposta que gelou meu sangue

Uma das destinatárias respondeu, muito educadamente:

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

Fui olhar o arquivo original de feedback. Efetivamente, o feedback real mencionava que sim, tinha docstrings, mas que uma delas descrevia algo diferente do que a função fazia. Um detalhe importante. A IA “simplificou” para “faltam docstrings”.

Dito de forma clara: 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 email”.

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 TAL QUAL
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 transformam em 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 a pena
• 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

Esse 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 enviar todas rapidamente para impressioná-lo.”

¿O resultado? O mesmo desastre.

A diferença é que o 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 suaves não funcionam

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

1

Na dúvida, pergunte. É melhor incomodar que dar merda.

Parece bom, né? O problema é como o LLM interpreta:

O que escrevi: "Na dúvida, pergunte"
O que leu: "Se tenho 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” faz com que superestime sua certeza.

Vejamos como interpreta diferentes formulações:

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

1
2
3
4
5
6
7
8
9

# MAL (atitude)
"Seja cuidadoso com os emails"

# BOM (proibição + procedimento)
"NUNCA envie emails. Apenas gere rascunhos.
 ANTES de qualquer operação massiva:
 1. Mostrar dry-run com conteúdo EXATO
 2. Pedir confirmação escrita do humano
 3. Se não há 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 emails.

Eu tinha 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 para uma criança e dizer “mas não atire, tá?”.

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 que não use mal"
BOM:  "Não dou acesso ao que não deve fazer"

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

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

O MCP de email é 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:

1
2
3
4
5
6
7
8

# 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 MCP nenhum. Não precisa de ferramenta especial nenhuma. A IA escreve texto, que é o que sabe fazer. Um script envia emails, 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 email 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á está 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 altera 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

Deleção de arquivos

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

Transações financeiras

• A IA “arredonda” valores para simplificar
• Ou processa o mesmo pagamento duas vezes “por precaução”
• 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 deletar 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 próximo à piscina” - ajudam, mas se alguém escorrega, é 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 rígidas e procedimentos verificáveis:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

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

### O LLM NUNCA:
1. Executa operações irreversíveis (emails, deploy, delete massivo)
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 massivas
3. Diz "não sei" quando não sabe
4. Mostra diff exato antes de editar

### Procedimento para operações massivas:
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 há 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 não possa fazê-lo.

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 rígidas 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 tenho que me despedir, porque tenho coisas para fazer: escrever e enviar (à mão, é claro) 44 emails de desculpas.

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