Artikel
Datenschutz beim KI-Einsatz in der Bank: Was 'Daten bleiben bei uns' bedeutet
Komponente | Anforderung |
|---|---|
Rechenzentrum | Deutschland, europäischer Betreiber |
Hardware | Dediziert oder On-Premise |
Modell-Training | Auf anonymisierten Daten, lokal |
Inferenz | Lokal oder dedizierte Cloud |
Telemetrie | Deaktiviert oder auf Metadaten beschränkt |
API-Aufrufe | Keine externen Modelle für Kundendaten |
Modell-Export | Möglich, ohne Abhängigkeit vom Anbieter |
Datenschutz beim KI-Einsatz in der Bank: Was "Daten bleiben bei uns" bedeutet
"Unsere Daten verlassen nicht das Haus." Diesen Satz hören wir in jedem Gespräch mit Finanzdienstleistern. Er ist richtig und wichtig. Aber er ist auch unschärfer, als er klingt.
Was genau bedeutet "bei uns"? Das eigene Rechenzentrum? Ein deutsches Rechenzentrum eines Cloud-Anbieters? Ein europäisches Rechenzentrum eines US-Anbieters? Jede Antwort hat andere Implikationen für Datenschutz, Regulatorik und Vertragsgestaltung.
Die drei Ebenen der Datenhoheit
Ebene 1: Wo liegen die Daten?
Die physische Lokation der Daten bestimmt, welches Recht gilt. Daten in einem deutschen Rechenzentrum unterliegen deutschem Datenschutzrecht und der DSGVO. Soweit klar.
Aber: Ein deutsches Rechenzentrum eines US-Anbieters unterliegt potenziell auch US-Recht. Der CLOUD Act erlaubt US-Behörden unter bestimmten Umständen Zugriff auf Daten, die von US-Unternehmen gespeichert werden — unabhängig vom Standort.
Für Banken bedeutet das: Ein deutsches Rechenzentrum reicht nicht. Der Betreiber muss ein europäisches Unternehmen sein, das nicht dem CLOUD Act unterliegt. Oder die Daten müssen verschlüsselt sein, wobei der Schlüssel beim Institut verbleibt.
Ebene 2: Wer verarbeitet die Daten?
KI-Modelle brauchen Daten zum Trainieren und zum Ausführen (Inferenz). Die Frage ist: Wo findet diese Verarbeitung statt?
On-Premise: Training und Inferenz auf eigener Hardware im eigenen Rechenzentrum. Maximale Kontrolle. Höchste Investitionskosten. Sinnvoll für Institute mit bestehender GPU-Infrastruktur.
Dedizierte Cloud: Eigene, isolierte Instanzen bei einem europäischen Cloud-Anbieter. Keine geteilte Hardware mit anderen Kunden. Guter Kompromiss zwischen Kontrolle und Skalierbarkeit.
Öffentliche Cloud mit Datenisolation: Geteilte Infrastruktur, aber logisch getrennte Datenverarbeitung. Vertragliche Zusicherungen, keine technische Isolation. Für regulierte Finanzinstitute in den meisten Fällen nicht ausreichend.
Ebene 3: Wohin fließen die Daten?
Die subtilste Frage. Auch wenn Daten lokal gespeichert und verarbeitet werden, können sie abfließen:
• Telemetrie: Manche KI-Frameworks senden Nutzungsdaten an den Hersteller. Anonymisiert — aber Metadaten über Transaktionsvolumen oder Modellnutzung können sensibel sein.
• Modell-Updates: Wenn ein Modell extern aktualisiert wird, stellt sich die Frage: Fließen die lokalen Trainingsdaten in das Update zurück?
• API-Aufrufe: Wird ein externes Modell per API angesprochen (etwa für Textanalyse), verlassen die Eingabedaten das Institut. Auch wenn die Antwort zurückkommt, waren die Daten kurzzeitig extern.
Was eine BaFin-konforme KI-Architektur erfordert
Kein Datenabfluss an öffentliche Modelle
Kundendaten dürfen nicht an OpenAI, Google oder andere Anbieter öffentlicher Modelle gesendet werden. Nicht für Training, nicht für Inferenz, nicht für Textanalyse. Das ist keine Empfehlung, das ist regulatorische Anforderung.
Nachvollziehbare Datenverarbeitung
Jede Verarbeitung von Kundendaten durch ein KI-Modell muss dokumentiert sein. Welche Daten wurden wann von welchem Modell verarbeitet? Zu welchem Zweck? Das ist Teil der DSGVO-Dokumentationspflicht und der MaRisk-Anforderungen.
Modell-Training mit anonymisierten Daten
Wenn Modelle mit Bankdaten trainiert werden, müssen die Trainingsdaten anonymisiert oder pseudonymisiert sein. Eine Rückführung auf einzelne Kunden darf nicht möglich sein. Das erfordert technische Maßnahmen, nicht nur organisatorische.
Ausstiegsfähigkeit
Was passiert, wenn der KI-Anbieter wechselt oder ausfällt? Die Modelle müssen exportierbar sein. Die Trainingsdaten müssen beim Institut verbleiben. Kein Vendor Lock-in auf Modellebene.
Wie eine sichere Architektur aussieht
Zusammengefasst:
Der Unterschied zwischen Versprechen und Architektur
"Daten bleiben bei uns" ist ein Versprechen. Die Architektur muss es einlösen. Das erfordert technische Entscheidungen auf jeder Ebene: Infrastruktur, Framework, Modellwahl, Betriebsmodell.
Ein Anbieter, der diese Fragen nicht beantworten kann, hat die Architektur nicht durchdacht.
Nächster Schritt
Lassen Sie uns in 30 Minuten prüfen, wo KI in Ihrem Finanzunternehmen den größten Hebel hat — regulatorisch sicher, unverbindlich und kostenfrei.
Weiterlesen
800 Institute, ein Modell: Skalierung mit bankindividuellen Regeln
Ein KI-Modell für 800+ Institute. Jedes mit eigenen Regeln. Wie Skalierung und Individualität im genossenschaftlichen Verbund koexistieren.
16. März 2026
Integrationsmuster für Banken und Finanzdienstleister: Batch, API und die Schicht dazwischen
Wie Integrationsschichten die Datenlücken zwischen Kernbanksystemen und Partnersystemen schließen. Batch-Verarbeitung, API-Gateways und Datennormalisierung im Überblick.
25. März 2026
Datenlücken zwischen Bank und Finanzdienstleister: Wo die Brüche liegen
Banken und externe Finanzdienstleister arbeiten mit denselben Kunden — aber unterschiedlichen Datenständen. Wo die kritischen Lücken entstehen und warum sie sich nicht von allein schließen.
25. März 2026