Author: Thomas Conrad, CEO, beON consult GmbH
Why the Location of Your AI Model Is Only the Beginning
Knowing where an AI model is hosted is a good start: on your own infrastructure, in a sovereign cloud, or in a regional data center. However, this alone does not create true AI sovereignty.
The crucial question is:
Can you consistently control the data your AI relies on—and migrate it if necessary without time-consuming and costly re-engineering?
For many companies today, the answer is still no.
A sovereign AI architecture must do more than just keep data within a specific region. It must empower organizations to control the entire chain behind an AI outcome: data sources, copies, access, models, workloads, providers, and the ability to exit a platform when needed.
Model Location Does Not Equal Sovereignty
In many discussions around sovereign AI, the initial focus centers on questions such as:
-
- Is the model running in Europe?
- Is it hosted in a sovereign cloud?
- Does the data remain in a regional data center?
- Is a private or self-hosted LLM being used?
These questions are relevant, but they address only part of the problem. Even a model running on your own infrastructure or in a sovereign cloud can depend on data that:
-
- originates from uncontrolled sources,
- is fragmented across multiple copies,
- is processed outside the designated region,
- is locked into a specific platform provider,
- can only be consumed via proprietary formats or interfaces,
- would require extensive re-integration in the event of a platform migration.
Sovereignty is therefore not merely a question of location. It is a question of control over the entire system behind an AI outcome.
When Centralization Weakens Sovereignty
A centralized lakehouse or data lake approach offers many advantages: unified data access, centralized governance, improved analytics capabilities, and a shared foundation for AI applications.
Yet centralizing all data does not automatically equate to greater control.
With every additional data copy, new questions arise:
-
- Does the copy leave an approved region?
- Who is accountable for this copy?
- What access permissions apply there?
- How up-to-date and complete is the dataset?
- How can the copy be deleted or repatriated?
- How complex and costly would it be to switch the underlying platform?
- What happens to the agents, APIs, and dashboards built on top of it?
A single central repository can actually increase technical dependency. When data, semantics, vector storage, orchestration, and applications are tightly coupled to a single platform, switching later becomes expensive and risky.
Centralization can enhance control—but it can also create new dependencies. The architecture is what makes the difference.
Another Approach: The Governed AI Data Layer
An AI Data Layer takes a different path. Rather than forcing all data to reside physically in a single location, it establishes a managed, logical layer across distributed data sources.
As a result, AI applications do not directly access the physical infrastructure of individual systems. Instead, they utilize:
-
- logical data products,
- unified semantics,
- defined data access policies,
- governance and compliance metadata,
- traceable data flows,
- controlled interfaces to SAP and non-SAP sources.
The underlying data can evolve, be moved, or be repatriated to an on-premises environment without requiring the overlying applications to be completely redeveloped. This applies to:
-
- AI agents,
- APIs,
- RAG applications,
- Dashboards,
- Automation and workflow solutions.
The critical advantage is decoupling: AI applications are decoupled from the physical infrastructure while data control, semantics, and governance remain intact.
This does not mean that data may never be moved. On the contrary: data can move whenever it makes functional, regulatory, or economic sense.
The real question is: Who decides when, why, and under what conditions the data is moved?
That is the true test of AI sovereignty.
The Seven Dimensions of Sovereign AI Architectures
A reliable assessment should look beyond model hosting location and cover at least the following dimensions:
- Control over the Source
Do you know which systems and data sources feed your AI? Are data owners, responsibilities, and quality requirements clearly defined? - Data Residency
Can you track where original data, copies, backups, and derived data products are located? - Access and Usage
Are roles, permissions, and access contexts consistently enforced across SAP, non-SAP, and AI systems? - Copies and Data Products
Do you know which copies, embeddings, vectors, and derived data products exist—and can you govern their usage? - Reusability
Can data be securely leveraged across different AI applications without building new, proprietary copies and integrations each time? - Workload Placement
Can you decide where data processing and AI workloads run based on sensitivity, latency, cost, and regulation? - Portability and Exit Strategy
Can you move data, models, and workloads between platforms or repatriate them to your own environment without rebuilding the applications on top?
These dimensions make it clear whether an architecture is genuinely sovereign—or merely appears sovereign because the model is hosted in a specific location.
The EU Data Act Turns Portability into an Architectural Requirement
Regulatory requirements for data control and portability are rising. The EU Data Act strengthens, among other things, the ability to switch data and cloud services between providers. As of January 12, 2027, switching charges for cloud and comparable data processing services are set to be eliminated.
This elevates portability beyond a commercial consideration. Enterprises must evaluate:
-
- Are data formats and interfaces portable?
- Can workloads run in an alternative environment?
- Are semantics and policies documented and transferable?
- Which proprietary services are currently in use?
- What happens to RAG pipelines, vector stores, and AI agents during a platform switch?
- How much re-engineering would be required for a migration?
Eliminating switching fees removes a financial barrier, but it does not automatically resolve technical lock-in. A cost-free platform switch offers little value if the migration takes years or requires core applications to be rebuilt from scratch.
Portability must therefore be treated as an architectural principle from day one—not addressed only when a vendor switch is imminent.
What Does This Mean for SAP-Centric Companies?
In many enterprises, SAP forms the backbone of critical business processes. At the same time, critical business data often resides in:
- Non-SAP applications,
- Documents and knowledge bases,
- CRM and service solutions,
- MES and LIMS systems,
- IoT and machine data,
- Data lake and analytics platforms,
- ITSM and operational systems.
A sovereign AI architecture must connect these sources without uncontrolled replication or locking applications into a single platform.
For SAP-centric companies, this means:
-
- Enforcing SAP authorizations for AI access
- Integrating SAP and non-SAP data via controlled interfaces
- Running RAG on enterprise data with source attribution and access controls
- Decoupling AI agents from physical data platforms
- Leveraging SAP Business AI where it delivers functional and economic value
- Utilizing open or sovereign technologies when data ownership, flexibility, maturity, or costs demand it
- Factoring exit and migration options into PoCs from the start
This approach avoids isolated AI silos, creating instead an integrated and highly portable intelligence layer across and between existing SAP and non-SAP systems.
Six Questions to Assess Your AI Sovereignty
Enterprises can gauge their current readiness using six straightforward questions:
-
- Do we control the data sources, copies, and derived data products on which our AI relies?
- Can we trace the complete data flow—including embeddings, vector stores, and backups?
- Are existing roles, permissions, and governance policies enforced within AI applications?
- Can we securely leverage data and live context from distributed SAP and non-SAP sources?
- Can we flexibly switch models, providers, platforms, and workloads based on changing requirements?
- Can we migrate or repatriate data and workloads without redeveloping agents, APIs, and dashboards?
If several of these questions cannot be answered clearly, a gap likely exists between technical control and actual sovereignty.
The beON Perspective
beON supports SAP-centric enterprise clients in operating AI architectures that are not only secure, but controllable and scalable over the long term.
Our approach combines:
-
- AI and architectural strategy,
- SAP and non-SAP integration,
- Governed AI Data Layer,
- Sovereign and self-hosted AI,
- Portable model and provider layers,
- Security, governance, and auditability,
- Production-ready PoCs using real-world data,
- Defined migration and exit strategies.
Our guiding principle:
SAP when SAP delivers functional and economic value.
Open or sovereign technologies when data sovereignty, flexibility, maturity, or costs require them.
We do not just look at where a model runs. We analyze the entire system behind the AI outcome: data, access, copies, workloads, models, platforms, and operational processes.
Conclusion: Sovereignty Is an Architectural Decision
AI sovereignty does not start with choosing a private LLM, nor does it end with hosting in a sovereign cloud.
It is defined by the ability to:
-
- govern data and its usage,
- maintain full transparency over data flows and copies,
- decouple AI applications from physical infrastructure,
- switch models and providers on a sound technical basis,
- place workloads flexibly,
- move or repatriate data as needed,
- and accomplish this without completely re-engineering the applications built on top.
What matters is not that data never moves.
What matters is that you decide when, why, and how it moves.