Der neue Lock-in sitzt im Gedächtnis

Die meisten Unternehmen diskutieren Vendor-Lock-in noch immer so, als lebten wir im Jahr 2018. Dann geht es um APIs, Dateiformate, Export-Funktionen, Kündigungsfristen und die übliche Procurement-Folklore. Alles nicht falsch. Nur unvollständig.

Dieser Text macht drei Dinge.

Er verschiebt die Debatte von Modellen und Schnittstellen auf die eigentliche neue Machtfrage: Wer hält das Gedächtnis eurer Agenten?
Er zeigt, warum diese Frage in Deutschland nicht nur technisch, sondern auch organisatorisch und regulatorisch relevant wird.
Er endet nicht bei Diagnose, sondern bei vier konkreten Fragen, mit denen ihr eure eigene AI-Architektur prüfen könnt.

Wenn ihr ihn bis zum Ende lest, sollt ihr drei Dinge klarer sehen als vorher: warum offene Standards allein nicht reichen, worin sich die nächste AI-Abhängigkeit von klassischem Software-Lock-in unterscheidet und welche Entscheidungen ihr jetzt treffen müsst, bevor aus Bequemlichkeit Infrastruktur wird.

Die eigentliche Frage der nächsten Jahre lautet nicht mehr nur: Können wir unsere Daten mitnehmen?

Sie lautet: Können wir das Gedächtnis unserer Agenten und die Routinen unserer Mitarbeitenden mitnehmen?

Das klingt erst mal abstrakt. Ist es aber nicht. Sobald ein Agent nicht nur auf Zuruf antwortet, sondern über Wochen und Monate in echten Arbeitsabläufen steckt, sammelt sich etwas an. Präferenzen. Freigaben. Ausnahmen. Reihenfolgen. Stille Abkürzungen. Das Wissen, wie euer Team tatsächlich arbeitet, nicht wie es im Prozesshandbuch stehen sollte. Eure AI-Agents lernen. Sie merken sich Prozesse, Ausnahmen und werden in Teilen wie ein Mitarbeiter, der schon einige Monate im Unternehmen ist.

Und genau dort beginnt die neue Form von Lock-in.

Nicht im Modell. Im Gedächtnis.

Die falsche Debatte

Offene Standards wie MCP sind nützlich. Sie standardisieren, wie Agenten mit Tools sprechen. Das ist wichtig. Wer seine Systeme anschließen will, braucht genau solche Protokolle.

Bleib auf dem Laufenden

Erhalte eine Nachricht, wenn ein neuer Essay erscheint. Jederzeit abbestellbar.

Nur wird daraus schnell eine bequeme Selbstberuhigung. Offener Standard, Problem gelöst. Kein Walled Garden. Alles portabel.

Das ist dieselbe Verwechslung, die man in anderen Technologiewellen schon sehen konnte. Ein offenes oder halb-offenes Protokoll verhindert nicht automatisch, dass sich die ökonomische Macht in die Schicht darüber verschiebt. Der Standard darunter kann offen sein, und trotzdem sitzt der eigentliche Sog an der Oberfläche: im Default, im Ökosystem, in der Distribution, in der Gewohnheit.

Das Web ist offen. Die Marktmacht saß trotzdem bei wenigen Browsern, Suchmaschinen und Plattformen. Das US-Justizministerium argumentiert im Google-Verfahren sehr direkt, wie wertvoll voreingestellte Defaults sind und wie selten Nutzer von ihnen wegwechseln. Der Default ist nicht der ganze Markt. Aber er ist oft der Punkt, von dem aus Gewohnheit entsteht.

MCP löst die Frage: Wie kommt ein Agent an ein System heran?

MCP löst nicht die wichtigere Frage: Wem gehört der Kontext, der sich bei dieser Arbeit ansammelt?

Der Stecker ist offen. Die Gewohnheit nicht.

Was diesmal anders ist

Bisheriger Software-Lock-in war schmerzhaft, aber sichtbar. Microsoft hielt eure Dateien. Salesforce hielt eure Kundendaten. Slack hielt eure Kommunikationshistorie. SAP hielt eure Prozesslogik, euer Customizing und große Teile der operativen Wahrheit des Unternehmens. Das war unangenehm zu migrieren, aber immerhin greifbar.

Agentischer Lock-in sitzt tiefer.

Wenn ein System über Monate lernt,

welche Ausnahmen euer Team regelmäßig macht,
wer welche Freigaben wirklich braucht,
welche Formulierungen intern funktionieren,
welche Qualitätsmuster akzeptiert oder verworfen werden,
welche Workflows morgens gut laufen und nachmittags regelmäßig steckenbleiben,

dann speichert es nicht nur Daten. Es speichert eine verhaltensnahe Betriebserfahrung.

