Zentral oder eingebettet? Wie Banken ihre KI-Teams organisieren

Autor: acceleraid Redaktion

HSBC kündigt für die zweite Jahreshälfte 2026 ein Global AI Centre of Excellence in Singapur mit mehr als 100 KI-Spezialistinnen und -Spezialisten an. Das Zentrum soll mit dem Chief AI Officer sowie den Bereichen Wealth Management und Global Payments Solutions arbeiten; im Fokus stehen unter anderem Kundengespräche, Treasury-Lösungen und digitale Zahlungen. Der Schritt zeigt: Die entscheidende Frage lautet nicht mehr, ob eine Bank KI erprobt, sondern wie sie Verantwortung, Plattformen und Fachwissen so organisiert, dass aus einzelnen Vorhaben belastbare Produkte werden. HSBC

Wie sich diese Organisationsfrage im Customer Lifecycle Management niederschlägt, zeigt unser Beitrag zum Operating Model für CLM in Banken. Warum diese Fähigkeit eher als kontinuierliche Modernisierung denn als einmaliges Transformationsprogramm gedacht werden sollte, erläutert der gleichzeitig veröffentlichte Artikel zur AI-native Bank.

Das Operating Model ist ein System für Entscheidungen

„Zentral oder eingebettet?“ ist die falsche Kurzform der Debatte. Ein Operating Model legt fest, wer einen Anwendungsfall priorisiert, wer Daten und Modelle verantwortet, wer Kontrollen definiert, wer eine Freigabe erteilt und wer den Effekt im Geschäft misst. Erst diese Entscheidungen machen KI wiederholbar.

Ein zentraler Ansatz bündelt knappe Expertise, technische Standards und Kontrollmechanismen. Ein eingebetteter Ansatz bringt Datenexpertise und Produktverantwortung in die Nähe von Kundensituation, Prozess und Fachentscheidung. Eine Bank braucht beides. Sie sollte jedoch nicht beides für dieselben Aufgaben gleichzeitig aufbauen. Doppelte Plattformen, parallele Modellprüfungen und voneinander abweichende Lieferantenentscheidungen schaffen Kosten und erschweren die Nachvollziehbarkeit.

Die sinnvolle Trennlinie verläuft daher nicht entlang eines Organigramms, sondern entlang der Wiederverwendbarkeit und des Risikos einer Entscheidung. Was viele Einheiten identisch benötigen oder große Auswirkungen hat, gehört in einen gemeinsamen Kern. Was nur mit aktuellem Domänenwissen und schneller Rückkopplung funktioniert, gehört in die Geschäftsbereiche.

Was die Praxis über zentrale und föderierte Modelle zeigt

Die Datenlage spricht nicht für ein dauerhaft starres Modell. In einer McKinsey-Erhebung unter 16 Finanzinstituten waren vier Archetypen annähernd gleichmäßig verteilt: hochzentralisiert und hochdezentralisiert jeweils rund ein Fünftel, die beiden Mischformen jeweils rund drei Zehntel. Gleichzeitig hatten etwa 70 % der Institute mit hochzentralisiertem Ansatz GenAI-Anwendungsfälle in Produktion, gegenüber rund 30 % bei einem vollständig dezentralen Ansatz. McKinsey erwartet deshalb eine Bewegung von anfänglicher Zentralisierung zu föderierten Strukturen; dauerhaft zentral bleiben vor allem Risikomanagement, Architektur, Partnerentscheidungen und Standardsetzung. McKinsey

ING steht für den Nutzen eines zentral gesteuerten Starts: Laut Computer Weekly werden dort 90 % der KI-Piloten produktiv, verglichen mit einem genannten Branchendurchschnitt von 30 %. Die Bank verbindet die Zentralisierung mit einer gemeinsamen Plattform, zentralen Guardrails und Echtzeit-Monitoring, hält aber die Verbindung zu den Geschäftsbereichen aufrecht. Das ist kein Beleg dafür, dass jede Bank ein identisches Modell kopieren sollte. Es ist ein Hinweis darauf, dass eine gemeinsame Liefer- und Kontrollumgebung die Lücke zwischen Pilot und Betrieb schließen kann. Computer Weekly

DBS wählt ausdrücklich ein föderiertes Modell: Ein CoE bildet den Kern, funktionsübergreifende Squads arbeiten von dort in die Bereiche hinein, und Data Scientists sind in den Squads eingebettet. Die Bank berichtet, dass sich die Zeit bis zum Deployment von etwa 18 Monaten auf vier bis fünf Monate verringerte. Entscheidend ist dabei nicht die Zahl der Gremien, sondern die Verbindung aus zentral bereitgestellten Spezialistinnen und Spezialisten, gemeinsamer Befähigung und klarer Verantwortung im Squad. DBS

Eine belastbare Arbeitsteilung: Kern, Domäne, gemeinsame Übergaben

Für die konkrete Gestaltung hilft eine einfache Regel: Zentralisieren, wenn der Gegenstand wiederverwendbar, regulierungsrelevant oder nur einmal wirtschaftlich betreibbar ist. Einbetten, wenn die Qualität der Entscheidung vom Prozesskontext, von lokalen Kundenrückmeldungen oder von einem konkreten Ergebnis im Fachbereich abhängt.

Der zentrale Kern ist kein Bestellservice für Modelle. Er stellt Fähigkeiten als Produkt bereit: eine geprüfte Entwicklungsumgebung, wiederverwendbare Schnittstellen, Regeln für Datenzugriff, Dokumentation und Monitoring. Dafür braucht er ein transparentes Serviceversprechen gegenüber den Fachbereichen: Welche Bausteine sind verfügbar, nach welchen Kriterien wird priorisiert, und wann darf ein Team von einem Experiment in den regulären Betrieb wechseln?

