Die Funktion lässt sich nicht exportieren

Am Freitag hat ein Entwicklungsteam eine Nachricht erhalten, die keines seiner Systeme betraf. Am 28. August kündigte OpenAI an, die Belieferung von Cursor mit den eigenen Modellen zu beenden, unter Berufung auf die Change-of-Control-Klausel, die die Übernahme durch SpaceX ausgelöst hat: direkter Zugang geschlossen am 12. November, die maximale Frist, die der Vertrag erlaubt. Von heute an fünfundsiebzig Tage.

Kein Angriff. Kein Ausfall. Keine Daten verloren, keine API verletzt. Cursor existiert weiter, die Repositories bleiben, wo sie sind, die anderen Modelle bleiben im Menü. Es ist schlicht passiert, dass eine Funktion, die Tausende Teams täglich benutzen, aus ihrer Umgebung verschwinden wird, wegen einer Vertragsentscheidung zwischen zwei Dritten.

Stellen wir uns nun den CTO dieses Teams vor, der sein Abhängigkeitsinventar öffnet. „GPT“ taucht fast nirgends auf. Nicht im Lock File. Nicht in der SBOM. Nicht in den Architekturdiagrammen. Und doch wurde ein erheblicher Teil des Entwicklungsprozesses über Monate auf das Verhalten dieses Modells kalibriert: die Größe der Spezifikationen, die Tiefe der Reviews, die Zahl der eingeplanten Iterationen, bis hin zu den Schätzungen für die Kunden. Technisch hat das Team nichts verloren. Organisatorisch muss es erst noch herausfinden, wie viel es verloren hat.

Das Unternehmen, das alles richtig gemacht hatte

Ich habe vor wenigen Tagen geschrieben, dass der Lock-in bald nicht mehr in den Daten steckt: zwischen den Dokumenten und den Entscheidungen bildet sich ein drittes Objekt, der Zustand, den das System ansammelt, während es für dich arbeitet, und der Preis des Ausstiegs droht die Amnesie zu sein. Die Antwort war eine präzise Architekturdisziplin: was für das Verhalten des Agenten wichtig ist, sollte, wo immer möglich, außerhalb des Agenten leben.

Diesmal will ich zugestehen, dass diese Architektur funktioniert. Stellen wir uns eine Organisation vor, die alles richtig gemacht hat. Die Spezifikationen liegen im Repository. Die Architekturentscheidungen sind versioniert. Die wichtigen Prozeduren sind explizite Skills geworden. Die Werkzeuge laufen über offene Protokolle. Der Projektkontext lebt nicht im privaten Gedächtnis des Providers, die Evals sind modellunabhängig, die Daten lassen sich exportieren, das relevante Gedächtnis lässt sich rekonstruieren. Das System wurde genau dafür entworfen, Claude durch GPT ersetzen zu können, GPT durch Gemini, Gemini durch ein Open-Weight-Modell.

Dann, an einem Montagmorgen, wird das Modell ersetzt. Technisch funktioniert alles weiter. Keine Migration, keine Inkompatibilität, kein vergessenes Gedächtnis.

Und doch wird der Prozess schlechter. Der Agent ändert mehr Dateien als nötig. Er liest die Spezifikationen mit weniger Disziplin. Er braucht drei Iterationen, wo vorher eine genügte. Er erkennt nicht mehr mit derselben Zuverlässigkeit, wann eine Anfrage mehrdeutig ist. Seine Reviews sind technisch korrekt, aber weniger nützlich. Vielleicht ist er schneller, vielleicht billiger, und produziert dabei mehr Arbeit, die absorbiert werden muss. Oder das Gegenteil geschieht: das neue Modell ist insgesamt besser, dominiert die öffentlichen Benchmarks, und ist schlechter genau in der Kombination von Verhaltensweisen, auf der die Organisation, ohne es zu wissen, ihre Arbeitsweise aufgebaut hatte.

Das Unternehmen hat seine Daten nicht verloren. Es hat sein Gedächtnis nicht verloren. Es hat seine Werkzeuge nicht verloren. Es hat eine kognitive Funktion verloren.

