On-Premise-Dokumenten-KI für Finanzdienstleister: BaFin, MaRisk & DORA

In einer Bank ist ein Cloud-KI-Prompt eine Auslagerungsentscheidung

Wenn eine Analystin eine Kreditakte, ein KYC-Dossier oder einen Prospektentwurf in einen Cloud-Chatbot kopiert, fühlt sich das nicht nach Beschaffung an. In einem regulierten Finanzinstitut ist es genau das. Das Dokument sind vertrauliche Mandantendaten, und der Chatbot ist ein externer IT-Dienst, der sie nun verarbeitet. Für eine Bank, einen Versicherer oder einen Vermögensverwalter ist es eine Auslagerung von ICT, ein vertrauliches Dokument in ein fremdes System zu geben, und Auslagerung gehört im Finanzsektor zu den am stärksten beaufsichtigten Tätigkeiten überhaupt.

Diese Umdeutung verschiebt die Frage. Sie lautet nicht mehr „taugt das Werkzeug etwas?", sondern „haben wir unsere Auslagerungs- und ICT-Risikopflichten erfüllt, bevor die Daten das Haus verlassen haben?" Für die meisten ad hoc genutzten Cloud-KI-Werkzeuge ist die ehrliche Antwort: nein.

Gleich vorweg klargestellt: Cloud-KI zu nutzen ist nicht illegal, und nichts hier behauptet das. Es ist zulässig, verbreitet und reguliert. Der Punkt ist genau, dass es reguliert ist, und die Pflichten treffen dich, das beaufsichtigte Institut, nicht den Anbieter.

MaRisk: Auslagerung ist erlaubt, aber nie umsonst

In Deutschland ist die MaRisk der BaFin (Mindestanforderungen an das Risikomanagement) das aufsichtliche Regelwerk, das das Kreditwesengesetz ausfüllt. Ihr Auslagerungsmodul, AT 9, gibt den Auslagerungspflichten aus § 25b KWG konkrete Gestalt. Der Kerngedanke ist einfach: Du kannst eine Tätigkeit auslagern, aber nicht die Verantwortung dafür.

Für alles, was als wesentliche Auslagerung gilt, erwartet AT 9, dass du die Arbeit vorab geleistet hast:

eine dokumentierte Risikoanalyse, die überhaupt erst entscheidet, ob die Vereinbarung wesentlich ist;
vertragliche Rechte auf Information, Prüfung und Weisung, damit du und deine Aufsicht tatsächlich in den Dienst hineinsehen können;
Vorkehrungen zur Fortführung für einen Ausstieg, damit die Funktion überlebt, wenn der Anbieter ausfällt oder der Vertrag endet;
eine laufende Überwachung und eine regelmäßige Neubewertung der Vereinbarung.

Ein Cloud-KI-Dienst, der Mandantendokumente einliest, ist ein starker Kandidat für eine wesentliche Auslagerung. Kannst du die Risikoanalyse, die Prüfrechte und den Ausstiegsplan nicht vorweisen, ist die Lücke deine, nicht die des Anbieters.

DORA: ICT-Drittparteirisiko wurde 2025 zur harten Regel

Die europäische Ebene ist inzwischen noch ausdrücklicher. DORA, der Digital Operational Resilience Act, Verordnung (EU) 2022/2554, gilt seit dem 17. Januar 2025. Sie behandelt die Abhängigkeit von ICT-Anbietern als Frage der Finanzstabilität, nicht als bloßes IT-Detail, und legt Pflichten auf, die direkt auf „wir haben Dokumente an einen KI-Anbieter geschickt" passen:

Du musst ein Informationsregister über alle ICT-Drittparteivereinbarungen führen (die ersten Meldungen an die zuständigen Behörden wurden 2025 fällig);
du musst das Konzentrationsrisiko steuern, die Gefahr, dass sich alle auf dieselbe Handvoll Anbieter stützen;
der Rahmen ergänzt eine Überwachung kritischer ICT-Drittdienstleister auf EU-Ebene.

Ein Cloud-KI-Anbieter ist im Sinne von DORA ein ICT-Drittdienstleister. Jeder vertrauliche Arbeitsablauf, den du durch einen solchen schiebst, ist eine weitere Zeile im Register, eine weitere zu überwachende Abhängigkeit und ein weiterer Beitrag zum Konzentrationsrisiko in einem Markt, in dem die zugrunde liegenden Modelle von sehr wenigen Firmen geliefert werden.

Darunter: Bankgeheimnis und der CLOUD Act

