Model Context Protocol: Der erste Nutzen kommt vor der Konsolidierung, nicht danach
Erst integrieren, dann auswerten. Diese Reihenfolge kostet Jahre und ist der Grund, warum KI-Vorhaben nicht anfangen. Ein Kontextprotokoll dreht sie um. Was dabei entfällt und was ausdrücklich nicht.
Die Reihenfolge stand jahrzehntelang fest. Erst wird integriert, dann wird ausgewertet: erst das Datenlager, dann der Bericht; erst die Schnittstelle, dann der Vorgang über Systemgrenzen hinweg. Wer diese Reihenfolge einhält, hat gute Gründe und wartet Jahre auf den ersten Nutzen. In vielen Häusern ist genau das der Grund, warum KI-Vorhaben nicht anfangen. Es fehlt nicht das Modell. Es fehlt der aufgeräumte Untergrund, den man für unerlässlich hält.
Ein Kontextprotokoll dreht die Reihenfolge um. Die Systeme bleiben, wo sie sind, und werden zur Laufzeit als Kontext erschlossen.
Was sich im Zugriff ändert
Der Unterschied lässt sich ausrechnen. Vier Datenquellen und drei Agenten, die darauf zugreifen sollen, ergeben in der klassischen Bauweise zwölf Verbindungen — jede eigens geschrieben, jede eigens zu pflegen, jede bei jeder Änderung erneut zu prüfen. Über einen gemeinsamen Zugang sind es sieben: vier Quellen, die sich einmal anschließen, und drei Agenten, die einmal andocken.
Die Zahlen wachsen unterschiedlich schnell. Kommt eine fünfte Quelle dazu, entstehen links drei weitere Verbindungen und rechts eine. Das ist der ganze technische Kern, und er ist alt. Ein Vermittler zwischen n und m Beteiligten ersetzt das Produkt durch die Summe. Neu ist nicht die Idee, neu ist, dass daraus ein breit getragener Standard geworden ist.
Der Fall, an dem die Entscheidung fiel
Ein international tätiger Anbieter modularer Raumlösungen steht vor der Ausgangslage vieler gewachsener Unternehmen. Zukäufe haben dezentrale Strukturen und mehrere Systemwelten hinterlassen, die Auftragsstrecke von der Anfrage bis zur Rechnung ist nicht durchgängig, und zwischen Vertrieb und Konstruktion gibt es einen Bruch, an dem Informationen langsamer und unvollständiger ankommen, als sie sollten.
Der naheliegende Schluss wäre, erst aufzuräumen. Ein Vorhaben von Jahren, und in dieser Zeit geschieht nichts, was jemand im Betrieb merkt. Die Architekturentscheidung, die aus einem Managementworkshop hervorging, lautet deshalb anders. Die vorhandenen Systeme werden verbunden, nicht abgelöst. Darauf sitzen spezialisierte Agenten für die , für die Koordination von der Anfrage bis zur Bestellung und für den Dialog mit dem Kunden.
Entscheidend für die Machbarkeit ist ein Satz, der in der Vision ausdrücklich steht. Für den ersten Schritt genügt gezielter Zugriff auf ausgewählte Bestände (den vorhandenen Konfigurator, relevante Konstruktionsunterlagen, vertriebsnahe Wissensbestände). Kein unternehmensweiter Integrationsschritt. Das Führungsteam hat im Anschluss beschlossen, in die Vorbereitung eines Transformationsprogramms einzutreten. Mehr behauptet dieser Fall nicht. Er ist entworfen und beschlossen, nicht in Betrieb.
Was das Protokoll leistet und was es nicht leistet
Es standardisiert den Zugriff. Lesen, Schreiben und Orchestrieren über bestehende Systeme hinweg laufen über eine einheitliche Form. Was dadurch entfällt, ist der Konnektorzoo: für jedes Paar eine eigene Schnittstelle, mit eigenem Lebenszyklus und eigener Fehlerquelle.
Es standardisiert die Bedeutung nicht. Geschäftssemantik, , Verknüpfungen, Historisierung und Datenqualität klärt ein Zugriffsprotokoll nicht. Ein Agent, der ohne eine bedeutungstragende Schicht auf eine Tabelle namens `tbl_po_2024_v3` trifft, rät. Genau dafür gibt es Datenlager, und genau deshalb verschwinden sie nicht.
Es verlagert die Prüfbarkeit, es erledigt sie nicht. Freigaben, Protokollierung und Nachweispflichten wandern in den Laufzeit- und Betriebsfluss. Das ist ein Gewinn, weil sie dort hingehören, aber die Spezifikation sagt selbst, dass sie Sicherheitsprinzipien nicht auf Protokollebene erzwingen kann. Die Autorisierung ist optional; öffentlich erreichbare Server ohne Authentifizierung sind in vierstelliger Zahl gemeldet worden. Wer das Protokoll einsetzt, hat die Frage der Zugriffsrechte damit nicht gelöst, sondern erst gestellt.
Warum die Frage nach dem Standard erledigt ist
Ein häufiges Gegenargument lautet, man warte ab, bis sich ein Standard durchsetzt. Dieses Argument ist verbraucht. Das Protokoll gehört seinem Urheber nicht mehr. Es ist an die Linux Foundation übergeben worden und steht dort zusammen mit einem zweiten Agentenprotokoll unter dem Dach einer eigenen Stiftung mit über Mitgliedern. Auf der obersten Ebene stehen die großen Anbieter von Rechenzentrumsdiensten und Modellen, darunter die großen Anwendungshersteller.
Bemerkenswerter als die Mitgliedschaft ist die Reaktion der Anwendungshersteller. SAP, Salesforce, Microsoft, Oracle, ServiceNow und Workday haben das Protokoll nicht abgewehrt, sondern in ihre eigenen Plattformen und in ihre eigenen Freigabe- und Kontrollschichten eingebaut. Das ist die vernünftige Antwort eines Herstellers, dessen Daten plötzlich von außen erreichbar werden: den Zugang zulassen und die Kontrolle behalten.
Einordnung
Die praktische Folge betrifft nicht die Technik, sondern die Reihenfolge der Investitionen. Solange Integration vor Nutzen kommt, muss ein Unternehmen den gesamten Aufwand vorfinanzieren, bevor irgendetwas sichtbar wird — und genau daran scheitern Architekturvisionen, nicht an ihrem Inhalt, sondern an ihrer Eintrittsschwelle. Kommt der Nutzen zuerst, finanziert der erste Schritt den zweiten.
Das heißt nicht, dass die Aufräumarbeit entfällt. Sie verliert ihren Vorrang. Wer heute eine Datenstrategie beginnt, beginnt sie an der Stelle, an der ein Agent zum ersten Mal raten musste, und weiß damit, wofür er sie macht. Das ist eine andere Ausgangslage als ein Programm, das erst in drei Jahren erklären kann, wozu es gut war.
Fragen zu diesem Beitrag? Schreiben Sie uns über das Kontaktformular.