MCP und Enterprise Architecture: Eine souveräne Kontextschicht für KI aufbauen

MCP ist der Port, nicht das Produkt

Das Model Context Protocol (MCP) ist zur Standardmethode geworden, einen KI-Agenten mit einem externen System zu verbinden. Es ist faktisch der USB-Port der KI: eine saubere, strukturierte Schnittstelle, die ein Agent nutzen kann, um Daten zu lesen und auf ihnen zu handeln, die er nicht nativ besitzt. Anbieter überschlagen sich mit der Ankündigung, dass ihr Werkzeug „MCP unterstützt“, und Enterprise-Architecture-Anbieter sind keine Ausnahme.

Hier ist die unbequeme Wahrheit für Käufer: MCP ist eine Commodity. Niemand wählt eine Plattform, weil sie ein Protokoll spricht — man wählt sie wegen dem, was hinter dem Port steckt. In diesem Artikel ist MCP daher nie das Argument. Das Argument ist der Kontext, den das Protokoll freigibt, und ob dieser Kontext aktuell, gouverniert und überhaupt sicher freizugeben ist.

Ardoq und Bizzdesign sagen im Kern: „sprich mit deiner Architektur“. Wir starten bei einer schärferen Frage: Wie lässt man KI über die Architektur schließen, ohne die Kontrolle darüber zu verlieren? Genau dort treffen sich Enterprise Architecture, Regulierung und Souveränität — und das ist das Thema dieses Hubs.

EA als das System of Context des Unternehmens

Zwei Jahrzehnte lang investierten Unternehmen in Systems of Record — Salesforce, SAP, ServiceNow — die autoritativen Speicher dafür, wer der Kunde ist, was verkauft wurde, welches Ticket offen ist. KI-Agenten brauchen nun etwas, wofür diese Systeme nie ausgelegt waren: ein kohärentes, abfragbares Bild davon, wie der gesamte Bestand zusammenpasst. Das ist eine neue Schicht. Wir nennen sie das System of Context.

Enterprise Architecture ist die natürliche Heimat dieser Schicht. Ein EA-Modell kodiert bereits die Geschäftsfähigkeiten, das Anwendungsportfolio, den Technologie-Stack und — entscheidend — die Abhängigkeiten zwischen ihnen. Wenn ein Agent „was bricht, wenn diese Anwendung abgeschaltet wird?“ beantworten muss, liegt die Antwort in keinem einzelnen System of Record; sie liegt in der Architektur. Das System of Context steht neben den Systems of Record, nicht über ihnen.

Diese Umdeutung zählt, weil sie verändert, wofür ein EA-Repository da ist. Es hört auf, ein Dokumentationsarchiv zu sein, das ein paar Architekten konsultieren, und wird zum lebendigen Substrat, über das Agenten schließen. Was die Latte höher legt: ein System of Context ist nur nützlich, wenn es aktuell, gouverniert und vertrauenswürdig ist.

Sechs EA-Fragen, die Agenten in natürlicher Sprache beantworten sollten

Das Versprechen einer agentenbereiten Architektur ist, dass die Fragen, die ein CIO, ein CISO oder ein Auditor tatsächlich stellt, zu Abfragen in natürlicher Sprache gegen das Modell werden — keine wochenlange manuelle Analyse. Sechs wiederkehrende Enterprise-Architecture-Anwendungsfälle bilden sich sauber darauf ab:

• Rationalisierung: „Welche Anwendungen sind über Geschäftsbereiche hinweg redundant oder überlappend, und was würde eine Konsolidierung kosten?“
• Wirkungsanalyse: „Wenn wir dieses Kernsystem stilllegen, welche Fähigkeiten, Integrationen und nachgelagerten Prozesse sind betroffen?“
• Compliance-Dokumentation: „Zeige jede Anwendung, die personenbezogene Daten verarbeitet, und wo diese Daten gehostet sind“ — Nachweis, kein Urteil.
• Risiko und Schwachstellen: „Welche kritischen Geschäftsfunktionen hängen von Komponenten mit bekannten Schwachstellen oder End-of-Support-Status ab?“
• Strategische Ausrichtung: „Welche Initiativen in der Roadmap unterstützen dieses strategische Ziel, und welche Fähigkeiten berühren sie?“
• End-of-Life-Planung: „Welche Technologien erreichen in den nächsten 18 Monaten das End-of-Support, und was hängt von ihnen ab?“