Die These, präzise formuliert: in der KI kann der Lock-in nicht in der technischen Unmöglichkeit bestehen, den Anbieter zu wechseln, sondern in der organisatorischen Abhängigkeit von einer bestimmten Verteilung von Fähigkeiten, Fehlern, Verhaltensweisen und Aufsichtskosten, deren Ersetzbarkeit keine Standard-API garantiert. Im vorigen Essay war der Preis des Ausstiegs die Amnesie. Hier ist er heimtückischer: man kann operative Kompetenz verlieren, ohne ein einziges Byte zu verlieren.

Der Einwand: das ist kein Lock-in, das ist Qualität

Bevor es weitergeht, gebührt dem stärksten Einwand fast volle Zustimmung. Ersetze ich PostgreSQL durch eine langsamere Datenbank und die Anwendung wird träge, habe ich keine neue Form von Vendor Lock-in entdeckt: ich habe ein schlechteres Produkt gewählt. Ersetze ich einen exzellenten Ingenieur durch einen mittelmäßigen, leidet der Prozess, und niemand würde sagen, ich sei auf den ersten „locked in“ gewesen. Führt Claude eine Aufgabe besser aus als Gemini, begründet der Qualitätsunterschied keine pathologische Abhängigkeit. Dieser Einwand muss stehen bleiben: das Wort Lock-in hat nur Wert, wenn es etwas Präziseres beschreibt als die banale Feststellung, dass Produkte sich unterscheiden.

Das Problem erscheint, wenn die Eigenschaften des Produkts aufhören, Leistung zu sein, und zu Annahmen werden, die in die Organisation eingebaut sind. Es ist ein Unterschied, ob man sagt „dieses Modell schreibt besseren Code“ oder: unser Review-Prozess, die Größe unserer Spezifikationen, die Granularität der Aufgaben, die Zahl der menschlichen Kontrollen und selbst der Preis, zu dem wir unsere Arbeit verkaufen, setzen voraus, dass dieses Modell eine bestimmte Zuverlässigkeit hält. Im zweiten Fall ist die Fähigkeit des Modells zur Infrastruktur geworden. Der Austausch bleibt technisch möglich, verlangt aber organisatorische Neukonstruktion.

Und genau das ist die Signatur des echten Lock-ins: die Ausstiegskosten decken sich nicht mit den Kosten der Übertragung der Assets. Sie decken sich mit den Kosten, anderswo die Bedingungen wiederaufzubauen, von denen das System abhing.

Das Modell ist Teil des Prozesses

Das klassische SaaS machte die Abhängigkeit wenigstens benennbar: Datenbank, Dateien, Konfigurationen, APIs, Workflows. Das Problem war, sie in brauchbarer Form wieder herauszubekommen, und das ist das Problem, das der Data Act mit Switching, exportierbaren Daten und funktionaler Äquivalenz angreift. Im vorigen Essay war schon etwas Flüchtigeres aufgetaucht: der Zustand des Agenten ist kein Archiv, sondern eine Transformation des Archivs, und zwei Systeme mit denselben Daten können sich unterschiedlich verhalten, weil sie die Erfahrung unterschiedlich konsolidiert haben.

Der nächste Schritt ist radikaler. Auch zwei Agenten mit denselben Daten, demselben Gedächtnis, denselben Werkzeugen, denselben Anweisungen und derselben Spezifikation bleiben funktional verschiedene Systeme. Denn das Modell ist kein neutraler Interpret des Prozesses: es ist Teil des Prozesses. Es entscheidet implizit, wie es die Aufmerksamkeit verteilt, wie viel es erkundet, bevor es sich festlegt, wie viel es verifiziert, wann es nachfragt, statt weiterzumachen, wie sehr es dem Kontext vertraut, wie wörtlich es ein Requirement nimmt und wie stark es generalisiert, wie es auf einen fehlschlagenden Test reagiert, wie leicht es die eigene Hypothese aufgibt, wann es aufhört.

Keine dieser Eigenschaften ist im API-Vertrag deklariert. Keine lebt in unserem Repository. Keine wird exportiert. Und vor allem hat keine notwendigerweise ein direktes Äquivalent im Konkurrenzmodell. Ein agentischer Workflow ist die Komposition aus einem expliziten Prozess und dem impliziten Verhalten des Modells: der erste Teil lässt sich mit der Disziplin des vorigen Essays portabel machen. Der zweite nicht.

