Notifications
Clear all
Topic starter
20/08/2026 5:53 pm
TL;DR: Syncing AI agent traces into BigQuery and Iceberg lets teams join decisions, costs, infrastructure, and customer outcomes in SQL, turning observability into a durable data layer for operational and business analysis, according to Arize. The governance implication is that agent telemetry is now a control surface, not just a debugging artifact, and it needs identity-aware retention, access, and audit rules.
NHIMG editorial — based on content published by Arize: Data Fabric: Querying agent traces in BigQuery
By the numbers:
- Arize says its Data Fabric syncs trace data to the warehouse in approximately 60 minutes.
- Arize reports that adb has demonstrated from 2.7x to 176x better performance than competing analytical systems.
- Arize's example enterprise support agent handles 10k+ sessions monthly across order status checks, refunds, account updates, and escalations.
Questions worth separating out
Q: How should teams govern AI agent trace data in a warehouse?
A: Treat trace data as governed operational evidence, not throwaway telemetry.
Q: Why do AI agents create new risk in non-human identity management?
A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts.
Q: How do you know if joined AI telemetry is actually working?
A: Look for stable identifiers, reproducible joins, and analysis that answers cost, latency, and business outcome questions without manual stitching.
Practitioner guidance
- Define trace data as governed evidence Classify agent traces, evaluations, and annotations as business records with explicit retention, access, and review rules.
- Review service account access to trace warehouses Audit every non-human principal that can read or write trace tables, external Iceberg metadata, or linked billing datasets.
- Standardise identifiers before joining systems Make session IDs, customer IDs, timestamps, and project labels consistent across traces, billing exports, and infrastructure tables.
What's in the full article
Arize's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step SQL examples for joining traces with billing exports, infrastructure metadata, and customer datasets.
- Implementation details for creating BigQuery external tables over Iceberg metadata in cloud storage.
- Performance and cost considerations for partition pruning, materialised subsets, and warehouse query latency.
- Production examples showing how an enterprise support agent's traces map to cost, latency, and customer outcomes.
👉 Read Arize's analysis of querying AI agent traces in BigQuery →
Agent traces in BigQuery: what it means for AI governance teams?
Explore further
20/08/2026 6:32 pm
Agent traces are becoming governed business records, not disposable telemetry. Once traces are used for cost analysis, customer impact review, and operational debugging, they inherit the same governance requirements as financial and customer data. That creates an identity boundary problem because access to the trace warehouse may expose sensitive prompts, tool invocations, and evaluator outputs. Practitioners should treat trace datasets as controlled evidence, not analyst convenience data.
A question worth separating out:
Q: What should security teams do before exposing trace data to analysts?
A: Restrict raw trace access, separate human and machine roles, and publish curated reporting tables for common use cases. That reduces unnecessary exposure while preserving the evidence needed for incident review, model evaluation, and cost governance.
👉 Read our full editorial: AI agent traces in BigQuery turn observability into business data
