Antes de automatizar, vale entender o que sua operação realmente faz

Quando a operação depende de exceção, improviso e critério que ninguém formalizou, AI e automação não resolvem. Só aceleram o que já estava frágil.

Existe uma situação que aparece com frequência em organizações que estão em estágio de escala: a liderança decide que chegou a hora de "trazer AI para dentro". Contrata consultoria, escolhe ferramentas, aloca budget. Algumas semanas depois, a automação está no ar. E a operação continua igual. Ou pior.

O diagnóstico costuma ser atribuído à ferramenta errada, ao time resistente ou à implementação apressada. Raramente aponta para o problema real: a operação que foi automatizada não tinha forma definida para começar.

A ilusão do processo documentado

A maioria das organizações que chegam a um projeto de automação tem algum nível de documentação. Tem playbooks, tem SOPs, tem fluxogramas desenhados em workshops. O problema é que esses documentos descrevem como o processo deveria funcionar, não como ele funciona de fato.

O processo real vive em outro lugar: nos acordos tácitos entre pessoas, nas exceções que viraram rotina, nas decisões que são tomadas "no olho" porque quem criou a regra já saiu da empresa. Quando alguém novo entra, aprende o processo na prática. Quando alguém experiente sai, leva o critério junto.

Esse fenômeno tem nome: ambiguidade operacional. E ela não é um problema de cultura nem de disciplina. É um problema estrutural que emerge naturalmente em organizações que cresceram rápido, priorizaram entrega sobre sistematização e postergaram a formalização dos critérios que sustentam as decisões cotidianas.

A ambiguidade operacional não é visível no organograma. Ela aparece no padrão de escalações, na variação entre como times diferentes executam a mesma tarefa, na concentração de decisão em uma ou duas pessoas que "entendem como as coisas funcionam aqui".

O que acontece quando você automatiza ambiguidade

Automação é, em essência, a codificação de um critério de decisão. Para funcionar, o critério precisa existir e estar suficientemente explicitado. Quando a organização tenta automatizar um processo que opera por improviso, uma de duas coisas acontece:

A primeira: a automação funciona para os casos fáceis — os 70% que seguem o fluxo padrão — e quebra nos outros 30%, que são justamente os casos onde o valor das operações está concentrado. Esses casos seguem para a fila de exceção, que é tratada manualmente. O que muda é que agora a exceção é visível e monitorada, mas não está resolvida.

A segunda: a automação funciona em produção, mas produz resultados que ninguém consegue explicar nem auditar. A lógica foi codificada por quem desenvolveu a ferramenta com base em uma descrição do processo, não no processo real. Os resultados ficam certos quando o input está dentro do esperado e erram de forma opaca quando não está.

Em ambos os cenários, o custo não é só técnico. É o custo de ter investido em automação sem ter criado a condição que tornaria a automação útil.

Por que AI torna esse problema mais urgente, não mais simples

Modelos de linguagem e ferramentas generativas de AI introduziram uma camada nova de complexidade nessa equação. Elas parecem resolver o problema da ambiguidade porque conseguem lidar com linguagem natural, variação de input e contexto incompleto. Na prática, isso cria uma falsa sensação de que o critério não precisa ser explicitado, a AI "entende" o que você quer dizer.

O problema é que "entender" não é o mesmo que "decidir de forma consistente com os critérios da organização". Um modelo de linguagem aplicado a um processo ambíguo vai tomar decisões. Vai tomar muitas decisões por dia. E vai tomá-las com base em padrões que inferiu do material disponível, que pode ser a documentação desatualizada, os exemplos que você forneceu e o comportamento dos casos de teste que você escolheu.

Quando essa inferência está alinhada com o que a organização quer, parece que está funcionando. Quando não está, o problema é difícil de diagnosticar porque a AI não explicita suas premissas. A ambiguidade que antes estava distribuída entre pessoas agora está codificada em um modelo que opera em escala e sem fricção.

O resultado prático: o volume de decisões problemáticas aumenta proporcionalmente ao volume total de decisões. AI em operação imatura não resolve o problema, ela o industrializa.

Como identificar se sua operação tem ambiguidade crítica

Antes de qualquer projeto de automação ou AI, vale fazer um diagnóstico honesto da maturidade operacional. Os sinais mais indicativos não estão nas ferramentas — estão no comportamento das pessoas e nos padrões de decisão.

O critério está concentrado em pessoas, não em regras. Se você perguntar "como decidimos X?" e a resposta for um nome próprio — ou uma lista de nomes —, o critério não está na organização. Está em indivíduos. Quando essa pessoa sai ou está sobrecarregada, o processo oscila.