Das falsche Versprechen der kompatiblen API

In der traditionellen Informatik hat die kompatible Schnittstelle enorme Macht. Sprechen zwei Datenbanken gut genug SQL, ist ein großer Teil der Abhängigkeit verschwunden. Implementieren zwei Object Storages dieselbe API, bricht der Wechselpreis ein. Akzeptieren zwei Runtimes dasselbe OCI-Artefakt, ist die Interoperabilität real. Bei Sprachmodellen drohen wir, syntaktische Kompatibilität mit Verhaltensäquivalenz zu verwechseln.

Zwei Provider können dieselben Messages, dieselben Tools, dasselbe JSON-Schema akzeptieren und dasselbe Format zurückgeben. Die Anwendung läuft auf Anhieb. Aber der wirkliche Vertrag war nie der Endpoint. Er war eine ungeschriebene Eigenschaft, die so lautet: wenn du eine Spezifikation dieser Art erhältst, mit diesem Repository, diesen Werkzeugen und diesen Evals, erreichst du ein akzeptables Ergebnis mit dieser Fehlerverteilung und diesen menschlichen Aufsichtskosten. Kein Protokoll standardisiert diese Eigenschaft. Ein kompatibler Adapter kann den Endpoint-Wechsel trivial machen und neunzig Prozent der realen Migrationskosten unberührt lassen.

Die Portabilität der APIs ist, für sich genommen, eine kosmetische Form von Souveränität.

Eine dynamische Einstellung eines SaaS

Der Fall Cursor ist nützlich, weil er ein Risiko konkret macht, das sonst abstrakt bleibt, aber es wäre ein Fehler, die ganze Argumentation darauf zu bauen: er ist eine Anomalie, mit Musk darin, einer 60-Milliarden-Übernahme und einer persönlichen Rivalität. Die gewöhnliche Form des Problems ist viel banaler, und sie hat ein Datum: übermorgen.

Am 1. September zieht GitHub sechs Modelle aus Copilot zurück, darunter Versionen von Claude Sonnet, Claude Opus und Gemini, auf allen Oberflächen des Produkts, mit den Nachfolgern als Alternativen. Aus Sicht des Anbieters ist das normales Lifecycle-Management, und daran ist nichts auszusetzen. Aus Sicht der Organisation bedeutet es etwas Präzises: ein Verhalten, das gestern Teil des Workflows war, ist morgen nicht mehr verfügbar. Und mit der Global Model Policy können neue Modelle standardmäßig verfügbar werden, wenn der Administrator keine restriktivere Richtlinie gewählt hat: die kognitive Funktion, die einem Team zugänglich ist, ist, buchstäblich, eine dynamische Einstellung eines SaaS.

In traditioneller Software ändert ein Upgrade den Code, der bestimmte Regeln ausführt. In der KI ändert ein Modellwechsel die Funktion, die die Regeln selbst interpretiert. Das klassische Machine Learning hat uns an den Drift gewöhnt: die Daten ändern sich, die Verteilung verschiebt sich, die Leistung degradiert. Hier geschieht etwas anderes, das ich vorsichtig Cognitive Dependency Drift nennen würde: deine Anwendung ändert sich nicht, deine Daten ändern sich nicht, die Spezifikation ändert sich nicht, und das Verhalten des Systems ändert sich trotzdem, weil sich die zugrunde liegende kognitive Komponente geändert hat. Neue Version, neues Fine-Tuning, neue Safety Policies, neues Routing, neuer Provider. Das Repository bleibt vollkommen unbewegt, während die Abhängigkeit unter einer scheinbar stabilen Schnittstelle ihre Natur wechselt.

Und die Kette ist geschichteter als beim SaaS: Organisation, Werkzeug, Modell-Broker, Modell-Provider. Jedes Glied kann unabhängig von den anderen reißen. Bei Cursor musste GPT nicht aus der Welt gezogen werden: es genügte, dass es aus der spezifischen Schnittmenge von Werkzeug, Vertrag und Organisation verschwindet, auf der jemand seinen Prozess gebaut hatte.

