Produção de IA é um alvo móvel. Depois de implantar um agente de IA, seu comportamento pode mudar sem que uma única linha de código seja alterada. Como a equipe do Microsoft Foundry afirma: "A parte difícil não é fazer o agente funcionar — é mantê-lo funcionando". A Microsoft endereçou esse desafio tornando Evaluation, Monitoring e Tracing no Microsoft Foundry geralmente disponíveis por meio do Foundry Control Plane, profundamente integrados ao Azure Monitor — a observabilidade de agentes de IA vive no mesmo plano operacional da telemetria de infraestrutura existente.
TL;DR: O Microsoft Foundry tornou GA (março/2026) os três pilares de observabilidade para agentes de IA: Evaluation, Monitoring e Tracing, todos integrados ao Azure Monitor. Agora é possível tratar groundedness, alucinação e segurança como métricas operacionais contínuas, não como checklists pré-deploy. Para empresas brasileiras, isso significa detectar regressões invisíveis em APM tradicional — como deriva de modelo, prompt injection e vazamento de dados — com sampling recomendado de 5–10% do tráfego para equilibrar custo e detecção.
Este artigo, Parte 1 de uma série de duas partes, cobre por que o monitoramento de IA exige novas abordagens, quais capacidades de observabilidade o Microsoft Foundry oferece e como elas se encaixam no kit de ferramentas operacionais, de segurança e de governança de custos de uma empresa. A Parte 2 trará um guia de configuração passo a passo.
Nota do portal: Este artigo foca exclusivamente na experiência do Foundry (novo portal). Certifique-se de que a opção "New Foundry" esteja ativada no banner do seu portal para confirmar que você está usando a experiência atual.
Por que o monitoramento contínuo de IA é crítico?
O monitoramento tradicional de performance de aplicações (APM) — uptime, CPU/memória, latency de requisições, taxas de erro — continua necessário para serviços de IA, mas está longe de ser suficiente. Sistemas de IA podem falhar de maneiras que aplicações web clássicas jamais falhariam: retornar respostas sutilmente erradas, vazar dados sensíveis nas respostas ou degradar gradualmente a qualidade ao longo do tempo. Essas falhas são invisíveis para métricas de uptime.
O comportamento de um sistema de IA é função de forças que mudam independentemente do seu código:
| Força | O que muda | Impacto |
|---|---|---|
| Atualizações do modelo fundação | Provedores lançam novas versões continuamente | Estilo de saída, padrões de raciocínio e tratamento de casos limite podem mudar sem ação sua |
| Alterações de prompt | Time ajusta prompts de sistema ou usuário | Efeitos não lineares downstream, especialmente em fluxos agenticos com múltiplos passos |
| Deriva do pipeline de retrieval | Índices de documentos, bancos de dados ou bases de conhecimento evoluem | O contexto que um agente vê em inferência hoje pode diferir do que viu durante os testes. Dados desatualizados reduzem a precisão |
| Distribuição real de consultas | Usuários enviam consultas nunca previstas em datasets de teste | Entradas de cauda longa revelam modos de falha invisíveis durante o desenvolvimento |
A maioria dos workflows de evaluation é projetada em torno de uma gate pré-implantação: construir um dataset de teste, rodar avaliações, revisar scores, publicar. Essa abordagem tem valor real, mas um teto duro. A implicação é clara: a avaliação precisa ser contínua, não episódica. Sinais de qualidade são necessários no momento do desenvolvimento, em cada commit de CI/CD, e continuamente contra tráfego de produção ao vivo — usando as mesmas definições de evaluator para que os resultados sejam comparáveis entre ambientes.
Tradeoff a considerar: A avaliação contínua de tráfego de produção incorre em invocações adicionais de modelo (e, portanto, custo) para os modelos avaliadores. Arquitetos precisam equilibrar a taxa de sampling contra o custo de regressões perdidas. Monitorar 100% do tráfego pode ser proibitivo em custo, mas uma taxa muito baixa corre o risco de perder quedas transitórias de qualidade. Uma abordagem prática inicial: configurar uma taxa de sampling modesta (por exemplo, 5–10% das consultas de produção) e ajustar com base na variância observada e no orçamento.
Quais são os três pilares de observabilidade do Foundry?
O Microsoft Foundry oferece três capacidades principais que funcionam juntas ao longo de todo o ciclo de vida da aplicação de IA: Evaluation, Monitoring e Tracing. Todas são profundamente integradas ao Azure Monitor e atingiram disponibilidade geral em março de 2026.
Pilar 1: Evaluation Contínua — "Quão boas são as saídas da minha IA?"
Evaluators nativos (GA): O Foundry vem com evaluators padronizados que cobrem as dimensões mais críticas de qualidade e segurança para sistemas agenticos em produção:
| Evaluator | O que mede | Por que importa |
|---|---|---|
| Coerência e Relevância | Se as respostas são internamente consistentes e no tópico em relação à entrada | Sinal básico para qualquer agente conversacional ou de conclusão de tarefas |
| Groundedness | Se a saída do modelo é realmente suportada pelo contexto recuperado (e não alucinada da memória paramétrica) | Indicador líder de risco de alucinação em produção; frequentemente invisível para revisores humanos em escala |
| Qualidade de Retrieval | Se o passo de retrieval trouxe contexto relevante, independentemente da qualidade da geração | Isola a causa raiz: o modelo está ignorando bom contexto ou o pipeline de retrieval está falhando? |
| Segurança e Alinhamento com Políticas | Se as saídas atendem aos requisitos de política de implantação: segurança de conteúdo, restrições de tópico, conformidade de formato | Garante que agentes implantados respeitem limites organizacionais e regulatórios |
Groundedness merece atenção particular em arquiteturas RAG. Falhas de groundedness podem se originar em dois lugares: o modelo pode estar ignorando bom contexto, ou o pipeline de retrieval pode não estar trazendo contexto relevante em primeiro lugar. Ao separar groundedness e qualidade de retrieval em sinais distintos, o Foundry torna a análise de causa raiz muito mais tratável.
Os evaluators rodam em três estágios do ciclo de vida:
- Desenvolvimento local — execute avaliações inline enquanto itera em prompts, configuração de retrieval ou lógica de orquestração.
- Pipelines CI/CD — gateie cada commit contra baselines de qualidade; pegue regressões antes que cheguem à produção.
- Monitoramento de tráfego de produção — avalie continuamente o tráfego ao vivo amostrado e exiba tendências ao longo do tempo.
Como os evaluators são idênticos nos três contextos, uma pontuação no CI significa a mesma coisa que uma pontuação no monitoramento de produção.
Evaluators customizados (Public Preview): Agentes em produção frequentemente precisam atender a critérios específicos de um domínio, ambiente regulatório ou padrão interno. O Foundry suporta dois tipos:
- LLM-as-a-Judge: Configure um prompt e uma rubrica de notas (ex.: escala de 1 a 5 com critérios para cada nível), depois use um modelo de linguagem para aplicar essa rubrica em escala.
- Code-based evaluators: Funções Python implementando qualquer lógica de avaliação programável: regex, validação de schema, regras de negócio, asserções de compliance ou chamadas a sistemas externos.
Evaluators customizados e nativos compõem-se naturalmente — rodam contra o mesmo tráfego, produzem resultados no mesmo schema e alimentam os mesmos dashboards e regras de alerta.
Configurações adicionais na aba Monitor do agente:
| Configuração | Status | Propósito |
|---|---|---|
| Continuous evaluation | GA | Roda avaliações em respostas amostradas do agente. Configure evaluators e taxa de sampling |
| Scheduled evaluations | Preview | Roda avaliações em um cronograma para validar performance contra benchmarks |
| Red team scans | Preview | Roda testes adversariais para detectar riscos como vazamento de dados ou ações proibidas |
| Alerts | Preview | Detecta anomalias de performance, falhas de avaliação e riscos de segurança; configurável para latency, uso de tokens, scores de avaliação ou achados de red team |
Essas configurações são acessíveis pelo ícone de engrenagem na aba Monitor de um determinado agente. Para habilitar regras de avaliação contínua, a identidade gerenciada do projeto deve ter o papel Azure AI User.
Pilar 2: Monitoramento Integrado e Azure Monitor — "Meu serviço de IA está performando bem?"
Todos os dados de observabilidade produzidos pelo Foundry — resultados de avaliação, traces, latency, uso de tokens e métricas de qualidade — são publicados diretamente no Azure Monitor. Essa integração profunda desbloqueia quatro capacidades que ferramentas de monitoramento de IA isoladas não conseguem igualar:
| Capacidade | Descrição |
|---|---|
| Correlação cross-stack | Quando um score de groundedness cai, determine se a causa é uma atualização de modelo, um problema no pipeline de retrieval ou um problema de infraestrutura. Tudo no mesmo workspace do Application Insights, em minutos em vez de horas |
| Alertas unificados | Configure regras de alerta do Azure Monitor em qualquer métrica de avaliação — dispare um incidente PagerDuty quando groundedness cair abaixo do threshold, envie uma notificação Teams quando violações de segurança dispararem ou crie respostas automatizadas de runbook quando a qualidade de retrieval degradar |
| Governança empresarial por padrão | RBAC, políticas de retenção, configurações de diagnóstico e logging de auditoria do Azure Monitor se aplicam automaticamente a todos os dados de observabilidade de IA. As organizações herdam a estrutura de governança já construída e aprovada |
| Integração com Grafana | Para equipes que usam Azure Managed Grafana, as métricas de avaliação fluem para dashboards existentes ao lado de outras métricas operacionais. Um único painel para saúde da aplicação, performance da infraestrutura e qualidade do agente de IA |
O Dashboard de Monitoramento de Agentes no portal do Foundry oferece uma visão nativa de IA pronta para uso. Tendências de métricas de avaliação, status de threshold de segurança, distribuições de scores de qualidade e breakdowns de latency. Tudo nesse dashboard é alimentado por dados do Azure Monitor, permitindo que times de SRE aprofundem a qualquer momento.
Como acessar o monitoramento no nível do agente no novo portal: Navegue até a página Build usando a navegação superior, selecione o agente desejado e depois selecione a aba Monitor para visualizar dados operacionais, de avaliação e de red teaming. O dashboard consiste em cards de resumo no topo para métricas de alto nível e gráficos abaixo para detalhes granulares, refletindo dados do intervalo de tempo selecionado.
Definições das métricas do dashboard:
- Uso de tokens: Contagens de tokens para tráfego do agente. Alto uso pode indicar prompts ou respostas verbosas que poderiam ser otimizadas.
- Latency: Tempo de resposta para execuções do agente. Latency acima de 10 segundos pode indicar throttling de modelo, chamadas complexas de ferramentas ou problemas de rede.
- Taxa de sucesso de execução: Percentual de execuções que completam com sucesso. Uma taxa abaixo de 95% justifica investigação nas execuções falhas.
- Métricas de avaliação: Scores produzidos pelos evaluators em saídas amostradas do agente. Scores variam por evaluator; consulte a documentação individual para interpretação.
- Resultados de red teaming: Resultados de varreduras de red team agendadas, se habilitadas. Varreduras falhas indicam riscos potenciais de segurança que exigem remediação.
Os dados de monitoramento são armazenados no recurso Application Insights conectado. Retenção e faturamento seguem a configuração do Application Insights. O Dashboard de Monitoramento de Agentes lê telemetria desse recurso conectado. Se o Application Insights não estiver conectado, nenhum dado aparece.
Nota: Embora as capacidades subjacentes de Evaluation e Monitoring sejam GA, a experiência "View agent metrics" no portal está atualmente marcada como (preview). Isso significa que o pipeline de dados subjacente e a integração com Azure Monitor são de nível de produção, mas a UI do portal pode ainda evoluir.
Visibilidade em nível de frota via Operate: Para organizações que gerenciam múltiplos agentes entre projetos, a seção Operate fornece supervisão em nível de assinatura através do painel Overview (saúde da frota, agentes ativos, tendências de custo, taxa de conclusão de execuções, comportamentos prevenidos) e do painel Assets (uma tabela unificada e pesquisável de cada agente, modelo e ferramenta com scores de saúde, custo, alertas e uso de tokens). De qualquer entrada na tabela Assets, você pode ir diretamente para a aba Evaluation ou Monitoring do agente para insights pré e pós-implantação.
Pilar 3: Tracing de Ponta a Ponta — "O que exatamente aconteceu durante esta requisição de IA?"
Um score de qualidade diz que algo está errado. Um trace diz exatamente onde a falha ocorreu e o que o agente realmente fez.
O Foundry oferece tracing distribuído baseado em OpenTelemetry que acompanha cada requisição através de todo o sistema do agente: chamadas de modelo, invocações de ferramentas, passos de retrieval, lógica de orquestração e handoffs entre agentes. Os traces capturam o caminho completo de execução — entradas, saídas, latency em cada passo, parâmetros e respostas de chamadas de ferramentas e uso de tokens.
A decisão de design chave: os resultados de avaliação são vinculados diretamente aos traces. Quando você vê um score baixo de groundedness no dashboard de monitoramento, navega diretamente para o trace específico que o produziu — sem correlação manual de timestamp, sem busca separada por ID de trace. A conexão é feita automaticamente. Isso é o que torna os três pilares um sistema, não ferramentas isoladas: evaluation identifica o problema, monitoring exibe a tendência e tracing aponta a causa.
Coleta automática de frameworks: O Foundry coleta automaticamente traces dos frameworks mais comuns:
- Microsoft Agent Framework
- Semantic Kernel
- LangChain e LangGraph
- OpenAI Agents SDK
Para frameworks de orquestração customizados ou menos comuns, o Azure Monitor OpenTelemetry Distro oferece um caminho de instrumentação.
Consideração de custo: Tracing armazena telemetria no Application Insights do Azure Monitor, que pode incorrer em custos com base no volume de dados e configurações de retenção. Retenção e faturamento seguem a configuração do Application Insights. Arquitetos devem considerar isso no planejamento de capacidade, especialmente para implantações de agentes de alta throughput.
Segurança, Compliance e IA Responsável
Monitorar sistemas de IA deve ir além de performance e qualidade para cobrir segurança e governança. Construir workloads de IA introduz desafios únicos de segurança:
| Risco | Descrição |
|---|---|
| Prompt injection | Entradas maliciosas criadas para manipular o comportamento do modelo ou burlar controles de segurança |
| Vazamento de dados sensíveis | Modelos expondo inadvertidamente informações confidenciais nas respostas |
| Uso indevido do modelo | Uso não autorizado ou abusivo das capacidades de IA que viola políticas organizacionais |
Microsoft Foundry, Defender for Cloud e Microsoft Purview abordam esses riscos em combinação:
| Camada | Ferramenta | Função |
|---|---|---|
| Camada de Modelo | Foundry Guardrails | Filtros de conteúdo, prompt shields e detecção de abuso protegem endpoints de inferência gerenciados |
| Detecção de Ameaças | Defender for Cloud | Recomendações de postura de segurança identificam má configuração; proteção contra ameaças para Foundry Tools detecta ataques de jailbreak e input de usuário |
| Governança de Dados | Microsoft Purview | Auditoria, classificação de tipos de informações sensíveis (SIT) e DSPM para IA fornecem visibilidade e governança sobre dados de prompt e resposta |
| Runtime de Terceiros | Palo Alto Prisma AIRS + Zenity (GA) | Integrações de segurança runtime para detecção de prompt injection, vazamento de dados e uso indevido de ferramentas |
Navegando pela Compliance no Novo Portal
Foundry Control Plane centraliza compliance, inventário, observabilidade e segurança em uma única interface ciente de papéis. As capacidades são organizadas em painéis acessados ao selecionar Operate na barra de ferramentas superior direita do workspace do Foundry. A partir de Operate, você pode monitorar, governar e otimizar cada agente, modelo e implantação dentro da sua assinatura.
O painel Compliance permite definir, aplicar e monitorar continuamente guardrails e políticas de compliance em todos os seus recursos de IA. Ele fornece uma interface unificada para operacionalizar princípios de IA responsável enquanto ajuda a garantir segurança e alinhamento regulatório em nível empresarial. Capacidades específicas incluem:
- Definir e aplicar proteções através de integrações profundas com Azure Policy, Defender e Microsoft Purview, garantindo que salvaguardas de identidade, dados e ameaças funcionem em conjunto.
- Aplicar políticas com versionamento e rastrear atribuições para manter auditabilidade e rastreabilidade completas entre agentes e ambientes.
- Monitorar postura de compliance em tempo real, exibindo ativos não conformes e permitindo remediação em massa diretamente do Foundry Control Plane.
Dentro do painel Compliance, há quatro abas para navegação:
| Aba | Caminho de Acesso | Resultado |
|---|---|---|
| Policies | Operate > Compliance > Policies | Revisar políticas de guardrail, verificar compliance, criar ou editar regras de enforcement |
| Assets | Operate > Compliance > Assets | Inspecionar implantações de modelo individuais, visualizar violações de política, ir para remediação |
| Guardrails | Operate > Compliance > Guardrails | Comparar configurações de guardrail entre implantações, identificar lacunas de cobertura |
| Security posture | Operate > Compliance > Security posture | Revisar recomendações do Defender for Cloud, gerenciar ativação do Microsoft Purview |
Acesse o workspace de compliance selecionando Operate na barra de ferramentas e depois Compliance no painel esquerdo. Use os filtros de assinatura e projeto para escopar sua visão antes de alternar entre abas.
Pré-requisitos de visibilidade: O workspace de compliance está disponível apenas no portal Foundry (novo). Se você não vir o painel Compliance ou suas sub-abas, verifique: (1) a opção "New Foundry" está ativada no banner do portal, (2) você tem as permissões necessárias e (3) está usando as versões mais recentes dos agentes para suporte total das funcionalidades de compliance. Alguns itens na documentação de compliance estão marcados como (preview) e estão em public preview. Permissões necessárias: visualizar status de compliance não precisa de permissões especiais além de acesso ao projeto; criar ou editar políticas de guardrail requer Owner ou Resource Policy Contributor no nível da assinatura ou grupo de recursos; ativar Defender for Cloud requer Security Admin ou Owner; configurar Microsoft Purview requer Azure AI Account Owner.
Políticas de guardrail permitem que equipes centrais determinem controles mínimos de guardrail (filtragem de conteúdo, monitoramento de abuso e outras medidas de segurança) para implantações de modelo em uma assinatura ou dentro de um grupo de recursos. Políticas de guardrail não conformes exibem um valor "Violations detected" na coluna Policy Compliance. Selecionar uma política não conforme abre um painel comparando as configurações de guardrail do ativo com os requisitos da política; selecionar "Fix now" abre o painel de configuração de guardrail da implantação do modelo onde você pode ajustar as configurações. O status de compliance é atualizado em alguns minutos após salvar as alterações.
Integração com Defender for Cloud: Para obter recomendações de postura de segurança do Defender for Cloud, ative-o em sua assinatura Azure. Para receber alertas de proteção contra ameaças para ataques de jailbreak baseados em detecção de risco no Foundry para ataques de input de usuário, ative a proteção contra ameaças para Foundry Tools especificamente. Ataques de jailbreak tentam contornar medidas de segurança de IA usando prompts cuidadosamente elaborados, e o Foundry detecta esses padrões de ataque no input do usuário. Recomendações e alertas cobrem workloads de IA construídas em endpoints de inferência gerenciados do Foundry. Detecções para jailbreak e ataques de prompt aparecem como alertas do Defender e podem ser correlacionadas com registros de auditoria do Microsoft Purview de interações de IA para suporte a investigação e governança.
Integração com Microsoft Purview (preview): Quando ativada via aba Security posture (Operate > Compliance > Security posture), o Purview acessa, processa e armazena dados de prompt e resposta de apps e agentes Foundry, incluindo metadados associados. Cenários suportados incluem: Microsoft Purview Audit, classificação de tipos de informações sensíveis, DSPM para IA, Insider Risk Management, Communication Compliance, Data Lifecycle Management e eDiscovery. As políticas de segurança de dados do Microsoft Purview exigem tokens de contexto de usuário do Microsoft Entra ID para anexar políticas a interações de usuário. A integração com Microsoft Purview ainda não suporta isolamento de rede.
Tradeoff: Ativar a proteção de workload de IA do Defender for Cloud e o DSPM para IA do Purview introduz custos adicionais de serviço Azure e complexidade de configuração. Para workloads não regulamentadas com perfis de risco mais baixos, as equipes podem começar apenas com os guardrails nativos do Foundry e adicionar Defender/Purview conforme a implantação amadurece.
Monitoramento de Custo e Cota
O consumo de tokens é o principal driver de custo para workloads de IA generativa. O Dashboard de Monitoramento de Agentes do Foundry exibe o uso de tokens como métrica chave — contagens de tokens para tráfego do agente no intervalo de tempo selecionado. Alto uso de tokens pode indicar prompts ou respostas verbosas que poderiam ser otimizadas.
O painel Operate > Quota mostra implantações de modelo e quanto de cota cada implantação consome, fornecendo insights sobre padrões de uso e ajudando a gerenciar recursos de forma eficaz. Por padrão, a visualização de cota exibe apenas modelos com implantações ativas; ativar a opção Show all revela a lista completa de modelos e regiões disponíveis, incluindo modelos ainda não implantados — útil para verificar capacidade antes de criar uma implantação.
O painel Operate > Overview agrega métricas operacionais chave incluindo tendências de custo e uso de tokens em toda a sua frota de IA, permitindo aprofundar em anomalias ou picos de custo através de gráficos contextuais e links diretos para inventário, observabilidade ou informações de política. Da mesma forma, o painel Assets permite filtrar e ordenar por custo, uso de tokens e outros atributos para localizar rapidamente agentes ou modelos intensivos em recursos.
O Foundry Control Plane também suporta rastreamento de rate limits, uso de tokens e anomalias de custo para prevenir ineficiência ou abuso. Ao combinar essa visibilidade no portal com as capacidades de alerta do Azure Monitor e as ferramentas de orçamento do Azure Cost Management, as equipes podem construir governança proativa de custos em vez de reagir a contas inesperadas.
Conclusão e Próximos Passos
A observabilidade integrada do Microsoft Foundry — Evaluation, Monitoring e Tracing, todos geralmente disponíveis através do Foundry Control Plane — combinada com a integração profunda ao Azure Monitor e o workspace de Compliance para governança de guardrails, torna possível tratar a qualidade e a segurança da IA como sinais operacionais ao vivo, não como checkboxes pré-implantação.
O contexto mais amplo da plataforma reforça por que a observabilidade importa agora: o Foundry Agent Service (GA) fornece um runtime pronto para produção construído sobre a Responses API, com segurança empresarial, rede privada e tracing completo — tudo gerenciável através da visibilidade em nível de frota do Foundry Control Plane, enforcement de compliance e capacidades de segurança. À medida que as organizações evoluem de copilotos isolados para frotas autônomas multi-agentes, a necessidade de supervisão unificada cresce.
Prompt Optimizer (atualmente em public preview) adiciona uma dimensão de feedback loop: ele analisa prompts existentes e aplica técnicas estruturadas de engenharia de prompt, esclarecendo instruções ambíguas, melhorando a formatação para compreensão do modelo e reestruturando exemplos few-shot com explicações no nível de parágrafo para cada alteração que faz. Em vez de produzir um prompt "otimizado" em caixa preta, ele mostra exatamente o que mudou e por quê. Isso fecha o loop entre insights de monitoramento ("groundedness está baixo") e melhoria de prompt ("aqui está o que mudar e por quê").
Na Parte 2, vamos colocar a mão na massa: conectar o Application Insights a um projeto Foundry, instrumentar agentes para tracing, habilitar avaliações contínuas, configurar alertas do Azure Monitor para métricas específicas de IA e implementar políticas de guardrail. Com passos no portal e exemplos de código. Fique ligado.
Perguntas Frequentes
-
Como o Microsoft Foundry detecta alucinações (groundedness) em produção?
O Foundry oferece um evaluator específico de Groundedness que verifica se a resposta do modelo é suportada pelo contexto recuperado (RAG). Ele separa o sinal de retrieval quality para isolar a causa raiz: se o problema é o modelo ignorar contexto bom ou o pipeline de retrieval não trazer o conteúdo certo. -
Quais são os custos adicionais de monitoramento contínuo no Foundry?
A avaliação contínua de tráfego de produção incorre em invocações extras de modelo (para os evaluators LLM-as-a-Judge) e armazenamento de traces no Application Insights. A recomendação prática é iniciar com sampling de 5–10% do tráfego e ajustar conforme orçamento e variabilidade observada. -
Como o Foundry se integra com ferramentas de segurança como Defender for Cloud e Purview?
O Foundry Control Plane se integra ao Defender for Cloud para detectar jailbreak e prompt injection, e ao Microsoft Purview para classificar dados sensíveis (SIT) e auditar interações. Ambas exigem custos adicionais de serviço Azure e permissões específicas (Security Admin, Azure AI Account Owner). -
É possível usar o Foundry com frameworks como LangChain ou Semantic Kernel?
Sim. O Foundry faz auto-coleta de traces para Microsoft Agent Framework, Semantic Kernel, LangChain/LangGraph e OpenAI Agents SDK. Para frameworks customizados, o Azure Monitor OpenTelemetry Distro oferece um caminho de instrumentação manual.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
