KI‑Automatisierung für Finanz‑ und ICT‑Anbieter: Antworten und Nachweise organisieren

Dokumentationsarbeit ist ein praktischer erster Einsatz von KI in Finanzdienstleistungen: das Auffinden eines Kontroll‑Datensatzes, das Verfassen einer Fragebogen‑Antwort und das Identifizieren fehlender Lieferanten‑Informationen. Diese Aufgaben können festgelegte Quellen und Genehmiger haben. Ihre Ergebnisse können zudem mit dem bestehenden manuellen Prozess verglichen werden.

Ein Finanzinstitut kann relevante Informationen über Verträge, Lieferanten‑Register, Tickets und Sicherheitsdokumente hinweg besitzen. Ein ICT‑Anbieter steht vor einem ähnlichen Problem, wenn ein weiterer Kunden‑Fragebogen eintrifft. Ein langer Fragebogen rechtfertigt nicht, Antworten aus dem allgemeinen Wissen eines Modells zu generieren. Eine Aussage, dass eine Kontrolle funktioniert, benötigt aktuelle Nachweise, die den betreffenden Service abdecken.

Dieser Leitfaden behandelt Dokumentation, Lieferanten‑Risiko und interne Verfahren. Er beschreibt nicht automatisierte Bonitäts‑Bewertungen, Investitionsentscheidungen oder ein vollständiges DORA‑Umsetzungsprogramm. Gesetzliche Anforderungen enthalten Quellen‑Verweise. Die vorgeschlagene Arbeits‑Methode und der Pilot sind Autor‑Empfehlungen, die an die jeweilige Organisation angepasst werden sollten.

Ein Workflow aus zwei Perspektiven

Für ein Finanzinstitut kann ein Assistent Informationen zu einem ICT‑Service zusammenstellen: den vertraglich vereinbarten Umfang, die unterstützte Funktion, die Verarbeitungs‑Standorte, Sub‑Contractor‑Informationen und den Vertrags‑Besitzer. Er kann unbeantwortete Fragen und inkonsistente Dokumente hervorheben. Die autorisierten Personen bewerten weiterhin das Risiko und entscheiden, ob der Lieferant akzeptiert wird.

Für einen ICT‑Anbieter ist ein nützlicher Ausgangspunkt ein Fragebogen‑Entwurf, der ausschließlich auf genehmigten Aufzeichnungen beruht. Jede Antwort sollte ihr Evidenz‑Material, den Geltungs‑Bereich und das Datum benennen. Wenn eine Frage alle Services betrifft, das verfügbare Dokument jedoch nur einen Service abdeckt, muss der Assistent diese Grenze anzeigen. Eine Aussage über das hinaus zu erweitern, was die Evidenz belegt, kann vertragliche Haftungs‑Risiken erzeugen.

Beginnen Sie mit dem Lesen und Verfassen auf beiden Seiten. Das Senden einer Antwort, das Ändern eines Registers und das Akzeptieren eines Risikos sind separate Aktionen. Fügen Sie Berechtigungs‑ und Genehmigungs‑Regeln dafür nur hinzu, wenn ein nachgewiesener Bedarf besteht. Mehr Autonomie repariert nicht inkonsistente Quell‑Dokumente und kann diese Inkonsistenzen schwerer erkennbar machen.

DORA überträgt keine Verantwortung auf KI

DORA gilt für festgelegte Finanzinstitute, vorbehaltlich ihres Anwendungs‑ und Ausnahme‑Umfangs. Ein Finanzinstitut bleibt für seine Pflichten verantwortlich, wenn es externe ICT‑Dienste nutzt. Artikel 28 behandelt das ICT‑Dritt‑Partei‑Risikomanagement, die Bewertung vor Vertragsabschluss und das Register von Informationen zu ICT‑Vertrags‑Arrangements. [1]

Artikel 30 legt vertragliche Elemente fest, darunter die Service‑Beschreibung, Standorte, Datenschutz, Daten‑Zugriff und -Rückgabe, Vorfalls‑Unterstützung und Kündigungs‑Rechte. Dienste, die kritische oder wichtige Funktionen unterstützen, haben zusätzliche Anforderungen. Bewerten Sie die Funktion, die ein Service unterstützt, bevor Sie einen undifferenzierten Fragebogen auf jeden Lieferanten anwenden. [1]

