Souveräne KI – welche Stufe für welche Daten

Kaum ein Begriff fällt in deutschen KI-Diskussionen so oft wie Souveränität. Und kaum einer wird so unterschiedlich gemeint. Die einen wollen, dass keine Daten abfließen. Die anderen wollen, dass die Verarbeitung in Europa stattfindet. Die dritten wollen unabhängig von einzelnen Anbietern sein. Das sind drei verschiedene Ansprüche, und sie verlangen drei verschiedene Dinge.

Denn mit der Trennung ist die Entscheidung noch nicht getroffen. Wer weiß, dass er mehr braucht als einen Vertrag, steht vor der nächsten Frage: wie viel mehr? Zwischen der Consumer-App eines US-Anbieters und einem Modell, das offline auf eigener Hardware läuft, liegen mehrere Stufen. Jede kostet etwas anderes, jede löst etwas anderes. Diese Lesson behandelt Souveränität deshalb als das, was sie in der Praxis ist: eine gestufte Infrastruktur-Entscheidung pro Datenklasse.

Warum ein Verbot keine Antwort ist

Die häufigste Abkürzung lautet: „KI ist bei uns verboten, bis das geklärt ist.“ Das klingt nach Kontrolle, erzeugt aber das Gegenteil. Mitarbeitende nutzen KI dann privat, auf eigenen Konten, ohne Schutzmaßnahmen, ohne Audit-Trail. Das Risiko verschwindet nicht, es wird unsichtbar. Die belastbare Alternative ist, Stufen zu definieren: welche Daten in welche Art von System dürfen, unter welchen Bedingungen. Genau dieses Stufenmodell baust du in den nächsten fünf Schritten.

Der Weg durch diese Lesson

Was du nach dieser Lesson kannst

• Die sechs Souveränitätsstufen benennen und deine heutigen Werkzeuge darin einordnen
• Aus einer Datenklasse die Mindeststufe ableiten, statt aus dem Bauchgefühl
• Die sechs Betriebsformen mit ihrer jeweiligen Betriebsverantwortung vergleichen
• Die vier Risikoklassen trennen und erklären, welche davon Self-Hosting löst
• Einen konkreten Use Case in vier Fragen zu einer begründeten Stufe führen

Souveränität ist kein Schalter mit zwei Positionen. Zwischen „alles läuft beim Anbieter“ und „nichts verlässt das Haus“ liegen sechs Stufen, die sich in drei Dingen unterscheiden: wer die Daten sieht, unter welchem Recht sie liegen und wer den Betrieb verantwortet. Die Nummerierung läuft von S6 nach S1, von der offensten zur souveränsten Stufe.

Beim Abstieg von S6 nach S1 ändern sich vier Eigenschaften, und sie ändern sich nicht gleichzeitig. Ob Eingaben ins Training fließen, regelt schon der Sprung von S6 auf S5, ein Vertrag genügt. Ob ein Auftragsverarbeitungsvertrag existiert, ebenso. Ob eine fremde Regierung Zugriff verlangen kann, ändert sich erst bei S3, denn das hängt an der Jurisdiktion des Anbieters, nicht am Standort des Rechenzentrums. Und ob überhaupt ein Dritter beteiligt ist, ändert sich erst bei S2 und S1. Wer eine Stufe fordert, sollte sagen können, welche dieser vier Eigenschaften er braucht.

In der Praxis wird die Stufe oft nach Vorliebe gewählt: nach dem Werkzeug, das schon da ist, oder nach dem Grundsatz, der gerade im Raum steht. Die belastbare Reihenfolge ist umgekehrt. Erst die Daten klassifizieren, dann die Mindeststufe ablesen. Vier Klassen reichen für fast alle Fälle.

Die Merklogik dahinter: je sensibler die Daten, desto näher an S1. Wichtig ist, was diese Tabelle nicht sagt. Sie sagt nicht, dass ein Werkzeug gut oder schlecht ist. Problematisch ist nie das Werkzeug allein, sondern die Kombination aus Datenklasse und Stufe. Dieselbe Consumer-App, die für öffentliche Recherche völlig in Ordnung ist, ist für Kundendaten ein Verstoß.

Die Stufen aus Schritt 1 sind Ansprüche. Betriebsformen sind das, was du dafür tatsächlich betreiben musst. Und hier liegt der Punkt, der in Souveränitätsdiskussionen am häufigsten fehlt: jede Stufe nach unten kauft Kontrolle mit Betriebsverantwortung. Jemand muss Hardware beschaffen oder mieten, Modelle aktualisieren, Sicherheitslücken schließen, Ausfälle beheben und in zwei Jahren noch da sein.

