Grafana aplica SLOs e error budgets ao comportamento de agentes de IA

A Grafana Labs publicou uma proposta para resolver um problema que boa parte dos times que colocaram agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → em produção ainda não sabe nomear: como medir se o agente está se comportando bem, e não apenas se está no ar. Em artigo citado pelo InfoQ, a empresa descreve como usar avaliações, SLOs (service-level objectives) e error budgets para transformar comportamentos como alucinação, cumprimento de tarefa, toxicidade e custo em alvos mensuráveis ao longo do tempo.

O problema que a observabilidade tradicional não resolve

Métricas de aplicação convencionais dizem se um agente respondeu rápido, não disparou erro técnico e consumiu X tokens. Nenhuma delas diz se a resposta estava correta, se foi baseada no contexto fornecido ou se foi realmente útil para quem perguntou. É a lacuna clássica entre "o sistema está de pé" e "o sistema está fazendo o que deveria", só que agora aplicada a um componente que decide, em vez de apenas processar.

A saída da Grafana é avaliar o comportamento em si e transformar o resultado dessa avaliação num SLI (service-level indicator), o indicador que depois vira SLO.

Como funciona: avaliação, SLI, SLO e error budget

O primeiro passo é a avaliação: examinar uma interação do agente e decidir se ela atendeu a um critério comportamental específico. A Grafana cita exemplos como verificar se a resposta estava aterrada no contexto fornecido, se cumpriu o pedido do usuário, se continha conteúdo tóxico, se expôs dados pessoais ou se sucumbiu a um ataque de prompt injection. Essas checagens podem usar outro modelo de linguagem como juiz (LLM-as-judge) ou métodos determinísticos, como expressões regulares, quando o comportamento dá para identificar sem precisar de um LLM.

Aqui está uma distinção importante em relação à tentação de criar um "score único de qualidade do agente". A Grafana argumenta que qualidade é multidimensional: um agente pode estar bem aterrado mas caro, útil mas ocasionalmente tóxico, preciso mas lento. Tratar essas dimensões como medições separadas permite definir objetivos diferentes para os comportamentos que importam em cada aplicação, em vez de esconder falhas relevantes dentro de uma média.

Uma vez que um comportamento pode ser medido, os conceitos clássicos de SRE passam a se aplicar direto: define-se o SLI, o alvo (SLO) e a janela de tempo, exatamente como a própria ferramenta de SLO da Grafana já faz para disponibilidade de sistemas tradicionais.

Um exemplo prático de SLO para agentes

A Grafana dá um exemplo concreto: um SLO exigindo que 95% das conversas sejam julgadas como "cumpridas" (fulfilled) ao longo de 30 dias. Os 5% restantes viram o error budget, a quantidade de comportamento inaceitável que o time decidiu explicitamente tolerar naquele período.

O valor do modelo está menos no percentual escolhido e mais na decisão que ele habilita. Com error budget sobrando, o time pode experimentar prompts, trocar de modelo ou ajustar o comportamento do agente. Conforme o budget é consumido, a prioridade muda de experimentação para remediação de qualidade. É a mesma lógica que times de SRE usam há anos para equilibrar confiabilidade contra velocidade de mudança, só que aplicada a respostas em vez de uptime.

A degradação silenciosa que um alerta tradicional não pega

Esse modelo fica particularmente útil quando o comportamento do agente piora aos poucos, em vez de falhar de forma dramática. Um alerta convencional detecta um pico repentino de requisições com erro. Mas um agente pode continuar respondendo com sucesso técnico enquanto suas respostas ficam, sutilmente, menos úteis.

Uma troca de modelo, um ajuste de prompt, uma mudança no mecanismo de retrieval ou até uma mudança no comportamento dos usuários pode corroer a qualidade em frações de ponto percentual por dia. Monitorar o consumo do error budget torna esse tipo de deriva visível: uma interação ruim isolada pode não importar diante de um objetivo de 30 dias, mas um declínio persistente consome o budget de forma acumulada. O sinal relevante deixa de ser "uma execução falhou" e passa a ser "o comportamento agregado do sistema está saindo do envelope de confiabilidade combinado".

O ponto difícil: definir o que é aceitável

