Die Frage wird meist falsch gestellt. „Öffentliche KI oder eigenes Modell?“ klingt nach einer Grundsatzentscheidung – Cloud oder Souveränität, Bequemlichkeit oder Kontrolle. In der Praxis ist es keine Entweder-oder-Frage, sondern eine Zuordnungsfrage: Welche Aufgabe gehört auf welches Modell, und wer entscheidet das nach welcher Regel? Souveräne KI im Sinne von sector7 ist deshalb kein Cloud-Purismus. Sie ist die Disziplin, jedes Modell an den Ort zu setzen, an den es gehört.
Der Reflex, aus Datenschutzgründen pauschal alles lokal zu betreiben, ist genauso teuer wie der gegenteilige Reflex, aus Bequemlichkeit alles in die öffentliche Cloud zu geben. Beide verwechseln eine Architekturentscheidung mit einer Weltanschauung. Wer souverän arbeiten will, trifft die Entscheidung pro Aufgabe – und macht sie überprüfbar.
Planen in der öffentlichen Cloud, umsetzen lokal
Eine brauchbare Faustregel trennt nach dem, was mit den Daten passiert. Öffentliche Cloud-Modelle sind dort überlegen, wo es um Recherche, Entwürfe, Ideenfindung und breites Weltwissen geht – Aufgaben, bei denen keine schützenswerten Inhalte in den Prompt wandern. Nennen Sie es „Planen im Internet“: Sie lassen sich einen Vertragstyp erklären, eine Argumentationsstruktur skizzieren oder Optionen gegenüberstellen. Die Eingabe ist unkritisch, die Leistung der großen proprietären Modelle ist hier real.
Die Ausführung auf sensiblen Inhalten gehört an einen anderen Ort. Sobald ein Modell auf Ihre Verträge, Personaldaten, Konstruktionsunterlagen oder Kundenakten zugreift, ändert sich die Rechnung. Diese Inhalte sollen Ihr Haus nicht verlassen – hier arbeitet ein selbst gehostetes, offenes Modell auf eigener oder souverän betriebener Infrastruktur in Deutschland. „Umsetzen lokal“ heißt: Die eigentliche Arbeit am schützenswerten Datenbestand findet dort statt, wo Sie die Kontrolle über Speicherort, Zugriff und Recht behalten.
Warum das inzwischen praktisch trägt
Diese Aufteilung war vor zwei Jahren ein Kompromiss zulasten der Qualität. Das ist sie heute nur noch selten. Der Abstand zwischen offenen und proprietären Modellen hat sich auf vielen produktionsrelevanten Aufgaben – Coding, Wissensfragen, Zusammenfassungen – deutlich verringert. Offene Modelle wie DeepSeek V4, Qwen 3.5, Llama 4 oder Mistral Medium 3.5 erreichen auf gängigen Benchmarks Werte, die noch vor Kurzem der proprietären Spitze vorbehalten waren: DeepSeek V4 Pro etwa erzielt 80,6 auf SWE-Bench Verified und 90,1 auf GPQA Diamond bei einem Kontextfenster von einer Million Token.
Nüchtern bleibt festzuhalten, wo der Abstand fortbesteht: bei anspruchsvollem, mehrstufigem Reasoning, bei langen agentischen Arbeitsketten und bei der Verlässlichkeit in Randfällen führen die proprietären Spitzenmodelle weiterhin – der Vorsprung schrumpft, ist aber nicht verschwunden. Genau deshalb ist der Mix kein Notbehelf, sondern die sachlich richtige Antwort: Man nutzt die öffentliche Spitze dort, wo sie zählt, und das lokale Modell dort, wo die Datenlage es verlangt und die offene Qualität ausreicht.
Residenz ist nicht Souveränität
Ein verbreiteter Trugschluss verdient hier eine klare Einordnung, weil er teure Fehlentscheidungen verursacht. Ein Modell in einer AWS- oder Azure-Region Frankfurt zu betreiben, verschafft Ihnen Datenresidenz – die Daten liegen geografisch in Deutschland. Souveränität ist das nicht. Residenz beantwortet die Frage „Wo liegen die Daten?“, Souveränität die Frage „Wessen Recht greift darauf zu, und wer kann Herausgabe erzwingen?“.
Der Unterschied ist juristisch konkret. Der US CLOUD Act verpflichtet US-Unternehmen, Daten auf Anordnung US-amerikanischer Behörden herauszugeben – unabhängig davon, ob die Server in Frankfurt oder Virginia stehen. Ein US-Anbieter mit deutschem Rechenzentrum unterliegt beiden Rechtsordnungen. Der seit dem 12. September 2025 EU-weit anwendbare Data Act verlangt umgekehrt von Cloud-Anbietern technische Vorkehrungen gegen unrechtmäßigen Drittstaaten-Zugriff auf in der EU gespeicherte Daten. Die beiden Regelwerke stellen an denselben Anbieter gegenläufige Pflichten. Wer echte Souveränität braucht, kommt an einem Betreiber vorbei, der ausschließlich EU-Recht unterliegt – nicht bloß an einem Rechenzentrumsstandort. Für sensible Ausführung ist das der Grund, das lokale Modell auf europäisch verantworteter Infrastruktur zu betreiben.
Das Gateway macht die Modellwahl zur Entscheidung
Zwischen „öffentlich planen“ und „lokal umsetzen“ steht die eigentlich schwierige Aufgabe: die Steuerung. Ohne eine gemeinsame Kontrollstelle entscheidet in der Praxis der Zufall, welches Modell eine Anfrage bekommt – die Entwicklerin, die gerade den bequemsten API-Schlüssel zur Hand hat, oder das Werkzeug mit der vorkonfigurierten Voreinstellung. So wandern sensible Inhalte an das falsche Modell, nicht aus böser Absicht, sondern mangels Regel.
Ein reguliertes KI-Gateway löst das, indem es sämtlichen Modellverkehr über einen Zugang bündelt und nach festen Regeln lenkt. Die Kriterien sind benennbar:
- Sensitivität: Als vertraulich klassifizierte Inhalte gehen an das lokale Modell, unkritische Aufgaben an das leistungsfähigste passende öffentliche.
- Kosten und Token-Budget: Kurze Klassifikations- und Routineaufgaben laufen auf kleineren, günstigeren Modellen; komplexes Reasoning wird gezielt an ein starkes Modell geleitet. Öffentlich verfügbare Router-Verfahren zeigen, dass sich so ein erheblicher Teil der Kosten sparen lässt, ohne die Ergebnisqualität nennenswert zu senken.
- Nachvollziehbarkeit: Jede Anfrage wird protokolliert, wiederkehrende Anfragen werden zwischengespeichert, Budgets werden durchgesetzt. Die Regel wird einmal definiert und gilt für jede angebundene Anwendung.
Der entscheidende Effekt ist governance-, nicht technikgetrieben. Routing ist keine Konfigurationsschraube, sondern eine geregelte Fläche: Die Modellwahl wird zur dokumentierten Entscheidung statt zum Nebenprodukt. Und weil alle Anwendungen über denselben Zugang sprechen, wird der Wechsel eines Anbieters oder Modells zur Konfigurationsänderung – nicht zum Umbau jeder einzelnen Integration. Genau das ist der wirksamste Schutz vor Lock-in: nicht der Verzicht auf einen bestimmten Anbieter, sondern die Freiheit, ihn jederzeit auszutauschen.
Was daran echter Wert ist – und was Marketing
Zwei Punkte gehören auseinandersorgt. Souveräne KI wird gelegentlich als Verzicht auf Leistungsfähigkeit verkauft – „lokal, dafür bescheidener“. Das war einmal richtig und ist es kaum noch: Der offene Mittelbau reicht für einen großen Teil der Ausführung auf eigenen Daten aus. Umgekehrt wird „sovereign cloud“ oft als Etikett auf Angebote geklebt, die Residenz liefern, aber nicht Souveränität. Beide Vereinfachungen führen in die Irre.
Der belastbare Kern ist unspektakulär: Ordnen Sie Ihre Aufgaben nach Sensitivität, wählen Sie pro Klasse das passende Modell, und setzen Sie eine Kontrollstelle davor, die diese Zuordnung durchsetzt und protokolliert. Das ist weniger eine KI-Frage als eine Frage sauberer Architektur und gelebter Governance – dieselbe Disziplin, mit der man auch Netzwerke segmentiert und Zugriffe kontrolliert.
Wie sector7 unterstützt
Wir bauen genau diese Aufteilung als betriebenen Aufbau, nicht als Foliensatz. Unser Angebot Souveräne KI beginnt mit Governance – Use-Case- und Risikobewertung nach EU AI Act, Datenhygiene, Anschluss an vorhandene ISO-27001- und NIS-2-Strukturen – und führt zum abgesicherten Betrieb: gesicherte private Sprachmodelle und Managed RAG auf Ihren Dokumenten, betrieben auf selbst gehosteten offenen Modellen in unserem eigenen Serverpark in Deutschland. Die Steuerung dazwischen richten wir als Gateway mit regelbasiertem Routing ein: sensible Inhalte lokal, unkritische an das passende öffentliche Modell – mit Kosten-, Token- und Protokolltransparenz.
Bewusst nicht dazu gehört das Training eigener Basismodelle; wir setzen auf bewährte offene und öffentliche Modelle und bringen sie sicher zum Einsatz. Für sehr große Rechenkapazität binden wir souveräne Partner ein. Den laufenden Betrieb übernehmen wir auf Wunsch aus unserem Rechenzentrum – verbindliche SLA-Modelle dafür bauen wir gerade auf und stimmen Umfang und Zusagen im Einzelfall konkret mit Ihnen ab. Am Anfang steht dabei kein Modell, sondern ein Gespräch: Wir sortieren Ihre Vorhaben ergebnisoffen und setzen um, was Nutzen bringt.
Dieser Beitrag ist eine fachliche Einordnung und ersetzt keine Rechtsberatung im Einzelfall.
Quellen
- https://www.jamesm.blog/ai/state-of-open-weight-models-2026/
- https://whatllm.org/blog/open-source-vs-proprietary-llms-2025
- https://www.vellum.ai/open-llm-leaderboard
- https://blogs.vmware.com/cloud-foundation/2025/11/18/the-great-cloud-charade-why-data-residency-isnt-data-sovereignty/
- https://particula.tech/blog/eu-ai-act-data-sovereignty-residency
- https://beyondscale.tech/blog/ai-data-residency-sovereignty-gdpr-cloud-act
- https://www.digitalapplied.com/blog/llm-model-routing-2026-cost-quality-optimization-engineering-guide
- https://neuraltrust.ai/blog/llm-model-routing