Sovereign AI in practice: how to check your AI infrastructure against the BSI C3A criteria.

Executive summary
The BSI’s C3A criteria were built for cloud services, so they don’t map neatly onto an AI stack. We translate the six C3A sovereignty domains into audit questions for each of the five layers of an AI stack, then show how to turn the assessment into a roadmap without giving up AI capabilities.

A sovereign AI infrastructure check covers every layer of your AI deployment, from the models to the people who operate them. The cloud hosting contract is only one part of it. Ahead of the German government’s Digital-Gipfel in Berlin on November 2–3, 2026, IT and procurement leads in Germany, Austria, and Switzerland now treat digital sovereignty as a requirement. The Federal Office for Information Security (BSI, Bundesamt für Sicherheit in der Informationstechnik) published its Criteria enabling Cloud Computing Autonomy (C3A) so organizations can assess whether a cloud service can be used under their own control. An assessment against C3A shows how much operational independence you have and which vendor dependencies you need to manage.

From the EU Cloud Sovereignty Framework to the Digital-Gipfel: the BSI published C3A v1.0 on April 27, 2026.

What are the BSI C3A criteria, and how do they relate to C5?

The BSI C3A criteria catalog is Germany's standardized framework for assessing whether a digital service permits self-determined use. It builds directly upon the cybersecurity baseline of BSI C5:2026. Published by the BSI on April 27, 2026, C3A makes digital sovereignty measurable and auditable for public sector and commercial IT procurement. C3A adopts the categorization and objectives of the European Union Cloud Sovereignty Framework (EU CSF), evaluating cloud offerings across six core sovereignty domains: Strategic Sovereignty (SOV-1), Legal & Jurisdictional Sovereignty (SOV-2), Data Sovereignty (SOV-3), Operational Sovereignty (SOV-4), Supply Chain Sovereignty (SOV-5), and Technology Sovereignty (SOV-6).

The BSI Cloud Computing Compliance Criteria Catalogue (C5:2026) attests baseline technical cybersecurity controls, corresponding to security and compliance sovereignty (SOV-7). C3A presupposes C5 compliance as a mandatory prerequisite and evaluates non-technical legal exposure, vendor dependencies, and operational governance. Environmental sustainability (SOV-8) is excluded because it falls outside the BSI security mandate. In short, C5 shows that security controls work. C3A evaluates whether an organization can operate its digital services without unwanted external interference or sudden loss of access.

C3A turns six of the eight EU CSF sovereignty objectives into verifiable criteria. Security is covered by C5:2026, a prerequisite for C3A.

Is C3A a certification? Why "C3A-compliant" is the wrong question

As the BSI states, "The C3A Framework is not binding in itself." Providers demonstrate compliance by presenting evidence through an independent audit. Within each domain, the framework defines criteria alongside stricter additional criteria that raise the requirements for operational autonomy. That makes "Is this provider C3A-compliant?" the wrong question. Ask instead which C3A criteria it meets, at which level, and with what audit evidence.

How do the C3A sovereignty domains apply to your AI stack?

To apply C3A to AI, we map its six sovereignty domains onto the five functional layers of an AI stack: foundation models, compute execution, software harness and agents, data pipelines, and operations. C3A was written for cloud services, so this mapping is our interpretation, not an official BSI view.

Standard cloud computing contracts cover basic hosting, but AI systems add dependencies at every operational layer. Our breakdown of the layers of a sovereign AI stack details how hardware, open-source orchestration, and model weights interact in production systems.

Every domain touches every layer. The list below shows where each domain carries the most risk in an AI stack, so IT and procurement leads can see what standard service-level agreements (SLAs) miss:

1. Foundation models mapped to Strategic Sovereignty (SOV-1): SOV-1 evaluates EU ownership stability, governance influence, and protection against non-EU corporate takeovers. In the AI stack, model weights and intellectual property licensing decide whether a non-EU entity can unilaterally modify model behavior, restrict license terms, or alter acceptable use policies.

2. Compute (GPUs) mapped to Legal & Jurisdictional Sovereignty (SOV-2): SOV-2 requires providers to identify, at least once a year, non-EU laws with cross-border implications for their services and to carry out a structured risk assessment. For compute execution, running GPU inference on infrastructure subject to foreign laws exposes prompt inputs, activation states, and generated outputs to extraterritorial inspection or remote service suspension.