Das ist der eigentliche Vermögenswert. Nicht die Datei. Nicht die Nachricht. Nicht der Connector. Sondern das verdichtete Modell davon, wie ihr arbeitet.

Und genau das ist schwer portabel.

Wenn ERP-Systeme Unternehmen an ihre Prozesse gebunden haben, werden Agent-Systeme sie an ihre gelebten Routinen binden. SAP hielt eure Stammdaten. Die nächste Plattform will halten, wie eure Organisation tatsächlich arbeitet.

Warum offene Protokolle nicht reichen

Die faire Gegenposition lautet natürlich: Wenn der Tool-Zugang offen ist und das Memory sauber getrennt gebaut wird, lässt sich diese Abhängigkeit begrenzen.

Das stimmt. Technisch ist das möglich. Microsoft argumentiert inzwischen ziemlich explizit für user-scoped persistent memory, also für ein Gedächtnis, das nicht stillschweigend in der Runtime verschwindet, sondern als eigene, kontrollierbare Schicht behandelt wird. Der interessante Punkt ist nicht nur das Produkt, sondern das Framing: Persistenz ist in Enterprise-Umgebungen eben nicht nur Komfort, sondern eine Frage von Privacy, Data Isolation, Governance und Compliance.

Auch praktisch gibt es Gegenentwürfe. Ideen wie Open Brain beschreiben genau so ein Muster: eigenes Memory, angebunden über MCP, nutzbar aus verschiedenen Clients und Modellen. Die Architekturidee ist sauber. Das Gedächtnis soll reisen können, nicht am Tool kleben.

Das ist die gute Nachricht.

Die schlechte ist: Gute Architektur gewinnt nicht automatisch gegen Bequemlichkeit. Oder Enterprise Procurement.

Denn der Alltag bevorzugt fast immer das polierte System, das einfach da ist. Das Produkt, das Marketplace, Admin-Oberfläche, Standard-Integrationen, Billing, Berechtigungen und Support aus einer Hand liefert. Das Tool, das nicht nur anschlussfähig ist, sondern sich schnell nach Zuhause anfühlt. Oder wie es früher so schön hieß: "Nobody ever got fired for buying IBM."

Und genau deshalb greift die reine Protokoll-Debatte zu kurz. Die entscheidende Ebene ist nicht nur Interoperabilität. Es ist Betriebsnähe.

Alle bauen an derselben Schicht

Anthropic deutet mit Enterprise Agents, Plugins und Marketplace auf eine Welt, in der Claude nicht nur antwortet, sondern in den laufenden Arbeitskontext hineinwächst. Dazu kommt ein wichtiger Detailpunkt: Im Claude Marketplace können Unternehmen vorhandene Anthropic-Commitments auf Partnerlösungen anrechnen. Das ist kein technisches Detail. Das ist Distribution, Procurement und Lock-in-Logik in einem Satz.

OpenAI beschreibt fast spiegelbildlich eine einheitliche Betriebsschicht und eine AI-Superapp für Unternehmen. Microsoft wählt die governance-lastigere Sprache, zielt aber ebenfalls auf die Schicht, in der aus einzelnen Modellaufrufen ein betriebliches System wird.

Die Anbieter konkurrieren damit nicht mehr nur darum, welches Modell etwas besser formuliert oder etwas billiger denkt.

Sie konkurrieren darum, die Betriebsschicht der Wissensarbeit zu werden.

Das ist der strategische Shift.

Das eigentliche Risiko ist betriebliche Amnesie

Für Entscheider liegt das Problem nicht darin, dass ein Wechsel technisch unmöglich wird.

Das Problem ist subtiler. Ein Wechsel kann auf dem Papier möglich und in der Praxis trotzdem unattraktiv sein, weil er betriebliche Amnesie erzeugt.

Stellt euch vor, ihr tauscht nicht nur ein Tool aus, sondern ein System, das inzwischen weiß,

welche Requests euer CFO immer noch einmal sehen will,
welche Kundenfälle sofort eskaliert werden,
welche Tabellen das Controlling vertraut,
welche Formulierungen in Legal rot aufblinken,
welche Ausnahmen im Vertrieb faktisch akzeptiert sind, obwohl sie nie sauber dokumentiert wurden.

All dieses Wissen ist in vielen Organisationen heute schon diffus. Es lebt in Köpfen, Chats, Gewohnheiten und den stillen Rändern von Prozessen. Agenten können diese Schicht zum ersten Mal sammeln, verdichten und im Alltag wirksam machen.

Das macht sie nützlich.

Es macht sie aber auch gefährlich, wenn der Besitz ungeklärt bleibt.

Denn der Verlust bei einem Wechsel ist dann nicht nur Reibung. Er ist der Verlust von angesammelter Betriebsintelligenz.

Man ist zurück bei einem brillanten Fremden.

Die deutsche Version des Problems

