Digitale Souveränität für KI-Teams

Das Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) hat einen Kriterienkatalog zur Konsultation gestellt. Bis zum 15. Mai 2026 können Behörden, Unternehmen und Zivilgesellschaft kommentieren. Für KI-Teams ist das mehr als ein Behördenthema, denn KI-Systeme leben von Daten, Modellen und Infrastruktur, die fast nie vollständig unter eigener Kontrolle stehen.

Was ZenDiS prüft

Der Kriterienkatalog auf souveränitätscheck.de gliedert sich in vier Bereiche:

• A Organisation und Fähigkeiten: Ist Souveränität strategisch verankert? Gibt es Zuständigkeiten, Schulung, Wissensmanagement?
• B Digitale Anwendungen und Dienste: Wie abhängig sind die eingesetzten Systeme von einzelnen Anbietern? Gibt es Alternativen?
• C Daten: Wer kontrolliert die Datenbestände? Wo werden sie verarbeitet und gespeichert?
• D Betrieb und Infrastruktur: Sind Hosting, Netzwerk und Rechenzentrum unter eigener oder europäischer Kontrolle?

Die Leitfrage lautet: Haben wir Wechselmöglichkeiten, Gestaltungsfähigkeit und Einflussnahme auf Anbieter? Typische Prüffragen sind "Gibt es getestete Exit-Strategien für kritische Systeme?" und "Ist die Herkunft der eingesetzten Komponenten nachvollziehbar?". Das klingt zunächst klassisch nach IT, aber in einem KI-Stack liest sich jede Frage anders.

Der KI-Stack durch die Souveränitätsbrille

Ein typischer KI-Produktionsstack 2026 besteht aus mehreren Schichten: Modellanbieter (Claude, GPT, Gemini, Mistral, Aleph Alpha), Hosting (Cloud-Anbieter, eigene Server), Vektordatenbanken, Orchestrierung (LangChain, n8n, eigene Pipelines), Beobachtung (Logging, Tracing). Jede Schicht ist ein Souveränitätsrisiko.

A Organisation: Wer weiß, wo welche Daten hingehen?

Die meisten Teams, mit denen wir sprechen, wissen gut, welchen Modellanbieter sie nutzen. Deutlich weniger Teams können genau beantworten, wo deren Anbieter die Daten verarbeiten, was die Datenschutzvereinbarung (DPA) konkret erlaubt und ob Subdienstleister im Spiel sind. Die ZenDiS-Frage "Ist der Überblick dokumentiert?" ist banal und oft unangenehm.

Konkret: Eine aktuelle Stack-Übersicht mit Datenflüssen und Verantwortlichkeiten pro Komponente. Das ist Grundlage für Artikel 30 DSGVO, aber auch für jede Souveränitätsprüfung.

B Anwendungen: Wie abhängig bin ich wirklich?

"Wir können ja jederzeit zu einem anderen Anbieter wechseln" ist eine häufige Antwort. In der Realität stimmt das oft nicht. Prompts sind modellspezifisch optimiert, Tool-Interfaces unterscheiden sich, Feintuning ist nicht portabel.

Prüffrage: Wie lange braucht das Team, um bei einem Ausfall des primären Modellanbieters produktiv weiterzuarbeiten? Wenn die Antwort "mehrere Wochen" lautet, gibt es keine funktionierende Exit-Strategie. Abstraktionsschichten wie LiteLLM, OpenRouter oder das SDK-Wrapping von Langchain helfen, reichen aber nicht aus, wenn Prompts nicht modellagnostisch sind.

C Daten: Was verlässt die Organisation?

Jede KI-Anfrage über eine API transportiert Daten außer Haus. Die Frage ist nicht nur "Ist das im DPA erlaubt?", sondern auch "Was passiert mit den Daten jenseits der DPA?". Training-Opt-Outs sind bei vielen Anbietern Default, bei anderen Opt-In. Logs bleiben beim Anbieter typischerweise 30 Tage, bei Enterprise-Verträgen kürzer.

