DORA und Architektur-Nachverfolgbarkeit im Zeitalter der KI-Agenten

DORA hat Sie bereits gebeten, Architektur nachverfolgbar zu machen

Lange bevor KI-Agenten ins Bild kamen, setzte DORA eine klare Erwartung für die regulierte Finanzbranche: Kennen Sie Ihre ICT-Abhängigkeiten, identifizieren Sie, welche davon kritische oder wichtige Funktionen stützen, dokumentieren Sie Ihre Drittanbieter-Vereinbarungen, und seien Sie in der Lage zu erklären — mit Nachweisen —, wie Ihre operative Resilienz zusammenhält. Das ist im Kern eine Nachverfolgbarkeitsanforderung, angewandt auf Ihre Architektur.

Unser begleitender Pfeiler zur Architektur-Governance für DORA und NIS2 behandelt die Maschinerie, die das erzeugt: das Review-Board, die Entscheidungsdatensätze, das Anwendungsregister und das ICT-Abhängigkeits-Mapping. Dieser Artikel wiederholt es nicht. Er betrachtet, was sich ändert, wenn KI-Agenten beginnen, über dieselben Architekturdaten zu schlussfolgern — denn die Nachverfolgbarkeitslatte sinkt nicht, wenn ein Modell dem Workflow beitritt; sie steigt.

Ein Haftungsausschluss vorweg, und wir werden ihn durchgängig ehrlich halten: Nichts hier macht Sie rechtlich konform. DORA-Konformität wird von Aufsichtsbehörden und Auditoren gegen Ihre organisatorischen, vertraglichen und Sicherheitsmaßnahmen entschieden. Ein gesteuertes Architekturmodell — mit oder ohne KI — hilft Ihnen zu dokumentieren und zu belegen, was Sie tun. Es ersetzt nicht die rechtliche, Risiko- und Sicherheitsarbeit.

Was ein KI-Agent an Ihrer ICT-Lieferkette ändert

Ein KI-Agent, der Fragen zu Ihrer Architektur beantwortet oder eine Behebung vorschlägt, ist keine neutrale Funktion. Er hängt in der Regel von einem externen großen Sprachmodell ab. In dem Moment, in dem dieses Modell eine operative oder Resilienzentscheidung beeinflusst, hat der Anbieter dahinter einen Anspruch, Teil Ihrer ICT-Lieferkette zu sein — genau die Art von Beziehung, die DORA von Ihnen erwartet zu identifizieren, zu dokumentieren und zu bewerten.

Ehrlich behandelt, wirft das vertraute Drittanbieterfragen an einem neuen Ort auf. Wer ist der Anbieter, und unter welchem Vertrag? Wohin gehen die Daten? Und — die eine, die Teams vergessen — wenn drei oder vier kritische Workflows alle leise von demselben Modell abhängen, haben Sie ein Konzentrationsrisiko, das Sie nie festgehalten haben. Die Disziplin ist, jedes externe Modell als zu dokumentierende Abhängigkeit zu behandeln, nicht als unsichtbares Dienstprogramm, zu dem Sie standardmäßig greifen.

• Ein externer Modellanbieter hinter einem Agenten ist ein ICT-Drittanbieter-Kandidat
• Mehrere kritische Workflows auf einem Modell sind ein festzuhaltendes Konzentrationsrisiko
• Vertrag, Datenort und Exit-Haltung sind die üblichen Drittanbieterfragen, auf KI angewandt
• Der ehrliche Standard: die Modellabhängigkeit dokumentieren, sie nicht verbergen

Prompts und Antworten sind ein Datenfluss, den Sie beschreiben müssen

Wenn ein Agent Architekturkontext an ein Modell sendet, denken Sie darüber nach, was dieser Kontext tatsächlich ist. Er kann Systeminventar, Kritikalitätsbewertungen, Abhängigkeitskarten, Hosting-Details enthalten — in Summe ein nahezu vollständiger Bauplan der Organisation. Der Prompt ist ein ausgehender Datenfluss; die Antwort, die eine Entscheidung formt, ist ein eingehender. DORA-gesinnte Governance erwartet, dass Sie wissen, welche Daten wohin gehen, und KI bekommt keine Ausnahme.

Hier zählt die Quelle des Kontexts enorm. Wenn der Agent aus verstreuten Exporten und Ad-hoc-Kopien schöpft, können Sie den Fluss nicht mit Zuversicht beschreiben — und Sie können ihn schon gar nicht später beweisen. Wenn der Kontext aus einem gesteuerten Modell kommt, auf das Sie zeigen können, wird der Fluss beschreibbar: dieser definierte Ausschnitt der Architektur, mit diesen Residenzattributen, war der Input. Je sauberer die Quelle, desto sauberer der Nachweis.

