Die KI wechselt jedes Quartal. Deine Verbindungen sollten es nicht.

An einem Dienstag wechselt ein Team von ChatGPT zu Claude. Das Abo dauert dreißig Sekunden. Die Einrichtung dauert drei Wochen.

Nicht weil Claude schwer ist. Weil elf Apps in ChatGPT verbunden waren, jede mit ihrem eigenen OAuth-Grant, ihren eigenen Scopes, ihrem kleinen Stück institutionellem Gedächtnis. Der neue Assistent startet ohne all das. Jemand autorisiert Gmail, Slack, Notion, Stripe und die interne Datenbank neu. Jemand entdeckt, dass der alte Assistent einen breiteren Kalender-Scope hatte, als der neue erlaubt. Jemand fragt, warum die Audit-Spur am Tag des Wechsels eine Lücke hat, und niemand hat eine gute Antwort.

Die Rechnung für das Modell ist sichtbar. Die Rechnung für den Wechsel ist es nicht, und sie ist meistens größer.

Ich habe Vinkius gegründet, und das ist das Muster, das ich in fast jedem Team sehe, das KI ernsthaft nutzt. Der Assistent wird als der Ort behandelt, an dem Arbeit passiert, also werden die Verbindungen dort gebaut. Aber der Assistent ist die am wenigsten haltbare Schicht im Stack. Modelle wechseln jedes Quartal. Clients ändern ihr Connector-Modell, ihren Einstellungsbildschirm, ihren Preis. Die Apps, die du verbindest, sind der stabile Teil. Die Beziehung zwischen deinen Leuten und diesen Apps ist das Asset.

Der Fehler ist architektonisch, nicht taktisch. Wir haben den Tool-Call mit MCP standardisiert und dann jeden Client die Verbindung besitzen lassen, die ihn erzeugt. Das Ergebnis ist eine Verbindungsschicht, die pro Assistent, pro Nutzer, pro Gerät dupliziert und als ein System nicht auditierbar ist.

KI zu wechseln sollte ein Einfügen sein, keine Migration.

Die Rechnung, die du nicht siehst

Jeder Wechsel hat sichtbare und versteckte Kosten. Sichtbar sind Abo, Sitzplätze, die Migrations-E-Mail. Versteckt ist die Arbeit, die Beziehung zwischen deinem Team und seinen Apps neu aufzubauen, einen Consent-Screen nach dem anderen.

Was ein Wechsel wirklich kostet	Was passiert	Warum es sich summiert
Re-Authentifizierung	Jede App fragt erneut nach Zustimmung, pro Client	Jeder Grant erzeugt einen neuen Token mit eigenem Ablauf und Scope
Rechte-Drift	Der neue Client zeigt ein anderes Berechtigungsmodell	Die Richtlinie lebt in der UI und wird von Hand neu gebaut
Audit-Lücke	Die Logs bleiben beim alten Anbieter	Es gibt keine gemeinsame Zeitachse über den Wechsel hinweg
Integrations-Neubau	Jeder Client hat sein eigenes Connector-Format	Die Arbeit wiederholt sich für jede App und jeden Client
Identitätsverwirrung	Private und berufliche Konten verschwimmen	Das falsche Konto kann mit der richtigen Absicht handeln
Kontextverlust	Prompts, Favoriten und Routinen bleiben zurück	Der Assistent vergisst, wie dein Team arbeitet

Nichts davon taucht in einem Benchmark auf. Alles davon taucht im ersten Monat auf.

Drei Schichten von Lock-in

Modell-Lock-in ist der, über den alle reden. Er ist real, aber er hat einen Preis. Du kannst ihn messen, verhandeln, mit einem zweiten Anbieter umgehen, und der Markt drückt den Preis weiter nach unten.

Client-Lock-in ist der, den alle fühlen. Es ist die Gewohnheit, der Tastatur-Shortcut, die Team-Konvention, das Projekt, das schon in einer Seitenleiste lebt. Auch er ist real, aber er ist vor allem ein UX-Problem, und UX-Probleme werden gern im nächsten Release gelöst.

Verbindungs-Lock-in ist der, den niemand benennt. Es sind die Kosten, die Beziehung zwischen deinen Leuten und ihren Apps jedes Mal neu aufzubauen, wenn sich die Oberfläche ändert. Er steht in keinem Vertrag. Er zeigt sich als drei Wochen Einrichtung und eine Lücke in der Audit-Spur.