Für On-Device-Betrieb genügen heute Werkzeuge wie Ollama oder LM Studio auf einem gut ausgestatteten Arbeitsrechner. Für einen Server, ob gemietet oder im Haus, braucht es ein Inference-Framework wie vLLM und jemanden, der es pflegt. Die Werkzeuge sind ausgereift und frei verfügbar. Was sie nicht mitliefern, ist die Person, die zuständig bleibt. Deshalb ist die ehrlichste Frage vor jedem Eigenbetrieb nicht „welches Tool“, sondern „wer betreibt das in zwölf Monaten noch“.

Warum Region nicht Jurisdiktion ist

Der häufigste Irrtum im Spektrum betrifft den Unterschied zwischen S4 und S3. Ein EU-Rechenzentrum eines US-Anbieters verlagert die Verarbeitung nach Europa. Es verlagert nicht das Recht. Der US CLOUD Act erlaubt US-Behörden, von US-Unternehmen Daten herauszuverlangen, unabhängig davon, wo sie physisch gespeichert sind. Das steht in Spannung zu Art. 48 DSGVO, der genau solche Herausgaben ohne Rechtshilfeabkommen untersagt. Kundenverwaltete Schlüssel und konfigurierbare Speicherfristen mindern dieses Restrisiko, sie beseitigen es nicht. Wer die Jurisdiktion wechseln will, wechselt den Anbieter, nicht das Rechenzentrum.

Die Querschnittsmaßnahme: das Gateway

Eine Maßnahme wirkt auf jeder Stufe: ein AI-Gateway, ein zentraler Kontrollpunkt, durch den der gesamte KI-Verkehr der Organisation läuft. Dort lassen sich personenbezogene Angaben vor dem Versand maskieren, Aufrufe protokollieren und Richtlinien durchsetzen. Vor allem macht ein Gateway das Modell dahinter austauschbar: Wer heute über eine solche Schicht arbeitet, kann morgen die Stufe wechseln, ohne jede Anwendung anzufassen. Offene, selbst betreibbare Gateways wie LiteLLM existieren; wie so eine Schicht in eine Anwendung passt, zeigt Der Stack hinter einer KI-App.

Wer die Betriebsformen kennt, landet früher oder später bei einem Satz, der in Entscheidungsvorlagen und Fachbeiträgen gleichermaßen auftaucht: „Wir betreiben das Modell selbst, damit verlassen unsere Daten nicht das Unternehmen, die Sicherheitsbedenken sind erledigt.“ Der Satz ist zu einem Viertel richtig. Er löst genau eine von vier Risikoklassen und übergeht die anderen drei.

Was Eigenbetrieb wirklich löst: den Datenabfluss

Läuft ein Modell auf eigener Hardware ohne Verbindung zum Anbieter, fließt nichts ab. Diese Risikoklasse ist mit Eigenbetrieb plus Netzwerk-Isolation vollständig adressiert, und zwar unabhängig davon, aus welchem Land das Modell stammt. Das ist der wahre Kern des Satzes, und er ist ein echter Gewinn.

Was in den Gewichten sitzt, bleibt in den Gewichten

Ein Modell ist kein Code, den man Zeile für Zeile lesen kann. Es ist ein Bündel aus Milliarden Parameterwerten. „Offene Gewichte“ heißt: Du hast diese Werte. Es heißt nicht: Du verstehst, was sie tun. Forschung hat 2024 demonstriert, dass sich Modelle gezielt so trainieren lassen, dass sie auf bestimmte Auslöser hin anders reagieren, etwa ab einem Datum fehlerhaften Code erzeugen, und dass dieses Verhalten Standard-Sicherheitstraining und normale Tests übersteht. Ob so etwas in einem konkreten Modell steckt, lässt sich mit heutigen Prüfmethoden nicht ausschließen. Eigenbetrieb ändert daran nichts: Ausgelöst wird solches Verhalten durch Eingaben, nicht durchs Netzwerk.

Dasselbe gilt für die dritte Klasse, den Output-Bias. Modelle tragen die Werte und Auslassungen ihrer Trainings- und Ausrichtungsphase in sich. Sichtbare Verweigerungen bei bekannten Reizthemen sind dabei das kleinere Problem, gerade weil sie sichtbar sind. Die relevantere Frage ist, was nicht sichtbar ist: Gewichtungen in Bewertungen, Empfehlungen und Quellenauswahl. Systemprompts können viel überschreiben, aber nicht alles. Und weil bei offenen Gewichten die Trainingsdaten fast nie offenliegen, gilt: Gewichte offen heißt nicht Trainingsdaten offen. Du kannst prüfen, dass das Modell läuft. Nicht, was hineintrainiert wurde.

Compliance, Herkunft und die geopolitische Frage

Die vierte Klasse löst Eigenbetrieb nur teilweise. Datenschutzanforderungen ja. Aber regulierte Branchen verlangen zunehmend eine nachvollziehbare Herkunft des Modells, und die hängt nicht am Hosting. Hierher gehört auch die geopolitische Frage, die in der Debatte oft alles überlagert: Manche Organisationen schließen Modelle aus bestimmten Jurisdiktionen grundsätzlich aus. Das ist eine legitime Risikoabwägung. Sie sollte nur als das dokumentiert werden, was sie ist: eine geopolitische Entscheidung, kein technisches Urteil. Beides zu vermischen macht beide Argumente schwächer.