Die Abhängigkeit, die der Graph nicht erfasst

Ein Lock File zeigt, dass ich von einer Bibliothek abhänge. Eine SBOM zeigt eine Version. Ein Digest identifiziert ein Artefakt. Bei verwalteten Modellen ist die wichtigste Abhängigkeit semantisch reicher und für diese Instrumente völlig unsichtbar. Ich hänge nicht von „gpt-x“ ab: ich hänge davon ab, dass diese Version lange Spezifikationen gut versteht, Tests nicht umschreibt, um Code durchzubringen, Mehrdeutigkeiten erkennt, bestimmte Werkzeuge sparsam benutzt, mit einer gewissen Strenge reviewt, im Durchschnitt eine gewisse Zahl von Iterationen braucht.

Das Dependency Management könnte sich entsprechend weiterentwickeln müssen. Nicht nur: welche Version benutzen wir? Sondern: welche operativen Eigenschaften des Prozesses delegieren wir implizit an diese Version? Nach der SBOM, und mit aller Vorsicht, die neuen Namen gebührt, bräuchte es so etwas wie eine Cognitive Bill of Materials: keine Liste der vorhandenen Intelligenzen, sondern ein Inventar der kognitiven Funktionen, von denen der Prozess abhängt. Interpretation der Requirements, Generierung, Sicherheitsdenken, Review, Werkzeugplanung, Klassifikation, Ausnahmeerkennung. Und für jede: welches Modell sie ausführt, welche Zuverlässigkeit wir verlangen, welche Evals das belegen, welche Alternative wir haben, welchen Verlust wir bei einem Wechsel akzeptieren.

Heute inventarisieren wir Komponenten, weil eine Komponente verschwinden oder verwundbar werden kann. Delegierte Fähigkeiten können auf genau dieselbe Weise verschwinden. Sie stehen nur in keinem Inventar.

Evals als Instrument der Souveränität

Im vorigen Essay lautete der Ausstiegstest: wenn ich morgen den Provider ersetze, wie viel organisatorische Fähigkeit verliere ich? Er muss aktualisiert werden, denn diese Frage maß, was du mitnimmst. Die neue Frage lautet: was funktioniert noch, nachdem du gegangen bist? Das sind verschiedene Fragen. Du kannst alles exportieren und trotzdem mit einem unbrauchbaren Prozess dastehen.

Der wahre Ausstiegstest eines agentischen Systems ist also verhaltensbasiert. Eine Batterie von Aufgaben, die die reale Arbeit repräsentieren: dieselbe Spezifikation, dieselben Werkzeuge, dasselbe Gedächtnis, dieselben Daten, alternatives Modell. Man beobachtet, was überlebt. Wie stark der Task Success fällt, wie stark das menschliche Rework steigt, welche Aufgabenkategorien aufhören zu funktionieren, welche neuen Failure Modes auftauchen, wie sich die Kosten ändern, wie lange es dauert, das vorige Niveau wiederherzustellen. Das sind weit ehrlichere Wechselmetriken als „die API ist kompatibel“.

Hier wechseln die Evals den Beruf. Normalerweise bauen wir sie, um zu beantworten: welches Modell ist besser? Aber sie beantworten eine politisch interessantere Frage: wie abhängig sind wir von diesem Modell? Besitze ich hundert repräsentative Aufgaben und kann sie gegen mehrere Modelle laufen lassen, besitze ich ein Maß der Ersetzbarkeit. Besitze ich sie nicht, ist die Abhängigkeit unsichtbar: ich weiß, dass das System heute funktioniert, aber ich weiß nicht, welcher Teil dieses Funktionierens meiner Architektur gehört, meinem Kontext, meinen Spezifikationen, und welcher Teil, zufällig, dem Verhalten des aktuellen Modells. Die Evaluation wird zum Nachweis kognitiver Portabilität, zum Äquivalent des Disaster-Recovery-Tests: das Backup zu haben genügt nicht, man muss die Wiederherstellung proben. Ein zweites Modell im Auswahlmenü genügt nicht, man muss die Kontinuität der Funktion proben.

