Souveräne KI
Generative KI in Banken ohne Bruch des Bankgeheimnisses
Kurze Antwort: Der einzige Ansatz, der die Vertraulichkeitsfrage beseitigt, anstatt sie nur zu verwalten, besteht darin, das Modell auf einer vom Bankinstitut selbst kontrollierten Infrastruktur zu betreiben und das Need-to-know-Prinzip innerhalb dieser Bereitstellung genauso streng durchzusetzen, wie es die Bank bereits überall sonst tut. Alles andere ist eine Offenlegung gegenüber Dritten, die gerechtfertigt werden muss. Und diese Rechtfertigung ist schwieriger, als die meisten KI-Anbieter behaupten, da die Bankkundenvertraulichkeit nicht dieselbe Verpflichtung wie der Datenschutz ist.
Dieser Artikel befasst sich mit dieser Unterscheidung und den daraus resultierenden Konsequenzen. Es handelt sich hierbei nicht um eine Rechtsberatung, und die Rechtslage unterscheidet sich je nach Land!
Das Bankgeheimnis ist eine vom DSGVO-Datenschutz separate Verpflichtung
Die meisten Unterlagen von KI-Anbietern behandeln die "DSGVO-Konformität" als die Ziellinie für europäische Banken. Dabei ist das nicht einmal das richtige Rennen.
Das Datenschutzrecht bietet Ihnen einen bewährten Weg zur Einbindung einer externen Partei. Sie schaffen eine Rechtsgrundlage, ernennen den Anbieter zum Auftragsverarbeiter, unterzeichnen einen Auftragsverarbeitungsvertrag (AVV), regeln internationale Datentransfers, und die Vereinbarung steht auf soliden Beinen. Dieses Konstrukt macht die gesamte Cloud-Branche überhaupt erst arbeitsfähig.
Das Bankgeheimnis bietet diesen Weg nicht, und es lohnt sich zu verstehen, warum. Es wurde bei der EU-Harmonisierung weitgehend außen vor gelassen, ist somit nationales Recht geblieben und variiert erheblich. In Österreich ist es in Paragraph 38 des Bankwesengesetzes (BWG) kodifiziert, wobei eine strafrechtliche Haftung nach Paragraph 101 BWG greift. Das Schweizer Bankgeheimnis ist in Artikel 47 des Bundesgesetzes über die Banken und Sparkassen verankert und zieht eine Freiheitsstrafe von bis zu drei Jahren nach sich. Luxemburg behandelt den Verstoß gegen das Berufsgeheimnis im Bankensektor als Straftat. Das deutsche Bankgeheimnis funktioniert wiederum anders und ergibt sich in erster Linie aus dem Vertragsverhältnis und dem Datenschutzrecht und weniger aus einem eigenständigen gesetzlichen Privileg.
Gemeinsam ist diesen Regelungen die Art der Pflicht: Informationen, die im Rahmen der Kundenbeziehung erlangt werden, dürfen nicht an Dritte weitergegeben werden. Es gibt keine allgemeine Bestimmung, die einen Dritten zu einer Verlängerung der Bank macht, so wie es ein Auftragsverarbeitungsvertrag im Datenschutzrecht tut. Die üblichen Ausnahmen sind eng gefasst, und die verlässlichste davon ist die ausdrückliche Einwilligung des Kunden selbst.
Die österreichische Rechtsprechung zeigt, wie streng dies gehandhabt wird. Der Oberste Gerichtshof hat entschieden, dass die Abtretung einer Forderung durch eine Bank nicht wirksam war, da die Übertragung zwangsläufig die Offenlegung von Informationen über den Schuldner beinhaltete, was das Bankgeheimnis untersagt. Der Empfänger hatte einen Vertrag. Der Vertrag war jedoch nicht die Lösung.
Wendet man diese Logik auf eine KI-Bereitstellung an, ändert sich die Fragestellung entscheidend. Die Frage ist nicht, ob der Anbieter vertrauenswürdig, zertifiziert oder vertraglich gebunden ist. Sie lautet, ob überhaupt Kundeninformationen die Bank verlassen haben.
Vier Optionen, und nur eine davon vermeidet die Offenlegung
Eine öffentliche API. Kundeninhalte werden an einen externen Anbieter übermittelt und auf dessen Infrastruktur verarbeitet. Was auch immer in den Bedingungen über Training und Speicherung steht: Ein Dritter hat die Informationen erhalten. Im Sinne des Datenschutzrechts handelt es sich hierbei um eine Auftragsverarbeitung. Im Sinne des Bankgeheimnisses ist es eine Offenlegung, die einer eigenen Rechtfertigung bedarf.
Ein Enterprise-Vertrag mit deaktivierter Datenspeicherung. Besser, und das in erheblichem Maße für Datenschutzzwecke. Eine Speicherung von Null ist jedoch eine Zusage darüber, was der Empfänger mit den Daten tut, und keine Erklärung, dass kein Empfänger existiert hat. Die Analyse der Offenlegung bleibt unverändert.
Ein privater Endpunkt in einer europäischen Cloud-Region. Dies klärt die Frage des Datenstandorts (Residency). Es löst jedoch nicht das Problem der Offenlegung, da der Betreiber immer noch ein Dritter ist. Unterliegt dieser Betreiber einer ausländischen Gerichtsbarkeit, hat die Bank der ersten Frage nur eine zweite hinzugefügt, anstatt eine von beiden zu lösen.
Das Modell läuft auf der bankeigenen Infrastruktur. Kein Dritter erhält die Inhalte, da die Verarbeitung auf Hardware erfolgt, die die Bank kontrolliert, und zwar innerhalb ihres eigenen Netzwerks. Es gibt keine Offenlegung zu rechtfertigen, weil schlichtweg keine stattgefunden hat.
Das ist das gesamte strukturelle Argument, und man sollte es klar aussprechen, anstatt es schönzureden. Die ersten drei Optionen verwalten ein Vertraulichkeitsproblem. Die vierte Option beseitigt es. Bei Anwendungsfällen, die identifizierbare Kundeninformationen in einer Rechtsordnung betreffen, in der das Bankgeheimnis strafrechtlich geschützt ist, ist dieser Unterschied keine bloße Präferenz, sondern essenziell.
Danach verlagert sich das Problem in die Bank
Das ist der Teil, der oft zu wenig geplant wird, und hier scheitern Implementierungen, nachdem das Häkchen bei der Datenhoheit (Souveränität) gesetzt wurde.
Sobald das Modell intern läuft, ist nicht mehr die externe Offenlegung das Risiko, sondern das interne Need-to-know-Prinzip. Banken wissen das bereits. Die Informationsbarrieren zwischen Beratung und Handel existieren gerade deshalb, weil die Aussage "Wir sind alle ein Institut" keine angemessene Vertraulichkeitsposition darstellt. Ein KI-Assistent, der abteilungsübergreifend Daten abrufen kann, ist in der Lage, Informationen über eine Barriere hinweg zu bewegen, deren Entwicklung Jahre gedauert hat, ohne dass jemals etwas das Gebäude verlässt.
Drei spezifische Fehlerszenarien sind besonders erwähnenswert:
Ein Datenabruf, der bestehende Berechtigungen ignoriert. Wenn der Assistent Dokumentenspeicher durchsuchen kann, die der einzelne Benutzer selbst nicht öffnen dürfte, wird er zu einem Tool zur Rechteausweitung (Privilege Escalation). Der Abrufbereich muss die Berechtigungen des Benutzers selbst erben, nicht die des Dienstkontos.
Ein gemeinsam genutzter Credential (Zugangsdaten) vor dem Modell. Wenn jede Anwendung mit demselben Schlüssel aufruft, kann die Bereitstellung nicht zwischen dem Compliance-Beauftragten und dem Praktikanten unterscheiden, und sie kann dies auch nicht nachweisen. Das Need-to-know-Prinzip ist eine personenbezogene Kontrolle. Es kann nicht von einem System durchgesetzt werden, das nie erfährt, wer die Person überhaupt ist.
Prompts im Protokollierungssystem (Logging Stack). Ein Kundenbetreuer fügt die Situation eines namentlich genannten Kunden in einen Prompt ein. Wenn der vollständige Prompt-Inhalt in die Protokolle geschrieben wird, befinden sich diese Kundeninformationen nun in einem operativen System mit einem völlig anderen Zugriffskonzept als die Bankplattform – lesbar für Personen, die überhaupt keine Kundenbeziehung haben. Dies ist eine der häufigsten Feststellungen bei internen KI-Pilotprojekten, und sie entsteht eher durch Standardeinstellungen als durch eine bewusste Entscheidung.
Fragen Sie sich, was tatsächlich im Prompt stehen muss
Ein überraschend großer Teil des Nutzens von KI im Bankensektor erfordert überhaupt keine Kundenidentifikatoren. Das Entwerfen interner Richtlinien, das Zusammenfassen von Vorschriften, das Beantworten von Prozessfragen, das Generieren von Code, das Erstellen von Schulungsmaterialien oder das Erklären eines Produkts für einen Kollegen: Nichts davon benötigt einen Namen oder eine Kontonummer, und Vertraulichkeitspflichten gelten nicht für Informationen, die sich nie im Prompt befunden haben.
Für diejenigen Anwendungsfälle, die tatsächlich einen Kundenkontext erfordern, besteht die sinnvolle Vorgehensweise darin, bewusst zu entscheiden, welche Felder übergeben werden, und den Datenabruf auf das zu beschränken, was der anfragende Benutzer ohnehin sehen darf. Eine Pseudonymisierung auf Anwendungsebene hilft bei einigen Arbeitsabläufen, sollte jedoch nicht überbewertet werden: Eine hinreichend detaillierte Beschreibung der Umstände eines Kunden kann auch ohne Namen identifizierbar sein, und die Geheimhaltungspflichten erstrecken sich auf Tatsachen über die Beziehung, nicht nur auf Identifikatoren.
Ein praktikables Konzept
Betreiben Sie das Modell auf einer Infrastruktur, die die Bank kontrolliert. Dies beseitigt die Frage der Offenlegung, anstatt darüber zu diskutieren.
Verknüpfen Sie jede Anfrage mit einer realen Identität über den bestehenden Identitätsanbieter der Bank, nicht über einen gemeinsamen Schlüssel.
Beschränken Sie den Datenabruf auf die eigenen Berechtigungen des Benutzers, sodass der Assistent nicht sehen kann, was der Person verwehrt bleibt.
Ziehen Sie klare Trennungen an der Bereitstellungsgrenze, wo Informationsbarrieren dies erfordern, da innerhalb einer einzelnen Serving-Instanz die Trennung eher logisch als physisch ist.
Entscheiden Sie explizit, was protokolliert wird. Entscheiden Sie dann, wer es lesen darf, und behandeln Sie Prompt-Inhalte in Protokollen als Kundeninformationen – denn das sind sie.
Führen Sie ein Nachweisprotokoll, das Sie vorlegen können. Welche Person, welches Modell, wann. Ein internes System ohne Zuordnungsmöglichkeit kann das Need-to-know-Prinzip nicht nachweisen, sondern nur behaupten.
Dokumentieren Sie die Aufteilung der Verantwortlichkeiten zwischen der Plattform, dem Infrastrukturteam und dem Anwendungseigentümer vor dem ersten Audit und nicht erst währenddessen.
Häufig gestellte Fragen
Kann eine Bank ChatGPT oder einen ähnlichen öffentlichen Dienst mit Kundendaten nutzen? Die Übermittlung von Kundeninformationen an einen externen Anbieter ist eine Offenlegung gegenüber Dritten. In Ländern, in denen das Bankgeheimnis strafrechtlich geschützt ist, erfordert dies eine spezifische Rechtfertigung, am verlässlichsten die ausdrückliche Einwilligung des Kunden. Enterprise-Bedingungen und Aufbewahrungseinstellungen ändern zwar, was der Empfänger mit den Daten tut, nicht aber die Tatsache, dass ein Empfänger existiert hat.
Reicht die DSGVO-Konformität für das Bankgeheimnis im Bankensektor aus? Nein. Es handelt sich um getrennte Verpflichtungen. Das Datenschutzrecht bietet ein Auftragsverarbeiter-Konstrukt, das die Einbindung eines Anbieters legitimiert. Das Bankgeheimnis ist nationales Recht mit engeren Grenzen und ohne allgemeines Äquivalent, sodass eine Bank die DSGVO erfüllen und dennoch ein Problem mit dem Bankgeheimnis haben kann.
Löst eine EU-Cloud-Region das Problem? Sie löst die Frage des Datenstandorts. Der Cloud-Betreiber bleibt jedoch ein Dritter, der Kundeninformationen erhält. Unterliegt dieser Betreiber einer ausländischen Gerichtsbarkeit, hat die Bank zwei Fragen statt einer.
Macht uns der Betrieb von KI auf unseren eigenen Servern standardmäßig vertraulich? Er beseitigt die Frage der externen Offenlegung. Er löst jedoch nicht das interne Need-to-know-Prinzip, den Datenabruf über Informationsbarrieren hinweg oder in Protokolle geschriebene Prompt-Inhalte. Das sind die verbleibenden Risiken, für die entsprechende Sicherheitsvorkehrungen getroffen werden müssen.
Wie startet man mit dem geringsten Risiko? Mit Anwendungsfällen, die überhaupt keine Kundenidentifikatoren benötigen. Das Entwerfen von Richtlinien, die Zusammenfassung von Vorschriften, interne Prozessfragen, Programmcode. Der Nutzen ist real und die Vertraulichkeitsanalyse kurz.
Fazit
Die Frage für Banken lautet nicht "welcher KI-Anbieter ist konform", sondern "hat uns etwas verlassen, und können wir nachweisen, wer was gesehen hat". Die erste Hälfte wird durch die Architektur beantwortet. Die zweite Hälfte wird durch die Kontrollen rund um das Modell beantwortet und durch die Frage, ob die Bank eine Anfrage einer Person und nicht nur einer Anwendung zuordnen kann.
Xinity betreibt Open-Source-Modelle auf der bankeigenen Infrastruktur, wobei der Zugriff über Single Sign-On (SSO) und rollenbasierte Zugriffskontrolle an reale Identitäten gekoppelt ist und jede Inference-Anfrage der Person zugeordnet werden kann, die sie gestellt hat. Die Datenverarbeitung bleibt innerhalb des Instituts. Und der Nachweis ebenso.
KI-Erklärung
Dieser Artikel wurde mit Unterstützung von KI erstellt und vor der Veröffentlichung vom Xinity-Team geprüft, faktenbasiert kontrolliert und bearbeitet.
Referenzierte Quellen
Paragraph 38 des österreichischen Bankwesengesetzes (BWG) und der Umfang des österreichischen Bankgeheimnisses, einschließlich der Entscheidung des Obersten Gerichtshofs zur Forderungsabtretung: https://www.taylorwessing.com/en/insights-and-events/insights/2020/03/austrian-banking-secrecy
Vergleichshinweis, dass das deutsche Bankgeheimnis in erster Linie aus dem Vertrag und dem Datenschutzrecht resultiert und nicht aus einem gesonderten gesetzlichen Privileg: https://practiceguides.chambers.com/practice-guides/comparison/1132/17912/27952-27954-27956-27958-27962-27964-27966-27968-27970-27972-27974
Das Bankgeheimnis als weitgehend unharmonisiertes nationales Recht in der EU und die Ausnahme der schriftlichen Zustimmung gemäß § 38 Abs. 2 Nr. 5 BWG: