Documentar processo para a IA: um texto que serve para os dois

Empresas que começam a usar agentes descobrem que precisam escrever os processos, e quase sempre criam uma segunda versão do manual, feita para a máquina. Este artigo mostra por que isso sai caro e como escrever um único texto que a pessoa e o agente consomem igual.

Categoria: Método

Por ·

Resposta rápida: Quando uma empresa coloca agentes para trabalhar, ela descobre que os processos nunca foram escritos com precisão, e a reação mais comum é criar um segundo documento voltado à máquina. Isso dobra o custo de manutenção e garante divergência entre as duas versões em poucos meses, com o pior desfecho possível: pessoa e agente seguindo regras diferentes. Existe um texto único que serve aos dois, e ele obedece a cinco regras. Uma decisão por bloco, com o gatilho escrito na frente. Nomes reais, os que a casa usa na boca. Exceção escrita como exceção, e não como nota de rodapé. Fonte da informação nomeada, com o lugar exato onde ela vive. Data e dono em cada bloco. Um documento assim é lido por gente em trinta segundos e consumido por agente sem tradução, e o efeito colateral mais valioso é descobrir as decisões que a empresa nunca tinha tomado.

Fui chamado numa empresa de serviços que tinha decidido documentar processos para viabilizar o uso de agentes. Seis meses antes, alguém havia contratado um trabalho de mapeamento, e o resultado estava numa pasta com mais de quarenta arquivos, incluindo fluxogramas bonitos e um manual de oitenta páginas.

A pessoa responsável pelo projeto me contou, meio sem graça, que o time não usava aquilo. Quando alguém tinha dúvida, perguntava no grupo de mensagens. E que agora eles estavam escrevendo uma outra documentação, mais curta e direta, para alimentar o agente.

Pedi para ver as duas. A segunda versão era muito melhor: objetiva, com gatilho na frente, exceções explícitas, sem enfeite. Perguntei por que não substituíam a primeira por ela. A resposta veio na hora: porque a primeira é a oficial, aprovada, com assinatura da diretoria.

A empresa estava mantendo um documento que ninguém lia por causa de uma assinatura, e escrevendo outro que resolvia o problema, com a intenção declarada de usá-lo apenas com a máquina. Em nove meses, os dois iam divergir, e a pergunta sobre qual valia ia parar na mesa de alguém.

Duas versões do mesmo processo é a doença

O impulso de escrever separado para a máquina vem de uma suposição razoável e errada: a de que o agente precisa de um formato técnico que uma pessoa não leria. Isso era verdade quando automação significava programar regra em sistema, e deixou de ser.

Manter duas versões custa duas vezes e vale menos que uma. Quando o processo muda, alguém precisa lembrar de atualizar os dois lugares, e essa pessoa vai esquecer em algum momento. A partir daí, existem duas verdades na empresa, e ninguém sabe qual delas está errada.

O desfecho é sempre o mesmo e é feio: o cliente ouve uma coisa da pessoa e outra do agente, ou dois funcionários agem diferente porque leram documentos diferentes. Escolher um único texto é decisão de arquitetura de informação, e ela precisa ser tomada antes de o time começar a escrever.

Por que o manual de oitenta páginas não serve para nenhum dos dois

Vale entender por que o documento tradicional falha, porque a explicação vale para os dois leitores. Um manual longo é organizado por área e por hierarquia, o que reflete o organograma e não o momento em que a dúvida aparece.

Quem tem dúvida real está no meio de uma tarefa, com um caso concreto na mão, e precisa de uma resposta em segundos. O manual pede navegação: sumário, capítulo, seção, e depois um texto que explica o contexto antes de dizer o que fazer. Ninguém tem paciência para isso com um cliente esperando.

O agente sofre com o mesmo defeito por outro motivo. Texto longo, cheio de contexto e com a regra enterrada no meio de um parágrafo explicativo, produz respostas imprecisas, porque a informação decisiva está diluída. Os dois leitores precisam da mesma coisa: a regra na frente.

