Handoffs de agentes de IA: desenhar o escalamento humano

Todos os projetos de agentes em que trabalhámos acabaram por girar em torno da mesma pergunta, e nunca é aquela que o cliente esperava. Não é o que o agente consegue fazer. É o que faz quando chega a algo que não deveria decidir.

Essa pergunta é adiada porque não tem glamour. Uma demonstração mostra o percurso ideal — o agente lê o documento, faz a correspondência da transação, envia o aviso. Ninguém demonstra o caso ambíguo, portanto ninguém o desenha, e o agente entra em produção com o escalamento tratado como assunto secundário: uma fila, um alerta por email, uma marca num registo. Ao fim de um mês essa fila tem várias centenas de itens, nenhum responsável e nenhum tempo de resolução definido. Tecnicamente, o agente está a funcionar. O processo não.

O desenho do handoff é a diferença entre um agente que reduz trabalho e um que o desloca para outro lado. A deslocação é pior do que o estado original, porque um processo manual tinha, pelo menos, alguém responsável em cada passo.

Por que razão isto importa

Uma fila de escalamentos não resolvidos falha de três formas ao mesmo tempo, e essas falhas somam-se.

O trabalho não é feito. Os itens de uma fila sem responsável envelhecem. Nos processos financeiros, envelhecer tem consequências — uma exceção de reconciliação não resolvida transforma-se num atraso do fecho, uma questão sobre uma fatura não resolvida transforma-se numa conta a pagar vencida, uma exceção de encomenda não resolvida transforma-se num cliente que não recebeu a sua mercadoria.

A confiança no agente desmorona-se com base nas provas erradas. Quando algo corre mal, a falha é atribuída ao agente, ainda que o agente se tenha comportado corretamente ao escalar. O que falhou foi o handoff. Mas a memória da organização registou "a IA errou", o que torna mais difícil financiar o projeto seguinte.

Ninguém aprende nada. Um handoff bem desenhado produz informação: que casos o agente não conseguiu resolver, porquê, como uma pessoa os resolveu e se essa resolução poderia ser codificada. Um handoff mal desenhado produz uma fila. O primeiro melhora o agente todos os meses; o segundo garante que as mesmas exceções se repetem indefinidamente.

Existe também uma dimensão de governação que importa em ambientes regulados e auditados. Se não conseguir demonstrar onde está a fronteira entre a decisão automatizada e a decisão humana, e evidenciar que essa fronteira se manteve, tem uma deficiência de controlo — independentemente de o agente já ter errado alguma vez.

Num relance: os quatro gatilhos de handoff

A maioria das implementações constrói o primeiro e descura os outros três. Os limites de confiança são os mais fáceis de raciocinar e os menos suficientes por si só. Um agente pode estar inteiramente confiante quanto a uma ação que não lhe compete de forma alguma — pagar uma fatura acima de um limite delegado, alterar os dados bancários de um fornecedor, libertar uma encomenda para um cliente com o crédito bloqueado. Isso é uma fronteira de autoridade, e a confiança é irrelevante para ela.

O gatilho de consequência é aquele a que os clientes mais resistem, porque significa escalar deliberadamente casos que o agente provavelmente resolveria bem. É precisamente esse o objetivo. Quando o prejuízo de uma ação errada é grande e assimétrico, "provavelmente bem" não é o critério.

O que funciona e sobre o que ser honesto

O que funciona:

Um responsável humano com nome por tipo de escalamento, não por fila. "A área financeira revê as exceções" não é responsabilidade. Uma pessoa, com um substituto, e um tempo de resposta definido. Onde o volume o justifique, uma escala rotativa — mas sempre a resolver-se num indivíduo.

Escalamentos que chegam com o raciocínio do agente anexado. O maior determinante isolado da velocidade de resolução. O que o agente estava a tentar fazer, o que encontrou, o que considerou, por que razão parou e as resoluções candidatas ordenadas. Um escalamento que diz "requer revisão manual" desperdiça o trabalho que o agente já fez.

