Bull + Schwarz Digits sovereign AI stack: does bundling European hardware and cloud actually cut your dependence on US hyperscalers?

Key Points:

• Bundling European AI hardware with a European-operated cloud buys jurisdictional sovereignty (who can legally compel your data) and operational sovereignty (who holds the admin keys). It buys zero portability. The vendor owns the first two; you own the third.
• Lock-in lives in the API layer, far above the rack: provider-exclusive managed services, provider-native IAM, hardcoded Terraform and CI/CD pipelines that encode one provider's primitives. Changing the flag on the building changes none of that.
• Supply-chain sovereignty is partial at best. A BullSequana rack can be built in Angers, but the accelerators inside are overwhelmingly NVIDIA silicon, and TSMC held 72.5% of global foundry revenue in Q2 2026.
• Use one practical test instead of a procurement questionnaire: can you redeploy a production-like environment onto a second provider's Kubernetes in under a day? Portable architectures migrate in weeks. Provider-coupled architectures migrate in years, if at all.
• Qovery keeps the layer developers touch provider-neutral. It deploys and operates applications inside your own AWS, GCP, Azure or Scaleway account, or on an existing Kubernetes cluster, so the cloud underneath stays a configuration decision rather than a rewrite.

Cloud lock-in has never lived in the rack. It lives in the APIs your code calls.

Bull and Schwarz Digits announced on November 3, 2026 that they will build a European AI and cloud stack from the servers up, with STACKIT as the cloud. So does bundling hardware and cloud buy more independence from US hyperscalers? Partly, and the part it buys is real. You get strong jurisdictional and operational sovereignty, partial supply-chain sovereignty, and no portability sovereignty at all. Portability is the one that decides whether you can ever leave.

I run a company whose whole job sits on that portability layer, so I'll be explicit about where my bias starts. The first half of this article is about the deal itself and what it changes.

What exactly did Bull and Schwarz Digits announce?

Bull and Schwarz Digits signed a memorandum of understanding on November 3, 2026 to build a European AI and cloud infrastructure ecosystem, combining Bull servers manufactured in Angers, France with Schwarz Digits' STACKIT cloud, so that both the hardware integrator and the cloud operator sit under EU jurisdiction (Bull press release).

The two parties:

• Bull is the French HPC, AI and quantum systems builder behind the BullSequana line. Atos bought it in 2014 and ran it as Eviden from 2022. In 2026 it became a standalone company again, with the French State as a shareholder (Bull heritage). Bull reports roughly €720 million in revenue and 3,000 staff.
• Schwarz Digits is the IT and digital division of the Schwarz Group, the owner of Lidl and Kaufland. It runs the German cloud STACKIT and the group's cybersecurity business.

The release, announced at the German Government's 2026 Digital Summit in Berlin, commits to four concrete things. Rack-scale AI servers built at Bull's Angers factory with direct liquid cooling. The BullSequana AI software platform listed on the STACKIT Marketplace. Co-designed servers based on Open Compute Project standards. And follow-on work on SAP RISE integration, large HPC projects and quantum. It's an MoU, and it publishes no GPU count, megawatt figure or investment amount, so I won't invent one.

This is a different kind of thing from a hyperscaler's "EU sovereign region". Those keep a US-incorporated parent above an EU legal entity and EU-resident staff. Here, the company that builds the hardware and the company that runs the cloud are both European.

It also lands in a crowded policy context. Gaia-X has been trying to set federation rules since 2020. On February 11, 2025 the European Commission launched InvestAI to mobilise €200 billion for AI, including a €20 billion fund for AI gigafactories (European Commission). And JUPITER, Europe's first exascale supercomputer at Jülich, was itself built on Bull's BullSequana XH3000.

For scale, Amazon, Microsoft and Google held 70% of the European cloud market in 2024, while European providers held around 15%, down from 29% in 2017 (Synergy Research Group, July 2025).

The deal changes who can legally compel access to your data and who holds the admin keys. On its own, it does nothing to make your application able to leave.

What does 'sovereignty' actually mean, and which kind does this deal buy?

Cloud sovereignty is four separable properties: jurisdictional (who can legally compel your data), operational (who holds the admin keys), supply-chain (who makes the silicon) and portability (whether you can leave), and the Bull and Schwarz Digits partnership is strong on the first two, partial on the third and neutral on the fourth.

