Um fornecedor mostra-te uma demo. Lê faturas, classifica emails ou responde a pedidos de clientes, o que precisares. Corre na perfeição: rápida, limpa, sem uma única falha. Assinas, ligam-na à tua operação real e, três semanas depois, alguém da equipa diz-te que não se pode confiar nela. O fornecedor jura que é o mesmo produto. Tem razão, e é precisamente esse o problema: entre a demo e a produção não mudou o sistema, mudou o material com que foi testado.
A tese numa linha: a demo não falha por má-fé, falha por seleção da amostra. Os documentos que enviaste eram os limpos, os tickets eram os bem escritos, e os casos que quebram o caso de negócio nunca chegaram a entrar. O que viste não era um teste, era um ensaio.
Porque é que a demo de IA não se parece com a produção
Porque alguém escolheu os casos. Quase sempre tu, com a melhor das intenções. Pedem-te exemplos para o teste e envias os que tens à mão: os documentos bem digitalizados, os tickets escritos com frases completas, os clientes que seguem o processo tal como o desenhaste no papel. Com esses, qualquer sistema razoável parece bom. E o fornecedor prepara-se com eles: ajusta o prompt, afina as regras, resolve as esquisitices que aparecem. Quando chega a demo, o sistema já viu o exame.
A produção não é essa amostra. É a distribuição inteira, com as suas caudas: a digitalização torta, o email de três linhas sem contexto, o cliente com duas denominações sociais, a fatura retificativa que chega numa sexta à tarde. Um sistema avaliado só na parte fácil da distribuição não está testado, está ensaiado. É a mesma lógica pela qual uma percentagem de acerto não basta em produção: o número depende dos casos que entram na conta.
O que fica fora de uma demo, e porque é exatamente o que custa dinheiro
- Os documentos feios. Fotografias tiradas com o telemóvel, PDFs digitalizados ao contrário, tabelas partidas entre duas páginas, formatos de há cinco anos que ninguém desativou.
- As mensagens mal escritas. Frases a meio, duas línguas no mesmo email, referências a uma conversa anterior que o sistema não tem.
- As exceções do negócio. O cliente com condições especiais, a encomenda que mistura duas tabelas de preços, o caso que só conhece a pessoa que está no cargo há dez anos.
- O raro e o hostil. Entradas vazias, duplicados, anexos que não são o que dizem ser, alguém a testar os limites do sistema.
Há algo pior do que a frequência: os casos raros não custam o mesmo que os normais. Um erro num ticket simples corrige-se num minuto. Um erro na fatura de um cliente grande, ou na resposta que chega à administração, paga-se em confiança. Por isso, uma demo perfeita nos casos fáceis diz pouco sobre o custo real de pôr o sistema a funcionar.
O número que importa não é a média, é a cauda má
Se te dizem que o sistema acerta «quase sempre», pergunta: em quê? Uma média alta pode esconder que os casos fáceis saem quase todos bem e os difíceis quase todos mal, e que o teu caso de negócio depende dos difíceis. Se o processo se justifica porque hoje alguém perde horas com as exceções, um sistema que resolve o que já era fácil não te poupa nada. Olha para o pior troço: o que acontece com os casos mais complicados, que erros comete e com que frequência, quais deteta sozinho e quais chegam ao cliente. É isso que medir o desempenho das tuas automatizações exige desde o primeiro dia.
O que pedir em vez de uma demo: um método de compra em cinco passos
- Uma amostra aleatória, escolhida por ti. Apanha os últimos casos reais de um período, sem filtrar nem limpar, e não os mostres ao fornecedor antes do teste. Se for ele a escolhê-los, voltamos ao ponto de partida.
- Com os raros lá dentro. Acrescenta à mão os que mais doem: os que escalaram, os que acabaram em reclamação, os que só uma pessoa da equipa resolve.
- Critério antes de ver o resultado. Define por escrito que erro é aceitável em cada tipo de caso e qual nunca o é. Se fixares a fasquia depois, acabas a defender o que já viste.
- Lê as falhas, não só a percentagem. Revê à mão os casos que falham. Erros espalhados ao acaso e erros sempre concentrados no mesmo tipo de cliente são problemas diferentes, mesmo com a mesma percentagem.
- Testa com os teus dados, no teu ambiente. Com as tuas permissões, os teus formatos e os teus sistemas ligados. Uma avaliação da qualidade dos agentes de IA existe precisamente para repetir este teste de cada vez que algo muda, não só antes de comprar.
Quando a demo serve mesmo
Nem tudo é desconfiança. Uma demo é útil para ver se a interface se ajusta à forma como a tua equipa trabalha, se as integrações existem a sério e se o fluxo faz sentido. Também chega quando o custo de um erro é pequeno e reversível: um rascunho que uma pessoa revê antes de enviar não precisa de um protocolo de avaliação. A demo responde a «isto é possível?». Não responde a «isto aguenta a minha operação?», que é a pergunta pela qual se assina.
O que ler na reação do fornecedor
Quando propões o teste com amostra aleatória e casos difíceis, a reação diz-te mais do que a demo. Um fornecedor sério aceita, ajuda-te a desenhá-lo e mostra-te as falhas juntamente com os acertos. Um que se põe a negociar a amostra, a pedir «um caso representativo» ou a mudar o critério de sucesso acabou de te mostrar como será a relação quando algo falhar em produção.
Se estás a comparar opções, como escolher uma ferramenta de automatização com IA dá-te os restantes critérios. E se já passaste por um piloto que brilhou e nunca chegou à produção, a demo não é o projeto conta o que vem depois de assinar.
A frase para levar: uma demo não prova que o sistema funciona, prova que existe um conjunto de casos para os quais funciona. O teu trabalho, antes de assinar, é descobrir que casos não estão nesse conjunto.