A parte mais trabalhosa não é criar o SLO, é decidir o que conta como comportamento aceitável. Para disponibilidade, a indústria tem décadas de experiência operacional para se apoiar. Para saber se um agente deveria cumprir 85%, 95% ou 99% das tarefas, ou manter que nível de aterramento no contexto, não existe esse consenso ainda.

A abordagem da Grafana é estabelecer uma linha de base por meio de avaliações e usar os resultados históricos para recomendar um alvo inicial, que pode ser apertado conforme o agente amadurece. A ideia nasceu de um problema interno: o trabalho de Agent Observability da própria Grafana surgiu da necessidade de monitorar o Grafana Assistant, quando mudanças de prompt, modelo e ferramentas tornaram o monitoramento tradicional insuficiente. Em discussões da comunidade, engenheiros da Grafana distinguem avaliações offline, que validam mudanças contra cenários conhecidos, de avaliações online, que medem o comportamento contra interações reais de produção.

As limitações: o SLO só vale o que a avaliação vale

Um SLO é tão confiável quanto a medição por trás dele. Se um LLM-juiz classifica errado de forma sistemática, o error budget resultante passa uma falsa sensação de precisão. Da mesma forma, uma avaliação mal desenhada pode recompensar um agente por produzir saídas que tecnicamente satisfazem um critério, mas falham em atender à intenção real do usuário.

Na prática, isso significa que organizações ainda precisam de datasets de avaliação representativos, definições claras do que é comportamento aceitável, checagens determinísticas onde for possível, revisão humana para casos ambíguos e validação contínua dos próprios avaliadores. O SLO dá o mecanismo de governança; ele não torna a medição de qualidade, por si só, correta.

O panorama mais amplo: Anthropic e OpenTelemetry

A proposta da Grafana se soma a um esforço mais amplo da indústria para tornar o comportamento de agentes mensurável, com outras empresas atacando o problema por ângulos diferentes. A Anthropic desenvolveu práticas de avaliação mais formais para agentes, usando tarefas definidas, repetição de testes e múltiplos avaliadores para medir se um agente alcança o resultado pretendido de forma consistente. A distinção entre pass@k, que mede se o agente acerta ao menos uma vez em várias tentativas, e pass^k, que mede se ele acerta de forma consistente em todas as tentativas, é especialmente relevante para agentes em produção, onde confiabilidade pesa mais do que encontrar a resposta certa eventualmente.

Já o OpenTelemetry ataca o problema em outra camada, trabalhando em convenções semânticas padronizadas para telemetria de agentes, de modo que traces, métricas e logs ofereçam uma base consistente para avaliar comportamento entre diferentes frameworks e fornecedores. O padrão que emerge: avaliações dizem se o agente se comportou corretamente, observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → fornece a evidência, e SLOs dão o limiar operacional para decidir se esse comportamento é aceitável.

O que muda para quem constrói agentes no Brasil

Times brasileiros que já usam Grafana e Prometheus para SRE de APIs e microsserviços↳Microsserviços24 conteúdosArquitetura de Microsserviços em Node com o MoleculerJSDev (Back & Front) · jun 2025Segurança das APIs: como proteger seu ecossistema de microsserviçosDev (Back & Front) · dez 2023Você provavelmente não precisa de microsserviços (ainda)Dev (Back & Front) · mar 2026Ver tudo em Dev (Back & Front) → têm o caminho técnico mais curto para adotar esse modelo: a mesma mecânica de SLI, SLO e error budget que já roda para latência e disponibilidade pode ser estendida para o agente de atendimento, o copiloto interno ou o assistente de busca que foi para produção nos últimos meses.

O ganho prático é separar "o agente está no ar" de "o agente está confiável". Um bot de suporte pode responder 200ms mais rápido e continuar dando respostas cada vez menos aterradas no conteúdo da base de conhecimento, sem que nenhum alerta tradicional dispare. Definir um SLO de fulfillment ou de groundedness, mesmo que arbitrário no começo, dá ao time um sinal objetivo para decidir quando parar de experimentar com prompt ou modelo e investir em corrigir qualidade antes do próximo deploy.

Fonte: InfoQ