Beherrschen statt besitzen — wo KI-Souveränität 2026 wirklich entsteht

Souveränität gehört nicht ins Strategiepapier. Sie gehört in den Stack.

KI-Souveränität entsteht 2026 nicht durch Besitz, sondern durch Beherrschung kritischer Stack-Schichten. Daten, Inferenz, Post-Training, Evaluation, Compliance/Audit und Betrieb sind die sechs Achsen, an denen sich entscheidet, wie souverän eine Organisation 2027 tatsächlich operiert. Der deutsche Reflex von 2024 — „Wir brauchen ein eigenes ChatGPT" — war Souveränität als Besitzfrage. Heute zählt eine reifere: Welche Schicht behalten wir, welche delegieren wir bewusst? Wer das nicht differenziert beantwortet, betreibt Strategiepapier-Souveränität.

Auf einen Blick

• Souveränität 2026 ist Beherrschungs-, nicht Besitzfrage: Welche Schicht des KI-Stacks ein Unternehmen kontrolliert, entscheidet, wie souverän es operativ tatsächlich ist.
• Sechs Stack-Schichten sind die Entscheidungsachsen: Daten/Residenz, Inferenz, Post-Training, Evaluation, Compliance/Audit, Betrieb. Jede lässt sich behalten, delegieren oder hybrid betreiben — aber nicht ignorieren.
• Die Boardroom-Dichotomie „proprietär = enterprise-ready, Open Source = Bastelprojekt" trägt 2026 nicht mehr. Open-Source-Software dominiert die Cloud — gerne verpackt als SaaS. Open-Weight-Stacks laufen produktiv in regulierten Branchen — bei korrekt sortierter Schichten-Architektur.
• Was Souveränität ausbremst, ist selten die Software oder das Modell: Procurement-Reflexe auf „Hersteller mit SLA", Skill-Lücken oder Outsourcing der Verantwortung, der hartnäckige Sicherheits-Mythos, der ungeklärte Tag-eins-Plan.

Open Source ist kein Geschäftsmodell — sondern eine Kontrollfrage

Yann Lechelle, Executive President & Chairman von probabl und ehemals CEO von Scaleway, hat den entscheidenden Satz formuliert:

„Open source is not a business model. It's a distribution, it's a community, it's a federation, it's a governance concept, it's a marketing asset."

In Entscheidungssprache: Sie kaufen keine kostenlose Software. Sie entscheiden, wo Kontrolle und Anpassbarkeit für Ihr Geschäft wesentlich sind — und wo ein externer Partner die Schicht günstiger und sauberer betreibt als Sie. Die Frage ist nicht „offen oder geschlossen?", sondern: Welche Schicht des Stacks behalten wir, welche delegieren wir bewusst?

Ines Montani (spaCy) hat den damit verbundenen Vorstandsmythos entkräftet:

„People use open source not because it's free, I think that's one of these misconceptions, but because it's flexible, it's extensible, you can program with it. Composable."

Unternehmen nutzen offene Stacks 2026 nicht aus Geiz, sondern weil sich nur damit die Kontrollschichten oben behalten lassen. Selbst die Kostenrechnung trägt das alte Bild nicht: Sind die Gesamtkosten für Schulung, Support und Anpassung proprietärer Software wirklich geringer als der Aufbau eigener Skills? Selten — und der Vergleich übersieht, was beim offenen Stack zusätzlich auf der Habenseite steht: Kontrolle über Daten, Inferenz, Eval und Roadmap.

Eine Konsequenz daraus: Open-Weight-Modelle auf Open-Source-Stack zu betreiben ist 2026 keine Ideologie, sondern Architektur-Logik. Wer Open-Weight wählt, dann aber proprietäre Orchestrierung darunterlegt, gibt einen Teil der gerade gewonnenen Kontrolle zurück — die Audit-Kette bricht dort, wo die Inspizierbarkeit aufhört.

