KI mit Ihrem EA-Repository verbinden: Eine Compliance-Checkliste

Warum ein EA-Repository das falsche Ding zum Lecken ist

Es gibt gerade viel Enthusiasmus dafür, einen Allzweck-Assistenten — ChatGPT, Microsoft Copilot, Claude, Gemini — auf interne Systeme zu richten, damit Menschen einfach Fragen in natürlicher Sprache stellen können. Für die meisten Wissensdatenbanken ist das ein vernünftiger Produktivitätsschritt. Für ein Enterprise-Architecture-Repository verdient es zuerst einen härteren Blick.

Ein EA-Repository ist nicht nur eine weitere Datenquelle. Es kommt einem vollständigen Bauplan der Organisation nahe: das gesamte Systeminventar, die kritischen Abhängigkeiten zwischen Anwendungen, welche Komponenten veraltet sind, wo die bekannten Schwachstellen sitzen, wie sensible Daten zwischen Systemen fließen und manchmal die Sicherheitsmaßnahmen selbst. Einem externen Modell übergeben, ist das genau die Karte, die ein Angreifer, ein Wettbewerber oder ein neugieriger Insider am meisten wollen würde.

Die Frage für eine regulierte EU-Organisation ist also nicht „können wir eine KI mit unserer Architektur verbinden?“ — technisch können Sie das an einem Nachmittag. Sie ist „was verlässt unsere Kontrolle, wenn wir es tun, und können wir einem Auditor beweisen, dass wir es gouverniert haben?“ Die Checkliste unten verwandelt das in konkrete Punkte. Jeder ist gerahmt als was zu prüfen ist und warum ein Regulator oder Auditor sich darum kümmert.

Datenresidenz: wohin gehen Prompts und Antworten tatsächlich?

Der erste Punkt ist der physischste. Wenn ein Nutzer den Agenten über Ihre Architektur fragt, reist der Prompt — und oft der abgerufene Repository-Inhalt — dorthin, wo das Modell läuft, und kann dort verarbeitet, zwischengespeichert oder vorübergehend aufbewahrt werden. Für eine sensible EA-Karte ist „irgendwo in einer US-Cloud-Region“ selten eine akzeptable Antwort.

Stellen Sie schriftlich fest, wo Inferenz stattfindet, wo aufbewahrte Daten liegen und ob Unterauftragsverarbeiter sie weiter bewegen. Ein Regulator kümmert sich, weil grenzüberschreitende Verarbeitung sensibler operativer Daten Übermittlungsregeln und Konzentrationsbedenken auslöst; ein Auditor kümmert sich, weil „wir wissen nicht, wohin es geht“ für sich genommen ein Befund ist.

• Prüfen: die genaue(n) Region(en), in denen Prompts und abgerufener Inhalt verarbeitet werden, und jede vorübergehende Aufbewahrung.
• Prüfen: ob Unterauftragsverarbeiter oder Fallback-Regionen die Daten außerhalb Ihres beabsichtigten Perimeters bewegen können.
• Warum es zählt: sensible operative Architektur, die die EU verlässt, löst Übermittlungsregeln, Konzentrationsrisiko und Souveränitätserwartungen aus.

Berechtigungsbewusstheit: sieht der Agent nur, was der Nutzer sehen darf?

Dies ist der Punkt, den die meisten Integrationen falsch machen. Ein naiver Konnektor indiziert das gesamte Repository einmal und beantwortet alle aus diesem Index, was bedeutet, dass ein Nutzer faktisch Objekte lesen kann, die er im EA-Werkzeug nie öffnen dürfte. Die Bequemlichkeit von „frag alles“ löst still Ihr Zugriffskontrollmodell auf.

