Was ein Auditor zum Zugriff Ihrer KI auf Architekturdaten fragen wird

An dem Tag, an dem KI Zugriff auf Ihre Architektur erhält, startet die Audit-Uhr

Ein Enterprise-Architecture-Repository ist eine der sensibelsten Karten, die Ihre Organisation besitzt: das Systeminventar, die kritischen Abhängigkeiten, die veralteten Komponenten, die bekannten Schwachstellen, die sensiblen Datenflüsse. In dem Moment, in dem ein KI-Agent dieses Repository abfragen kann, haben Sie eine neue Kontrolloberfläche geschaffen — und ein Regulator, ein interner Auditor oder eine CSSF-Inspektion wird sie als solche behandeln.

Das ist kein Grund, KI von Ihrer Architektur fernzuhalten. Es ist ein Grund, vor dem Gespräch genau zu wissen, was ein Auditor fragen wird und welcher Nachweis es beantwortet. Die gute Nachricht: diese Fragen sind vorhersehbar. Der ehrliche Vorbehalt: den Nachweis zu erbringen ist Ihre Arbeit, kein Anbieter-Häkchen. Dieses Stück ist eine Audit-Readiness-Hilfe — es hilft Ihnen, Nachweise vorzubereiten — und es ist keine rechtliche Konformität oder Rechtsberatung.

Nachstehend die sechs Fragen, die Sie erwarten sollten, formuliert, wie Audit sie tatsächlich formuliert: die Frage, dann wie ein guter Nachweis aussieht.

Frage 1 — Wer und was kann die Architekturdaten abfragen?

Die erste Frage betrifft das Zugriffsmodell. Ein Auditor wird „die KI kann das Repository lesen“ nicht akzeptieren — er wird fragen, welche Agenten, handelnd für welche Nutzer, welche Objekte abfragen können und unter welcher Autorisierung.

Die Falle ist, dass KI-Zugriff oft außerhalb Ihres normalen Identitäts- und Berechtigungsmodells angeflanscht wird. Sieht der Agent alles, unabhängig davon, wer tatsächlich fragt, haben Sie faktisch pauschalen Zugriff auf Ihre sensibelste Karte gewährt. Guter Nachweis ist ein explizites Zugriffsmodell, das jede Abfrage an einen authentifizierten Nutzer und seine Berechtigungen bindet, sodass ein Agent nur das zurückgibt, was dieser Nutzer sehen darf.

• Nachweis: ein dokumentiertes Zugriffsmodell, das Agenten und Nutzer auf Repository-Objekte abbildet
• Nachweis: Durchsetzung von Berechtigungen pro Nutzer, nicht ein einzelnes Service-Konto, das alles sieht
• Nachweis: ein Review-Prozess dafür, wem KI-Abfragerechte gewährt werden und wann sie entzogen werden

Frage 2 — Wohin gehen die Daten, und über welche Grenzen?

Das ist die Residenz- und Transferfrage, und für die EU-regulierte Finanzwelt ist sie oft entscheidend. Wenn ein Agent antwortet, wird Ihr Architekturkontext zur Eingabe eines Modells. Läuft dieses Modell außerhalb Ihrer Kontrolle — etwa ein US-Cloud-LLM —, dann können Ihr Systeminventar, Ihre Abhängigkeiten und Ihre Schwachstellen Ihre Region und Ihren Governance-Perimeter verlassen.

Ein Auditor wird den Datenpfad gezeichnet sehen wollen, nicht abstrakt beschrieben. Guter Nachweis ist eine dokumentierte Hosting-Region, eine klare Darstellung jeder grenzüberschreitenden Übertragung, die vertraglichen und Datenverarbeitungsbedingungen, die sie regeln, und — wo es am meisten zählt — die Fähigkeit, die Inferenz innerhalb einer von Ihnen kontrollierten Umgebung zu halten. Seien Sie präzise, was Sie heute beweisen können versus was aspirativ ist; Auditoren bemerken den Unterschied.

