De uma demo convincente a um sistema que você consegue operar.
Publicado em 30 de setembro de 2026
Uma boa demo não é um produto
Uma demo funciona porque quem apresenta escolhe a entrada. Um produto encontra documentos que ninguém escreveu para ele, perguntas que ninguém previu e usuários que às vezes tentam fazê-lo errar. A distância entre os dois é, em grande parte, engenharia: definir a tarefa, conectar os dados certos, medir a qualidade e controlar o que o sistema pode fazer.
Este artigo lista o que acreditamos que precisa ser verdade antes de colocar uma funcionalidade de IA diante de usuários reais. É um checklist para apoiar o julgamento, não uma garantia, e nem todo item se aplica a toda funcionalidade.
Defina a tarefa e o custo de errar
Comece pelo que o sistema deve fazer, em termos que um colega não técnico aceitaria, e pelo que acontece quando ele erra. Um resumo ligeiramente impreciso custa pouco. Uma resposta errada sobre um contrato, um tema médico ou financeiro, ou uma ação automatizada na conta de um cliente pode custar muito.
Esse custo define o desenho. Tarefas de baixo custo podem rodar com supervisão leve. Tarefas de alto custo exigem que uma pessoa aprove o resultado, permissões restritas ou um escopo mais estreito. Registrar isso cedo evita a falha comum de descobrir o risco depois do lançamento.
Avalie com os seus próprios casos
Benchmarks gerais dizem como um modelo se sai nas perguntas de outras pessoas. Não dizem como a sua funcionalidade se sai nas suas. Monte um conjunto de avaliação com casos reais e representativos: pedidos típicos, difíceis e aqueles que precisam falhar de forma segura, como uma pergunta que os dados não respondem ou um pedido que o usuário não deveria poder fazer.
Execute o conjunto a cada mudança relevante: uma nova versão do modelo, um prompt alterado, uma configuração de recuperação diferente. Alguns julgamentos podem ser automatizados, outros exigem revisão humana, e não há problema em começar pequeno. O que importa é que a qualidade seja medida, e não presumida, e que uma regressão apareça antes de os usuários a verem.
Ancore o sistema e respeite os dados
Modelos são fluentes, estejam certos ou não. A ancoragem reduz essa distância ao recuperar informação relevante das suas próprias fontes e pedir que o modelo responda a partir dela, idealmente com referências que o usuário possa conferir. A qualidade da recuperação passa então a fazer parte da qualidade do sistema e precisa ser avaliada por si só.
O tratamento de dados exige decisões explícitas: o que é enviado a qual provedor, o que é armazenado e por quanto tempo, quem pode ver quais documentos e como tudo isso se encaixa na LGPD e nas suas políticas internas. As regras de acesso precisam valer no momento da recuperação, para que o sistema nunca exiba um documento que o usuário não poderia abrir diretamente.
Controles, supervisão e operação
O uso em produção exige as partes pouco glamorosas: logs que permitam reconstituir o que aconteceu, monitoramento de qualidade, latência e custo, limites que interrompam um ciclo descontrolado e uma alternativa para quando o modelo ou o provedor estiver indisponível.
Para agentes que podem agir, e não apenas responder, as permissões merecem cuidado especial. Dê ao sistema o menor acesso que lhe permita fazer o trabalho, exija aprovação para ações custosas ou difíceis de desfazer e só relaxe isso conforme a avaliação mostrar que é seguro. Modelos e provedores mudam rápido, então projete o sistema de modo que o modelo possa ser trocado sem reconstruir tudo ao redor.
Se você tem um protótipo e não sabe a que distância ele está da produção, um diagnóstico pode responder isso de forma delimitada, antes de investir mais.