Ein ICT‑Anbieter wird nicht automatisch zu einem Finanzinstitut, nur weil er einer Bank liefert. Er kann vertragliche Pflichten vom Kunden erhalten, während ausgewiesene kritische ICT‑Anbieter einem separaten Aufsichts‑Rahmen unterliegen. Daher ist eine pauschale Aussage, ein Unternehmen sei DORA‑konform, unzureichend. Identifizieren Sie das Unternehmen, den Service, die Rolle und die konkrete Verpflichtung, die adressiert wird.

Die DSGVO verlangt weiterhin die Bewertung personenbezogener Daten, Zweck, Rechtsgrundlage, Auftrags‑Verarbeitungs‑Arrangements und Sicherheit. [2] Nach dem KI‑Gesetz ist das Durchsuchen von Verfahren ein anderer beabsichtigter Verwendungszweck als die Bewertung der Kreditwürdigkeit einer natürlichen Person oder spezifizierte Risiko‑ und Preis‑Bewertungen in Lebens‑ und Krankenversicherungen. Ein Chat‑Bot im Finanzsektor ist nicht automatisch hoch‑risikobehaftet. [3]

NIS2 kann ebenfalls bestimmte ICT‑Einheiten und -Dienste betreffen. Für Finanzinstitute ist das Zusammenspiel mit DORA als sektorspezifische Gesetzgebung relevant. Prüfen Sie die Tätigkeit, Rolle und nationale Umsetzung, anstatt Pflichten aus zwei nicht zusammengehörigen Checklisten zu kombinieren. [4] Dieser Leitfaden ist eine Vorbereitungsmethode; detaillierte Melde‑Regeln und Umsetzungs‑Maßnahmen erfordern eine separate Prüfung, sobald sie das Projekt betreffen.

Evidenz für jede Aussage etablieren

Sicherheits‑Fragebögen vermischen häufig eine Richtlinie, eine operative Tatsache und ein vertragliches Versprechen. Sie benötigen unterschiedliche Nachweise. Eine Backup‑Richtlinie beweist nicht, dass das neueste Backup eines konkreten Systems erfolgreich war. Ein Bericht über einen einzelnen Wiederherstellungstest legt nicht dieselbe Wiederherstellungs‑Zeit für jeden Service fest.

Dokumentieren Sie für jede Antwort den Evidenz‑Typ, den Service, den Geltungs‑Bereich, das Datum und den Eigentümer. Ein fehlender Datensatz sollte eine Anfrage erzeugen, nicht eine positive Erklärung. Ältere Evidenz kann nach den eigenen Regeln der Organisation zur Überprüfung markiert werden. Es gibt kein einheitliches Ablauf‑Datum für alle Sicherheits‑Dokumente. Lassen Sie das Modell keine Zertifikate, Audits oder Daten erfinden, die nicht aus der Quelle stammen.

Nützliche Evidenz‑Status umfassen „bestätigt in der Quelle“, „Klärungsbedarf“ und „außerhalb des Geltungs‑Bereiches“. Diese Status beschreiben die verfügbaren Informationen; sie stellen keine Risiko‑Akzeptanz dar. Der Genehmiger kann dann sehen, welche Antworten fertig sind und welche die Reaktion des Kontroll‑Eigentümers benötigen.

Bewahren Sie die Unterscheidung zwischen einer Aussage des Lieferanten und Evidenz, die von Ihrer eigenen Organisation geprüft wurde. Beispiel: Eine per E‑Mail erhaltene Bescheinigung bleibt dem Lieferanten zuzuordnen. Der Assistent darf sie nicht in eine Aussage umwandeln, dass Ihr Team die Kontrolle eigenständig getestet hat. Diese Unterscheidung ist wichtig, wenn später jemand die Entscheidungs‑Kette prüft.

Daten‑Zugriff und Entscheidungs‑Rechte definieren

Die folgende Matrix ist ein vorgeschlagenes Betriebs‑Arrangement. Stimmen Sie sie ab, bevor Sie Dokumente oder Werkzeuge verbinden.