Es gibt auch einen einfachen Weg, den wirklichen Vertrag operativ zu machen, den, den die API nie aufschreibt. Wir haben SLOs für Verfügbarkeit, Latenz, Fehlerraten; ein KI-Workflow kann ihr kognitives Äquivalent haben: Aufgabenakzeptanz über einer Schwelle, kritische Halluzinationen unter einer Schwelle, medianes menschliches Rework unter so vielen Minuten, Kosten pro Aufgabe unter so viel, Latenz unter so viel. Der Begriff muss kein Standard werden. Was zählt, ist die Verschiebung des Gegenstands: der reale Vertrag mit dem Modell ist nicht sein Name, sondern die Mindestleistung, die den Prozess existieren lässt. Erfüllen zwei Modelle diese SLOs, sind sie für diesen Prozess funktional austauschbar, wie verschieden sie innen auch sein mögen. Das ist die wahre Abstraktion. Nicht die API: die Schwelle.

An diesem Punkt erreicht man den Satz, auf den alles zuläuft: das Modell sollte ein Implementierungsdetail der Unternehmens-Capability sein, nicht die Identität der Capability. Nicht „wir haben einen Claude-Prozess“, sondern „wir haben einen Code-Review-Prozess, der heute Claude benutzt, weil es unsere SLOs am besten erfüllt“. Der Unterschied wirkt sprachlich. Er ist Governance.

Echte Redundanz und falsche

Für kritische Datenbanken bauen wir Redundanz ohne Diskussion: Primary, Replica, Failover. Warum finden wir es normal, genau eine kritische kognitive Funktion zu haben? Ein reifer Prozess könnte ein primäres Modell haben, ein sekundäres, das an denselben Evals validiert ist, ein Routing nach Aufgabenkategorie, einen ausdrücklich degradierten Fallback. Nicht um parallel Traffic zu bedienen: um Plan B nicht am Tag des Vorfalls zu entdecken.

Aber auch hier verdient der Einwand Respekt: Multi-Model kann eine falsche Sicherheit sein. „Wir unterstützen OpenAI, Anthropic und Google“ zu sagen heißt nicht, unabhängig zu sein. Wenn der ganze Prozess auf Modell A geschrieben und kalibriert wurde, sind die Provider B und C Adapter, die niemand benutzt: nie getestete Backups. Oder schlimmer: drei Modelle können vom selben Hyperscaler abhängen, vom selben Framework, von derselben Control Plane, und die Redundanz muss entlang der gesamten Kette bewertet werden. Drei Einträge im Modell-Selektor sind keine resiliente Architektur.

Und es gibt eine noch alltäglichere Abhängigkeit, die in keiner Lock-in-Diskussion vorkommt: die Prompts. Riesige Prompts, hyperoptimiert für ein einzelnes Modell. System-Anweisungen, die idiosynkratische Verhaltensweisen ausnutzen. Empirische Hacks, überliefert wie Folklore: „bei Claude funktioniert es nur, wenn du es ihm so sagst“. Dieses Wissen erzeugt einen realen lokalen Vorteil, und es ist anbieterspezifisches Kapital. Im SaaS baute der Anbieter den proprietären Teil, der dich abhängig machte; in der KI baut der Kunde einen Teil seines eigenen Lock-ins selbst, einen Prompt nach dem anderen. Tausende Workarounds, Parser, die auf ein Ausgabeformat eingestellt sind, Tool-Beschreibungen, die auf ein Modell kalibriert sind: eine Kompatibilitätsschicht, die niemand bestellt hat und die den Preis des Ausstiegs erhöht. Das heißt nicht, auf Optimierung zu verzichten. Es heißt, das Domänenwissen, das zu bewahren ist, vom Wissen über das kontingente Verhalten des Modells zu unterscheiden, das als Schuld zu behandeln ist. Anbieterspezifische kognitive Schuld.

