Revisão humana e limites de automação: quem decide o quê
Automação não é tudo ou nada. Veja os níveis de automação, onde colocar aprovação humana, como tratar exceções e como parar o fluxo.
Mauricio Zaffari
Considere uma cena ilustrativa. No meio da manhã, o fluxo de conferência de documentos já validou um lote grande de notas; as que passam por todas as validações são registradas no ERP, e a liberação do pagamento segue a aprovação definida no processo. Então chega uma nota em que o total não bate com a soma dos itens. O fluxo não lança. Não adivinha. Para, etiqueta a divergência e coloca o caso na frente de um revisor nomeado.
Essa parada não é uma falha. É o desenho. A decisão é onde o fluxo pode seguir sozinho e onde uma pessoa precisa aprovar, corrigir ou interromper.
Em que nível de automação está rodando
Olhando o conjunto. Equipes costumam discutir IA como um interruptor, tudo manual ou tudo automático, e a discussão trava porque as duas pontas assustam. O fluxo da cena não está em nenhuma delas. Está num ponto da escala:
flowchart TD
N["Nota do fornecedor"] --> V{"Validação de campos e regras"}
V -- bate --> R1["Registrada no ERP; pagamento segue a aprovação do processo"]
V -- diverge --> E["Exceção etiquetada na fila"]
E --> H{"Revisor nomeado decide"}
H -- liberada com correção --> R1
H -- retida --> P["Tratamento fora do fluxo"]
- Manual assistido: a pessoa faz a tarefa e a IA sugere a próxima ação. A pessoa sempre decide.
- Sugestão com revisão: a IA prepara a saída e a pessoa confere antes de seguir. Num piloto, a pessoa confere a saída antes de seguir.
- Automático com verificação: o fluxo anda sozinho quando campos e regras batem, e as divergências vão para revisão. A cena está aqui.
- Automático com exceção: o fluxo anda sozinho e para para uma pessoa só quando encontra um caso que ninguém previu.
Nenhum nível é melhor no abstrato. O nível certo depende do custo do erro, do volume e da maturidade do processo. Um erro num relatório interno custa pouco. Um erro num pagamento custa caro, e é por isso que a nota da cena parou.
Por que o ponto de aprovação está ali
Posicionar o portão é decisão de desenho, não limite da tecnologia. Na cena, três verificações o colocaram ali:
- Consequência: o efeito que não se desfaz com facilidade recebe uma aprovação definida no processo. Onde fica esse portão depende do ERP: se o registro da nota já cria a obrigação de pagamento, a aprovação vem antes do registro; se a obrigação nasce na liberação, o registro pode ser automático. Na cena, o desenho escolhido foi o segundo.
- Reversibilidade: as notas que passam pelas validações andam sozinhas porque a divergência é percebida pela validação, não pela consequência.
- Volume: as divergências são minoria no fluxo, então revisá-las uma a uma pode ser viável se a equipe tiver capacidade. Se fossem a maior parte do volume, o portão seria um gargalo e precisaria de critérios, não de fila.
O portão também precisa de um dono. Se ninguém é responsável por aprovar, o fluxo trava. Se qualquer um pode aprovar, o controle se perde. Na cena, um revisor nomeado responde pela fila.
Para onde a exceção vai em seguida
De volta à nota da cena. A divergência precisa de um destino, e um balde não é um destino. Uma exceção pode ir para uma pessoa que decide na hora, uma fila de revisão com prazo definido, ou uma regra nova, quando o caso se repete o suficiente para virar padrão.
O revisor abre o caso, vê a divergência etiquetada e decide. Digamos que o total esteja deslocado por um valor real, não por arredondamento: o revisor retém a nota, confere a origem e pede uma correção ou uma resolução autorizada antes de liberar, com a decisão registrada. Se o mesmo fornecedor apresentar a mesma divergência repetidas vezes, a repetição pede investigação; quem responde pelo processo decide se há uma regra a documentar, testar e aprovar.
O erro comum é jogar toda divergência no mesmo balde e deixar alguém separar depois. Sem critérios de prioridade, a fila cresce e a confiança no fluxo cai. Combine também quanto tempo uma exceção pode ficar aberta. Caso sem prazo é um erro esperando aparecer em outro lugar.
Quando é o fluxo que precisa parar
Um fluxo automatizado precisa de um botão de parada. Sem um procedimento de parada, uma divergência pode continuar se repetindo. No fluxo de conferência de documentos, se o número de divergências saltar de um punhado para boa parte do lote, alguém pode interromper novas conferências, revisar as regras e inspecionar os casos já registrados antes de retomar.
Parar é metade. Corrigir significa ajustar a regra, separar os casos pendentes dos já registrados e registrar o que mudou. Sem esse registro, o mesmo erro volta e ninguém sabe por quê.
A escolha aqui é deliberada. Preferimos um fluxo que para quando não tem certeza a um que decide rápido e transfere o problema para depois. O primeiro é mais lento em alguns casos e mais confiável no conjunto.
O que replicar da cena
A cena conquista confiança por um motivo, e cada parte dela é uma decisão que você pode copiar:
- o nível de automação foi escolhido pelo custo do erro, não pela ambição do projeto;
- o ponto de aprovação está onde a consequência não se desfaz com facilidade, e tem um dono nomeado;
- cada exceção tem destino, prioridade e prazo;
- o fluxo tem um botão de parada, e a correção fica registrada.
Nenhum desses controles elimina o erro. Sistemas de IA não são livres de erros, e este desenho não finge que são. Os controles definem onde o erro é encontrado e quem responde por ele.
Em resumo
Automação é uma escala, não um interruptor. Antes de automatizar, registre o que segue sozinho, quem aprova as exceções e quem pode parar o fluxo. A discussão deixa de ser se a IA substitui o processo e passa a ser quem aprova o quê.
Se você quer avaliar o nível certo de automação para um processo da sua operação, Solicitar diagnóstico.