Prüffrage: Gibt es Datenklassen, die das Haus nicht verlassen dürfen? Falls ja, sind sie technisch vor Weitergabe geschützt (DLP, Proxy, Policy-Engine), nicht nur vertraglich?

D Infrastruktur: Betriebsort und Lieferkette

Wo laufen Modelle tatsächlich? Amazon Bedrock in Frankfurt ist nicht dasselbe wie OpenAI direkt über api.openai.com. Hosting in der EU reicht nicht, wenn der CLOUD Act den US-Mutterkonzern zum Herausgeben zwingen kann. Lokal laufende Modelle auf Ollama, vLLM oder TGI sind eine Souveränitätsoption, aber mit eigenem Betriebsaufwand.

Prüffrage: Für welche Use Cases wäre ein lokales Open-Weight-Modell (Llama, Mistral, Aleph Alpha, Gemma) technisch ausreichend und organisatorisch machbar? Die Antwort "keine" ist meistens falsch.

Praktische Anwendung des Katalogs

So übertragen Teams die ZenDiS-Fragen auf den eigenen KI-Stack, ohne ein Compliance-Großprojekt daraus zu machen:

1. Inventarisierung: Liste aller KI-Komponenten (Modelle, APIs, Vektordatenbanken, Agenten-Frameworks) mit Anbieter, Betriebsort, Datenkategorien.
2. Abhängigkeitsprüfung: Pro Komponente eine Einschätzung zur Wechselbarkeit auf einer Skala (sofort austauschbar, mehrere Wochen Aufwand, grundlegende Umbauarbeiten nötig).
3. Datenklassen-Matrix: Welche Datenklassen (öffentlich, intern, vertraulich, personenbezogen, besonders schützenswert) werden in welcher Komponente verarbeitet? Wo bestehen Konflikte?
4. Exit-Pfade: Für jede kritische Komponente mindestens eine dokumentierte Alternative samt geschätztem Migrationsaufwand.

Das ergibt eine Souveränitätskarte des KI-Stacks. Sie ist nie vollständig grün, aber sie macht sichtbar, wo die blinden Flecken sind.

Warum das für Teams relevant ist, die nicht für Behörden arbeiten

Der ZenDiS-Katalog richtet sich an Verwaltungen, aber drei Trends machen ihn für Unternehmen genauso nützlich:

Beschaffungsdruck: Die Ausschreibungen des Bundes verlangen zunehmend Souveränitätsnachweise. Wer Dienstleister für öffentliche Auftraggeber ist, wird geprüft. Das zeigt sich jetzt schon bei Project Spark und der Aleph-Alpha-Cohere-Fusion.

Regulierung: EU AI Act, DORA für den Finanzsektor und die NIS-2-Richtlinie verlangen ohnehin Dokumentationen, die stark mit Souveränitätsfragen überlappen. Wer einmal den Katalog durcharbeitet, hat für diese Regulierungen Vorarbeit geleistet.

Geopolitik: Zollkonflikte, Exportkontrollen und die Anti-Distillation-Koalition zeigen, wie schnell sich Zugang zu KI-Modellen ändern kann. Ein Team, das seine Abhängigkeiten kennt, reagiert schneller.

Mitgestalten statt nur anwenden

Die Konsultation bei ZenDiS läuft bis zum 15. Mai 2026. Teams, die den Katalog in der Praxis prüfen und sinnvolles Feedback haben, können direkt auf der Plattform kommentieren. Das ist eine der seltenen Gelegenheiten, an einem Standard mitzuschreiben, bevor er in Ausschreibungen auftaucht.

Wer keine Zeit für formale Kommentare hat, kann zumindest den Katalog als Checkliste intern nutzen. Schon das strukturierte Durchgehen bringt oft zutage, was sonst unterm Radar läuft: der eine Datenexport, der niemandem bewusst war. Die Vertragsklausel, die keiner gelesen hat. Der Notfallplan, der nie getestet wurde.