Minimum Viable Bank: Wie geht’s weiter, wenn wichtige KI-Systeme ausfallen?

KI durchzieht inzwischen viele Banking-Prozesse, sodass Störungen oder Ausfälle erhebliche Auswirkungen haben können. Das müssen Banken beim Aufbau ihrer KI-Systeme berücksichtigen, denn auch im Worst Case muss der grundlegende Geschäftsbetrieb weiterlaufen.

von Armin Warda, Chief Tech­no­lo­gist Red Hat

In den vergangenen Monaten und Jahren sind Banken deutlich resilienter geworden, vor allem durch den Digital Operational Resilience Act (DORA). Sie haben neue Sicherheitslösungen eingeführt, ihre Infrastrukturen zumindest teilweise modernisiert und das IT-Risikomanagement verbessert. Dennoch liegt insbesondere mit Blick auf KI noch viel Arbeit vor ihnen, und das aus ganz unterschiedlichen Gründen.

Da wäre zunächst die Tatsache, dass fortschrittliche KI-Modelle wie Anthropics Mythos in der Lage sind, Schwachstellen in Software schneller und in größerer Menge zu finden als je zuvor, was den Arbeitsaufwand und den Zeitdruck beim Patchen erheblich erhöht.

Nahezu alle Finanzunternehmen nutzen inzwischen Open Source, unter anderem, um Innovationen schneller voranzutreiben.

Durch die vielen verschiedenen Komponenten wächst allerdings die Herausforderung zu evaluieren, in welchen Anwendungen verwundbare Komponenten stecken und welche Systeme betroffen sind, sowie die verfügbaren Updates und Patches sorgfältig zu testen, bei Bedarf anzupassen und anschließend einzuspielen. Zumal vielen Unternehmen erfahrungsgemäß eine vollständige und jederzeit aktuelle Sicht auf die eingesetzten Open-Source-Komponenten und deren direkte sowie indirekte Abhängigkeiten fehlt.

Eine Möglichkeit, Schwachstellen in den von Banken in selbstentwickelten Anwendungen eingesetzten Open-Source-Frameworks schneller zu beheben, bieten Initiativen wie Lightwell, das von Red Hat und IBM ins Leben gerufen wurde.“

Dennoch müssen sich Banken darauf vorbereiten, dass Systeme zur Abschirmung von Schwachstellen isoliert oder vorübergehend abgeschaltet werden müssen. Um dann wenigstens den grundlegenden Geschäftsbetrieb aufrechterhalten zu können, als Minimum Viable Bank, braucht es Risikomanagement, Notfallpläne, Ersatzsysteme und Ausweichlösungen – ganz so, wie es die europäische DORA-Regulierung verlangt. Welche Systeme und Anwendungen absolut überlebenswichtig sind, im Notfall temporär mit eingeschränktem Funktionsumfang, ergibt sich dabei aus den Anforderungen und Bewertungen der Business-Seite. Das ist gerade bei KI-Systemen wichtig, die mehr und mehr Geschäftsprozesse überwachen, steuern oder sogar selbstständig abwickeln und damit geschäftskritisch sind.

Wechseloptionen sind unverzichtbar

Im KI-Bereich existieren über Schwachstellen und Cyberangriffe hinaus zahlreiche Risiken, mit denen sich Banken gemäß DORA befassen müssen. An vorderster Front stehen dabei die vielen Abhängigkeiten von Drittanbietern – sei es bei Modellen und Agenten oder bei Plattformen und Clouds, die für deren Betrieb notwendig sind. Hier benötigen die Banken Wechseloptionen, mindestens für KI in Prozessen, die wie die Abwicklung des Zahlungsverkehrs zu einer Minimum Viable Bank zählen.

Eine Kombination aus einer zentral gemanagten, offenen Hybrid-Cloud-Plattform, Open-Weight-Modellen und verschiedenen Cloud-Anbietern bietet dabei die meisten Freiheiten.“

