MCP für Enterprise Architecture: 6 Anwendungsfälle, die KI-Agenten freischalten

Von einer statischen Karte zu einem System of Context

Die meisten Enterprise-Architecture-Repositories werden von Menschen gelesen, langsam, ein Diagramm nach dem anderen. Die Verschiebung im Gange ist nicht, dass jemand ein Protokoll namens MCP hinzugefügt hat — MCP ist Klempnerei, der USB-Port der KI, und niemand kauft ein Produkt, weil es das spricht. Die Verschiebung ist, dass das EA-Modell zu einem System of Context werden kann: eine gouvernierte Schicht, die KI-Agenten direkt abfragen, neben den Systems of Record wie Ihrem CRM, ERP und Servicekatalog.

Wenn das geschieht, ersetzt eine Frage in natürlicher Sprache eine Woche des Querverweisens von Tabellen. Die sechs Anwendungsfälle unten sind diejenigen, die für ein reguliertes Unternehmen am meisten zählen. Für jeden geben wir die Frage, die Sie tatsächlich stellen würden, was die Antwort freischaltet und — ebenso wichtig — die ehrliche Grenze dessen, was ein Agent tun kann. Durchgängig gilt ein Prinzip: Der Wert ist nicht das Protokoll, es ist die Qualität, Aktualität und Governance des Kontexts, über den der Agent schließt.

1. Anwendungsrationalisierung — die Überlappung finden und begründen

Die Abfrage: „Wo haben wir überlappende Anwendungen, und welche sollten wir warum stilllegen?“ Ein Agent durchläuft die Fähigkeitskarte, findet die Fähigkeiten, die von mehr als einer Anwendung bedient werden, und gleicht Kosten, Eigentümerschaft, Nutzerzahl und Lebenszyklus ab, um Stilllegungskandidaten mit Begründung vorzuschlagen.

Was sie freischaltet: eine verteidigbare Shortlist statt eines politischen Streits. Rationalisierung stockt meist, weil niemand die Überlappung schnell beweisen kann; ein Agent, der über ein lebendiges Portfolio schließt, bringt sie in einem Satz zutage und zeigt die Abhängigkeiten, die Sie zuerst entwirren müssten.

Die ehrliche Grenze: Der Agent reiht und erklärt, er entscheidet nicht. Ob ein Duplikat echte Verschwendung oder eine bewusste Redundanz für Resilienz ist, ist ein menschliches Urteil, und die Shortlist ist nur so vertrauenswürdig wie die Kosten- und Nutzungsattribute im Modell.

2. Wirkungsanalyse — wissen, was bricht, bevor Sie es anfassen

Die Abfrage: „Was sind die nachgelagerten Effekte einer CRM-Migration?“ Der Agent durchläuft den Abhängigkeitsgraphen vom CRM nach außen — Integrationen, Datenflüsse, die Geschäftsfähigkeiten und Prozesse, die es konsumieren — und liefert den Wirkungsradius als gereihte Liste statt eines Diagramms, das Sie von Hand entschlüsseln müssen.

Was sie freischaltet: Änderungsplanung, die bei Evidenz beginnt. Migrations- und Stilllegungsrisiko lebt in den Abhängigkeiten zweiter und dritter Ordnung, an die sich niemand erinnert; ein Agent, der über den Graphen schließt, macht sie vor der Change-Board-Sitzung explizit, nicht während der Incident-Review.

Die ehrliche Grenze: Er kann nur Abhängigkeiten verfolgen, die modelliert sind. Eine undokumentierte Integration oder ein Schatten-IT-Konsument ist für den Agenten unsichtbar. Wirkungsanalyse ist ein Kraftmultiplikator auf einem vollständigen Graphen und ein falscher Trost auf einem dünnen.

3. Compliance-Reporting — die Regulierung schneller abgrenzen

Die Abfrage: „Welche Systeme fallen in den DORA-Geltungsbereich?“ Der Agent identifiziert die Anwendungen und Infrastruktur, die Ihre kritischen und wichtigen Funktionen stützen, bringt die Drittanbieter dahinter ans Licht und stellt eine Erstentwurf-Scope-Liste mit den angehängten Abhängigkeitsnachweisen zusammen.

Was sie freischaltet: der mühsame, fehleranfällige Abgrenzungsdurchlauf wird in Minuten zu einem Entwurf und überlässt Ihrem Team die Urteilsarbeit — bestätigen, welche Funktionen wirklich kritisch sind, wo die Grenzen liegen, welche Nachweise ein Regulator akzeptiert.

Die ehrliche Grenze, klar gesagt: Dies ist eine Dokumentations- und Nachweishilfe, kein Konformitätsurteil. Ein Agent hilft Ihnen, zu dokumentieren und zu belegen; er macht Sie nicht konform. Die Interpretation der DORA-, NIS2- oder CSSF-Erwartungen und die Position gegenüber dem Regulator bleiben bei einem Menschen, der dafür verantwortlich ist.

4. Risiko und Schwachstellen — die Aufmerksamkeit dort bündeln, wo sie zählt

Die Abfrage: „Zeige mir hochkritische Anwendungen, on-premise gehostet, mit bekannten Schwachstellen.“ Der Agent filtert das Portfolio über mehrere Attribute zugleich — Geschäftskritikalität, Hosting-Modell, Schwachstellenstatus, Eigentümerschaft — und liefert eine fokussierte Risikofläche statt einer 400-Zeilen-Tabelle.

Was sie freischaltet: Triage durch Schnittmenge. Die gefährlichen Systeme sind selten die, die auf einer einzelnen Dimension markiert sind; sie liegen am Kreuzungspunkt von hoher Kritikalität, schwacher Hosting-Haltung und einer offenen Schwachstelle. Ein Agent drückt diese Schnittmenge als eine Frage aus.

