Kurz gesagt: Mit C3A hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) im April 2026 erstmals einen Kriterienkatalog veröffentlicht, der bewertet, wie unabhängig ein Unternehmen seine Cloud-Dienste nutzen kann. Behält es die Kontrolle über Daten und Schlüssel? Kann es den Anbieter wechseln? Da der Katalog für Cloud-Dienste geschrieben wurde, übertragen wir seine sechs Bewertungsbereiche auf die fünf Ebenen einer typischen KI-Lösung und leiten daraus konkrete Prüffragen ab. Zum Schluss zeigen wir, wie Sie aus dem Ergebnis einen Maßnahmenplan entwickeln, ohne auf leistungsfähige KI zu verzichten.
Wer über Souveränität von KI-Anwendungen spricht, denkt oft zuerst an den Cloud-Anbieter: Wo stehen die Server, was regelt der Vertrag? Das ist aber nur ein Teil. Souveränität betrifft jede Ebene Ihres KI-Einsatzes, von den Modellen über die Daten bis zu den Menschen, die die Systeme betreiben.
Wie weit oben das Thema inzwischen auf der Agenda steht, zeigt der Digital-Gipfel der Bundesregierung am 2. und 3. November 2026 in Berlin. Für IT- und Beschaffungsverantwortliche reicht ein allgemeines Bekenntnis zur Souveränität deshalb nicht mehr. Mit C3A gibt es erstmals einen Maßstab dafür. Eine Bewertung zeigt, wie viel operative Unabhängigkeit Sie tatsächlich haben und welche Anbieterabhängigkeiten Sie aktiv steuern müssen.
Okt. 2025
EU Cloud Sovereignty Framework vorgestellt
Okt. 2025
EU Cloud Sovereignty Framework vorgestellt
BSI veröffentlicht C5:2026 und C3A v1.0 (C3A: 27. April)
Apr. 2026
Apr. 2026
BSI veröffentlicht C5:2026 und C3A v1.0 (C3A: 27. April)
3. Juni 2026
EU-Kommission schlägt den Cloud and AI Development Act vor
3. Juni 2026
EU-Kommission schlägt den Cloud and AI Development Act vor
Digital-Gipfel der Bundesregierung, Berlin
2.–3. Nov. 2026
2.–3. Nov. 2026
Digital-Gipfel der Bundesregierung, Berlin
Vom EU Cloud Sovereignty Framework bis zum Digital-Gipfel: Das BSI veröffentlichte C3A v1.0 am 27. April 2026.
C3A, C5 und CADA: Wie hängen sie zusammen?
Seit 2016 gibt es mit dem Cloud Computing Compliance Criteria Catalogue (C5) einen etablierten BSI-Standard für sichere Cloud-Dienste, aktuell in der Version C5:2026. Der C3A-Kriterienkatalog (PDF, englisch) baut auf C5 auf, setzt aber einen anderen Schwerpunkt. Vereinfacht gesagt: C5 prüft, ob ein Cloud-Dienst sicher ist. C3A prüft, ob Sie die Kontrolle darüber behalten.
C3A übernimmt die Struktur des European Union Cloud Sovereignty Framework (EU CSF) und bewertet Cloud-Angebote in sechs Bereichen: strategische Souveränität (SOV-1), rechtliche Souveränität (SOV-2), Datensouveränität (SOV-3), operative Souveränität (SOV-4), Souveränität der Lieferkette (SOV-5) und technologische Souveränität (SOV-6). Den siebten Bereich des EU-Rahmens, die Sicherheits- und Compliance-Souveränität (SOV-7), deckt bereits C5 ab. Deshalb setzt C3A die Erfüllung von C5 voraus. Den achten Bereich, ökologische Nachhaltigkeit (SOV-8), lässt das BSI aus, weil dieser nicht zu seinem Auftrag gehört.
Auch rechtlich unterscheiden sich C3A und C5. Beide sind zunächst Kriterienkataloge und keine Gesetze. C5 ist inzwischen aber in einzelnen Bereichen verbindlich: Im Gesundheitswesen schreibt § 393 SGB V für die Verarbeitung von Gesundheits- und Sozialdaten in der Cloud ein C5-Testat vor. C3A ist dagegen freiwillig. Das BSI plant jedoch einen Leitfaden für C3A-Prüfungen nach dem Vorbild von C5, womit Souveränität in Ausschreibungen überprüfbar und nachvollziehbar wird.
Auf EU-Ebene ist ein verbindlicher Rahmen in Arbeit. Mit dem Cloud and AI Development Act (CADA) hat die EU-Kommission im Juni 2026 eine Verordnung vorgeschlagen, die ein einheitliches EU-weites Bewertungsverfahren für die Souveränität von Cloud- und KI-Diensten einführen soll, zunächst vor allem für die öffentliche Beschaffung. Anders als C3A wäre CADA rechtlich verbindlich und würde KI ausdrücklich einschließen. Der Vorschlag befindet sich allerdings noch im Gesetzgebungsverfahren, und wie sich C3A und der künftige EU-Rahmen zueinander verhalten, ist noch offen. Eine Bewertung nach C3A ersetzt deshalb keine spätere Prüfung nach CADA, zeigt aber schon heute, wo Ihre KI-Systeme stehen und wo Handlungsbedarf besteht.
|
C5 |
C3A |
CADA |
|
|
Kernfrage |
Ist der Cloud-Dienst sicher? |
Behalten Sie die Kontrolle? |
Wie souverän sind Cloud- und KI-Dienste in der EU? |
|
Herausgeber |
BSI |
BSI |
EU-Kommission |
|
Gegenstand |
Cloud-Dienste |
Cloud-Dienste |
Cloud- und KI-Dienste |
|
Verbindlichkeit |
In Teilen gesetzlich vorgeschrieben, z. B. § 393 SGB V |
Freiwillig |
Als EU-Verordnung geplant |
|
Stand |
Etabliert, aktuell C5:2026 |
Veröffentlicht im April 2026, Prüfleitfaden in Vorbereitung |
Vorschlag vom Juni 2026 |