Um caminho de resolução definido, não apenas um destino. Cada tipo de escalamento precisa de um responsável, de um tempo-alvo, de um conjunto de ações e de uma regra para o que acontece quando o alvo não é cumprido. Sem esta última, a fila absorve as falhas em silêncio.

Resoluções devolvidas como sinal de treino. Cada resolução humana é ou um caso que o agente poderia ter tratado com melhores regras, ou um juízo genuíno que deve escalar sempre. Categorizar as resoluções nesses dois grupos todos os meses é o que faz um agente melhorar. A maioria dos projetos nunca o faz.

O volume de escalamentos como métrica monitorizada. Ambas as direções importam. Um volume a subir significa que o agente está a degradar-se ou que a distribuição das entradas mudou. Um volume a descer não é automaticamente bom — pode significar que os limites foram afrouxados para além do ponto seguro.

Sobre o que ser honesto:

O desenho do escalamento custa mais do que a lógica de correspondência. Frequentemente é a maior parte da construção. Os clientes subestimam isto de forma consistente e é aí que a pressão sobre o âmbito aterra primeiro. Protegê-lo é o principal fator que distingue os projetos que sobrevivem ao seu segundo ano.

A deteção de anomalias é genuinamente difícil. Detetar uma falha é simples; detetar que um caso não se parece com nada visto antes não é, e nenhuma abordagem atual é fiável. A mitigação prática são fronteiras conservadoras de autoridade e de consequência, que apanham os casos novos como efeito secundário.

As pessoas deixam de ler filas em que não confiam. Se uma fila contém uma proporção elevada de não problemas, os revisores começam a despachá-la mecanicamente, e a exceção genuína na posição quarenta é despachada com as restantes. A precisão da fila importa mais do que a sua exaustividade.

Alguns escalamentos não devem ir a lado nenhum. Não é preciso resolver todas as exceções. Alguns casos são melhor abatidos, tolerados ou agrupados trimestralmente. Encaminhar tudo para uma pessoa trata todas as exceções como se merecessem igualmente tempo humano, e não é o caso.

A fronteira precisa de ser renegociada periodicamente. À medida que um agente acumula evidência, algumas decisões podem passar da pessoa para o agente — mas isso deve ser uma alteração deliberada, documentada e revisível, não uma deriva de limites que ninguém aprovou.

Quadro de decisão: desenhar o handoff

Percorra pela ordem indicada. Pare na primeira correspondência.

1. Já deixou escrito quais são as decisões que o agente nunca pode tomar?
Comece aqui, antes de construir. As fronteiras de autoridade derivam da política de delegação, não da capacidade técnica, e devem ser impostas na configuração para que não possam ser atravessadas por uma alteração de limite.

2. Cada tipo de escalamento tem um responsável individual com nome e um tempo-alvo de resolução?
Se não, atribua ambos. Um caminho de escalamento que termina numa caixa de correio partilhada ou no nome de uma equipa não é um caminho.

3. Os escalamentos transportam o raciocínio do agente e as resoluções candidatas?
Se não, corrija a apresentação antes de afinar a correspondência. Habitualmente é a maior melhoria disponível no tempo total de processo e é rotineiramente ignorada em favor da taxa de correspondência.

4. Tem uma regra definida para quando o tempo-alvo de resolução não é cumprido?
Se não, defina-a: escalar para um segundo responsável, alertar um gestor ou aplicar uma ação por omissão. Sem isto, o seu caminho de escalamento não tem chão.

5. Está a categorizar as resoluções em "deveria ter sido automatizada" e "corretamente escalada"?
Se não, inicie uma revisão mensal. Este é o mecanismo pelo qual o agente melhora, e saltá-lo significa pagar eternamente pelas mesmas exceções.

6. Está a monitorizar o volume e a precisão dos escalamentos em ambas as direções?
Instrumente os dois. Acrescente um alerta para qualquer alteração material em qualquer um deles, em qualquer direção.

7. Tem tudo o anterior no lugar e a fila continua a crescer?
O seu problema está a montante. Uma fila que cresce de forma persistente significa que a qualidade das entradas se está a deteriorar ou que o âmbito do agente excede o que as suas regras conseguem suportar — nenhum dos dois se resolve acrescentando revisores.

