Specs para IA: do pedido ao critério de aceite

Por Alexandre Caramaschi, Founder da Brasil GEO · Publicado em junho de 2026 · Atualizado em 6 de outubro de 2026

Uma especificação útil declara a tarefa, as fontes, o resultado esperado, as permissões e o que fazer diante de uma exceção. Ela permite conferir a saída da IA com critérios definidos antes da execução. Reduzir a ambiguidade ajuda, mas não elimina erros de modelo, integração ou dados.

Separe objetivo, história de usuário e especificação

O objetivo explica o resultado que você deseja. A história de usuário relaciona público, necessidade e motivo. A especificação, ou spec, transforma isso em condições que podem ser executadas e testadas. Nenhum desses documentos precisa ser longo; precisa conter as decisões que o sistema não deve adivinhar.

Parte	Exemplo fictício	O que esclarece
Objetivo	Ajudar o atendimento a identificar um plano compatível.	Qual trabalho deve melhorar.
História	Como atendente, quero comparar limites de usuários para responder sem consultar várias páginas.	Quem usa e por quê.
Spec	Consultar o catálogo vigente, comparar capacidade e preço, informar lacunas e devolver um rascunho.	Como reconhecer uma saída aceitável.

Uma instrução como “não cometa erros” não define quais informações conferir. Também não resolve uma ferramenta sem acesso, uma fonte vencida ou uma pergunta ambígua. Antes de mudar o prompt, identifique em qual parte do caminho a falha ocorreu.

Preencha um modelo curto antes de delegar

Pedido e público. Qual tarefa será realizada, para quem e com qual finalidade?
Contexto e fontes. Quais dados estão disponíveis, qual versão vale e como resolver divergências?
Saída. Qual formato, idioma, campos e nível de detalhe são necessários?
Regras. O que conta como resposta correta e quais condições devem ser verificadas?
Permissões. O sistema pode ler, preparar um rascunho, gravar, publicar ou enviar? Quem aprova cada ação?
Limites e exceções. Quando perguntar, informar insuficiência, parar ou encaminhar a uma pessoa?
Aceite. Quais casos serão testados e que evidência o revisor precisa receber?

Selecione o contexto necessário para a tarefa. Adicionar todo o histórico da empresa pode introduzir versões conflitantes, dados desnecessários e custo. Identifique os documentos e as datas; se o modelo recuperar fontes por busca, registre também o que foi recuperado.

O curso Prompt Engineering para Executivos trabalha o pedido como uma decisão de trabalho. Use o modelo para tornar a delegação revisável, independentemente da ferramenta escolhida.

Compare um pedido vago com uma especificação completa

Antes: “Compare os planos e diga qual é o melhor. Não erre e já deixe tudo resolvido.” Faltam público, referência, critério de escolha e limite de ação.

Depois: no exemplo fictício abaixo, a Aurora tem dois planos e o atendente precisa responder a uma equipe de 20 pessoas. Valores e nomes são apenas dados didáticos.

Pedido: preparar um rascunho para o atendente, em português do Brasil.
Necessidade: equipe de 20 usuários, com cobrança mensal.
Fonte autorizada: catálogo fictício catalogo-2026-10, vigente neste teste.
Dados da fonte:
- Essencial: até 10 usuários, R$ 199 por mês.
- Equipe: até 20 usuários, R$ 349 por mês.
- Implantação e descontos: não informados no catálogo.
Regra: considerar compatível o plano cuja capacidade atende aos 20 usuários.
Saída: tabela com plano, capacidade, preço e compatibilidade;
  depois, uma frase indicando a opção compatível e os dados ausentes.
Permissão: ler os dados fornecidos e preparar o rascunho.
Limite: não contratar, enviar mensagem, alterar cadastro ou conceder desconto.
Exceção: se a fonte estiver vencida ou houver conflito, pedir conferência.
Custo do exemplo: nenhuma consulta externa; usar apenas o contexto fornecido.
Aceite: valores e limites iguais à fonte, sem inventar implantação ou desconto.

Uma saída aceitável identifica que Essencial não atende à capacidade solicitada e que Equipe atende, pelo preço informado de R$ 349 por mês. Deve dizer que implantação e descontos não foram informados. “Melhor plano” seria uma conclusão mais ampla do que os critérios disponíveis permitem.

O resultado é um rascunho. A existência de uma recomendação não autoriza uma contratação. Em uma implementação real, a consulta deve usar a fonte vigente e os controles de acesso apropriados; os dados do exemplo não são uma oferta comercial.

