Foto: Markus Winkler / Unsplash
IA
Colocar um sistema de IA em produção sem registrar o prompt completo e a resposta de cada chamada deixa a falha sem como ser reproduzida nem virar caso de teste
Pedro Toledo · 3 de novembro de 2026 · 3 min de leitura
Colocar um sistema de IA em produção sem registrar o prompt completo e a resposta de cada chamada deixa a falha sem como ser reproduzida nem virar caso de teste — porque o erro que o cliente relata depende do que exatamente foi enviado ao modelo e do que ele devolveu, e sem esse registro a equipe só pode tentar adivinhar o que aconteceu. Por que o log comum parecer suficiente, o que caracteriza o registro de uma chamada de IA, e como perceber se a próxima falha vai poder ser investigada.
Um sistema de IA que não retorna erro costuma parecer estar funcionando. Perguntar se, dada a reclamação de um cliente de ontem, a equipe consegue abrir o prompt exato e a resposta devolvida revela se a próxima falha poderá ser investigada.
Colocar um sistema de IA em produção sem registrar o prompt completo e a resposta de cada chamada deixa a falha sem como ser reproduzida nem virar caso de teste — porque o erro depende do que foi enviado ao modelo e do que ele devolveu.
Por que o log comum parece suficiente
A equipe está acostumada a registrar erros e tempos de resposta, e um sistema que não falha tecnicamente parece estar funcionando. A falha de qualidade, porém, como uma resposta errada, inventada ou fora do tom, não gera erro algum, e só o conteúdo do prompt e da resposta permite entendê-la.
O que caracteriza o registro de uma chamada de IA
Um registro útil guarda o prompt completo, a resposta, os parâmetros do modelo, os tokens, o custo e, quando há busca de documentos, o que foi recuperado. Isso tem relação direta com avaliar um agente de IA só com um conjunto pequeno e fácil de exemplo, sem caso extremo nem execução repetida — os dois casos apontam pro mesmo princípio de fundo: a qualidade de um sistema de IA só se sustenta com casos reais e difíceis, e os registros de produção são a fonte desses casos, seja pra montar o conjunto de avaliação, seja pra investigar uma falha.
Como o registro vira melhoria
Os guias de observabilidade, em geral de fornecedores, descrevem usar os casos sinalizados pelos usuários como ruins pra montar um conjunto de avaliação e avaliar uma amostra das respostas de produção, de modo que cada falha vire um teste pra a próxima mudança. Um artigo de pesquisa observa que a observabilidade de IA é menos madura que a de software tradicional, e poucas organizações medem qualidade em produção além de erros e tempo de resposta.
Os cuidados com dados dos clientes
Guardar o conteúdo completo das conversas é guardar dados dos clientes, o que exige finalidade, controle de acesso, prazo de retenção e, quando necessário, anonimização. Uma das fontes cita a hospedagem na própria infraestrutura como forma de manter os prompts dentro da empresa. Vale consultar um especialista em proteção de dados antes de definir o que e por quanto tempo guardar.
Como perceber se a próxima falha poderá ser investigada
A forma prática é pegar uma reclamação recente e tentar abrir o prompt exato enviado ao modelo e a resposta devolvida. Se não for possível, o sistema está sem o registro que torna a falha reprodutível, e vale instrumentar cada chamada antes da próxima ocorrência.
Um exemplo prático
Uma empresa usa um assistente de atendimento e recebe a reclamação de que ele informou um prazo errado. A equipe só tem o registro de que a chamada ocorreu e não consegue ver o que foi enviado. Depois, ela passa a guardar, com prazo de retenção definido, o prompt, os documentos recuperados e a resposta de cada conversa, e transforma cada reclamação num caso do conjunto de testes.
O ponto central
Antes de colocar um sistema de IA em produção, vale decidir o que será registrado de cada chamada. Falha que não pode ser reproduzida não pode ser corrigida; só pode ser esperada de novo.