Thin MCP vs native MCP — und warum Tiefe gewinnt

Nicht alle MCP-Integrationen sind gleich. Ein Thin MCP legt das Protokoll um einen bestehenden Such- oder Export-Endpunkt: Der Agent erhält Schlüsselwortzugriff auf Dokumente oder eine flache Objektliste. Es demonstriert gut und ist schnell ausgeliefert. Aber es behandelt das EA-Repository als Texthaufen, nicht als vernetztes Modell.

Ein natives MCP gibt die Architektur so frei, wie sie tatsächlich ist — ein Graph aus Fähigkeiten, Anwendungen, Technologien und den Beziehungen zwischen ihnen —, sodass der Agent Abhängigkeiten durchlaufen kann, statt sie zu erraten. Der Unterschied zeigt sich genau bei den schweren Fragen: Wirkungsanalyse und Rationalisierung brauchen die Beziehungen, nicht nur die Knoten. Bizzdesign hat diese Thin-versus-native-Unterscheidung öffentlich formuliert, und die Unterscheidung ist real.

Unsere Position ist, dass Tiefe notwendig, aber nicht hinreichend ist. Ein natives MCP über einem veralteten oder oberflächlichen Repository ist immer noch wertlos, und ein natives MCP, das sensiblen Kontext exfiltriert, ist für eine regulierte Institution schlimmer als nichts. Die Baureihenfolge zählt: zuerst Kontext, dann regulatorische Intelligenz, dann das Protokoll.

Das Souveränitätsrisiko, das die Etablierten unadressiert lassen

Ardoq (Erster am Markt mit einem allgemein verfügbaren MCP) und Bizzdesign wetteifern darum, „MCP × EA“ und „Context Engineering“ zu besetzen. Beide beruhen auf einer unausgesprochenen Annahme: dass es akzeptabel ist, Claude, ChatGPT, Gemini oder Copilot mit Ihrem EA-Repository zu verbinden. Für regulierte Finanzinstitute ist es das oft nicht.

Bedenken Sie, was eine EA-Karte tatsächlich enthält: ein nahezu vollständiges Inventar Ihrer Systeme, Ihre kritischen Abhängigkeiten, Ihre veralteten und ungepatchten Komponenten, Ihre bekannten Schwachstellen, Ihre sensiblen Datenflüsse und manchmal Ihre Sicherheitsmaßnahmen. Es ist, ganz wörtlich, ein Bauplan dafür, wo die Organisation verwundbar ist. Das an ein US-Cloud-LLM zu senden, ist eine DORA-, CSSF-, DSGVO- und EU-AI-Act-Mine — die sensibelste Beschreibung Ihrer Institution, die in einem einzigen API-Aufruf Ihre Jurisdiktion verlässt.

Niemand besetzt die Souveränitätsseite dieses Gesprächs. Die Etablierten besitzen das „sprich mit deiner Architektur“-Narrativ; die Governance-Frage — sollte dieser Kontext Ihre Kontrolle überhaupt verlassen, und unter welchen Bedingungen — ist der weiße Fleck. Das ist das Gespräch, das wir führen wollen.

Was ein reguliertes Rahmenwerk tatsächlich erfordert

Die meisten MCP-Implementierungen bleiben bei der Berechtigungsbewusstheit stehen: Sie prüfen, wer was abfragen darf. Das ist notwendig, aber unvollständig. Ein Rahmenwerk, das für regulierte Finanzinstitute taugt, muss zwei Dinge zugleich gouvernieren.

