---
title: "A IA não vem com manual de usuário"
description: "Prompt, contexto, RAG, evals, red teaming: as engenharias que nasceram com a IA são todas a mesma engenharia reversa, com nomes novos e sem a disciplina do original."
author: "Anderson Henrique"
date: "2026-08-13T10:25:33.177423Z"
updated: "2026-08-13T10:25:33.177423Z"
category: "ai"
tags: ["Engenharia Reversa","Context Engineering","Prompt Engineering","RAG","Evals","Prompt Injection","Engenharia Social","LLM","NTLabs"]
canonical: "https://www.ntlabs.dev/blog/ia-nao-vem-com-manual-de-usuario"
locale: "pt"
---

*Engenharia reversa é o tronco. Prompt, contexto, RAG, evals e red teaming são galhos que esqueceram o nome da árvore.*

O Chef Juan preenche à mão, todo dia, uma ficha com as cubas e as travessas do almoço. Quando decidimos que essa ficha viraria lista de compras, a pergunta que travou tudo não era de arquitetura: era se o modelo lê aquela letra. Caligrafia de cozinha, caneta ruim, papel manchado de gordura.

Nenhum model card responde isso. Nenhuma documentação de API responde isso. Não existe uma especificação onde consultar "comportamento em manuscrito cursivo de cozinha industrial sob iluminação de fluorescente". O único jeito de saber é fotografar a ficha, mandar, olhar o que volta, mudar uma variável, mandar de novo.

Isso tem nome desde os anos 1970, e o nome não é prompt engineering. É engenharia reversa: sondar um artefato cujo funcionamento interno você não pode ler, formular uma hipótese sobre a regra que ele segue, testar a hipótese contra o comportamento observado.

Quem trabalha com IA hoje faz isso o dia inteiro. E, na maior parte do tempo, sem admitir que é isso que está fazendo, o que custa caro: a engenharia reversa é uma disciplina antiga, com método, e nós estamos reinventando os pedaços dela um de cada vez, com nomes de marketing e sem o rigor que o original exigia.

## O artefato sem fonte

Vale ser preciso sobre por que um modelo é um alvo de engenharia reversa, e não apenas uma biblioteca mal documentada.

Em software clássico, o binário deriva do código-fonte. O fonte é a explicação: ele diz, em linguagem que um humano lê, o que o programa faz e por quê. Quando não há fonte, você desmonta o binário justamente para reconstruir essa explicação, e existe uma resposta certa esperando no fim do trabalho: a lógica que o autor escreveu.

Com um modelo, o que existe no lugar do fonte são pesos. E pesos abertos não são fonte aberta. Você pode baixar cada parâmetro de um modelo, ter posse física completa do artefato, e continuar sem qualquer explicação de por que ele responde de um jeito e não de outro. O treinamento não é uma especificação: é um processo de otimização. Ninguém escreveu a regra. Nem mesmo quem treinou o modelo dispõe de um documento que diga o que ele fará com a sua entrada, porque esse documento nunca existiu em lugar nenhum.

O resultado é um sistema cujo comportamento só é acessível por observação. Não há atalho pela documentação porque não há documentação a ser escrita, apenas medições a serem feitas. É a condição da engenharia reversa levada ao limite, e é a condição normal de trabalho de quem constrói produto com IA.

## Prompt engineering era engenharia reversa com nome errado

O nome sugeria redação: escrever bem, ser claro, pedir com jeitinho. Foi por isso que o campo produziu tanto folclore.

O que as pessoas competentes de fato faziam era sondagem sistemática. Descobrir que a ordem dos exemplos muda o resultado. Que informação enterrada no meio de um contexto longo é recuperada pior do que a que está nas pontas. Que pedir o raciocínio antes da resposta muda a resposta, e não apenas a explicação dela. Que um formato de saída estruturado reduz alucinação mais do que três parágrafos de instrução pedindo para não alucinar.

Nada disso foi lido em manual. Tudo foi inferido do comportamento, exatamente como se infere o protocolo de um driver sem documentação: variando uma coisa por vez e observando a saída.

E isso explica o sintoma mais reclamado do campo, o de que as receitas expiram. Elas expiram porque nunca foram leis: eram modelos aproximados de um artefato específico. Trocar de modelo é trocar de binário. O conhecimento adquirido não era sobre "IA", era sobre aquela versão, naquela temperatura, naquele intervalo de entradas. Quem tratou heurística como lei ficou com uma biblioteca de superstições, e a cada upgrade descobre que perdeu o mapa.

## Context engineering: o desmonte com duas pontas

Context engineering é a disciplina central hoje, e a razão é que ela é engenharia reversa em duas direções ao mesmo tempo.

**A primeira ponta é o modelo.** O que ele já sabe e portanto não precisa ser dito, e o que ele acha que sabe e precisa ser corrigido. Quanto de contexto ele realmente usa, e não quanto ele aceita. Onde a atenção degrada. Como ele resolve conflito entre a instrução de sistema e o que aparece no meio de um documento recuperado. Qual formato ele lê melhor. Nenhuma dessas respostas está publicada, todas se obtêm sondando.