Jurisdictional. The US CLOUD Act lets US authorities compel a US-controlled provider to produce data in its "possession, custody, or control", wherever that data is stored (US DOJ CLOUD Act resources; 18 U.S.C. § 2713). The EDPB and EDPS have set out how that clashes with GDPR transfer rules (EDPB-EDPS joint response), and the CJEU's Schrems II ruling (Case C-311/18) shows how seriously EU courts take it. A provider with no US parent sits outside that statute's direct reach.

Operational. Who holds admin credentials, who patches the hypervisor, and whether support runs entirely on EU-resident staff without a non-EU parent able to issue instructions. STACKIT is built for this.

Supply chain. This is where the bundle is weakest. JUPITER, the flagship of European HPC, runs on roughly 24,000 NVIDIA GH200 Grace Hopper Superchips (EuroHPC JU). NVIDIA reported $89.0 billion in data center revenue for the quarter ended July 26, 2026 (NVIDIA), and TSMC took 72.5% of global foundry revenue in Q2 2026 with its 5/4nm and 3nm lines fully booked (TrendForce). EuroHPC, SiPearl and the EU Chips Act are the long-horizon counterweight. They're a decade-scale bet, not a 2026 procurement option.

Portability. This one is a property of your software architecture. No procurement decision, contract clause or certification can grant it to you.

The verdict I'd quote: real progress on jurisdiction and operations, partial on supply chain, neutral on portability. That's genuine engineering and procurement work with legal consequences for banks, health and the public sector. It answers a different question from "am I locked in?"

Does bundling hardware with cloud reduce lock-in, or just relocate it?

Bundling European hardware with a European cloud cuts geopolitical and legal exposure but leaves switching costs where they were, because lock-in accumulates at the API layer, so a vertically integrated European stack can carry the same switching cost as AWS with a different flag on the building.

Lock-in piles up in four places:

• Provider-exclusive managed services: DynamoDB, BigQuery, Lambda, Cosmos DB, Cloud Run. Each one becomes a rewrite when you leave.
• Provider-native IAM: roles and policies that only make sense inside one provider's identity model.
• Hardcoded Terraform: modules that use one provider's resources directly, with no abstraction for a second target.
• CI/CD pipelines: deploy steps that call one provider's CLI, registry and load balancer APIs.

Egress is the financial side of lock-in, and regulation is now dealing with it. The EU Data Act (Regulation (EU) 2023/2854) has applied since September 12, 2025, and it removes switching and data egress charges entirely from January 12, 2027 (European Commission). Until then, providers may only charge their costs. Article 25 caps the customer notice period at two months and sets a 30-day transition period, which can be extended to seven months where the provider shows it is technically unfeasible.

The hyperscalers moved first. Google Cloud dropped data transfer fees for customers leaving on January 11, 2024 (Google Cloud), AWS followed on March 5, 2024 (AWS), and Microsoft on March 14, 2024 with conditions (TechCrunch). Free egress removes a bill. It leaves your architecture where it was: your DynamoDB tables still need rewriting.

Vertical integration cuts both ways. You get one accountable supplier and a short escalation path. You also get one supplier owning hardware, platform, support and the renewal negotiation at the same time.

The fair counter-argument: smaller European providers have a commercial reason to stay open. STACKIT, OVHcloud, Scaleway and IONOS all lean on Kubernetes and S3-compatible APIs, which lowers switching cost by design. Their managed Kubernetes services appear in the CNCF conformance program, which I'll come back to.

So my direct answer: yes, the bundle buys more independence from US hyperscalers. It only buys more independence in general if your application layer stays portable. For most engineering teams, "can we leave?" is the sovereignty question with the biggest price tag attached.

How do European sovereign cloud options actually compare in 2026?

European sovereign cloud options differ sharply in operator jurisdiction, managed-service breadth, Kubernetes conformance and how much US technology runs underneath, and those differences, more than the sovereignty label, set your real migration effort.

Be fair to the hyperscalers. The AWS European Sovereign Cloud went generally available in Brandenburg on January 15, 2026, backed by a planned €7.8 billion investment and an EU-based operating entity (Amazon). S3NS, Thales's joint venture running Google Cloud technology, received SecNumCloud 3.2 qualification for its PREMI3NS offer on December 17, 2025 (Thales). That's real engineering. The objection to the US-owned constructs is the parent company, and that's a legal question rather than an engineering one.