Die ehrliche Grenze: Der Agent spiegelt die Schwachstellen- und Kritikalitätsdaten, die Sie ihm zuführen. Er ist eine Linse auf das Modell, kein Scanner — er entdeckt keine Schwachstellen, er korreliert die bereits erfassten. Halten Sie diese Daten aktuell, sonst verzerrt die Linse.

5. Strategische Ausrichtung — Initiativen mit Zielen verbinden

Die Abfrage: „Welche Initiativen bilden sich auf unsere Finanzziele ab, und welche Ziele haben keine Initiative dahinter?“ Der Agent verfolgt die Kette von strategischen Zielen über die Fähigkeiten, von denen sie abhängen, bis zu den Projekten und Anwendungen, die dagegen liefern, und legt sowohl Abdeckung als auch Lücken offen.

Was sie freischaltet: ein Portfolio-Gespräch, das im Modell verankert ist statt in Folien. Architektur verdient sich ihren Platz am Strategietisch, wenn sie auf Abruf zeigen kann, wo Investition konzentriert ist und wo ein erklärtes Ziel nichts dahinter hat.

Die ehrliche Grenze: Ausrichtung ist nur so real wie die Verbindungen im Modell. Wenn Ziele, Fähigkeiten und Initiativen nicht verbunden sind, hat der Agent nichts zu durchlaufen. Dieser Anwendungsfall belohnt die Organisationen, die diese Beziehungen pflegen, und entlarvt die, die es nicht tun.

6. End-of-Life und Obsoleszenz — die Klippe sehen, bevor Sie sie erreichen

Die Abfrage: „Welche Geschäftsbereiche hängen von Systemen ab, die nahe am End-of-Life sind?“ Der Agent verbindet die Technologie-Lebenszyklusdaten mit der Fähigkeits- und Geschäftsbereichskarte und liefert, wer welchem Obsoleszenzrisiko ausgesetzt ist, gereiht danach, wie kritisch die abhängige Funktion ist.

Was sie freischaltet: proaktive Behebung. End-of-Life-Risiko wird üblicherweise spät entdeckt, wenn eine Anbieterankündigung mit einem kritischen Prozess kollidiert. Ein Agent, der über Lebenszyklus-Attribute schließt, verwandelt diese Überraschung in ein geplantes, priorisiertes Backlog.

Die ehrliche Grenze: Es hängt vollständig davon ab, dass Lebenszyklus-Attribute befüllt und korrekt sind. Falsche oder fehlende End-of-Support-Daten erzeugen ein falsches Sicherheitsgefühl. Der Anwendungsfall ist nur so gut wie die Disziplin hinter den Lebenszyklusdaten.

Der Vorbehalt, der über alle sechs entscheidet: Souveränität

Lesen Sie diese sechs Abfragen noch einmal und beachten Sie, was sie gemeinsam haben. Jede lässt den Agenten über einen nahezu vollständigen Bauplan der Organisation schließen: das gesamte Systeminventar, die kritischen Abhängigkeiten, die veralteten Komponenten, die bekannten Schwachstellen, die sensiblen Datenflüsse. Das ist genau das Asset, dessen Leck sich eine regulierte Institution nicht leisten kann.

Ardoq und Bizzdesign wetteifern darum, „MCP × EA“ zu besetzen, aber ihr Rennen beruht 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: diesen Bauplan an ein US-Cloud-LLM zu senden, ist eine DORA-, CSSF-, DSGVO- und EU-AI-Act-Exposition. Die unbeantwortete Frage ist nicht „kann KI mit meiner Architektur sprechen?“, sondern „kann sie das, ohne dass die Architektur meine Kontrolle verlässt?“

Das ist die Überzeugung, auf die ArchiLU hinarbeitet — eine souveräne Kontextschicht, in der KI über die Karte schließt, ohne dass die Karte die EU oder Ihre Kontrolle verlässt. Um präzise bei der Claim-Disziplin zu sein: Der ArchiLU-MCP-Server ist nicht ausgeliefert. Diese sechs Anwendungsfälle beschreiben, wohin eine souveräne, regulierungstaugliche Kontextschicht steuert, keinen Schalter, den Sie heute umlegen. Was jetzt existiert, ist das vernetzte EA-Modell, natives FR/EN, ein veröffentlichter Preis und EU-Region- oder On-Premise-Hosting unter Ihrer Kontrolle — der Kontext, der zuerst kommen muss.

Warum das regulierte Profil zu diesem Ansatz passt

Ein CISO, DPO oder Head of Architecture in einer EU-regulierten Institution braucht keine schillerndere KI; sie brauchen KI, die sie einem Auditor vorlegen können. Die Baureihenfolge zählt hier: zuerst Kontext, dann regulatorische Intelligenz, dann das Protokoll. Ein MCP über einem veralteten oder oberflächlichen Repository ist wertlos — der Wert ist der lebendige, gouvernierte Kontext darunter und die Gewissheit, dass das Abfragen keine sensiblen Daten über eine Grenze bewegt.

Wenn diese Anwendungsfälle Fragen beschreiben, die Ihr Team heute langsam stellt, ist der erste Schritt nicht, einem Protokoll hinterherzujagen. Es ist, den Kontext darunter agentenbereit zu machen: aktuell, gouverniert und souverän. Beginnen Sie damit zu sehen, wo Ihre Architekturpraxis tatsächlich steht, mit unserem kostenlosen EA-Reifegrad-Assessment — zehn Dimensionen, ein priorisierter Aktionsplan, etwa zehn Minuten — und lesen Sie den Cluster-Hub zu MCP und dem System of Context, um zu sehen, wie die Teile zusammenpassen.