1. O que você vai aprender
Conectar os playbooks em uma rotina leve de entrega. Você terá um caminho de aprovação proporcional ao risco, com versão, confirmação de resultado e regra de retorno à versão anterior.
2. Conceito em 1 minuto
Produção é o uso real em um processo, não apenas uma demonstração. Um prompt pode funcionar no laboratório e falhar com dados, ferramentas ou usuários diferentes. Por isso, a entrega inclui teste, responsável e acompanhamento.
Em agentes, avaliar o resultado exige observar o ambiente, não confiar apenas na mensagem final do modelo. [S13]
3. Por que isso importa
“O agente disse que fez” não significa que fez. Uma resposta pode estar correta e a gravação no sistema falhar. O processo profissional diferencia qualidade do texto, sucesso da ferramenta e valor para a pessoa.
4. Quando usar
Use quando o prompt entrar em rotina compartilhada, integração ou atendimento. Aplique uma versão mínima para tarefas de baixo risco e acrescente controles à medida que o impacto aumentar.
5. Quando NÃO usar
Não transforme uma revisão de e-mail em projeto de governança. Também não pule validações essenciais porque o piloto parece bom. Velocidade e cuidado não são opostos: limite o escopo e confirme o que importa.
6. Estrutura da técnica
ENTREGAR: Definir → Testar → Medir → Corrigir → Versionar → Acompanhar.
Objetivo e dados
↓
Prompt baseline + critério de aceite
↓
Casos de teste → respostas preservadas
↓
Avaliação → falhas → variante
↓
Confirmação em casos novos
↓
Uso limitado + revisão apropriada
↓
Monitoramento → correção ou retorno à versão anterior
Mínimo para baixo risco: tarefa clara, cinco a dez casos iniciais, revisão humana, arquivo com versão e registro de falhas. A quantidade é ponto de partida de aprendizado, não garantia de confiabilidade.
Quando houver ação externa: acrescente permissões restritas, validação de entrada/saída, confirmação da execução e proteção contra duplicação. Idempotência significa poder repetir a solicitação sem executar duas vezes o mesmo efeito, quando o sistema foi projetado para isso.
Rollback é retornar a uma configuração anterior. Reverter um prompt não desfaz automaticamente mensagens enviadas ou dinheiro movimentado. Por isso, prevenir efeitos indevidos é diferente de apenas guardar versões.
7. Exemplo ruim
O teste deu certo uma vez. Agora automatize tudo e não peça ajuda.
O pedido transforma uma demonstração em autorização irrestrita, sem provar o caminho operacional.
8. Exemplo melhorado
Use a versão aprovada somente no escopo testado.
Registre entrada, versão, resultado e falha, sem dados sensíveis desnecessários.
Encaminhe casos fora do escopo e ações que exigem autorização.
Se ocorrer falha crítica, interrompa o efeito externo e aplique o plano de retorno.
A autonomia passa a depender do contrato e do risco.
9. Exemplo profissional
Cenário fictício de tickets. Primeiro, a IA classifica e uma pessoa confirma. Depois, um piloto em modo sombra produz classificações sem alterar a fila. As diferenças são revisadas. Em seguida, somente categorias de baixo risco podem ser encaminhadas automaticamente, se os testes e o responsável aprovarem.
Casos de segurança continuam com tratamento prioritário e revisão. O registro inclui versão do prompt, política, modelo, rubrica, horário e confirmação da ferramenta. Um retorno inválido não vira encaminhamento silencioso.
Modo sombra é executar a lógica sem deixar a saída afetar a operação real. Ele permite comparar com o processo atual, mas não mede todos os efeitos de uma automação ativa.
10. Template reutilizável
Aplicação: [OBJETIVO]
Contexto, usuários e sistemas: [CONTEXTO]
Prompt, dados e evidências de teste: [DADOS]
Limites operacionais e ações proibidas: [RESTRIÇÕES]
Critérios de promoção, acompanhamento e interrupção: [CRITÉRIOS]
Crie um plano em [FORMATO_DE_SAÍDA] com:
versão, escopo, responsáveis, teste final, piloto, validação,
registro mínimo, revisão de falhas e retorno à versão anterior.
Distinga “texto correto”, “ação confirmada” e “resultado de negócio”.
Não declare produção validada sem evidência de execução real.
11. Exercício para o aluno
Escreva um critério de pronto para um prompt de ata. Gabarito: preservar decisões, não inventar responsáveis e passar na revisão de casos definidos; “parece profissional” não basta.
12. Exercício intermediário
Planeje um piloto de uma semana de uso manual de um prompt de relatório. Aceite: escopo, dono, casos, tempo de revisão e registro de erros; nenhum envio automático durante o teste sem aprovação.
13. Desafio profissional
Desenhe o lançamento gradual de uma triagem conectada a CRM. Aceite: dataset de confirmação, revisão de casos críticos, confirmação da escrita, proteção contra duplicação, métricas por segmento e regra objetiva para interromper a automação.
14. Checklist
- O escopo aprovado é explícito.
- Prompt, modelo, política e rubrica têm identificação.
- Os critérios de aceite foram testados.
- Casos novos confirmaram a candidata.
- Há responsável por falhas e exceções.
- Ações externas têm confirmação e controle.
- Registros respeitam minimização e acesso.
- Existe regra de interrupção e retorno.
15. Erros comuns
Confundir código pronto com processo validado; monitorar só custo; não guardar versão; usar dados de cliente sem necessidade; deixar um agente aprovar a própria ação sensível; acreditar que rollback apaga efeitos externos; criar controles pesados para tarefas triviais e nenhum para tarefas críticas.
16. Antes e depois
PROMPT INICIAL: “Teste e coloque em produção.”
→ PROMPT OTIMIZADO: “Confirme os critérios no escopo definido, rode um piloto limitado, verifique o resultado no sistema e acompanhe falhas com uma versão recuperável.”
→ MOTIVO DA MELHORIA: fecha a distância entre demonstrar, operar e gerar valor.
17. Resumo de bolso
Um prompt pronto tem evidência de uso, limite conhecido e alguém responsável.