Um sistema automatizado onde é impossível saber o que foi feito, quando, com que dados e porquê, não está sendo operado; está sendo mantido em funcionamento. A diferença torna-se evidente no dia em que algo dá errado e, nesse momento, não há como reconstruir o que aconteceu: os dados necessários não foram salvos porque ninguém se deu ao trabalho de salvá-los.
Este é provavelmente o defeito de projeto mais comum nos sistemas de componentes de IA que auditamos, e o mais barato de evitar se for abordado desde o início.
Monitorar significa verificar se o sistema está ativo: se responde, se não apresenta erros e se a latência é aceitável. É necessário, mas não suficiente.
A observação permite responder a perguntas que você não havia previsto. Por que esse caso específico se resolveu dessa maneira? Qual versão do modelo estava envolvida na última terça-feira? Quantas tentativas o sistema precisou fazer antes de responder? Qual a porcentagem de sugestões do agente que são corrigidas antes da aprovação?.
Essa distinção é especialmente importante com componentes probabilísticos, porque um sistema de IA pode estar perfeitamente saudável em termos de infraestrutura — zero erros, baixa latência, disponibilidade total — e ainda assim produzir resultados progressivamente piores. Um painel de monitoramento tradicional não detecta isso. Ele mostra tudo em verde.
Desenvolvemos isso com mais detalhes em Observabilidade LLM, a métrica que ninguém está medindo.
|
Camada |
O que é gravado? |
Para que serve? |
|
Entrada |
Que dados e que contexto o sistema recebeu? |
Reproduza o caso e detecte dados anômalos. |
|
Decisão |
O que o modelo produziu, com qual versão e com qual configuração? |
Explique o resultado e detecte a deriva. |
|
Ação |
O que foi executado em qual sistema? |
Auditoria, estorno e responsabilidade |
|
Validação |
Quem revisou, o que mudou e quando? |
Meça a qualidade real e assegure a supervisão humana. |
|
Custo |
Consumo por execução e por caso de negócio |
Controle do custo unitário em escala |
A camada de validação é a mais frequentemente negligenciada, porém a mais valiosa. Registrar o que a pessoa corrigiu antes da aprovação transforma a supervisão humana em um fluxo de dados sobre a qualidade do sistema. Sem esse registro, o único sinal disponível é a reclamação do cliente, que chega tarde e tendenciosa.
A camada de custos é a segunda mais negligenciada. Um sistema de IA tem um custo variável por execução, o que é incomum em softwares corporativos. Se esse custo não for monitorado por análise de viabilidade, é impossível saber se o processo automatizado é lucrativo, e essa questão sempre surge, geralmente durante a revisão orçamentária do trimestre seguinte.
Os indicadores técnicos — latência, tokens, taxa de erros da API — servem à equipe operacional. Apenas quatro deles são relevantes para um comitê diretivo:
Taxa de aceitação inalterada. Das propostas geradas pelo sistema, qual a porcentagem aprovada sem alterações? Este é o indicador de qualidade mais honesto disponível, pois se baseia no uso no mundo real, e não em testes de laboratório.
Taxa de escala humana. Qual a porcentagem de casos que o sistema não consegue resolver? Deveria haver um valor alvo para isso: se for muito alto, o sistema não está contribuindo; se for zero, provavelmente está resolvendo casos que não deveria.
Custo por caso resolvido. O custo total dividido pelo número de casos efetivamente encerrados, e não pelo número de tentativas. Este é o número que é comparado ao custo do processo anterior.
Tempo de detecção de falhas. Quanto tempo leva para uma organização perceber que o sistema está produzindo resultados incorretos? Se ninguém tiver medido isso, a resposta real geralmente é "quando um cliente reclama".
Essas quatro métricas podem ser apresentadas em um único slide e respondem à única pergunta que importa para o conselho: Isso funciona, quanto custa e quanto tempo leva para descobrirmos se para de funcionar?
Até recentemente, a rastreabilidade era defendida com base em argumentos de engenharia. Desde 2025, surgiu um segundo argumento, mais difícil de refutar em comissão.
O Regulamento Europeu de IA exige, para certas categorias de sistemas, o registo de eventos, documentação técnica e supervisão humana demonstrável. A Estrutura de Gestão de Riscos de IA do NIST estrutura a gestão de riscos em torno da capacidade de medir e monitorizar. A norma ISO/IEC 42001 exige evidências de controlo contínuo para certificar um sistema de gestão de IA.
Todas as três estruturas exigem a mesma coisa, embora com vocabulários diferentes: a capacidade de demonstrar o que o sistema fez. Um sistema que não registra suas ações não pode demonstrá-las, e adicionar essas informações posteriormente exige modificar a arquitetura.
É importante dizer isso claramente porque altera a ordem das prioridades: A observabilidade deixou de ser uma tarefa operacional e tornou-se um requisito de projeto..
Não há necessidade de reescrevê-lo. O caminho usual tem três etapas e pode ser executado sem interromper a operação:
O erro a evitar é tentar implementar tudo de uma vez. Um sistema com duas camadas bem alinhadas é infinitamente mais gerenciável do que um com cinco camadas parcialmente alinhadas.
Antes de considerar um projeto de automação concluído, é aconselhável realizar um teste concreto: Escolha um caso aleatório de três semanas atrás e peça à pessoa que explique exatamente o que aconteceu..
Se a equipe conseguir reconstruir o processo — quais dados foram inseridos, qual versão do modelo foi usada, o que foi executado e quem o validou — o sistema está operacional. Se a resposta começar com "teríamos que analisar os registros, embora eu não saiba se os armazenamos", o sistema está em produção, mas não finalizado.
Trata-se da capacidade de responder a perguntas inesperadas sobre o comportamento do sistema: por que um caso específico foi resolvido de determinada maneira, qual versão do modelo foi utilizada, quantas tentativas foram feitas ou qual a proporção de propostas que estão sendo corrigidas. Difere do monitoramento, que apenas verifica se o sistema está disponível e responsivo.
Cinco camadas: entrada (dados recebidos e contexto), decisão (saída do modelo, versão e configuração), ação (o que foi executado e em qual sistema), validação (o que o revisor corrigiu) e custo por execução e por caso de negócio.
Quatro: taxa de aceitação inalterada, taxa de escalonamento para atendimento humano, custo por caso resolvido e tempo para detecção de falhas. Métricas técnicas como latência ou consumo de tokens servem à equipe de operações, não à tomada de decisão de negócios.
Sim. O Regulamento Europeu de IA exige registro de eventos, documentação técnica e supervisão humana comprovada para certas categorias de sistemas. O NIST AI RMF estrutura a gestão de riscos em torno da capacidade de medir e monitorar, e a norma ISO/IEC 42001 exige evidências de controle contínuo para certificação.
Sim, sem precisar reescrever. A ordem correta é primeiro implementar a entrada e a ação — que permitem reconstruir um incidente — e depois adicionar o registro de validação humana e definir os limites de alerta antes de obter os dados, não depois.
Isso ocorre porque os indicadores de infraestrutura (disponibilidade, latência, erros) podem estar verdes enquanto a qualidade dos resultados se degrada. A qualidade de um componente probabilístico não é medida com ferramentas de monitoramento tradicionais, mas sim com métricas de desempenho baseadas no uso real.
|
Você conseguiria reconstruir hoje o que seu sistema de IA fez há três semanas? Se a resposta não estiver clara, é melhor revisá-la antes que um cliente ou auditor faça a pergunta. Analisaremos seu caso em duas horas, sem compromisso. Vamos conversar → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
