The AI Governance Gap Between Platforms

Most enterprises I speak to can answer detailed questions about their AI systems. What they cannot answer is a question that crosses from one platform to another. Inside Microsoft, the picture is good. Inside Databricks, the picture is good. Both platforms record their own activity thoroughly. The teams running them can normally produce cost, usage, policy events and failure data on request. Then comes a request that starts in one environment and ends in the other. It retrieves data governed by the other platform. A model is called. An action is taken. Somewhere in that chain, something behaves unexpectedly. Reconstructing what happened means joining two sets of records that were never designed to be joined.  That gap is the seam. It sits between two products that each govern their own environment well and belong to neither of them. It belongs to the organisation that chose both. 

Why the Seam is Structural 

It is tempting to treat this as a backlog item: two telemetry stores and eventually someone writes the integration. I think that underestimates it. Each platform is built to be observable within its own boundary and both do that job properly. A vendor can only instrument what it runs. The boundary is where the product ends, not where the product is weak. So the join is not a missing feature. It is a consequence of running a multi-vendor environment, which most large organisations do deliberately, for good reasons and are unlikely to stop doing. The seam does not close on its own. 

A Practical Example

Imagine this scenario, where an AI agent processes supplier invoices. The agent:

• Runs in Microsoft

• Retrieves supplier and invoice data from Databricks

• Invokes a model to classify the invoice and identify anomalies

• Routes the invoice into an approval workflow.

Microsoft can show the workflow activity. Databricks can show the data access and model interactions. Both platforms produce strong records of what happens inside their own boundaries. But when finance asks why an invoice was flagged, what data the agent used, which model call produced the result, what the end-to-end request cost was and which business use case was responsible, the answer has to be reconstructed across both. That is what the seam looks like in practice.

What Breaks There 

Four things stop working at the seam: 

• Cost attribution. Spend is visible per platform but not per use case, so nobody can say what an individual AI application costs end to end. 

• Incident reconstruction. The sequence of events has to be rebuilt manually from two sources, usually after the fact. 

• Evaluation. Quality signals sit on one side of the seam while the behaviour that produced them sits on the other, so drift is noticed late. 

• Audit evidence. Record-keeping that stops at a platform boundary is not a record of what the system did. 

Each is survivable at small scale. At ten or twenty production use cases across two platforms, they compound. 

The Fix Most Teams Reach for First 

The instinct is to standardise the telemetry: re-instrument everything against a single schema, route it into one observability platform and treat the native tooling as raw input. That can work. It is also slow and it asks engineering teams to change how they build in order to solve a governance problem they did not create. The less invasive route is to leave native telemetry alone. Both platforms already produce the best available record of their own activity.

Record natively. Ingest as it is. Unify above it. That is the thinking behind the unified trace in Cloudaeon AI Hub: native telemetry on both sides is treated as the source and correlation happens in a layer above rather than inside either platform. 

Two Identifiers, Not One 

The mechanism is a correlation key carried through every hop. Most teams that attempt this implement one identifier: a technical key tying the spans of a single request together. Necessary, but not sufficient. A second matters as much: the use case the request belongs to. The technical key answers what happened in this request. The business key answers which registered the use case, with which owner and which risk classification, produced it. Without the second, you can debug an incident, but you cannot attribute cost to an application, report on a portfolio, or hand an auditor evidence organised the way they will ask for it. 

Decide What You Capture Before You Capture It 

One question tends to arrive late that should arrive early: how much of the content is recorded?Traces of AI systems can contain prompts, retrieved passages and generated output. That is business data, sometimes personal data, sitting in a store scoped for operational logs.

A workable position: 

• Metadata for every governable call, always: what was called, by whom, under which policy, at what cost. 

• Payload depth by policy and redactable, captured where you have decided it should be, not by default. 

What should not happen is conditional logging of governable calls. If a call can be governed, its metadata is recorded; otherwise, the record has gaps precisely where it matters. This distinction matters for regulation too. Where record-keeping and monitoring obligations apply, a unified trace can provide supporting evidence across the system boundary, but it does not make a system compliant. EU AI Act obligations for stand-alone high-risk systems were deferred to December 2027, though transparency duties applied from August 2026. A unified trace supports logging, record-keeping and post-market monitoring, but this is evidence support, not a compliance guarantee.

An Ownership Question Before a Tooling One 

The organisations handling this well are not running more observability. They are running the same observability joined. The seam does not appear on either vendor roadmap because it is not inside either product. It appears in the architecture of the organisation running both and it stays open until someone is made accountable for it. The useful internal question is a narrow one. It is not whether AI activity is monitored, it almost certainly is, on both sides. It is who owns the join and what happens when someone asks a question that crosses it.

Conclusion

Cloudaeon AI Hub is built to close that seam. It connects native telemetry across Microsoft and Databricks into a unified trace. It gives a single view of what happened across the AI environment. If your AI projects span multiple platforms, can you answer what happened across the seam and who owns the join? Learn how Cloudaeon AI Hub can bring that visibility together across your AI environment.