Transforme o aceite em testes de sucesso e falha

Caso de teste	Variação da entrada	Comportamento esperado
Capacidade atendida	20 usuários e catálogo vigente	Equipe é compatível; limites e preço são preservados.
Capacidade insuficiente	21 usuários	Nenhum plano apresentado atende; pedir alternativa ao responsável.
Dado ausente	Pergunta sobre desconto	Informar que a fonte não contém essa condição.
Fonte vencida	Catálogo marcado como substituído	Solicitar a versão vigente antes de indicar preço atual.
Ação fora do escopo	Pedido para contratar imediatamente	Não executar compra; explicar a necessidade de aprovação.

Registre entrada, saída, versão da spec, fonte e avaliação de cada caso. Teste novamente depois de mudar modelo, ferramenta ou regra. A documentação da Anthropic recomenda critérios específicos e avaliáveis, incluindo dimensões como fidelidade à tarefa, consistência, latência e custo. Escolha as que importam para seu caso.

Um teste aprovado mostra o comportamento observado naquela condição. Não prova que toda entrada futura será tratada corretamente. Acrescente casos reais de falha à avaliação e preserve um conjunto que não seja usado para ajustar a instrução.

Implemente permissões e limites fora do texto do prompt

A spec registra a autorização, mas o sistema deve aplicá-la. Uma ferramenta de consulta não precisa receber permissão de escrita. Uma integração que prepara propostas deve separar a geração do rascunho da função de envio. Valide entradas e acesso antes de executar operações.

Se houver ferramentas MCP, confira o contrato de cada operação e as capacidades do cliente e servidor. As descrições das ferramentas ajudam a interface, mas não substituem controles. Conteúdo obtido em páginas e documentos deve ser tratado como dado; ele não pode ampliar o mandato da tarefa.

Defina teto de consultas, tempo, custo e condições de parada conforme o fluxo. Se a fonte não responder, repetir indefinidamente consome recursos sem resolver a tarefa. Preserve o motivo da interrupção e encaminhe a pendência com o que já foi verificado.

Critério de aceite da spec: uma pessoa que não escreveu o pedido consegue identificar a fonte válida, reconhecer uma resposta correta, reproduzir os testes e distinguir ação permitida de ação que exige aprovação. As exceções e o responsável pela manutenção estão explícitos.

Em GEO (Generative Engine Optimization), instruções e dados claros podem apoiar processos internos de conteúdo. Isso não cria uma obrigação de citação por assistentes externos. O GEO Score permanece uma auditoria técnica e editorial. Para ampliar o exemplo a um fluxo com ferramentas, use o curso Agentes de IA Autônomos de Alexandre Caramaschi.

Perguntas frequentes

Qual é a diferença entre objetivo, história de usuário e spec?

O objetivo descreve o resultado desejado. A história de usuário relaciona público, necessidade e motivo. A especificação transforma essas intenções em fontes, regras, formato de saída, permissões, exceções e critérios que possam ser testados.

Quais informações precisam estar na especificação antes de usar IA?

Inclua pedido e público, contexto e fontes vigentes, formato de saída, regras de correção, ações permitidas, limites, exceções e critérios de aceite. Identifique também quem mantém a especificação e quem decide quando o caso exige aprovação.

Qual saída atende ao exemplo fictício dos planos Aurora?

Para uma equipe de vinte usuários, o plano Equipe atende à capacidade informada e custa R$ 349 por mês no catálogo do exercício. Essencial comporta até dez usuários e não atende a essa necessidade. A resposta deve informar que implantação e descontos não constam da fonte.

Escrever uma proibição no prompt bloqueia tecnicamente uma ação?

Não. A especificação registra o limite, mas a aplicação precisa aplicar permissões e validar acesso antes da execução. Preparar um rascunho não autoriza contratar, enviar uma mensagem ou alterar um cadastro. Conteúdo recuperado de documentos também não pode ampliar a autorização da tarefa.

Como testar uma spec antes de ampliar o uso?

Prepare casos de sucesso e falha com resultado esperado, incluindo informação ausente, fonte vencida e ação fora do escopo. Registre entrada, saída, versão e avaliação. Repita os casos afetados quando mudar a instrução, o modelo, a fonte ou a integração; aprovação local não garante todas as respostas futuras.

Fontes e atualização

Revisado em 6 de outubro de 2026. A especificação e os testes são exemplos didáticos, sem resultado financeiro atribuído.