Zeichne die Matrix. Fünf Assistenten oben, zwölf Apps an der Seite. Sechzig Zellen. Jede Zelle braucht einen Auth-Flow, ein Credential, einen Scope, eine Richtlinie und eine Log-Zeile. Füge jetzt einen zweiten Nutzer, ein zweites Gerät, ein zweites Agent-Framework hinzu. Die Matrix multipliziert sich, und jede Zelle wird von jemandem gepflegt, der sie nicht gebaut hat.

Eine Konnektivitätsschicht kollabiert die Matrix. Die Apps werden einmal verbunden. Jeder Client bekommt einen Link. Richtlinie und Aufzeichnung leben in der Schicht, nicht in der Zelle.

Was bricht, wenn die Verbindung im Client lebt

Das Credential erbt die Sicherheitslage des Clients. Der schnellste Weg, eine App mit einem Assistenten zu verbinden, ist, einen Token in seine Konfiguration zu kleben. Jetzt liegt der Token im Speicher des Clients, in seinen Logs, unter seiner Aufbewahrungsrichtlinie und im Kontextfenster eines Modells, das du nicht kontrollierst. Eine Verbindung, die im Client lebt, erbt die Sicherheitslage des Clients, und das ist kein Satz, den ein Sicherheitsteam unterschreiben will.

Das Berechtigungsmodell wird von Hand neu gebaut. Jeder Client hat seine eigene Vorstellung davon, was ein Connector tun darf. Eine Berechtigung, die in einem Assistenten existiert, muss im nächsten nicht existieren, und die am Montag sorgfältig gescopte Richtlinie wird am Mittwoch aus dem Gedächtnis neu gebaut. Der Drift ist unsichtbar, bis eine Aktion, die hätte blockiert werden müssen, gelingt.

Die Audit-Spur bricht am Wechsel. Wenn der Client den Call macht, macht der Client die Aufzeichnung. Wechsle den Client, und die Zeitachse teilt sich in zwei. Die Frage nach einem Incident ist nicht „was hat das Modell gesagt“, sondern „wer hat diese Aktion autorisiert, für welches Konto, zu welcher Zeit“. Ein Log pro Client beantwortet das nicht über Clients hinweg.

Die Wartung endet nie. Jeder Client liefert ein neues Connector-Format, einen neuen Einstellungsbildschirm, ein neues JSON. Jede App ändert ihre API, ihre Scopes, ihren OAuth-Flow. Die Integrationsarbeit verschwindet nicht, wenn du zu einem managed Connector wechselst. Sie wandert zu dem, der den Connector pflegt, und wenn das du bist, kommt sie jedes Quartal zurück.

Die Identität wird geteilt. Ein Link, der in einen Team-Kanal geklebt wird, ist eine geteilte Identität. Ein Token, der in ein Repository committet wird, ist eine geteilte Identität. Eine Verbindung, die einer Person gehören sollte, gehört jetzt allen, die den Kanal lesen können. Die Verbindung muss an eine Person gebunden sein, nicht an ein Chat-Fenster.

Portabilität ist Architektur, kein Export-Button

Das Wort Portabilität bedeutet meistens einen Button, der deine Daten exportiert. Das reicht nicht. Eine CSV deiner Verbindungen re-authentifiziert sie nicht, trägt keine Berechtigungen, bewahrt die Audit-Spur nicht und macht den nächsten Client nicht funktionsfähig. Portabilität ist eine Eigenschaft des Pfades, nicht einer Datei.

Eine Verbindung ist portabel, wenn sie acht Anforderungen erfüllt:

Anforderung	Was sie in der Praxis bedeutet
Stabiler Endpoint	Eine URL pro Nutzer, die sich nicht ändert, wenn der Client sich ändert
An Identität gebunden	Der Endpoint trägt die Person, nicht das Chat-Fenster oder das Gerät
Offenes Protokoll	Die Grenze spricht MCP, also kann jeder kompatible Client andocken
Externe Credentials	Secrets leben in einem Vault, nie im Client oder im Modellkontext
Externe Richtlinie	Autorisierung wird pro Aktion ausgewertet, außerhalb der Client-UI
Externes Audit	Jeder Call wird in der Schicht aufgezeichnet, auf einer Zeitachse
Widerrufbarer Token	Der Link kann widerrufen und neu ausgestellt werden, ohne die Apps neu zu bauen
Gleiche Fähigkeiten überall	Chat, IDE, Terminal und deine eigenen Agenten sehen denselben Katalog

Wenn eine Verbindung stirbt, sobald der Client deinstalliert wird, war sie nie deine.

Wie ein Link das macht