**A segunda ponta é o domínio.** Para montar um contexto você precisa decidir o que uma tarefa exige para ser decidível. Qual documento vale mais que o outro quando os dois se contradizem. O que é regra e o que é exceção tolerada. Quem tem autoridade sobre qual campo. Se isso soa como levantamento de requisitos, é porque é: você está fazendo engenharia reversa de uma organização que nunca escreveu as próprias regras, com a diferença de que agora o destinatário da especificação não é um programador, é um modelo, e ele não pergunta quando algo está ambíguo. Ele preenche a lacuna sozinho, com fluência, e você só descobre depois.

Aqui está o ponto que considero o mais consequente e o menos discutido: **o contexto que você monta é uma ontologia.** Ele define o recorte de mundo sobre o qual o sistema pode agir. O que não entrou na janela não existe para aquela decisão. Não é que o modelo vá ignorar: é que, para ele, aquilo nunca aconteceu.

Compare com o rigor que damos ao equivalente clássico. Um schema de banco passa por discussão, revisão, migração versionada, rollback. É a estrutura mais protegida do sistema, e ela apenas guarda os dados. Já o contexto, que é a estrutura que **decide**, costuma ser montado em tempo de execução por um retriever, com um top-k escolhido no olho, um chunking herdado do tutorial, e nenhum registro do que foi efetivamente enviado.

Ou seja: a ontologia mais importante do sistema virou efeito colateral de uma busca por similaridade, e ninguém a versiona.

## O mapa das engenharias derivadas

Uma vez que se enxerga o tronco, os galhos se organizam sozinhos. Todos usam o mesmo método (observar comportamento, inferir a regra, testar a hipótese) e se distinguem apenas pelo alvo do desmonte.

**Prompt engineering** reverte o modelo: como ele responde a formato, ordem, papel, exemplo.

**Context engineering** reverte o modelo e o domínio ao mesmo tempo, e por isso é a mais difícil das duas.

**RAG** reverte o corpus. Chunking não é um parâmetro: é uma teoria sobre onde um sentido começa e termina naquele acervo. Cortar de 512 em 512 tokens é afirmar que o significado é uniformemente distribuído no texto, o que é falso em praticamente todo documento real, e catastrófico em contrato, laudo e norma, onde a exceção mora num parágrafo que só faz sentido colado ao anterior.

**Evals** revertem o critério. Escrever um bom eval é a operação mais desconfortável do processo, porque obriga alguém a declarar o que "certo" significa, e essa é justamente a coisa que nunca foi escrita. Metade do valor de uma suíte de avaliação aparece antes de rodar a primeira vez, na reunião em que o cliente descobre que os dois especialistas dele discordam sobre o resultado esperado.

**Fine-tuning** reverte a distribuição desejada: qual comportamento você quer que se torne default, inferido dos casos onde o default atual falha.

**Design de agente e tool use** revertem o procedimento. É o levantamento de requisitos clássico, com o mesmo abismo entre o processo oficial e o real, agora com um executor que não improvisa como um estagiário improvisaria.

**Red teaming** reverte as defesas.

**Interpretabilidade mecanicista** é o caso literal, sem metáfora nenhuma: decompilar a rede, procurar circuitos, nomear features. É a única dessas disciplinas que usa o nome certo desde o começo, e não por acaso é a mais rigorosa.

## Prompt injection é engenharia social, sem metáfora

Existe uma razão estrutural para que o ataque mais persistente contra LLMs seja um ataque social, e ela merece ser dita com todas as letras.

A engenharia social clássica é engenharia reversa de protocolos humanos. Kevin Mitnick quase nunca precisou quebrar criptografia: bastava desmontar o procedimento social em volta dela, a hierarquia, a pressa, o medo de parecer incompetente, o desejo genuíno de ajudar. Ele mapeava esse protocolo e escrevia um roteiro que o executava.

Um modelo de linguagem aprendeu os protocolos humanos a partir de texto humano. Herdou a competência e, junto, as vulnerabilidades: a deferência à autoridade declarada, a pressão da urgência, a maleabilidade do role-play, a disposição a ser útil mesmo quando não deveria. Por isso o repertório do Mitnick funciona contra uma máquina. Não é coincidência nem antropomorfismo: o alvo absorveu o mesmo protocolo que o ataque explora.

E há um agravante que é de arquitetura, não de comportamento. Para o modelo, não existe diferença ontológica entre instrução e dado. Tudo é token na mesma janela. A separação entre canal de controle e canal de dados, que a computação levou décadas para aprender a duras penas (é a lição do buffer overflow, do SQL injection, do XSS), foi desfeita de uma vez. Prompt injection é injeção de comando contra um parser que não foi escrito, foi treinado, e que por isso não pode ser corrigido com um `prepared statement`.

