JúpiterTech
Tutoriais de IA

Como criar critérios de aceite de entregável com ChatGPT

Use o ChatGPT para transformar um briefing em critérios de aceite observáveis, localizar lacunas e revisar um entregável antes da aprovação final.

Júpiter Tech 14 min de leitura

“Está pronto” pode esconder duas definições diferentes

Uma equipe pede uma página de inscrição para um evento. O fornecedor entrega o link, o formulário abre e o trabalho parece concluído. Na revisão aparecem perguntas que deveriam ter sido respondidas antes: quais campos são obrigatórios, para onde os dados seguem, o que acontece depois do envio e qual texto legal precisa aparecer?

O ChatGPT pode ajudar a transformar briefing, restrições e resultado esperado em critérios observáveis. Também pode inventar padrão visual, meta de conversão, integração ou obrigação que ninguém aprovou.

Este tutorial usa uma entrega inteiramente sintética e uma conversa comum no ChatGPT. O caminho principal depende apenas de texto colado. O gabarito foi conferido contra o briefing publicado abaixo. A Júpiter não executou benchmark entre modelos, planos ou interfaces.

O resultado será um pacote de revisão. Ele não aprova o entregável, não publica a página, não altera sistemas e não substitui validação jurídica, técnica ou de negócio.

O que você vai produzir

Ao final, você terá:

  1. inventário de requisitos e restrições;
  2. lista de lacunas que impedem critérios completos;
  3. critérios de aceite observáveis;
  4. casos de teste com evidência esperada;
  5. separação entre bloqueio, correção e melhoria;
  6. matriz ligando cada critério ao trecho de origem;
  7. roteiro de revisão humana;
  8. parecer em estado RASCUNHO PARA REVISÃO.

O artigo sobre como criar casos de teste de processo com ChatGPT começa com regras operacionais e testa o comportamento de um processo. Aqui, a entrada é um briefing de entrega. A pergunta é se o artefato recebido cumpre o que foi combinado, sem ampliar o acordo durante a revisão.

A página sobre critérios de aceite para agentes de IA governa a liberação de um sistema de agentes. Este exercício ensina uma pessoa a preparar critérios para um entregável empresarial delimitado.

Ferramenta, acesso e cuidados com dados

Use o ChatGPT pela web numa conversa nova. Cole somente o cenário sintético deste artigo.

A documentação oficial da OpenAI descreve o ChatGPT como ferramenta para seguir instruções, resumir, reescrever e trabalhar com texto. As orientações de prompting recomendam contexto, pedido específico e formato desejado. Essas capacidades bastam para o método documental.

Antes de usar material real:

  • confirme a conta e o workspace autorizados;
  • remova dados pessoais e segredos sem função na revisão;
  • preserve o briefing e a entrega originais no sistema oficial;
  • identifique versão, data e responsáveis;
  • confirme quem possui autoridade de aceite;
  • trate contrato, marca, segurança e privacidade com os especialistas adequados;
  • não conecte publicação, pagamento ou aprovação automática;
  • confira os controles de dados aplicáveis à conta.

Planos, limites, retenção e controles podem variar. Conteúdo empresarial só deve entrar num ambiente aprovado pela empresa.

Briefing sintético do exercício

A Empresa Horizonte realizará o evento fictício “Operação 2027” e contratou uma página simples de inscrição.

Copie o briefing:

ENTREGÁVEL: página de inscrição do evento Operação 2027
VERSÃO DO BRIEFING: 1.4
ESTADO: aprovado para produção do rascunho; publicação ainda proibida

OBJETIVO
Receber pedidos de inscrição para análise da equipe de eventos.
A inscrição enviada não confirma vaga.

PÚBLICO
Gestores de operações de empresas brasileiras.