O que a pessoa procura quando abre um documento de processo

Observei muita gente consultando documentação interna e o padrão é sempre igual. A pessoa não lê, ela busca. Digita uma palavra, olha o resultado, e decide em três segundos se aquilo responde. Se não responder, ela fecha e pergunta a alguém.

O que ela quer encontrar é um bloco curto que comece pela situação dela. Cliente pede reembolso depois de trinta dias. Fornecedor entregou fora do padrão. Nota chegou com valor divergente. Ela procura o caso, não o capítulo.

Esse comportamento explica por que o grupo de mensagens vence o manual em toda empresa. No grupo, ela descreve a situação em linguagem natural e recebe a regra. É exatamente esse formato que precisa estar no documento, e é exatamente o formato que o agente também consome bem.

O que o agente precisa do mesmo texto

As exigências da máquina são menos exóticas do que se imagina, e elas se resumem a três. Precisa que a regra esteja explícita, e não implícita numa história. Precisa que o caso de exceção esteja separado do caso comum. E precisa saber onde buscar o dado que muda com frequência.

O terceiro item é o que mais gera erro na prática. Quando o documento diz que o prazo é de cinco dias, aquele número envelhece dentro do texto. Quando ele diz que o prazo vigente está numa tabela específica, com nome e local, o agente busca a informação atual.

Existe uma regra simples que resolve isso e melhora o documento para gente também: número que muda não entra no texto do processo, entra na fonte apontada pelo texto. Assim o processo descreve o que fazer, e o dado vive onde ele é mantido.

Leia também

A boa notícia: as duas listas de exigência são quase iguais

Quando se coloca as duas listas lado a lado, a sobreposição é grande. Os dois querem a regra na frente, os dois querem o caso em linguagem de negócio, os dois querem a exceção separada, e os dois se dão mal com contexto longo antes da resposta.

A diferença que sobra é pequena: o agente precisa de mais explicitação, porque não tem a convivência que preenche lacuna. Onde uma pessoa entende que "avaliar caso a caso" quer dizer levar ao coordenador, o agente precisa ler isso escrito.

Essa diferença é boa, e é o argumento que eu uso para vender o trabalho internamente. Escrever para o agente força a precisão que a empresa devia ter e nunca teve, e o beneficiário maior acaba sendo a pessoa nova que entra na semana seguinte.

Regra 1: uma decisão por bloco, com o gatilho na frente

O bloco é a unidade do documento, e ele resolve uma decisão só. Começa pela situação que o dispara, escrita como a pessoa descreveria: "quando o cliente pede reembolso após o prazo de sete dias". Depois vem o que fazer, em frases curtas, e depois o que nunca fazer.

Um bloco tem oito a quinze linhas. Se está passando disso, existe mais de uma decisão dentro dele, e separar melhora a leitura para os dois leitores. Isso torna o documento maior em número de blocos e muito mais curto em tempo de consulta.

O ganho aparece na busca. Quando cada bloco carrega o gatilho no título, procurar por "reembolso fora do prazo" encontra o bloco certo, e não um capítulo de política de reembolso onde a informação está no terceiro subitem.

Regra 2: usar os nomes que a casa usa na boca

Documentação interna tende a inventar vocabulário formal que ninguém fala. O documento diz "solicitação de reversão de faturamento" e o time diz "estorno". O agente, alimentado pelo documento, responde com a palavra formal e ninguém entende.

A regra que aplico é registrar o nome oficial uma vez e usar o nome real no resto. Quando existem dois nomes para a mesma coisa, os dois entram no bloco, porque quem busca vai digitar o que fala. Sinônimo escrito é ganho de busca para pessoa e para máquina.

Isso vale também para nome de sistema, de tela e de campo. Escrever o caminho exato que a pessoa vê na tela, com o texto do botão, poupa muito mais tempo que uma descrição elegante do fluxo. E permite que o agente instrua alguém com precisão.