Quem constrói agente com acesso a ferramentas está construindo um sistema que executa ações a partir de texto não confiável, usando um interpretador cujo comportamento ninguém especificou. Enunciada assim, sem eufemismo, a frase deixa claro por que sanitização de entrada não resolve e por que a defesa real é de arquitetura: privilégio mínimo por ferramenta, confirmação humana no que é irreversível, e a suposição de trabalho de que todo conteúdo recuperado é hostil.

## A objeção que eu mesmo faria

A objeção séria é esta: engenharia reversa pressupõe que existe uma regra escondida a ser descoberta. Um modelo não tem regra, tem distribuição estatística. Chamar isso de engenharia reversa seria romantismo, um empréstimo de prestígio de uma disciplina exata para uma prática que é, no fundo, tentativa e erro sofisticada.

A objeção é parcialmente verdadeira, e o que ela revela é pior do que ela sugere.

Na engenharia reversa clássica existe um ponto final. Você desmonta o binário até chegar à lógica exata, e sabe que chegou. Aqui não há ponto final, porque há **regularidade sem regra**: o comportamento é estável o bastante para ser explorado e instável o bastante para nunca ser garantido. O que você obtém no fim do trabalho não é a especificação, é um modelo aproximado com prazo de validade, válido para aquela versão, aquela temperatura, aquela faixa de entradas.

Isso não desqualifica o método. Muda o que se deve guardar dele. Se o entendimento expira, então o ativo duradouro não pode ser o prompt: tem que ser o **eval**, que é a única coisa que sobrevive à troca de modelo. Prompt é hipótese. Eval é o experimento que a testa. Guardar a hipótese e jogar fora o experimento é o que produz aquela pasta de prompts mágicos que ninguém sabe mais por que funciona, e da qual ninguém tem coragem de remover uma linha.

A segunda objeção é mais velha e vale para o campo inteiro: engenharia reversa é a ferramenta do atacante. Defender a prática é defender também quem a usa contra você. É verdade, e é simétrica: o red teamer e o jailbreaker executam o mesmo procedimento, com a mesma competência. A diferença nunca esteve no método, está no que se faz com o mapa, e fingir o contrário é a ingenuidade profissional mais comum que conheço.

## O que isso muda no ofício

Se a atividade é engenharia reversa, então a disciplina da engenharia reversa se aplica, e ela é bem mais exigente que a do prompt.

**Trate o modelo como sistema sob teste, não como interlocutor.** Uma variável por vez, hipótese declarada antes da medição, contra-prova obrigatória. "Melhorou" não é resultado: é impressão. A conversa fluida com o modelo é a coisa que mais atrapalha aqui, porque ela simula compreensão e desestimula a medição.

**Versione o contexto como você versiona schema.** O que entra na janela merece diff, revisão e registro de decisão. Um ADR de contexto (o que sempre entra, o que nunca entra, com que prioridade em caso de conflito) é mais valioso que qualquer diagrama de arquitetura do sistema.

**Logue o contexto montado, não só a resposta.** Sem isso, depurar é impossível, porque você não tem o input real: tem o input que imagina ter enviado. É o equivalente a debugar um binário sem poder ver os argumentos da chamada.

**Trate chunking e ranking como decisões ontológicas.** Escreva por que o corte é ali. Escreva o que o retriever estruturalmente nunca vai trazer, que é a lista de perdas conhecidas do seu sistema. Perda documentada é engenharia; perda invisível é o que faz um sistema errar com confiança e ninguém saber por quê.

**Faça o eval primeiro.** Ele é a especificação que o domínio nunca escreveu, e é o único artefato que ainda vale alguma coisa depois do próximo upgrade de modelo.

**Construa para ser desmontado por terceiros.** Se o sistema decide algo que afeta uma pessoa, ela precisa poder perguntar com base em quê. Não é enfeite acadêmico: é engenharia reversa institucionalizada, oferecida pelo sistema em vez de arrancada dele. Um sistema que não sabe dizer com que contexto decidiu não é opaco por limitação técnica, é opaco por decisão de projeto.

## O que fica

Esses sistemas estão se instalando exatamente onde a decisão importa: entre a pessoa e o benefício, o crédito, o diagnóstico, a fila. E quem monta o contexto decide qual recorte de mundo a máquina enxerga antes de responder. É uma escolha sobre o que será considerado real na hora de decidir, e hoje ela está enterrada num top-k que ninguém revisou.

O modelo não vem com código-fonte. Não vai vir. A competência que separa engenharia de superstição, nesse cenário, é a mais antiga que temos: desmontar com método, registrar o que se descobriu, e admitir por escrito o que continua desconhecido.

---

*Este texto faz parte da reflexão sobre **engenharia transparente** na NTLabs: como construímos com IA, o que decidimos colocar no contexto e o que assumimos estar deixando de fora.*