Lift-and-Shift fürs LLM: Wer KI nur in die Cloud schiebt, hat noch keine KI-Strategie

Der Einstieg für Finanzdienstleister in die KI führt in der Regel über den Endpunkt eines Hyperscaler-Modells. Eine Strategie ist das noch nicht. Drei Fragen stehen davor: Wo läuft die Inference, worauf greift das Modell zu, und wer verantwortet den Betrieb gegenüber der Aufsicht?

von Johannes Meyer, Senior Market Development Manager (Cloud), noris network 

API-Schlüssel anfordern, den Endpunkt eines Hyperscaler-Modells anbinden, Prototyp bauen. Im Proof of Concept funktioniert der KI-Einstieg für Banken, Versicherer und Zahlungs­dienstleister in der Regel reibungslos. Die Kehrseite zeigt sich im Produktivbetrieb, wenn Kernbankdaten, Auslagerungsregime und Prüfungsfestigkeit im Pflichtenheft stehen.

Einer von der BaFin in „Risiken im Fokus 2026“ aufgegriffenen EBA-Umfrage zufolge setzten Ende 2024 rund 40 Prozent der befragten bedeutenden Institute generative KI ein, im ersten Quartal 2025 bereits mehr als 60 Prozent.

Wie viele dieser Anwendungen einen dokumentierten Betrieb und ein geprüftes Auslagerungsverhältnis haben, erfasst die Umfrage allerdings nicht. Wo diese Modelle rechnen, bleibt ebenso offen.“

Inference ist ein Workload wie jeder andere

Entscheidend in diesem Zusammenhang sind drei Faktoren: Latenz, Kosten und Kontrolle – drei Größen, die sich nicht gleichzeitig optimieren lassen. Die Platzierungsfrage beginnt bei der Rechenleistung. Hier steht die Entscheidung an, ob dedizierte GPU-Ressourcen mit planbarer Auslastung oder geteilte Kapazität mit elastischer Skalierung genutzt werden soll. Sie setzt sich fort bei der Modellwahl. Ein quantisiertes Modell mittlerer Größe belegt weniger Speicher und bedient mehr parallele Anfragen je Karte. Besonders relevant ist darüber hinaus das Lastprofil. Dokumentenklassifikation im Backoffice ist ein Batch-Workload: Er läuft nachts, verträgt Wartezeiten und lässt sich auf hohe GPU-Auslastung trimmen. Betrugserkennung im Zahlungsverkehr ist das Gegenteil. Hier braucht es Antwortzeiten im Millisekundenbereich, mit Reserven, die im Regelbetrieb allerdings brachliegen. Organisationen, die beide Profile über denselben Endpunkt bedienen, zahlen für ungenutzte Kapazität oder verfehlen ihre Servicezusagen. Die Folge: Token-Durchsatz und Kosten je Anfrage gehören in die Planung, nicht in die Nachkalkulation. Am Ende steht eine Abwägung: Elastische Skalierung verschiebt Kontrolle und Kostenrisiko zum Anbieter, dedizierte Infrastruktur bindet Planungsaufwand und GPU-Know-how im Haus oder beim Dienstleister.

Der zweite Datenbestand

Das unterschätzte Risiko liegt vor dem Modell, in der Datenpipeline. Produktive KI-Anwendungen arbeiten mit Retrieval Augmented Generation und greifen auf Kernbanksysteme, Data Warehouses und Dokumentenablagen zu. Damit wird das zur Abfrageschicht über Daten, die bislang von gewachsenen Rollen- und Rechtemodellen geschützt waren. Diese müssen nun bis in den Retrieval-Layer durchgreifen, denn das Modell darf nicht mehr sehen als der Mitarbeiter, der die Anfrage stellt. Ein Grundsatz, der in der Praxis regelmäßig verletzt wird.

