Souveräne KI · Expertenblick

Souveräne KI — Vertiefung

Architektur, Compliance und operative Realität in einem Bild — und vier Branchen-Vertiefungen, die in die Tiefe gehen.

Auf Experten-Ebene sind Begriffe Bewertungs-Achsen, nicht Erklärungs-Hilfen. Die Frage ist, wie ein Stack unter Last, Audit und Eskalation steht — und wo die Vertrauenswurzel sitzt, wenn der Vertragspartner ausfällt.

Drei Bewertungs-Dimensionen, die in jeder Konstellation tragen müssen

Erste Dimension — Vertrauenswurzel. Vertragliche Souveränität (EU-Anbieter mit US-Mutter) reicht für viele Workloads nicht. Operative Souveränität (vollständig EU-eigene Infrastruktur ohne US-Subprocessor) trägt produktive Hochrisiko-Anwendungen. Physische Souveränität (eigene Co-Location oder On-Premise mit eigenem Hypervisor) ist der Stand für Kronjuwelen — Audit-Resistenz und Vertrags-Souveränität gleichzeitig. Confidential Computing (Intel TDX, AMD SEV-SNP) verschiebt die Wurzel von Vertragskette in Hardware-Attestation; produktiv reif für CPU-Inferenz, GPU-CC noch in Reifeprozess.

Zweite Dimension — Audit-Architektur. Annex IV des EU AI Act und die DSGVO-Rechenschaftspflicht verlangen eine Pipeline, die ihre eigene Geschichte erzählen kann. Vollständige Inferenz-Logs mit Modell-Versions-ID, Eingabe-Hash, Sampling-Parametern und Ausgabe-Hash; Replay-Fähigkeit über Modell-Snapshots in einer Registry; Daten-Lineage von Source bis Inferenz; Manipulations-Sicherheit über append-only Sinks mit kryptografischem Anchoring. Ohne diese Bausteine scheitert Konformitätsbewertung nach Artikel 43 nicht erst beim Audit, sondern bereits in der Vorbereitung.

Dritte Dimension — Resilienz unter Eskalation. Modell-Portabilität (offene Gewichte, OpenAI-kompatible Inferenz-API als Standard, austauschbare Backends), Daten-Portabilität (offene Vektor-Formate, dokumentierte Schema-Migration), Vertrags-Portabilität (Multi-Provider-Setup mit dokumentierter Migrations-Reihenfolge). Im Eskalations-Fall — Sanktions-bedingter API-Ausfall, politisch erzwungener Anbieterwechsel, plötzliche Lizenz-Änderung — entscheiden diese Achsen zwischen 'innerhalb von Tagen umgezogen' und 'Quartalsprojekt'. Tabletop-Übungen für solche Szenarien gehören zur Vorbereitung, nicht zur Reaktion.

Die vier Branchen-Vertiefungen darunter gehen in den jeweiligen Compliance-Pflichtenkatalog im Detail. Annex-VI-Konformitätsbewertung im Unternehmen-Pfad; AI-Act-plus-BSI-Grundschutz-Integration im Verwaltungs-Pfad; technische Implementierung mit Confidential Inference und Annex-IV-Pflichtenkatalog bei Tech; deterministische Reproduzierbarkeit, föderiertes Lernen und Forschungsprivileg in der Forschung.

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.

Häufige Fragen

Welche technischen Schutzmaßnahmen halten unter Schrems-II-Logik?
Standardvertragsklauseln allein reichen nicht. Tragend sind: Pseudonymisierung mit revertierbarem Mapping unter EU-Schlüsselhoheit; Confidential Computing für Inferenz-Isolation (Intel TDX, AMD SEV-SNP, NVIDIA H100 mit CC-On für GPU-Workloads); HSM-gestützte Bring-Your-Own-Key-Verfahren mit EU-Hardware-Anker; deterministisches Logging in EU-only Sinks. Für höchste Schutzstufen: air-gapped Inferenz-Cluster mit definierter Daten-Diode. Aufsichtsrechtlich werden diese Maßnahmen pro Anwendung einzeln bewertet — kein einheitlicher Pauschalschutz.
Wie wird AI-Act-Annex-IV-Konformität operativ implementiert?
Annex IV verlangt unter anderem: Modellbeschreibung mit Trainings-Methodik, Datenqualitäts-Belege nach Artikel 10, Performance-Metriken nach Aufgabenklasse, Risiko-Mitigationen nach Artikel 9, menschliche-Aufsicht-Mechanismen nach Artikel 14, Cybersecurity-Maßnahmen nach Artikel 15. Implementierungs-Bausteine: Model Cards (Mitchell et al. 2019), Datasheets für Datasets (Gebru et al.), kontinuierliche Eval-Reports mit Goldstandard-Coverage, Threat-Modeling pro Anwendungs-Kontext. Tooling: Hugging Face Model Cards Toolkit, MLflow mit AI-Act-Erweiterung, Eigenbau auf OpenTelemetry.
Welche Audit-Architektur trägt aufsichtsrechtliche Prüfungen?
Drei Anforderungen: Vollständigkeit (jeder Inferenz-Aufruf mit Eingabe-Hash, Modell-Versions-ID, Parameter-Fingerprint, Ausgabe-Hash); Replay-Fähigkeit (deterministische Reproduktion aus Input und Modell-State, fixed Seeds bei stochastischen Modellen); Manipulations-Sicherheit (append-only Log-Sinks, kryptografisches Anchoring über Hash-Chains). Strukturiertes Logging via OpenTelemetry, Sink in EU-only Object-Storage mit Object-Lock, periodische Hash-Verifikation. Daten-Lineage parallel — sonst scheitert Artikel-10-Konformität bei Re-Trainings.
Wie wird ein Multi-Tier-Stack zwischen Schutzbedarf-Klassen aufgesetzt?
Pro Workload-Klasse ist die zulässige Stack-Stufe vertraglich und technisch fixiert. Routing-Layer (LiteLLM oder Eigenbau) prüft Workload-Klassifizierung und routet zu zugelassenem Backend; Sicherheits-Constraint: keine Cross-Klassen-Leaks, vertrauliche Inputs landen niemals in unzulässigen Backends. Logging dokumentiert jeden Routing-Entscheid mit Klasse, Backend, Begründung. Routing-Konfiguration als versionierter Code unter Audit. Stufe 1 (vertraglich souverän) für isolierbare Workloads, Stufe 2 (operativ souverän) für Produktion, Stufe 3 (physisch souverän) für Kronjuwelen.
Welche Resilienz-Strategien tragen politische Eskalationen?
Drei Achsen, alle parallel zu pflegen: Modell-Portabilität mit OpenAI-kompatibler Inferenz-API als Schnittstellen-Standard und austauschbaren Backends (vLLM, SGLang, TGI, llama.cpp je nach Workload); Daten-Portabilität mit offenen Vektor-Formaten (pgvector, Qdrant), standardisierten Embeddings-Modellen, dokumentierter Schema-Migration; Vertrags-Portabilität mit Multi-Provider-Setup und dokumentierter Migrations-Reihenfolge zwischen Stack-Stufen. Tabletop-Übungen für Eskalations-Szenarien — Sanktions-bedingter API-Ausfall, plötzlicher Lizenzwechsel, politisch erzwungener Anbieterwechsel — gehören zur Vorbereitung.

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.