Notifications
Clear all
Topic starter
19/08/2026 3:57 pm
TL;DR: OpenTelemetry can fan out the same production traces to both observability and governed lakehouse storage, allowing engineering teams to debug agent behaviour while data teams query the same telemetry in Unity Catalog, according to Arize. The pattern reduces duplicate pipelines, but it also raises new questions about trace governance, access control, and reuse of AI telemetry across the enterprise.
NHIMG editorial — based on content published by Arize: One agent, two trace destinations: Arize AX + Databricks Unity Catalog
Questions worth separating out
Q: How should teams govern AI traces that are exported to both observability and analytics platforms?
A: Teams should treat dual-export traces as governed data, not just logging output.
Q: Why do production AI traces create security and governance risk?
A: Production traces can include prompts, tool calls, model outputs, and evaluation signals, which means they may expose sensitive context beyond standard application logs.
Q: How do organisations know whether trace data is being reused safely?
A: Look for clear lineage from capture to destination, named owners for each reuse class, and a documented reason for every move from debugging evidence into analytics or training.
Practitioner guidance
- Define trace reuse classes Separate production traces into operational, analytical, and training-eligible classes before they leave the instrumentation layer.
- Enforce export controls at the SDK or collector Treat the TracerProvider and collector pipeline as enforcement points, not just plumbing.
- Classify trace fields before lakehouse ingestion Identify which span attributes contain prompts, model output, customer identifiers, tool parameters, or evaluation data.
What's in the full article
Arize's full article covers the operational implementation details this post intentionally leaves for the source:
- The exact Databricks notebook setup for dual export, including the working code path and runtime assumptions
- The OpenTelemetry and OpenInference dependency details needed to reproduce the integration in a live workspace
- The verification queries used to confirm that spans landed in both Arize AX and Unity Catalog
- The secrets handling and environment configuration steps required to run the example end to end
👉 Read Arize's walkthrough on sending OpenTelemetry traces to Arize AX and Unity Catalog →
OpenTelemetry dual export for AI traces: what changes for governance teams?
Explore further
19/08/2026 4:34 pm
Dual-export telemetry creates governance debt if the organisation cannot explain downstream reuse. The same trace can support debugging, analytics, and model improvement, but each use case implies a different access model and retention rule. Without clear lineage, teams will treat production traces as harmless metadata when they can also expose prompts, tool calls, and decision context. Practitioners should treat trace fan-out as a governance design decision, not just an observability convenience.
A question worth separating out:
Q: What should security teams do before production traces become training data?
A: They should require explicit approval, provenance tracking, and field-level review before any production trace enters a training or evaluation dataset. That prevents operational telemetry from being repurposed without consent, and it keeps AI lifecycle decisions tied to data governance rather than convenience.
👉 Read our full editorial: OpenTelemetry dual export gives AI traces both observability and governance