Dazu kommt eine Datenhaltung, die in vielen Konzepten fehlt: die Vektor-Datenbank. Sie gilt als technisches Beiwerk, enthält aber Embeddings der sensibelsten Unterlagen, aus denen sich Ausgangstexte näherungsweise rekonstruieren lassen. Wer sie nicht wie einen produktiven Datenspeicher inklusive Verschlüsselung, Zugriffskontrolle und Löschkonzept behandelt, betreibt einen ungesicherten Zweitspeicher. Bleiben Datenminimierung im Kontextfenster und die lückenlose Protokollierung jeder Anfrage: ohne sie wird die Revisionsprüfung zum Vabanque-Spiel.

Prüfungsfestigkeit entsteht im Betriebsmodell

Unbestritten ist: Der KI-Betrieb in BaFin-regulierten Häusern ist Auslagerungsmanagement unter DORA-Bedingungen. Dazu gehören die Aufnahme ins Informationsregister, eine Bewertung als IKT-Drittdienstleister sowie die dokumentierte Ausstiegsstrategie.

Portabilität setzt voraus, dass sich Modell, Prompt-Logik, Feinabstimmung und Vektorbestände tatsächlich mitnehmen lassen.“

Bei proprietären Modellen, die nur als Dienst verfügbar sind, ist der Exit häufig nur ein Wunschgedanke. Hinzu kommen Prüfungsrechte bis in die Subdienstleisterkette. Wer sein Modell bei einem Anbieter betreibt, der GPU-Kapazität seinerseits zukauft, sollte wissen, wo diese Kette endet.

Parallel dazu läuft die Einordnung nach der KI-Verordnung. Systeme zur Kreditwürdigkeitsprüfung natürlicher Personen gelten als Hochrisiko-KI nach Anhang III; der Digital Omnibus hat die Frist dafür vom 2. August 2026 auf den 2. Dezember 2027 verschoben. Das schafft Planungsspielraum, aber keine Entwarnung, weil Risikomanagement, Dokumentation und menschliche Aufsicht gefordert bleiben. Eine Grenze lässt sich ohnehin nicht verhandeln: Ein US-Hyperscaler kann Datenresidenz, Verschlüsselung und Auditrechte zusichern, das Zugriffsrisiko aus dem US-CLOUD Act beseitigt er nicht. Eine souveräne Umgebung wiederum liefert Rechtssicherheit, aber keine Skalierungsreserven für Lastspitzen.

Drei Platzierungen und ihre Grenzen

Unternehmen, die Lastprofil, Datenzugriff und Betriebsmodell zusammen betrachten, landen bei drei Platzierungen. Die erste ist die API-Nutzung eines Hyperscaler-Modells für unkritische Anwendungsfälle ohne Personenbezug: Textentwürfe, Recherche, Wissenssuche auf freigegebenen Beständen. Hier bleiben Aufwand und Kompetenzbedarf gering, der Nutzen stellt sich schnell ein. Die Grenze liegt dort, wo Kundendaten ins Kontextfenster geraten.

Bei der zweiten Platzierung läuft ein dediziertes Modell auf eigener oder gehosteter GPU-Infrastruktur in deutschen Rechenzentren. Das bringt volle Kontrolle über Daten, Modellstand und Protokollierung, dazu einen Betriebsaufwand, den die meisten Organisationen unterschätzen: Modell-Lifecycle, Evaluierung nach jedem Update, Auslastungsmanagement. Schließlich gleicht der Betrieb eines Modells eher einem Produktlebenszyklus als einer Installation.

Die dritte kombiniert beides, nämlich sensible Inference in einer souveränen Umgebung und die unkritische Skalierung beim Hyperscaler. Der Preis – die Komplexität. Hier kommen zwei Betriebsmodelle, zwei Vertragswerke und eine gemeinsame Steuerung zusammen. Eine pauschal richtige Platzierung gibt es ohnehin nicht. Richtig ist allein die je Workload begründete und dokumentierte Entscheidung. Damit wird klar: Die Cloud ist auch für das Finanzumfeld ein Werkzeugkasten, aber noch keine Strategie. Eine echte KI-Strategie liegt erst vor, wenn ein Institut je Anwendungsfall begründen kann, wo die Inference läuft, welche Daten mit welchen Kontrollen einfließen und wer den Betrieb regulatorisch verantwortet. Alles andere ist eine Bestellung. Johannes Meyer, noris network