Google Cloud plaatst agenttelemetrie in BigQuery-tabellen van klanten

Google Cloud heeft de monitoring- en evaluatietools voor AI-agents uitgebreid op 13 november 2026. Daarbij zijn logging onder beheer van de klant, dashboards, privacywaarborgen en bestedingslimieten toegevoegd voor BigQuery en Looker, voor zowel beheerde data-agents als aangepaste agents die zijn gebouwd met Agent Development Kit (ADK) of LangGraph.

Het systeem gebruikt één gezamenlijk telemetriepad voor eigen agents en aangepaste agents. Beheerde Conversational Analytics-agents versturen automatisch telemetrie, terwijl aangepaste agents op basis van ADK of LangGraph gestructureerde telemetrie kunnen verzenden met instrumentatie via één regel SDK-code. De gegevens komen terecht in BigQuery-tabellen die eigendom zijn van de klant, zodat ze kunnen worden geanalyseerd in de ontwikkelaars- en beheerderstools van Google Cloud.

Verschillende belangrijke monitoringfuncties zijn algemeen beschikbaar (GA). De vooraf gebouwde dashboards van BigQuery Studio houden het gebruik, actieve sessies, belangrijkste kennisbronnen en latentie bij. Ook de Looker System Activity-dashboards voor Conversational Analytics zijn algemeen beschikbaar in Looker (Google Cloud core) en Looker (original); ze geven inzicht in de betrokkenheid en het tokengebruik. Gebruikersbeoordelingen en het beoordelen van query’s op het tabblad Reacties & feedback zijn nog in de previewfase.

Operationele traces bevatten geen gespreksinhoud

Google Cloud houdt operationele telemetrie gescheiden van gespreksinhoud, zodat beheerders en eigenaren van agents deze twee lagen onafhankelijk van elkaar kunnen beheren. Cloud Monitoring levert geaggregeerde meetgegevens over het aantal verzoeken, de latentie en het tokengebruik, terwijl Cloud Trace voor elk verzoek stapsgewijze spans biedt. Met observability-scopes in Cloud Trace kan telemetrie uit meerdere agentprojecten worden samengevoegd.

Deze operationele meetgegevens en opgeschoonde trace-spans van eigen agents bevatten geen gevoelige klantinhoud, waaronder gebruikersprompts, modelantwoorden, interne redeneringen en gegenereerde SQL. Zo kunnen platformteams de activiteit monitoren zonder operationele tools automatisch toegang te geven tot de inhoud van elke interactie.

Voor uitgebreidere controles kunnen eigenaren en editors van agents ervoor kiezen om gesprekken voor afzonderlijke agents te loggen. Een door Google beheerde serviceagent streamt vervolgens prompts, antwoorden en telemetrie per beurt via de BigQuery Storage Write API naar een door de klant beheerde agent_events tabel. De tabel neemt de identiteits- en toegangsbeheerrechten, door de klant beheerde versleutelingssleutels en VPC Service Controls van de dataset over.

Privacywaarborgen controleren elke beurt voordat die wordt gelogd. Als een kennisbron beveiliging op rijniveau, beleidslabels op kolomniveau of dynamische gegevensmaskering gebruikt, wordt de logging voor die beurt overgeslagen. Bij een loggingfout gaat de chatsessie van de gebruiker gewoon door. Zo maakt het ontwerp onderscheid tussen breed operationeel inzicht en beperktere, expliciet ingeschakelde toegang tot volledige interacties.

Volgens Google Cloud kunnen aangepaste agents meer diagnostische details bewaren met de open-source ADK-plug-in, die volledige bomen van toolaanroepen, tijdreeksgegevens en multimodale gegevens kan streamen naar BigQuery. Bij logging van gesprekken door eigen agents worden low-level argumenten van tools en interne SQL bewust verwijderd.

Bestedingslimieten gaan verder dan dashboards

De logs bieden ook een basis voor kostenbeheer. Voor elke gespreksbeurt in BigQuery worden de aantallen inputtokens, outputtokens, redeneertokens, gecachte tokens en het totale aantal tokens vastgelegd, samen met de totale latentie van de beurt. Looker System Activity rapporteert daarnaast het geschatte aantal input- en outputtokens voor BI-werklasten.

Limieten per query voor het aantal bytes dat in BigQuery wordt gescand, gebruiken schattingen van proefuitvoeringen om te grote query’s te blokkeren zonder kosten voor scans op aanvraag te veroorzaken. Daarnaast zijn dagelijkse quota voor input- en outputtokens voor BigQuery en de Conversational Analytics API in de previewfase. Deze quota kunnen per project, gebruiker of agent worden ingesteld via de Google Cloud-console of gcloud de CLI.

Deze combinatie brengt verbruiksrapportage samen met actieve limieten. Limieten voor gescande bytes voorkomen querykosten voordat een query wordt uitgevoerd, terwijl de quota voor tokens in de previewfase de handhaving uitbreiden naar het verbruik door agents, projecten, gebruikers en afzonderlijke agents.

Evaluatieresultaten staan naast productielogs

Met de open-source tool Prism van Google Cloud kunnen Conversational Analytics-agents worden getest die zijn gebaseerd op BigQuery-tabellen of Looker-verkenningen. De tool ondersteunt herbruikbare testsuites, beweringen op basis van reguliere expressies en het opsporen van agents in meerdere regio’s. De evaluaties richten zich op de nauwkeurigheid van SQL en de kwaliteit van antwoorden, voordat wijzigingen in prompts, modellen of schema’s gebruikers bereiken.

Prism kan afgeronde evaluatieruns wegschrijven naar BigQuery-tabellen die per dag zijn gepartitioneerd, zodat benchmarkresultaten naast productiegegevens komen te staan agent_events voor analyse in BigQuery en Looker. Daarnaast zijn native evaluaties van BigQuery-agents door Google Cloud in de previewfase beschikbaar via een API en een begeleide Colab-notebook.

Met deze aankondiging maakt Google Cloud telemetrie in BigQuery-tabellen van klanten tot de gezamenlijke basis voor monitoring, kostenbeheersing en evaluatie. Zo wordt het toezicht op agents gekoppeld aan bestaande datawarehouse-machtigingen en beveiligingsmaatregelen. Beheerde gesprekslogging en de belangrijkste dashboards zijn algemeen beschikbaar, terwijl tokenquota, native evaluaties en enkele feedbackfuncties van Looker nog in de previewfase zijn. Voor productieteams omvat het implementatieontwerp daarom zowel de scheiding tussen operationele traces en volledige gesprekken als de verschillende beschikbaarheidsstatussen van elke maatregel.