A exceção virou o padrão. Em toda operação existe um fluxo esperado e um fluxo de exceção. Quando mais de 20–30% das ocorrências vão para o fluxo de exceção, isso não é mais exceção. É sinal de que o fluxo principal não foi desenhado para a realidade que a organização enfrenta.

O processo documentado diverge do processo executado. Peça para duas pessoas do mesmo time descreverem como executam a mesma tarefa. A distância entre as duas descrições é uma medida direta de ambiguidade. Se as descrições coincidem com o que está documentado, você tem um processo estável. Se divergem — entre si ou em relação à documentação —, você tem critério tácito em operação.

Decisões de escopo ou prioridade são feitas "no feeling". Quando não há critério explícito para decidir o que entra ou não em escopo, o que priorizar ou o que pausar, as decisões são tomadas por quem tem mais influência ou mais urgência no momento. Isso produz resultados inconsistentes e cria dependência de liderança para decisões que deveriam ser operacionais.

A operação depende de comunicação lateral não estruturada. Se o WhatsApp, o Slack ou e-mails são o mecanismo de sincronização principal entre etapas do processo — e não uma exceção para alinhamentos pontuais —, é sinal de que o handoff entre etapas não está resolvido no design do processo.

O que precisa acontecer antes de automatizar

A reorganização não é necessariamente longa. Em muitos casos, três a seis semanas de diagnóstico e redesenho criam condição suficiente para uma automação funcionar. O que não é possível é pular essa etapa.

O trabalho tem quatro movimentos:

Primeiro: tornar o processo real visível. Isso exige observação direta — entrevistas com quem executa, análise de dados de execução, mapeamento das variações. O objetivo não é produzir um fluxograma bonito. É entender onde o critério está concentrado, onde a exceção é frequente e onde a decisão é opaca.

Segundo: explicitar o critério de decisão. Para cada ponto de decisão no processo, a pergunta é: com base em quê essa decisão é tomada? A resposta precisa ser formalizada de forma que possa ser verificada, ensinada e contestada. Critério implícito não é critério — é dependência de pessoa.

Terceiro: estabilizar o fluxo principal antes de escalar. Um processo que tem taxa de exceção elevada não está pronto para automação. O trabalho aqui é entender por que as exceções existem e redesenhar o fluxo para absorver as variações mais frequentes. O objetivo é reduzir a proporção de exceções para um nível gerenciável antes de codificar qualquer lógica.

Quarto: definir o que será automatizado e o critério de sucesso. Automação deve começar pelo ponto de maior volume e menor variação — não pelo ponto mais visível ou mais urgente. E o critério de sucesso precisa ser definido antes da implementação: qual métrica vai indicar que a automação está funcionando? Qual variação é aceitável? Quem monitora?

A implicação organizacional que raramente é dita

Projetos de automação e AI costumam ser vendidos — e comprados — como iniciativas técnicas. Mas o trabalho real de preparar uma operação para automação é organizacional. Exige que a liderança aceite olhar para o que a operação realmente faz — não para o que deveria fazer. Exige conversas sobre critérios que às vezes revelam inconsistências entre áreas ou entre o que está escrito e o que está sendo feito.

Esse é frequentemente o ponto de resistência real. Não a tecnologia. Não o time. A disposição de tornar explícito o que estava confortavelmente implícito.

Organizações que passam por essa etapa — mesmo que de forma parcial — têm resultados consistentemente melhores em automação. Não porque encontraram a ferramenta certa. Porque criaram a condição para que qualquer ferramenta funcione.

Para quem está considerando um projeto de AI ou automação nos próximos meses

As perguntas que valem ser respondidas antes de escolher ferramenta ou contratar implementação:

• Seu time consegue descrever, de forma consistente, como o processo funciona — incluindo quem decide o quê e com base em quê?
• Qual é a taxa de exceção atual nos processos que você quer automatizar?
• Se você mapeasse as últimas 50 execuções desse processo, quantas teriam seguido o fluxo padrão do início ao fim?
• O critério de decisão que você quer codificar está documentado de forma que possa ser contestado e revisado?

Se as respostas forem vagas ou incertas, o projeto de automação provavelmente vai precisar de uma etapa anterior que não está no escopo contratado.

Essa etapa é o diagnóstico operacional. E ela é mais barata — e mais rápida — do que refazer uma automação que não funcionou.

A Espiral 12 trabalha com diagnóstico e reorganização operacional para organizações que estão em processo de escala. Se você está avaliando um projeto de AI, automação ou reestruturação de processos e quer entender o que precisa estar resolvido antes de começar, podemos conversar.

→ Solicitar diagnóstico operacional