Europa als Ökosystem ist oft unsichtbar: Tragende Entwickler kritischer Open-Source-Libraries sitzen in der EU. Drei OSS-Titanen, ohne die kein Enterprise-Stack auskommt — scikit-learn, spaCy, Jupyter — kommen direkt aus diesem Ökosystem: probabl trägt scikit-learn, das spaCy-Team sitzt in Berlin, QuantStack pflegt Jupyter. 2026 sind diese Akteure plus Mistral und viele andere auch als Service-Markt belastbar. Keine Ersatzlösung für US-Bigtech, sondern eine andere Infrastruktur-Architektur — die längst im Betrieb ist.

Sechs Schichten machen die Frage konkret.

Die sechs Stack-Schichten — behalten oder delegieren?

1. Daten / Residenz

Welche Daten dürfen den eigenen Kontrollraum verlassen? Lokale Modelle für sensible Workloads — vertrauliche Tickets, Code-Repositories, Vertragsentwürfe — bleiben auf eigener Infrastruktur. Externe APIs für nicht-sensible Pfade reduzieren Betriebsaufwand, ohne den Kern preiszugeben. Die Reife des lokalen Stacks reicht 2026 für interne Wissensbasen, Coding-Assistenz auf vertraulichem Code, Klassifikation in regulierten Pipelines, dokumentennahe Q&A — nicht Frontier-Niveau, aber ausreichend, und ohne Datenfluss zu US-Servern.

2. Inferenz

Wo läuft die Modell-Anfrage, wer sieht die Logs? Eigene Inferenz-Infrastruktur für sensible Pfade ist 2026 mit lokal lauffähigen Open-Weight-Modellen praktisch erreichbar. Audit-Logs zur Laufzeit liegen damit im eigenen Haus. Bei einer externen API bleibt diese Schicht beim Anbieter, auch wenn sie vertraglich umzäunt ist. Hybridbetrieb ist die Regel: lokal für sensibel, API für skalierbar.

3. Post-Training

Wo entsteht die Differenzierung? Hier kaum delegierbar — hier sitzt das Geschäft. Cursors Composer 2 ist das Lehrstück, ausführlich im Stop Waiting, Start Shipping-Beitrag dieser Serie: im Kern Kimi 2.5 mit zusätzlichem Reinforcement Learning, im März 2026 von Cursor-Mitgründer Aman Sanger bestätigt. Composer 2 zeigt exemplarisch den pragmatischen Ansatz: Mehrwert auf den Schultern von Riesen aufbauen schlägt jeden Eigenbau-Reflex am Base-Modell. Wertschöpfung entsteht nicht aus der Wahl des Base-Modells, sondern aus eigenen Daten, Evals, Harness und Produktdisziplin.

Ines Montani hat die ökonomische Logik dahinter klar formuliert:

„It's like software 2.0. You have code and data, and a lot of the value is in the data. So we can provide the code basically for free and open source and then focus our product offering on the other part that's more custom."

Das Base-Modell ist das geteilte Code-Layer. Eigene Daten und Post-Training darauf sind die Schicht, in der Differenzierung entsteht. Wer sie delegiert, delegiert sein Geschäft.

4. Evaluation

Wie misst man Modellverhalten — im eigenen Haus? Eval-Disziplin, eigene Eval-Suite und ein selbst kontrollierter Harness sind 2026 die Schichten, in denen domänenspezifische Qualität sichtbar wird und falsche Modellwahl frühzeitig auffliegt. Ohne Eval-Disziplin bleibt jede Souveränitäts-Aussage Behauptung und jede Modell-Migration ein Bauchgefühl. Günstig im Aufbau, teuer in der Vernachlässigung.

5. Compliance / Audit

Können wir das Modell inspizieren, wenn die Aufsicht es verlangt? Sylvain Corlay (QuantStack, Jupyter) hat das Argument in seine fundamentale Form gebracht:

„Anyone who's done science at some point in their life understands that there would be a huge contradiction in trying to understand the world like physics or biology or anything with a tool that you don't have the right to understand or look into."
„The core of the logic and of the intelligence will have to be open source. Otherwise, nobody is going to buy it. And that's a big part of the trust that people have in the software. It's that it's been audited by experts."