Es muss berechtigungsbewusst sein — durchsetzen, dass ein Agent, der für einen bestimmten Nutzer handelt, nur den Kontext erreichen kann, zu dem dieser Nutzer berechtigt ist. Und es muss datenresidenzbewusst sein — gouvernieren, wo die Antwort berechnet wird und wohin die zugrunde liegenden Daten physisch gehen, damit die sensibelste Beschreibung der Institution keine Grenze überschreitet und nicht in einem unkontrollierten Modell landet. Der Markt adressiert meist das Erste und ignoriert das Zweite.

Das meinen wir mit einem datenresidenzbewussten MCP und Sovereign Context Engineering: Context Engineering unter Datenresidenz- und Governance-Beschränkungen, nicht trotz ihnen. Das Ergebnis, das ein CISO und ein Auditor beide wollen, ist dasselbe: KI kann über die Architektur schließen, und die Institution kann beweisen, dass das Schließen nie die Souveränität kompromittierte.

• Berechtigungsbewusst: jede Abfrage respektiert die tatsächlichen Berechtigungen des fragenden Nutzers.
• Datenresidenzbewusst: wohin die Daten gehen, ist gouverniert, nicht nur wer abfragt.
• Auditierbar: jeder Zugriff wird als Nachweis protokolliert, den ein Auditor akzeptiert.
• EU-hostbar: der Kontext kann aus einer Region und Infrastruktur bereitgestellt werden, die Sie kontrollieren.

Wohin ArchiLU steuert (Vision, ehrlich gekennzeichnet)

Wir sind präzise dabei, was existiert und was nicht. ArchiLU liefert heute keinen MCP-Server aus. Ein souveränes, gouverniertes, datenresidenzbewusstes MCP ist die Richtung, auf die wir hinarbeiten — eine Überzeugung darüber, wohin regulierter KI-Kontext gehen muss, kein Feature, das Sie heute Nachmittag einschalten.

Was heute existiert, ist das Fundament, das dieses Ziel glaubwürdig macht: ein vernetztes EA-Modell (Fähigkeiten, Anwendungsportfolio, Abhängigkeiten), EU-Region- oder On-Premise-Hosting unter Ihrer Kontrolle, natives Französisch und Englisch, ein veröffentlichter Preis mit unbegrenzten Nutzern und ein kostenloses EA-Reifegrad-Assessment. Wir bauen zuerst den lebendigen Kontext und die regulatorische Intelligenz, denn ein souveränes MCP ist nur so wertvoll wie der gouvernierte Kontext darunter.

Wenn ein Anbieter Ihnen sagt, sein MCP-Server mache Sie konform, seien Sie skeptisch. Eine Kontextschicht hilft Ihnen, zu dokumentieren und zu belegen — sie ist eine Nachweis- und Dokumentationshilfe, keine rechtliche Konformität und kein Ersatz für Ihr eigenes regulatorisches Urteilsvermögen. Wir halten uns an denselben Maßstab: überzeugen, indem wir ehrlich über die Grenze sind, nicht, indem wir sie verwischen.

Starten Sie bei Ihrer Reife, nicht beim Hype

MCP, Agenten und das System of Context lohnen sich nur als Aufbau auf einer Architektur, die aktuell und vertrauenswürdig ist. Bevor Sie dem Protokoll hinterherjagen, lohnt es zu wissen, wo Ihre Praxis tatsächlich steht — wie aktuell Ihr Repository ist, wie vollständig Ihre Abhängigkeiten sind, wie gouverniert Ihr Zugriff bereits ist.

Das kostenlose EA-Reifegrad-Assessment von ArchiLU bewertet zehn Dimensionen und liefert in etwa zehn Minuten einen priorisierten Aktionsplan. Es ist ein konkreter, hypefreier Weg zu sehen, ob Ihre Architektur bereit ist, ein System of Context zu werden, dem Agenten — und Auditoren — vertrauen können.