Die Migration von Modellen und Anwendungen zwischen Clouds und eigenen Systemen on-premises ist in einer solchen hybriden Umgebung problemlos möglich. Und da die Modelle frei verfügbar sind, besteht auch nicht die Gefahr, dass der Zugang zu ihnen aufgrund geopolitischer Spannungen eingeschränkt wird. Zudem sind leistungsfähige Open-Weight-Modelle, etwa von Mistral, DeepSeek und Qwen, nicht nur bei den US-Hyperscalern verfügbar, sondern auch bei vielen europäischen Cloud-Anbietern, sodass Banken von Innovationen profitieren können, ohne allzu große Abhängigkeiten einzugehen.

Der Wechsel von Modellen und Clouds muss allerdings gut vorbereitet werden – das heißt, er darf nicht erst dann auf der Agenda auftauchen, wenn er notwendig ist.“

Im Grunde muss der KI-Betrieb in den anderen Clouds bereits erprobt sein und die KI-Anwendung mit einem alternativen Modell schon weitgehend fertig in der Schublade liegen, damit die Umstellung im Worst Case nicht zu viel Zeit kostet. Immerhin: Eine Eins-zu-Eins-Ersetzung der Originalanwendung ist für einen Notbetrieb häufig nicht erforderlich – auch eingeschränkte Funktionen beziehungsweise eine geringere Genauigkeit sind in der Regel für einen gewissen Zeitraum hinnehmbar.

Die Einschätzung, was akzeptabel ist, liefern die Fachbereiche.“

Dabei müssen sie jedoch berücksichtigen, dass eine höhere Anzahl von False Negatives ein Risiko darstellt, da beispielsweise Betrugsversuche nicht erkannt werden. Eine geringfügige Erhöhung der Anzahl an False Positives ist üblicherweise weniger riskant und in erster Linie ärgerlich für Mitarbeitende oder Kunden, wenn etwa Transaktionen aufwendig manuell geprüft werden müssen und verzögert freigegeben werden. Eine drastische Erhöhung der Anzahl von False Positives kann allerdings zu einer massiven Überforderung der Mitarbeiter und kritischem Stau in der Abarbeitung führen.

Model Routing bietet Flexibilität

Erleichtern lässt sich der Wechsel von KI-Modellen auch durch modellagnostische Anwendungen, in denen ein Modell oder KI-Service nicht fest verdrahtet ist, sondern über Schnittstellen verschiedene Angebote eingebunden werden können. Einige Anwendungen von Drittanbietern bieten diese Option, die zugleich den Vorteil hat, dass die Bedienung unverändert bleibt und sich Mitarbeitende nicht an neue Oberflächen und Workflows gewöhnen müssen, wenn das Modell oder der Modellanbieter gewechselt wird.

Bei selbst entwickelten Lösungen sollte ein Abstraktionslayer die Weiterleitung von Daten und Anfragen übernehmen, sodass bei einem Anbieterwechsel keine neuen Integrationen und Schnittstellen gebraucht werden.“

Unabhängig davon erlaubt es ein solches Model Routing natürlich auch, Kosten zu optimieren. Entsprechende Model Router, KI-Gateways oder LLM-Proxies gibt es sowohl von kommerziellen Anbietern als auch aus der Open-Source-Community, darunter litellm und der vom vLLM-Projekt entwickelte Semantic Router.

Bei selbst gehosteten und betriebenen KI-Modellen bieten multimodale Inferenzserver auf Basis von vLLM die Möglichkeit, Modelle flexibel zu wechseln – und das sowohl im Rechenzentrum als auch in der Cloud, unabhängig von den genutzten Hardware-Beschleunigern.“

Dabei gibt es über Einschränkungen beim Zugang zu Modellen, Agenten, Anwendungen und Clouds hinaus noch weitere Risiken, die sich durch Model Routing und multimodale Inferenzserver eindämmen lassen. Hierzu zählen beispielsweise eine nachlassende Genauigkeit der KI, Angriffe auf die Modelle oder sich verändernde Anforderungen. All das kann geschäftskritisch sein und einen Wechsel erforderlich machen.

KI braucht Kontrolle

