Warum die meisten EA-Repositories zu veraltet sind, um einen KI-Agenten zu füttern

Alle eilen, das Repository offenzulegen. Fast niemand prüft, ob es lebendig ist.

Der Pitch ist jetzt überall: „sprich mit deiner Architektur“. Ardoq, Bizzdesign und ein Dutzend andere verkabeln KI-Agenten mit dem Enterprise-Architecture-Repository, sodass ein CISO oder ein CIO eine Frage in einfachem Deutsch stellen und eine Antwort über das gesamte Bestand zurückbekommen kann. Es ist eine wirklich gute Idee — und sie ruht auf einer Annahme, die fast niemand laut ausspricht.

Die Annahme ist, dass es am anderen Ende dieser Verbindung ein befülltes, korrektes, aktuelles Repository gibt. In den meisten Organisationen gibt es das nicht. Und diese eine Lücke ist der Unterschied zwischen einem KI-Agenten, der nützlich ist, und einem, der leise, selbstbewusst gefährlich ist.

Dieser Beitrag handelt von dieser Lücke. Das Argument ist einfach und unbequem: Ein MCP-Server über einem veralteten Repository ist wertlos. Der Markt konkurriert über Kontextexposition — das Protokoll, die Integration, die „sprich mit“-Demo. Der eigentliche Kampf ist die Kontextakquisition: das Modell am Leben zu halten. Das ist das schwierigere Problem, und es ist dasjenige, das entscheidet, ob irgendetwas davon funktioniert.

Das schmutzige Geheimnis des Marktes: Die meisten Repositories sind bereits zu veraltet

Gehen Sie in ein typisches Unternehmen und betrachten Sie ehrlich das EA-Repository. Nach den meisten Schätzungen der Branche befindet sich die große Mehrheit von ihnen — eine Zahl, die oft mit etwa neun von zehn angegeben wird — in einem oder mehreren dieser Zustände: unvollständig, zwölf bis achtzehn Monate veraltet, von ein oder zwei Personen handgepflegt und von den Systemen abgekoppelt, die das laufende Bestand tatsächlich beschreiben. Das ist keine präzise auditierte Statistik, und wir werden sie nicht als solche darstellen; es ist das konsistente, beobachtete Muster über Analystenkommentare und Praxiserfahrung hinweg. Behandeln Sie es als richtungsweisende Wahrheit, nicht als Zitat.

Die Gründe sind strukturell, nicht das Versagen eines einzelnen Teams. Repositories werden in einem Projekt-Schub befüllt, dann fällt die Pflege auf manuelle Aktualisierungen, die mit dem Tagesgeschäft aller konkurrieren. Das Bestand bewegt sich weiter — Cloud-Migrationen, Stilllegungen, Schatten-IT, Fusionen —, während das Modell stillsteht. Drift ist der Standardzustand eines Enterprise-Architecture-Repositories, und sie setzt schnell ein.

Für den menschlichen Gebrauch war das immer erträglich. Ein Architekt, der ein zwei Jahre altes Diagramm liest, weiß, ihm zu misstrauen, gleicht mit dem Team ab, füllt Lücken aus dem Gedächtnis. Das Repository war ein Ausgangspunkt für ein Gespräch, nicht das letzte Wort. Genau diese Toleranz bricht zusammen, wenn man einen Agenten in die Schleife setzt.

Warum Agenten die Veraltung nicht nur erben — sie verstärken sie

Ein Sprachmodell hat keinen Instinkt für Frische. Geben Sie ihm einen Datensatz, und es wird über diesen Datensatz argumentieren, als wäre er wahr, und die Schlussfolgerung dann in fließender, selbstbewusster Prosa ausdrücken. Es relativiert nicht, weil die Daten alt sind; es weiß nicht, dass die Daten alt sind. Die Veraltung, die ein Mensch stillschweigend abwertet, wäscht ein Agent stillschweigend zu einer sauberen, autoritativ klingenden Antwort.

Das ist die Verstärkung. Ein falscher Fakt, vergraben in einer vergessenen Tabelle, ist inert. Derselbe falsche Fakt, von einem Agenten abgerufen und geliefert als „die Anwendung hat keine Upstream-Abhängigkeit vom Legacy-Zahlungskern, die Stilllegung ist also risikoarm“, ist nun eine Eingabe für eine Entscheidung — formuliert mit genau der Selbstsicherheit, die Menschen vom Nachprüfen abhält. Fehlerhafter Kontext hinein, selbstbewusster Unsinn heraus.

