Como medir o retorno de um projeto de IA

Meça quatro coisas: horas de trabalho humano devolvidas, tempo de ciclo do processo, taxa de resolução sem intervenção humana e taxa de erro que chega ao cliente. Compare cada uma com uma linha de base coletada antes do projeto. O resto é decoração de apresentação.

Colete a linha de base antes, não depois

Este é o erro que inviabiliza a medição de mais da metade dos projetos: começar sem saber como era antes.

Por duas a quatro semanas, antes de escrever qualquer código, registre:

• Volume, quantas vezes a tarefa acontece por dia ou semana
• Tempo por execução, quanto leva do início ao fim, incluindo espera
• Pessoas envolvidas, quantas e por quanto tempo cada uma
• Taxa de erro atual, quantas execuções precisam de retrabalho
• Fila, quanto tempo o pedido fica esperando alguém pegar

Sem esses números, qualquer resultado vira opinião. E é notável a frequência com que a linha de base revela que o processo custava menos do que se imaginava, o que muda a decisão de investir antes de gastar.

As quatro métricas que importam

1. Horas devolvidas por semana. A mais direta e a mais difícil de maquiar. Se a triagem consumia 15 horas semanais de duas pessoas e passou a consumir 4, foram 11 horas devolvidas.

A ressalva honesta: hora liberada só vira dinheiro se for realocada. Se ninguém foi remanejado e ninguém deixou de contratar, o ganho é de conforto, não financeiro. Diga isso com clareza no relatório em vez de converter tudo em reais automaticamente.

2. Tempo de ciclo. Do pedido à conclusão, incluindo espera. É o número que o cliente sente. Um processo que levava 2 dias e passa a levar 3 horas melhora a experiência mesmo que ninguém economize hora nenhuma.

3. Taxa de resolução sem humano. Percentual de casos concluídos de ponta a ponta pelo sistema, com o problema efetivamente resolvido. Não confunda com "conversas encerradas": cliente que desiste também encerra a conversa.

4. Taxa de erro que chega ao cliente. Quantos casos saíram errados sem serem pegos na revisão. É a métrica que segura as outras três, sem ela, dá para inflar a resolução automática à custa de qualidade.

Métricas de vaidade

A pior de todas é acurácia medida em perguntas escritas pela própria equipe do projeto. Perguntas reais são mais bagunçadas, ambíguas e fora do escopo do que qualquer conjunto criado em sala.

Como montar a conta de retorno

Estrutura simples e defensável:

Ganho anual = (horas devolvidas por semana × 48 × custo/hora carregada) + ganho de tempo de ciclo convertido em receita ou perda evitada

Custo anual = desenvolvimento amortizado + infraestrutura + custo de modelo por uso + manutenção + horas de acompanhamento de qualidade

Três cuidados que separam uma conta honesta de uma peça de vendas:

• Custo de modelo é variável. Ele cresce com o uso. Estime com base no volume real medido, não no volume do piloto.
• Manutenção existe sempre. Base a atualizar, integrações que mudam, prompts a ajustar, avaliações a rodar. Reserve uma fatia recorrente.
• Custo carregado, não salário. Encargos, ferramentas e estrutura entram na hora da pessoa.

Métricas específicas por tipo de projeto

Assistente de conhecimento (RAG): taxa de resposta correta com fonte certa, taxa de recusa apropriada (quando não sabe, admite), consultas que geraram escalonamento.

Agente com tool-use: taxa de escolha da ferramenta certa, taxa de parâmetros válidos, ações executadas indevidamente (deve ser zero em ações críticas), passos médios por tarefa concluída.

Extração de documentos: acurácia por campo, não por documento. Um documento com 20 campos e 1 errado é "95% correto" e "100% precisa de revisão" ao mesmo tempo, o segundo número é o que decide se houve ganho.

Triagem e classificação: matriz de confusão por categoria. Erro concentrado em uma categoria é problema de definição, não de modelo.

O horizonte realista

Projetos de automação com volume alto e tarefa bem delimitada mostram sinal em 4 a 12 semanas depois da estabilização. Antes disso você está medindo o período de calibração, quando erros são frequentes e a equipe ainda está ajustando a base.

Projetos que dependem de mudança de comportamento de muitas pessoas demoram mais e falham mais, não por limitação técnica, mas por adoção. Nesses casos, meça adoção recorrente antes de tentar medir retorno financeiro.

Quando admitir que não deu

Um bom sistema de medição também precisa dizer não. Sinais claros de que o projeto não vai se pagar:

• A taxa de resolução sem humano estabilizou abaixo do esperado depois de três ciclos de correção
• O custo de revisão das saídas ficou igual ao custo do trabalho original
• O volume real da tarefa é bem menor do que o estimado no início
• A base de conhecimento exige mais manutenção do que o processo antigo consumia

Encerrar cedo um projeto que não vai andar é uma decisão boa, não um fracasso. Nos projetos que acompanhamos na Retti Tech, os que dão retorno claro têm quase sempre o mesmo perfil: escopo estreito, volume alto, erro barato e uma linha de base medida antes de qualquer linha de código. Os que patinam costumam ter escopo largo e nenhum número anterior para comparar.