Ein lebendiges, gesteuertes Modell ist der Nachverfolgbarkeitsanker

Das Asset, das all dies verteidigungsfähig macht, ist ein aktuelles, gesteuertes Architekturmodell — keine achtzehn Monate alte Momentaufnahme. Ein lebendiges Anwendungsregister, kartierte ICT-Abhängigkeiten und festgehaltene Entscheidungen sind bereits das, was eine Resilienzprüfung sehen will. Sie sind auch das, worüber ein KI-Agent schlussfolgern sollte, denn einen Agenten in veralteten oder oberflächlichen Daten zu gründen, produziert zuversichtliche Antworten, die kein Auditor akzeptieren würde.

Konkret ist das dasselbe Rückgrat, das der Governance-Pfeiler beschreibt, für einen neuen Zweck genutzt. Das Register sagt Ihnen, welche Anwendungen eine kritische Funktion stützen. Die Abhängigkeitskarte sagt Ihnen, worauf diese Anwendungen beruhen. Wenn die Empfehlung eines Agenten in diesem Modell gegründet ist, erbt die Empfehlung die Nachverfolgbarkeit des Modells, statt frei in einem Chat-Fenster zu schweben.

• Ein Anwendungsregister mit Eigentümern, Kritikalität und Hosting-Attributen
• Kartierte ICT-Abhängigkeiten von kritischen Funktionen hinab zu Anbietern
• Entscheidungsdatensätze, die die menschliche Wahl und ihre Begründung festhalten
• Kontinuierlich gepflegt, sodass der Agent über die aktuelle Realität schlussfolgert

KI-beeinflusste Entscheidungen innerhalb des Rahmens halten

Das Risiko bei Agenten ist nicht, dass sie schlechte Antworten geben; es ist, dass eine gut aussehende Antwort ohne Herkunft eintrifft. Eine Resilienzentscheidung, die nur bis zu einem undurchsichtigen Gespräch nachverfolgt werden kann, ist genau das, was eine aufsichtsrechtliche Prüfung nicht will. Das Heilmittel ist, die Entscheidung zu verankern: Der Input des Agenten war dieser versionierte Ausschnitt des Modells, die menschliche Wahl wurde als eine mit den betroffenen Anwendungen verknüpfte Entscheidung festgehalten, und die Spur läuft von der kritischen Funktion zur Abhängigkeit zum Anbieter ohne Lücke.

Das ist die praktische Disziplin. Nutzen Sie den Agenten, um die Analyse zu beschleunigen, und halten Sie dann das Ergebnis als erstklassige Entscheidung in demselben gesteuerten Modell fest — Kontext, Optionen, Entscheidung, Begründung — genau wie Sie es für jede bedeutende Architekturänderung tun würden. Die KI beschleunigt das Denken; der gesteuerte Datensatz hält es nachverfolgbar. Das eine ohne das andere ist entweder langsam oder unverteidigbar.

Hin zu einer souveränen Kontextschicht für regulierte KI

Es gibt eine vorausschauende Version davon, von der wir überzeugt sind, dass sie die richtige Richtung ist, und wir werden klarstellen, dass es Überzeugung und Roadmap ist, keine ausgelieferte Funktion. Wir glauben, regulierte Organisationen sollten in der Lage sein, ihren KI-Agenten eine souveräne Kontextschicht zu geben: ein gesteuertes System of Context, gehalten in einer Region, die Sie kontrollieren, über das ein Agent schlussfolgern kann, ohne dass die sensible Architekturkarte Ihre Grenze verlässt. Das Ziel ist, die DORA-Fragen — was hängt wovon ab, wohin gehen die Daten — per Design zu beantworten statt nachträglich.

Dorthin steuert ArchiLU: Kontext zuerst, regulatorisches Schlussfolgern als Nächstes, und jeder datenresidenzbewusste Zugriff für Agenten aufgebaut auf einem Modell, das bereits gesteuert, aktuell und Ihres war. Für heute ist der verteidigungsfähige Schritt unglamourös und real — ein lebendiges Architekturmodell halten, jedes externe Modell als dokumentierte Abhängigkeit behandeln und jede KI-beeinflusste Entscheidung an einer gesteuerten Quelle verankern. Wenn Sie eine schnelle Einschätzung wollen, wo Ihre Praxis steht, bewertet das kostenlose EA-Reifegrad-Assessment zehn Dimensionen und liefert in etwa zehn Minuten einen priorisierten Plan.