• Nachweis: dokumentierte Hosting-Region für das Modell und den Kontext, den es erhält
• Nachweis: eine Datentransferkarte und die rechtliche Grundlage für jeden grenzüberschreitenden Fluss
• Nachweis: Datenverarbeitungsvereinbarungen, die den Modellanbieter abdecken
• Nachweis: wo erforderlich, EU-Region- oder On-Premise-Inferenz unter Ihrer Kontrolle

Frage 3 — Was wird protokolliert, und können Sie es rekonstruieren?

Die Auditierbarkeit von Prompts und Antworten trennt eine geregelte KI-Fähigkeit von einer undurchsichtigen. Ein Auditor, der einen Vorfall untersucht — ein durchgesickertes Design, eine umgesetzte falsche Empfehlung —, wird Sie bitten zu rekonstruieren, wer was wann gefragt hat und was der Agent zurückgab.

Sind diese Interaktionen nicht protokolliert, können Sie nicht untersuchen und keine verhältnismäßige Kontrolle nachweisen. Guter Nachweis ist ein dauerhaftes, manipulationssicheres Protokoll von Abfragen und Antworten, für einen definierten Zeitraum aufbewahrt, während einer Untersuchung abfragbar und so geschützt, dass das Protokoll selbst nicht still bearbeitet werden kann. Behandeln Sie es vom ersten Tag an als erstklassiges Artefakt, denn Protokollierung nach einem Vorfall nachzurüsten ist, wie Organisationen ein Audit nicht bestehen.

• Nachweis: ein Abfrage-und-Antwort-Protokoll, das Nutzer, Zeitstempel, Anfrage und Antwort erfasst
• Nachweis: ein definierter Aufbewahrungszeitraum, abgestimmt auf Ihre Aufbewahrungspflichten
• Nachweis: Integritätskontrollen des Protokolls, damit die Spur nicht still verändert werden kann

Frage 4 — Wie werden sensible Objekte klassifiziert und geschützt?

Nicht jedes Objekt im Repository trägt dasselbe Risiko. Eine Fähigkeitskarte ist eine Sache; ein Inventar ungepatchter Schwachstellen oder die Datenflüsse, die personenbezogene oder aufsichtsrechtliche Daten berühren, eine andere. Ein Auditor wird fragen, wie Sie sie unterscheiden und wie die sensiblen vor einem Agenten geschützt sind, der sie unachtsam zutage fördern könnte.

Guter Nachweis beginnt mit Klassifizierung: ein Schema, das Architekturobjekte nach Sensibilität kennzeichnet, konsistent angewandt. Darüber sitzt Redaction oder Zurückhaltung — die Fähigkeit, die sensibelsten Attribute (bekannte Schwächen, Sicherheitsmaßnahmen, regulierte Datenflüsse) aus den Antworten eines Agenten herauszuhalten, sofern nicht ausdrücklich autorisiert. „Die KI hat einfach alles zusammengefasst, was sie fand“ ist keine Antwort, die ein Auditor für Ihre Kronjuwelen-Objekte akzeptieren wird.

• Nachweis: ein Klassifizierungsschema, angewandt auf Architekturobjekte und -attribute
• Nachweis: Redaction- oder Zurückhaltungsregeln für hochsensible Objekte
• Nachweis: eine verteidigbare Begründung dafür, was ein Agent zutage fördern darf und was nicht

Frage 5 — Wer ist für eine KI-beeinflusste Entscheidung verantwortlich?

Das ist meist die schwierigste Frage und diejenige, die schwache Governance am schnellsten entlarvt. Wurde eine Architekturentscheidung von der Antwort eines Agenten geformt, wird ein Auditor fragen, wer diese Entscheidung besitzt und ob die Antwort auf eine geregelte Quelle — ein echtes Objekt in Ihrem Repository — zurückgeführt werden kann statt auf die plausibel klingende Improvisation eines Modells.