CONTEÚDO OBRIGATÓRIO
R1. Nome do evento: Operação 2027.
R2. Data: 18 de março de 2027.
R3. Local: Vitória, ES. O endereço exato ainda está A DEFINIR.
R4. Texto: “Envie seus dados para solicitar uma vaga. A equipe responderá após a análise.”
R5. Aviso visível: “O envio do formulário não confirma a participação.”
R6. Botão: “Solicitar inscrição”.

FORMULÁRIO
R7. Campos obrigatórios: nome, e-mail corporativo, empresa e cargo.
R8. Campo opcional: telefone.
R9. Campo obrigatório de aceite da política de privacidade.
R10. O link final da política de privacidade está A DEFINIR.
R11. Depois do envio válido, mostrar: “Recebemos sua solicitação. A equipe responderá pelo e-mail informado.”
R12. Depois do envio inválido, identificar os campos que precisam de correção sem apagar os demais valores.

DESTINO DOS DADOS
R13. O formulário deve registrar a solicitação na lista EVENTO-2027-INSCRICOES.
R14. Nenhum e-mail automático será enviado ao participante nesta versão.
R15. Nenhuma tarefa comercial será criada nesta versão.

VISUAL E ACESSIBILIDADE
R16. Usar logotipo fornecido pela empresa e contraste legível.
R17. Todos os campos precisam de rótulo visível.
R18. A página deve permitir navegação por teclado.
R19. O briefing não define fonte, tamanhos, imagens, animações ou layout final.

PLATAFORMAS
R20. Revisar em desktop e celular.
R21. Navegadores mínimos ainda estão A DEFINIR.

PROIBIÇÕES
- não publicar;
- não usar dados reais no teste;
- não prometer vaga;
- não inventar endereço;
- não inserir contagem regressiva;
- não enviar e-mail automático;
- não criar tarefa no CRM;
- não tratar preferência visual como requisito aprovado.

O briefing contém requisitos verificáveis, lacunas e proibições. Um bom pacote de aceite preserva as três classes.

Passo 1: fixe o contrato da conversa

Envie:

Vou fornecer um briefing sintético de entregável.

Prepare critérios de aceite em estado RASCUNHO PARA REVISÃO.
Use somente o conteúdo fornecido.
Não invente requisito, padrão, meta, integração, responsável ou aprovação.
Quando faltar informação, use exatamente A DEFINIR.
Separe requisito obrigatório, restrição, lacuna e sugestão.
Não aprove, publique ou execute ação externa.
Aguarde o briefing.

Depois, cole o briefing completo.

A instrução protege uma fronteira importante. Critério de aceite confirma o acordo. Uma sugestão pode melhorar o trabalho, mas não deve reprovar o fornecedor quando nunca fez parte do briefing.

Passo 2: extraia o acordo antes de escrever testes

Peça:

Extraia o briefing numa tabela com:
- ID;
- trecho literal;
- tipo: requisito, restrição, lacuna ou contexto;
- objeto observado;
- condição esperada;
- evidência necessária;
- autoridade que precisaria confirmar;
- estado: verificável agora ou A DEFINIR.

Não crie critérios adicionais.
Não converta preferência comum de mercado em obrigação.

A tabela precisa preservar R1 a R21 e as oito proibições. Itens A DEFINIR continuam como lacunas:

  • endereço exato;
  • link final da política de privacidade;
  • navegadores mínimos;
  • escolhas visuais não definidas.

O modelo pode apontar outras perguntas. Mantenha-as como perguntas, sem fingir que o briefing já contém a resposta.

Passo 3: classifique o que pode bloquear o aceite

Use:

Classifique cada item em uma destas categorias:
1. BLOQUEIO DE ACEITE: requisito obrigatório descumprido ou ação proibida executada;
2. CORREÇÃO NECESSÁRIA: requisito verificável com defeito corrigível;
3. PENDÊNCIA DO BRIEFING: decisão A DEFINIR que impede teste conclusivo;
4. MELHORIA OPCIONAL: sugestão sem origem no briefing;
5. FORA DO ESCOPO DESTA VERSÃO.

