O piloto de IA foi bem na demo. Como saber se ele serve antes de escalar?

Em 1 minuto

Uma demo mostra o que a IA consegue fazer com exemplos escolhidos. Um piloto precisa responder a outra pergunta: se faz o trabalho de todo dia melhor, mais barato ou mais rápido do que é feito hoje, com os casos que de fato chegam. Para saber isso, são necessárias três coisas, e convém fixá-las antes de começar: quanto custa e quanto demora o trabalho hoje, uma amostra de casos reais — incluídos os difíceis — e critérios escritos que digam qual resultado leva a escalar, a ajustar ou a parar.

Imagine uma empresa de serviços que recebe todo dia centenas de solicitações de clientes: dúvidas sobre faturas, mudanças de dados, declarações. É fictícia, mas se parece com muitas. Uma equipe de cinco pessoas as lê, classifica e redige a resposta.

Um fornecedor propõe um piloto de IA: o sistema classifica cada solicitação e deixa uma resposta pronta para que uma pessoa a revise e envie. Na demo, diante do comitê, a IA resolve vinte exemplos sem um tropeço. As respostas são claras, o tom é correto e tudo leva segundos. Alguém pergunta: «quando colocamos isso para todo mundo?».

É a pergunta natural. E é a que convém não responder ainda, porque a demo não trouxe os dados para respondê-la.

Este artigo é para quem precisa aprovar — ou frear — a passagem de um piloto de IA para a operação. Ele defende uma ideia: um piloto se mede contra o trabalho de hoje, com casos reais e um critério de saída fixado antes de começar; não contra a demo. Não é preciso entender de modelos para aplicar isso; é preciso saber como se trabalha hoje.

O que uma demo não consegue dizer

Uma demo é feita para mostrar. Os exemplos são escolhidos, o cenário está limpo e ninguém pergunta quanto custou cada resposta nem quanto tempo a pessoa levou para revisá-la. Isso não a torna enganosa: torna-a incompleta para decidir.

Por isso, uma demo sozinha dá evidência limitada sobre três coisas:

• Os casos que de fato chegam. O guia de avaliações da OpenAI recomenda que os testes reflitam a capacidade do modelo «em distribuições do mundo real» (tradução livre) [3]: os casos com a mistura e a dificuldade que a operação tem, não os que fazem melhor figura.
• A variação. O mesmo guia alerta que a IA generativa «é variável»: o modelo pode dar respostas diferentes para a mesma entrada, e por isso os testes tradicionais de software não bastam (tradução livre) [3]. Vinte acertos são um sinal inicial; não bastam para estimar como o sistema vai se comportar com o volume de um mês.
• O ponto de comparação. «Foi bem» — comparado com quê? Sem saber como sai hoje esse mesmo trabalho, não há como dizer se a IA o melhora.

Passo 1 · Medir o trabalho de hoje, antes de mexer em qualquer coisa

As regras de aprendizado de máquina que o Google publica colocam isso em primeiro lugar: antes de formalizar o que o sistema vai fazer, projete e implemente as métricas, e registre o máximo possível do sistema atual (tradução livre) [1]. A razão é simples: se o antes não é medido, o depois não tem com o que ser comparado.

Na empresa fictícia, medir hoje significa responder, com dados de um mês normal:

• Quantas solicitações chegam, e de que tipos?
• Quanto tempo leva em média uma resposta, da chegada ao envio?
• Quantas saem com erro e precisam ser corrigidas, e quantas geram uma reclamação?
• Quanto custa atender uma, somando o tempo das pessoas?

Esse mesmo documento do Google traz outra regra que vale a pena ler antes de qualquer piloto: não tenha medo de lançar um produto sem aprendizado de máquina, porque uma regra simples bem pensada pode render mais que um modelo sem dados (tradução livre) [1]. Às vezes, medir hoje revela que metade das solicitações se resolve com um modelo de resposta e uma regra. Isso também é um bom achado: a IA fica reservada para o que de fato precisa dela.