Leia também

Regra 3: a exceção escrita como exceção

O erro mais comum em documentação de processo é enterrar exceção no meio do texto do caso comum, muitas vezes com um "salvo quando" no fim do parágrafo. Isso funciona para quem já conhece o processo e falha para todos os outros.

Exceção precisa de bloco próprio, com gatilho próprio, e precisa dizer quem autoriza. A frase que resolve a maior parte dos casos: nesta situação, a decisão é de tal cargo, e o critério é este. Sem o nome do cargo, a exceção vira um convite ao improviso.

Existe um subproduto valioso: a lista de exceções documentadas é a melhor pauta de simplificação de processo que uma empresa pode ter. Quando um caso comum tem sete exceções, o processo está errado, e isso só fica visível quando as sete estão escritas em blocos separados.

Regra 4: dizer onde a informação vive, com nome

Todo bloco que depende de dado precisa apontar a fonte com nome exato: qual planilha, qual sistema, qual tela, qual tabela, e quem mantém aquilo. Fonte apontada de forma vaga é a origem de metade dos erros que vejo em operação com agente.

Isso tem um efeito organizacional que ultrapassa o documento. Ao escrever as fontes, a empresa descobre que a mesma informação existe em três lugares com valores diferentes, e que ninguém sabe qual é a oficial. Essa descoberta é desconfortável e é a mais útil do processo.

Resolver isso é trabalho anterior ao agente, e é o tipo de faxina que dá retorno independente de qualquer projeto de IA. A ordem que funciona nessa arrumação está em arrumar os dados antes de começar com IA.

Regra 5: data e dono em cada bloco

Cada bloco leva duas linhas de metadado: quando foi revisado por último e quem responde por ele. Parece burocracia e é o que separa documentação viva de documentação abandonada.

A data serve para dois leitores. A pessoa que consulta sabe se aquilo é recente. E na revisão periódica, dá para listar os blocos mais antigos e revisar por ordem de idade, o que transforma manutenção num trabalho de meia hora por semana em vez de um projeto anual.

O dono serve para outra coisa: dar destino à correção. Quando alguém descobre que um bloco está errado, existe um nome para avisar. Sem dono, o erro é comentado no corredor e permanece no documento por anos, envenenando pessoa e agente ao mesmo tempo.

O fluxograma que ninguém lê, e o que fazer com ele

Não sou contra diagrama, sou contra diagrama como documentação principal. Fluxograma serve muito bem para uma coisa: mostrar a visão geral a quem está entendendo o processo pela primeira vez, numa conversa de quinze minutos.

Para consulta no meio da tarefa, ele falha. A pessoa precisaria localizar o próprio caso dentro de uma figura, seguir setas e interpretar losango de decisão, tudo isso com um cliente esperando. É mais lento que perguntar no grupo.

Minha recomendação prática: manter um diagrama simples por processo, com dez a quinze caixas, apenas como mapa, e ter os blocos de texto como a documentação de trabalho. O diagrama fica para treinamento, o texto fica para operação.

Leia também

Como escrever isso a partir do que já existe

A boa notícia é que ninguém precisa começar de uma página em branco. O processo real existe na cabeça de três ou quatro pessoas e nas conversas do grupo de mensagens, e as duas fontes são melhores que qualquer manual antigo.

O método que eu uso é uma entrevista de quarenta minutos com quem executa, gravada, com uma pergunta guia: me conte os últimos cinco casos que você resolveu, um por um, com o que você decidiu e por quê. Casos reais produzem regras reais, incluindo as exceções que ninguém lembraria de mencionar em abstrato.

A transcrição dessa conversa virou matéria-prima barata de transformar em blocos, e é aqui que a tecnologia atual acelera de forma decisiva. O trabalho humano que sobra é o mais importante: revisar, decidir o que fica como regra e nomear os donos. Sobre o acervo que esse esforço constrói, escrevi em IA e memória institucional.

Onde o processo real diverge do que está escrito