Bankenaufsicht, Versicherungsaufsicht und interner Audit folgen derselben Logik. Der zweite Satz ist die kommerzielle Konsequenz des ersten — im Vorstand das stärkere Argument.

Was Open-Weight liefert: Modellgewichte, eigene Inferenz, Laufzeit-Audit-Logs, Kontrolle der Datenflüsse. Was nicht automatisch dazugehört: vollständige Trainingsdaten-Auditierbarkeit. Bei Qwen, DeepSeek, Kimi wie bei Llama, Gemma, Mistral ist die Trainingsdaten-Provenienz selten vollständig dokumentiert. Wer Compliance auf Provenienz baut, muss die Trennung zwischen Open-Weight und Open-Data explizit machen.

Proprietäre Enterprise-Anbieter sind keine reine Black Box mehr: OpenAI Enterprise, Anthropic Claude for Work und Azure OpenAI bieten Datenresidenz, Zero-Retention, BAA und Audit-Logs auf Inferenz-Ebene. Was bleibt: kein Modellgewicht in eigener Hand, keine Trainingsdatenkontrolle, kein direkter Zugriff auf Modellverhalten. Für viele Use Cases ausreichend — für Modell-Inspektion in der Compliance-Argumentation nicht.

6. Betrieb

Was tun wir am Tag eins, wenn ein zentraler Anbieter wegbricht? QuantStack hat operativ darauf geantwortet: Migration aller Services zu europäischen Providern, ein „contingency forge" als GitHub-Mirror, damit am nächsten Tag weitergearbeitet werden kann, sollte der Hauptzugang fallen. Sylvain Corlay nennt das economic survivalism.

„We've migrated all of our services to European providers … we even have a contingency forge with pretty much everything we touch on GitHub mirrored so that we have something to do the next day, if we are shut down, basically."

Übertragen auf Enterprise-Stacks: Service-Partner statt Hersteller-Lizenz, dokumentierte Backup-Pfade, eine Tag-eins-Antwort, die im Vorstand vorliegt — bevor sie gebraucht wird. Allein diese Fähigkeit ist Hebel bei Preisverhandlungen. Diese Schicht entscheidet, ob die Architektur 2027 noch trägt oder an einer einzigen Anbieter-Entscheidung scheitert.

Eine ehrliche Einordnung der Modellwahl

Die Modellwahl ist wichtig — aber nicht das Wichtigste. Wichtig ist die Kontrolle der Schichten darüber: Daten, Eval, Harness, Post-Training. Tiefer dazu im Stop Waiting, Start Shipping-Beitrag dieser Serie.

Die organisationalen Blocker

Ausgebremst wird Souveränität selten am Modell, sondern an organisationalen Blockern. Vier sind 2026 die hartnäckigsten.

Procurement-Reflex auf „Hersteller mit SLA"

Beschaffungsabteilungen sind auf „Hersteller mit SLA" konditioniert. Ein offener Stack braucht ein anderes Vertragsmodell: Service-Provider, Engineering-Beratung, interne Verantwortung. Wer den Procurement-Frame nicht früh verändert, scheitert nicht am Modell, sondern am Vertragsformular.

Ines Montani warnte zudem vor einer Variante, die in jede Procurement-Diskussion gehört:

„You adopt a project and then the startup behind the project goes and raises a lot of money, and they pivot here, they pivot there, and in the end the open source is kind of collateral."

VC-Finanzierung ist kein Stabilitätsbeweis. Stabilität sitzt in der Governance.

Mein Punkt dazu: Open-Source-Lizenzen sind in der Regel unwiderruflich. Auch nach Pivot oder Insolvenz des Anbieters bleibt das Recht, die Software zu nutzen, zu forken und weiterzuentwickeln — eine strukturelle Absicherung, die kein Hersteller-Vertrag bietet.

Skill-Mangel: Betrieb, Training, OSS-Komposition