Cite o ID e o trecho de origem.
Não use opinião estética como bloqueio.

Exemplos esperados:

  • prometer vaga é bloqueio;
  • apagar os campos depois de erro é correção necessária;
  • testar o link final de privacidade permanece pendente enquanto a URL estiver A DEFINIR;
  • sugerir animação entra como melhoria opcional;
  • criar tarefa no CRM fica fora do escopo e também viola uma proibição explícita.

Passo 4: transforme requisitos em critérios observáveis

Peça:

Crie um critério de aceite por comportamento observável.

Use o formato:
- critério_id;
- requisito_origem;
- condição inicial;
- ação de teste;
- resultado esperado;
- evidência a registrar;
- severidade se falhar;
- estado quando depender de A DEFINIR.

Evite palavras vagas como bonito, moderno, intuitivo, rápido ou profissional.
Não invente número, navegador, resolução, prazo ou meta.

Critérios úteis descrevem o que uma pessoa consegue observar.

Fraco:

A página deve ter boa experiência.

Verificável:

CA-12
Origem: R12
Condição: formulário preenchido, com e-mail em formato inválido
Ação: tentar enviar
Esperado: indicar o campo de e-mail e preservar nome, empresa, cargo e telefone já preenchidos
Evidência: captura do erro e dos valores preservados
Se falhar: correção necessária

O critério não avalia toda a experiência. Ele testa um comportamento acordado.

Passo 5: crie os testes do formulário

Envie:

Prepare testes para o formulário usando dados sintéticos.
Inclua:
- envio válido;
- ausência de cada campo obrigatório;
- telefone vazio;
- aceite de privacidade desmarcado;
- e-mail em formato inválido;
- correção depois de erro;
- preservação dos campos preenchidos;
- mensagem de sucesso;
- ausência de confirmação de vaga;
- ausência de e-mail automático;
- ausência de tarefa comercial.

Para cada teste, informe entrada, passos, resultado e evidência.
Não use dados reais.

Use estes dados fictícios:

nome: Marina Teste
email: marina.teste@empresa-exemplo.com
empresa: Empresa Exemplo Ltda.
cargo: Gerente de Operações
telefone: (27) 99999-0000
aceite_privacidade: marcado

Para o teste inválido, troque o e-mail por marina.teste@.

O envio válido deve produzir a mensagem de recebimento e um registro na lista EVENTO-2027-INSCRICOES. Ele não deve enviar e-mail, criar tarefa comercial ou apresentar linguagem de vaga confirmada.

Passo 6: trate as lacunas sem completar o briefing

Peça:

Liste todas as lacunas que impedem um aceite conclusivo.
Para cada uma, informe:
- trecho de origem;
- teste afetado;
- risco de presumir resposta;
- pessoa ou função que precisa decidir;
- pergunta objetiva;
- estado temporário do critério.

Não proponha a decisão como se estivesse aprovada.

Resultado esperado:

Endereço

A página pode mostrar somente Vitória, ES. Inserir rua, espaço ou hotel específico inventaria informação.

Política de privacidade

É possível testar presença e obrigatoriedade do campo. O destino do link continua pendente até a empresa fornecer a URL aprovada.

Desktop e celular estão no briefing. A lista de navegadores e versões permanece aberta. O teste não pode transformar preferência da equipe em requisito retroativo.

Visual

Logotipo, contraste e rótulos visíveis são verificáveis. Fonte, imagens, animações e layout não possuem padrão aprovado neste documento.

Passo 7: monte a matriz de rastreabilidade

Use:

Crie uma matriz com:
- requisito ou proibição;
- critério de aceite;
- caso de teste;
- evidência esperada;
- estado: coberto, parcial, pendente ou sem critério;
- motivo;
- revisão humana necessária.

Aponte:
- requisito sem critério;
- critério sem fonte;
- teste que depende de decisão A DEFINIR;
- sugestão usada indevidamente como obrigação.