Die Disziplin, die daraus folgt, trägt einen Namen, den ich seit einer Weile benutze: Spezifikationen, nicht Prompts. Eine Spezifikation beschreibt, was wahr sein muss, unabhängig vom Ausführenden. Ein Prompt beschreibt, zu oft, wie man einen bestimmten Ausführenden dazu überredet. Je mehr der Prozess auf Requirements, Abnahmekriterien, Invarianten, Tests, Policies und Evidenzen ruht, desto weniger hängt er vom impliziten Verhalten des Modells ab; je mehr er auf Tricks, Tonfall, modellspezifischen Few-Shots und emergenten Strategien ruht, desto mehr lebt die Funktion beim Provider. Spezifikationsgetriebene Entwicklung ist nicht nur ein Weg, Coding Agents besser arbeiten zu lassen: sie ist eine Ausstiegsstrategie.

Der symmetrische Fehler ist allerdings der andere Reflex des Ingenieurs: den gigantischen internen Abstraction Layer zu bauen, der jeden Unterschied zwischen Modellen versteckt. Es ist oft der beste Weg, den Lock-in vom Anbieter ins eigene Framework zu verlegen: eine Schicht, die jedem Feature hinterherläuft, die besten Fähigkeiten auf den kleinsten gemeinsamen Nenner plättet, für immer gewartet werden muss und selbst zur Plattform wird. Die vernünftige Strategie ist minimaler und ähnelt dem Progressive Enhancement des Web: ein portabler Kern aus Spezifikationen, Tool-Verträgen, Evals und Fallbacks, und darüber eine anbieterspezifische Beschleunigungsschicht, die ohne Scham die besten Fähigkeiten des Providers nutzt, Caching, fortgeschrittenes Reasoning, besondere Protokolle. Verschwindet der Provider, verlierst du die Beschleunigung, nicht das System. Die Architektur muss die Modelle nicht ununterscheidbar machen. Sie muss messbar machen, was geschieht, wenn sie aufhören, es zu sein.

Preis, Latenz, Kontinuität

Die Funktion kann unverfügbar werden, ohne zurückgezogen zu werden. Sie kann schlicht aus der Ökonomie des Prozesses fallen. Verkaufe ich einen bearbeiteten Vorgang für einen Euro und ruht der Workflow auf einem Modell, das fünfzehn Cent pro Aufgabe kostet, bricht eine verdreifachte Preisliste keine API: sie bricht die Kalkulation. Dasselbe gilt für die Latenz: ein kundenseitiger Agent, gebaut um neunhundert Millisekunden, stirbt mit einem Ersatz von sechs Sekunden, auch wenn die abstrakte Capability äquivalent ist. Die Portabilität der Funktion ist eine mehrdimensionale Kurve, Qualität, Kosten, Latenz, Zuverlässigkeit, erforderliche menschliche Aufsicht, keine einzelne Zahl. Es ist dasselbe Argument, das ich über die Produktivitätsmetriken gemacht habe: die Ersetzbarkeit zertifiziert sich nicht mit einem öffentlichen Benchmark, sie misst sich an der eigenen Arbeit.

Daraus folgt eine Konsequenz, die das Procurement noch nicht absorbiert hat. In den Vendor Assessments erscheinen OpenAI und Anthropic noch als „KI-Tools“. Aber wenn ein erheblicher Teil des Deliverys von ihrer Verfügbarkeit und ihren Leistungen abhängt, ist die richtige Kategorie kritischer Lieferant, mit allem, was folgt: Vertrag, SLAs, Exit-Plan, Monitoring, Subunternehmer-Analyse, Business Continuity. Sonst landet man im Widerspruch von Unternehmen, die ausgefeilte Bewertungen der Cloud durchführen, die ihre Daten speichert, und keinerlei Bewertung der Gesellschaft, die die Funktion liefert, durch die diese Daten interpretiert werden.

Business Continuity ist tatsächlich das fehlende Wort. Unternehmen bauen Kontinuitätspläne für Rechenzentren, Datenbanken, Konnektivität, Schlüsselpersonen, strategische Lieferanten. Wird eine Unternehmensfunktion schrittweise an ein Modell delegiert, muss sie in dieselbe Überlegung eintreten. Welche Prozesse stehen still, wenn das Modell nicht verfügbar ist, wie lange, mit welchem Fallback, mit welcher akzeptablen degradierten Leistung. Und mit welcher menschlichen Restkompetenz: denn wenn ein Modell eine Funktion fünf Jahre lang ausführt, kann die Organisation die menschliche Fähigkeit verlieren, sie auszuführen, nicht weil sie jemanden entlässt, sondern weil niemand sie mehr ausübt. Der kognitive Lock-in trifft auf das Deskilling, und der Provider wird technisch ersetzbar genau in dem Moment, in dem die Organisation entdeckt, dass sie keine menschliche Basislinie mehr hat, zu der sie zurückkehren könnte.

