Como medir um agente de IA: as métricas que importam

Pergunte qual é a taxa de automatização de um agente e obterá normalmente um número seguro. Pergunte o que aconteceu ao custo total do processo, à taxa de erro ou ao tempo de ciclo e a resposta será muito menos segura e, frequentemente, indisponível — porque ninguém mediu o processo antes de o agente chegar.

Este é o problema central de medição nas implementações de agentes. As métricas fáceis de produzir são as que o agente gera acerca de si mesmo: quantos itens processou, que proporção tratou sem envolvimento humano, a sua confiança média. São entradas, não resultados. Um agente pode reportar uma taxa de automatização elevada enquanto o custo total do processo se mantém inalterado, porque o trabalho passou para uma fila de escalamento que ninguém conta.

As métricas que importam são as que dizem respeito ao processo, não ao agente. São mais difíceis de recolher, exigem uma linha de base captada antes da implementação e são a única base sobre a qual alguém pode dizer honestamente se a coisa funcionou.

Por que é que isto importa

A medição determina três resultados que chegam todos mais tarde do que a implementação.

Se o agente sobrevive ao seu primeiro mês mau. Todos os agentes têm um. Se a única evidência disponível for uma taxa de automatização, uma única falha visível domina a conversa. Se conseguir mostrar tempo de ciclo a descer, taxa de erro a descer e custo por transação a descer ao longo de dois trimestres, um incidente fica contextualizado em vez de decisivo.

Se melhora. A melhoria exige saber que casos falham e por que motivo. Uma implementação que mede apenas a taxa de automatização agregada não tem mecanismo de melhoria, porque o número não se decompõe em nada acionável.

Se o próximo é financiado. Os programas de agentes são normalmente sequenciais — um processo, depois outro. O segundo é financiado com a evidência do primeiro, e «automatizámos 85% da correspondência» é um argumento mais fraco perante uma comissão financeira do que uma alteração demonstrada no custo por transação e no tempo de ciclo.

Há um risco inverso que vale a pena nomear. Uma má medição também pode fazer com que uma implementação genuinamente fraca pareça bem-sucedida durante tempo suficiente para ser prolongada, o que é mais caro do que uma falha honesta e precoce.

Num relance: as camadas de métricas

A camada que mais frequentemente falta por completo é a saúde da passagem de trabalho, que é precisamente onde uma implementação em falência se esconde. Um agente com uma taxa de automatização elevada e uma fila de escalamento crescente e a envelhecer não reduziu trabalho — concentrou o trabalho difícil num só lugar e deixou de o contar.

O que funciona e sobre o que ser honesto

O que funciona:

Uma linha de base captada antes de se construir qualquer coisa. Tempo de ciclo, custo por transação, taxa de erro e volume durante pelo menos um período completo, idealmente dois. É a atividade mais barata e mais frequentemente saltada de toda a implementação e, sem ela, cada afirmação subsequente é uma asserção.

O custo total do processo, incluindo escalamentos. O denominador honesto é todo o tempo humano gasto no processo — supervisão do agente, resolução de escalamentos, monitorização e o ajuste periódico. As implementações que contam apenas a parte automatizada reportam poupanças que não aparecem no orçamento de ninguém.

Revisão por amostragem das ações automatizadas, de forma permanente. Os escalamentos são revistos porque exigem atenção. As ações automatizadas não, e é exatamente por isso que os erros aí são encontrados tarde. Uma pequena amostra permanente é a única forma de detetar degradação silenciosa.

Taxa de erro dividida por consequência, não apenas por contagem. Dez itens de baixo valor mal classificados e um pagamento a fornecedor erradamente redirecionado não são comparáveis. Pondere pelo impacto ou a métrica vai induzir em erro.

Precisão do escalamento como métrica de primeira ordem. A proporção de escalamentos que se revelaram problemas genuínos. Precisão baixa significa que as pessoas estão a revisar não-problemas, o que destrói a atenção dada à fila e é invisível em todas as outras métricas.

Sobre o que ser honesto:

Sem uma linha de base, não consegue provar o valor e provavelmente não a obterá retrospetivamente. Reconstruir de memória o tempo de ciclo anterior à implementação produz um número moldado por quem quer que a implementação tenha sido um sucesso. Aceite que alguns benefícios serão indemonstráveis e seja franco sobre quais.

Os resultados de negócio são multicausais. Os dias até ao pagamento melhoraram — mas também alterou condições, acrescentou um segmento de clientes e perdeu um pagador lento. Reclamar toda a melhoria para o agente é a forma mais rápida de perder credibilidade junto de um CFO. Atribua de forma conservadora e diga o que mais mudou.

Parte do benefício é real e não mensurável. Consistência, auditabilidade, resiliência à ausência de pessoal e a remoção de trabalho que as pessoas achavam desmoralizante. Estas coisas importam e não aparecem numa métrica de custo. Enuncie-as como qualitativas em vez de as converter em números inventados.

A taxa de automatização pode ser manipulada sem que ninguém tenha essa intenção. Afrouxar limiares aumenta-a. Estreitar o âmbito aos casos fáceis aumenta-a. Nenhuma das duas coisas melhora o processo. Se for reportada, reporte-a ao lado da taxa de erro e da precisão do escalamento, para que não possa mover-se sozinha.

A medição tem um custo. Instrumentar tudo o que consta desta lista é desproporcionado para uma implementação pequena. Escolha as camadas que correspondem ao que está em jogo — qualidade do agente, saúde da passagem de trabalho e um resultado de processo são um mínimo defensável.

Quadro de decisão: construir a medição