A matriz precisa conter R1 a R21 e as oito proibições. Uma linha pode estar parcial quando parte do comportamento é testável e outra depende de decisão.

R10 é um exemplo: a obrigatoriedade do aceite pode ser testada, mas o destino final do link continua pendente.

Passo 8: revise um resultado sintético

Agora forneça esta descrição fictícia do primeiro corte:

RESULTADO RECEBIDO: versão 0.8
- Nome, data e cidade aparecem.
- O texto principal diz: “Garanta sua vaga no Operação 2027”.
- O endereço exibido é “Centro de Convenções de Vitória”.
- O formulário contém nome, e-mail, empresa, cargo e telefone.
- Todos os campos, incluindo telefone, estão obrigatórios.
- Existe caixa de aceite de privacidade sem link.
- O botão diz “Quero participar”.
- No erro de e-mail, todos os campos são apagados.
- No sucesso, aparece “Inscrição confirmada”.
- A solicitação foi registrada na lista EVENTO-2027-INSCRICOES.
- Um e-mail automático de confirmação foi enviado.
- Nenhuma tarefa foi criada no CRM.
- Os campos possuem placeholder, mas não possuem rótulo visível.
- O botão pode ser acionado por teclado.
- O logotipo fornecido foi usado.
- A equipe enviou capturas de desktop e celular.
- Não há evidência de navegação completa por teclado.

Peça:

Compare o RESULTADO RECEBIDO com o briefing e a matriz.

Para cada item, informe:
- requisito de origem;
- observado;
- esperado;
- estado: atende, falha, pendente ou sem evidência;
- severidade;
- correção ou decisão necessária;
- evidência faltante.

Não aprove o entregável.
Não acrescente requisitos.

Gabarito da revisão

A revisão deve localizar pelo menos estes pontos:

Falhas ou bloqueios

  • “Garanta sua vaga” viola o objetivo e a proibição de prometer vaga.
  • O endereço foi inventado diante de R3.
  • Telefone obrigatório viola R8.
  • A caixa sem link deixa R10 pendente e incompleta.
  • O botão diverge do texto aprovado em R6.
  • Apagar campos viola R12.
  • “Inscrição confirmada” viola R11 e a proibição de confirmação.
  • O e-mail automático viola R14.
  • Ausência de rótulos visíveis viola R17.

Atende

  • registro na lista atende R13;
  • nenhuma tarefa no CRM atende R15;
  • logotipo atende parte de R16;
  • capturas em desktop e celular oferecem evidência para R20;
  • acionamento do botão por teclado cobre somente parte de R18.

Pendente ou sem evidência

  • destino final da política de privacidade continua A DEFINIR;
  • contraste legível precisa de evidência;
  • navegação completa por teclado não foi demonstrada;
  • navegadores mínimos continuam A DEFINIR.

A presença de vários itens corretos não compensa uma promessa proibida. O aceite precisa respeitar requisitos impeditivos antes de resumir o resultado numa porcentagem.

Passo 9: produza a devolutiva sem renegociar o escopo

Peça:

Prepare uma devolutiva de revisão com quatro blocos:
1. preservar: itens que atendem;
2. corrigir antes do aceite: falhas ligadas ao briefing;
3. decidir pelo dono do briefing: itens A DEFINIR;
4. melhorias opcionais: somente sugestões claramente identificadas.

Para cada correção, cite requisito, comportamento observado e evidência esperada.
Use linguagem factual.
Não chame melhoria de obrigação.
Não declare aprovação final.

Uma devolutiva útil permite execução. “Melhorar a experiência” transfere interpretação. “Manter telefone opcional conforme R8 e repetir o envio válido com o campo vazio” orienta correção e teste.

Passo 10: faça a auditoria final da própria saída

Envie:

Audite sua revisão linha por linha contra o briefing.
Crie cinco listas:
1. requisito preservado;
2. requisito omitido;
3. obrigação inventada;
4. lacuna preenchida indevidamente;
5. ação externa sugerida sem autorização.