Der Skill-Engpass 2026 sitzt selten beim ML-PhD. Er sitzt in drei Disziplinen, die sich gegenseitig bedingen: Betrieb (lokale Inferenz-Stacks, Audit-Logs, dokumentierte Migrationspfade, Tag-eins-Plan), Training (Post-Training, Continued Pre-Training auf eigenem Korpus, Eval-Suite, Harness-Disziplin) und OSS-Komposition — die oft übersehene Schlüsseldisziplin: Auswahl, Integration und Wartung der offenen Komponenten zu einer kohärenten Architektur.

Ohne diese drei Disziplinen — im Haus oder beim Service-Partner — läuft kein Schichten-Programm. Die These „Domänenexperte mit Experimentierwillen vor ML-PhD" gilt weiter, reicht allein aber nicht. Wer Souveränität ernsthaft umsetzen will, braucht eine Brücke aus interner Engineering-Substanz und externer Beratung.

Der Open-Source-Sicherheits-Mythos

Die Vorstellung, Open Source sei unsicherer als proprietär, ist empirisch schwer zu stützen. Der Code ist offen, also auditierbar. Proprietärer Code ist es in der Regel nicht — was beim Anbieter passiert, bleibt beim Anbieter. Auf der Sicherheitsfrage geht der Punkt damit an Open Source: Mehr Augen wachen über den Code als bei einem einzelnen Hersteller, CVE-Prozesse sind transparent, der Patch-Pfad liegt offen.

Sicherheit erschöpft sich darin nicht. Sie hängt auch an technisch erzwingbaren Guardrails — Tool-Berechtigungen, Filesystem-Zugriff, API-Keys. Bei einem offenen Stack lässt sich diese Schicht selbst inspizieren. Bei einer Black-Box-API bleibt man auf das Vertrauen zum Anbieter angewiesen.

Der ungeklärte Tag-eins-Plan

Was tun wir am Tag eins, wenn AWS, Azure oder ein zentraler Service-Provider unsere Konten sperrt? Die meisten Enterprise-Stacks haben darauf 2026 keine geprobte Antwort — nicht aus technischer Unmöglichkeit, sondern aus der Vermutung, dass es schon nicht passieren wird. Souveränität, die diese Annahme stehen lässt, ist Pose.

Für Entscheider heißt das

Erstens: Souveränitäts-Inventar entlang der Schichten

Welche Workloads müssen lokal laufen, welche dürfen in die Cloud? Welche Schicht behalten wir, welche delegieren wir an einen Service-Partner? Diese Inventarisierung ist die Grundlage jeder Souveränitätsarchitektur — und 2026 ein konkretes Arbeitsdokument, kein Strategiepapier.

Zweitens: Procurement neu rahmen

Nicht „Hersteller-Lizenz" suchen, sondern „Service-Partner für den offenen Stack". Andere Vertragslogik, mehr geteilte Engineering-Verantwortung — und die ausdrückliche Prüfung der Governance des Partners, nicht nur seines SLA-Logos.

Drittens: Eine Use-Case-Insel bauen, nicht einen Pilot

Ein „Pilot" ist defensiv und selten Architektur. Eine Use-Case-Insel ist ein internes Programm mit lokalem Modell, eigenem Post-Training, eigener Eval-Disziplin und eigenem Harness — auf einem klar abgegrenzten Use Case. Die Insel ist die kleinste vollständige Implementierung der Schichten-Karte — und damit die kürzeste Strecke vom Strategiepapier zum Stack.

Viertens: Eine Tag-eins-Antwort vorbereiten, bevor sie gebraucht wird

Was tun wir, wenn morgen ein zentraler Anbieter wegbricht? Ein dokumentierter Migrationspfad, ein Mirror der kritischen Repositories, ein Service-Partner, der einspringen kann — 2026 keine Paranoia, sondern Architekturpflicht.

Souveränität 2026 ist keine Besitzfrage mehr. Sie ist eine Beherrschungsfrage. Welche Schicht des Stacks ein Unternehmen kontrolliert und welche es bewusst delegiert, entscheidet, wie souverän es 2027 tatsächlich agiert.