Für Politik·Expertenblick

Souveräne KI für Politik und Verwaltung — Expertenblick

Architektur, Aufsicht und Vergabe in einem konsistenten Bild — was im Echtbetrieb tragen muss.

Souveräne KI ist für Politik und Verwaltung mehr als ein Beschaffungs-Thema: Sie ist die Voraussetzung für Vertrauen in algorithmische Verwaltungsentscheidungen. Wer Bürgerdaten in fremder Jurisdiktion verarbeitet oder Modelle einsetzt, deren Trainings-Provenienz unklar ist, gibt einen Teil staatlicher Souveränität ab — sichtbar im Streitfall, unsichtbar im Alltag.

Warum Souveränität jetzt auf der Verwaltungs-Agenda steht

Öffentliche Verwaltung steht KI-rechtlich am vordersten Punkt: Der EU AI Act stuft fast jede Verwendung in Behörden als Hochrisiko ein — Migration und Asyl, Strafverfolgung, Bildungszugang, kritische Infrastruktur, demokratische Prozesse. Parallel verlangt die DSGVO ihre Anwendbarkeit ohne Hintertüren, und das Bundesdatenschutzgesetz schließt unbeschränkten US-Zugriff auf Bürgerdaten aus. Wer KI in solchen Verfahren einsetzt, betreibt sie unter den schärfsten Anforderungen, die das deutsche und europäische Recht heute kennen.

Anders als in der Privatwirtschaft fehlt Verwaltungen die Möglichkeit, Akzeptanz durch Marktwahl herzustellen. Wer mit dem Finanzamt, dem Sozialamt oder dem Gericht zu tun hat, kann den Anbieter nicht wechseln. Algorithmische Verwaltungsentscheidungen brauchen daher eine Transparenz und Nachvollziehbarkeit, die Closed-API-Modelle aus Drittländern strukturell nicht liefern können — Modell-Versionen, Trainings-Daten und Update-Politik gehören zum demokratischen Rechenschafts-Pflichtenkatalog.

Die deutsche und europäische Politik hat technologische Souveränität in den letzten Jahren von einem Industriepolitik-Begriff zu einem strategischen Eigeninteresse aufgewertet. Beschaffungsentscheidungen für KI-Systeme sind heute auch außenpolitische Entscheidungen — über die Reichweite extraterritorialer Gesetze fremder Staaten in deutschen Verwaltungsabläufen, über Resilienz im Konfliktfall, über die Verhandlungsmacht Europas im globalen KI-Markt.

Drei Spannungsfelder, die Souveränität konkret machen

Hochrisiko per Definition

Annex III des EU AI Act listet öffentliche Verwaltung in mehreren Punkten — Bildungszugang, Asyl, Migration, Strafverfolgung, kritische Infrastruktur, demokratische Prozesse. Praktisch bedeutet das: Konformitätsbewertung, technische Dokumentation, Logging-Pflicht und menschliche Aufsicht für nahezu jedes KI-System mit Bürgerschnittstelle.

Vergaberecht versus Hyperscaler-Realität

Vergaberecht zwingt zu objektiven Kriterien, IT-Sicherheitsrecht schließt extraterritoriale Zugriffe aus, das BSI-Grundschutzkompendium verlangt nachvollziehbare Lieferketten. Closed-API-Angebote ohne Audit-Recht und mit US-Subprocessor-Klauseln passen technisch und rechtlich nicht in dieses Schema — auch wenn sie funktional verlockend wirken.

Vertrauen ist nicht delegierbar

Wenn algorithmische Entscheidungen Bürgerinnen und Bürger betreffen, kann Verantwortung nicht ausgelagert werden. Eine Behörde, die ihren KI-Stack nicht selbst auditieren oder im Streitfall offenlegen kann, verliert die Grundlage demokratischer Rechenschaft. Souveräne Architektur ist hier kein technisches Nice-to-have, sondern Bedingung für Legitimität.

Die vier Säulen souveräner KI

Auf Experten-Ebene sind die vier Säulen Bewertungsdimensionen, nicht Erklärungs-Hilfen. Die Frage ist, wie sich der Stack unter Last, Audit und Eskalation verhält.

Modell

Provenienz, Lizenz-Bedingungen, Inferenz-Ökonomie unter Souveränitäts-Constraint

