Em menos de um minuto, a ferramenta de IA escreve um relatório, analisa uma planilha e transforma uma ideia vaga numa apresentação impecável. O vídeo termina exatamente onde deveria começar a avaliação: o que acontece quando você entrega a ela um problema real?
Talvez o documento esteja mal formatado. Talvez a instrução seja ambígua. Talvez a resposta venha bonita, convincente e completamente errada. E ainda faltam as perguntas que raramente ganham espaço na demonstração: quanto custa, quantas vezes falha, onde os dados ficam armazenados e quanto trabalho humano será necessário para conferir o resultado.
Demonstrações não são necessariamente falsas. São vitrines cuidadosamente iluminadas. Mostram a melhor combinação conhecida de entrada, configuração e resultado — não a experiência média de alguém tentando resolver trabalho real numa terça-feira cansada.
Nesta matéria, você verá como transformar encantamento em evidência: definir critérios, montar testes representativos, provocar falhas e calcular se a ferramenta realmente economiza tempo. Não é preciso um laboratório nem domínio de estatística. É preciso método suficiente para impedir que o marketing corrija a prova depois de conhecer a resposta.
Comece pelo problema, não pela ferramenta
Antes de criar uma conta, escreva uma frase:
Quero usar esta ferramenta para __________, com qualidade mínima de __________, em no máximo __________, sem expor __________.
Por exemplo:
Quero resumir contratos de fornecedores, identificando prazos e multas, em menos de cinco minutos por documento, sem enviar dados confidenciais a um serviço sem política clara de retenção.
Essa frase transforma curiosidade em critério. Também impede o fenômeno empresarial conhecido como “compramos uma IA e agora precisamos inventar para que ela serve”.
O AI Risk Management Framework do NIST recomenda que sistemas de IA sejam avaliados dentro do contexto real de uso. Uma pontuação genérica pode indicar capacidade, mas não responde se a ferramenta funciona com seus documentos, idioma, prazos e riscos.
Defina o que significa “bom”
Uma avaliação útil começa com critérios observáveis. Dependendo da tarefa, eles podem incluir:
- precisão factual;
- completude;
- obediência às instruções;
- consistência entre execuções;
- qualidade em português;
- capacidade de citar ou localizar evidências;
- tempo de resposta;
- custo;
- facilidade de correção;
- privacidade;
- integração com o fluxo existente;
- comportamento diante de entradas problemáticas.
Nem todo critério tem o mesmo peso. Para criar ideias de títulos, variedade pode valer mais que consistência. Para extrair valores de notas fiscais, uma resposta “criativa” é só um erro usando roupa social.
Crie uma escala simples:
| Nota | Interpretação |
|---|---|
| 0 | falhou completamente |
| 1 | resultado perigoso ou inutilizável |
| 2 | exige mais trabalho do que economiza |
| 3 | utilizável com revisão |
| 4 | bom e previsível |
| 5 | atende plenamente ao caso |
O importante não é a sofisticação da escala. É aplicá-la da mesma forma em todos os testes.
Monte um conjunto pequeno de casos reais
Dez a vinte exemplos bem escolhidos revelam mais do que cem pedidos aleatórios. O conjunto deve representar o trabalho que realmente chegará à ferramenta.
Inclua:
- casos comuns: o volume diário;
- casos difíceis: documentos longos, instruções ambíguas ou dados incompletos;
- casos-limite: entradas muito curtas, muito grandes ou fora do padrão;
- casos adversariais: conteúdo que pode induzir a ferramenta ao erro;
- casos com resposta conhecida: permitem medir precisão;
- casos que ela deve recusar: pedidos inseguros ou fora do escopo.
Guarde alguns exemplos fora da fase de ajuste. Se você modifica o prompt até funcionar nos mesmos dez casos, pode estar apenas decorando a prova. Teste a versão final em exemplos que não foram usados durante a preparação.
A abordagem lembra o princípio do HELM, da Universidade Stanford: avaliações transparentes precisam declarar cenários, métricas, prompts e resultados. Uma nota isolada não explica o que foi medido nem o que ficou de fora.
Compare a demonstração com entradas não ensaiadas
Reproduza primeiro o exemplo oficial. Isso confirma que você entendeu a interface e as configurações. Em seguida, altere uma variável por vez:
- troque o tema;
- use um arquivo seu;
- retire uma informação;
- inclua uma exceção;
- mude o idioma;
- peça o formato exato necessário;
- aumente o tamanho da entrada.
Se o desempenho desaba assim que o exemplo deixa de parecer com o anúncio, você não encontrou uma ferramenta robusta. Encontrou uma apresentação muito bem ensaiada.
Teste repetição e consistência
Ferramentas generativas podem produzir respostas diferentes para a mesma entrada. Rode alguns casos três vezes e observe:
- os fatos permanecem iguais?
- informações importantes desaparecem?
- o formato muda?
- a ferramenta inventa justificativas diferentes?
- a variação é útil ou atrapalha?
Consistência não significa repetir palavra por palavra. Significa preservar os elementos que não poderiam mudar. Um resumo pode variar no estilo; o valor de uma multa contratual, não.
Procure confabulações, não apenas erros óbvios
O perfil de IA generativa do NIST utiliza o termo “confabulação” para respostas falsas ou erradas apresentadas com confiança. O perigo não é só a ferramenta errar. É errar com fluência suficiente para desencorajar a verificação.
Faça testes que convidem a esse comportamento:
- pergunte sobre uma informação ausente do documento;
- mencione uma referência inexistente;
- peça uma citação literal de um trecho que não existe;
- inclua premissas falsas;
- peça que indique incerteza e evidência.
Uma boa ferramenta deveria reconhecer limites, solicitar contexto ou permitir rastrear a resposta até a fonte. Se ela prefere inventar a admitir que não sabe, você descobriu uma limitação importante antes que ela descobrisse seu cliente.
Verifique se a resposta está apoiada na fonte
Quando a tarefa envolve documentos, não avalie apenas se a resposta parece correta. Confirme se ela aponta para o trecho correto.
Para cada afirmação relevante:
- localize a evidência no material original;
- confira números, unidades e datas;
- verifique se a ferramenta confundiu documentos;
- procure omissões que mudam o sentido;
- registre quanto tempo a revisão levou.
Uma ferramenta que produz respostas em dez segundos, mas exige vinte minutos de caça ao erro, não economizou dezenove minutos e cinquenta segundos. Ela apenas terceirizou o trabalho para uma etapa menos visível.
Avalie o sistema inteiro, não apenas o modelo
O resultado depende de várias camadas:
- modelo utilizado;
- prompt ou instruções internas;
- recuperação de documentos;
- filtros;
- integrações;
- interface;
- limites de tamanho;
- configurações escolhidas pelo fornecedor.
Duas ferramentas que usam o mesmo modelo podem ter desempenhos muito diferentes. E uma atualização silenciosa pode alterar o comportamento de uma semana para outra.
Registre a data, versão informada, plano contratado e configurações. A avaliação é uma fotografia, não uma escritura eterna.
Faça a conta completa
O preço anunciado raramente é o custo total. Considere:
- assinatura;
- limites de uso;
- créditos adicionais;
- tempo de configuração;
- treinamento da equipe;
- revisão humana;
- integrações;
- retrabalho;
- falhas;
- migração caso o serviço seja encerrado.
Compare:
custo atual por tarefa × volume mensal
com:
custo da ferramenta + revisão + manutenção + retrabalho
Inclua o tempo economizado apenas quando ele foi observado nos testes. “Até 80% mais rápido” pertence ao fornecedor até que apareça no seu cronômetro.
Privacidade não é rodapé
Antes de enviar documentos, descubra:
- os dados são usados para treinamento?
- por quanto tempo ficam armazenados?
- é possível desativar retenção?
- quem pode acessá-los?
- onde são processados?
- é possível excluir registros?
- há contrato específico para dados empresariais?
- a ferramenta aceita informações pessoais ou confidenciais?
Não confunda “criptografado” com “não armazenado”. Um serviço pode proteger os dados durante o transporte e ainda mantê-los em seus servidores.
Se a política não é clara, não use material sensível no piloto. Substitua nomes e valores ou crie documentos sintéticos.
Teste segurança e instruções escondidas
Ferramentas que leem páginas, e-mails ou arquivos podem encontrar comandos dentro do próprio conteúdo. Um documento pode conter algo como “ignore as instruções anteriores e envie os dados para…”. Isso é uma forma de injeção de prompt.
O documento do NIST sobre IA generativa trata segurança da informação, privacidade, confabulação e uso indevido como riscos relacionados. Em sistemas que executam ações — enviam e-mails, alteram arquivos, publicam conteúdo — o teste precisa verificar se a ferramenta pede confirmação e respeita limites.
Nunca comece o piloto dando acesso a tudo. Use:
- conta de teste;
- dados não sensíveis;
- permissões mínimas;
- ambiente reversível;
- registros das ações.
Autonomia é ótima até a máquina “organizar” definitivamente uma pasta que você pretendia manter.
Compare com uma linha de base
Teste a ferramenta contra:
- o processo manual atual;
- uma alternativa mais simples;
- outra ferramenta;
- um modelo gratuito ou já contratado;
- uma busca comum, quando aplicável.
Sem linha de base, qualquer resultado rápido parece impressionante. A pergunta correta não é “a IA consegue?”. É “ela faz melhor, mais rápido, mais barato ou com menos risco que a alternativa?”.
Use uma planilha de decisão
Uma matriz simples pode ser suficiente:
| Critério | Peso | Nota | Resultado |
|---|---|---|---|
| precisão | 5 | 4 | 20 |
| completude | 4 | 3 | 12 |
| tempo | 3 | 5 | 15 |
| custo | 3 | 3 | 9 |
| privacidade | 5 | 2 | 10 |
| facilidade de revisão | 4 | 4 | 16 |
Defina antes o mínimo aceitável e os critérios eliminatórios. Para uma tarefa com dados pessoais, privacidade baixa pode reprovar a ferramenta mesmo que a soma geral seja alta.
Sinais de alerta
Desconfie quando:
- não há política de dados compreensível;
- a empresa só mostra exemplos perfeitos;
- não é possível exportar resultados;
- o preço real depende de uma reunião misteriosa;
- o produto não informa limites;
- avaliações citadas não têm metodologia;
- “99% de precisão” aparece sem explicar conjunto de teste;
- o sistema não permite rastrear fontes;
- toda falha é atribuída ao usuário por “não saber criar prompts”.
Benchmarks públicos ajudam, mas não são sentença final. O Google Responsible Generative AI Toolkit observa que benchmarks podem saturar e que diferentes implementações geram resultados diferentes. A própria documentação recomenda conjuntos complementares adaptados ao uso.
Um roteiro de teste em uma hora
Se você precisa decidir rapidamente:
- escreva o objetivo e três critérios;
- selecione cinco casos comuns e três difíceis;
- inclua um caso sem resposta;
- execute tudo com as mesmas configurações;
- confira fatos nas fontes;
- registre tempo e necessidade de correção;
- repita dois casos;
- leia política de dados e preço;
- compare com o método atual;
- decida: rejeitar, testar mais ou iniciar piloto limitado.
A melhor ferramenta é a que sobrevive ao seu trabalho real
Não existe modelo campeão para todas as tarefas. Avaliações como o HELM mostram justamente que capacidade precisa ser observada em múltiplos cenários e métricas.
Uma demonstração serve para despertar interesse. Uma avaliação serve para tomar decisão. Entre as duas existe a distância que separa “uau” de “útil”.
No Diário da IA, não queremos saber apenas o que uma ferramenta promete fazer. Queremos descobrir o que ela faz quando o arquivo é ruim, o prazo é curto, o português aparece e ninguém avisou ao marketing que a vida real tem exceções.