Como instrumentar telemetria em funcionalidades com IA

A telemetria de produtos com IA começa no desenho de eventos e atributos: o que precisa ser registrado para reconstruir a tarefa, interpretar o resultado e decidir a próxima investigação. Em uma funcionalidade inteligente, volume de uso, latência e erro técnico mostram atividade, mas raramente explicam se a inteligência artificial ajudou, confundiu, exigiu correção ou criou risco.

Essa arquitetura separa três camadas: intenção do usuário, execução da IA e evidência observável de resultado.

O que a telemetria precisa responder sobre a funcionalidade inteligente

Quando uma funcionalidade inteligente entra em uso, a reunião de produto costuma pedir respostas simples: em quais situações ela ajudou, onde atrapalhou, quais usuários precisaram corrigir a resposta, quais casos devem virar melhoria. O problema é que a instrumentação de produto muitas vezes nasce técnica demais ou genérica demais.

Técnica demais quando registra apenas chamada ao modelo, tempo de resposta, erro de API e disponibilidade. Genérica demais quando mede cliques, sessões e volume de uso sem contexto da tarefa.

A telemetria de produtos com IA precisa responder perguntas de produto, não apenas perguntas de infraestrutura. Algumas perguntas úteis são:

Que tarefa o usuário tentava concluir quando acionou a IA?
Que contexto estava disponível para a funcionalidade naquele momento?
O que a IA executou: resposta direta, busca em base de conhecimento, chamada de ferramenta, sugestão ou resumo?
O usuário aceitou, editou, repetiu, abandonou ou reverteu a ação?
O resultado observado é compatível com sucesso da tarefa ou apenas com uso da funcionalidade?
Em quais segmentos o comportamento muda o suficiente para merecer investigação?

Essa diferença importa porque uso não é valor por si só. Uma funcionalidade pode ser acionada muitas vezes porque resolve uma dor real. Também pode ser acionada muitas vezes porque erra, exige nova tentativa ou virou etapa obrigatória de um fluxo mal desenhado.

A dooop trata esse tipo de decisão como parte de uma estratégia mais ampla de adoção responsável de IA. Em um nível anterior, o tema aparece em como criar uma estratégia de inteligência artificial conectada ao negócio: antes de medir, a organização precisa saber que decisão quer melhorar.

Três blocos de evento: intenção, execução e resultado observado

Um bom desenho de telemetria para uma funcionalidade inteligente começa com três blocos.

O primeiro bloco é a intenção do usuário. Ele registra a tarefa tentada, o ponto do fluxo, o tipo de comando, o contexto selecionado e, quando fizer sentido, a categoria operacional do caso. Não é necessário guardar tudo em texto bruto para reconhecer intenção. Muitas vezes, uma taxonomia de tarefas já permite análise suficiente.

O segundo bloco é a execução da IA. Aqui entram informações como versão da funcionalidade, modelo usado quando essa informação for relevante para análise interna, ferramenta acionada, fonte de contexto consultada, tentativa, estado da resposta, tempo de execução e fallback. Neste artigo, fallback é o caminho alternativo usado quando a IA não responde, não tem confiança suficiente ou precisa devolver o controle ao usuário.

O terceiro bloco é o resultado observado. Esse é o ponto que separa telemetria útil de telemetria decorativa. O resultado pode ser aceitação da sugestão, edição manual, nova tentativa, abandono, reversão, escalonamento, classificação do usuário ou conclusão de uma etapa verificável no sistema.

A Anthropic distingue a trajetória de execução de um agente do resultado efetivo no ambiente. Uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado. A mesma lógica vale para produtos com IA: uma resposta apresentada pela funcionalidade não é prova de que a tarefa do usuário foi concluída.

Essa distinção evita uma armadilha comum. Se o painel mostra que a IA respondeu, o time pode concluir que o fluxo funcionou. Mas, se o usuário editou quase tudo, pediu outra resposta, acionou suporte ou desfez a ação, o sinal de produto é diferente.

Eventos mínimos, retenção e risco de coleta excessiva

Instrumentar uma funcionalidade inteligente exige escolher eventos que respondam perguntas recorrentes de produto, suporte, qualidade e risco.

Eventos geralmente úteis em uma funcionalidade inteligente incluem:

Início da tarefa ou entrada no fluxo em que a IA pode ser usada.
Pedido enviado à IA.
Resposta apresentada ao usuário.
Ação do usuário depois da resposta.
Correção manual ou edição relevante.
Nova tentativa.
Fallback para fluxo tradicional ou intervenção humana.
Erro técnico ou resposta indisponível.
Encerramento, abandono ou conclusão observável.

Também existem dados que devem ser evitados por padrão, a menos que exista justificativa clara e proteção adequada. Entradas completas com informação sensível, campos pessoais sem necessidade analítica e logs extensos que ninguém sabe interpretar tendem a aumentar risco sem aumentar aprendizado.

