Padrões de Execução de IA
As regras e expectativas para delegar trabalho à IA em toda a organização.
Política de Expectativas Organizacionais
O princípio operacional por trás desses padrões é a Regra de Tradução Universal: substituir "o humano produz o artefato" por "o humano define a spec → o sistema produz o artefato".
1. Princípio central
A IA é tratada como um trabalhador autônomo, não como um chatbot.
Todo trabalho atribuído à IA deve ser executável sem supervisão em tempo real.
2. Camadas de trabalho obrigatórias
Todo fluxo de trabalho habilitado por IA deve definir todas as quatro camadas.
Camada 1 – Criação de prompts (habilidade básica)
Os colaboradores devem:
- escrever instruções claras
- especificar o formato
- incluir exemplos quando útil
- resolver ambiguidades antecipadamente
Barra mínima: o output de IA deve exigir ≤20% de correção.
Camada 2 – Engenharia de contexto
Cada equipe deve manter um arquivo de contexto estruturado contendo:
- objetivos
- restrições
- terminologia
- padrões de qualidade
- documentos relevantes
- regras de acesso a ferramentas
Requisito: as tarefas de IA devem carregar esse contexto antes da execução.
Camada 3 – Engenharia de intenção
Todo fluxo de trabalho deve definir:
- hierarquia de objetivos
- regras de trade-off
- condições de escalada
- o que a IA pode decidir versus o que deve escalar
Nenhum agente pode ser executado sem intenção definida.
Camada 4 – Engenharia de especificação (padrão mais elevado)
Todas as tarefas não triviais devem ter uma especificação escrita.
Componentes obrigatórios da spec:
- declaração do problema
- escopo
- entradas
- restrições
- critérios de aceitação
- condições de falha
- testes de sucesso
- definição de conclusão
Regra: se o sucesso não puder ser verificado objetivamente, a tarefa não está pronta para ser especificada.
3. Primitivos de especificação (habilidades aprendíveis)
A engenharia de especificação é construída a partir de cinco primitivos. Cada um é uma habilidade distinta para praticar. Para exemplos, templates e specs elaboradas para diferentes funções, veja o Guia de Especificação.
Primitivo 1 – Declarações de problema auto-suficientes
Declare o problema com contexto suficiente para que a tarefa seja solucionável sem que o agente busque mais informações. Exponha as premissas ocultas. Articule as restrições que você normalmente deixa implícitas.
Exercício de treinamento: pegue uma solicitação que você normalmente faria de forma conversacional e reescreva como se o destinatário nunca tivesse visto seu projeto, não conhecesse sua terminologia e tivesse acesso apenas ao que você incluiu.
Primitivo 2 – Critérios de aceitação
Defina como é o "pronto" de forma que um observador independente possa verificar o output sem fazer perguntas. Se você não consegue escrever três frases que verifiquem a conclusão, você não entendeu a tarefa suficientemente bem para delegá-la.
Primitivo 3 – Arquitetura de restrições
Defina quatro categorias para cada tarefa:
- Deve – requisitos inegociáveis
- Não deve – ações ou outputs proibidos
- Prefira – orientação quando múltiplas abordagens válidas existem
- Escale – condições em que o agente deve parar e perguntar
Primitivo 4 – Decomposição
Divida as tarefas em componentes que possam ser executados independentemente, testados independentemente e integrados de forma previsível. Granularidade alvo: subtarefas de ≤2 horas com limites claros de entrada/saída, cada uma verificável por conta própria.
Primitivo 5 – Design de avaliação
Para cada tarefa de IA recorrente, construa 3-5 casos de teste com outputs conhecidos e bons. Execute-os após atualizações de modelo para detectar regressões. Os outputs são julgados por métricas, não por aparência.
Uma spec válida deve passar em todos os cinco: auto-suficiente, testável, com restrições, decomponível, avaliável.
4. Checklist de prontidão para delegação
Antes de atribuir trabalho à IA, os colaboradores devem confirmar:
- Entendo completamente a tarefa
- Posso definir o sucesso objetivamente
- Posso listar os casos de falha
- Posso descrever as restrições
- Posso verificar os resultados sem interpretação
Se qualquer resposta = não → não delegue ainda.
5. Modelo de responsabilidade por falha
A falha é atribuída por camada:
| Tipo de falha | Causa raiz |
|---|---|
| Output ruim | Problema de prompt |
| Output irrelevante | Problema de contexto |
| Direção errada | Problema de intenção |
| Output incompleto | Problema de spec |
As equipes devem corrigir a camada responsável, não repetir os prompts.
6. Funções organizacionais
Cada sistema de IA em produção deve ter:
- Dono da Spec
- Dono do Contexto
- Dono da Avaliação
Uma pessoa pode exercer múltiplas funções inicialmente.
7. Padrão de documentação
Todos os documentos internos devem ser escritos como se um agente fosse executá-los.
Os documentos devem:
- declarar premissas
- definir termos
- especificar resultados
- incluir restrições
- evitar conhecimento implícito
8. Regra do resumo executivo
O pensamento claro precede a execução de IA.
Se você não consegue especificá-lo, não consegue automatizá-lo.
← Voltar para o início · O framework de referência · O Lab de IA · Glossário