Custo e esforço indicativos

Pressupõe um único agente sobre um processo. Os projetos com vários agentes exigem uma camada adicional que decida a que agente pertence um escalamento, o que acresce de forma significativa. Peça um orçamento para uma estimativa delimitada.

Perguntas frequentes

Qual é o limite de confiança correto?
Não há uma resposta geral, porque depende da assimetria de custo entre os seus dois tipos de erro. Quando uma ação errada é dispendiosa e uma ação atrasada é barata — pagamentos a fornecedores, comunicação com o cliente —, fixe-o alto. Quando se passa o contrário, baixe-o. Derive o número das consequências, não das estatísticas de desempenho do agente.

Um agente pode escalar para outro?
Sim, e é muitas vezes sensato — um agente de documentos que passa uma discrepância de preço a um agente de encomendas. Mas toda a cadeia tem de terminar numa pessoa dentro de um número limitado de passos, e a cadeia tem de ser registada de ponta a ponta. O escalamento circular entre agentes é um modo de falha real e precisa de uma salvaguarda explícita.

Como evitamos que os revisores validem a fila sem a ler?
Mantenha a precisão elevada para que a fila seja sobretudo genuína, mantenha o volume dentro da capacidade real, torne visível a responsabilidade individual e audite uma amostra de resoluções. Validar sem ler é um sintoma de uma fila demasiado grande ou demasiado ruidosa, não de pessoas distraídas.

Um auditor precisa de ver isto?
Em ambientes auditados, sim — conte com perguntas sobre onde está a fronteira automatizado/humano, como é imposta e como evidencia que se manteve. Documente a fronteira, o mecanismo de imposição e a pista de auditoria antes de a pergunta chegar.

E se, no início, o agente escalar quase tudo?
Esse é o estado inicial correto. Comece conservador, reúna evidência e mova a fronteira de forma deliberada. Os projetos que começam permissivos e apertam depois de um incidente perdem uma confiança organizacional difícil de recuperar.

Com que rapidez pode ser construído o lado de sistemas de uma passagem como esta?
Normalmente mais rápido do que o trabalho de conceção acima. Um parceiro certificado como Stacksync pode pôr em produção em semanas a sincronização em tempo real de que depende uma passagem de escalonamento. A parte mais lenta é decidir, como este artigo aborda, exatamente quando um agente deve parar e a quem passa — isso é uma decisão de política, não de integração.

Fecho — Próximos passos

O instinto com os agentes é medir quanto tratam de forma autónoma. A medida mais útil é o que acontece ao restante — porque é aí que está o risco, é de onde vem a aprendizagem e é onde o processo se mantém ou se desfaz em silêncio.

Um ponto de partida prático num agente já em funcionamento: tome uma semana de escalamentos e, para cada um, identifique o responsável, o tempo até à resolução e se essa resolução poderia ter sido uma regra. Se não conseguir nomear um responsável para cada um deles, essa é a conclusão, e importa mais do que a taxa de correspondência do agente.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes mid-market em toda a Península Ibérica. Especializa-se em ligar sistemas CRM e ERP para fluxos order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comerciais e financeiras. Enquanto partner oficial de implementação da Stacksync, Bruno desenha e coloca em produção agentes de IA sobre plataformas de integração para tratar do encaminhamento de exceções, do processamento de documentos e da reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis que se monitorizam a si próprios.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são a nível de editor e devem ser verificados antes da publicação.

• NIST, AI Risk Management Framework — supervisão humana e responsabilização — https://www.nist.gov/itl/ai-risk-management-framework
• Comissão Europeia, EU AI Act — obrigações de supervisão humana — https://digital-strategy.ec.europa.eu
• Comité Europeu para a Proteção de Dados, orientações sobre decisões automatizadas — https://www.edpb.europa.eu
• COSO, Internal Control — Integrated Framework — desenho de controlos e delegação de autoridade — https://www.coso.org
• Experiência de projetos da Atypical Tech, implementações de agentes em mid-market na Península Ibérica
• Stacksync, blog da plataforma de integração e sincronização em tempo real — https://www.stacksync.com/blog