Um critério simples ajuda: se o dado não muda uma decisão de produto, suporte, qualidade ou risco, ele precisa ser justificado antes de entrar.

Isso não resolve todas as discussões de privacidade, segurança ou governança, mas muda o ponto de partida. Em vez de perguntar “o que conseguimos coletar?”, o time pergunta “qual decisão esse dado permite tomar?”. Em contextos sensíveis, categorias, mascaramento, amostragem e retenção limitada podem ser melhores do que guardar conteúdo bruto.

Atributos de contexto para comparar segmentos

Médias gerais podem esconder problemas importantes. O Google SRE explica, no contexto de monitoramento, que médias podem ocultar comportamentos problemáticos e que visões diferentes atendem públicos diferentes. Em produto, a leitura correspondente é que uma funcionalidade inteligente pode parecer estável na média e falhar em contextos relevantes.

Atributos de contexto ajudam a separar essas situações. Alguns exemplos:

Tipo de tarefa.
Canal de uso.
Perfil operacional do usuário, sem expor identidade desnecessária.
Versão da funcionalidade.
Idioma.
Fonte de conhecimento usada.
Presença de intervenção humana.
Grupo de exposição em um experimento.
Estado do fluxo antes da IA ser acionada.

Esses atributos não provam causalidade sozinhos. Eles permitem comparação. Se uma IA de resumo funciona de um jeito em chamados simples e de outro em chamados com histórico longo, a média não deve decidir pelo time. O recorte por contexto ajuda a formular a próxima pergunta.

Esse cuidado conversa com decisões de maturidade. Em maturidade em IA, a questão não é ter tecnologia sofisticada, mas saber se a organização tem capacidade de operar, avaliar e ajustar o uso de IA com critério.

Sinais posteriores: sucesso, falha e incerteza

O sinal mais fácil de medir nem sempre é o sinal mais próximo da tarefa. Clique, visualização e resposta gerada indicam exposição. Eles não bastam para inferir qualidade.

Sinais mais úteis costumam aparecer depois da resposta da IA:

O usuário manteve a sugestão sem alteração relevante.
O usuário editou a sugestão antes de seguir.
O usuário pediu uma nova resposta.
O usuário copiou a resposta para outro fluxo.
O usuário desfez a ação.
O caso foi reaberto.
O usuário acionou suporte.
Um passo verificável foi concluído no sistema.
O usuário classificou o resultado, quando essa classificação tem contexto suficiente para análise.

Imagine, de forma fictícia, uma IA que sugere respostas para atendimento ao cliente. “Resposta enviada” é um sinal. “Resposta editada antes do envio” é outro. “Caso reaberto depois da resposta” é outro ainda. Nenhum deles, isoladamente, encerra a interpretação.

A resposta enviada pode indicar utilidade. Também pode indicar pressa do atendente. A edição pode indicar melhoria humana sobre uma boa base. Também pode indicar que a sugestão estava inadequada. A reabertura pode ter relação com a resposta, com a complexidade do problema ou com uma expectativa do cliente que não estava disponível para a IA.

Telemetria boa reduz a dependência de memória, anedota ou opinião mais alta na sala.

Qualidade de evento antes de interpretar variações

Antes de alterar a funcionalidade com base nos dados, o time precisa revisar se a coleta é interpretável. Essa etapa é menos vistosa do que um dashboard, mas costuma ser onde decisões ruins são evitadas.

Perguntas de revisão:

Os eventos disparam no momento correto do fluxo?
Há duplicidade de eventos causada por recarregamento, tentativa automática ou mudança de interface?
Existem eventos ausentes em canais específicos?
Os segmentos têm volume suficiente para interpretação responsável?
A definição de um evento mudou durante o período analisado?
Uma alteração de layout aumentou o clique sem mudar a utilidade?
Picos ou quedas são compatíveis com exposição, disponibilidade ou mudança operacional?

A Microsoft, ao tratar de experimentação, recomenda observar um conjunto amplo de métricas e segmentos durante o acompanhamento para identificar regressões e evitar interpretações precipitadas (Microsoft Research). Em análise posterior, também recomenda verificar se mudanças nas métricas são compatíveis com o desenho do teste e se problemas de qualidade dos dados comprometem a interpretação antes de decidir pelo lançamento (Microsoft Research).

Mesmo fora de um experimento formal, o princípio é útil. Se a instrumentação mudou no meio do período, uma variação no indicador pode ser mudança de coleta, não mudança de comportamento.

Para organizações construindo um roadmap de adoção, isso muda a ordem da conversa. O próximo passo de IA não deve ser decidido apenas pela lista de funcionalidades desejadas. Ele precisa considerar se a empresa consegue aprender com o uso. Esse ponto aparece também no roadmap de IA: priorizar sem capacidade de medir cria uma fila de apostas difíceis de comparar.