Passo 2 · Escrever os critérios antes de começar

A segunda peça é decidir, antes do piloto, qual resultado conta como bom. Se os critérios são fixados depois de ver os resultados, eles tendem a se acomodar a eles.

A documentação da Anthropic para quem constrói com os modelos dela pede critérios de sucesso com quatro traços: específicos («classificar bem as solicitações», não «bom desempenho»), mensuráveis (com números ou escalas bem definidas), alcançáveis (baseados em referências reais, não no que se gostaria) e relevantes (alinhados com o que o negócio precisa) (tradução livre) [2]. Sugere também comparar com uma referência — um modelo base ou uma versão anterior — e medir à parte os casos-limite [2].

Em linguagem de comitê, os critérios cabem numa tabela. Esta é de exemplo, com números inventados para ilustrar; os de cada empresa saem do Passo 1:

Os limites são ilustrativos: cada empresa os fixa conforme o processo, quem responde por ele e o limite de risco que tiver aprovado. Dois detalhes dessa tabela importam mais que os números. Primeiro, ela separa os eventos de alto impacto dos erros leves: um tom que pode melhorar se corrige; mandar o dado de um cliente para outro, não. Segundo, ela tem coluna para parar: se não está escrito qual resultado interrompe o piloto, o piloto não para.

Passo 3 · Testar com casos reais, incluídos os difíceis

Com os critérios escritos, prepara-se com a operação uma amostra de casos reais que se pareça com o trabalho que chega — por exemplo, os de um mês normal, na proporção em que chegam —, não os vinte da demo. Três regras a tornam útil para decidir:

• Separe os casos para ajustar dos casos para decidir. Os primeiros servem para afinar instruções; os segundos ficam guardados e só são usados no final. A documentação da Anthropic chama esses de avaliações reservadas (held-out) [2].
• Escreva antes o que conta como resposta correta, quem a avalia e como se resolve uma divergência entre dois revisores.
• Decida por escrito quais dados entram: quem pode vê-los, que informação é ocultada ou substituída para o teste e quem autorizou esse uso. O fato de a operação ter controles não diz, por si só, que a amostra pode sair para um ambiente de teste ou para um fornecedor.

O perfil de IA generativa do NIST, o instituto de normas e tecnologia dos Estados Unidos, é um guia de uso voluntário que coloca isso assim na função de medição: o desempenho do sistema é medido e demonstrado em condições parecidas com as da operação, e as medidas são documentadas (tradução livre) [4]. O guia da OpenAI sugere ainda registrar tudo durante o teste, para tirar desses registros novos casos de teste [3].

Dentro dessa amostra convém separar um grupo de casos difíceis — mesmo que sejam poucos, incluídos os de alto impacto — e medi-lo à parte: a solicitação ambígua, a que traz dois assuntos, a do cliente irritado, a que menciona um dado que não está no sistema. É ali que um piloto ganha ou perde a confiança da equipe que vai usá-lo.

Passo 4 · Medir o que custa, não só o que acerta

Um piloto pode acertar muito e mesmo assim não compensar. Antes de escalar, convém olhar quatro custos que a demo não mostra:

• O tempo de revisão. Se a pessoa leva quase o mesmo tempo para revisar a resposta que para escrevê-la, a economia é pequena.
• O custo de operar o caso. O uso do modelo, conforme o contrato ou a infraestrutura da empresa, mais a revisão de uma pessoa. Multiplicado pelo volume real de um mês, esse número pode mudar a decisão. A preparação inicial é apresentada à parte, para não misturá-la com o custo de operar.
• Os casos que passa para uma pessoa. Que a IA reconheça o que não deve resolver é bom; que passe quase tudo significa que não está economizando trabalho.
• O trabalho de mantê-lo. Alguém precisa revisar os resultados todo mês, ajustar instruções e cuidar do que mudar nos sistemas de onde a IA tira dados.