Die Gefahr skaliert damit, wie gut der Agent klingt. Je besser die Formulierung, desto mehr verbirgt sich das Frische-Problem dahinter. Eine ungeschickte Antwort lädt zur Prüfung ein; eine geschliffene lädt zum Vertrauen ein. Je schlechter also die Frische Ihres Repositories, desto mehr arbeitet ein eloquenter Agent gegen Sie — nicht für Sie.

„Sprich mit deiner Architektur“ setzt ein befülltes, frisches Repository voraus, das selten existiert

Lesen Sie die Demos der Etablierten genau, und Sie werden bemerken, dass sie alle auf einem wunderbar vollständigen, aktuellen Modell laufen — dem Referenzdatensatz des Anbieters oder einer speziell für die Demo kuratierten Kundenumgebung. Die Capability-Karte ist voll. Die Abhängigkeiten sind verkabelt. Das Anwendungsportfolio ist aktuell. Natürlich gibt der Agent eine brillante Antwort; er argumentiert über ein Repository in einem Zustand, in dem fast keine Produktionsumgebung tatsächlich ist.

An einer sauberen Demo ist nichts Unehrliches. Das Problem ist der stille Sprung von „der Agent antwortet hier gut“ zu „der Agent wird auf Ihrem Repository gut antworten“. Dieser Sprung ist nur gültig, wenn Ihr Repository so lebendig ist wie das der Demo — und der ganze Punkt des vorigen Abschnitts ist, dass es das normalerweise nicht ist.

Die richtige Frage an jeden Anbieter, der Ihnen „sprich mit deiner Architektur“ verkauft, ist also nicht, wie gut das Gespräch ist. Sie lautet: Was hält das Modell hinter diesem Gespräch wahr? Wenn die Antwort lautet „Ihr Team pflegt es“, haben Sie eine schnellere Schnittstelle zu Ihrer eigenen Veraltung gekauft.

Was ein lebendiges, agent-ready Repository tatsächlich erfordert

„Lebendiger Kontext“ und „agent-ready Repository“ sind keine Slogans — sie beschreiben einen konkreten, anspruchsvollen Standard. Drei Dinge trennen ein lebendiges Repository von einem Snapshot, und ein Repository, dem auch nur eines davon fehlt, ist nicht bereit, die Grundwahrheit für einen Agenten zu sein.

Erstens: kontinuierlicher Abgleich mit den Wahrheitsquellen. Das Modell sollte automatisch und häufig gegen die Systeme geprüft werden, die das reale Bestand beschreiben — die CMDB, das Cloud-Inventar, die Deployment-Pipelines, das Feld. Abgleich ist kein einmaliger Import; es ist ein stehender Prozess, der zutage fördert, wo Modell und Realität auseinandergegangen sind, sodass die Lücke geschlossen statt vergessen wird.

Zweitens: Verantwortlichkeit. Jedes Element — jede Capability, Anwendung, Abhängigkeit — braucht jemanden, der für seine Richtigkeit zuständig ist, nicht eine vage kollektive Verantwortung, bei der niemand hinschaut. Verantwortlichkeit ist das, was eine erkannte Drift in einen korrigierten Fakt verwandelt.

Drittens: Frische-Signale. Das Repository sollte je Element tragen, wann es zuletzt verifiziert wurde und gegen was. Das ist die stille Superkraft für Agenten: Ein Modell, das seine eigene Frische kennt, lässt einen Agenten sagen „diese Abhängigkeit wurde vor sechs Tagen bestätigt“ oder, ebenso wichtig, „dies wurde seit über einem Jahr nicht verifiziert — mit Vorsicht behandeln“. Ein Agent, der seine eigene Unsicherheit kennzeichnen kann, ist weit mehr wert als einer, der immer sicher klingt.

• Kontinuierlicher Abgleich mit Quellsystemen — Drift erkannt und geschlossen, nicht angesammelt
• Klare Verantwortlichkeit je Element — Zuständigkeit für Richtigkeit, nicht kollektive Vernachlässigung
• Frische-Signale je Element — damit der Agent weiß, und sagen kann, wie sehr jedem Fakt zu trauen ist
• Eine Struktur, die auf Abgleich ausgelegt ist, statt eines Dokuments, das einmal befüllt wird und verfällt

