Private Cloud oder SaaS? Warum Datensouveränität für Banken kein Komfort, sondern eine Anforderung ist

Die meisten Software-Entscheidungen in Unternehmen drehen sich heute um SaaS: schnelle Bereitstellung, niedrige Anfangsinvestitionen, automatische Updates, skalierbare Nutzungsmodelle. Für viele Anwendungsfälle ist SaaS die richtige Wahl.

Für KI-Systeme, die mit Kundendaten regulierter europäischer Banken arbeiten, ist die Entscheidung komplexer.

Dieser Artikel beschreibt sachlich, welche Anforderungen Banken an die Deployment-Architektur ihrer KI-Systeme stellen müssen — und warum Private Cloud oder On-Premises-Deployment für viele Institute nicht eine Option unter mehreren ist, sondern eine regulatorische und strategische Notwendigkeit.

Die regulatorische Ausgangslage

Banken in Deutschland und der EU unterliegen einem dichten Netz von Anforderungen, die den Umgang mit Kundendaten regeln:

DSGVO und BDSG: Personenbezogene Daten dürfen nur dann an Drittanbieter weitergegeben werden, wenn eine ausreichende Rechtsgrundlage vorliegt und die betroffenen Personen ausreichend informiert wurden. Der Export personenbezogener Daten in KI-Infrastrukturen außerhalb der EU — oder in Systeme, über die die Bank keine ausreichende Kontrolle hat — ist regulatorisch riskant.

DORA (Digital Operational Resilience Act): Ab Januar 2025 verpflichtet DORA Finanzinstitute in der EU, die Risiken durch dritte IKT-Dienstleister aktiv zu managen. Dazu gehört die Fähigkeit, kritische Systeme im Notfall schnell umzustellen oder in der eigenen Infrastruktur zu betreiben.

BaFin BAIT / ZAIT: Die Bankenaufsicht verlangt, dass ausgelagerte IT-Systeme prüfbar, kontrollierbar und im Notfall ins eigene Haus zurückholbar sind. Ein KI-System, dessen Betrieb vollständig von einem externen Anbieter abhängt, kann diese Anforderungen schwer erfüllen.

Bankgeheimnis: Das deutsche Bankgeheimnis (und äquivalente Regelungen anderer EU-Staaten) schützt Kundendaten vor unberechtigtem Zugriff Dritter — einschließlich des Datenzugriffs durch den Cloud-Anbieter selbst.

Was "Kontrolle" in der Praxis bedeutet

Das zentrale Argument für Private Cloud oder On-Premises-Deployment ist nicht Misstrauen gegenüber bestimmten Anbietern. Es ist das Bedürfnis nach nachweisbarer Kontrolle.

Konkret bedeutet das:

Datenlokalisierung: Die Bank weiß zu jedem Zeitpunkt, wo ihre Kundendaten gespeichert sind. Sie kann demonstrieren, dass keine Daten in Jurisdiktionen außerhalb der EU verarbeitet werden — oder in Bereiche, die dem US CLOUD Act oder vergleichbaren Regulierungen zugänglich sind.

Zugriffskontrolle: Kein externer Anbieter hat ohne explizite Autorisierung Zugriff auf die Rohdaten der Bank. In einem Multi-Tenant-SaaS-Modell ist diese Garantie schwerer nachzuweisen.

Modellkontrolle: Die Bank behält die Kontrolle über die eingesetzten Modellversionen. Sie kann einen spezifischen Modellstand einfrieren, prüfen und für Aufsichtsbehörden reproduzieren. Bei externen SaaS-Modellen, die automatisch aktualisiert werden, ist das kaum möglich.

Audit-Trail: Jeder Zugriff auf Kundendaten, jede Modellinferenz, jede Parameteränderung muss protokollierbar sein. Private Cloud-Deployments ermöglichen vollständige Audit-Trails unter der Kontrolle der Bank.

Die typischen Missverständnisse auf beiden Seiten

Missverständnis 1: Private Cloud ist immer teurer Das war vor zehn Jahren richtig. Heute bieten spezialisierte Anbieter Private-Cloud-Deployments auf dedizierten Cloudinfrastrukturen oder in der eigenen Rechenzentrumsumgebung zu Kosten an, die mit Multi-Tenant-SaaS vergleichbar oder bei höheren Datenvolumina sogar günstiger sind.

Missverständnis 2: SaaS bietet keine ausreichende Sicherheit Das ist zu pauschal. Es gibt SaaS-Lösungen mit SOC-2-Zertifizierung, deutschen Rechenzentren und robusten Datenschutzverträgen. Das Argument für Private Cloud ist nicht die absolute Sicherheitsstufe, sondern die nachweisbare Kontrolle — die in regulierten Umgebungen regulatorisch gefordert wird.

Missverständnis 3: On-Premises ist operativ untragbar Moderne On-Premises-Deployments ändern sich deutlich von dem, was vor fünf Jahren darunter verstanden wurde. Containerisierte Lösungen (Kubernetes, Docker) laufen auf Bankhardware mit demselben Abstraktionsgrad wie eine Cloud-Infrastruktur. Updates sind automatisierbar, Wartungsaufwand ist kalkulierbar.

Das richtige Modell für unterschiedliche Anforderungen

Nicht jede Banking-KI-Anwendung hat dieselben Anforderungen. Eine nüchterne Einschätzung:

Multi-Tenant-SaaS akzeptabel: Anonymisierte Benchmarkdaten, Marktdaten-Feeds, öffentlich zugängliche Enrichment-Quellen ohne Kundendaten.

Private Cloud empfohlen: Alle Anwendungen mit Kundendaten im Trainings- oder Inferenzprozess — CDP, Propensity-Modelle, Churn-Prediction, Next-Best-Action, Kampagnenautomatisierung.

On-Premises erforderlich: Kreditentscheidungssysteme mit regulatorischer Hochrisikoklassifikation, Systeme mit Zugriff auf besonders sensible Daten (Gesundheit, Familienstand), Institute mit sehr strikten internen Datenschutzrichtlinien.

Was das für die Kaufentscheidung bedeutet

Banken, die heute KI-Systeme evaluieren, sollten die Deployment-Frage nicht als nachrangige technische Entscheidung behandeln. Sie ist eine strategische Entscheidung, die regulatorische Prüfbarkeit, Kostenpfade und langfristige Autonomie bestimmt.

ACCELERAID wurde von Anfang an für den Betrieb in Private-Cloud- und On-Premises-Umgebungen entwickelt. Kein Multi-Tenant-Modell, keine Rohdaten außerhalb der kontrollierten Infrastruktur des Kunden, vollständige Audit-Trails.

Demo anfragen