3. Software harness and agents mapped to Technology Sovereignty (SOV-6): SOV-6 requires an EU backup of source code no older than 24 hours, and documented contingency strategies to keep services running if third parties disconnect. In the AI harness, orchestration tools, prompt templates, agentic tools, and retrieval pipelines must be portable so that workflows can run independently if external application programming interfaces (APIs) disconnect.

4. Data mapped to Data Sovereignty (SOV-3): SOV-3 covers customer control over data residency, external encryption key management, integration of your own identity provider, and access logging. For AI data pipelines, training corpora, fine-tuning datasets, vector database embeddings, and retrieval-augmented generation (RAG) context windows must be protected using customer-managed encryption keys (BYOK), with access managed through your own identity provider.

5. Operations mapped to Operational Sovereignty (SOV-4) and Supply Chain Sovereignty (SOV-5): SOV-4 requires local operation, maintenance, and Security Operations Center (SOC) capabilities within the EU, while SOV-5 asks for transparency into software dependencies based on a Software Bill of Materials (SBOM) or equivalent. In AI operations, model monitoring, guardrail telemetry, identity management, and hardware maintenance must remain under EU operational control. Otherwise, a provider can switch off your AI service administratively.

How to assess the operational independence of your sovereign AI infrastructure

Audit each stack layer against specific criteria in the BSI C3A catalog, and base your verdict on documented evidence, not on provider marketing.

The checklist below turns the six C3A sovereignty domains into audit questions per AI stack layer for IT and procurement leads:

Is the sovereignty boundary enforced by contracts, architecture, or both?

You need both contractual protections under EU jurisdiction and technical controls built into the AI deployment. Contractual agreements establish legal enforceability, SLA commitments, and regulatory compliance under European law. However, contracts alone cannot prevent remote service disconnections, network outages, or foreign lawful access requests executed at the infrastructure level.

Technical architecture provides physical and cryptographic insulation. Enforcing customer-managed encryption keys (BYOK), running inference within containerized environments on European sovereign cloud platforms, and maintaining open-weights model fallbacks keep systems running even if external connections are severed. Our analysis of when owning your LLMs pays off helps you weigh the cost of self-hosted open models against operational risk. For an overview of broader European regulatory frameworks, our analysis of EU cloud sovereignty assurance levels examines procurement requirements under the proposed Cloud and AI Development Act (CADA).

CADA is still a proposed regulation, with formal adoption expected in late 2027, so its legal thresholds may change during negotiations. Because C3A and CADA both build on the EU Cloud Sovereignty Framework, an audit against C3A today shows where your AI stack stands and prepares you for CADA's requirements once they are final.

Does C3A matter in Austria and Switzerland?

Yes. Although Germany's BSI published it, the C3A criteria catalog is a practical evaluation framework for IT and procurement leads in Austria and Switzerland too. Austria is an EU member state where the GDPR applies directly, and Switzerland's revised Federal Act on Data Protection (FADP) is aligned with EU data protection standards. With the BSI C3A criteria, Swiss and Austrian organizations can assess their independence from AI vendors and benchmark cloud providers against one European standard.

From check to roadmap: closing sovereignty gaps without losing capabilities

A sovereign AI roadmap starts with your highest-risk workloads and closes gaps without sacrificing AI capabilities. Boston Consulting Group (BCG) argues in AI Sovereignty Is an Illusion. Resilience Is Real that AI sovereignty conceived as full-stack autarky is an illusion and that the realistic goal is AI resilience. We agree, and for enterprises we'd go one step further: independence at the software and model layer is achievable today, even when the hardware is not European.

IT and procurement leads can move from an initial C3A assessment to a mature deployment in four steps:

1. Inventory AI stack components: Map active foundation models, compute hosts, vector repositories, and software orchestration tools across your organization.

2. Execute C3A and C5 gap audits: Benchmark AI vendors against BSI C5 security controls and C3A operational autonomy criteria.

3. Decouple orchestration from underlying providers: Containerize inference pipelines, enforce BYOK key management, and adopt open API standards to ensure model portability.

4. Update procurement specifications: Integrate C3A criteria into upcoming requests for proposals (RFPs) to mandate vendor transparency, SBOM availability, and clear contingency options.

We help organizations build these architectures. Explore our sovereign AI solutions or read our guide on deploying high-risk AI systems under the EU AI Act. Verifiable AI governance helps keep your sovereign AI infrastructure compliant and auditable over time.