Cite o trecho de origem.
Não corrija silenciosamente.

Reprove o pacote se ele:

  • inventar endereço;
  • escolher link de privacidade;
  • exigir navegador não informado;
  • definir meta de conversão;
  • transformar gosto visual em bloqueio;
  • aceitar telefone obrigatório;
  • aceitar confirmação de vaga;
  • ignorar o e-mail automático;
  • declarar publicação ou aprovação;
  • usar dados reais;
  • omitir evidência necessária.

Como revisar a qualidade dos critérios

Cada critério possui origem

Se não aponta briefing, regra ou decisão aprovada, pode ser uma sugestão disfarçada de obrigação.

O resultado é observável

“Funciona bem” deixa a avaliação aberta. “Ao enviar sem cargo, o formulário identifica o campo e preserva os demais valores” define uma observação.

A evidência alcança o comportamento

Uma captura do formulário não prova registro na lista. Uma mensagem de sucesso não prova ausência de e-mail automático. Cada critério precisa de evidência no lugar correto.

O teste não amplia a autoridade

O pacote pode preparar aceite. A pessoa responsável continua decidindo, registrando a aprovação e autorizando publicação ou pagamento.

A lacuna permanece visível

Resolver silenciosamente uma pendência pode produzir retrabalho contratual. Marque A DEFINIR, formule a pergunta e suspenda o critério afetado.

Limites do método

O ChatGPT organiza apenas o material fornecido. Ele não conhece conversas paralelas, cláusulas contratuais, padrões internos, critérios legais ou decisões que ficaram fora do briefing.

Antes do aceite real:

  • o dono do negócio confirma objetivo e conteúdo;
  • design revisa marca, contraste e experiência;
  • tecnologia valida integração e comportamento;
  • privacidade confirma texto, base e destino da política;
  • segurança revisa coleta e armazenamento;
  • a equipe executa os casos no ambiente correto;
  • resultados observados são registrados;
  • divergências voltam para correção;
  • uma pessoa autorizada aprova a versão identificada.

A ferramenta pode omitir requisito, confundir sugestão com obrigação ou afirmar cobertura sem evidência. A revisão humana precisa voltar ao briefing e ao artefato.

Checklist antes do aceite

  • [ ] Briefing, entrega e revisão possuem versão?
  • [ ] Cada critério aponta para uma fonte aprovada?
  • [ ] Requisitos e proibições estão completos?
  • [ ] Lacunas continuam como A DEFINIR?
  • [ ] Sugestões estão separadas do escopo?
  • [ ] Critérios descrevem comportamento observável?
  • [ ] Casos usam dados sintéticos?
  • [ ] Evidência foi definida para cada resultado?
  • [ ] Campos obrigatórios e opcionais foram testados?
  • [ ] Erros preservam os dados já preenchidos?
  • [ ] Mensagens evitam promessas proibidas?
  • [ ] Integrações dentro e fora do escopo foram verificadas?
  • [ ] Acessibilidade foi testada além de uma captura?
  • [ ] Itens sem evidência permanecem pendentes?
  • [ ] O parecer continua como rascunho?
  • [ ] A decisão final pertence a uma pessoa autorizada?

Aceite começa antes da entrega

Critérios úteis retiram ambiguidade do final do trabalho. Eles ligam cada requisito a uma observação, um teste e uma evidência. Também mostram o que ainda depende de decisão.

O ChatGPT ajuda a decompor o briefing, encontrar lacunas e preparar a revisão. O aceite continua sendo um ato humano, aplicado à versão correta e sustentado por evidência do comportamento real.

Fontes oficiais verificadas em 2 de outubro de 2026:

As fontes sustentam capacidades e controles gerais do produto. Elas não aprovam o briefing, não comprovam execução do teste e não autorizam inserir dados empresariais numa conta específica.

Leia também