Es gibt sogar ein Paradox des Erfolgs. Funktioniert der Agent schlecht, überwachen wir ihn, behalten die manuellen Prozeduren, kennen die Alternativen. Funktioniert er jahrelang perfekt, automatisieren wir, beseitigen die Doppelungen, bauen die redundanten Kompetenzen ab, integrieren tief. Je besser er funktioniert, desto teurer wird der Ausstieg. Das ist kein Grund, nicht zu automatisieren: es ist der Grund, die Reversibilität als Betriebskosten zu behandeln, genau wie das Backup. Ein gepflegter zweiter Adapter, aktuelle Evals, eine alternative Pipeline, kultivierte interne Kompetenzen: all das sieht nach Verschwendung aus, bis zu dem Tag, an dem es gebraucht wird. Die Freiheit zu gehen ist eine Option, und Optionen haben eine Prämie. Die erwachsene Wahl ist nicht, sie überall zu zahlen: sie ist zu entscheiden, welche Funktionen sie verdienen. Bei manchen akzeptierst du starke Abhängigkeit, weil der Vorteil enorm ist; bei Commodity-Workflows verlangst du hohe Ersetzbarkeit. Eine ehrliche Klassifikation, portabel, portabel mit Degradierung, providerabhängig, heute unersetzbar, ist mehr wert als jedes Kästchen „vendor-neutral: ja“.

Denn der Punkt ist nicht, einen Single Point of Failure zu haben. Der Punkt ist, nicht zu wissen, dass man einen hat.

Das Kriterium bleibt unseres

Der Weg dieser beiden Essays durchquert vier Objekte. Die Daten, die sich exportieren lassen. Den Zustand, der sich mit Disziplin externalisieren lässt. Die Funktion, die sich nur ersetzen lässt, wenn eine hinreichend äquivalente Alternative existiert. Und schließlich das Kriterium: denn um zu wissen, ob die Alternative hinreichend äquivalent ist, braucht es etwas, das die Organisation notwendigerweise selbst besitzen muss, die operative Definition dessen, was es heißt, dass diese Funktion gut ausgeführt wurde.

Hier hört die Sache auf, technisch zu sein. Besitzt der Provider das Modell, das Gedächtnis, den Benchmark und die Definition des guten Ergebnisses, bist du Kunde eines Dienstes, den du nur durch das beurteilen kannst, was der Dienst selbst dir erzählt. Besitzt du die Spezifikation, die Evals, die Rubriken, die Fehlergrenzen und die Evidenzen, kannst du mehrere Modelle befragen und entscheiden, welches deine Funktion erfüllt. Die Macht verschiebt sich: wer die operative Definition von „gut genug“ besitzt, besitzt die Möglichkeit, den zu ersetzen, der die Arbeit ausführt. Ich habe argumentiert, dass der Burggraben nicht die Daten sind, sondern das Urteil; dies ist sein defensives Korollar. Dasselbe Eval-Korpus, das deine vertikale KI besser macht, ist auch das, was dir erlaubt, sie zu wechseln.

Es ist, was wir mit Menschen tun, im Übrigen. Es gibt Organisationen, in denen ein Mitarbeiter formal ersetzbar ist und praktisch nicht: nicht weil er Dokumente als Geisel hält, sondern weil niemand je formalisiert hat, was seine Leistung gut machte. Wenn er geht, entdeckt das Unternehmen, dass es die Arbeit, die es ihm delegiert hatte, nie definiert hat. Bei Modellen kann dasselbe im industriellen Maßstab geschehen: ein Agent, der „hervorragend funktioniert“, ohne dass jemand genau sagen kann, warum, welche Fehler er nicht macht, gemessen an welchem Vergleich. An dem Tag, an dem er verschwindet, entdeckt man, dass der wahre Lock-in nie beim Provider lag. Er lag in unserer Unfähigkeit, die Arbeit zu beschreiben, die wir ihm anvertraut hatten.

