AI-Souveränität: Warum die Modellwahl eine Architekturentscheidung ist
Ein Modell mit Inferenz außerhalb der EU, eins mit EU-Inferenz, ein selbst gehostetes, ein lokales: In vielen Unternehmen fällt die Entscheidung über AI-Souveränität einmal und soll dann gelten. Im Alltag ist sie eine Routing-Frage, die pro Anwendungsfall anders ausgeht. Dieser Artikel zeigt, welche AI-Klassen du unterscheiden musst und wie ein Gateway dafür sorgt, dass die Regel im Projekt tatsächlich ankommt.
Das Wichtigste in Kürze
KI-Souveränität ist im Alltag keine einmalige Anbieterentscheidung, sondern eine laufende Routing-Frage: Welche Information darf in welches KI-System?
Vier AI-Klassen strukturieren die Wahl: lokale AI (läuft vollständig auf dem Gerät), interne AI (selbst betrieben, von Dritten isoliert), externe AI mit EU-Inferenz und externe AI mit Non-EU-Inferenz (z. B. USA).
Drei Datenklassen – öffentlich, vertraulich, geheim – legen fest, welche der vier AI-Klassen jeweils erlaubt sind.
Ein AI-Gateway wie LiteLLM setzt diese Regeln technisch durch: Es erkennt am virtuellen API-Schlüssel einer Person das Projekt und schaltet nur die dafür erlaubten Modelle frei.
Ein Anbietervertrag beantwortet die falsche Frage
Die typische Diskussion im Lenkungskreis: US-Anbieter oder europäischer Anbieter, Managed Service oder Eigenbetrieb. Am Ende steht ein Vertrag und ein Endpoint. Drei Monate später kommt die erste Ausnahme, weil ein Team etwas braucht, was das gewählte Modell nicht kann.
Du entscheidest laufend über Kombinationen: Welche Information geht in welches System. Ein Retro-Protokoll ist ein anderer Fall als der Quellcode eines Kundenprojekts, und der wieder ein anderer als eine Formulierungshilfe für ein Angebot. Ein einzelner Anbietervertrag fällt für alle drei gleich aus. Er gerät damit entweder zu streng, und die Teams weichen auf private Accounts aus, oder zu locker.
Souveränität heißt: Du kannst jederzeit entscheiden, wohin welche Daten gehen, und du kannst diese Entscheidung durchsetzen und belegen. Doch dafür benötigt es eine Architektur, die das ermöglicht.
Die vierte AI-Klasse, die in den meisten Richtlinien fehlt
Die meisten AI-Richtlinien unterscheiden drei Kategorien, und das ist ein brauchbarer Anfang.
Lokale AI läuft vollständig auf einem verwalteten Gerät, etwa über Ollama oder LM Studio. Nichts verlässt das System, solange Cloud-Sync und Telemetrie aus sind. Dafür sind lokale Modelle schwächer als die großen Cloud-Modelle, und damit fehleranfälliger und prüfintensiver. Und die Modelllizenz muss auch evaluiert werden: Forschungs- oder nicht-kommerzielle Lizenzen schließen den Einsatz in Kundenarbeit aus.
Interne AI ist ein selbst betriebenes, von Dritten isoliertes System. Bei der Eingabe ist hier viel möglich, weil die Verarbeitung in der eigenen Umgebung bleibt. Dafür trägst du Betrieb, Kapazität und Aktualisierung selbst.
Externe AI ist alles, was ein Drittanbieter betreibt. Diese Kategorie ist zunächst grob geschnitten. Zwischen einem Modell, dessen Inferenz nachweislich in einer EU-Region läuft, und einem Modell, dessen Anfragen außerhalb der EU verarbeitet werden, beispielsweise in den USA, liegt der gesamte Themenkomplex Drittlandtransfer. Beides trägt dasselbe Etikett und verlangt verschiedene Prüfungen.
Die brauchbare Einteilung hat deshalb vier Klassen:
lokale AI
interne AI
externe AI mit EU-Inferenz
externe AI mit Non-EU-Inferenz.
Drei Datenklassen, drei Regeln
Datenklasse Öffentlich: erlaubte AI-Klassen sind alle. Typische Inhalte: Website-Texte, Veröffentlichungen, allgemeine Recherche.
Datenklasse Vertraulich: erlaubte AI-Klassen sind EU-Inferenz, intern, lokal. Typische Inhalte: Kundendaten, Quellcode, Designs, laufende Projekte.
Datenklasse Geheim: erlaubte AI-Klassen sind intern oder lokal. Typische Inhalte: Prototypendaten, kritische Geschäftsgeheimnisse.
Öffentliche Inhalte gehören ins stärkste verfügbare Modell. Wer hier aus Gewohnheit lokal bleibt, verschenkt Qualität ohne Gegenwert. Bei vertraulichen Inhalten fällt die Non-EU-Inferenz weg, der Rest bleibt nutzbar. Und bei geheimen Inhalten verlässt nichts das Haus.
Exkurs: Memory-Funktionen
Ein Punkt, der in Richtlinien selten steht und im Alltag schnell Schaden anrichtet. Moderne AI-Werkzeuge merken sich Inhalte über die einzelne Session hinaus und ziehen sie später wieder heran, projektübergreifend und ohne dass jemand danach fragt. Genau das macht sie im Alltag angenehm.
Für die Regeln oben heißt das: Eine Information, die in einem Kundenprojekt zulässig war, kann Wochen später im Kontext eines anderen Kunden auftauchen.
Die Gegenmaßnahme ist einfach. Persistente, projektübergreifende Memory-Funktionen bleiben aus. Was das Werkzeug dauerhaft wissen soll, pflegst du von Hand und beschränkst es auf Arbeitsweisen, Formatvorgaben und Qualitätsansprüche ohne Kunden- oder Projektbezug. Kontext innerhalb einer Session oder eines Workspace darf bleiben, weil er das Projekt nicht verlässt.
Ein Gateway macht die Regeln durchsetzbar
Ein AI-Gateway ist die technische Stelle, an der aus einer Regel eine Durchsetzung wird. Das bekannteste Open-Source-Beispiel ist LiteLLM: eine OpenAI-kompatible Schnittstelle vor über 100 Anbietern, mit virtuellen Schlüsseln pro Team oder Projekt, Budgets und Rate Limits, Routing mit Fallbacks, Guardrails inklusive Maskierungen und zentralem Logging. Selbst hosten lässt es sich ebenfalls, und damit liegt die Kontrolle im eigenen Haus. Der Endpunkt, die Protokolle und die Entscheidung, welches Modell überhaupt erreichbar ist, bleiben in der eigenen Umgebung.
LiteLLM ist nicht die einzige Option. Portkey AI Gateway und Bifrost verfolgen denselben Ansatz mit Fokus auf Durchsatz und Guardrails, Kong AI Gateway und Envoy AI Gateway hängen die AI-Steuerung an ein API-Gateway, das viele Unternehmen ohnehin betreiben. Alle sind quelloffen und selbst hostbar. Die Auswahl ist damit weniger eine Feature- als eine Betriebsfrage: Wer schon ein Gateway im Haus hat, erweitert es eher, als ein zweites danebenzustellen.
Für die Klassen oben heißt das: Aus jeder Regel wird eine Route. Verlagert ein Anbieter seine Inferenzregion oder fällt eine vertragliche Grundlage weg, änderst du eine Zuordnung im Gateway statt die API-Schlüssel in vielen Projekten. Und das zentrale Logging gibt den Einblick, ob die Regeln greifen und welche Projekte welche Modelle nutzen. Es ist zugleich der Nachweis, den du in einem Audit brauchst und über verteilte API-Keys nicht bekommst.
Wie die Regel im Projekt ankommt
Ein Gateway allein routet noch nichts. Es braucht eine Verbindung zwischen dem Projekt, an dem jemand gerade arbeitet, und der Regel, die für dieses Projekt gilt.
Das Muster dafür: Jedes Projekt ist im Gateway ein eigenes Team. Am Team hängen die erlaubte Modellliste, das Budget und die Limits. Jede Person bekommt in diesem Team einen eigenen virtuellen Schlüssel. Dieser Schlüssel liegt im Projektordner/Repository oder ist, wo möglich, der Sandbox des Projekts zugeordnet. Er wird aber nicht im gesamten Team verteilt, sondern gilt pro Person für dieses Projekt. Hilfsmittel wie beispielsweise direnv helfen bei der automatischen Verwaltung.
Damit ergibt sich folgende Route: Das Werkzeug schickt die Anfrage mit dem Schlüssel ans Gateway, das Gateway erkennt daraus das Projekt, und aus dem Projekt folgt die Datenklasse und damit die erlaubte Modellmenge. Das Gateway schickt die Anfrage dann an das jeweilige Modell weiter. Somit muss niemand beim Arbeiten aus einer Liste wählen, in der auch die falschen Modelle stehen. Modelle, die in diesem Kontext nicht erlaubt sind, werden gar nicht erst angezeigt.
Die Datenklasse des Projekts bestimmt, was der Schlüssel freischaltet: A ist geheim und bleibt im Haus, B ist vertraulich und darf zusätzlich in die EU, C ist öffentlich und erreicht alle vier Klassen. D hat keinen Schlüssel und bekommt am Gateway einen Fehler statt einer stillen Ersatzroute.
Der entscheidende Teil daran ist serverseitig: Die Modell-Allowlist hängt am Schlüssel und wird im Gateway durchgesetzt. Wer mit dem Schlüssel eines vertraulichen Projekts arbeitet, erreicht die Non-EU-Modelle schlicht nicht.
Damit das umsetzbar wird, ist essentiell, dass es keinen globalen Fallback-Schlüssel gibt. Ohne Fallback bekommst du in einem Ordner ohne Projektbindung einen sofortigen und eindeutigen Fehler. Mit Fallback greift stillschweigend ein falscher Schlüssel: die Kosten landen in der falschen Abrechnung, die Regeln gelten nicht und es fällt dabei niemandem auf.
Was das kostet
Ein Gateway hat einen Preis und der gehört in dieselbe Entscheidung. Es ist ein zusätzlicher Dienst im kritischen Pfad. Fällt es aus, fällt AI im ganzen Unternehmen aus. Es braucht denselben Betriebsanspruch wie beispielsweise ein Identity-Provider, samt Monitoring, Bereitschaft und Redundanz.
Auf der Nutzerseite kostet es Einrichtung. Einmal pro Person eine globale Konfiguration mit dem Endpunkt des Gateways. Pro Projektordner eine kleine Datei, die das Environment lädt. Dazu die eigenen Schlüssel, den sich jede Person im Self-Service aus der Verwaltungsoberfläche holt, und ein Hilfsmittel, damit der Schlüssel auch korrekt greift. Überschaubar, aber nicht null, und der Aufwand fällt bei jedem neuen Projekt und bei jeder neuen Kollegin wieder an.
FAQ | Wiederkehrende Fragen rund um AI-Souveränität
KI-Souveränität bedeutet, jederzeit entscheiden zu können, wohin welche Daten gehen, und diese Entscheidung durchsetzen und belegen zu können. Das ist keine einmalige Anbieterwahl, sondern eine Architekturfrage, die pro Anwendungsfall neu entschieden wird, z. B. ob ein Retro-Protokoll, Quellcode oder eine Angebotsformulierung in dasselbe System darf.
Lokale AI läuft vollständig auf einem verwalteten Gerät, z. B. über Ollama oder LM Studio, und verlässt das System nicht. Interne AI ist selbst betrieben und von Dritten isoliert. Externe AI mit EU-Inferenz verarbeitet Anfragen nachweislich innerhalb der EU. Externe AI mit Non-EU-Inferenz verarbeitet Anfragen außerhalb der EU, z. B. in den USA, und unterliegt damit dem Themenkomplex Drittlandtransfer.
Ein AI-Gateway ist die technische Stelle, an der aus einer Datenschutz- oder Souveränitätsregel eine tatsächliche Durchsetzung wird. Es sitzt zwischen den Teams und den KI-Anbietern, vergibt virtuelle Schlüssel pro Projekt und schaltet darüber nur die für dieses Projekt erlaubten Modelle frei. Bekanntestes Open-Source-Beispiel ist LiteLLM.
Portkey AI Gateway und Bifrost verfolgen denselben Open-Source-Ansatz mit Fokus auf Durchsatz und Guardrails. Kong AI Gateway und Envoy AI Gateway hängen die KI-Steuerung stattdessen an ein API-Gateway, das viele Unternehmen ohnehin schon betreiben. Welche Option passt, ist eher eine Betriebs- als eine Feature-Frage.
Moderne KI-Werkzeuge merken sich Inhalte projektübergreifend und über die einzelne Session hinaus. Eine Information, die in einem Kundenprojekt zulässig war, kann dadurch Wochen später im Kontext eines anderen Kunden wieder auftauchen. Persistente, projektübergreifende Memory-Funktionen sollten deshalb ausgeschaltet bleiben; Kontext innerhalb einer einzelnen Session oder eines Workspace ist unkritisch, weil er das Projekt nicht verlässt.
Fazit: Souveränität ist ein Regelwerk mit einem Schalter
Wer AI-Souveränität als Anbieterfrage behandelt, bekommt eine Entscheidung, die beim nächsten Anbieterwechsel wieder offen ist. Drei Datenklassen, vier AI-Klassen und ein Gateway, das den Schlüssel eines Projekts in eine Route übersetzt. Die Modelle werden sich weiter ändern, die Rechtslage ebenfalls, und du änderst dann eine Zuordnung an zentraler Stelle statt Konfigurationen an vielen Stellen. Der Gewinn ist Handlungsfähigkeit. Du kannst die starken Modelle dort einsetzen, wo sie erlaubt sind, statt vorsichtshalber überall schwächere zu nehmen.
