KI-Risiken: Was die BaFin für den sicheren Einsatz von LLMs empfiehlt

Im Dezember 2025 hat die BaFin ihre Orientierungshilfe zu IKT-Risiken beim Einsatz von KI in Finanzunternehmen veröffentlicht. Das Dokument ist keine verbindliche Auslegung von DORA, aber es benennt Risiken, die bei der Nutzung von KI-Systemen unter DORA relevant sind, und gibt konkrete Hinweise, wie Finanzunternehmen mit ihnen umgehen können. Auffällig ist dabei, dass das Dokument in Kapitel 5.2 zwei Schutzstufen für Daten in der Verarbeitung beschreibt: eine Verschlüsselung der Daten während der Verarbeitung und, wo das nicht möglich ist, zumindest eine getrennte und geschützte Verarbeitungsumgebung.

Was die BaFin als wesentliches IKT-Risiko beim KI-Einsatz einstuft

Die Orientierungshilfe unterscheidet drei Infrastrukturvarianten für den Betrieb eines LLM-basierten KI-Assistenten:

1. Betrieb im eigenen Rechenzentrum
2. Betrieb im eigenen Cloud-Tenant
3. Betrieb außerhalb des eigenen Tenants

Die dritte Variante ist heute in der Praxis am weitesten verbreitet. Ein Finanzunternehmen nutzt ein großes Sprachmodell über eine API, die von einem externen Anbieter betrieben wird. Das Modell läuft dabei nicht auf der Infrastruktur des Unternehmens, sondern auf der Infrastruktur des Anbieters. Häufig nutzt auch dieser Anbieter wiederum Cloud-Infrastruktur eines weiteren Dienstleisters.

Für diese Variante formuliert die BaFin das wesentliche Risiko, dass Daten den eigenen Tenant verlassen und zum Service- und Cloud-Anbieter fließen. Die Orientierungshilfe empfiehlt als Gegenmaßnahmen unter anderem Filter, die prüfen ob Eingabedaten vertraulich sind, Einschränkungen beim Daten-Upload für bestimmte Nutzergruppen und die Vergabe geringerer Datenzugriffsrechte an die KI-Anwendung. Diese Kontrollen muss das Finanzunternehmen jedoch selbst entwickeln, bereitstellen und warten. Für Unternehmen mit einer Cloud-First-Strategie bedeutet das, für jeden KI-Use-Case eine eigene Filterinfrastruktur einzuführen und dauerhaft zu pflegen. Sie muss bei jeder Änderung nachgezogen werden, etwa wenn eine neue Nutzergruppe hinzukommt oder sich die Sensitivität der verarbeiteten Daten ändert.

Das sind organisatorische Kontrollen. Sie reduzieren die Wahrscheinlichkeit, dass besonders sensible Daten in das Modell gelangen, aber sie sind nicht dafür gemacht, den Zugriff auf sensible Daten technisch zu verhindern. Der Anbieter hat weiterhin technischen Zugriff auf alles, was an sein Modell gesendet wird. Als einzige Schutzmaßnahme reichen Filter oft nicht aus. Der Kontext einer Anfrage bleibt häufig erkennbar, und nicht jede vertrauliche Information lässt sich einfach „schwärzen“.

Die Orientierungshilfe begrenzt dieses Risiko zudem nicht auf den Modellanbieter. In Kapitel 5.2 (Cloud-Spezifika) hält sie im Rahmen der Due Diligence fest, dass ein Finanzunternehmen bei der Nutzung von Cloud-Dienstleistungen „auch die Risiken eines unautorisierten Datenabflusses, auch an den Cloud-Anbieter“ berücksichtigen soll. Das wesentliche Risiko der Variante 3 ist damit doppelt: Daten verlassen den eigenen Tenant nicht nur in Richtung des Service-Providers, sondern liegen auch in der Infrastruktur des Cloud-Anbieters offen, auf der die Inferenz läuft.

Was DORA Art. 9 und die BaFin-Orientierungshilfe Kap. 5.2 an dieser Stelle verlangen

Kapitel 5.2 der Orientierungshilfe formuliert eine Anforderung, die über Filter und Policies hinausgeht. Sinngemäß heißt es dort: KI-Systeme werden nach Datenklassifizierung und IKT-Risikobewertung verschlüsselt, und zwar für Daten in Speicherung, Übertragung und Verarbeitung (DORA Art. 9 Abs. 2, näher ausgestaltet durch Art. 6 und 7 der Delegierten Verordnung (EU) 2024/1774, dem technischen Regulierungsstandard zum IKT-Risikomanagement). Wo Verschlüsselung während der Verarbeitung nicht möglich ist, sind zumindest andere Maßnahmen erforderlich, insbesondere die Verarbeitung in einer getrennten und geschützten Umgebung.

