Observabilidade em IA: sem rastreabilidade não existe confiança

Observabilidade em IA: sem rastreabilidade não existe confiança.

No artigo anterior, falei sobre agentes em produção e sobre como autonomia é uma decisão arquitetural.

Terminei com uma frase:

Não existe autonomia sem rastreabilidade.

Hoje quero aprofundar isso.

Porque, ao longo deste ano, praticamente todos os temas que discuti aqui — confiança, avaliação, custo, contexto, agentes — chegam ao mesmo ponto:

Você não consegue governar o que não consegue enxergar.

O sistema respondeu. Mas por quê?

Imagine este cenário.

Um cliente reclama que o assistente de IA deu uma informação errada sobre a política de reembolso.

O time abre os logs e encontra:

• POST /chat 200 OK
• Latência: 2,3s
• Tokens: 4.812

E só.

Ninguém sabe:

• Quais documentos foram recuperados
• Qual versão do prompt estava ativa
• Qual modelo respondeu
• Se alguma ferramenta foi chamada
• Se a política estava desatualizada na base
• Se outros clientes receberam a mesma resposta

Para a infraestrutura, a requisição foi um sucesso.

Para o negócio, foi um incidente.

Essa é a lacuna que a observabilidade tradicional não cobre.

Por que observabilidade tradicional não basta

Observabilidade clássica responde bem a perguntas como:

• O serviço está de pé?
• Qual a latência?
• Qual a taxa de erro?
• Onde está o gargalo?

Em sistemas determinísticos, isso é quase suficiente. Se o código não mudou e a entrada é a mesma, a saída é a mesma.

Em sistemas de IA, não.

O comportamento depende de:

• O contexto recuperado naquele momento
• A versão do prompt
• A versão do modelo
• Parâmetros de geração
• O estado da base de conhecimento
• Decisões intermediárias de um agente

Uma resposta errada com status 200 é o tipo de falha mais comum em IA.

E é invisível para um dashboard de latência.

As quatro camadas de observabilidade em IA

Quando desenho arquiteturas de IA para produção, separo a observabilidade em quatro camadas.

1. Operacional

A camada que todo mundo já conhece:

• Latência por etapa
• Taxa de erro
• Disponibilidade dos provedores
• Timeouts e retries

Necessária, mas longe de suficiente.

2. Contexto

O que entrou no modelo:

• Quais fontes foram consultadas
• Quais trechos foram recuperados e com qual relevância
• Quais transformações foram aplicadas
• Quais filtros de permissão foram usados
• Tamanho final do contexto

Essa camada conecta diretamente com orquestração de contexto e MCP. Se o contexto é a matéria-prima da resposta, ele precisa ser rastreável.

3. Decisão

O que o sistema decidiu fazer:

• Versão do prompt e do modelo
• Ferramentas chamadas, com parâmetros e resultados
• Passos de um agente e o raciocínio associado
• Pontos onde houve aprovação humana
• Caminhos de fallback acionados

É essa camada que permite responder “por que ele fez isso?”.

4. Qualidade e negócio

O que aquilo significou:

• Avaliações automáticas de qualidade
• Feedback de usuários
• Taxa de escalonamento para humanos
• Custo por tarefa resolvida, não por requisição
• Impacto em indicadores de negócio

Sem essa camada, você sabe que o sistema funciona.

Mas não sabe se ele serve.

O trace como unidade de verdade

A peça central de tudo isso é o trace.

Cada interação com o sistema de IA deveria gerar um rastro completo, do pedido do usuário até a resposta final, passando por:

1. Entrada recebida
2. Contexto recuperado
3. Prompt montado
4. Chamada ao modelo
5. Ferramentas executadas
6. Validações aplicadas
7. Resposta entregue
8. Feedback recebido

Com um identificador único, ligando tudo.

Isso permite:

• Reproduzir um incidente
• Comparar versões de prompt com tráfego real
• Encontrar padrões de erro
• Alimentar conjuntos de avaliação com casos reais
• Atribuir custo a funcionalidades e clientes

Padrões abertos como o OpenTelemetry já começam a tratar chamadas de LLM como cidadãs de primeira classe. Vale aproveitar isso em vez de criar um formato próprio.

Observabilidade e avaliação são a mesma conversa

No artigo sobre avaliação de sistemas de IA, defendi que avaliação é uma decisão arquitetural.

Observabilidade é o que torna essa avaliação contínua.

• Avaliação offline diz se uma mudança deveria funcionar
• Observabilidade em produção diz se ela está funcionando

Os melhores times que conheço fecham o ciclo:

1. Observam falhas em produção
2. Transformam casos reais em testes
3. Avaliam novas versões contra esses testes
4. Publicam e voltam a observar

Isso é engenharia.

O resto é torcida.

Os cuidados que quase todo mundo esquece

Observabilidade em IA tem um efeito colateral perigoso:

Você passa a registrar exatamente o tipo de dado que mais precisa de proteção.

Prompts e respostas carregam:

• Dados pessoais
• Informações de clientes
• Segredos de negócio
• Às vezes, credenciais coladas por engano

Por isso, a arquitetura de observabilidade precisa nascer com:

• Mascaramento de dados sensíveis antes do armazenamento
• Controle de acesso aos traces
• Políticas de retenção e expiração
• Amostragem consciente, e não registro indiscriminado
• Separação entre métricas agregadas e conteúdo bruto

Rastreabilidade sem governança troca um risco por outro.

Por onde começar

Não é preciso construir uma plataforma inteira no primeiro dia.

Um caminho pragmático:

1. Gere um ID de trace para cada interação e propague por todas as etapas
2. Registre versões: prompt, modelo e base de conhecimento
3. Registre o contexto recuperado, com mascaramento
4. Capture feedback do usuário, mesmo que seja um simples polegar
5. Meça custo por tarefa, não só por chamada
6. Revise semanalmente uma amostra de interações reais

Em poucas semanas, o time sai do “achamos que está funcionando” para o “sabemos onde está falhando”.

Reflexão final

Durante muito tempo, observabilidade foi tratada como algo que se adiciona depois que o sistema está pronto.

Em IA, essa lógica não funciona.

Quando o comportamento é probabilístico, a capacidade de enxergar o que aconteceu é o que separa um sistema governável de uma caixa-preta cara.

Confiança não vem do modelo.

Vem da capacidade de explicar, reproduzir e corrigir cada decisão que o sistema toma.

E essa capacidade não aparece por acaso.

É desenhada.

É arquitetura.