Straight answers for the people who have to decide.

Most public bodies and large firms run on a handful of non-European platforms, which means your data, your costs and your continuity depend on decisions and laws made outside the EU. Sovereignty is about keeping control, over where data lives, who can access it, and your ability to change supplier without operations collapsing. SovereignOS is designed so your organisation can define the data boundary, applicable jurisdictions and review evidence for each deployment.

The lock-in behind most sovereignty problems sits beneath the applications, in the identity system, the database and the AI services everything depends on, so it cannot be fixed one app at a time. SovereignOS is planned as an AI native foundation, with sovereignty, compliance and AI oversight built in rather than bolted on. It is designed as a measured path, not rip-and-replace: you adopt it where it helps and keep what already works.

We define it in six checkable dimensions, Data (where it lives), Operational (can you keep running), Technology (no hidden dependencies), Jurisdiction (whose laws apply), Knowledge (do your people understand it) and Exit (can you leave). For each, the aim is evidence, not promises, for example a reviewable record of where data sits and who touched it. It is a checklist you can hold any supplier to, ourselves included.

AI is arriving in your organisation whether it is planned or not, and the real risk is ungoverned AI, tools that send sensitive data outside your control or produce answers no one can check. SovereignOS is designed to make AI usable safely: approved local models, drafts that cite their sources, a human-approval gate before anything acts, and a reviewable record. The goal is AI you can defend to an auditor, not more AI faster.

The roadmap covers seventeen planned products across Applications, Intelligence, Foundation and Trust, built by the alliance and its planned open source community rather than a single vendor. When the relevant releases are published under OSI-approved licences, alliance partners, European integrators and the wider developer community can build and maintain them under those terms. To be honest, these are planned products on a roadmap, not a finished catalogue you can buy today; the design goal is that no single company becomes the new bottleneck.

SovereignOS is a roadmap. Its products are described as planned capabilities at different stages of design and development, not a generally available release you can deploy tomorrow. We say so on purpose: the right way to engage now is a low-risk assessment and a contained pilot, not a purchase. Where something is not ready, we tell you.

Open source describes how software is licensed and built openly, not whether it is supported. Professional support, service levels and accountability come from named commercial partners in the alliance, as they do for other openly licensed systems. When a release is published under an OSI-approved licence, another qualified partner can review and adapt it if you want to switch. A service agreement still defines who supports your deployment and how.

Honestly, on day one a roadmap product will not match software that has had decades and billions invested in it. The strategy is to be genuinely good enough for the core daily work, documents, mail, knowledge, service desk, and to close the gap through an open community rather than one vendor’s release schedule. Where a capability is not ready, the plan is to say so and to support running alongside your existing tools during transition.

Migration is part of delivery. The Assess → Define → Deploy → Verify path starts by mapping exactly what data and formats you have before anything moves. The intent is to support open, standard formats so existing records come across and stay usable, and to migrate in planned, reversible stages with verification before anything is switched off. Migration always takes real effort; the aim is to make it measured and evidenced.

Interoperability is a design priority, because no institution can replace everything at once. SovereignOS is intended to run alongside your current systems and exchange data through open standards, so you can adopt it in one area while the rest keeps working. Running old and new in parallel during transition is expected, not a failure.

The design is intended to let your organisation set the data boundary, approved model routes and access policy, with a reviewable activity record showing what the deployment does. The selected infrastructure, operating entities, support routes and any subprocessors still need to be assessed for each release and contract. A supplier should show that evidence before you rely on a sovereignty claim, including us.

In practice openness tends to strengthen security: many independent experts can inspect the code and find flaws, rather than trusting that a single vendor found and disclosed them, which is why open source systems already run critical government and banking infrastructure. On top of that, SovereignOS plans a dedicated Trust layer, AI guardrails, AI defense and post quantum cryptography, designed against today’s and tomorrow’s threats. To be clear, the alliance holds no third-party security certifications yet; these are design commitments, and formal certification would come later.

The design maps onto these obligations through controls intended to support GDPR and EU AI Act governance: lifecycle records, human oversight and technical evidence, with cited drafts, a human approval gate and a reviewable activity record. Compliance remains your organisation’s legal responsibility, you generally remain the “deployer” under the AI Act with your own duties, and the alliance does not claim certifications it has not earned. The aim is to make those duties easier to assess and evidence.

That is exactly why the design keeps a person in charge, not the machine. Drafts are intended to cite their sources so a person can check them, nothing acts without passing a human-approval gate, and each step is designed to leave a reviewable record. The accountable official still decides. Citations reduce but do not eliminate the risk, so the human reviewer remains essential, by design.

A fair challenge, which is why Exit is one of the six dimensions we hold ourselves to, not an afterthought. The planned use of open standards and OSI-approved licences is intended to support usable exports, another provider or customer operation where the release and deployment conditions allow it. Switching still involves work such as retraining and reintegration, so each deployment needs a tested transition plan.

Open source removes per-seat licence fees, but honesty matters: the real costs move to migration, support, training, hosting and compute, and integration, and those are not zero. The fair way to judge it is total cost of ownership over several years, where no licence lock-in, no forced upgrade cycles and freedom to shop for support can mean meaningful and, importantly, more predictable costs. We would encourage you to model your own numbers rather than take “free” on trust.

Open source and alliance based delivery can fit evidence based public procurement, and open standards can reduce single vendor dependency. Because support and integration come from commercial partners, you procure services through familiar routes rather than buying a black box. You still run your own procurement and legal review; the alliance is not a shortcut around either, and we expect to work closely with your teams.

Accountability sits with the named commercial partner delivering your deployment, under a proper service agreement. To be plain: the alliance itself does not offer a production SLA or indemnity, and the open source software is provided as-is, your contracting counterparty for guarantees is the commercial partner. Because the system is open, another qualified provider can step in if needed, a fallback that proprietary lock-in does not give you.

No, and we are deliberately clear about it. SovereignEU is an independent European public and private alliance advancing open source sovereign AI; it is not an institution of the European Union and is not EU-endorsed. Our alignment with European values and rules such as GDPR and the AI Act is by design and by choice, not because we hold any official status.

This is one reason the planned open source direction matters. If the alliance faltered, open formats, documented exports and any published source under the release licence could support another provider or your own team. That is an intended continuity option, not a promise that migration is effortless; the release and deployment evidence must show what can be transferred.

You should not trust it on reputation, you should trust it on what it can prove, which is the point of the technical evidence pillar and the public repositories where progress is published. This is a roadmap and an alliance still earning its track record, which is why we recommend starting small, verifying results and expanding only as it proves itself. Established vendors offer maturity, while provider jurisdiction, lock in and unpredictable cost still need to be assessed.

You begin small and reversibly. The Assess → Define → Deploy → Verify path starts with a low-risk assessment and a contained pilot in one area, running alongside your existing systems, before any wider commitment, and you expand only once you have verified results and your people are confident operating it. The first step is understanding and a plan, not a purchase.