Cenário ilustrativo. Um gabinete de contabilidade quer que um agente concilie os recebimentos dos clientes. Pergunta à Marta, que o faz há doze anos, como é que o faz. «É fácil — diz ela —, cruzas o extrato com as faturas.» O agente é construído com essa descrição e, nas primeiras semanas, falha precisamente onde a Marta nunca parava para pensar: o cliente que paga três faturas numa só transferência, o valor que chega sempre com um desconto combinado de viva voz, o fecho do trimestre em que não se mexe em nada até chegar um e-mail. Nada disto estava escrito. A Marta nem sabia que o sabia.
A tese numa linha: antes de automatizar um processo, é preciso tirar da cabeça de quem o executa aquilo que nunca foi escrito, e esse passo muitas vezes já rende mais do que a própria automatização.
Porquê documentar processos antes de automatizar com IA?
Porque um agente executa o que lhe contas, não o que a empresa faz de facto. A diferença entre as duas coisas é o conhecimento tácito: critérios, exceções e atalhos que quem faz o trabalho aplica sem dar por isso e, por isso mesmo, não sabe explicar. Se lhe perguntas «como é que fazes?», devolve-te a versão oficial, a que cabe numa frase. O agente constrói-se sobre essa versão e parte-se em tudo o resto.
Não é um pormenor de implementação. A análise da RAND sobre o porquê de os projetos de IA falharem, baseada em entrevistas a engenheiros e cientistas de dados, aponta entre as causas mais comuns que o problema a resolver foi mal compreendido ou mal comunicado (RAND, 2024). É o mesmo padrão que descrevemos em porque falham os projetos de automatização com IA: o projeto não falha na demonstração, falha no intervalo entre aquilo que cada parte dava por entendido.
Como saber se um processo só existe na cabeça de uma pessoa?
Há sinais bastante fiáveis, e não é preciso uma auditoria para os ver.
- Duas pessoas fazem-no de forma diferente e ambas dizem que o fazem bem. Cada uma aplica o seu critério e ninguém os colocou alguma vez lado a lado.
- Quando essa pessoa falta, o processo pára ou degrada-se. Se as férias de alguém são um risco operacional, o processo vive na cabeça dela (o mesmo problema, visto do lado do agente, em o que acontece ao teu agente quando sai quem o montou).
- A explicação começa por «depende». Quando cada passo traz um «depende» e ninguém sabe de quê, há regras por escrever.
- As exceções resolvem-se por telefone ou por mensagem. O que se decide fora do sistema não fica no sistema, e o agente só vê o sistema.
Como se extrai o processo real numa semana?
Não com um questionário nem com uma reunião de duas horas. Com casos reais, observados por alguém que não seja quem executa o trabalho. Um método que cabe em cinco dias:
- Segunda: escolhe um processo e uma pessoa. Um único processo, o que tem mais movimento, e quem o executa todos os dias. Diz-lhe desde o início que não está a ser avaliada: o objetivo é perceber, não auditar.
- Terça: observa casos, não perguntes como se faz. Senta-te ao lado dela enquanto resolve casos reais, incluindo os esquisitos, e anota cada decisão. Uma amostra dos últimos casos vale mais do que qualquer descrição.
- Quarta: pergunta porquê em cada decisão. «Porquê este e não aquele?», «o que teria acontecido com outro valor?». É aqui que saem os critérios que ela achava óbvios.
- Quinta: escreve a regra de negócio, não os cliques. Condição, exceção e a quem se avisa, numa página por processo. O formato está em como documentar automatizações.
- Sexta: confronta com casos que ela não viu. Dá-lhe casos novos sem lhe mostrar a regra e compara a decisão dela com o que ficou escrito. Cada diferença é uma regra que faltava.
| O que diz a versão oficial | O que a pessoa faz na realidade | Como vem ao de cima |
|---|---|---|
| «Cruzo o extrato com as faturas» | Agrupa pagamentos, aplica descontos combinados de viva voz e deixa certos clientes em espera | Observando casos reais, em vez de os ouvir descritos |
| «Aprova-se se cumprir a política» | Aprova coisas fora da política quando conhece o cliente | Perguntando porquê em cada exceção |
| «Revê-se antes de enviar» | Só verifica o que lhe cheira mal, por uma intuição que não sabe nomear | Dando-lhe casos novos e comparando a decisão dela com a regra escrita |
Repara na última coluna: em nenhum caso a solução é perguntar mais, é olhar mais. Quem descreve o seu trabalho descreve o ideal; quem o faz à tua frente mostra o real. E o real é o único que um agente vai encontrar na segunda de manhã, com os casos que ninguém previu na reunião de arranque.
E se, ao documentar, descobres que não convém automatizar?
Acontece mais do que se admite. Ao documentar aparecem incoerências entre pessoas, passos de que ninguém se lembra do motivo e decisões que dependem de um juízo que não se deixa reduzir a regras. Daí saem três caminhos: simplificar o processo antes de mexer em seja o que for, automatizar apenas a parte que já é regra e deixar a parte de juízo nas mãos de uma pessoa, ou decidir que esse processo não é para um agente (o raciocínio de fundo está em quando não automatizar com IA). Qualquer um dos três sai mais barato do que descobri-lo com o agente já em produção.
E a parte de juízo não desaparece: define quanta autonomia podes dar ao agente. Decide-se com os níveis de autonomia de um agente, e só se pode decidir se souberes primeiro onde está o juízo.
Quando não compensa documentar primeiro o processo?
Quando o processo é curto, reversível e barato de errar: três passos, sem dinheiro nem dados pessoais pelo meio. Aí experimenta-se diretamente e corrige-se pelo caminho. Também não compensa documentar com tanto detalhe um processo que muda todos os meses; nesse caso escrevem-se os princípios estáveis, não cada passo (mais em automatizar um processo que muda todos os meses).
Se tens vários candidatos e não sabes por qual começar, auditar os teus processos para IA responde primeiro a qual merece o esforço; o exercício desta semana é o que fazes a seguir, com o escolhido.
A linha para levares: o processo que vais automatizar não é o do manual, é o que a pessoa executa, e enquanto esse não estiver escrito, o agente constrói-se sobre um palpite.
Fontes (consultadas a 28 de outubro de 2026): «The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed», RAND Corporation (2024), usada de forma qualitativa. O cenário inicial é ilustrativo, não um caso real.