Akquisition ist der schwere Teil; Exposition ist die einfache letzte Meile

Treten Sie zurück, und das Wettbewerbsbild kehrt sich um. MCP hinzuzufügen — das Repository offenzulegen, damit ein Agent es abfragen kann — ist der einfache, sich kommoditisierende Teil. Es ist ein Protokoll; es wird binnen eines Jahres ein Häkchen auf jedem EA-Werkzeug sein. Exposition ist die letzte Meile, und letzte Meilen sind nicht der Ort, an dem Burggräben leben.

Kontextakquisition — das Modell zu befüllen, kontinuierlich abzugleichen und zu steuern, damit es wahr bleibt — ist der schwere Teil, der langsame Teil, der Teil, der tatsächlich bestimmt, ob „sprich mit deiner Architektur“ Einsicht oder Halluzination produziert. Hier sitzen die echte Ingenieurarbeit und der echte Wert. Es ist unglamourös: Integrationen, Abgleichslogik, Verantwortlichkeits-Workflows, Frische-Tracking. Es demonstriert sich nicht so gut wie eine Chat-Box. Es ist auch das Einzige, das die Chat-Box vertrauenswürdig macht.

Wir werden hier ehrlich über unsere eigene Position sein, gemäß unserer eigenen Disziplin. ArchiLU baut auf kontinuierlichen, souveränen Kontext hin — das ist unsere Überzeugung und unsere Richtung, kein ausgelieferter magischer Knopf. Wir behaupten keinen Auto-Befüller, der Ihr Repository frisch hält, während Sie schlafen; wer das behauptet, verkauft die einfache Geschichte. Wozu wir uns verpflichten, ist die schwierigere: eine Enterprise-Kontextschicht, die unter Ihrer Kontrolle und EU-Datenresidenz akquiriert und am Leben gehalten wird, so strukturiert, dass Abgleich möglich ist, statt manuellem Heldentum überlassen zu sein. Das ist die Arbeit. Wir sagen Ihnen lieber, dass es Arbeit ist, als Magie vorzutäuschen.

Wie Sie die Bereitschaft Ihres eigenen Repositories bewerten, bevor Sie einen Agenten anschließen

Bevor Sie irgendeinen Agenten mit Ihrer Architektur verbinden, führen Sie einen fünfminütigen Ehrlichkeitstest durch. Wählen Sie fünf geschäftskritische Anwendungen. Beantworten Sie für jede drei Fragen: Wann wurde dieses Element zuletzt mit der Realität abgeglichen? Wer ist für seine Richtigkeit zuständig? Passt sein erfasster Abhängigkeitsgraph noch zu dem, was die Produktion heute tatsächlich tut?

Wenn Sie alle drei für die meisten der fünf beantworten können, haben Sie die Anfänge eines agent-ready Repositories — und es einem Agenten offenzulegen, wird wahrscheinlich Wert schaffen. Wenn Sie die erste Frage für die meisten nicht beantworten können, halten Sie inne. Sie haben keine lebendige Kontextschicht; Sie haben ein Dokument. Einen Agenten daran anzuschließen, wird dieses Problem nicht zutage fördern — es wird es hinter selbstbewusster Prosa verbergen, was das schlimmstmögliche Ergebnis für eine regulierte Institution ist, die ihre Entscheidungen verteidigen muss.

Der konstruktive Schritt ist, die Bereitschaft als das Projekt zu behandeln, mit der Exposition als Belohnung am Ende. Entscheiden Sie, was „verifiziert“ in Ihrem Kontext bedeutet, weisen Sie Verantwortlichkeiten zu, richten Sie den Abgleich mit Ihren realen Quellen ein, und schalten Sie erst dann den Agenten ein. Die Bau-Reihenfolge zählt: Kontext zuerst, dann das Gespräch. Wenn Sie einen strukturierten Ausgangspunkt wollen, bewertet unser kostenloses EA-Reifegrad-Assessment zehn Dimensionen in etwa zehn Minuten und sagt Ihnen ehrlich, wie weit Ihr Repository davon entfernt ist, etwas zu sein, dem ein KI-Agent sicher vertrauen kann.