Der Agent muss dieselbe Autorisierung durchsetzen wie das zugrunde liegende Repository: Er sollte nur sehen, wozu der anfragende Nutzer berechtigt ist, Anfrage für Anfrage. Verifizieren Sie es mit einem bewussten Test — lassen Sie einen Nutzer mit niedrigen Rechten über eine eingeschränkte Domäne fragen und bestätigen Sie, dass der Agent ablehnt oder nichts zurückgibt. Ein Auditor liest eine fehlende Prüfung hier als gebrochene Zugriffskontrollgrenze, was zu den schwerwiegenderen Befunden gehört, die Sie sammeln können.

• Prüfen: dass der Abruf pro Nutzer eingegrenzt ist, kein einzelner gemeinsamer Index, den alle abfragen.
• Prüfen: ein Nutzer mit niedrigen Rechten kann über den Agenten keine eingeschränkten Objekte extrahieren.
• Warum es zählt: eine KI, die Ihr Zugriffsmodell umgeht, ist ein Zugriffskontrollversagen, unabhängig davon, wie die Antwort formuliert ist.

Klassifizierung und Redaktion sensibler Objekttypen

Nicht jedes Objekt in einem EA-Repository trägt dasselbe Risiko. Die gefährlichsten zur Offenlegung sind üblicherweise bekannte Schwachstellen und Behebungsstatus, Sicherheitskontrollen, benannte Single Points of Failure und detaillierte Datenflüsse, die personenbezogene oder regulierte Daten berühren. Bevor Sie irgendetwas verbinden, klassifizieren Sie Ihre Objekttypen und entscheiden Sie, welche niemals vollständig ein externes Modell erreichen dürfen.

Dann redigieren oder zurückhalten Sie diese Kategorien an der Grenze, sodass der Agent über eine bewusst reduzierte Sicht statt über die rohe, vollständige Karte schließt. Ein Regulator kümmert sich, weil die externe Offenlegung Ihrer Schwachstellenkarte selbst operatives Risiko schaffen kann; ein Auditor kümmert sich, weil er erwartet, dass Klassifizierung die Handhabung treibt, nicht umgekehrt.

• Prüfen: eine Klassifizierung der EA-Objekttypen nach Sensibilität existiert und wird am Konnektor angewendet.
• Prüfen: die Kategorien mit dem höchsten Risiko (Schwachstellen, Kontrollen, Single Points of Failure, regulierte Datenflüsse) werden redigiert oder zurückgehalten.
• Warum es zählt: klassifizierungsgetriebene Handhabung ist eine Basiserwartung; eine Schwachstellenkarte offenzulegen, kann selbst ein operatives Risikoereignis sein.

Protokollierung, Auditierbarkeit und ein Mensch in der Schleife

Wenn Sie nicht rekonstruieren können, wer den Agenten was gefragt hat, wann, und was er geantwortet hat, können Sie einen Vorfall nicht untersuchen und können Kontrolle nicht demonstrieren. Protokollieren Sie Prompts und Antworten mit der anfragenden Identität, bewahren Sie sie gemäß Ihrer Richtlinie auf und machen Sie sie abfragbar — derselbe Maßstab, den Sie auf jeden Zugriff auf sensible Daten anwenden würden.

Halten Sie den Agenten fest auf Lesen-und-Beraten, nicht Handeln. Für ein sensibles Repository vervielfacht eine KI, die autonom ins Modell zurückschreiben, Änderungen auslösen oder andere Systeme aufrufen kann, die Risikofläche; ein Mensch sollte jede folgenreiche Handlung prüfen und verantworten. Ein Regulator kümmert sich, weil Auditierbarkeit und menschliche Aufsicht wiederkehrende Themen über DORA und den EU AI Act hinweg sind; ein Auditor kümmert sich, weil „wir haben keine Aufzeichnung“ die meisten Untersuchungslinien schlecht beendet.

• Prüfen: Prompts und Antworten werden mit Identität protokolliert, aufbewahrt und für Untersuchungen durchsuchbar.
• Prüfen: der Agent hat keine autonome Schreib- oder Handlungsfähigkeit auf dem Repository oder nachgelagerten Systemen.
• Warum es zählt: Auditierbarkeit und menschliche Aufsicht sind wiederkehrende regulatorische Erwartungen; eine folgenreiche Handlung braucht einen benannten menschlichen Eigentümer.