Das ist der entscheidende Satz. Er beschreibt keine Filterlösungen oder Datenzugriffskonzepte, sondern eine Verarbeitungsumgebung, die strukturell gegen unautorisierten Zugriff geschützt ist. Zusammen mit dem Due-Diligence-Hinweis aus Kapitel 5.2 deckt er beide Risikoquellen der Variante 3 ab. Den Abfluss sensibler Daten an den Modellanbieter und an den Cloud-Anbieter. Genau das liefert Confidential Computing.

Wie Privatemode AI dieses Problem löst

Privatemode AI ist ein GenAI-Inferenzdienst, bei dem Prompts und Antworten in einer hardwareisolierten Umgebung verarbeitet werden. Weder der zugrunde liegende EU-Cloud-Provider noch Edgeless Systems als Betreiber des Dienstes können auf den Inhalt von Anfragen oder Antworten zugreifen. Das ist keine vertragliche Zusicherung, sondern eine technisch erzwungene Eigenschaft der Architektur. Dabei wird die Isolation durch die Hardware durchgesetzt, nicht durch eine Richtlinie.

Das hat zwei praktische Konsequenzen. Erstens entfällt die Notwendigkeit, eine eigene Filterinfrastruktur aufzubauen. Datensicherheit ist hier keine zusätzliche Schicht, die dem Dienst vorgeschaltet wird, sondern fest in die Inferenzumgebung integriert. Zweitens ist die Schutzaussage unabhängig vom Anbieter überprüfbar. Durch Remote Attestation kann jeder Kunde verifizieren, dass die versprochene Umgebung tatsächlich vorhanden ist, ohne Edgeless Systems dabei vertrauen zu müssen.

Privatemode AI ist auf Contrast aufgebaut, dem Open-Source-Framework von Edgeless Systems für Confidential Computing in Kubernetes, dessen Quellcode vollständig öffentlich ist und reproduzierbar gebaut wird. Bestehende KI-Integrationen lassen sich mit minimalen Anpassungen auf Privatemode AI umstellen. Es muss lediglich ein anderer API-Endpunkt ausgewählt werden.

Was das für DORA-Compliance in Finanzunternehmen bedeutet

Die BaFin-Orientierungshilfe beschreibt Variante 3, das Verwenden externer SaaS-Dienste, als die risikoreiche Option und empfiehlt vor allem organisatorische Kompensationsmaßnahmen. Privatemode geht auf Basis von Confidential Computing darüber hinaus, indem es technisch sicherstellt, dass weder der Anbieter noch Dritte auf die verarbeiteten Daten zugreifen können. Das entspricht der höheren der beiden Schutzstufen aus Kapitel 5.2, der getrennten und geschützten Verarbeitungsumgebung. Der Schutz sensibler Daten liegt damit nicht mehr bei den einzelnen Nutzern.

Das hat auch praktische Konsequenzen für Nachweispflichten unter DORA. Audit- und Kontrollrechte bis in die Kette der Unterauftragsverarbeiter, die Kapitel 4.2 im Kontext von DORA Art. 30 verlangt, lassen sich mit Remote Attestation und reproduzierbaren Builds technisch belegen, nicht nur vertraglich absichern. Der Nachweis gegenüber der BaFin basiert auf kryptografischer Evidenz statt auf Zusicherungen des Anbieters.

Privatemode AI ersetzt nicht die gesamte Compliance-Arbeit rund um den Einsatz von KI-Systemen unter DORA. Governance, Risikobewertung, Incident-Management und die übrigen Anforderungen der Orientierungshilfe bleiben bestehen. Aber es adressiert genau den Kern des Problems, das die BaFin für Variante 3 benennt: den unautorisierten Datenabfluss an den Modell- und Cloud-Anbieter als wesentliches IKT-Risiko. Genau hier setzt Confidential Computing an. Es verhindert diesen Zugriff technisch, statt ihn nur organisatorisch unwahrscheinlicher zu machen.

Wer die Architektur und Sicherheitseigenschaften prüfen möchte, findet die vollständige Dokumentation auf docs.privatemode.ai. Der Quellcode ist öffentlich zugänglich.