Deshalb würde ich dieses Argument nie in einen Angriff auf die Anbieter verwandeln. Ein Provider hat jedes Recht, ein besseres Modell zu bauen, seine Preisliste zu ändern, Versionen vertragsgemäß zurückzuziehen. Der kognitive Lock-in ist großteils selbst zugefügt: je mehr wir delegieren, ohne Ziele, Kriterien, Grenzen und Evidenzen zu explizieren, desto mehr lebt das, was den Prozess wirksam macht, im privaten Verhalten des Ausführenden. Und die regulatorische Gegenmaßnahme, falls sie eines Tages kommt, wird den neuen Provider nicht zwingen können, wie der alte zu denken: das wäre absurd. Sie kann tun, was der Data Act für die Daten getan hat und was der DMA für die Märkte tut, die Bestreitbarkeit erhalten: Transparenz über Versionen, anständige Deprecation-Fristen, Export des Kontexts, Interoperabilität der Evaluationsartefakte. Nicht die Intelligenz standardisieren. Die Bedingungen standardisieren, die dem Kunden erlauben zu prüfen, ob eine andere Intelligenz für seinen Zweck äquivalent genug ist. Es ist eine sehr europäische Unterscheidung, und sie scheint mir die richtige.

Wir haben zwanzig Jahre gebraucht, um zu verstehen, dass die Cloud nicht portabel war, nur weil wir eine Datenbank exportieren konnten. Dann haben wir entdeckt, dass es nicht genügt, die Dokumente mitzunehmen, wenn man zurücklässt, was das System aus diesen Dokumenten gelernt hat. Jetzt kommt die nächste Stufe: man kann alles mitnehmen, Spezifikationen, Gedächtnis, Anweisungen, Werkzeuge, Evals, jedes Artefakt in unserem Besitz, und trotzdem entdecken, dass der Prozess gelernt hatte, um eine nie formalisierte Eigenschaft herum zu funktionieren: die besondere Art, in der ein bestimmtes Modell diese Artefakte in Urteil und Handlung verwandelte.

Souveränität besteht auf diesem Feld nicht darin, Abhängigkeiten abzulehnen. Sie besteht darin, ihren Preis zu kennen: zu wissen, welcher Teil der Funktion uns gehört und welchen wir mieten, zu wissen, was geschieht, wenn die Miete endet, und die Alternative ausübbar zu halten, nicht theoretisch. Eine reale Option, mit ihren in den letzten neunzig Tagen gelaufenen Evals, kein Eintrag in einem Menü. In der KI könnte die wichtigste Ausstiegsklausel nicht im Vertrag stehen: sie könnte ein Test sein. Ein Satz von Aufgaben, der erlaubt zu sagen: das ist die Arbeit, die wir delegiert hatten, das ist, was wir als korrekt betrachten, das sind die anderen Systeme, die es heute können. Dann kann ein Modell außergewöhnlich sein, ohne unersetzbar zu werden.

Und vielleicht wird die reifste Definition kognitiver Souveränität nicht sein, ein Modell zu besitzen, ein europäisches zu trainieren oder es im eigenen Rechenzentrum zu betreiben. Sie wird etwas viel weniger Spektakuläres sein: die Definition der eigenen Arbeit gut genug zu besitzen, um wechseln zu können, wer sie ausführt. Denn ein Modell wird nicht zum Lock-in, wenn es technisch schwer zu ersetzen ist. Es wird zum Lock-in, wenn die Organisation die Funktion nicht mehr beschreiben kann, die seinen Austausch überleben müsste.

Der Autor

Andrea MargiovanniKI

Ich verfolge das Verhältnis zwischen KI und europäischer Regulierung als politisches Faktum, nicht als technisches Spektakel. Ich arbeite mit Teams, die KI mit AI Act, CRA, NIS2 vereinbar machen müssen, ohne Compliance auf eine Checkliste zu reduzieren.

Zum Weg →