Toda vez que faço esse trabalho, aparece divergência entre o que o documento oficial diz e o que a operação faz. E na maior parte dos casos, quem está certo é a operação, porque ela ajustou o processo à realidade e ninguém atualizou o papel.

A pergunta que resolve é direta: o que a operação faz hoje está errado, ou o documento é que está velho? Fazer essa pergunta caso a caso, com quem executa na sala, é a parte mais valiosa do projeto e a que mais gera decisão pendente.

Existe um risco a evitar: transformar o exercício em auditoria de conformidade. Se as pessoas perceberem que contar o que realmente fazem gera punição, elas passam a descrever o processo oficial, e a documentação nasce falsa. O acordo precisa ser explícito no início da conversa.

O documento vira o teste do agente, e isso fecha o ciclo

Existe um uso do documento que quase ninguém percebe e que paga o esforço sozinho. Cada bloco, com o gatilho na frente e a regra escrita, é um caso de teste pronto. Dá para perguntar ao agente exatamente aquele gatilho e comparar a resposta com o bloco.

Isso transforma qualidade em algo verificável. Em vez de discutir se o agente está bom, a operação roda os blocos como uma lista e vê quantos ele acerta. Quando erra, a investigação tem duas saídas possíveis: o bloco está mal escrito ou a instrução do agente não aponta para ele.

Times que adotam esse hábito ganham uma coisa rara: capacidade de mudar de ferramenta sem medo. O documento é o padrão, e o teste roda contra qualquer fornecedor. É a forma mais barata de reduzir dependência que eu conheço nesse assunto.

Leia também

Quem escreve, e por que raramente é a pessoa mais sênior

A tentação é pedir para o especialista escrever, porque ele sabe mais. Costuma dar errado por dois motivos. Ele conhece tanto o processo que omite o obvio, e o obvio dele é justamente o que a pessoa nova e o agente não sabem.

O arranjo que funciona é uma dupla. Alguém com menos tempo de casa escreve, entrevistando o especialista, porque essa pessoa ainda percebe o que não está claro. O especialista revisa e aprova. A escrita fica clara e o conteúdo fica correto.

Existe um ganho de formação nisso. Quem escreve o processo aprende o processo de um jeito que treinamento nenhum entrega, e a empresa forma alguém enquanto documenta. Sobre a chegada de gente nova nesse ambiente, escrevi em contratei uma pessoa para um time de agentes.

Como manter isso vivo sem virar burocracia

Documentação morre por falta de rotina, não por falta de qualidade inicial. A prática que sustenta é pequena e barata: toda vez que uma dúvida chega ao grupo de mensagens e é respondida, alguém verifica se existe bloco para aquilo. Se não existe, cria. Se existe e a pessoa não achou, corrige o título.

Esse hábito transforma o grupo de mensagens de concorrente do documento em fonte de melhoria dele. E dá um indicador ótimo de saúde: o número de perguntas que já tinham resposta escrita. Quando esse número cai, a documentação está funcionando.

O segundo ritual é a revisão por idade, meia hora por semana, começando pelos blocos mais antigos. Nenhum projeto de atualização anual, nenhuma força-tarefa. A lógica de rotinas que sustentam operação com IA está em os nove rituais que sustentam IA em operação.

Quando os blocos ficam bons, aparece uma consequência que costuma surpreender a diretoria: eles viram a base de um atendimento interno automático, que responde a dúvida do próprio time sem precisar de gente. A mesma pergunta que chegava trinta vezes por mês ao grupo passa a ser resolvida na hora, com a resposta oficial e datada. O desenho desse tipo de fila interna está em helpdesk interno com IA.

O que eu não documentaria

Vale dizer o limite, porque a empolgação com esse trabalho produz projeto infinito. Não documento processo que está em mudança ativa, porque o texto nasce vencido e queima a confiança no documento. Espero a operação estabilizar.