Passo 5 · Decidir por escrito: escalar, ajustar ou parar

No final, o resultado é comparado com os critérios e toma-se uma de três decisões, por escrito:

• Escalar, se cumpre as metas combinadas e se mantém dentro do limite de risco aprovado.
• Ajustar e repetir, se chega perto e há uma causa clara que pode ser corrigida: uma instrução, um dado que faltava, um tipo de solicitação que convém deixar de fora.
• Parar, se não cumpre e não há uma causa clara. Parar a tempo também é um bom resultado: é o que evita escalar um custo.

Entre as ações sugeridas, o NIST propõe compartilhar os resultados dos testes anteriores à implantação com quem tem a autoridade de aprovar a entrada em operação (tradução livre) [4]. Em linguagem de comitê: a decisão de escalar é tomada por quem responde pela operação, com o documento de resultados na mão, não com a lembrança da demo. Essa mesma ata nomeia quem responde pelo processo, diz como um incidente é reportado e atendido e marca a próxima revisão. Os limites de risco são tratados à parte das metas de economia ou de velocidade.

Os sinais de que um piloto ainda não está pronto

Cinco perguntas para o próximo comitê

1. Quanto tempo leva, quanto custa e quantos erros tem hoje o trabalho que o piloto quer melhorar? Se não há número, esse é o primeiro pendente.
2. Qual resultado nos faria escalar e qual nos faria parar, e isso está escrito desde antes de começar?
3. Com quais casos se testou: escolhidos ou uma amostra real de um mês, com os difíceis medidos à parte?
4. Houve eventos de alto impacto, e quanto custa cada caso somando o processamento e a revisão de uma pessoa?
5. Quem assina a decisão de escalar, com qual documento, e quem responde pelo processo depois que entrar em operação?

Se várias respostas forem «não sei», o piloto ainda não está pronto para ser decidido; está pronto para ser medido.

Por onde começar esta semana

Escreva os critérios do piloto numa única página, mesmo que o piloto já esteja rodando. Quatro blocos:

• O trabalho de hoje: volume, tempo, erros e custo de um mês normal.
• Os indicadores: de três a cinco, com o valor de hoje, o que leva a escalar e o que leva a parar.
• A amostra: de onde saem os casos de teste, quem os escolhe e quais são os difíceis.
• A decisão: quem a toma, em que data e com qual documento.

Se a página não puder ser preenchida, isso já diz o que falta antes de escalar.

O que a Hábil faz

Na Hábil construímos sob medida a IA que trabalha com os dados e as regras dos sistemas da empresa.

Se o piloto precisa desses critérios de saída, a proposta está na Hábil AI. Escolhemos junto com a empresa um processo em que hoje ela perde tempo, dinheiro ou clientes, e o deixamos funcionando com indicador, critério de saída, escopo e custo acordados antes de começar, incluído o custo de processamento com o teto. Antes de operar, é testada com casos reais e com um critério de saída acordado. O caminho é: diagnóstico → proposta com escopo, custo e risco → teste com critério de saída → operação. Podemos trabalhar com a IA que a empresa já tem — ChatGPT, Copilot, Gemini ou Claude — ou com uma instalada nos servidores dela; e o que movimenta dinheiro ou dados é executado com uma pessoa aprovando.

A conversa pode começar com a página de critérios, mesmo pela metade: qual processo, como ele é medido hoje e que resultado se espera. Com isso, revisamos juntos se convém seguir, ajustar ou começar por outro processo. Escreva para nós pelo WhatsApp; para proteger as informações, não compartilhe por esse meio dados dos clientes nem dos sistemas da empresa: combinaremos na conversa o canal para o caso.

Peça a primeira conversa, sem custo.

Consultadas em 12 de novembro de 2026. Cada referência traz o grau de confiança: alta (fonte primária lida).