The single best portability signal when shortlisting is CNCF Certified Kubernetes conformance. Open the CNCF conformance listing or the cncf/k8s-conformance repository, pick the Kubernetes version folder, and look for the provider's product. The v1.35 folder lists 135 certified products as of November 6, 2026.

The practical gap: fewer managed services means more components you operate yourself. That takes platform engineering capacity, and in 2023, 57.5% of EU enterprises that recruited or tried to recruit ICT specialists had trouble filling the roles (Eurostat). For the German providers in more depth, see our STACKIT, IONOS and Open Telekom Cloud comparison.

What would actually make your stack sovereign-ready, regardless of provider?

A stack is sovereign-ready when the application runs on standards-conformant Kubernetes with open or standards-compatible data services, because then moving between AWS, GCP, Azure, Scaleway, STACKIT or your own datacenter becomes a weeks-scale project rather than a multi-year rewrite.

1. Standardise on Kubernetes. It's the one control-plane API every serious provider, sovereign ones included, implements and certifies against. 82% of container users now run it in production (CNCF 2025 Annual Survey).
2. Pick open data services. PostgreSQL, Redis, Kafka and S3-compatible object storage run everywhere. DynamoDB and Cosmos DB don't. You give up some convenience, so price that honestly.
3. Parameterise infrastructure as code by provider. Keep a second target in the repo even if you never use it. OpenTofu or Terraform modules with a provider variable beat hardcoded resources.
4. Keep identity, secrets and telemetry off one provider's IAM. OIDC, Vault or an equivalent, and OpenTelemetry.
5. Run a timed exit test every quarter. Redeploy a production-like environment on a second provider and time it. If it takes more than a day, you aren't portable yet. Our cloud portability drill walks through it.

The checklist I'd hand a CTO: zero provider-exclusive services in the critical path, IaC parameterised by provider, data services on open protocols, and a timed exit test in the last 90 days.

The trade-off is real. Portable architectures give up some depth of managed services and some per-service convenience. In return you get exit options and real bargaining power at every renewal.

Where does an internal developer platform fit in a sovereignty strategy?

An internal developer platform makes the cloud provider choice reversible: developers get one stable self-service interface while the cloud underneath stays swappable, so switching cost becomes a single, measurable platform decision instead of being spread across every team's bespoke pipelines.

Without a platform layer, every team bakes provider specifics into its own pipelines. Nobody can tell the board what leaving would cost, because the cost is spread across fifty repositories. With a platform layer, the provider becomes a cluster-level configuration choice.

That's where Qovery fits. Qovery deploys and operates applications inside your own cloud account (BYOC) on AWS, GCP, Azure or Scaleway, so the bill, the data, the contracts and any committed-spend discounts stay in your name. For other targets, Qovery connects to a Kubernetes cluster you already run: the Qovery Operator handles existing AWS, GCP and Scaleway clusters (in Preview on the Enterprise plan), and installation with the Qovery CLI covers other providers and on-premise clusters. That bring-your-own-Kubernetes path is how a STACKIT, OVHcloud or private target becomes realistic.

On top, teams get git-push deployments, a preview environment per pull request, auto-stop for non-production environments, managed cluster upgrades and per-environment RBAC, without a dedicated DevOps engineer. Auto-stop matters: Flexera's 2026 State of the Cloud Report puts wasted cloud spend at 29%, the first increase in five years.

To be clear about the limits: Qovery is not a sovereign cloud and does not replace STACKIT, OVHcloud or Scaleway. It's the portable application layer above whichever cloud you choose. Red Hat OpenShift and Rancher solve an adjacent problem with a heavier footprint. Northflank and Porter also run in your own cloud account, so check their supported providers against your sovereign target.

How do I test cloud portability with Qovery from Claude Code or Cursor?

You can connect Qovery to Claude Code, Cursor, Codex, OpenCode or Gemini CLI with one install command, then ask the agent in plain language to deploy the same application into a second cloud account or an existing Kubernetes cluster, which is the fastest honest measure of your switching cost.

Install the Agent Skills once:

curl -fsSL https://skill.qovery.com/install.sh | bash

Or scope them to a single repository:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code for read-only inspection, authenticated with OAuth:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want the agent to change things (you also need to enable write access in the Qovery Console):

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) set things up. The MCP Server operates what already exists. Then ask: "Deploy this app to my Scaleway account with Qovery" or "Deploy this to my existing Kubernetes cluster", and approve each step the agent proposes. Time it. That number is your real exit cost.

Docs: AI agent quickstart and Claude Code integration.