Kritische Bewertungsachsen: Trainings-Datensatz-Dokumentation (für EU-AI-Act-Artikel-10-Konformität), Lizenz-Klauseln zu Re-Distribution und Fine-Tuning (Llama-Custom-Use-Klausel vs. Apache-2.0 / MIT), Hardware-Footprint im Inferenz-Mode (ein 70B-Modell quantisiert auf INT4 läuft auf 1×A100 80GB; FP8 auf einer H100 erreicht TPS-Werte vergleichbar zu Closed-API für Batch-Workloads). Für regulierte Branchen ist Open-Weight + selbst-gehostet die einzige Konfiguration, die Audit-Resistenz und Vertrags-Souveränität gleichzeitig erfüllt. Mixed-Strategy mit API-Frontier-Modellen für nicht-vertrauliche Aufgaben bleibt zulässig — solange der Routing-Layer pro Workload-Klasse trennscharf entscheidet und Logs nicht ungewollt in Closed-API-Kontexte fließen.

Daten

DSGVO-EU-AI-Act-CLOUD-Act-Trilemma, technische Mitigationen, Audit-Trail-Design

Drei Rechtsrahmen kollidieren in produktiven Architekturen: DSGVO-Artikel-28-Auftragsverarbeitung mit EU-only-Subprocessor-Klausel; EU-AI-Act-Artikel-10-Datenqualitäts-Nachweis; CLOUD Act und FISA 702 als extraterritoriale US-Zugriffsregime. Schrems II hat klargestellt, dass Standardvertragsklauseln allein nicht reichen — supplementary measures sind Pflicht. Praktische Mitigationen: Confidential Computing (Intel TDX, AMD SEV-SNP) für Inferenz-Isolation; HSM-gestützte Bring-Your-Own-Key-Verfahren mit EU-Hardware-Anker; deterministisches Logging in EU-only Sinks; Pseudonymisierung mit revertierbarem Mapping unter EU-Schlüsselhoheit. Für höchste Schutzstufen: Air-gapped Inferenz-Cluster mit definierter Daten-Diode.

Betrieb

Stack-Architektur, Vertrags-Topologie, Resilienz unter politischer Eskalation

Souveräne Inferenz-Stacks lassen sich nach Schutzbedarf staffeln. Stufe 1 — vertraglich souverän: EU-Anbieter mit EU-Tochter und US-Hyperscaler-Backend (z. B. T-Systems Open Telekom Cloud auf VMware/Azure). Akzeptabel für unkritische Workloads, fällt unter CLOUD-Act-Risiko. Stufe 2 — operativ souverän: vollständig EU-eigene Infrastruktur (OVHcloud, Hetzner, Scaleway, Stackit, IONOS) ohne US-Subprocessoren. Stufe 3 — physisch souverän: eigene Co-Location oder On-Premise mit eigenem Netzwerk-Edge. Bewertungs-Vektor: Recovery-Time bei Anbieter-Ausfall, Migrations-Aufwand zwischen den Stufen, Audit-Kosten pro Stufe. Realistisches Zielbild ist Stufe 2 für Produktion plus Stufe 3 für Kronjuwelen — Stufe 1 nur für isolierbare Workloads mit dokumentiertem Schutzbedarf.

Governance

Audit-Architektur, Exit-Strategie, AI-Act-Hochrisiko-Pflichten in der Praxis

Audit-Architektur ist die Disziplin, die den Stack vor Ort prüfbar macht: vollständige Inferenz-Logs mit Modell-Versions-ID, deterministische Replay-Fähigkeit, Daten-Lineage von Quelle bis Inferenz, Modell-Karten nach Vorgabe von Annex IV des EU AI Act. Exit-Strategie ist die Disziplin, die den Wechsel kalkulierbar hält: standardisierte Prompt- und Fine-Tune-Formate, portable Vektor-Daten (pgvector, Qdrant), abstrahierte Inferenz-API (OpenAI-kompatibel als Lingua franca). Für Hochrisiko-Anwendungen (Annex III) ist die Konformitätsbewertung nach Artikel 43 verpflichtend, inklusive Konformitäts-Erklärung und CE-Kennzeichnung. Realistisch erreichbar ist das nur, wenn Audit-Rechte gegen Modell-Anbieter vertraglich verankert sind — was Closed-Source-API-Anbieter nicht standardmäßig gewähren.

Spektrum der KI-Souveränität

Von vollständiger Abhängigkeit zu vollständiger Kontrolle – wo steht Ihre Organisation?

← Hohe AbhängigkeitHohe Souveränität →
Level 1
1

Volle Abhängigkeit