Die regulatorische Schicht: DORA, DSGVO, der EU AI Act und Anbieterbedingungen

Über den technischen Kontrollen sitzt die regulatorische Rahmung, und hier müssen die meisten Teams langsamer werden. Behandeln Sie den KI-Anbieter als IKT-Drittanbieter unter DORA: bewerten Sie Konzentrationsrisiko, dokumentieren Sie eine Ausstiegsstrategie und prüfen Sie das vertragliche Recht auf Audit und auf Benachrichtigung über Vorfälle. Ein in Ihre Architektur verdrahteter Allzweck-Assistent ist genau die Art von Abhängigkeit, die DORA explizit zu managen erwartet.

Unter der DSGVO identifizieren Sie eine Rechtsgrundlage für jegliche personenbezogene Daten in den Flüssen, die der Agent erreichen kann, und bestätigen Sie, ob und wie Daten übermittelt werden. Unter dem EU AI Act ordnen Sie den Anwendungsfall der richtigen Risikoklasse zu und wenden die entsprechenden Pflichten an, statt anzunehmen, eine Chatbox sei automatisch risikoarm. Und lesen Sie die LLM-Bedingungen des Anbieters genau zu einer Frage vor allen anderen: werden Ihre Daten genutzt, um ihre Modelle zu trainieren oder zu verbessern, und können Sie das vertraglich abschalten? „Es sah in der Oberfläche in Ordnung aus“ ist nicht der Nachweis, den ein Auditor will — der Vertrag ist es.

• Prüfen (DORA): der KI-Anbieter wird als IKT-Drittanbieter behandelt — Konzentrationsrisiko, Ausstiegsstrategie, Audit- und Vorfallbenachrichtigungsrechte.
• Prüfen (DSGVO): Rechtsgrundlage für jegliche vom Agenten erreichbare personenbezogene Daten, und der Übermittlungsmechanismus für grenzüberschreitende Verarbeitung.
• Prüfen (EU AI Act): der Anwendungsfall ist nach Risiko klassifiziert und trägt die passenden Pflichten.
• Prüfen (Anbieterbedingungen): ob Ihre Prompts und Daten die Modelle des Anbieters trainieren, und ob Sie sich vertraglich abmelden können.

Wohin das steuert — und ein ehrlicher Haftungsausschluss

Das aus dieser Checkliste hervorgehende Muster ist ein Governance-Tor zwischen dem Agenten und dem Repository: eine Schicht, die Residenz durchsetzt, nutzerbezogene Berechtigungen anwendet, die sensibelsten Objekttypen redigiert und alles protokolliert — sodass KI über Ihre Architektur schließen kann, ohne dass Sie die Kontrolle darüber verlieren. Das ist die Richtung, auf die wir mit einem souveränen Kontextansatz hinarbeiten, und wir sind ehrlich, dass ein vollständig souveränes, datenresidenzbewusstes MCP für das ArchiLU-Repository eine Überzeugung und eine Roadmap ist, kein heute ausgeliefertes Produkt.

Nutzen Sie die obigen Punkte, um das Gespräch zwischen Ihren Architektur-, Sicherheits- und Compliance-Teams zu strukturieren und die Nachweise zu sammeln, die ein Auditor verlangen wird. Wichtig und unvermeidlich: Dieser Artikel ist eine Dokumentations- und Risiko-Rahmungshilfe, keine Rechts- oder Compliance-Beratung. Er macht Sie nicht konform mit DORA, NIS2, DSGVO, dem EU AI Act, CSSF-Erwartungen oder einem anderen Regime. Validieren Sie jede Entscheidung mit Ihren eigenen Rechts-, DPO- und Risikofunktionen an Ihrer spezifischen Situation, bevor Sie irgendeine KI mit Ihrem EA-Repository verbinden.