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".

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 humana em tempo real durante a execução. A clarificação pré-execução – o agente trazendo à tona premissas e fazendo perguntas calibradas antes de produzir output – é permitida e, em maturidade mais alta, esperada. Veja Lab de IA § Os cinco estágios para o padrão operacional.

Camadas de trabalho obrigatórias

Todo fluxo de trabalho habilitado por IA deve definir as quatro camadas de entrada (1–4). A Camada 5 (Process Design) as estende com o pipeline operacional que consome as entradas; é obrigatória para trabalho de Tier 3 / Rung 5 e opcional abaixo disso.

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.

Para bases de código brownfield, a inversão é importante: o código já existe e as especificações precisam ser extraídas por engenharia reversa antes que o novo trabalho spec-first possa ser retomado. Veja a estratégia de engenharia brownfield para o fluxo de trabalho spec-from-code.

Camada 5 – Process Design

A camada operacional. Uma vez que uma spec funciona, a próxima pergunta é o pipeline que a executa. Process design é a disciplina de projetar fluxos de trabalho restritos e faseados dentro dos quais a IA opera de forma consistente – distinta da engenharia de prompts e da escrita de spec em si. É a camada que distingue o trabalho de Tier 3 / Rung 5 do trabalho de Tier 2 / Rung 4.

O vocabulário, extraído de Building Effective Agents da Anthropic:

Prompt chaining – etapas sequenciais de prompt único com validação intermediária
Routing – classificar a tarefa, despachar para o prompt ou fluxo de trabalho especializado apropriado
Parallelization – executar subtarefas independentes em paralelo, agregar resultados
Orchestrator-workers – um agente líder decompõe a tarefa e despacha workers
Evaluator-optimizer – um gerador emparelhado com um avaliador separado que pontua e itera
Autonomous agents – exploração aberta com uso de ferramentas e loops de feedback

Regra de decisão: comece com prompt único; adicione fluxo de trabalho quando necessário; adicione multi-agente apenas quando o valor por tarefa justificar o prêmio de tokens (agentes típicos usam ~4× os tokens do chat; multi-agente ~15×, segundo Anthropic, 2025). Não recorra a multi-agente porque soa sofisticado.

Antipadrões:

Pitfall: Mega-prompt único
Combina modos de falha; impossível de depurar.
Pitfall: Multi-agente por si só
Caro, frágil, frequentemente um único agente faz tão bem.
Pitfall: Context dumping
Mais contexto é frequentemente pior contexto.
Pitfall: Pular avaliações
Sem avaliações, sistemas de IA degradam silenciosamente.
Pitfall: Otimizar prompts quando o problema é o contexto
Atribuição errada do modo de falha.

As quatro camadas de entrada (Prompt → Contexto → Intenção → Spec) descrevem o que o humano prepara antes da delegação. A Camada 5 descreve o pipeline que consome essas entradas. No T3/R5 o pipeline também é um artefato projetado – e os portões de validação dentro dele são graduados por risco (HITL / HOTL / HOOTL).

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.

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.

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
Output danoso	Problema de permissão / raio de impacto – o agente não deveria ter podido tomar essa ação
Output não percebido	Problema de portão de validação – a postura de supervisão errada para o raio de impacto desta ação (veja portões graduados por risco)
Direção errada defendida com confiança	Clarificação pulada – o agente se comprometeu antes que as premissas fossem trazidas à tona

As equipes devem corrigir a camada responsável, não repetir os prompts.

Funções organizacionais

Cada sistema de IA em produção deve ter:

Dono da Spec – responsável pela qualidade da especificação, critérios de aceitação e o que significa "pronto"
Dono do Contexto – responsável pelos arquivos de contexto (CLAUDE.md / AGENTS.md), frescor do contexto e escopo de ferramentas/skills
Dono da Avaliação – responsável pela suíte de avaliações, detecção de regressões e métricas de qualidade
Responsável por permissões (Permissions Owner) – responsável pelo que cada agente pode e não pode fazer, e pelo nível de portão de validação (HITL / HOTL / HOOTL) por classe de ação

Uma pessoa pode exercer múltiplas funções inicialmente. O papel de Responsável por permissões se torna essencial assim que os agentes tocam sistemas de produção com efeitos colaterais irreversíveis.

Esses quatro papéis governam um sistema de IA em produção. Eles são distintos dos três papéis necessários para governar a transformação em IA de uma equipe – veja Liderar a transformação § Funções organizacionais.

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

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