Die Einheit ist ein Connector-Link, eine URL der Form https://edge.vinkius.com/vk_YOUR_TOKEN/mcp. Er trägt deine Identität in die Schicht. Du klebst ihn in ChatGPT, Claude, Gemini, Copilot, Perplexity, Grok, DeepSeek, Cursor, VS Code, Windsurf, JetBrains, Claude Code, Cline, Lovable, Antigravity, OpenClaw/ClawX, Goose, Claude Desktop oder jeden MCP-kompatiblen Client. Für Agenten, die du baust, kommen dieselben Fähigkeiten über das AI Connect SDK, mit Adaptern für Vercel AI SDK, OpenAI Agents, Anthropic, Google ADK, LangChain, CrewAI, Semantic Kernel und AutoGen.

Ein Link, eine Identität, jeder Client.

Der Katalog ist just-in-time. Das Modell muss keine 9.268 Connector-Namen lernen. Es sucht nach der Aufgabe, prüft die Fähigkeiten, verbindet und führt aus. Heute trägt der Katalog 9.268 managed Connectors und 63.133 Fähigkeiten, und die Zahl bewegt sich, während der Katalog synchronisiert.

Die App-Credentials sind nicht im Client. Sie sind at rest verschlüsselt und gehen nie an das Modell zurück. Die Richtlinie wird pro Aktion ausgewertet. Die Audit-Spur wird in der Schicht geschrieben, also überlebt sie den Wechsel. Der Link ist ein Bearer-Token: behandle ihn wie einen Schlüssel, halte ihn aus Repositories heraus und widerrufe ihn im Console, wenn er leakt. Ein neuer Token ist in Sekunden ausgestellt, und der alte funktioniert nicht mehr.

Derselbe Link funktioniert in einer IDE oder einem Desktop-Client. Claude Desktop liest ihn aus seiner Konfigurationsdatei:

{
  "mcpServers": {
    "vinkius-ai-connections": {
      "url": "https://edge.vinkius.com/vk_YOUR_TOKEN/mcp"
    }
  }
}

Der Client ändert sich. Die Konfiguration ändert sich. Der Link nicht.

Eine Migration für diese Woche

Inventarisiere die Verbindungen. Liste die Apps, den Besitzer jedes Kontos, die genutzten Scopes und den letzten Aufruf. Fang nicht mit den einfachen Apps an. Fang mit denen an, die wehtun würden, wenn sie mit dem falschen Konto verbunden wären.

Verbinde einmal in der Schicht. Autorisiere jede App einmal, an einer Stelle. Die Arbeit ist pro App, nicht pro App pro Client. Das ist der ganze Unterschied zwischen einer Matrix und einer Liste.

Klebe den Link in einen zweiten Client und führe drei echte Aufgaben aus. Ein Read, ein Write und eine, die blockiert werden sollte. Der dritte Test ist der wichtige. Portabilität ohne ein Nein ist nur Bequemlichkeit.

Verschiebe die Richtlinie in die Schicht. Freigabe pro Aktion für destruktive Operationen, DLP-Muster für PII und Finanzfelder, ein Ausgaben-Limit und ein Schalter, der alle Agenten stoppt. Die Richtlinie gilt für alle Clients gleichzeitig, weil sie in keinem von ihnen lebt.

Rente die alten Tokens pro Client aus. Die Migration ist nicht fertig, wenn der neue Client funktioniert. Sie ist fertig, wenn der alte Pfad geschlossen ist. Widerrufe die Tokens, die in Client-Konfigurationen geklebt wurden, und prüfe, ob noch etwas von ihnen abhängt.

Dokumentiere Besitzer und Rotation. Ein Bearer-Token ohne Besitzer ist ein Incident, der auf ein Datum wartet. Stelle den Link unter dieselbe Disziplin wie jedes andere Produktions-Secret.

Der Lock-in-Einwand

Jede Architekturdiskussion kommt irgendwann zu dieser Frage: Ersetzt du nicht einfach ein Lock-in durch ein anderes?

Es ist eine faire Frage, und die Antwort ist eine Unterscheidung. Lock-in als Geisel bedeutet, dass Weggehen dich die Fähigkeit kostet zu arbeiten. Lock-in durch Wert bedeutet, dass Weggehen dich ein besseres Produkt kostet, aber du kannst noch arbeiten. Das erste ist eine Falle. Das zweite ist eine Wahl.