Guter Nachweis ist ein Human-in-the-Loop-Verantwortungsmodell: ein benannter Verantwortlicher für Entscheidungen, die KI informiert, und Nachverfolgbarkeit von der Antwort des Agenten zurück zu den Quellobjekten, auf die er sich stützte. Es geht nicht darum, dass Menschen alles genehmigen; es geht darum, dass Verantwortung nie ins Modell verdunstet. Wenn Sie keinen Verantwortlichen benennen und keine Quelle zitieren können, lesen sich Ihre übrigen Kontrollen wie Dekoration.

• Nachweis: ein Human-in-the-Loop-Modell, das Verantwortliche für KI-informierte Entscheidungen benennt
• Nachweis: Nachverfolgbarkeit von der Antwort eines Agenten zu zitierbaren Quellobjekten
• Nachweis: eine klare Grenze zwischen KI-Vorschlag und menschlicher Referenzentscheidung

Frage 6 — Wie wird Drittanbieter- und ICT-Risiko geregelt (DORA)?

Ein KI-Agent, der Ihre Architekturdaten erreicht, ist fast immer eine ICT-Drittanbieterabhängigkeit. Unter DORA zieht das ihn in Ihr ICT-Drittanbieter-Risikomanagement: er sollte in Ihrem Informationsregister erscheinen, mit den Konzentrations-, Weiterauslagerungs- und Exit-Erwägungen, die jeder kritische Anbieter anzieht.

Ein Auditor wird fragen, ob der KI-Anbieter wie jeder andere ICT-Lieferant geregelt wird — bewertet, vertraglich gebunden, überwacht und ablösbar. Guter Nachweis ist ein Eintrag in Ihrem ICT-Drittanbieterregister, vertragliche Bedingungen, die DORA-Erwartungen erfüllen, und eine getestete Antwort auf „was passiert, wenn dieser Anbieter ausfällt oder ersetzt werden muss?“. Das Architektur-Repository selbst hilft hier: es ist der Ort, an dem die Abhängigkeit von der KI-Fähigkeit modelliert werden sollte, sodass das Risiko sichtbar ist statt in einem Einkaufsordner verborgen.

• Nachweis: die KI-Fähigkeit gelistet in Ihrem ICT-Drittanbieter-Informationsregister
• Nachweis: Vertragsbedingungen und Überwachung, abgestimmt auf DORA-Erwartungen
• Nachweis: ein dokumentierter und getesteter Exit-/Substitutionsplan

Bereiten Sie den Nachweis vor, bevor Sie ihn brauchen

Diese sechs Fragen sind kein Grund, KI von Ihrer Architektur fernzuhalten — sie sind die Agenda, es verteidigbar zu tun. Jede ist beantwortbar, und jede ist weit günstiger vor einer Inspektion zu beantworten als während einer. Wir bauen ArchiLU auf einen souveränen, data-residency-aware Context Layer für genau dieses Gespräch hin; dieser MCP-Layer ist Überzeugung und Roadmap, kein ausgeliefertes Produkt, und wir werden nichts anderes vorgeben. Was heute existiert, ist ein vernetztes EA-Modell, EU-Region- oder On-Premise-Hosting unter Ihrer Kontrolle, natives FR/EN und eine Struktur, die um DORA/CSSF-Dokumentationsbedarf herum gebaut ist.

Beginnen Sie dort, wo Ihre Praxis tatsächlich steht. Das kostenlose EA-Reifegrad-Assessment von ArchiLU bewertet zehn Dimensionen und liefert in etwa zehn Minuten einen priorisierten Aktionsplan — ein konkreter Weg zu sehen, wie bereit Ihre Architektur-Governance für die Fragen ist, die ein Auditor mitbringen wird, sobald KI-Agenten Ihr Repository nach Antworten zu fragen beginnen.