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.
Editorial analysis by NHI Mgmt Group, based on content published by Arize: “One agent, two trace destinations: Arize AX + Databricks Unity Catalog”.
Key questions
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 does dual-export tracing create access-control risk for AI teams?
A: Because the same trace may serve engineers, analysts, and ML practitioners, each with different needs and privileges.
Q: What breaks when production traces are not reused in testing?
A: When production traces are not reused, the team keeps seeing the same failures without improving the test suite.
Practitioner guidance
- Define trace classification before dual export Label AI traces by sensitivity and permitted reuse before they are sent to observability and lakehouse destinations.
- Separate engineer and analyst entitlements Use destination-specific access controls so debugging teams can inspect live traces without automatically granting broad query access to governed storage.
- Review retention and residency per destination Set different retention periods, residency expectations, and deletion rules for observability copies and governed lakehouse copies.
Bottom line: Dual export makes AI traces simultaneously useful for engineering investigation and governed analytics, so the same telemetry now needs both observability and data-governance controls.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Dual export turns AI traces into governed enterprise records, not disposable debug artefacts. Once the same span can be queried in a lakehouse and inspected in an observability tool, trace handling becomes a data governance problem as much as an engineering one. The control question shifts from capture to authorised reuse, retention, and downstream access. For practitioners, the trace lifecycle must be governed with the same discipline applied to other sensitive operational datasets.
A question worth separating out:
Q: What is the difference between observability storage and governed lakehouse storage for AI traces?
A: Observability storage is optimised for inspection and troubleshooting, while governed lakehouse storage is optimised for SQL analysis, long-term retention, and enterprise controls. The same trace can belong in both, but the access model and lifecycle rules should differ by destination.
👉 Read our full editorial: OpenTelemetry dual export gives AI traces both observability and governance