Fluxo de trabalho IA: cinco aprovações humanas antes de um agente publicar
Um fluxo de trabalho IA para publicar precisa de cinco aprovações humanas: entrada, evidência, rascunho, publicação e verificação. Veja a tabela de passagem para um agente API ou MCP, a condição de cada etapa e o que continua humano.

Um fluxo de trabalho IA para publicar depende de cinco aprovações humanas, não de um prompt e um botão de publicar. Uma pessoa ainda decide o tema, quais afirmações são permitidas, o que o rascunho pode dizer, quem aperta publicar e se a página no ar corresponde ao que foi aprovado. Coloque essas cinco aprovações na passagem de bastão e o agente fica útil. Retire-as e você só ganha uma forma mais rápida de publicar um erro.
Este capítulo parte do princípio de que você já tem um briefing de conteúdo e um jeito de verificar afirmações. Se o briefing ainda é só um tema e uma contagem de palavras, comece por como escrever um briefing de conteúdo. Se a revisão é o ponto fraco, o registro de afirmações de verificar conteúdo gerado por IA é a ferramenta que acompanha. Aqui o foco é mais estreito: onde fica a pessoa quando um script ou um assistente de IA faz a passagem.
Fluxo de trabalho IA: por que aprovações, e não prompts
Uma aprovação é uma decisão registrada antes de o próximo passo começar. Um prompt apenas orienta a próxima saída. A diferença importa porque um agente pode chamar uma ferramenta, gastar créditos e gravar um registro sem perguntar de novo. O protocolo coloca essa responsabilidade no host. A especificação MCP diz que os hosts «devem obter o consentimento explícito do usuário antes de invocar qualquer ferramenta» (especificação Model Context Protocol, consultada em 2026-11-02). Esse consentimento é uma aprovação e precisa viver no seu processo, não numa janela que ninguém lê.
A maioria das equipes já tem o equivalente. Um editor aprova o briefing. Um revisor assina uma afirmação. Um responsável aperta publicar. A falha aparece quando essas decisões entram numa troca automatizada e ninguém reescreve a sequência. O agente recebe as cinco tarefas de uma vez, e o único controle que sobra é confiar na saída.
| Passagem | O modelo decide | A pessoa mantém |
|---|---|---|
| Só prompt | Tema, fatos, estrutura, texto | Tudo depois da colagem |
| Prompt e exportação | Rascunho e formatação | Revisão, publicação, verificação |
| Cinco aprovações | Escrever dentro de um briefing aprovado | Cada aprovação, com registro |
A terceira linha é a que este capítulo constrói. Ela deixa o começo mais lento e o fim mais rápido, porque a correção acontece quando ainda custa pouco.
Há três atores, e eles não devem compartilhar uma única identidade. O modelo escreve. O script move os dados e anota o que aconteceu. A pessoa aprova. Com uma chave compartilhada, o registro não diz quem agiu, e a primeira revisão importante vira uma investigação. Separar chaves não é burocracia: é o que mantém a aprovação de publicação visível.
As cinco aprovações de um fluxo de trabalho IA, em ordem
Rode na ordem abaixo. Cada uma tem uma condição de passagem observável e produz um registro que pode ser entregue à próxima pessoa. Sem registro, considere a aprovação como falha.
- Entrada: aprovar a pergunta. O briefing nomeia um leitor, uma intenção de busca e uma página que deve ser dona da resposta. Passa quando o briefing lista as páginas existentes que não podem ser duplicadas. A intenção de busca mostra como ler o que o leitor está pedindo.
- Evidência: aprovar as fontes. Cada afirmação factual tem uma URL e uma data de consulta, ou uma amostra própria e uma janela de tempo. Passa quando nenhuma linha continua «a confirmar» e o revisor abriu as fontes, não apenas as citações.
- Rascunho: aprovar o argumento. O rascunho responde no primeiro parágrafo, mantém uma ideia por seção e nomeia seu limite. Passa quando o revisor consegue apontar a frase que diz o que a página não cobre.
- Publicação: aprovar a ação. Uma pessoa nomeada aperta o botão na própria conta. Passa quando o registro tem a URL, o horário e a conta que publicou. O agente prepara o conteúdo; ele não vira dono da conta.
- Verificação: aprovar o resultado. A página no ar é buscada e comparada ao rascunho aprovado. Passa quando título, canonical, dados estruturados e links internos coincidem, e a URL responde 200.
| Aprovação | O que responde | O que deixa |
|---|---|---|
| Entrada | O que responder e onde | Briefing com página dona |
| Evidência | Quais afirmações são permitidas | Registro de fontes |
| Rascunho | Se o argumento se sustenta | Versão aprovada |
| Publicação | Quem age | URL, horário, conta |
| Verificação | Se a página está correta | Busca e diferenças |
Como é a passagem por API ou MCP
A passagem é um conjunto de permissões e um rastro escrito, não uma integração única. Tanto em REST quanto em MCP, quem chama precisa de uma chave cujos escopos combinem com a aprovação que ele pode tocar. A documentação para desenvolvedores do QueryWin separa read, publish e spend, e afirma que publish não inclui spend (documentação para desenvolvedores do QueryWin, consultada em 2026-11-02). Essa separação é a versão técnica da aprovação de publicação: uma chave que lê um rascunho não vira automaticamente uma chave que paga por outro.
A mesma página lista dezenove ferramentas MCP e diz que elas são filtradas por escopo, então uma chave somente leitura nem mostra as ferramentas de geração ao assistente. Também documenta um limite de 120 requisições por minuto e por chave, um teto diário de geração e a diferença entre uma listagem publicada que você informou e uma listagem verificada que o QueryWin conferiu cerca de 72 horas depois. São controles, não garantias. Dizem o que o sistema pode registrar; não decidem se o rascunho é verdadeiro.
| Escopo | O que permite | O que não decide |
|---|---|---|
| read | Ler sites, temas e rascunhos | Se o tema vale a pena |
| publish | Criar perfis, campanhas e status | Se a afirmação é exata |
| spend | Gerar estruturas, rascunhos e reescritas | Se a saída passa na revisão |
Dê ao agente uma chave própria. Uma chave compartilhada transforma uma integração comprometida em todas as aprovações de uma vez e torna o registro de publicação inútil, porque você deixa de saber quem agiu.
O entregável: uma tabela de passagem de uma página
Copie esta tabela para o mesmo documento do briefing. É toda a superfície de controle: cinco linhas, um responsável por linha e um lugar para guardar a evidência. Uma aprovação sem responsável é só uma sugestão.
| Aprovação | Entrada | Condição | Evidência | Responsável |
|---|---|---|---|---|
| Entrada | Tema e leitor | Uma intenção, uma página | Link do briefing | Editor |
| Evidência | Afirmações e fontes | Tudo tem URL ou amostra | Registro | Revisor |
| Rascunho | Briefing aprovado | Resposta primeiro, limite dito | Versão do rascunho | Editor |
| Publicação | Rascunho aprovado | Uma pessoa, sua conta | URL e horário | Publicador |
| Verificação | URL no ar | A página coincide | Busca e diferenças | Revisor |
Antes de rodar o agente:
[ ] o briefing lista a página que não pode ser duplicada
[ ] cada afirmação tem URL e data, ou amostra e janela
[ ] o revisor abriu as fontes
[ ] o agente tem chave própria, limitada a esta tarefa
[ ] a publicação nomeia uma pessoa e uma conta
Depois que o agente voltar:
[ ] o rascunho declara seu limite em uma frase
[ ] nenhuma afirmação foi acrescentada após a aprovação de evidência
[ ] a URL no ar responde 200
[ ] título, canonical, dados estruturados e links coincidem
[ ] o registro diz quem agiu e quando
Duas linhas são fáceis de falsificar. «O revisor abriu as fontes» descreve um comportamento, não uma caixa: anote a URL ao lado da afirmação. «A página coincide» é uma comparação: guarde a versão ou o hash do rascunho aprovado. Se você não consegue mostrar um desses registros, a aprovação não aconteceu. Um rascunho não é uma decisão.
Onde este fluxo de trabalho falha
Três falhas explicam quase todo o dano. Todas passam por uma leitura rápida, e por isso as aprovações precisam ser registradas em vez de lembradas.
- O agente escreve o briefing. A aprovação de entrada vira um resumo do que o modelo já queria dizer. A página responde a uma pergunta fácil, não à do leitor. Correção: o briefing é aprovado antes da chamada de geração e chega ao agente como entrada.
- A aprovação de evidência vira checagem de links. Alguém confirma que os links existem, não que sustentam a frase. Uma fonte pode ser real e não dizer o que o rascunho afirma. Correção: o revisor reescreve a afirmação com as próprias palavras ao lado da fonte e depois compara com o rascunho.
- A aprovação de publicação é delegada à ferramenta. A integração tem escopo publish, então ela publica. Nada está tecnicamente quebrado, e o registro diz que um agente agiu. Correção: mantenha publish numa chave usada por uma pessoa e dê ao agente só read e spend.
Não medimos com que frequência um agente pula uma aprovação, porque uma aprovação pulada não deixa registro. Esse é justamente o problema: a falha é invisível na saída e só aparece na passagem.
Também não sabemos sua capacidade de revisão. Cinco aprovações podem virar uma fila que ninguém esvazia. Se o gargalo é a fila, reduza o número de artigos, não as aprovações. Publicar menos páginas aprovadas vale mais do que publicar mais páginas sem leitura.
Perguntas frequentes
O que é um fluxo de trabalho IA de conteúdo?
É a sequência que transforma uma oportunidade de busca numa página aprovada, com uma pessoa responsável em cada passagem. Inclui o briefing, a evidência, o rascunho, a publicação e a verificação. O modelo pode escrever parte; ele não é dono das decisões.
Um agente pode publicar sem revisão?
Não quando a página afirma fatos sobre seu produto, seu mercado ou seus clientes. Um rascunho não é uma decisão. Se a saída tem pouco risco e é reversível, uma aprovação mais leve pode bastar, mas o registro ainda precisa nomear a conta que agiu.
Como revisar conteúdo gerado por IA?
Revise as afirmações, não a prosa. Coloque cada frase factual num registro, anexe uma fonte e uma data, e confirme que a fonte diz aquela frase. O registro explicado antes pega números inventados que uma releitura deixa passar.
O MCP substitui um processo de aprovação?
Não. O MCP padroniza como um assistente chama ferramentas; não decide quais chamadas uma pessoa aprovou. A especificação coloca o consentimento no host, e seu processo ainda precisa registrar o sim. Quanto mais ferramentas o agente tiver, mais importante fica o registro, porque mais ações podem acontecer entre duas revisões.
Este capítulo trata da passagem, não da escrita nem dos prompts. Ele também não afirma que uma aprovação torna o rascunho verdadeiro; ela só torna a decisão visível. Isso já basta para frear os erros caros e deixa o julgamento com quem deve julgar.
Faz parte do guia do QueryWin · Nível 3