Percorra por ordem. Pare na primeira correspondência.

1. Tem uma linha de base anterior à implementação?
Se o agente ainda não está em produção, capte uma agora — um ou dois períodos completos de tempo de ciclo, custo, volume e taxa de erro. Se já está em produção, reconstrua o que puder, rotule-o como estimativa e comece a medir corretamente a partir de hoje em vez de discutir sobre o passado.

2. Está a medir algo além da atividade do agente?
Se a taxa de automatização e o volume são tudo o que tem, acrescente a taxa de erro nas ações automatizadas e a profundidade da fila de escalamento. Essas duas transformam um dashboard que não pode falhar num que pode.

3. A saúde da passagem de trabalho está instrumentada?
Se não, esta é a prioridade: profundidade da fila, antiguidade, tempo até à resolução, proporção dentro do objetivo. É aqui que uma implementação em falência se torna visível primeiro.

4. Está a amostrar ações automatizadas para verificar se estão corretas?
Se não, inicie uma pequena amostra permanente. Revisar apenas escalamentos significa que está a verificar os casos sobre os quais o agente já sabia que estava incerto.

5. Consegue indicar o custo total do processo incluindo todo o tempo humano?
Se não, construa esse número. É o que uma comissão financeira vai pedir e o que determina se a próxima implementação é financiada.

6. Tem uma revisão mensal que categorize as resoluções dos escalamentos?
Se não, agende-a com um responsável identificado. Sem ela, o desempenho do agente fica estático desde o arranque.

7. Tudo o que está acima, os números parecem bons, mas ninguém acredita neles?
A questão é de transparência e não de medição. Publique o método, as ressalvas e o que não consegue atribuir. A confiança num número vem mais das limitações declaradas do que da sua dimensão.

Custo e esforço indicativos

Pressupõe um agente num processo com dados disponíveis no ERP ou na plataforma de integração. Peça um orçamento para uma estimativa delimitada.

Perguntas frequentes

Que métrica única devemos reportar ao conselho de administração?
Custo por transação e tempo de ciclo, com a taxa de erro ao lado para que não se possa mostrar eficiência sem qualidade. Se só uma, o tempo de ciclo — é mais difícil de manipular e está correlacionado com a maior parte dos benefícios que às pessoas realmente interessam.

Quanto tempo passa até os números significarem algo?
A qualidade do agente e a saúde da passagem de trabalho tornam-se significativas em quatro a seis semanas. Os resultados de processo precisam de um a dois trimestres. Os resultados de negócio — dias até ao pagamento, dias até ao fecho — normalmente dois a três trimestres, porque são lentos e precisam de um período limpo depois de a implementação assentar.

Devemos medir contra um objetivo ou contra a linha de base?
Contra a linha de base, principalmente. Os objetivos fixados antes da implementação são adivinhas, e falhar um objetivo arbitrário numa implementação que melhorou materialmente o processo produz a conversa errada.

E se o agente estiver a funcionar mas os números não se mexeram?
As causas habituais são a parte automatizada não ter sido a restrição, o trabalho ter passado para uma fila de escalamento não contabilizada, ou um problema a montante dominar. As três são conclusões que vale a pena ter, e as três são invisíveis se apenas medir a taxa de automatização.

Precisamos de uma ferramenta de analítica separada?
Normalmente não, à escala mid-market. A maior parte destas métricas pode ser derivada do ERP e dos registos da própria plataforma de integração. A lacuna é normalmente o modelo de custo do processo e a revisão por amostragem, e nenhum dos dois é um problema de ferramentas.

Com que rapidez conseguimos ligar os dados subjacentes o suficiente bem para medir isto?
Mais rápido do que a maioria das equipas assume para a parte da ligação — um parceiro certificado como Stacksync pode ter em semanas a sincronização em tempo real que alimenta as métricas de um agente. A parte mais lenta é acordar quais das métricas acima realmente importam para o seu agente antes de começar a medir, para não acabar a produzir números limpos sobre as coisas erradas.

Fecho — Próximos passos

A métrica de agente que é reportada é quase sempre a que o agente produz acerca de si mesmo, e é a que está menos ligada a saber se a implementação valeu a pena. As medidas úteis situam-se ao nível do processo, precisam de uma linha de base e incluem o trabalho que o agente devolveu.

Se já tem um agente em funcionamento e quer saber em que ponto está: extraia a profundidade da fila de escalamento e o seu perfil de antiguidade, depois extraia o total de horas humanas gastas no processo este mês. Esses dois números, face ao que souber do estado anterior à implementação, dir-lhe-ão mais do que qualquer taxa de automatização.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes mid-market em toda a Ibéria. Especializa-se em ligar sistemas CRM e ERP para fluxos de 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. Como partner oficial de implementação da Stacksync, Bruno concebe e implementa agentes de IA em plataformas de integração para tratar o encaminhamento de exceções, o processamento de documentos e a reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis que se monitorizam a si mesmos.

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

Fontes

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

• APQC, Open Standards Benchmarking — medidas de custo e tempo de ciclo de processos — https://www.apqc.org
• NIST, AI Risk Management Framework — medição e monitorização de sistemas de IA — https://www.nist.gov/itl/ai-risk-management-framework
• Oracle NetSuite, documentação de reporting e saved searches — https://docs.oracle.com/en/cloud/saas/netsuite/
• COSO, Internal Control — Integrated Framework — atividades de monitorização — https://www.coso.org
• Experiência de projetos da Atypical Tech, implementações de agentes no mid-market da Ibéria
• Stacksync, blog da plataforma de integração e sincronização em tempo real — https://www.stacksync.com/blog