C3A macht sechs der acht Souveränitätsziele des EU CSF prüfbar. Sicherheit deckt C5:2026 ab, die Voraussetzung für C3A.
Praxisbeispiel (fiktiv): Ein mittelgroßer Energieversorger setzt einen KI-Agenten im Kundenservice ein. Der Agent beantwortet Fragen zu Abschlägen, Zählerständen und Tarifwechseln und greift dafür auf Verträge und Kundendaten zu. Alles läuft bei einem US-Cloud-Anbieter im Rechenzentrum in Frankfurt, mit einem Sprachmodell, das nur über dessen Plattform verfügbar ist. Die Daten liegen in Deutschland, der Vertrag ist DSGVO-konform. Ist das souverän? Wir kommen in diesem Artikel mehrfach auf das Beispiel zurück.
Ist C3A eine Zertifizierung, und was heißt „C3A-konform“?
Nein. C3A ist ein Kriterienkatalog, kein Gütesiegel. Künftig sollen Anbieter die Erfüllung der Kriterien in unabhängigen Prüfungen nachweisen, ähnlich wie bei C5. Den Leitfaden dafür will das BSI noch veröffentlichen. Innerhalb jedes Bereichs definiert das C3A-Rahmenwerk grundlegende Kriterien und strengere Zusatzkriterien, die höhere Anforderungen an die operative Unabhängigkeit stellen. Ein pauschales „C3A-konform“ sagt deshalb wenig aus. Fragen Sie Anbieter lieber, welche Kriterien sie erfüllen, in welchen Bereichen sie auch die Zusatzkriterien abdecken und welche Prüfnachweise sie vorlegen können.
Wie lassen sich die C3A-Bereiche auf Ihre KI-Systeme übertragen?
Wir ordnen die sechs Souveränitätsbereiche von C3A den fünf Ebenen zu, aus denen ein typisches KI-System besteht: Rechenleistung, KI-Modelle, Datenpipelines, Agenten und Orchestrierung sowie Betrieb. Da C3A für Cloud-Dienste geschrieben wurde, ist diese Zuordnung unsere Interpretation und keine offizielle Sicht des BSI.
Bei KI reicht die Abhängigkeit vom Anbieter weit über das Hosting hinaus. Wer ein Modell nutzt, das nur über die Plattform eines einzelnen Anbieters verfügbar ist, ist an diesen Anbieter gebunden. Das gilt ebenso, wenn Agenten auf einer Plattform entwickelt und betrieben werden, die nur mit den Diensten eines Herstellers funktioniert, oder das System auf spezielle Hardware angewiesen ist. Ein Wechsel ist dann nicht ohne Weiteres möglich. Wie die einzelnen Ebenen in der Praxis zusammenspielen, beschreiben wir ausführlicher in unserer Analyse zu souveräner KI (englisch).
Grundsätzlich betrifft jeder Bereich jede Ebene. Die folgende Übersicht zeigt, wo das Risiko jeweils am größten ist, und damit auch, was übliche Service-Level-Agreements (SLAs) nicht abdecken:
1. KI-Modelle und SOV-1 (Strategische Souveränität): Hier geht es darum, wer einen Anbieter kontrolliert und wie gut er vor Übernahmen von außerhalb der EU geschützt ist. Bei KI-Modellen entscheidet das, wer die Rechte an den Modellgewichten hält. Sitzt dieser Anbieter außerhalb der EU, kann er Verhalten, Lizenzbedingungen und Nutzungsrichtlinien des Modells einseitig ändern.
2. Rechenleistung (rechtliche Souveränität, SOV-2): Dieser Bereich fragt, ob Gesetze von Staaten außerhalb der EU auf einen Dienst durchgreifen können. Läuft die Inferenz auf GPUs eines Anbieters, der solchem Recht unterliegt, können dortige Behörden unter Umständen auf Prompts und Antworten zugreifen oder den Dienst abschalten lassen.
3. Agenten und Orchestrierung SOV-6 (Technologische Souveränität): Hier geht es darum, ob ein Dienst weiterläuft, wenn Dritte die Verbindung kappen. Für KI heißt das: Orchestrierung, Prompt-Vorlagen und Agenten-Werkzeuge sollten sich ohne großen Aufwand in eine andere Umgebung übertragen lassen. Sonst stehen Ihre Abläufe still, sobald eine externe Schnittstelle wegfällt.
4. Daten Pipelines und SOV-3 (Datensouveränität): Dieser Bereich fragt, ob Sie selbst bestimmen, wo Ihre Daten liegen und wer sie entschlüsseln kann. Bei KI betrifft das nicht nur die Ausgangsdaten, sondern auch alles, was daraus entsteht: Datensätze für das Fine-Tuning, Embeddings in Vektordatenbanken und die Dokumente, die über Retrieval-Augmented Generation (RAG) in Anfragen einfließen.
5. Betrieb und SOV-4 (Operative Souveränität) sowie SOV-5 (Lieferketten-Souveränität): Diese Bereiche fragen, wer einen Dienst betreibt und woraus er besteht. Zur Lieferkette gehören bei KI auch die eingesetzten Modelle und Open-Source-Bibliotheken. Liegen Überwachung, Wartung und Identitätsverwaltung bei einem Team außerhalb der EU, kann ein Anbieter Ihren KI-Dienst im Zweifel administrativ abschalten.
| C3A-Bereich | KI-Modelle | Rechenleistung (GPUs) | Agenten und Orchestrierung | Datenpipelines | Betrieb |
|---|---|---|---|---|---|
| SOV-1Strategische Souveränität | Dunkler Ton: größtes Risiko in dieser Ebene: Wer die Rechte an den Modellgewichten hält | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls |
| SOV-2Rechtliche Souveränität | Heller Ton: Bereich gilt ebenfalls | Dunkler Ton: größtes Risiko in dieser Ebene: Durchgriff von Nicht-EU-Recht auf die GPU-Inferenz | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls |
| SOV-3Datensouveränität | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls | Dunkler Ton: größtes Risiko in dieser Ebene: Eigene Schlüssel, eigener Identitätsanbieter | Heller Ton: Bereich gilt ebenfalls |
| SOV-4Operative Souveränität | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls | Dunkler Ton: größtes Risiko in dieser Ebene: SOC und Betrieb in der EU |
| SOV-5Lieferketten-Souveränität | Heller Ton: Bereich gilt ebenfalls | Dunkler Ton: größtes Risiko in dieser Ebene: Kapazitätsmanagement in der EU | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls | Dunkler Ton: größtes Risiko in dieser Ebene: SBOM für KI-Komponenten |
| SOV-6Technologische Souveränität | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls | Dunkler Ton: größtes Risiko in dieser Ebene: Portable Orchestrierung, EU-Code-Backup ≤ 24 h | Heller Ton: Bereich gilt ebenfalls | Heller Ton: Bereich gilt ebenfalls |
Matrix als Bild herunterladen (PNG)
Jeder C3A-Bereich betrifft jede Ebene einer souveränen KI-Architektur. Die dunkleren Felder zeigen, wo ein Bereich nach Einschätzung von ML6 das größte Risiko trägt.
Im Praxisbeispiel zeigt sich das Risiko auf fast jeder Ebene. Das Rechenzentrum steht zwar in Frankfurt, der Anbieter unterliegt aber US-Recht (SOV-2). Das Modell ist nur über seine Plattform verfügbar (SOV-1), der Agent wurde mit deren Werkzeugen gebaut (SOV-6), und die Überwachung übernimmt ein globales Team des Anbieters (SOV-4). Nur bei den Daten kann der Versorger mit eigener Schlüsselverwaltung schon heute viel erreichen (SOV-3).
Checkliste: Prüffragen nach C3A für jede Ebene Ihrer KI-Systeme
Prüfen Sie jede Ebene Ihres KI-Systems anhand konkreter Kriterien aus dem BSI-Kriterienkatalog C3A. Stützen Sie Ihr Urteil dabei auf dokumentierte Nachweise, nicht auf Werbeaussagen des Anbieters.
Die folgende Checkliste übersetzt die sechs Souveränitätsbereiche von C3A in konkrete Prüffragen für jede Ebene. Sie richtet sich an IT- und Beschaffungsverantwortliche:
|
C3A-Souveränitätsbereich |
Ebene des KI-Systems |
Referenz BSI-Kriterienkatalog C3A |
Prüffrage für Ihre souveräne KI-Infrastruktur |
|---|---|---|---|
|
Strategische Souveränität (SOV-1) |
KI-Modelle |
SOV-1-01 / SOV-1-04 |
Hat der Modell- oder Cloud-Anbieter seinen Sitz in der EU und unterliegt er ausschließlich EU-Recht? Ist er vertraglich verpflichtet, Sie mindestens 90 Tage im Voraus zu informieren, wenn sich seine Eigentümerverhältnisse ändern? |
|
Rechtliche Souveränität (SOV-2) |
Rechenleistung (GPUs) |
SOV-2-01-C |
Prüft der Anbieter mindestens einmal im Jahr, welche Gesetze von Staaten außerhalb der EU auf die Rechenleistung zugreifen können, auf der Ihre KI läuft? Und bewertet er diese Risiken nachvollziehbar und dokumentiert? |
|
Datensouveränität (SOV-3) |
Datenpipelines |
SOV-3-02 / SOV-3-03 |
Sind die Daten Ihres KI-Systems, einschließlich der Embeddings in Vektordatenbanken, mit Schlüsseln verschlüsselt, die Sie selbst außerhalb des Anbieters verwalten? Und läuft der Zugriff über Ihren eigenen Identitätsanbieter? |
|
Operative Souveränität (SOV-4) |
Betrieb |
SOV-4-04 / SOV-4-07 |
Wird das Security Operations Center (SOC) ausschließlich in der EU betrieben? Und wird jede Weitergabe von Betriebs- und Nutzungsdaten an Dritte kontrolliert und protokolliert? |
|
Operative Souveränität (SOV-4) |
Betrieb |
SOV-4-09-C / SOV-4-10-C |
Testet der Anbieter mindestens einmal im Jahr, ob sein Dienst weiterläuft, wenn die Verbindung zu Netzen außerhalb der EU getrennt wird? Und weist er nach, dass sich Updates auch nach einer Trennung von bis zu 90 Tagen noch einspielen lassen? |
|
Lieferketten-Souveränität (SOV-5) |
Betrieb und Rechenleistung (GPUs) |
SOV-5-01 / SOV-5-05 |
Legt der Infrastrukturanbieter offen, aus welchen Komponenten seine KI-Dienste bestehen, etwa über eine Software Bill of Materials (SBOM), die auch eingesetzte Modelle und Open-Source-Bibliotheken umfasst? Und werden seine Rechenkapazitäten innerhalb der EU geplant und verwaltet? |
|
Technologische Souveränität (SOV-6) |
Agenten und Orchestrierung |
SOV-6-01 / SOV-6-02 |
Hält der Anbieter in der EU eine Sicherung seines Quellcodes vor, die höchstens 24 Stunden alt ist und mindestens fünf ältere Versionen umfasst? Gehören dazu auch die Konfiguration der Infrastruktur und die Werkzeuge, mit denen die Dienste bereitgestellt werden? |
Im Praxisbeispiel müsste der Energieversorger die meisten der sieben Fragen mit „Nein“ oder „Unklar“ beantworten. Das heißt nicht, dass er den Anbieter wechseln muss. Es zeigt aber, wo er nachverhandeln oder technisch vorsorgen sollte.
Reichen Verträge aus, um Ihre KI-Systeme vor Zugriffen von außen zu schützen?
Nein. Verträge allein reichen nicht aus, denn sie regeln, was ein Anbieter darf, verhindern aber nicht, was technisch möglich ist. Wirksame Souveränität erfordert deshalb beides: vertragliche Absicherung nach EU-Recht und technische Vorkehrungen, die fest in Ihre KI-Systeme eingebaut sind. Verträge machen Ansprüche rechtlich durchsetzbar, legen zugesicherte Leistungen in Service-Level-Agreements (SLAs) fest und stellen die Einhaltung europäischer Vorgaben sicher. Sie verhindern jedoch nicht, dass ein Dienst aus der Ferne abgeschaltet wird, Verbindungen ausfallen oder Behörden von Staaten außerhalb der EU auf die Infrastruktur zugreifen.
Hier setzt die technische Architektur an. Sie schützt Systeme physisch und kryptografisch vor dem Zugriff Dritter. Selbst verwaltete Schlüssel, Modelle, die in Containern auf souveränen Cloud-Plattformen in Europa laufen, und offene Modelle mit frei verfügbaren Gewichten als Rückfalloption halten den Betrieb auch dann aufrecht, wenn externe Verbindungen wegfallen. Ob sich der Betrieb eigener offener Modelle lohnt, hängt vom Verhältnis zwischen Betriebskosten und operativem Risiko ab. Diese Abwägung beschreiben wir in unserer Analyse, wann sich eigene LLMs lohnen (englisch). Einen Überblick über die europäischen Rahmenbedingungen gibt unsere Analyse der Souveränitätsstufen für die EU-Cloud (englisch), die auch die Beschaffungsanforderungen des geplanten Cloud and AI Development Act (CADA) einordnet.
Im Praxisbeispiel hat der Versorger einen Vertrag nach EU-Recht und ein Rechenzentrum in Frankfurt. Ordnet eine US-Behörde die Herausgabe von Daten an, hilft dieser Vertrag nur begrenzt. Selbst verwaltete Schlüssel erschweren den Zugriff auf gespeicherte Daten dagegen erheblich, unabhängig davon, was im Vertrag steht.
Von der Bewertung zum Maßnahmenplan: Souveränitätslücken schließen, ohne auf KI-Fähigkeiten zu verzichten
Ein Maßnahmenplan für souveräne KI beginnt bei den Anwendungen mit dem höchsten Risiko und schließt Lücken, ohne dass Sie auf KI-Fähigkeiten verzichten müssen. Die Boston Consulting Group argumentiert in AI Sovereignty Is an Illusion. Resilience Is Real (englisch), dass vollständige Unabhängigkeit über alle Ebenen eines KI-Systems hinweg unrealistisch ist und das eigentliche Ziel Resilienz sein sollte. Wir teilen diese Einschätzung und gehen für Unternehmen einen Schritt weiter: Bei Software und Modellen ist Unabhängigkeit schon heute erreichbar, auch wenn die Hardware nicht aus Europa stammt.
IT- und Beschaffungsverantwortliche kommen in vier Schritten von einer ersten C3A-Bewertung zu einer belastbaren Umsetzung:
1. Bestandteile Ihrer KI-Systeme erfassen: Verschaffen Sie sich einen Überblick, welche KI-Modelle, Rechenressourcen, Vektordatenbanken und Orchestrierungswerkzeuge in Ihrer Organisation im Einsatz sind.
2. Lücken gegenüber C5 und C3A ermitteln: Prüfen Sie Ihre KI-Anbieter anhand der Sicherheitsanforderungen von C5 und der C3A-Kriterien für operative Unabhängigkeit.
3. Abhängigkeiten von einzelnen Anbietern reduzieren: Betreiben Sie Modelle in Containern, verwalten Sie Ihre Schlüssel selbst und setzen Sie auf offene Schnittstellenstandards, damit sich Modelle austauschen lassen.
4. Ausschreibungen anpassen: Verankern Sie die C3A-Kriterien in künftigen Ausschreibungen und fordern Sie von Anbietern Transparenz, eine SBOM und klare Ausweichlösungen für den Notfall.
Wir unterstützen Organisationen beim Aufbau solcher Architekturen. Lernen Sie unsere Leistungen für souveräne KI kennen oder lesen Sie unseren Leitfaden zum Einsatz von Hochrisiko-KI-Systemen nach dem EU AI Act. Eine nachweisbare KI-Governance sorgt dafür, dass Ihre KI-Systeme dauerhaft regelkonform und überprüfbar bleiben.
Im Praxisbeispiel könnte der Weg so aussehen: Der Versorger erfasst zuerst, welche Teile seines Agenten an den Anbieter gebunden sind, und bewertet sie nach C3A. Danach übernimmt er die Schlüsselverwaltung selbst, baut den Agenten so um, dass ein offenes Modell als Ausweichlösung bereitsteht, und verankert die C3A-Kriterien in der nächsten Ausschreibung. Der Kundenservice läuft währenddessen unverändert weiter.