Eine Konnektivitätsschicht sollte den Ausstieg absichtlich billig machen. Das Protokoll ist offen. Der Link gehört dir. Der Token kann widerrufen und neu ausgestellt werden. Die Verbindungen liegen nicht in einem Client, der sie deprecaten kann. Wenn die Schicht morgen verschwände, würdest du Bequemlichkeit verlieren, nicht deine Apps oder deine Konten. Das ist der Maßstab, an dem ich mich messen lassen will.

Portabilität ist kein Feature, das man am Ende hinzufügt. Sie ist der Grund, warum die Schicht existiert.

Sicherheit ist die Voraussetzung

Ein Link, der jede App erreicht, ist ein Generalschlüssel, und ein Generalschlüssel ohne Kontrolle ist schlimmer als zehn verstreute Tokens. Portabilität und Governance sind dasselbe Design: Beide verlangen, dass die Verbindung auf einem Pfad lebt, den du kontrollierst.

Die Kontrollen sind keine optionalen Extras. Sie machen den Link sicher genug, um ihn zu tragen:

• Autorisierung pro Aktion, ausgewertet bevor der Call rausgeht, statt eines breiten Token-Scopes.
• Credential-Isolation, mit at rest verschlüsselten Secrets, per Signatur authentifiziert und nie im Modellpfad platziert.
• DLP-Muster, die im Speicher abgeglichen werden, bevor die Antwort das Modell erreicht.
• Eine manipulationssichere Audit-Spur, in der jeder Datensatz mit dem vorherigen verkettet und signiert ist.
• Ausgaben-Limits und ein Circuit Breaker, der eine Schleife stoppt, bevor es die Rechnung tut.
• Ein Notfallschalter, der jeden Connector deaktiviert, jeden Token widerruft und jede Session beendet.

Weil die Kontrollen in der Schicht leben, gelten sie für alle Clients gleichzeitig. Das ist der zweite Nutzen der Portabilität: Du korrigierst eine Richtlinie einmal, und sie hält in ChatGPT, Claude, Cursor und dem Agenten, den du nächsten Monat deployst.

Das längere Argument für jede Kontrolle steht in Die Control Plane des Agent-Zeitalters und KI-Governance.

Häufige Fragen

Verliere ich beim Client-Wechsel meinen Chat-Verlauf? Der Chat-Verlauf gehört dem Client und bleibt dort. Was dir folgt, ist die Verbindung: die Apps, die Credentials, die Berechtigungen und die Ausführungsaufzeichnung. Das sind verschiedene Assets, und nur eines davon sollte an den Assistenten gebunden sein.

Unterstützen das alle KI-Clients? Jeder MCP-kompatible Client kann den Link einfügen. Heute sind mehr als 20 Clients abgedeckt, darunter die großen Chat-Apps, IDEs und Coding-Agenten. Für Clients ohne MCP oder für deine eigenen Agenten stellt das AI Connect SDK dieselben Fähigkeiten über Framework-Adapter bereit.

Ist ein Link sicher? Es ist ein Bearer-Token, also nur so sicher wie sein Umgang. Halte ihn aus der Versionskontrolle, binde ihn an eine Identität, widerrufe ihn bei einem Leak und rotiere ihn regelmäßig. Die Schicht erzwingt die Richtlinie pro Aktion auch bei gültigem Link, ein geleakter Link bedeutet also nicht automatisch freie Hand.

Können zwei Clients denselben Link gleichzeitig nutzen? Ja. Jeder Call wird derselben Identität zugeordnet und in derselben Spur aufgezeichnet. Wenn du getrennte Identitäten brauchst, stelle getrennte Links aus.

Und meine eigenen Agenten? Derselbe Katalog ist über das SDK verfügbar, mit Connectors und Credentials pro Nutzer. Die Modell-Runtime ändert sich; die Verbindung nicht.

Gilt das nur für MCP? MCP ist die Grenze, auf die wir standardisieren, weil sie der breiteste Stecker ist. Die Schicht selbst ist protokollagnostisch, und die SDK-Adapter decken Frameworks ab, die nicht direkt MCP sprechen.

Der Assistent ist ein Tab

Der Assistent ist ein Tab. Das Modell ist eine Versionsnummer. Die Verbindung ist die Arbeit.

Modelle werden sich weiter ändern. Clients werden weiter neue Einstellungsbildschirme ausliefern. Die Apps, auf denen dein Team läuft, bleiben ungefähr dieselben, und die Beziehung zwischen deinen Leuten und diesen Apps sollte nicht jedes Mal neu gebaut werden, wenn es die Oberfläche tut.

Richte es einmal ein. Klebe denselben Link in die nächste KI, die du nutzt. Wechsle die KI. Behalte die Verbindungen.