Wenn jede Abteilung ihren KI-Piloten skaliert, entstehen die nächsten Insellösungen

Die Frage nach dem Piloten lautet meistens: skalieren oder nicht. Sie unterstellt, dass es um einen Piloten geht. In Unternehmen, die seit zwei Jahren mit KI experimentieren, ist das selten der Fall. Dort laufen mehrere Versuche parallel, angestoßen von verschiedenen Abteilungen, mit verschiedenen Anbietern, zu verschiedenen Zeitpunkten. Jeder einzelne davon kann für sich sinnvoll sein. Die Rechnung kommt später und an anderer Stelle: dann, wenn diese Anwendungen dieselben Daten brauchen, dieselben Stammdaten unterschiedlich schreiben oder einander gegenseitig Ergebnisse liefern sollen.

Dieses Muster ist nicht neu, und es ist auch keine Eigenart von KI.

Was 2014 über Insellösungen zu sagen war

Im April 2014 erschien in der Fachzeitschrift Mobile Business (heute it-zoom) ein Beitrag über den Einsatz mobiler Systeme in der Hafenlogistik. Ich war damals als Geschäftsführer von WEBBYTE SYSTEMS zitiert, einem Anbieter von Logistiksoftware. Es ging um Container, Packschuppen, Seeterminals und Zollabwicklung, also um einen Prozess, an dem mehrere Unternehmen mit eigenen Systemen beteiligt sind.

Zum Ausblick sagte ich damals, die Sendungsstruktur werde sich weiter wandeln und immer kleinteiligere Insellösungen würden dabei eine Rolle spielen, einzelne Prozesse und Anforderungen zu automatisieren. Und weiter: „Diese Lösungen auf einem oder wenigen Standards basierend miteinander harmonisieren zu lassen, darf gerne einer der Trends sein“ (Mobile Business, 03.04.2014).

Zwölf Jahre später lässt sich diese Aussage überprüfen. Das ist der eigentliche Grund, warum ich sie hier zitiere: Eine Prognose, die man selbst formuliert hat, ist ein besserer Prüfstein als eine, die man von anderen übernimmt.

Der Standard ist inzwischen da

Am 25. November 2024 hat Anthropic das Model Context Protocol veröffentlicht. Die Ankündigung beschreibt das Problem in Worten, die 2014 genauso gepasst hätten: Modelle seien von ihren Daten getrennt, gefangen hinter Informationssilos und Altsystemen, und jede neue Datenquelle verlange eine eigene Implementierung. Der Anspruch des Protokolls: fragmentierte Einzelanbindungen durch ein einziges Protokoll ersetzen (Anthropic, 25.11.2024).

Daneben steht das Agent2Agent-Protokoll, das inzwischen unter dem Dach der Linux Foundation entwickelt wird. Nach deren Angaben vom 9. April 2026 unterstützen es über 150 Organisationen, es liegen fünf produktionsreife SDK-Implementierungen vor, und die Linux Foundation bezeichnet A2A ausdrücklich als komplementär zum Model Context Protocol, das dort ebenfalls als Projekt geführt wird. Die Arbeitsteilung: A2A regelt die Verständigung zwischen Agenten über Organisationsgrenzen hinweg, das Model Context Protocol die Anbindung an Werkzeuge und Datenquellen (Linux Foundation, 09.04.2026).

Damit ist eingetreten, was 2014 als wünschenswert beschrieben wurde. Es sind nicht viele Standards geworden, sondern zwei, und sie konkurrieren nicht, sondern teilen sich die Aufgabe. Wer diese Entwicklung als Bestätigung liest, sollte den nächsten Absatz trotzdem lesen.

Warum das eine Investitionsentscheidung noch nicht trägt

Ein Standard hilft einem Geschäftsführer erst dann, wenn er stabil genug ist, um eine Investition darauf zu gründen. Diesen Punkt hat das Model Context Protokoll noch nicht erreicht.

Die Spezifikation vom 28. Juli 2026 beschreibt einen Umbau des Protokolls von einer zustandsbehafteten zu einer zustandslosen Architektur. Sitzungskennungen entfallen, die Autorisierungsverfahren ändern sich, und das Projekt hat mit dieser Version erstmals eine formale Regel für den Auslauf alter Schnittstellen eingeführt: zwölf Monate Übergangsfrist (Model Context Protocol, Spezifikation 2026-07-28).

