Modell-Abhängigkeit: Warum modell-agnostische Workflows zur Chefsache werden
Marc GasserSerial Founder · GTM & MarketingVerbindet AI mit Revenue-Operations und baut autonome GTM-Systeme für vorhersehbares Wachstum.TL;DR
- Das Problem heisst nicht Fable 5, sondern Abhängigkeit. Erstmals nahm eine US-Behörde ein bereits öffentlich ausgerolltes Frontier-Modell per Anordnung vom Markt – weltweit, ohne Einspruchsrecht. Wer seine KI-Pipeline auf einen einzigen Anbieter baut, hat einen Single Point of Failure, den er nicht kontrolliert.
- Die Abhängigkeit hat Schichten: das Modell, die Cloud darunter, das API-Ökosystem deiner Workflows und die politische Gunst. Genau die Workflow-Schicht ist die, die Produktteams selbst steuern können – über eine Abstraktion, die den Anbieterwechsel von einem Reengineering-Projekt zurück zu einer Konfigurationsänderung macht.
- Die Antwort ist nicht «weg von US-Modellen» und auch keine Open-Source-Romantik. Die Antwort ist Wechselfähigkeit: Modellwahl pro Projekt, Routing nach Kritikalität, Hosting unter eigener Kontrolle. Genau dafür haben wir Teklens model-agnostisch gebaut – Modellwahl als Projekt-Einstellung statt Glückssache.
Kernaussagen
- VentureBeat brachte die Lehre auf einen Satz, der sich kaum präziser fassen lässt: «centralized, cloud-based frontier models exist at the absolute mercy of government oversight and vendor compliance.» Zentrale, cloud-basierte Modelle liegen in der Hand von Aufsicht und Anbieter-Compliance – nicht in deiner.
- Das teure Lock-in ist nicht der Modellname, sondern der Workflow rundherum: Prompt-Architekturen, Tooling-Integrationen, Agentic-Workflows, tief in eine spezifische API eingeschrieben. Ein Wechsel ist dann ein Reengineering-Projekt – es sei denn, man hat von Anfang an eine Abstraktion dazwischengelegt.
- Bitkom-Präsident Ralf Wintergerst forderte digitale Souveränität «mit an die Spitze der politischen Prioritäten». Aber Unternehmen müssen nicht auf Brüssel warten: Die Diversifikations-Hebel – Inventar, Abstraktion, Routing, Hosting-Wahl – liegen heute schon in der eigenen Hand.
Was am 12. Juni 2026 geschah – und warum es kein Tech-Insider-Thema ist
Am 9. Juni 2026 hat Anthropic Claude Fable 5 gelauncht, nach eigener Darstellung das leistungsfähigste öffentlich verfügbare Modell bis dahin, sofort auf allen grossen Plattformen. Drei Tage später, am Abend des 12. Juni, kam eine Export-Control-Direktive der US-Regierung. Und Fable 5 war weg. Für alle. Weltweit. Nicht weil Anthropic es wollte, sondern weil eine Behörde es so entschied.
Die Mechanik dahinter ist nüchtern und genau deshalb beunruhigend. Die Direktive richtete sich nominell gegen ausländische Staatsangehörige – aber eine selektive Sperrung nach Nationalität ist in einem globalen Cloud-System nicht in Echtzeit umsetzbar. Der einzige Weg zur Compliance war, alles abzuschalten. Auch für ein Unternehmen in Linz, das seinen Support über Claude-APIs abwickelt und am Montagmorgen ohne sein wichtigstes Werkzeug dastand. Kein Einspruchsrecht, kein Vorwarnzeitraum, keine europäische Instanz, die dazwischentreten könnte.
Man muss die Hintergründe des Konflikts nicht im Detail bewerten, um den Befund zu verstehen. Entscheidend ist: Es ist das erste Mal in der Geschichte der Branche, dass ein bereits ausgerolltes Frontier-Modell durch staatliche Anordnung vom Markt genommen wurde. Der deutsche Digitalverband Bitkom reagierte alarmiert; Präsident Ralf Wintergerst sprach von der Abhängigkeit «vom Wohlwollen der US-Regierung».
Das ist keine Kritik an Anthropic, das öffentlich gegen die Direktive Stellung bezog und sie trotzdem befolgen musste. Es gab keine andere Wahl – und genau das ist der Punkt.
Die vier Schichten der Modell-Abhängigkeit
Wenn Teams über ihre KI-Abhängigkeit nachdenken, denken die meisten ans Modell: Welche Version nutze ich, kann ich von Claude zu Gemini wechseln? Das ist die oberste und harmloseste Schicht. Darunter liegen drei weitere, die im Ernstfall mehr wehtun.
Schicht 1: Die Cloud. Claude läuft auf AWS, Gemini auf Google Cloud, GPT auf Azure. Alle drei Hyperscaler sind US-Unternehmen und unterliegen US-Recht. Selbst ein europäisches Modell liefe bei den meisten Firmen auf amerikanischer Infrastruktur – die Abhängigkeit reicht eine Etage tiefer, als der Modellname vermuten lässt.
Schicht 2: Das API-Ökosystem. Hier sitzt das eigentliche Lock-in. Die Workflows der letzten zwei Jahre sind tief in eine spezifische API eingeschrieben: Prompt-Architekturen, Tool-Definitionen, Agentic-Loops. Ein Modellwechsel ist dann keine Konfigurationsänderung, sondern ein Reengineering-Projekt – es sei denn, zwischen Geschäftslogik und Anbieter liegt eine Abstraktion.
Schicht 3: Die politische Gunst. Die Schicht, über die am wenigsten gesprochen wird. Export-Control-Direktiven liegen im Ermessen der Exekutive – kein Parlamentsbeschluss, keine internationale Abstimmung, keine Vorwarnung nötig. Eskaliert ein Handelskonflikt, kann die Verfügbarkeit von Frontier-Modellen über Nacht zur Verhandlungsmasse werden. Ich sage nicht, dass das passieren wird. Ich sage, dass es seit dem 12. Juni 2026 nachweislich möglich ist.
Der Anbieter-Risiko-Check: Wie abhängig bist du von einem einzigen Modell?
Du hängst an einem Anbieter, ohne es zu steuern. Starte mit dem Inventar – es kostet Tage und legt offen, wo ein Brief aus Washington wehtut.
Hake an, was bei euch heute gilt – das Ergebnis zeigt, ob ein Brief aus Washington euch am Montag lahmlegen könnte.
Was modell-agnostische Workflows konkret bedeuten
Modell-agnostisch heisst nicht, ständig den Anbieter zu wechseln. Es heisst, wechseln zu können, ohne den halben Stack neu zu bauen. Der Hebel ist eine Abstraktionsschicht: Deine Geschäftslogik spricht mit einer internen Schnittstelle, nicht direkt mit der API von Anthropic, OpenAI oder Google. Hinter dieser Schnittstelle ist der Anbieter eine Einstellung – austauschbar, testbar, pro Aufgabe wählbar. Aus dem Reengineering-Projekt wird wieder eine Konfigurationsänderung.
Genau deshalb haben wir Teklens von Anfang an model-agnostisch gebaut. Die Context Engine – semantische Suche plus Knowledge Graph über Code, Tickets und Entscheidungen – ist nicht an ein Modell gebunden. Die Modellwahl ist eine Projekt-Einstellung statt Glückssache: Claude, GPT oder Gemini je nach Aufgabe, inklusive EU- oder Schweizer Hosting für sensible Projekte. Der Kontext, das eigentlich Wertvolle, bleibt deiner – egal welches Modell unten dranhängt. So ist Vendor-Lock-in ausgeschlossen, nicht als Versprechen, sondern als Architektur.
Die zweite Hälfte ist Routing nach Kritikalität. Nicht jede Aufgabe braucht das teuerste Frontier-Modell. Eine Ticket-Zusammenfassung, eine Klassifikation, ein Standup-Text laufen problemlos auf einem kleineren oder lokal betreibbaren Modell. Frontier-Leistung – mehrstündige autonome Workflows, tiefe Code-Analyse – reservierst du für die Fälle, die sie wirklich brauchen. Das senkt Kosten, reduziert die Abhängigkeit pro Aufgabe und macht im Ernstfall einen Teil deiner Workflows sofort souverän.
Souveränität ohne Ideologie: weder US-Boykott noch Open-Source-Romantik
An dieser Stelle kippt die Debatte gern ins Grundsätzliche: weg von den Amerikanern, hin zu europäischen Modellen, am besten alles Open Source. Das ist gut gemeint und zu kurz gesprungen. US-Modelle sind heute für viele Aufgaben schlicht die leistungsfähigsten Optionen, und das ehrlich anzuerkennen gehört zu einer erwachsenen Strategie.
Europäische Anbieter wie Mistral liefern beeindruckende Open-Weight-Modelle für Standardaufgaben – aber für echte Frontier-Leistung besteht heute eine Lücke, die man nicht wegreden sollte.
Souveränität heisst deshalb nicht, das beste Werkzeug zu meiden. Sie heisst, nie von einem einzigen abhängig zu sein. Der EU AI Act regelt, welche Risiken von KI-Anwendungen ausgehen – Transparenz, Hochrisiko-Pflichten. Eine Souveränitätsstrategie beantwortet eine andere Frage: Wer kontrolliert die Infrastruktur, auf der diese Anwendungen laufen? Beides ist nötig, aber es ist nicht dasselbe. Der AI Act löst das Abhängigkeitsproblem nicht.
Die gute Nachricht: Den entscheidenden Teil können Unternehmen selbst steuern, ohne auf Brüssel zu warten. Wer eine Abstraktion einzieht, nach Kritikalität routet und für sensible Daten das Hosting kennt, übersetzt ein geopolitisches Risiko in eine Architektur-Entscheidung. Das ist kein Aktivismus, sondern Risikomanagement – dieselbe Disziplin, mit der man auch keinen einzigen Zahlungsdienstleister, keinen einzigen Cloud-Standort und keinen einzigen Lieferanten für ein geschäftskritisches Teil akzeptiert.
Empfehlungen
- Mach die Bestandsaufnahme diese Woche. Liste jeden Workflow mit seinem KI-Anbieter, der Kritikalität und der Datenklasse. Du kannst kein Risiko steuern, das du nicht siehst – und die Liste kostet Tage, nicht Monate.
- Zieh eine Abstraktionsschicht ein. Kein direkter Anbieter-API-Call in der Geschäftslogik. Sprich mit einer internen Schnittstelle, hinter der das Modell eine Einstellung ist. So wird der Wechsel zur Konfiguration statt zum Projekt.
- Route nach Kritikalität. Reserviere Frontier-Modelle für Aufgaben, die sie wirklich brauchen. Der Rest läuft auf kleineren oder lokal betreibbaren Modellen – billiger und im Ernstfall sofort souverän.
- Mach Modell-Risiko zum Vorstandsthema. Ein benanntes Risiko mit Verantwortlichem, einer Kennzahl (Wie schnell könnten wir wechseln?) und einem jährlichen Test. Lieferantenkonzentration bei KI gehört auf dieselbe Agenda wie bei Zahlung, Cloud und Logistik.
Einordnung & Grenzen
- Die Schilderung der Ereignisse um Fable 5 stützt sich auf öffentliche Berichterstattung (u.a. Anthropic-Statement, Bitkom, VentureBeat, TechCrunch, NBC News) mit Stand 15. Juni 2026. Es ist eine sich entwickelnde Lage ohne offiziellen Zeitplan zur Wiederherstellung – einzelne Details können sich noch ändern oder anders eingeordnet werden.
- Modell-Agnostik ist nicht gratis. Abstraktionsschichten, Eval-Harnesses über mehrere Modelle und portable Prompts kosten Engineering-Zeit. Kalibriere die Investition an der Kritikalität des Workflows – für interne Textentwürfe lohnt sich weniger Aufwand als für klinische Entscheidungsunterstützung.
- Die Leistungslücke ist real: Für echte Frontier-Aufgaben erreichen europäische und Open-Weight-Alternativen heute nicht das Niveau der besten US-Modelle. Modell-agnostisch heisst Wechselbereitschaft, nicht so zu tun, als wären die Optionen gleichwertig.
- Dieser Artikel ist eine produktstrategische Einordnung, keine geopolitische Prognose und keine Rechtsberatung. Die konkrete rechtliche Bewertung von Export-Kontrollen und Datenresidenz gehört in die Hände spezialisierter Fachleute.
Fazit
Die Lehre aus drei Tagen Fable 5 ist nicht «weg von US-Modellen», sondern «nie abhängig von einem einzigen». Wer modell-agnostische Workflows zur Strategie macht – Modellwahl pro Projekt, Abstraktion vor dem Anbieter, Hosting unter eigener Kontrolle –, übersetzt ein geopolitisches Risiko in eine Architektur-Entscheidung, die er selbst trifft.
Passende Use Cases aus der Bibliothek
Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.
Kein neuer Beitrag ohne dich.
Neue Artikel, neue interaktive Tools, neue Evidenz – zuerst in deiner Inbox. Und wenn du antwortest, antworten wir: Du schreibst direkt mit den Autoren, nicht mit einem No-Reply.
Kein Spam, keine Weitergabe, jederzeit abmeldbar.