Die Fachbereiche wiederum dürfen nicht bloß Anforderungen abliefern. Sie benennen eine verantwortliche Person für den Geschäftseffekt, definieren den zulässigen Handlungsspielraum und organisieren die Rückmeldung aus dem Prozess. Gerade bei kundenbezogenen KI-Anwendungen muss im Fachbereich klar sein, wann ein Ergebnis automatisch umgesetzt, wann es geprüft und wann es verworfen wird. So bleibt fachliche Verantwortung dort, wo die Folgen einer Entscheidung sichtbar werden.

Governance ist keine zentrale Ablage

Mit dem geltenden Zeitplan des EU AI Act ist diese Arbeitsteilung nicht optional. Seit dem 2. August 2026 gilt der verbleibende Teil der Verordnung mit der im Zeitplan genannten Ausnahme zu Artikel 6 Absatz 1. Anhang III stuft KI zur Bewertung der Kreditwürdigkeit natürlicher Personen oder zur Festlegung eines Kreditscores grundsätzlich als Hochrisiko ein; KI zur Aufdeckung von Finanzbetrug ist dort ausgenommen. Diese Einordnung ersetzt keine Rechtsberatung, macht aber deutlich, warum Modellverantwortung nicht zwischen Data Team und Fachbereich verschwinden darf. EU AI Act Implementation Timeline EU AI Act, Anhang III

Für jede produktive Lösung sollten daher vier Verantwortlichkeiten namentlich festgelegt sein: eine geschäftliche Ergebnisverantwortung, eine technische Systemverantwortung, eine unabhängige Challenge-Funktion und eine Instanz mit Freigabe- beziehungsweise Eskalationsrecht. Zentralisierung kann diese Rollen standardisieren; sie darf sie aber nicht anonymisieren. Die Fachseite bleibt für Zweck, Auswirkungen und den Prozess verantwortlich, in dem das System eingesetzt wird.

Die EZB-Bankenaufsicht benennt gerade hier typische Lücken: eindeutige Verantwortlichkeit für KI-Entscheidungen, Überwachung durch das Senior Management und robuste Challenge-Mechanismen durch Risiko, Compliance und Interne Revision. Sie verweist außerdem auf Erklärbarkeit, Governance über den Modelllebenszyklus, Datenqualität, Bias sowie Konzentrations- und Lock-in-Risiken. Ein gutes Operating Model behandelt diese Punkte als Entwurfsbedingungen für jeden Use Case – nicht als Prüfung kurz vor dem Go-live. EZB-Bankenaufsicht

Ein Startpunkt für die nächsten Entscheidungen

Statt eine Reorganisation auf einmal auszurufen, können Banken ihr Zielmodell an einem priorisierten Portfolio testen. Zuerst wird ein zentraler Mindeststandard für Plattform, Risiko- und Modellinventar festgelegt. Danach erhalten wenige fachlich verantwortete Use Cases klar abgegrenzte Produktteams. Anschließend werden die Übergaben gemessen: Wie schnell werden Datenzugriffe geklärt, wie oft wird eine Freigabe nachgearbeitet, welche Erkenntnisse werden als Standard wiederverwendet? Erst dann lohnt es sich, Zuständigkeiten oder Kapazitäten auszuweiten.

Für die Portfolioentscheidung sind drei Fragen besonders nützlich. Erstens: Entsteht der Wert aus einer wiederverwendbaren Fähigkeit oder aus einzigartigem Prozesswissen? Zweitens: Welche Entscheidung würde bei einem Fehler die meisten Kundinnen, Kunden oder Kontrollfunktionen betreffen? Drittens: Wer kann die Qualität im laufenden Betrieb tatsächlich beurteilen? Die Antworten ergeben häufig ein hybrides Modell – und verhindern, dass „föderiert“ nur ein anderes Wort für unkoordinierte Einzelprojekte wird.

Ein Plattformansatz kann dabei die wiederholte Spezialarbeit pro Use Case senken, wenn Datenzugriff, Governance und Entscheidungslogik als gemeinsame Bausteine bereitstehen. Acceleraid verbindet nach eigener Darstellung CDP- und Data-Governance-Funktionen, eine Prediction Engine sowie Orchestrierung für Customer Lifecycle Management; die Plattform ist modell-agnostisch ausgelegt. Für Banken ist das vor allem dann relevant, wenn sie fachliche Teams befähigen wollen, ohne Plattform- und Kontrollfragen für jeden Anwendungsfall neu zu lösen. Acceleraid Platform

Der Maßstab ist damit nicht die Größe eines CoE und auch nicht die Anzahl eingebetteter Data Scientists. Erfolg entsteht, wenn ein gemeinsamer Kern sichere Wiederverwendung ermöglicht und die Fachbereiche für echte Geschäftsentscheidungen verantwortlich bleiben. Das ist die organisatorische Voraussetzung, damit KI schneller produktiv wird, ohne dass Verantwortung mit skaliertem Tempo verloren geht.

Illustration: KI-generiert. KI-gestützte Inhalte: Bei der Erstellung unserer Beiträge setzen wir KI-Technologien und automatisierte Agenten ein, unter anderem von Microsoft, Google, OpenAI, Anthropic und weiteren Anbietern. Themen, fachliche Ausrichtung und finale Freigabe liegen bei unserem Team.