Zwei weitere Tatsachen liegen unter dem Regulierungstext. Die erste ist das Bankgeheimnis, die Vertraulichkeitspflicht der Bank gegenüber ihren Kunden, das nicht pausiert, nur weil der Kanal ein KI-Werkzeug ist. Die zweite ist die Rechtshoheit. Die meisten Spitzenmodelle laufen auf US-eigener Infrastruktur, und der US CLOUD Act erlaubt US-Behörden, einen US-kontrollierten Anbieter zur Herausgabe von Daten zu zwingen, die er kontrolliert, egal, wo sie gespeichert sind. Eine Frankfurt-Region kauft dir also Datenresidenz, aber keine Kontrolle: EU-Datenresidenz ist nicht dasselbe wie Datenhoheit, und „der Server steht in Europa" ist keine Verteidigung gegen eine US-Anordnung. Die Mechanik steht in Der CLOUD Act erklärt, die Lücke zwischen Residenz und Hoheit in On-Premise vs. deutsche Cloud.

Warum On-Premise oder BYOK die sauberste Antwort ist

Es gibt einen strukturellen Zug, der vieles davon auf einmal auflöst: Schick das Dokument gar nicht erst an einen Dritten. Lass die Inferenz On-Premise laufen, als On-Device-KI oder gegen deinen eigenen API-Schlüssel (BYOK), und die ICT-Drittparteiabhängigkeit für diesen Schritt verschwindet weitgehend.

Die regulatorischen Folgen ergeben sich unmittelbar:

MaRisk AT 9: verarbeitet kein externer Anbieter die Daten, ist der Inferenzschritt keine wesentliche Auslagerung mehr, die zu bewerten, zu prüfen und abzuwickeln wäre. Deine eigenen Systeme sind im Anwendungsbereich, aber die Auslagerungskette ist weg.
DORA: kein neuer kritischer ICT-Dienstleister fürs Register und kein zusätzliches Konzentrationsrisiko auf eine Handvoll US-Modellanbieter.
Bankgeheimnis und DSGVO: das vertrauliche Dokument verlässt nie deine Kontrolle, also gibt es keine Übermittlung und keine fremde Rechtshoheit zu bedenken.

Das ist keine Marketing-Unterscheidung. Es ist eine andere Architektur, die eine andere Klasse von Pflichten erzeugt.

Was Self-Hosting nicht tut

Sei genau über die Grenze, denn sie zu übertreiben ist ein eigenes Compliance-Risiko. Self-Hosting befreit dich nicht von MaRisk, DORA oder der DSGVO. Du bleibst die regulierte Partei und übernimmst Pflichten, statt sie abzuwerfen:

Dein eigenes ICT-Risikomanagement nach DORA gilt weiter für die Systeme, die du nun betreibst.
Betriebsstabilität, Änderungsmanagement und Sicherheit des lokalen Stacks liegen jetzt bei dir, nicht bei einem Anbieter.
Deine DSGVO-Pflichten als Verantwortlicher (Rechtsgrundlage, Betroffenenrechte, Richtigkeit, Governance) bleiben unverändert.
Und nochmals: Cloud-KI bleibt eine legitime, regulierte Option. Self-Hosting ist die sauberere Antwort für vertrauliche Finanzdokumente, nicht die einzig rechtmäßige.

Was sich ändert, ist die Gestalt des Problems: vom Beaufsichtigen eines ausländischen Anbieters, in den du nicht voll hineinsehen kannst, hin zum Steuern eines in sich geschlossenen Systems, das du voll kontrollierst. Für ein reguliertes Institut ist das meist die stärkere Position.

Wo pdf2okf ins Bild kommt

pdf2okf ist genau für dieses Ende des Spektrums gebaut. Es verwandelt ein PDF in OKF-kompatible Markdown-Konzeptdateien plus extrahierte Abbildungen, gebündelt als portabler OKFZ-Arbeitsbereich. (OKF, das Open Knowledge Format, ist Googles offener Standard; pdf2okf ist damit kompatibel, hat ihn aber nicht erfunden.) Ein Agent durchsucht diese einfachen Dateien dann direkt per grep (es gibt keine Vektordatenbank zu bauen, zu sichern oder zu auditieren), sodass Antworten deterministisch und belegt auf die Quellseite zurückzeigen statt aus einem undurchsichtigen Embedding-Speicher rekonstruiert zu werden.

Entscheidend: All das läuft lokal, On-Device oder gegen deinen eigenen Schlüssel (BYOK), sodass das vertrauliche Dokument nie deine Kontrolle verlässt. Es gibt keinen externen Auftragsverarbeiter fürs DORA-Register, keine wesentliche Auslagerung, die unter MaRisk AT 9 zu rechtfertigen wäre, und keine Bankgeheimnis-Frage zu prozessieren, weil nichts gesendet wurde. Du schuldest deinen eigenen Aufsehern weiterhin deine eigenen Kontrollen; pdf2okf nimmt schlicht die Dokumenten-KI-Abhängigkeit von Dritten heraus, die am schwersten zu verteidigen ist. Zur Datenschutz-Mechanik darunter siehe DSGVO-konforme KI.