Data sovereignty
Data Sovereignty: From the Location of Data to End-to-End Control
One question has sat at the centre of enterprise data strategy for a long time: where is our data held? It has lost none of its importance. In finance, the public sector, healthcare and energy in particular — wherever regulation, security or sensitive data set the terms — which country or region the data sits in is a serious architectural criterion.
Last updated: September 2026
In modern Data & AI architectures, though, data is no longer merely stored. It is queried, processed, transformed, moved between systems, consumed by analytics applications and drawn into AI workloads. Asking only “where is the data?” is therefore no longer enough. Other questions join it: where is the data processed, which services does it pass through, who can reach it, who governs the access policies, can operations be audited, and which external systems does the platform depend on?
This is also where the difference between data residency and data sovereignty starts to matter. Data residency concerns where data physically or geographically sits. Data sovereignty concerns which legal and regulatory framework the data is subject to. The job of a modern Data & AI platform is to let an organization apply the requirements it has set in both areas across the entire data lifecycle, not only at the storage layer.
The architectural approach of the Kauzas Data & AI Platform begins exactly here: running modern Data & AI capabilities on the infrastructure the organization needs, inside the control model the organization defines.
What is data sovereignty?
At its most basic, data sovereignty describes which legal and regulatory framework data is subject to. For an organization, however, defining the legal framework is not enough on its own — the requirement also has to hold up in the technology architecture. That is why these questions matter in modern Data & AI systems:
- Where is the data stored?
- Where is it processed?
- Which infrastructure does compute run on?
- Who can reach the data?
- Who governs authorization?
- Which services does data move between?
- Where does the control plane run?
- Where are logs and system activity held?
- Which external services does the platform depend on?
- Can data movement and access be audited?
There is an important distinction here: identity management, authorization, audit, lineage and monitoring are not the definition of data sovereignty. They are the mechanisms through which the sovereignty and control requirements an organization has set are applied and verified inside the technical architecture.
Kauzas therefore does not treat data sovereignty as a single feature or a checkbox. The platform brings storage, compute, catalogue, SQL, Spark, notebooks, orchestration, governance, identity, monitoring and AI workloads together in one Kubernetes-based architecture, so the organization can decide which environment each of those layers runs in and under which control model.
Location alone does not give control
For many organizations, keeping data inside the country is a significant requirement. The reason may be the legislation they are subject to, the kinds of data they process, contractual obligations, information security policy, or simply their own view of risk.
Running Kauzas on the AWS Local Zone in Istanbul offers a real alternative here. The Kauzas Data & AI platform layer can be placed on top of the local compute and storage infrastructure of that Local Zone. The same platform architecture also runs in the organization's own data centre or in a private cloud of its choosing. Organizations can therefore use modern lakehouse and AI capabilities while handling their data residency requirements in line with their own infrastructure preferences.
The important point, though, is this: data being stored in a particular country does not by itself answer every data sovereignty question. Even with storage in Türkiye, these questions remain open — where does compute run, where are queries executed, where is the control plane, where is authentication applied, which systems do logs and metadata go to, and where does AI inference happen?
In the Kauzas approach, the location of data is a starting point; the assessment carries on through the rest of the platform.
Storage in one place, compute in another
This is one of the most frequently overlooked subjects in data platforms. An organization can hold its data wherever it wants, while the compute used to query or process that data sits somewhere else entirely.
The distinction matters more in modern Data & AI architectures, because the same data can be used by many different compute layers: SQL queries, Spark jobs, notebook environments, machine learning and inference workloads.
Kauzas treats those layers inside one platform architecture. Kauzas SQL carries distributed query workloads, Spark carries data processing, notebook environments carry analytics and data science work, and the AI/ML layer carries artificial intelligence workloads — all positioned within the platform.
The organization can therefore make not only “where is my data?” but also “where is the compute that touches my data?” part of the architectural decision. This is one of the most important differences in the Kauzas approach to data sovereignty.
The data plane and the control plane
Knowing where data and workloads run matters. But there is another critical question: where does the layer that governs the platform run?
In modern platform architectures the data plane and the control plane can be separated. The data plane is where the organization's data and workloads run; the control plane is the layer used to manage and operate the platform.
No two organizations should be expected to have the same requirement for those two layers. An organization operating in a critical or disconnected environment may want both the data plane and the control plane entirely on its own infrastructure. Another may want to keep data and workloads in-house while taking platform management as a service. An organization with several facilities or sites may prefer central management alongside distributed data and compute layers.
Kauzas therefore supports several management models. The platform can be positioned as a fully in-house deployment, with a managed control plane, or as central management across distributed sites. Rather than equating data sovereignty with one fixed deployment model, this lets the organization make the architectural decision against its own requirements.
Control over data requires control over access
Data sitting in the location an organization prefers is not enough on its own. Who can reach which data is a fundamental part of the control model too.
Kauzas integrates with the organization's existing identity infrastructure over OIDC, so users and groups can be mapped onto platform permissions. Authorization is not handled only at the user interface level: a policy-based access model defines centrally who may reach which resource and under what conditions. Cedar-based policy mechanisms are used for this in the Kauzas governance layer.
The significance is this: the decisions an organization makes about where data sits can be carried through into the access layer. Alongside “where is the data?” come “who can reach it, under what conditions, with what permission?”
Control begins with being able to see
Control does not only mean being able to prevent an operation. It also means being able to see what is happening inside the system and to examine it after the fact when necessary. Auditability is therefore an important component of a modern data platform.
Alongside access policies, the Kauzas governance approach includes data lineage, audit records and monitoring. Tracking data movement and workflows through OpenLineage helps organizations understand where a piece of data came from and which processes it passed through. The monitoring layer makes the operational state of the platform and its workloads visible.
Control over data therefore becomes three separate questions: who can reach it, where did it move from and to, and what happened on the platform?
Disconnected networks and operational autonomy
For some organizations, an external internet connection or a dependency on an external service is simply not acceptable. In the public sector, in critical infrastructure and in high-security environments, a platform's ability to run independently of the outside world can become an important part of the architecture.
Kauzas supports models that can be installed and operated on disconnected networks with no external internet access. This is not itself the definition of data sovereignty. It is, however, an important capability for applying the sovereignty, security and operational control requirements an organization has set.
Because the question is no longer only whether data leaves. It is also whether the platform needs the outside world in order to work at all.
Tying yourself to one provider is a choice, not a requirement
Data sovereignty and technology independence are not the same concept, but they are closely related when it comes to long-term control. The more completely a data and AI platform depends on the proprietary services of one infrastructure, the more the cost and complexity of moving it to a different environment grows.
Kauzas therefore uses a Kubernetes-based platform architecture. The same Data & AI platform can be positioned on the AWS Local Zone in Istanbul, in the organization's data centre, or in a private cloud. The aim is to reduce the risk of having to redesign the entire data platform whenever the organization changes its infrastructure decision.
The same principle shows up in the platform's components. Lakehouse, catalogue, distributed SQL, Spark, notebooks, orchestration, governance, monitoring and AI layers are handled inside one architecture but kept separable from one another. This is not data sovereignty in itself; it does give the organization more architectural choice over the future of its data and AI infrastructure.
A modern Data & AI architecture makes sovereignty harder
In a traditional data system, working out where data sits can be relatively straightforward. In a modern Data & AI platform the same data interacts with many components at once: object storage, catalogue, SQL engines, Spark, notebooks, pipelines, event infrastructure, BI, AI/ML, identity, governance and monitoring.
A modern sovereignty assessment therefore cannot be made by looking at the database or storage layer alone; the end-to-end path of the data has to be understood.
This is one of the core advantages of Kauzas bringing all of those components together in a single platform architecture. Different data and AI workloads can be managed within the same platform while the organization decides which infrastructure they run on and which control mechanisms they are subject to.
From data sovereignty to AI sovereignty
The same subject now arrives on the artificial intelligence side. Data is not the only thing that needs controlling in AI applications: prompts, embeddings, organizational context, models, inference infrastructure and GPU resources all become part of the data flow.
- Where is organizational data sent to the model?
- Where does inference take place?
- Do prompts or embeddings leave the organization's control?
- Which compute infrastructure does the model use?
- Are organizational access policies applied at the AI layer too?
- Can AI operations be audited?
This is where it matters that Kauzas positions AI workloads as part of the same Data & AI architecture rather than a separate world beside the rest of the platform. The organization can position data, compute and AI workloads together, according to its own infrastructure model. That also lays important groundwork for the sovereign AI discussions that will be heard more in the period ahead.
What Kauzas provides, and what it does not
An important distinction is needed here. No technology platform can, on its own, guarantee data sovereignty or regulatory compliance for an organization. Those are determined by assessing the law the organization is subject to, the data it processes, the infrastructure it uses, its operating model and its technical arrangement together.
The role of Kauzas is different. Kauzas provides the technical platform layer through which organizations can apply their own data residency, sovereignty, security and operational control requirements to a modern Data & AI architecture.
- Where data will be held
- Where compute will run
- Which infrastructure will be used
- How the control plane will be positioned
- Who will be able to reach what
- Which operations will be audited
- How the platform will relate to external systems
The organization can design all of those decisions against its own requirements. It is therefore more accurate to read the Kauzas approach to data sovereignty as architectural freedom of choice rather than as a single feature.
Where your data is, and who holds control
The data residency discussion opens with an important question: where is the data? Data sovereignty adds another: which legal framework is the data subject to? A modern Data & AI architecture takes it one step further: are those requirements still upheld when the data is processed, queried, moved and used by AI?
The Kauzas Data & AI Platform is aimed precisely at that third question. One Kubernetes-based platform architecture brings lakehouse, catalogue, SQL, Spark, notebooks, orchestration, governance, SSO, monitoring and AI workloads together across environments as different as the AWS Local Zone in Istanbul, an organization's data centre and a private cloud.
But the real value is not simply gathering those technologies in one place. It is the organization being able to hold control over where and how its data and AI infrastructure runs.
A modern Data & AI infrastructure. Wherever you need it. Control stays with you.
Frequently asked questions
- What is data sovereignty?
- Data sovereignty describes which legal and regulatory framework data is subject to. Upholding that requirement in a modern Data & AI architecture means assessing data location, processing, access, governance and data movement together.
- What is the difference between data residency and data sovereignty?
- Data residency concerns where data physically or geographically sits. Data sovereignty concerns which legal and regulatory framework the data is subject to.
- How does Kauzas support data sovereignty?
- Kauzas lets organizations position their data and AI workloads on the infrastructure they need, and manage the storage, compute, identity, governance and operations layers within one Data & AI platform architecture.
- Does Kauzas support keeping data in Türkiye?
- Kauzas can run on the AWS Local Zone in Istanbul. It can also be positioned in the organization's own data centre or in a private cloud of its choosing, so the organization can pick the environment that suits its data residency requirement.
- Does Kauzas only run on AWS?
- No. With its Kubernetes-based architecture, Kauzas can be positioned on the AWS Local Zone in Istanbul, in an organization's data centre, or in a private cloud.
- Is keeping data in Türkiye enough for data sovereignty?
- Not on its own. The location of data matters, but compute, access, the control plane, data movement and other operational components have to be assessed as well.
- Can Kauzas run on a disconnected network?
- Kauzas supports deployment models that run on disconnected networks with no external internet access. That provides important operational control in environments where dependency on external services has to be limited.
- How are access and governance handled in Kauzas?
- Kauzas treats enterprise identity integration, policy-based authorization, data lineage, audit and monitoring as parts of platform governance.
- What is sovereign AI?
- Sovereign AI describes approaches in which the model, inference, prompts, embeddings, compute infrastructure and AI governance — not only the data — can be controlled in line with an organization's legal and operational requirements.
Let's answer these questions for your own organization.
We can map where data, compute and the control plane sit in your current architecture, and show how Kauzas would be positioned in your environment.