MCP
Model Context Protocol: standardisierte Werkzeug-Bindung für KI in regulierten Häusern.
Eine offene JSON-RPC-Schicht, die maßkonfektionierte Integrationen durch ein einheitliches Wire-Format ersetzt und jeden Tool-Aufruf zu einer Audit-Zeile macht.
DORA Art. 28-30 · EU AI Act Anhang IV s.6
5 Min. Lesezeit
Was es tatsächlich ist
Das Model Context Protocol ist eine offene JSON-RPC-2.0-Spezifikation, die Ende 2024 von Anthropic veröffentlicht und inzwischen als offener Standard gepflegt wird. Es definiert, wie eine Host-Anwendung, die ein Sprachmodell nutzt, sich mit externen Kontextanbietern verbindet - Datenquellen, internen APIs, Dokumentenspeichern, Pricing-Engines - über ein einheitliches Wire-Format anstatt durch maßkonfektionierten Integrationscode. Es ist das LLM-Aequivalent zu Microsofts Language Server Protocol, das die Verdrahtung zwischen IDEs und Sprachwerkzeugen standardisierte und ein N-mal-M-Integrationsproblem auf N-plus-M reduzierte.
Es gibt drei Akteure. Der Host ist die Anwendung, der der Nutzer vertraut - in unserem Fall die Alpha-Quant-Agent-Runtime. Innerhalb des Hosts verhandelt jeweils ein Client pro Datenquelle mit einem externen Server. Jeder Server stellt drei Kategorien von Capabilities bereit: Resources (lesbare Daten wie ein Dokument, eine Datenbankzeile, ein Pricing-Snapshot), Prompts (parametrisierte Workflow-Vorlagen, die der Nutzer aufrufen kann) und Tools (aufrufbare Funktionen mit einem JSON-Schema-Eingabevertrag und strukturierter Ausgabe). Der Host meldet seine eigenen clientseitigen Capabilities zurück an den Server: Sampling (der Server kann den Host bitten, eine Modell-Completion auszuführen), Roots (welche Dateisystem-URIs der Server sehen darf) und Elicitation (der Server kann den Nutzer über den Host nach einer Rückfrage fragen).
Die Capability-Negotiation findet zum Verbindungszeitpunkt statt. Der Transport ist JSON-RPC 2.0 über stdio für lokale Prozesse und Streamable HTTP mit Server-Sent Events für entfernte. Das Sprachmodell selbst spricht MCP nie - der Host tut es, im Namen des Modells, und leitet nur gefilterte Tool-Beschreibungen und Tool-Ergebnisse weiter.
Warum das in Ihrem Haus zählt
Jedes KI-Integrationsprojekt in einer Vermögensverwaltung stößt an dieselbe Wand: die Konnektoren. Verwahrstellen-Portal, Fondsadministrator-Extrakt, interne Pricing-Engine, Depotbank-Feed, Dokumentenspeicher, Risk-Grid, OMS - jeder davon ist ein eigenes Ticket, ein eigener Auth-Flow, ein eigener Wartungsvertrag, eine eigene Prüfer-Frage. Die Konnektor-Schicht verschlingt typischerweise mehr Budget als das Modell selbst, und verrottet schneller.
MCP löst das auf, indem es jeder Datenquelle einen einheitlichen Vertrag gibt: tools/list zum Entdecken des Verfügbaren, resources/read zum Abrufen von Daten, tools/call zum Ausführen einer Aktion - alles in JSON-RPC-Umschlägen, die der Host Byte für Byte mitprotokollieren kann. Der Pricing-Engine-Konnektor und der Prospekt-Store-Konnektor sehen auf dem Wire jetzt gleich aus, was bedeutet, dass sie auf dieselbe Weise geprüft, auf dieselbe Weise überwacht und auf dieselbe Weise ersetzt werden können.
Für den Käufer übersetzt sich das in drei konkrete Ergebnisse: weniger maßkonfektionierter Konnektor-Code in der Codebasis, ein einheitliches Prüfmuster für das Compliance-Team und eine strukturierte Audit-Zeile für jeden Lesezugriff und jede Aktion, die die KI jemals gegen ein internes System ausführt.
Der regulatorische Anker
DORA Art. 28-30 verlangt von Häusern, ein IKT-Drittanbieter-Register zu führen, die durch jeden Anbieter unterstützten operativen Aufgaben zu dokumentieren und das Konzentrationsrisiko-Management nachzuweisen. EU AI Act Anhang IV Abschnitt 6 verlangt, dass die Technische Dokumentation die Lebenszyklus-Änderungen eines hochriskanten KI-Systems festhält, einschließlich Änderungen an den Werkzeugen und Datenquellen, auf die es sich stützt.
Ein MCP-Host, der jeden JSON-RPC-Aufruf protokolliert - Methode, Server, Payload-Hash, Ergebnis, Zeitstempel - erzeugt genau das Artefakt, nach dem diese Artikel verlangen. Das Drittanbieter-Register wird zur Liste der MCP-Server. Das Lebenszyklus-Log wird zum Protokoll der Capability-Negotiations und Tool-Registrierungen. Kombiniert mit einem im Perimeter ansässigen Host und lokaler Inferenz verlässt kein MCP-Aufruf das Haus ohne strukturierte Audit-Zeile, und DORA-Konformität ist eine Eigenschaft des Wire-Formats, nicht eines Quartalsberichts.
Wie wir es bauen
Wir stellen jedes interne System als Single-Purpose-MCP-Server bereit. Ein Server für die Pricing-Engine. Einer für den Prospekt-Store. Einer für das Risk-Grid. Einer für die OMS-Read-View. Jeder läuft als Prozess, den das Haus selbst betreibt - ein Container in der Tenancy des Hauses, kein gehosteter Endpunkt bei einem Anbieter - und jeder deklariert seine Resources, Prompts und Tools über ein JSON-Schema, das wir versionieren und neben dem Rest der Codebasis ins Repository einchecken.
Der Host ist die Alpha-Quant-Agent-Runtime, je Mandant konfiguriert. Die Capability-Negotiation wird zum Verbindungszeitpunkt festgezurrt, sodass dem Modell nie Tools angeboten werden, die das Haus nicht freigegeben hat. User-Consent wird durchgesetzt, bevor ein tools/call gegen eine schreibfähige Resource ausgeführt wird; bei reinen Lese-Resources protokolliert der Host den Aufruf trotzdem, blockiert ihn aber nicht. Das strukturierte Audit-Log ist die Quelle der Wahrheit - Methode, Server, Schema-Hash, Request-Payload-Hash, Response-Payload-Hash, Modellversion, Nutzer-ID, Zeitstempel - und speist die bestehenden SIEM- und Audit-Werkzeuge des Hauses.
Weil MCP ein offenes Protokoll ist, verlangen wir vom Haus keine Wette auf die Konnektor-Bibliothek eines einzelnen Anbieters. Dieselben Server-Verträge funktionieren mit jedem konformen Host - was unter DORA Art. 28 (Exit und Substituierbarkeit) und unter jeder internen Modellrisiko-Richtlinie zählt, die komponentenweise Ersetzbarkeit verlangt.
Wo das Sprachmodell überhaupt beteiligt ist - bei der Auswahl eines Tools, beim Parsen einer Antwort, beim Entwerfen einer Rückfrage - läuft es über lokale Inferenz im Perimeter, sodass der KI-Methoden-Fußabdruck innerhalb derselben Grenze bleibt wie die Daten.
Was Sie NICHT tun sollten
Zeichnen Sie MCP nicht als 'das LLM verbindet sich direkt mit Ihren Daten'. Das Modell spricht das Protokoll nie. Der Host tut es, und der Host ist der Ort, an dem die Consent- und Audit-Mechanismen leben. Ein Anbieter-Diagramm, das den Host versteckt, versteckt das Sicherheitsmodell.
Lassen Sie keinen Dritten den Host für Sie auf gemeinsam genutzter Infrastruktur betreiben. Der Host ist der Vertrauensanker. Ihn an eine Vendor-SaaS auszulagern, führt das Konzentrationsrisiko wieder ein, das MCP eigentlich auflösen sollte.
Überspringen Sie nicht die Capability-Negotiation. Ein 'Wildcard'-Server, der jedem Client jedes Tool anbietet, gibt dem Modell eine Angriffsfläche, deren Begrenzung Sie nicht beweisen können; die Aufsicht liest das als unzureichende Änderungskontrolle.
Behandeln Sie das Audit-Log nicht als optionale Metadaten. Das Log ist das Lieferergebnis. Wenn ein Tool-Aufruf keine strukturierte Zeile erzeugt hat, hat er in einem regulierten Umfeld nicht stattgefunden.