Im deutschen Managementdiskurs wird AI-Abhängigkeit gern als Beschaffungs- oder Datenschutzfrage verhandelt. Welcher Anbieter, welcher Serverstandort, welche Klausel, welche Compliance-Schicht?

Alles legitim. Aber für dieses Thema nicht ausreichend.

Die eigentliche deutsche Frage müsste lauten:

Welche Teile unseres agentischen Gedächtnisses dürfen nur gelernt sein, und welche müssen uns als Organisation gehören?

Das ist keine technische Spitzfindigkeit. Es ist Governance.

Wenn Freigabelogiken, Präferenzen und Arbeitsroutinen nur deshalb funktionieren, weil ein Anbieter sie für euch mitführt, dann habt ihr nicht nur Software eingekauft. Dann habt ihr angefangen, Teile eurer Betriebsweise auszulagern.

Für DACH-Unternehmen ist das besonders heikel, weil hier Prozesse, Mitbestimmung, Dokumentation und Verantwortlichkeit ohnehin einen anderen Stellenwert haben als in vielen US-Produktnarrativen. Und diesmal ist das keine diffuse kulturelle Fußnote, sondern bereits im Rechtsrahmen angelegt.

Sobald Agenten nicht nur antworten, sondern Routinen, Freigaben, Bewertungen und implizite Auswahlmuster mitformen, landet das Thema automatisch bei Mitbestimmung, Dokumentation, Zugriffskontrolle, Aufbewahrungsregeln, Löschkonzepten und Protokollierung.

Es gehört auf die Ebene von COO, CIO, General Counsel und Betriebsrat.

Die faire Gegenposition

Man kann diese These auch überziehen. Nicht jeder integrierte Memory-Mechanismus ist automatisch böser Lock-in. Manchmal ist die integrierte Lösung einfach die bessere. Nicht jede Organisation braucht ein separates Gedächtnis-Backbone. Nicht jedes Team will zum Verwalter seiner eigenen Kontext-Infrastruktur werden.

Und es stimmt auch: Offene Standards und portable Memory-Schichten können die härteste Version des Problems entschärfen. Das ist keine bloße Hoffnung. Es ist real baubar.

Gerade deshalb sollte der Text nicht so tun, als sei alles entschieden.

Die stärkere Version der These ist eine andere:

Offene Standards verhindern nicht, dass sich Marktmacht in die Schicht darüber verschiebt.

Das ist der Punkt.

Nicht: Portabilität ist unmöglich.

Sondern: Portabilität allein schützt nicht vor Sog.

Was man jetzt tun sollte

Die naheliegende Management-Reaktion wäre, dieses Thema an die Architektur zu delegieren. Bitte prüfen, wie wir Memory sauber trennen. Bitte Exit-Klauseln ergänzen. Bitte vendor-neutral planen.

Alles richtig. Alles zu wenig.

Sinnvoller wäre ein einfaches Vier-Fragen-Audit:

Welche Routinen in unseren AI-Workflows sind dokumentiert, welche nur gelernt?
Welche Präferenzen und Freigaben liegen heute schon faktisch in einem Tool?
Was könnten wir technisch exportieren, aber operativ trotzdem nicht sofort wiederherstellen?
Wo kaufen wir gerade Bequemlichkeit ein, die morgen zu Betriebsabhängigkeit werden könnte?

Das ist kein Aufruf zur Paranoia. Es ist nur der Versuch, ein neues Infrastrukturproblem rechtzeitig als solches zu sehen.

Denn genau das ist es. Ein Infrastrukturproblem. Nur nicht mehr auf der Ebene von Servern, APIs und Dateiformaten. Sondern auf der Ebene von Gewohnheit, Kontext und organisationalem Gedächtnis.

Die letzte Welle von Plattformmacht kontrollierte Daten, Distribution und Defaults.

Die nächste kontrolliert zusätzlich Erinnerung.

Und dort, wo Agenten nicht nur arbeiten, sondern sich erinnern, beginnt die eigentliche strategische Frage:

Wem gehört das Gedächtnis eurer Organisation, wenn immer mehr Arbeit durch Systeme läuft, die mitlernen?

Vielleicht ist das die nützlichste Formulierung für die nächsten Monate: Prüft nicht nur, welches Modell ihr einkauft. Prüft, wo ihr gerade dabei seid, euer betriebliches Gedächtnis zu parken.

Ein Tool kann man ersetzen.

Ein ausgelagertes Gedächtnis viel schwerer.

Die Denkwerkzeuge zu diesem Text helfen euch, die eigene AI-Betriebsschicht systematisch zu prüfen. Das Memory-Ownership-Audit, der Exit-Cost-Simulator und der Governance-Boundary-Check sind drei Prompts, die ihr direkt auf eure Organisation anwenden könnt. Zu den Denkwerkzeugen

Neue Ausgaben direkt per Mail? Newsletter abonnieren

Navigation