Proof of ConceptsNicht-kritische AppsSchnelle Experimente
OpenAI ChatGPT API
Google Gemini API
AWS Bedrock APIs
Anthropic Claude API
Keine Datenkontrolle
Kein Modell-Eigentum
Externe Infrastruktur
Vendor Lock-in
Level 2
2

Hybride Kontrolle

Regulierte BranchenMittelständische UnternehmenCompliance-Anforderungen
Azure AI on VMs
AWS SageMaker
Google Vertex AI
Lokales Modell-Hosting
Teilweise Datenkontrolle
Begrenzte Anpassbarkeit
On-Premises-Option
Anbieterabhängigkeit
Level 3
3

Verwaltete Souveränität

BehördenFinanzdienstleistungenKritische Infrastruktur
Oracle Cloud@Customer
Microsoft Cloud for Sovereignty
OVHcloud KI-Dienste
Regionale Cloud-Anbieter
Datensouveränität
Lokale Jurisdiktion
Compliance-zertifiziert
Geteilte Infrastruktur
Level 4
4

Vollständige Souveränität

Verteidigung & GeheimdiensteGroßkonzerneStrategische KI-Fähigkeiten
On-Premises-Infrastruktur
Open-Source-Modelle (Llama etc.)
Eigene Trainingspipelines
Selbstverwaltete Infrastruktur
Vollständige Kontrolle
Keine Abhängigkeiten
Alles anpassbar
Hohe Komplexität
Der passende Level hängt von Ihrer Risikotoleranz und den strategischen Anforderungen ab. Die meisten Unternehmen benötigen Level 2–3. Kritische Anwendungen erfordern möglicherweise Level 4.

Praxisbeispiele für politik

Antrags-Vorprüfung im Bürgeramt

KontextEine kommunale Verwaltung erschließt eingehende Anträge (Wohngeld, BAföG, Sozialleistungen) für eine Vorprüfung — Vollständigkeit, formale Eignung, Plausibilität.

SouveränModell und Daten verlassen die Behörden-Infrastruktur nicht, Entscheidungen sind erklärbar, eine zuständige Person bleibt vollständig verantwortlich.

BeispielEin selbst gehostetes Open-Weight-LLM (Teuken-7B, Llama-3-Derivat) auf der Souveränen Cloud des Landes-Rechenzentrums, gekoppelt an die Fachverfahrens-Schnittstelle — keine externe API, keine US-Subprocessor.

Recherche und Wissensbasis in Ministerien

KontextMinisterial-Referenten brauchen schnellen Zugriff auf Gesetzestexte, Drucksachen, eigene Stellungnahmen und ressortinterne Auswertungen.

SouveränVertrauliche Verwaltungsvorgänge fließen nicht in Drittstaats-Modelle, Recherche-Logs bleiben in der Behörde, Modell-Versionen sind audit-fähig.

BeispielRAG-Architektur mit Open-Source-Embedding auf einem geschlossenen Vektorspeicher der eigenen IT, LLM-Inferenz auf souveräner GPU-Infrastruktur, kein Trainings-Beitrag an externe Anbieter.

Compliance und Aufsicht in Aufsichtsbehörden

KontextEine Aufsichtsbehörde analysiert große Mengen von Marktbeobachtungen, Beschwerden und Prüfberichten und muss Entscheidungen aufsichtsrechtlich begründbar treffen.

SouveränModell-Wechsel jederzeit möglich, Inferenz-Logs vollständig auditierbar, Quellen für jede algorithmisch unterstützte Aussage rückverfolgbar.

BeispielModulare Pipeline mit dokumentiertem Open-Weight-Modell, lokalem Re-Ranker und versionierter Daten-Lineage von Eingang bis Ausgabe.

Häufige Fragen

