KI in der Banken-IT: Woran Projekte scheitern – bevor das erste Modell live geht

Drei Fragen entscheiden, ob Ihr KI-Projekt die nächste Revision überlebt: Wo liegen Daten? Wer hatte Zugriff? Welcher Schlüssel wurde wann genutzt? Wer das nicht lückenlos belegen kann, hat ein Problem.

von Malte Sukopp, Buildsimple

Erfahrungsgemäß scheitern viele KI-Projekte in Banken und Versicherern nicht an der Modellqualität. Sie scheitern daran, dass die Nachweiskette reißt, weil niemand dokumentiert hat, welche Daten wann wohin geflossen sind und wer Zugriff hatte. Jede Anfrage, die ein Bankmitarbeiter oder ein automatisierter Prozess an ein Large Language Model über einen Cloud-Dienst stellt, wird auf Plattformebene maschinell klassifiziert.

Prompts sind kein geschlossener Raum

Bei Amazon Bedrock werden Eingaben und Ausgaben im Rahmen der automatisierten Missbrauchserkennung maschinell klassifiziert (u. a. Hate/Insults/Sexual/Violence/Misconduct/Prompt-Attack; Level none/low/medium/high) und laut AWS erfolgt dies vollautomatisch ohne Human Review. Zusätzlich können Kunden Amazon Bedrock Guardrails konfigurieren – Guardrails sind jedoch nicht standardmäßig aktiv, sondern müssen gezielt eingesetzt werden. Das gilt konkret für Modelle wie beispielsweise Claude von Anthropic, soweit sie über den AWS-Service Amazon Bedrock bezogen werden.
Was technisch als Schutzfunktion erscheint, ist regulatorisch ein zusätzlicher Daten­verarbeitungs­schritt – inklusive möglicher Subprozessoren, die in Ihrem AVV womöglich gar nicht auftauchen. Dieser muss in Rollen, Verträgen und Risikoanalysen sauber abgedeckt sein.

Für IT-Architekten bedeutet das konkret: Vor dem Einsatz eines LLM über einen Cloud-Dienst muss der vollständige Datenpfad kartiert sein.“

Welche Daten fließen als System- oder Prompt-Kontext in die Anfrage ein? Ist das mit dem Auftrags­verarbeitungs­vertrag vereinbar? Ist es in der Datenschutz-Folgenabschätzung (DSFA) erfasst? Wer diese Fragen nicht vorab beantwortet hat, betreibt KI auf Basis einer Annahme – nicht einer Rechtsgrundlage.

Wer seinen Schlüssel nicht kontrolliert, kann keine Revision überstehen

Verschlüsselung schützt nur dann, wenn der Schlüssel nicht beim Anbieter liegt. Verwaltet der Cloud-Anbieter die Schlüssel selbst, kann nicht ausgeschlossen werden, dass er theoretisch auf die Daten zugreifen kann – was regulatorisch bereits als inakzeptables Restrisiko eingestuft werden kann. Für regulierte Institute ist das kein akzeptabler Zustand.

Die Lösung ist Bring Your Own Key (BYOK): Der Kunde generiert und kontrolliert die Verschlüsselungs­schlüssel selbst, rotiert sie nach eigenem Zeitplan und kann sie bei Bedarf invalidieren – wobei je nach Implementierung eine Propagierungsverzögerung einzuplanen ist.“

Erst dann ist eine lückenlose Protokollierung möglich und nachvollziehbar, wer wann welchen Schlüssel für welches Datenobjekt genutzt hat. Ohne diese Protokollierung gibt es keinen Audit Trail, und ohne Audit Trail gibt es keine Revision.

Zugriff: Wer darf rein – und können Sie es beweisen?

Eine lückenlose Nachweiskette beginnt nicht beim Modell, sondern beim Login. Wer auf eine KI-Plattform mit Produktivdaten zugreift, muss über föderierte Identitäten via SAML 2.0 oder OpenID Connect authentifiziert sein – integriert in das bestehende Identity-Provider-System des Instituts. Nur so ist sichergestellt, dass Zugriffsrechte zentral verwaltet, sofort entzogen und vollständig protokolliert werden können. Multi-Faktor-Authentifizierung ist dabei keine Option, sondern Pflicht.

Das Berechtigungskonzept muss dokumentieren, wer auf welche Daten zugreifen darf.“

Ein Nutzer, der das System verlässt, darf keinen aktiven Token hinterlassen. Ein Service-Account, der nicht mehr genutzt wird, darf nicht einfach still weiterlaufen. Beides klingt selbstverständlich, ist allerdings in der Praxis bei erschreckend vielen Implementierungen nicht geregelt.

Training und Anonymisierung: Herstelleraussage ist keine Prüfung