Geben Sie keine Geheimnisse, vollständige Transaktions‑Datensätze oder eine gesamte Kunden‑Umgebung preis, weil ein Connector es bequem macht. Fragebogen‑Arbeit benötigt in der Regel eine genehmigte Kontroll‑Beschreibung und Evidenz mit passender Abdeckung. Ein Penetration‑Test‑Bericht kann Informationen enthalten, die nicht an jeden Empfänger weitergegeben werden dürfen.

Setzen Sie Beschränkungen sowohl bei der Dokument‑Abruf‑ als auch bei der Index‑Phase sowie in der sichtbaren Benutzeroberfläche durch. Der Mitarbeiter eines Kunden darf nicht das Material eines anderen Kunden durch Umformulierung einer Frage abrufen. Prüfen Sie Berechtigungen, bevor Inhalte in den Modell‑Kontext gelangen. Anweisungen innerhalb eines Prompts sind zu schwach, um alleinige Zugriffs‑Grenzen zu bilden.

API‑ und MCP‑Kontrollen außerhalb des Modells belassen

Stellen Sie einen begrenzten Satz von Operationen bereit: ein genehmigtes Dokument lesen, bestimmte Register‑Felder lesen, einen Entwurf einer Antwort erstellen oder ein Ticket anlegen. Jede Werkzeugs‑Komponente muss Rolle, Daten‑Umfang und Parameter prüfen. Das technische Konto sollte Berechtigungen besitzen, die genau diesen Operationen entsprechen. Das Modell darf seine eigene Autorität nicht durch nachfolgende Anfragen erweitern.

Ein Lieferanten‑Dokument oder Fragebogen kann Anweisungen enthalten, Informationen preiszugeben, Beschränkungen zu ignorieren oder ein Werkzeug aufzurufen. OWASP beschreibt diesen Mechanismus als Prompt‑Injection. [5] Das Dokument bleibt Eingabedaten, selbst wenn es administrative Autorität oder Dringlichkeit beansprucht. Anwendungs‑Kontrollen müssen eine Operation außerhalb des erlaubten Umfangs ablehnen.

Vor dem Schreiben zeigen Sie den Unterschied zwischen aktuellem und vorgeschlagenem Wert an. Verwenden Sie einen Idempotenz‑Schlüssel, der von der Komponente, die die Schreib‑Operation ausführt, erzwungen wird, sodass ein Netzwerk‑Retry keine doppelten Aufgaben erzeugt. Ein reiner Korrelations‑Identifier verhindert Duplikate nicht. Dies sind Design‑Empfehlungen. Ihr Zweck ist, Fehler zu begrenzen und Ereignisse nachvollziehbar zu machen, nicht unzählige Kontrollen zu akkumulieren, die niemand versteht.

Abhängigkeiten und Bedingungen vor dem Start abstimmen

Kartieren Sie die Verarbeitungskette: Anwendung, Modell, Dokument‑Index, Protokolle und Sub‑Contractor‑Partner. Prüfen Sie Standorte, Daten‑Nutzung durch den Anbieter, Aufbewahrung, Verpflichtungen bei Service‑Änderungen und Verfügbarkeit von Evidenz. Eine regionale Einstellung für eine Komponente begründet nicht den Standort oder die vertragliche Behandlung des gesamten Services.

Falls der Service eine kritische oder wichtige Funktion nach DORA unterstützt, bewerten Sie die entsprechenden zusätzlichen vertraglichen und operativen Anforderungen. [1] Der Einsatz von KI allein entscheidet nicht über diese Klassifizierung. Überlegen Sie, was im Finanzinstitut ausfallen würde, wenn die Anwendung oder ein abhängiger Anbieter nicht mehr verfügbar wäre.

Beschreiben Sie den manuellen Rückgriff, das Vorfalls‑Verfahren und Export‑Arrangements im Service‑Umfang. Versprechen Sie keine uneingeschränkte Autonomie, garantierte Konformität oder eine bestimmte Aufbewahrungs‑Regel, ohne dass die tatsächliche Konfiguration und der Vertrag dies unterstützen. Nicht unterstützte Versprechen tauchen häufig im nächsten Kunden‑Fragebogen wieder auf, als wären sie etablierte Fakten.

