Snowflake Cortex and Databricks AI on regulated data: where does governance end and sovereignty begin?

Governance ends where the operator's control of the compute ends. Snowflake Cortex and Databricks AI both deliver strong governance: fine grained access control, column and row lineage, and detailed audit of who queried regulated data inside the platform. What neither delivers is sovereignty, because the models run in the vendor's cloud under the vendor's keys, so the data leaves the operator's boundary to be processed. Governance proves who touched the data inside the platform. Sovereignty proves the data never left a boundary the operator controls.

In 2026 the buyer question has moved from can you govern our data to can you prove where it was processed. Regulated buyers in banking, health, defence and critical infrastructure now face overlapping rules that ask not only who read a record but on whose hardware and under whose jurisdiction the inference ran. Public answer engines like ChatGPT, Claude and Gemini are off the table for the sensitive workload for exactly this reason. The real choice is between a governed cloud service and a sovereign design, and the two answer different questions.

What is the difference between governance and sovereignty?

Governance is control and evidence inside a system. Sovereignty is control of the boundary of that system. A governed platform can show a complete access log, enforce least privilege, and mask columns by policy. A sovereign system can additionally prove that the regulated data was never transmitted beyond hardware the operator owns and controls. Governance answers who and what. Sovereignty answers where and under whose authority. A service can be perfectly governed and still not sovereign, if the compute sits in a third party cloud.

How do Snowflake Cortex and Databricks AI govern regulated data?

Both are mature at governance, and we would not argue otherwise. Snowflake Cortex runs models close to data already inside Snowflake, with role based access control, object tagging, masking policies and query history. Databricks AI applies Unity Catalog for lineage, permissions and audit across tables, models and features. Both give an auditor a strong internal record: which principal ran which query against which object, and when. For a large class of enterprise workloads that is exactly the right control surface.

Why does running in the vendor cloud cap the claim at governance?

The models execute on infrastructure the vendor operates. Data in use is decrypted in the vendor's memory to be processed, and keys, even customer managed, are exercised within the vendor's environment. Under the US CLOUD Act, a US headquartered provider can be compelled to produce data it controls, regardless of where the servers physically sit. That is a jurisdiction fact, not an accusation. It means the honest ceiling of a vendor cloud service is a strong governance claim, not a sovereignty claim, because the operator cannot prove the data stayed inside a boundary it alone commands.

“Governance tells you who touched the data; sovereignty tells you the data never left.”

What can an auditor actually check for sovereignty?

Sovereignty should reduce to tests an auditor can run without trusting a vendor dashboard.

• Zero egress: a deny by default outbound perimeter, so the system can receive a prompt but has no route to send regulated data out. Inbound only.
• Offline verifiability: the audit record can be verified with the network cable pulled, using only local keys.
• Hardware attested identity: every actor and node presents an attested identity bound to the audit chain, so a log entry maps to a specific machine.
• Sealed ledger: each entry is cryptographically signed, so tampering or deletion is detectable after the fact.

A governed cloud service can satisfy the first parts of the access record. Only a system that owns its own boundary can pass the egress and offline tests.

Which rules make this distinction necessary?

Several regimes now separate governance from sovereignty in practice.

• DORA, in force since January 2025, holds financial entities accountable for third party and concentration risk in their supply chain.
• NIS2 extends security and incident reporting duties to essential and important entities.
• GDPR constrains where and how personal data may be processed and transferred.
• The US CLOUD Act creates the cross border reach described above.
• ISO/IEC 42001 sets expectations for an AI management system.
• EU AI Act: the high risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high risk moved to 2 August 2028 and Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve.

How does a sovereign design prove the data never left?

This is where Mickai fits, alongside a governed data platform rather than against it. Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator owned hardware behind a zero egress inbound perimeter, so regulated data has no outbound route by design. Every actor holds a hardware attested identity bound to the audit chain, so each action maps to a known machine and principal. Every action is written to an audit ledger sealed with post-quantum digital signatures: FIPS 204 (ML-DSA) is the primary signature, with FIPS 205 (SLH-DSA) available as a stateless hash based alternative, and that ledger can be verified offline. Sensitive answers can be checked by cross-model consensus, where several sovereign models must agree before an output is trusted. This architecture is described across 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all pending and none granted. The point is not that governance is weak. The point is that governance and sovereignty are two different proofs, and a regulated operator increasingly needs both.

Frequently asked questions

Is Snowflake Cortex or Databricks AI enough for regulated data?

For governance, often yes. Both provide access control, lineage and audit that satisfy a large share of enterprise and regulatory needs. They fall short only on sovereignty, meaning proof that regulated data never left an operator controlled boundary, because inference runs in the vendor's cloud. Where a rule or a customer demands that proof, a governed platform needs a sovereign layer alongside it.

Can customer managed keys make a cloud AI service sovereign?

No. Customer managed keys improve governance and reduce vendor access, but the keys are still exercised inside the vendor's environment to decrypt data in use. Sovereignty requires that the data and the compute never leave hardware the operator controls. Key ownership is necessary but not sufficient for that claim.

Does the US CLOUD Act apply if our data is stored in the EU?

Storage location is not the deciding factor. The US CLOUD Act can reach data a US headquartered provider controls, even when the servers sit in the EU. This is why regulated buyers now ask on whose hardware and under whose jurisdiction processing occurs, not only in which region the bytes rest.

What single test separates governance from sovereignty?

The egress test. Pull the network cable and ask whether the system can still be verified and whether regulated data ever had a route out. A governed cloud service depends on that connection to the vendor. A sovereign system passes with the cable pulled, because its perimeter is inbound only and its audit ledger verifies against local keys.

Did the EU AI Act deadline for high-risk systems pass in August 2026?

No. The high risk Annex III obligations once expected on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high risk moved to 2 August 2028 and Article 50 transparency duties largely unchanged. We treat the extra time as a window to build verifiable sovereignty, not a reason to delay.