Kunden in regulierten Umgebungen müssen sicherstellen, dass ihre Daten nicht unkontrolliert in allgemeine Trainingsprozesse einfließen. Diese fünf Fragen müssen vor Vertragsabschlüssen beantwortet sein:
Werden Kundendaten auch zum Training anderer Modelle des Anbieters genutzt?
Woher stammen die Daten bei vortrainierten Modellen?
Wer stellt das Modell bereit – der Anbieter direkt oder ein vorgelagerter Cloud-Service?
Wo werden die Daten verarbeitet?
Welche externen Testate liegen vor (ISO 27001, SOC 2 Type II, BSI C5)?
Vor dem Training mit Kundendokumenten muss eine Anonymisierung stattfinden, die Personenbezug entfernt – wobei die Qualität der Anonymisierung methodisch zu belegen ist. Entscheidend: Der Kunde muss die Qualität dieser Anonymisierung anhand der tatsächlich verarbeiteten Dokumente selbst prüfen können. Und er muss jederzeit einsehen können, welche Dokumente als Trainingsbasis verwendet wurden.

Je nach Einsatzzweck und Kundenanforderung kommen auch Large Language Models ohne eigenes Training zum Einsatz – etwa wenn aus Compliance-Gründen kein Fine-Tuning mit Kundendokumenten möglich ist und stattdessen Inferenz, ggf. mit Retrieval/RAG, genutzt wird.“

SIEM erkennt Bedrohungen und Anomalien

Die Anforderungen für den Einsatz von SaaS-Systemen nehmen kontinuierlich zu. Dazu gehört auch das Liefern strukturierter Logdaten an ein kundeneigenes Security Information & Event Management (SIEM). Regulierte Unternehmen betreiben Security Operations Center, sprich Teams, die präventiv Cyberrisiken begegnen.

Das Security Operations Center (SOC) setzt SIEM-Systeme wie beispielsweise Splunk ein, um Bedrohungen anhand definierter Schwellwerte zu erkennen.“

Durchsucht werden Logfiles und Audit-Trails nach ungewöhnlichem Verhalten. Das funktioniert nur, wenn der SaaS-Anbieter die richtigen Felder per Logshipping liefert.
Mindestanforderung für die Vendor-Evaluation und für Benutzeranmeldungen: timestamp, username, user_type (human / service_account), source_ip, auth_method, login_success / login_failure, failure_reason, session_id, request_id/correlation_id, token_issued / token_expired, role_assumed. Für API-Zugriffe: api_key_id, Ziel-Endpunkt-URL, request_payload_size, response_size.
Wer im Vendor-Assessment diese Feldliste nicht als Ausschlusskriterium führt, wird sie spätestens bei der nächsten DORA-Prüfung nachreichen müssen – unter deutlich ungünstigeren Bedingungen.

Meldefristen als operative Herausforderung

Operativ wird es besonders anspruchsvoll, wenn Incident-Fristen greifen: Unter DORA gelten für „major ICT-related incidents“ u. a. eine Erstmeldung binnen 4 Stunden nach Klassifizierung (spätestens 24 Stunden nach Kenntnisnahme), eine Zwischenmeldung spätestens 72 Stunden nach Erstmeldung und eine Abschlussmeldung spätestens einen Monat nach der letzten Zwischenmeldung. Für Datenschutzverletzungen sieht die DSGVO eine Meldung an die Aufsichtsbehörde binnen 72 Stunden ab Kenntnisnahme vor – nicht ab dem Zeitpunkt des Vorfalls selbst.

Wer es ernst meint, übt konkrete Szenarien.“

Ein Beispiel: Ein kleiner Kreis ist vorab informiert, ein Mitarbeiter löst gezielt eine Störung aus, Notfallpläne treten in Kraft. Intern wird eskaliert – zu Bereichsleitung, Informations­sicherheits­beauftragtem (ISB) und Datenschutzbeauftragtem (DSB). Der Krisenstab wird situativ um Krisenhelfer der Cyberversicherung oder externe Berater erweitert. Was technisch vorbereitet sein muss, sind vorausgefüllte Meldebögen mit allen gesetzlich vorgeschriebenen Datenpunkten – Art der Meldung, Datum und Uhrzeit der Kenntnisnahme, Beschreibung des Vorfalls, Auswirkungen, betroffene Systeme, geografische Reichweite, Schweregrad. Ergänzt wird das durch eine redundant vorgehaltene Notfallkontaktliste aller Kunden, die unabhängig vom primären Mailserver verfügbar ist. Wer im Ernstfall erst nach den Kontakten sucht, hat die Frist bereits gefährdet. Malte Sukopp, Buildsimple