Um kritisches KI-Verhalten zu verhindern, sind Guardrails unerlässlich, die den Aktionen und Entscheidungen von KI-Anwendungen und insbesondere KI-Agenten genau abgesteckte Grenzen setzen. Hinzu kommen Human-in-the-Loop- und Human-on-the-Loop-Konzepte, die sicherstellen, dass kritische Aktionen und Entscheidungen geprüft werden – wobei Human in the Loop (HITL) mehr Kontrolle bietet, die Geschwindigkeit der KI bei automatisierten Abläufen aber begrenzt, weil Menschen jeweils die Freigaben erteilen müssen.

Maschinelle Geschwindigkeit wird erst mit Human on the Loop (HOTL) möglich, das heißt: Menschen fokussieren sich auf die Überwachung und greifen erst im Nachgang ein.“

Das erfordert jedoch ein gutes Monitoring, um Auffälligkeiten frühzeitig und zuverlässig erkennen zu können.

Ob HITL oder HOTL notwendig ist, hängt von den Risikobewertungen ab – beispielsweise davon, ob etwa eine Fehlentscheidung oder Endlosschleife der KI kritische Folgen hat. Dabei gilt es, auch die Fallback-Ebene zu berücksichtigen: Können andere Automatisierungen zum Einsatz kommen, nachdem eine KI-Anwendung oder ein KI-Agent abgeschaltet werden musste oder ausgefallen ist, lässt sich eventuell ein ausreichender Durchsatz aufrechterhalten. Müssen Menschen aber alle Aufgaben der KI übernehmen, reicht die Bearbeitungs­geschwindig­keit unter Umständen nicht einmal mehr für die grundlegenden Prozesse einer Minimum Viable Bank aus.

Beim Monitoring genügt es zudem nicht, einfach nur den Input und Output der KI-Systeme zu erfassen.“

Um alles exakt nachvollziehen zu können, werden umfassende Informationen benötigt, darunter die genaue Identität von Agenten, deren Abhängigkeiten von anderen Agenten und Tools, API-Aufrufe, Autorisierungsschritte, Fehlermeldungen, Zustandsdaten des Systems und die angewandten Guardrails. Erst dieser Kontext erlaubt fundierte Risikobewertungen und passgenaue Maßnahmen zur Risikominimierung.

KI-Agenten: Kontinuierliches Testen gehört zum Pflichtprogramm

Damit unbeherrschbare Risiken nicht eintreten und die Wahrscheinlichkeit, den operativen Betrieb auf eine Minimum Viable Bank zurückfahren zu müssen, möglichst gering bleibt, ist ein kontinuierliches Testen der KI-Agenten Pflicht. Dabei sollte das Testprogramm neben qualitativen Tests, etwa hinsichtlich Fehlerraten sowie des Umgangs mit Sonderfällen und unzulässigen Anfragen, auch Störungen von Datenquellen, anderen KI-Tools, auf die Agenten angewiesen sind, sowie Sicherheitsbelange berücksichtigen.

Schließlich dürfen sich die Agenten weder durch geschickt formulierte Aufträge so manipulieren lassen, dass sie ihre Guardrails ignorieren, noch dürfen sie den Human-in/on-the-Loop umgehen, um mehr Handlungsfreiheit zu erhalten.“

Um zu verhindern, dass die Governance-Ansätze zerfasern und Risiken unerkannt bleiben, sind klare Verantwortlichkeiten wichtig. Jeder KI-Agent im Unternehmen – unabhängig davon, ob er in-house entwickelt wurde, aus der Open-Source-Community stammt oder extern eingekauft wurde – benötigt einen Owner innerhalb der den Agenten einsetzenden Organisation, der die Fachlichkeit der vom Agenten übernommenen Aufgaben selbst beherrscht. Dieser Owner kümmert sich über den gesamten Lebenszyklus des Agenten hinweg um die zulässige Autonomie, die Überwachung von Risiken und das Management von Vorfällen. Dabei stellt er eine sorgfältige Dokumentation sicher und unterstützt bei Audits, sodass zuverlässig eingeschätzt werden kann, wie geschäftskritisch die von ihm geführten Agenten sind, welche Risiken eintreten können und wie sich die Prozesse im Ernstfall aufrechterhalten lassen. Armin Warda, Red Hat/aj