Pexon Consulting | 9 Min. Lesezeit | 16.07.2026
TL;DR
Souveräne KI heißt: du hältst die Modell-Gewichte selbst und betreibst Open-Weight-Modelle wie Qwen oder Mistral auf DE-Infrastruktur, air-gap-fähig, ohne Vendor-Lock-in. Ein Cloud-LLM in einer EU-Region senkt nur den Datenabfluss, bindet dich aber weiter an Anbieter und Preis. Pexon (80 Mitarbeitende, Microsoft-Partner) baut die Open-Weight-Variante und senkt Inferenzkosten um bis zu 60 Prozent.
Das Problem: „On-Prem“ heißt nicht automatisch souverän
Der verbreitete Ansatz für „souveräne KI“ klingt bequem: Man nimmt ein starkes Cloud-LLM eines großen Anbieters und lässt es in einer EU-Region oder in einer dedizierten Instanz laufen. Die Prompts verlassen die EU nicht mehr, das Compliance-Team ist beruhigt, der Haken auf der Folie sitzt.
Nur ist das keine Souveränität. Es ist reduzierter Datenabfluss. Die eigentliche Kontrollfrage lautet nicht „wo läuft das Modell“, sondern „wer besitzt die Gewichte und wer entscheidet über deren Zukunft“. Und die Antwort bleibt bei diesem Ansatz: der Anbieter. Er kann das Modell abkündigen, die Preise anheben, die Nutzungsbedingungen ändern oder eine Version zurückziehen, auf die deine Prozesse kalibriert sind.
Wir sehen das in Ausschreibungen fast wöchentlich: „on-premise“ und „souverän“ werden synonym benutzt, obwohl sie verschiedene Dinge bezeichnen. Wer den Unterschied nicht sauber trennt, kauft ein Souveränitäts-Etikett auf einer Lock-in-Architektur. Wie sich die Hosting-Varianten technisch unterscheiden, haben wir im Architektur-Vergleich der drei Hosting-Varianten im Detail durchgerechnet.
Was Souveränität wirklich bedeutet
Souveränität ist keine Marketing-Kategorie, sondern eine Frage der Kontrollrechte. Drei davon zählen:
Erstens die Verfügungsgewalt über die Gewichte. Liegt die Modelldatei auf deinem Storage, kann sie dir niemand entziehen. Ein Open-Weight-Modell unter Apache-2.0-Lizenz darfst du herunterladen, weiterbetreiben und feintunen, auch wenn der ursprüngliche Anbieter morgen die Tür zumacht.
Zweitens die Betriebshoheit. Air-Gap ist der Lackmustest. Ein echtes souveränes Setup läuft ohne Internetverbindung, ohne Lizenz-Ping nach Hause, ohne Telemetrie. Das ist für Behörden, Verteidigung, kritische Infrastruktur und stark regulierte Industrien der Unterschied zwischen „einsetzbar“ und „nicht genehmigt“.
Drittens die Roadmap-Unabhängigkeit. Du entscheidest, wann du das Modell wechselst, nicht der Anbieter. Kein erzwungenes Deprecation, kein API-Bruch mitten im Projekt.
Unsere Position ist eindeutig: Wenn Datensouveränität das Ziel ist, ist der Open-Weight-Weg der einzige, der alle drei Kontrollrechte liefert. Alles andere ist ein Kompromiss, den man bewusst und benannt eingehen sollte, nicht als Souveränität verkaufen. Den größeren regulatorischen und strategischen Rahmen dazu haben wir im Themen-Hub zur Datensouveränität in der KI aufbereitet.
Open-Weight-Modelle 2026 im Überblick
Der oft gehörte Einwand „die offenen Modelle sind zu schwach“ ist 2026 überholt. Die Qualitätslücke zwischen den besten geschlossenen und den besten offenen Modellen ist für die meisten Unternehmens-Workloads (RAG, Extraktion, Klassifikation, Zusammenfassung, Coding) praktisch geschlossen.
Ein konkretes Beispiel mit Stand: Am 16. April 2026 wurde Qwen3.6-35B-A3B unter Apache-2.0-Lizenz auf Hugging Face veröffentlicht, ein Mixture-of-Experts-Modell mit 35 Milliarden Parametern, von denen pro Token nur rund 3 Milliarden aktiv sind. Es unterstützt nativ 262.144 Token Kontext. Der Charme des MoE-Prinzips: die Antwortqualität eines großen Modells bei Inferenzkosten, die näher an einem kleinen liegen. Dazu kommen die etablierten Familien von Mistral und Llama, die als Open-Weight-Basis seit Jahren produktionsbewährt sind.
Regulatorisch gibt der EU AI Act zusätzlich Druck in Richtung Kontrolle: Seit dem 2. August 2026 greifen die Durchsetzungsbefugnisse des AI Office für General-Purpose-AI-Modelle. Die schärferen Hochrisiko-Pflichten für eigenständige Annex-III-Systeme wurden per Digital-Omnibus zwar auf den 2. Dezember 2027 verschoben, die Transparenz- und Governance-Anforderungen bleiben aber live. Wer die Modell-Gewichte selbst hält, kann Nachweise, Logging und Datenherkunft lückenlos dokumentieren, statt sie beim Anbieter anfragen zu müssen.
Auf der Betriebsseite ist die Werkzeugkette reif. vLLM in Version v0.25.1 (Release 14. Juli 2026) ist der De-facto-Standard für hochperformantes Serving; das Projekt steht bei rund 86.400 GitHub-Stars (abgerufen am 16.07.2026). Ein produktiver Start sieht schlanker aus, als viele erwarten:
# Qwen3.6-35B lokal servieren, DSGVO-konform im eigenen Rechenzentrum
vllm serve Qwen/Qwen3.6-35B-A3B
--tensor-parallel-size 2
--max-model-len 32768
--quantization awqEin einzelner Befehl, kein API-Key, keine Daten verlassen das Haus. Das ist der technische Kern von Souveränität.
Was Cloud-LLM-on-prem NICHT löst
Sei fair zu dem Ansatz: Ein Cloud-LLM in einer EU-Region ist ein echter Fortschritt gegenüber der öffentlichen Consumer-API. Die Prompts bleiben geografisch in Europa, oft mit vertraglicher Zusage gegen Trainingsnutzung. Für viele Teams ist das ein sinnvoller erster Schritt, und wir empfehlen ihn dort, wo es nur um Datenlokation geht und nicht um Betriebshoheit.
Was er strukturell nicht löst:
Der Lock-in bleibt vollständig. Du bist an ein Modell gebunden, das du nicht besitzt, dessen Preis du nicht kontrollierst und dessen Lebensdauer eine fremde Produktentscheidung ist. Ein Air-Gap ist per Konstruktion unmöglich, weil selbst die dedizierte Instanz Lizenz- und Telemetrie-Verbindungen braucht. Und du bezahlst pro Token, dauerhaft, während bei eigener Hardware nach der Anschaffung die Grenzkosten pro Anfrage gegen null gehen.
Ein zweiter Punkt wird gern übersehen: die Modell-Stabilität über die Zeit. Wenn der Anbieter eine neue Version ausrollt und die alte abkündigt, ändert sich das Antwortverhalten, oft subtil. Für regulierte Prozesse mit Freigabepflicht ist das ein echtes Problem, weil die Validierung von vorn beginnt. Bei eigenen Gewichten frierst du eine Version einfach ein und aktualisierst dann, wenn es dir passt.
Unsere Empfehlung an dieser Stelle: Nutze den EU-Region-Ansatz als Übergang, nicht als Ziel. Wer weiß, dass am Ende Air-Gap oder echte Preis-Kontrolle gefordert sind, sollte die Architektur von Beginn an offen auslegen, sonst zahlt er die Migration zweimal.
Kosten und Betrieb: die ehrliche Rechnung
Der ehrliche Teil, den viele weglassen: Souveränität ist nicht kostenlos, sie verschiebt nur die Kostenstruktur. Statt variabler Token-Kosten hast du fixe Infrastruktur- und Betriebskosten. Ab einem gewissen Nutzungsvolumen kippt die Rechnung klar zugunsten Open-Weight, darunter kann die Cloud-Variante günstiger sein.
Aus unseren On-Prem-Projekten ergeben sich grob diese monatlichen Größenordnungen für Hardware plus Betrieb (TCO-Bandbreite, ohne einmalige Anschaffung bei Kauf):
Die Faustregel aus der Praxis: Der Break-even gegenüber einer Cloud-API liegt bei intensiver Nutzung häufig im niedrigen sechsstelligen Anfragevolumen pro Monat. Bei einem unserer Fertigungskunden lag die Ersparnis nach Umstellung auf ein quantisiertes Open-Weight-Modell bei rund 60 Prozent der vorherigen Inferenzkosten, bei gleicher Antwortqualität für den konkreten RAG-Anwendungsfall.
Wichtig: Der GPU-Preis ist nicht der Kostentreiber, den man unterschätzt. Der Betrieb ist es. Monitoring, Quantisierung, Modell-Updates, GPU-Auslastung, Hochverfügbarkeit und der DSGVO-Nachweis machen aus einem laufenden Prototyp erst ein produktives System. Wer nur die Hardware budgetiert und den Betrieb vergisst, rechnet sich das Setup schön.
Häufig gestellte Fragen
Was kostet ein souveränes Open-Weight-LLM im Betrieb pro Monat?
Je nach Modellgröße und Verfügbarkeitsanspruch zwischen rund 1.500 Euro für ein Abteilungs-Setup mit einer einzelnen GPU und 20.000 bis 31.000 Euro monatlich für ein hochverfügbares, air-gapped Konzern-Cluster. Der Betrieb (Monitoring, Updates, HA) ist dabei der größere Posten, nicht die reine Hardware.
Was ist der Unterschied zwischen Open-Weight souverän und einem Cloud-LLM in einer EU-Region?
Bei Open-Weight liegen die Modell-Gewichte bei dir, du kannst air-gapped betreiben und bist an keinen Anbieter gebunden. Ein Cloud-LLM in einer EU-Region hält die Daten geografisch in Europa, lässt dich aber am Anbieter, an dessen Preis und an dessen Modell-Roadmap hängen. Ersteres ist Kontrolle, Letzteres reduzierter Datenabfluss.
Sind offene Modelle 2026 gut genug für den Produktivbetrieb?
Für RAG, Extraktion, Klassifikation, Zusammenfassung und Coding: ja. Modelle wie Qwen3.6-35B-A3B (Apache 2.0, April 2026) oder die Mistral- und Llama-Familien erreichen für Unternehmens-Workloads Qualität auf Augenhöhe mit geschlossenen Modellen. Die verbleibende Lücke betrifft primär exotische Reasoning-Spitzen, nicht den Standard-Geschäftsbetrieb.
Brauche ich eigene Hardware oder geht das auch in der Cloud?
Beides. Souveränität hängt nicht am Blech, sondern an der Kontrolle über die Gewichte. Du kannst Open-Weight-Modelle auch bei einem DE- oder EU-Hoster auf gemieteten GPUs betreiben und behältst trotzdem volle Modellhoheit. Air-Gap erfordert allerdings dedizierte oder eigene Infrastruktur ohne Internetanbindung.
Wie schnell lässt sich so ein Setup produktiv stellen?
Ein funktionierender Prototyp mit vLLM steht in Tagen. Der Weg zum Produktivbetrieb (Sizing, Quantisierung, SSO, Audit-Logging, HA, DSGVO-Nachweis) dauert in unseren Projekten typischerweise vier bis acht Wochen, abhängig von Verfügbarkeitsanspruch und Integrationstiefe.
Nächster Schritt
Verwandte Themen