Wie wird ein Hochrisiko-KI-System im Behörden-Einsatz konform produktiv?
Pflichtenkatalog aus Artikel 9 bis 17 produktiv: Risikomanagement-System (Art. 9) als kontinuierlicher Prozess; Datenqualitäts-Nachweis nach Art. 10 inklusive Repräsentativität und Bias-Tests; technische Dokumentation nach Annex IV; Logging mit Replay-Fähigkeit (Art. 12); Transparenz für Betroffene (Art. 13); menschliche Aufsicht mit echter Eingriffsbefugnis (Art. 14); Robustheit und Cybersecurity (Art. 15). Konformitätsbewertung nach Annex VI, Konformitäts-Erklärung nach Art. 47, CE-Kennzeichnung nach Art. 48. Ein KI-Risk-Officer mit klarer Berichtslinie ist faktisch unverzichtbar.
Welche Schutzmaßnahmen rechtfertigen Drittstaats-Inferenz im Einzelfall (post-Schrems-II)?
Standardvertragsklauseln allein reichen nicht. Erforderlich sind Einzelfall-Bewertungen mit ergänzenden Maßnahmen: Pseudonymisierung mit revertierbarem Mapping unter EU-Schlüsselhoheit, Confidential Computing für Inferenz-Isolation, deterministisches Logging in EU-only Sinks, dokumentierte Datenfluss-Karten für die Aufsicht. Für personenbezogene Verwaltungsdaten ist diese Konstruktion in der Praxis kaum tragfähig — die Aufsichtsbehörde wird das Risiko regelmäßig als nicht ausreichend reduziert bewerten. Reine Verwaltungsoptimierungs-Workloads ohne Personenbezug sind der realistische Anwendungsbereich.
Wie integriert sich AI-Act-Konformität ins BSI-Grundschutz-Kompendium?
Beide Rahmen ergänzen sich. BSI-Grundschutz liefert Bausteine zu Cloud-Nutzung (CON.8), Webanwendungen (APP.3.1), und allgemeiner IT-Sicherheit. AI-Act-Pflichten zu Logging, Robustheit und Datenqualität lassen sich in das Sicherheitskonzept integrieren, gehen aber inhaltlich darüber hinaus. Der BSI-Baustein 'Künstliche Intelligenz' (CON.10, in Abstimmung) wird die Brücke schlagen. Praxis: Schutzbedarfs-Feststellung um eine AI-Risiko-Achse erweitern, dokumentieren als Annex zur Schutzbedarfsanalyse, Maßnahmen aus AI-Act-Anforderungen als zusätzliche Bausteine aufnehmen.
Welche Audit-Anforderungen kommen aus dem Vergaberecht zusätzlich zum AI Act?
Vergaberecht verlangt nachvollziehbare, objektive Eignungs- und Zuschlagskriterien sowie Wirtschaftlichkeit. Bei IT-Beschaffung greifen zusätzlich EVB-IT-Verträge mit Standardklauseln zu Datenschutz, Audit-Rechten und Subunternehmer-Transparenz. Souveränität als Beschaffungskriterium ist zulässig, wenn sie objektiv begründet ist — etwa über DSGVO-Anforderungen, Schrems II oder konkreten Schutzbedarf. Praxis: Souveränitäts-Klauseln explizit in Leistungsbeschreibung aufnehmen, Bewertungsmatrix mit Audit-Recht, Datenresidenz, Subprocessor-Transparenz und Vertragsgerichtsstand.
Wie föderiert ein Behörden-KI-Stack zwischen Bund, Land und Kommune?
Föderationsachse 1 — Daten: Daten verlassen die jeweilige Verwaltungsebene nicht, gemeinsame Inferenz nur auf vereinbarten Aggregaten oder über DEÜV-Strukturen. Achse 2 — Modelle: gemeinsame Modell-Registry mit signierten, versionierten Open-Weight-Modellen, lokal ausführbar in jeder Ebene. Achse 3 — Infrastruktur: föderale Cloud-Strategie (Souveräne Cloud Bund, Landes-Clouds, Kommunal-Rechenzentren) mit standardisierten Schnittstellen. Bedingung: gemeinsame Souveränitäts-Anforderungen, dokumentierte Schnittstellen, kein einheitlicher Single-Point-of-Failure.

Annex III des EU AI Act listet acht Bereiche von Hochrisiko-KI: Biometrie, kritische Infrastruktur, Bildung, Beschäftigung, wesentliche Dienstleistungen, Strafverfolgung, Migration und Justiz, demokratische Prozesse.
Quelle: EU AI Act, Annex III

BSI-C5 (Cloud Computing Compliance Criteria Catalogue) liefert ein zertifiziertes Prüfraster für Cloud-Sicherheit; produktiv mit zusätzlichen Souveränitäts-Klauseln zu kombinieren.
Quelle: BSI, C5-Kriterienkatalog 2025

Praxisleitfaden · 22 Seiten · PDF

Souveräne KI in der Praxis.

Eine Ausarbeitung für Entscheider: EU AI Act, CLOUD Act, Architektur-Optionen und Vertragsbausteine für die nächsten 18 Monate. Direkt im Postfach, ohne Sales-Anruf.

Ihre E-Mail-Adresse nutzen wir ausschließlich für die Zustellung des Praxisleitfadens und gelegentliche Updates zu souveräner KI. Abmeldung jederzeit per Link in jeder E-Mail. Mehr in unserer Datenschutzerklärung.