Exemplo fictício: telemetria de uma IA que resume chamados de suporte

Considere um exemplo fictício: uma empresa usa uma funcionalidade inteligente para resumir chamados de suporte antes que o atendente escreva a resposta. O objetivo hipotético é reduzir esforço de leitura sem piorar a compreensão do caso. Esse efeito precisaria ser medido, não presumido.

Uma instrumentação útil poderia registrar eventos como:

Chamado aberto.
Resumo solicitado.
Resumo exibido.
Resumo editado ou complementado pelo atendente.
Resposta enviada.
Nova consulta ao histórico completo.
Fallback para leitura manual.
Feedback do atendente sobre o resumo.
Reabertura do chamado.

Os atributos poderiam incluir tipo de chamado, canal de entrada, versão da funcionalidade, fonte de conhecimento consultada, idioma e presença de histórico longo. Em vez de guardar o texto integral do chamado em uma base analítica ampla, o time poderia usar categorias de tarefa, marcadores de complexidade e indicadores de edição quando isso for suficiente para responder às perguntas de produto.

Com essa telemetria, o time poderia investigar perguntas como:

Em quais tipos de chamado o resumo parece reduzir esforço sem gerar retrabalho?
Onde o atendente sempre volta ao histórico completo depois de ver o resumo?
Quais padrões de edição devem virar casos de avaliação da IA?
Em quais contextos o fallback para leitura manual aparece com frequência suficiente para investigação?
Que dados não precisam ser guardados porque não mudam nenhuma decisão?

Perceba a diferença. O objetivo não é provar que a IA “funciona” por ter sido usada. O objetivo é criar rastros suficientes para decidir se a funcionalidade deve ser mantida como está, ajustada em certos contextos, limitada a tipos de tarefa específicos ou investigada com pesquisa qualitativa.

Matriz curta de instrumentação para perguntas de produto

Antes de publicar ou revisar uma funcionalidade inteligente, vale mapear cada critério em uma matriz curta.

Pergunta de decisão

Existe uma pergunta explícita que esse dado ajuda a responder?

Bom sinal: o evento ajuda a decidir manter, alterar, investigar, limitar ou remover uma parte da funcionalidade.

Sinal de alerta: o evento só existe porque é fácil de coletar.

Tarefa do usuário

O registro permite identificar qual tarefa estava sendo tentada?

Bom sinal: há tipo de tarefa, etapa do fluxo ou contexto operacional suficiente para análise.

Sinal de alerta: só há contagem de cliques ou chamadas ao modelo.

Execução da IA

O registro diferencia pedido, resposta, tentativa, ferramenta, versão ou fonte de contexto usada?

Bom sinal: é possível comparar comportamentos entre versões ou configurações.

Sinal de alerta: todas as respostas aparecem como uma única categoria genérica.

Resultado observável

Há um sinal verificável depois da resposta da IA?

Bom sinal: aceitação, edição, nova tentativa, abandono, reversão, escalonamento ou conclusão em sistema.

Sinal de alerta: a mensagem da IA dizendo que terminou é tratada como prova de sucesso.

Segmentação mínima

A análise consegue separar tipos de tarefa, usuários, canais ou versões relevantes?

Bom sinal: o time consegue identificar onde a funcionalidade parece funcionar bem e onde degrada.

Sinal de alerta: a média geral esconde grupos com comportamento muito diferente.

Privacidade e necessidade

Cada campo coletado tem finalidade analítica definida?

Bom sinal: dados sensíveis são minimizados, mascarados ou substituídos por categorias quando possível.

Sinal de alerta: o time guarda entradas completas por padrão sem saber como usará.

Qualidade do dado

Há verificação de duplicidade, ausência, atraso e mudança de definição dos eventos?

Bom sinal: antes de decidir, o time sabe se o dado é interpretável.

Sinal de alerta: uma mudança de coleta é confundida com mudança real de comportamento.

Limites da telemetria de produtos com IA

Este guia trata da instrumentação do uso de uma funcionalidade inteligente, não da escolha final de métricas, do desenho completo de experimentos ou do treinamento de modelos.

A telemetria não substitui pesquisa qualitativa, análise de suporte ou avaliações específicas de qualidade. Ela cria rastros para formular perguntas melhores e reduzir decisões baseadas apenas em percepção.

Também é preciso resistir à captura indiscriminada. Nem todo dado útil precisa ser coletado em forma bruta. Em muitos casos, a forma responsável de aprender é reduzir granularidade, categorizar, mascarar, limitar retenção ou combinar telemetria com revisão humana amostral.

A arquitetura mínima fica explícita quando cada funcionalidade inteligente tem eventos, atributos e sinais de resultado capazes de responder: o que o usuário tentou fazer, o que a IA executou e que evidência indica sucesso, correção, abandono ou risco. Se essa separação não estiver clara, o painel pode parecer rico e ainda assim não orientar a investigação seguinte.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.