Continuing the data portability theme leads us into the next level of detail, into forces that constrain what the architecture alone cannot resolve. The first is financial: the egress costs cloud providers charge to move data out are real, and they compound at scale. The second is legal: data sovereignty legislation can mandate that certain data never leaves a specific geography or jurisdiction, regardless of how elegant the architecture is. This article examines both and then presents the combination that handles the first, illuminates where the second begins, and introduces a layer of enterprise IP that organisations may not yet have recognised as their most strategic asset.
Every major architectural shift in data has moved the border between who needs to understand the business and who needs to understand the technology. In the mainframe era, developers had to understand business domain and technical system simultaneously to extract data that is required. Data warehouses moved the border slightly. BI tools moved it further. Advanced analytics moved it so far toward the business that departments broke away into siloed data marts creating the chaos that data lakes were built to resolve. But the data lake era started with a new problem. The technical connective tissue, lineage, governance, business rules, data dictionaries and business glossaries were left behind by the engineers who could build the lake but could not describe what lived in it in business terms.
Now AI moves the border again, and in an unexpected direction. An AI agent does not need a human to translate between the business and the data. But it does need that translation to already exist, somewhere, in a form it can read. Descriptive metadata is no longer a governance nicety. It is the prerequisite for AI to work at all. Organisations that invested in it have a competitive advantage. Organisations that skipped it are not just ungoverned, they are AI-unready.
And here is where portability enters the picture. The business understanding encoded in metadata, glossaries, semantic definitions, lineage, data contracts, is as much a part of organisational IP as any pipeline or model. If it lives in an open format, it travels with the organisation.
Modern architectures that solve this metadata portability problem share two characteristics. The first is an open data layer that describes and connects data regardless of where it physically lives, standardising the format rather than the location. The second is an open intelligence layer that governs how AI systems consume, reason over, and act on that data, independently of the infrastructure underneath. When both layers use open formats, the result is a stack whose IP belongs to the organisation rather than the vendor.
To see how these two layers manifest in practice, we examined one of the most mature executions of this approach currently available: Google Cloud and Databricks. Other configurations are valid, and the previous article mapped several in detail. This specific pairing illustrates how the open format layer operates end to end for AI engineering workloads.
Google Cloud brings the open data layer. At Cloud Next in April 2026, Google introduced the Cross-Cloud Lakehouse, allowing any data platform on Google Cloud to query data in AWS or Azure without moving it and without egress costs for the query. For federated analytics and ad hoc reporting, this largely resolves the egress problem; for GPU-intensive model training, compute and storage still need to be co-located. Beyond the lakehouse, Google adds Knowledge Catalog as a continuously enriching semantic context engine, Gemini Enterprise Agent Platform for building and governing agents, and the Open Knowledge Format, a vendor-neutral standard that keeps enterprise knowledge in plain markdown files rather than a proprietary system.
Databricks brings the open intelligence layer: Unity Catalog governing data and AI assets across any cloud, Unity AI Gateway managing agent interactions with guardrails, audit, and cost controls, Delta Lake as the open lakehouse format, and Mosaic AI for model training and agent orchestration. Open standards connect the two platforms without creating dependency between them: Apache Iceberg for the lakehouse, MCP (the Model Context Protocol, which keeps AI agent capabilities portable across platforms without vendor lock-in) for agent tooling, and OKF for enterprise knowledge context.
Technology has largely solved data portability. Legislation is now the last remaining constraint, and it is not a technology problem.
The most important distinction is between three concepts that most organisations conflate. Data residency is where data is physically stored. Data sovereignty is whose laws govern it. Technical sovereignty is who controls the stack. These three are not the same thing, and conflating them is where most cloud strategies go wrong. A US company running servers in Germany satisfies German data residency requirements as the data is physically on German soil. But the CLOUD Act means US authorities can compel that same US company to hand over the data regardless of where the servers are. German residency is satisfied. German sovereignty is not. The location of the server and the jurisdiction of the law are two entirely different questions.
Understanding this distinction reveals why different regulatory environments create five fundamentally different architectural constraints:
The rights-based model, the EU, sets the gold standard through GDPR and now the AI Act, fully applicable August 2026, which mandates documented data governance, bias detection, and human oversight for high-risk AI systems. Penalties reach 7% of global annual turnover.
The modernising model, Australia, is mid-reform. Automated decision-making disclosure is required by December 2026, essentially mandating explainability for AI systems. The shift is from declarative compliance to evidentiary compliance: organisations must demonstrate how data flows in live systems, not just in documentation.
The national interest model, China, is a completely different universe. Transfers involving one million individuals require a mandatory government security assessment, and transfers must stop until it is complete. No Western architecture assumption holds here without significant localisation.
The fragmented model, the United States, has no federal data sovereignty law but creates a sovereignty gap everywhere else through the CLOUD Act, which allows US authorities to compel American companies to provide access to data stored abroad. If your provider is headquartered in the US, your data is legally accessible to US authorities even if the servers are in Frankfurt.
The fast-following wave, India, Vietnam, Indonesia, ASEAN, is moving rapidly, with India potentially mandating that AI processing of Indian citizens data must happen on locally hosted infrastructure.
This is the honest limit of the Google plus Databricks story. Both are US-headquartered companies. Their Australian and European data centres satisfy residency. For the most sensitive regulated data, full sovereignty requires a combination of architectural decisions, contractual protections, and in some cases genuinely local providers. The architecture gives you the option. The contract and the jurisdiction determine whether you can exercise it.
For the most sensitive tier of regulated data, open formats offer something more concrete than a contract clause. Because Apache Iceberg separates metadata from physical storage, those metadata pointers can reference object storage on any S3-compatible provider, including genuinely local sovereign clouds with zero US jurisdictional ties. Providers such as OVHcloud in Europe and Vault Systems in Australia operate entirely outside US CLOUD Act reach. Storage alone is not enough, however. If a US-headquartered compute engine processes that data, that processing may still fall under US jurisdiction. For the most regulated data, the compute must also run on a locally incorporated provider with no US parent company. A US hyperscaler local data centre, such as AWS Sydney or Azure Melbourne, does not qualify: it remains subject to US jurisdiction regardless of its physical location. Architects should also recognise that descriptive metadata, column definitions, lineage graphs, data contracts, and AI guardrail configurations, sits in the governance catalogue and remains subject to that catalogue provider’s jurisdiction. For the highest sensitivity tier, where even the schema and business definitions constitute sensitive IP, the governance catalogue itself may need to be self-hosted locally rather than relying on a globally unified SaaS product. This is not a workaround. It is the architecture doing exactly what it was designed to do.
For the majority of workloads that do not require full sovereignty, the architecture still gives you commercial leverage. Because your metadata is in an open format, any compute engine can read the data wherever it lives. If a cloud provider charges egress fees to query your data, you can simply run that query from a different environment instead. That is a credible threat, and vendors know it.
Identify which data in your estate is subject to residency or sovereignty requirements before designing the compute layer, not after. For regulated exceptions, the hybrid sovereign pattern routes storage and compute to a local provider while keeping governance unified, with the caveat on the governance catalogue noted above.
The previous article showed that organisational data IP can be architecturally separated from the cloud infrastructure. This combination of Google Cloud and Databricks takes that separation further than any single platform can, covering the EDRA with near-completeness for AI engineering workloads, on open standards, without creating dependencies between the two platforms.
The remaining constraints are not architectural. They are financial, negotiable through contract. And they are legislative, not negotiable, but designable around. The architecture is the constant. The technology is a variable. The law is a constraint. Building for all three, simultaneously, is what enterprise data architecture looks like in 2026. By following this sequence, an organisation does not just build a legally compliant technology stack. They transform their descriptive metadata, their glossaries, lineage graphs, and business rules into a fully sovereign, portable layer of Enterprise IP that outlive any single vendor, any cloud contract, and any infrastructure decision.
Copyright © NeatenMyData
Neaten My Data 