Souveränität ist das Wort der Woche bei Beratern — aber der eigentliche Hebel ist euer Harness

Seit Anfang Juli sitzen wir in mehreren Wochen-Vorbereitungsgesprächen mit Kunden, deren Steuerberater, Wirtschaftsprüfer oder Datenschutzbeauftragte in einem Nebenpunkt „KI-Souveränität" angesprochen haben. Das Wort taucht auf, weil eure Berater die Schlagzeilen der letzten drei Wochen genauso lesen wie wir: Fable-Ban, Reinstate, Persona-Verifikation, GPT-5.6-Drosselung, heute morgen der Fable-Stealth-Reroute zu Opus und nachmittags die kurzfristige Verschiebung des Fable-Cutoffs vom 8. auf den 13. Juli. Der Reflex zu sagen „wir müssen souveräner werden" ist verständlich.

Nur ist die daraus üblicherweise abgeleitete Empfehlung — „wechselt zu einem EU-Anbieter" — eine zu einfache Antwort auf eine ehrliche Frage. Und in unseren Kundenprojekten dieser Woche merken wir, dass der Reflex den Blick auf das eigentlich Wichtige verstellt.

Was Souveränität nicht ist

Souveränität ist kein Anbieter-Etikett. Wer heute komplett von Anthropic auf Mistral umzieht, hat sein Klumpenrisiko nicht reduziert, sondern nur umverteilt — und läuft in der nächsten Krise eben in eine Mistral-spezifische Situation. Mistral ist ein starker Anbieter, EU-Compliance ist ein realer Vorteil, deutsche Sprache läuft dort spürbar besser als bei chinesischen Open-Source-Modellen. Aber Mistral ist ein Unternehmen, das eigene Preisänderungen, eigene Kapazitätsengpässe, eigene politische Konstellationen haben wird.

Wer die Souveränitätsfrage also mit einer Anbieter-Migration beantwortet, hat sie in Wahrheit nicht beantwortet. Er hat nur einen Anbieter-Riegel gegen einen anderen getauscht. Das kann sich betriebswirtschaftlich lohnen, das kann DSGVO-Fragen glätten — es ist aber nicht das, was Souveränität eigentlich meint.

Wo Souveränität wirklich sitzt

Die harte Definition sitzt eine Ebene tiefer. Souverän seid ihr in eurem KI-Setup, wenn ihr einen einzelnen Anbieter innerhalb eines Werktages ersetzen könnt, ohne dass eure produktive Auslieferung darunter leidet. Das ist eine architektonische Aussage, keine Anbieter-Aussage.

Praktisch heißt das: Zwischen eurer Anwendung und der Anthropic-, OpenAI-, Mistral- oder Ollama-API sitzt eine dünne Schicht, die ihr selbst kontrolliert. Eure Anwendung ruft nicht direkt anthropic.messages.create() auf, sondern eine eigene Funktion — nennen wir sie complete() —, die intern entscheidet, welchen Anbieter sie anspricht. Modell-Auswahl, Rate-Limits, Retry-Verhalten, Failover: alles im Harness, nichts in der Anwendungslogik.

Wer diesen Harness hat, ist tatsächlich souverän. Der Anbieter unter dem Harness kann sich ändern — und die Änderung wird eine Frage von Konfiguration, nicht von Notfall-Refactoring. Wer den Harness nicht hat, ist auch mit dem edelsten EU-Modell darunter nicht souverän.

Was den flexiblen Harness ausmacht

Drei Anforderungen, die in der Praxis den Unterschied ausmachen.

Erstens: Anbieter-agnostisches Interface. Der Harness spricht in einer normalisierten Sprache — typischerweise das OpenAI-Chat-Completion-Format oder ein hausinternes JSON —, und übersetzt intern in das jeweilige Anbieter-Format. Das ist nicht kompliziert. Bibliotheken wie LiteLLM oder Vercel AI SDK machen das aus der Kiste; ein eigener Wrapper ist an einem halben Tag geschrieben.

Zweitens: Konfigurationsgetriebene Modellwahl. Welches Modell für welche Aufgabe genutzt wird, steht in einer Konfigurations-Datei — nicht im Code. Damit ist die Umstellung eines Workloads eine Textdatei-Änderung, kein Deployment. Das Orchestrator-Pattern vom Sonntag ist die logische Erweiterung: pro Aufgabe eine Klasse (planen / ausführen / prüfen), pro Klasse ein Modell in der Konfiguration.

Drittens: Beobachtbare Nutzung. Der Harness loggt jede Anfrage mit Anbieter, Modell, Latenz, Kosten. Das ist die einzige Grundlage, auf der ihr Anbieter-Wechsel sinnvoll planen könnt. Und die einzige Grundlage, auf der ihr Vorfälle wie den heutigen Fable-Reroute-zu-Opus überhaupt bemerken würdet.

Der Kalender ab morgen — kurz und konkret

Damit dieser Standpunkt nicht abstrakt bleibt, hier die drei operativen Punkte für diese Woche, die die Souveränitäts-Diskussion konkret berühren:

Fable-Cutoff auf 13. Juli verschoben. Anthropic hat am Nachmittag des 7. Juli die 50-Prozent-Weekly-Limit-Phase für Fable 5 um sechs Tage verlängert — neuer Cutoff-Termin ist der 13. Juli. Das ist der zweite Terminwechsel innerhalb einer Woche. Wer ohne Harness plant, hat gerade zum wiederholten Mal eine Terminfestlegung neu einpflegen müssen. Wer mit Harness plant, hat den Termin in einer Konfigurations-Zeile — und ist beim nächsten Wechsel innerhalb von Sekunden anpassungsfähig.

8. Juli, parallel: Persona-Verifikation wird für geflaggte Konten scharf. Was das konkret bedeutet, haben wir am Freitag durchgesprochen. Die Entscheidung „Verifikation akzeptieren, Accounts splitten, oder API-Migration" ist einfacher zu treffen, wenn euer Harness die Umschaltung sowieso abstrahiert hat.

Ab dem 13. Juli: Fable wandert wie bisher geplant in die Prepaid-Credits, sofern nicht erneut verschoben wird. Anthropic hat weiter angekündigt, Fable „so bald wie Kapazität es zulässt" wieder in die Subscriptions zurückzuholen — ohne festen Termin. Wer den Harness hat, kann diese Rückkehr wie jede andere Anbieter-Änderung als Konfigurations-Update behandeln.

Was wir konkret empfehlen

Drei Aktionen für die nächsten sieben Tage — pragmatisch, ohne Ideologie:

1. Prüft eure aktuelle Harness-Struktur. Ist die Anbieter-Wahl eine Konfigurations-Zeile oder ein Refactor? Wenn Refactor: das ist der Ansatzpunkt der nächsten zwei Wochen.
2. Nicht Anbieter-Wechsel überstürzen. Wer heute mit Anthropic gut fährt und einen Harness ergänzt, ist am Ende der Woche souveräner als jemand, der ohne Harness zu Mistral gewechselt hat.
3. Beobachtung einbauen. Wenn ihr keinen Log-Layer über euren Anfragen habt, ist genau jetzt die Zeit dafür — die letzten zwei Wochen haben gezeigt, dass ihr diese Daten braucht, um Anbieter-Änderungen überhaupt zu erkennen.