Das ist eine gute Nachricht und eine schlechte zugleich. Gut, weil ein Übergangsfenster von zwölf Monaten Planbarkeit schafft, wo vorher keine war. Schlecht, weil die Regel gebraucht wird. Ein Protokoll, das innerhalb von rund zwanzig Monaten seine Transportarchitektur austauscht, verlangt von jedem, der darauf aufsetzt, wiederkehrende Anpassungsarbeit. Diese Arbeit steht in keinem Angebot, weil sie zum Zeitpunkt des Angebots noch niemand beziffern kann.

Für die Entscheidung heißt das nicht, auf Standards zu verzichten. Es heißt, den Pflegeaufwand als eigene Position zu führen, statt ihn unter „Integration“ einmalig zu verbuchen.

Was ein Standard ohnehin nicht löst

Zurück in den Hafen. Die technische Frage war 2014 bereits beantwortet, robuste Geräte und Datenfunk gab es. Was den Ablauf trug oder scheitern ließ, war eine andere Frage: Wer meldet die Containernummer, wer prüft die Angabe, wer trägt die Folgen einer falschen Ankunftszeit, und wer pflegt die Stammdaten, auf die sich alle Beteiligten verlassen.

Diese Fragen wandern nicht in ein Protokoll. Sie bleiben im Unternehmen, und sie werden mit jeder zusätzlichen Anwendung schwieriger zu beantworten, weil die Zahl der Übergabepunkte schneller wächst als die Zahl der Systeme. Genau das ist der Unterschied zwischen einem Piloten und einer Systemlandschaft: Der Pilot hat einen Verantwortlichen, die Landschaft hat viele.

Wer im Unternehmen die Aufsicht über ein produktives KI-System trägt, habe ich an anderer Stelle behandelt, ebenso die Frage, wer den wirtschaftlichen Nutzen misst. Beide Fragen stellen sich pro Anwendung neu. Bei fünf Anwendungen mit fünf Zuständigkeiten und fünf Messverfahren ist das keine Verwaltungsaufgabe mehr, sondern eine Architekturfrage.

Was ich vor der zweiten Skalierung prüfen würde

Vor der ersten Skalierung geht es um Vollkosten und Betreiberpflichten. Ab der zweiten kommt etwas hinzu, das sich nur unternehmensweit beantworten lässt:

• Welche KI-Anwendungen laufen bereits? Nicht die genehmigten, sondern die tatsächlich genutzten, einschließlich der Werkzeuge, die einzelne Mitarbeiter auf eigene Faust einsetzen.
• Welche dieser Anwendungen greifen auf dieselben Daten zu? Und welche schreiben zurück?
• Wo entstehen doppelte Wahrheiten? Wenn zwei Systeme denselben Kundenstatus führen, entscheidet später der Zufall, welcher gilt.
• Wer pflegt die Verbindungen, wenn sich ein Protokoll ändert? Diese Rolle muss benannt sein, bevor der erste Übergangszeitraum abläuft.
• Was kostet der Ausstieg aus einer einzelnen Anwendung? Eine Anwendung, die sich nicht mehr herauslösen lässt, ist keine Investition, sondern eine Bindung.

Diese Fragen sind unangenehm, weil sie nicht in das Projekt gehören, das gerade zur Entscheidung ansteht. Sie gehören zur Landschaft, in die es eingefügt wird.

Was offen bleibt

Nach Angaben des Bitkom vom 11. März 2026 nutzen 41 Prozent der Unternehmen in Deutschland Künstliche Intelligenz, gegenüber 17 Prozent ein Jahr zuvor; 66 Prozent der Nutzer wollen den Einsatz weiter ausbauen. Diese Zahlen belegen die Geschwindigkeit der Verbreitung. Sie belegen nicht, wie viele Unternehmen dabei in eine fragmentierte Landschaft laufen, denn zur Frage punktueller oder durchgängiger Nutzung macht die Mitteilung keine Angabe. Wer eine solche Zahl braucht, wird sie im eigenen Haus erheben müssen, und zwar mit der ersten der oben genannten Fragen.

Die Prognose von 2014 hat sich erfüllt. Der Standard kam, sogar in geordneter Aufteilung. Was er nicht mitgebracht hat, ist die Antwort darauf, wer im einzelnen Unternehmen dafür geradesteht, dass die Verbindungen morgen noch halten. Diese Antwort gab es 2014 nicht zu kaufen, und es gibt sie heute nicht zu kaufen.