Anforderungen, Aktionen und Lernen verbinden

Pulsar GRC wird in einer Early‑Access‑Phase entwickelt, um die Arbeit mit Kundendokumenten, Anforderungen, Kontrollen, Risiken, Aktionen und Evidenz zu unterstützen. Eine nützliche Beziehung in diesem Kontext verbindet eine Kunden‑Frage mit ihrer Anforderung, Kontrolle, Evidenz und dem Eigentümer. Bestätigen Sie die notwendige Funktionalität und den Integrations‑Umfang, bevor Sie implementieren.

Zmianowo/CrewShift wird für dokumenten‑basiertes Lernen und Tests mit menschlicher Freigabe entwickelt. Nach Bestätigung des verfügbaren Umfangs kann es die Vorbereitung einer überarbeiteten Lieferanten‑Bewertung oder eines Vorfalls‑Verfahrens unterstützen. Ein Testergebnis ist keine offizielle Qualifikation und begründet nicht, dass ein Mitarbeitender einen realen Vorfall ohne Hilfe bewältigen kann.

Die Verantwortung bleibt eindeutig: Der Kontroll‑Besitzer bestätigt den Zustand der Kontrolle, eine autorisierte Person akzeptiert die Antwort, und technisches Personal verwaltet die vereinbarte Konfiguration. Software hilft, die Arbeit zu organisieren. Sie darf nicht ein fehlendes Dokument in eine Aussage verwandeln, dass eine Anforderung erfüllt ist.

Pilot‑Einfrage und ein Service

Beginnen Sie mit einem bereits abgeschlossenen Fragebogen, mehreren Dutzend Fragen und Dokumentation für einen Service. Dies ist ein organisatorischer Vorschlag, keine DORA‑Vorgabe. Erstellen Sie Referenz‑Antworten und markieren Sie die Fragen, die zuvor Klärungs‑Bedarf hatten. Entfernen Sie unnötige personenbezogene Daten und Material, das Beschränkungen unterliegt.

Beziehen Sie Fragen ein, für die keine Evidenz vorliegt, veraltete Aufzeichnungen, widersprüchliche Beschreibungen und Anfragen, die außerhalb der Zugriffs‑Rechte des Nutzers liegen. Bewerten Sie, ob die Evidenz sowohl die Antwort als auch den angegebenen Geltungs‑Bereich unterstützt. Eine bejahende Antwort, die ausschließlich auf einem zukünftigen Implementierungs‑Plan beruht, ist ein wesentlicher Mangel, selbst wenn der Text plausibel klingt.

Messen Sie die Vorbereitungs‑Zeit inklusive Korrekturen, Antworten, die ohne Änderung akzeptiert wurden, korrekt identifizierte Lücken und unautorisierte Operationen. Schnellere Generierung hat wenig Wert, wenn die Überprüfung länger dauert. Vergleichen Sie ähnliche Aufgaben, anstatt ein leichtes KI‑unterstütztes Formular mit einem schwierigen manuellen zu vergleichen. Definieren Sie vor Beginn eine Abbruch‑Bedingung, etwa unautorisierte Offenlegung oder eine wesentliche, nicht unterstützte Aussage.

NIST AI 600‑1 kann helfen, generative KI‑Risiken für die Bewertung auszuwählen. Es handelt sich um freiwillige Leitlinien, nicht um ein Konformitäts‑Zertifikat. [6] Nutzen Sie die resultierende Risikoliste, um zu entscheiden, welche Evidenz der Pilot liefern muss und welche Fehl‑Schläge den vorgeschlagenen Umfang unakzeptabel machen würden.

Ein fiktives Beispiel aus dem Finanz‑Sektor‑Lieferanten‑Umfeld

Dieses Szenario ist fiktiv. Ein ICT‑Unternehmen erhält einen Fragebogen zu einem Service. Es verfügt über eine Backup‑Richtlinie, einen Wiederherstellungs‑Bericht und eine Sub‑Contractor‑Beschreibung. Der Assistent findet die relevanten Nachweise und erstellt einen Entwurf. Zwei Fragen betreffen Bereiche, die in den Dokumenten nicht vorhanden sind. Statt bejahender Antworten werden zwei Anfragen an die Kontroll‑Besitzer zugewiesen.