Was sich absichern lässt

• Netzwerk: Ausgehenden Verkehr blockieren oder das System ganz isolieren. Löst Datenabfluss vollständig
• Prompting: Strikte Systemprompts mit klaren Grenzen. Mindert Bias teilweise
• Evaluation: Eigene Test-Suite mit den Themenfeldern, die für dich kritisch sind. Macht Bias sichtbar
• Output: Review-Pflicht für Code und folgenreiche Ausgaben, Mensch im Loop. Fängt Integritätsprobleme ab
• Architektur: Kritische Pfade nicht von einem einzigen Modell abhängig machen. Begrenzt den Schaden
• Governance: Herkunft dokumentieren, erlaubte Use Cases festschreiben. Adressiert Compliance

Eine vollständige Absicherung der Modell-Integrität gibt es derzeit nicht. Deshalb skaliert das Restrisiko mit der Verlässlichkeitserwartung an den Output: Eine Zusammenfassung, die ein Mensch ohnehin liest, verträgt es. Code, der ungeprüft in Produktion geht, oder ein Agent mit Werkzeugzugriff verträgt es nicht.

Jetzt liegt alles auf dem Tisch: das Spektrum, die Datenklassen, die Betriebsformen, das Threat Model. Der Entscheidungspfad bringt es in eine feste Reihenfolge. Fest deshalb, weil die häufigsten Fehlentscheidungen daraus entstehen, dass mit der letzten Frage angefangen wird: erst die Infrastruktur gewählt, dann eine Begründung gesucht.

1. Use Case klären. Was soll das System tun, und wie viel Verlass braucht der Output? Wird jede Ausgabe ohnehin von einem Menschen geprüft, oder wirkt sie direkt?
2. Datenklasse bestimmen. Welche Daten fließen hinein? Die Klasse liefert die Mindeststufe (Schritt 2). Prüfe zuerst, ob sich die Klasse senken lässt.
3. Threat Model prüfen. Welche der vier Risikoklassen sind für diesen Fall relevant, und welche Absicherungen sind verfügbar (Schritt 4)?
4. Betrieb klären. Wer betreibt die nötige Betriebsform dauerhaft, und trägt der Fall die Kosten (Schritt 3)?

Typische Fälle im Pfad

In der Summe ergibt sich fast immer dasselbe Bild: Der größte Teil der Alltagsaufgaben läuft sauber auf mittleren Stufen. Eigenbetrieb ist die begründete Ausnahme für die sensibelste Schicht, nicht der Standard. Daraus folgt die tragfähigste Architektur: eine hybride Aufteilung, bei der die sensibelsten Datenklassen auf S1 bis S2 laufen und der Rest über eine API-Stufe, während das Gateway aus Schritt 3 die Anfragen nach Datenklasse verteilt.

Dieselbe Logik begegnet dir eine Ebene höher wieder: KI-Agenten führen spannt sie als Build-vs-Buy-Spektrum über die Beschaffung ganzer Agenten-Systeme auf, vom No-Code-Werkzeug bis zum Eigenbau. Die Stufenlogik dieser Lesson ist das Fundament darunter.

Souveränität ist als Schlagwort gestartet und als Entscheidungsverfahren angekommen: sechs Stufen, vier Datenklassen, sechs Betriebsformen, vier Risikoklassen, vier Fragen in fester Reihenfolge. Hier sind die fünf Regeln im Überblick.

Der Pfad auf einen Blick

1. Was soll das System tun, und wie viel Verlass braucht der Output?
2. Welche Datenklasse fließt hinein, und lässt sie sich senken? Daraus folgt die Mindeststufe.
3. Welche Risikoklassen sind relevant, und welche Absicherung kannst du leisten?
4. Wer betreibt die Betriebsform dauerhaft, und trägt der Fall die Kosten?

Begriffe aus dieser Lesson

• Open Weights — Open Weights bedeutet, dass die trainierten Parameterwerte eines KI-Modells veröffentlicht sind und das Modell selbst betrieben werden kann. Es bedeutet nicht, dass Trainingsdaten offenliegen oder die Lizenz jede Nutzung erlaubt.
• Self-Hosting — Self-Hosting bedeutet, ein KI-Modell auf eigener oder gemieteter Infrastruktur zu betreiben, statt es über die API eines Anbieters zu nutzen. Es löst den Datenabfluss vollständig, aber nur diese eine von vier Risikoklassen.
• Vendor Lock-in — Vendor Lock-in bezeichnet die Abhängigkeit von einem Anbieter, dessen Wechsel hohe Kosten verursachen würde. Bei KI ist er auf der Tool-Ebene niedrig, auf der Infrastruktur-Ebene real, und die Antwort ist Wechselfähigkeit, nicht Verzicht.