Não documento decisão que depende de julgamento pesado sobre pessoas ou sobre relação de longo prazo. Escrever critério para negociar com um cliente de dez anos produz uma caricatura, e a tentativa de padronizar isso costuma piorar a decisão.

E não documento o que acontece uma vez por ano. O custo de manter o bloco atualizado supera o benefício, e naquele momento é mais barato perguntar a quem sabe. Documentação boa cobre o que se repete, e a régua de repetição é o que separa processo de evento.

A régua que uso para decidir é uma pergunta: isso acontece pelo menos duas vezes por mês e alguém já perguntou como fazer? Se as duas respostas forem sim, vale bloco. Se acontece toda semana e ninguém nunca perguntou, provavelmente é tarefa dominada por uma pessoa só, e o assunto ali é risco de dependência, não falta de documento.

Como eu abriria a próxima segunda-feira

Não pediria projeto de mapeamento a ninguém. Abriria o grupo de mensagens do time e leria as últimas cinquenta perguntas feitas ali, marcando quais se repetem. Isso leva uma hora e produz uma lista mais honesta que qualquer levantamento formal.

As dez perguntas mais repetidas são os dez primeiros blocos, e nada mais. Escreveria esses dez com uma pessoa que executa o processo, no formato de gatilho na frente, com fonte nomeada, dono e data. Dez blocos cabem numa tarde e resolvem uma fatia real do volume de dúvida.

Depois disso, mediria uma coisa só nas quatro semanas seguintes: quantas dessas dez perguntas voltaram ao grupo. É a única evidência que importa, e ela diz se o documento está sendo encontrado, não apenas se ele existe. A rotina que mantém esse ciclo andando está em como criar uma rotina de melhoria contínua com IA.

Perguntas frequentes

Preciso escrever uma documentação separada para o agente de IA?

Não, e criar duas versões costuma sair caro. Manter dois documentos custa o dobro e garante divergência em poucos meses, com o pior desfecho possível: pessoa e agente seguindo regras diferentes, o cliente ouvindo uma coisa de cada lado. As exigências dos dois leitores se sobrepõem quase inteiramente: os dois querem a regra na frente, o caso descrito em linguagem de negócio, a exceção separada do caso comum e nenhum contexto longo antes da resposta. A diferença que sobra é que o agente precisa de mais explicitação, porque não tem a convivência que preenche lacuna.

Como estruturar um bloco de documentação de processo?

Uma decisão por bloco, com o gatilho escrito no título na linguagem de quem tem a dúvida, algo como quando o cliente pede reembolso após o prazo de sete dias. Depois o que fazer, em frases curtas, e o que nunca fazer. Cada bloco leva a fonte da informação com nome exato de planilha, sistema ou tela, mais duas linhas de metadado: data da última revisão e nome do responsável. Um bloco tem de oito a quinze linhas; se passar disso, existe mais de uma decisão dentro dele e vale separar.

Por onde começar a documentar processo numa empresa que nunca fez isso?

Pelo grupo de mensagens do time, não por um projeto de mapeamento. Leia as últimas cinquenta perguntas feitas ali e marque as que se repetem: isso leva uma hora e produz uma lista mais honesta que qualquer levantamento formal. As dez perguntas mais repetidas são os dez primeiros blocos. Escreva esses dez com alguém que executa o processo e, nas quatro semanas seguintes, meça uma coisa só: quantas dessas perguntas voltaram ao grupo. É a única evidência de que o documento está sendo encontrado.

Quem deve escrever a documentação de processo?

Uma dupla, e o autor principal raramente é a pessoa mais sênior. Quem tem menos tempo de casa escreve, entrevistando o especialista, porque ainda percebe o que não está claro; o especialista revisa e aprova. Quem domina muito o processo tende a omitir o obvio, e o obvio dele é exatamente o que a pessoa nova e o agente não sabem. Existe um ganho de formação nesse arranjo: quem escreve o processo aprende o processo de um jeito que treinamento nenhum entrega.

Documentar processo para a IA: um texto que serve para os dois