Das Sicherheitspersonal prüft die Abdeckung, das Rechts‑Team bewertet die Verpflichtungen, und der Service‑Besitzer genehmigt die finale Antwort. Erst danach wird sie an den Kunden gesendet. Dies ist kein Ergebnis einer Brillnet‑Implementierung. Es veranschaulicht den Workflow und die Punkte, an denen Menschen Entscheidungen treffen.

Die Bewertung sollte auch die Kosten für die Pflege der Quellen erfassen. Jemand muss die genehmigte Service‑Beschreibung aktualisieren, wenn ein Anbieter oder ein Standort wechselt. Zählen Sie diesen Aufwand in die Gesamtkosten‑Rechnung ein. Ein Assistent, der schnelle Antworten aus veralteter Evidenz liefert, kann die sichtbare Bearbeitungs‑Zeit reduzieren, während das verborgene operative Risiko steigt.

Vorbereitung auf Vorfälle und Ausstieg

Nach einem unautorisierten Lese‑ oder Schreib‑Vorgang stoppen Sie die betroffene Integration, bewahren notwendige Protokolle und bestimmen das Ausmaß des Ereignisses. Die verantwortliche Person aktiviert die organisationsinterne Bewertung nach den eigenen Verfahren, vertraglichen Pflichten und geltendem Recht. DORA, DSGVO und NIS2 haben jeweils eigene Anwendungs‑Umfänge und Regeln; nicht jedes Ereignis löst jede Melde‑Route aus. [1][2][4]

Stimmen Sie den Export von Dokumenten, Antworten, Beziehungen und Evidenz vor dem Start ab. Prüfen Sie, ob genehmigte Aufzeichnungen nach der Trennung des Modells weiterhin nutzbar bleiben. Legen Sie die Widerruf‑Regelungen für technische Konten, den Umgang mit verbleibenden Kopien und die Bestätigung fest, dass Ausstiegs‑Maßnahmen abgeschlossen sind. Der Ausstieg gehört in das ursprüngliche Service‑Design, nicht erst, wenn ein Vertrag endet.

Den Prozess in die erste Diskussion einbringen

Vor dem Start stimmt Brillnet den Werkzeug‑Umfang, Rollen, Daten und Ausstiegs‑Arrangements ab. Bereiten Sie einen Beispiel‑Fragebogen ohne vertrauliches Material, die verfügbare Quell‑Liste und den aktuellen Aufwand für die Beantwortung vor. Identifizieren Sie die Person, die befugt ist, die Aussagen zu akzeptieren. Diese Details ermöglichen die Bewertung der Machbarkeit und der Kosten der Automatisierung.

Send your process description to Brillnet. For requirements and evidence, explore Pulsar GRC. For learning based on procedures, explore CrewShift. An implementation is useful when it reduces total work while preserving the reliability of its answers.

Quellen

Verifiziert am 2. Oktober 2026. Prüfen Sie den regulatorischen Anwendungs‑Umfang und die detaillierten Anforderungen für das jeweilige Unternehmen und den jeweiligen Service. Der Pilot und das Beispiel sind Autor‑Vorschläge.

1. DORA — Regulation (EU) 2022/2554, Articles 2, 28–31 and 64. EUR‑Lex; accessed: 2026‑10‑02.
2. GDPR — Regulation (EU) 2016/679, Articles 5, 6, 28 and 32–35. EUR‑Lex; accessed: 2026‑10‑02.
3. AI Act: intended purpose and risk classification and current consolidated Regulation (EU) 2024/1689. European Commission and EUR‑Lex; accessed: 2026‑10‑02.
4. NIS2 — Directive (EU) 2022/2555, Articles 2, 4, 21 and 23 and annexes. EUR‑Lex; accessed: 2026‑10‑02.
5. OWASP LLM01:2025 — Prompt Injection. OWASP GenAI Security Project; accessed: 2026‑10‑02.
6. NIST AI 600‑1 — Generative Artificial Intelligence Profile. NIST; accessed: 2026‑10‑02. Voluntary guidance, not EU law.