Prompt engineering corporativo: o que muda quando o agente vai para produção
Prompt que funciona em demo morre em produção. Padrões testados em agentes Gemini Enterprise reais — estrutura, guardrails, few-shot, tratamento de incerteza e versionamento.
Fabiano Brito
CEO & Founder
"Prompt engineering" virou meme em 2024 — "qualquer um faz". Em produção corporativa, é o que separa agente confiável de agente vergonhoso. Este post traz os padrões que aplicamos em todos os projetos Autenticare.
Estrutura de prompt corporativo — os 7 blocos
Todo prompt em produção tem 7 blocos, nessa ordem:
Quem o agente é e qual o seu escopo. Sem isso ele assume "assistente geral".
Tom, valores, restrições de marca. É onde "nós" vira voz.
O que o agente pode e, principalmente, o que não pode fazer.
Como reagir quando não sabe. O bloco mais subestimado do prompt corporativo.
Estrutura JSON ou texto, citações obrigatórias, limites de tamanho.
2–5 exemplos do bom comportamento, incluindo 1 de "não sei".
Lista clara com quando usar cada tool e o schema esperado.
Sem qualquer um desses blocos, comportamento degrada em casos não-óbvios.
O bloco mais subestimado: regras de incerteza
O default do LLM é parecer confiante mesmo quando não sabe. Em produção, isso é alucinação maquiada. Sempre incluir literalmente:
"Se a informação necessária não estiver no contexto recuperado, responda 'não encontrei essa informação na base disponível' — não invente, não generalize de conhecimento próprio. Se a pergunta for ambígua, peça esclarecimento antes de responder."
Nos casos em que o agente tem certeza, ele responde. Nos que não tem, escala para humano. Reduz drasticamente alucinação. Mais em avaliação de agentes em produção.
Few-shot: como escolher exemplos
Few-shot mal escolhido enviesa pior que sem exemplos. Critérios:
- Diversidade: cobrir os 3–5 padrões mais comuns, não 5 variações do mesmo.
- Casos de borda: incluir 1 exemplo de "não tenho informação" e 1 de "preciso de esclarecimento".
- Formato espelhado: cada exemplo no exato formato esperado da resposta.
- Curado por humano: nunca usar saídas de LLM como few-shot — vira eco de viés.
Padrões que funcionam × anti-padrões
| Padrão recomendado | Anti-padrão a evitar |
|---|---|
| Restrição positiva ("responda em até 3 parágrafos") | Restrição negativa ("não responda muito longo") |
| Estrutura explícita ("Use títulos: Resumo / Contexto / Recomendação") | "Seja claro e organizado" |
| Citação obrigatória ([doc:página] ao final de cada afirmação) | "Inclua fontes quando possível" |
| Mascaramento explícito de PII (CPF → ***.***.***-12) | "Evite dados sensíveis" |
| Self-check antes de responder | Resposta direta sem revisão |
Datas em ISO 8601 (2026-04-20) |
"Esta semana", "mês passado" |
| PT-BR explícito ("vocabulário brasileiro, evite PT-PT") | Deixar o modelo escolher variante |
Versionamento: prompt é código
Prompt em produção é código. Tratamento mínimo:
- Repositório git dedicado, com PR e review.
- Cada versão tem hash + autor + data + motivação.
- A/B test antes de promover para 100%.
- Avaliação automatizada contra gold set a cada PR.
- Rollback em um comando.
Sem isso, "alguém mexeu no prompt" vira pesadelo de produção.
Modelo: Pro vs Flash no mesmo agente
Padrão eficiente em produção:
- Gemini 2.5 Flash: classificação, roteamento, tarefas curtas, validação de schema.
- Gemini 2.5 Pro: raciocínio complexo, geração principal, multimodal pesado.
Custo cai 60–80% sem perda de qualidade percebida — o usuário recebe Flash para os 70% triviais e Pro para os 30% que importam.
Guardrails além do prompt
Prompt sozinho não basta. Combine com:
- Input validation: limite de tamanho, sanitização de comandos.
- Output filter: regex/classificador para PII, conteúdo proibido.
- Tool authorization: cada tool tem ACL própria.
- Rate limit: por usuário e por agente.
- Confidence threshold: abaixo de X, escala para humano.
Seu agente em produção está com prompt versionado?
Fazemos auditoria do prompt atual, reestruturamos nos 7 blocos, adicionamos guardrails e configuramos gold set. Entrega em 2 semanas.