Google Cloud stocke les données télémétriques des agents dans des tables BigQuery appartenant aux clients

Google Cloud a étoffé ses outils de surveillance et d’évaluation des agents d’IA le 13 novembre 2026, en ajoutant la journalisation contrôlée par les clients, des tableaux de bord, des mesures de protection de la vie privée et des plafonds de dépenses dans BigQuery et Looker, pour les agents de données gérés et les agents personnalisés créés avec Agent Development Kit (ADK) ou LangGraph.

Le système utilise une voie de télémétrie commune pour les agents natifs et personnalisés. Les agents Conversational Analytics gérés émettent automatiquement des données télémétriques, tandis que les agents personnalisés créés avec ADK ou LangGraph peuvent envoyer des données structurées grâce à une instrumentation du SDK en une seule ligne. Les données sont stockées dans des tables BigQuery appartenant au client, où elles peuvent être analysées à l’aide des outils de développement et d’administration de Google Cloud.

Plusieurs fonctionnalités essentielles de surveillance sont généralement disponibles (GA). Les tableaux de bord prédéfinis de BigQuery Studio suivent l’utilisation, les sessions actives, les principales sources de connaissances et la latence. Les tableaux de bord Looker System Activity pour Conversational Analytics sont également généralement disponibles dans Looker (Google Cloud core) et Looker (original) ; ils couvrent l’engagement et l’utilisation des jetons. Les évaluations des utilisateurs et l’examen des requêtes dans l’onglet Réponses et commentaires restent en version préliminaire.

Les traces opérationnelles excluent le contenu des conversations

Google Cloud sépare les données télémétriques opérationnelles du contenu des conversations afin que les administrateurs et les propriétaires d’agents puissent gérer ces deux couches indépendamment. Cloud Monitoring fournit des métriques agrégées sur le volume des requêtes, la latence et l’utilisation des jetons, tandis que Cloud Trace présente des segments détaillés, étape par étape, pour chaque requête. Les périmètres d’observabilité de Cloud Trace peuvent regrouper les données télémétriques de plusieurs projets d’agents.

Ces métriques opérationnelles et les segments de trace natifs assainis excluent le contenu essentiel des clients, notamment les requêtes des utilisateurs, les réponses des modèles, les réflexions internes et le code SQL généré. Les équipes de plateforme peuvent ainsi surveiller l’activité sans que les outils opérationnels aient automatiquement accès au contenu de chaque interaction.

Pour approfondir les audits, les propriétaires et les éditeurs d’agents peuvent choisir d’activer la journalisation des conversations pour des agents individuels. Un agent de service géré par Google transmet alors les requêtes, les réponses et les données télémétriques de chaque tour au moyen de l’API BigQuery Storage Write, dans une table BigQuery appartenant au client. agent_events Cette table hérite des autorisations de gestion des identités et des accès du jeu de données, des clés de chiffrement gérées par le client et des contrôles de service VPC.

Les mesures de protection de la vie privée vérifient chaque tour avant sa journalisation et omettent celui-ci si une source de connaissances utilise la sécurité au niveau des lignes, des balises de stratégie au niveau des colonnes ou le masquage dynamique des données. En cas d’erreur de journalisation, la session de discussion de l’utilisateur se poursuit sans interruption. La conception distingue ainsi une visibilité opérationnelle étendue d’un accès plus restreint, explicitement activé, à l’intégralité des interactions.

Selon Google Cloud, les agents personnalisés peuvent conserver davantage de détails de diagnostic grâce au plug-in ADK open source, qui peut transmettre à BigQuery des arborescences complètes d’appels d’outils, des données télémétriques de séries chronologiques et des charges utiles multimodales. La journalisation des conversations des agents natifs supprime délibérément les arguments détaillés des outils et le code SQL interne.

Les plafonds de dépenses vont au-delà des tableaux de bord

Les journaux servent également de base à la gestion des coûts. Pour chaque tour de conversation dans BigQuery, ils consignent le nombre de jetons en entrée, en sortie, de réflexion, mis en cache et au total, ainsi que la latence totale du tour. Looker System Activity indique séparément les nombres estimés de jetons en entrée et en sortie pour les charges de travail de veille stratégique.

Les plafonds par requête sur le nombre d’octets analysés dans BigQuery s’appuient sur des estimations d’exécution à blanc pour bloquer les requêtes trop volumineuses sans générer de frais d’analyse à la demande. Par ailleurs, les quotas quotidiens de jetons en entrée et en sortie pour BigQuery et l’API Conversational Analytics sont en version préliminaire. Ces quotas peuvent être appliqués par projet, par utilisateur ou par agent au moyen de la console Google Cloud ou gcloud de l’interface de ligne de commande.

Cette combinaison associe le suivi de la consommation à des limites actives. Les plafonds sur les octets analysés permettent de maîtriser les dépenses liées aux requêtes avant leur exécution, tandis que les quotas de jetons en version préliminaire étendent le contrôle de la consommation des agents à plusieurs projets, utilisateurs et agents individuels.

Les résultats d’évaluation côtoient les journaux de production

L’outil open source Prism de Google Cloud évalue les agents Conversational Analytics qui s’appuient sur des tables BigQuery ou des explorations Looker. Il prend en charge des suites de tests réutilisables, des assertions fondées sur des expressions régulières et la détection d’agents dans plusieurs régions. Les évaluations portent sur la précision du code SQL et la qualité des réponses, avant que les modifications apportées aux invites, aux modèles ou aux schémas ne soient mises à la disposition des utilisateurs.

Prism peut écrire les évaluations terminées dans des tables BigQuery partitionnées par jour, afin de placer les résultats de référence aux côtés des enregistrements de production agent_events pour les analyser dans BigQuery et Looker. Les évaluations natives des agents BigQuery sont également disponibles séparément en version préliminaire, par l’intermédiaire d’une API et d’un notebook Colab guidé.

Cette annonce fait de la télémétrie BigQuery appartenant aux clients la couche commune de surveillance, de contrôle des coûts et d’évaluation, en reliant la supervision des agents aux autorisations et aux contrôles de sécurité déjà en place dans l’entrepôt de données. La journalisation des conversations gérées et les principaux tableaux de bord sont généralement disponibles, tandis que les quotas de jetons, les évaluations natives et certaines fonctionnalités de commentaires dans Looker restent en version préliminaire. Pour les équipes de production, la conception du déploiement doit donc tenir compte à la fois de la séparation entre les traces opérationnelles et les conversations complètes, et des différents niveaux de disponibilité de chaque contrôle.