Legacy-Plattformen werden zur neuen Betriebslast

Wenn KI-Agenten Teile der Kreditprüfung übernehmen, die Kundenansprache steuern oder die Geldwäscheprävention vorbereiten, brauchen sie eine Architektur, die nicht vor fünf Jahren für menschliche Bildschirmarbeit gebaut wurde. Die meisten Banking-Systeme sind aber genau das. Und genau das wird zum Problem.

Die Diskussion über autonome Agenten ist keine ferne Zukunftsfrage mehr. Selbst die Aufsicht denkt sie inzwischen mit: Im Kontext der neuen EU-Geldwäscheverordnung benennen Beobachter agentische KI ausdrücklich als eine der Technologien, die von optional zu erfolgskritisch werden. Wer in dieser Lage feststellt, dass die eigene Systemlandschaft Agenten nicht sauber anbinden kann, hat keine Werkzeugfrage, sondern ein Architekturproblem.

Das Grundproblem: Monolithen sprechen nicht mit Agenten

Ein klassisches Banking-System ist auf Oberflächen und menschliche Bedienung optimiert. Die Logik steckt fest verdrahtet hinter Masken, Workflows folgen dem Klickpfad eines Sachbearbeiters, und die Schnittstellen nach außen sind oft begrenzt, langsam oder gar nicht vorhanden. Für einen Menschen, der ohnehin Maske für Maske arbeitet, ist das tragbar. Für einen Agenten, der in Sekunden auf Daten zugreifen, Aktionen auslösen und Ergebnisse zurückschreiben soll, ist es eine Mauer.

Headless bedeutet, die Funktion von der Oberfläche zu trennen. Die Fähigkeiten eines Systems, etwa eine Bonität abzufragen, ein Dokument zu prüfen oder einen Vorgang anzulegen, werden über klar definierte Schnittstellen verfügbar gemacht, unabhängig davon, ob am anderen Ende ein Mensch in einer Maske oder ein Agent sitzt. Erst diese Trennung macht ein System überhaupt anschlussfähig für Automatisierung, die über das einzelne Klickskript hinausgeht.

Warum das gerade jetzt zur strategischen Frage wird

Die Versuchung ist groß, das Thema als Spielwiese der IT abzutun. Das verkennt die Dynamik. Wenn Agenten in der Lage sind, ganze Vorgangsketten zu übernehmen, entscheidet die Anschlussfähigkeit der Systeme darüber, welche Institute Geschwindigkeit gewinnen und welche im manuellen Takt verharren. Ein Institut mit headless-fähigen Systemen kann einen neuen automatisierten Ablauf in Wochen aufsetzen. Ein Institut mit verschlossenen Monolithen braucht dafür Großprojekte mit langen Laufzeiten oder schafft es gar nicht.

Das ist kein Plädoyer dafür, jedes Kernsystem morgen auszutauschen. Für Sparkassen und Genossenschaftsbanken, die auf zentrale Plattformen wie OSPlus oder agree21 angewiesen sind, wäre das weder realistisch noch sinnvoll. Der Hebel liegt anderswo: in der Frage, wie offen die eigene Architektur an den Rändern ist und wo gezielt Schnittstellen geschaffen werden müssen, damit Agenten andocken können, ohne das Kernsystem zu ersetzen.

Die ehrliche Bestandsaufnahme

Bevor ein Institut über Agenten nachdenkt, lohnt eine nüchterne Inventur der eigenen Systeme entlang einiger weniger Fragen. Welche unserer Kernfunktionen sind heute über Schnittstellen erreichbar und welche nur über die Oberfläche? Wo entstehen Medienbrüche, weil Systeme nicht miteinander sprechen? Und welche dieser Lücken stehen genau zwischen uns und den Prozessen, die wir als Erstes automatisieren wollen?

Diese Bestandsaufnahme trennt die teure Generalsanierung von der gezielten Investition. Selten muss alles offen sein. Meist genügt es, die wenigen Schnittstellen zu schaffen, die der erste wirklich relevante Anwendungsfall braucht, und von dort aus zu erweitern. So wird aus einer abstrakten Architekturdebatte ein konkreter, finanzierbarer Plan.

Was ein Agent von einem klassischen Workflow unterscheidet

Um die Tragweite zu verstehen, lohnt der Blick auf den Unterschied zwischen einer klassischen Automatisierung und einem Agenten. Eine klassische Automatisierung folgt einem festen Pfad: Wenn Bedingung A, dann Schritt B, dann Schritt C. Sie ist starr, vorhersehbar und bricht, sobald die Realität vom vorgesehenen Pfad abweicht. Ein Agent dagegen verfolgt ein Ziel und entscheidet selbst, welche Schritte er in welcher Reihenfolge ausführt, um es zu erreichen. Er kann auf unerwartete Situationen reagieren, Zwischenergebnisse bewerten und seinen Weg anpassen.

Dieser Unterschied stellt ganz andere Anforderungen an die Systeme im Hintergrund. Ein starrer Workflow kommt mit wenigen, fest definierten Schnittstellen aus. Ein Agent braucht die Fähigkeit, jederzeit auf eine Vielzahl von Funktionen zuzugreifen, Ergebnisse abzufragen und Aktionen auszulösen, ohne dass für jeden denkbaren Pfad vorab ein Klickskript hinterlegt wurde. Genau diese Flexibilität setzt eine offene, dienstbasierte Architektur voraus, und genau daran fehlt es den meisten gewachsenen Systemen.

Der Irrtum vom großen Plattformwechsel

Viele Häuser ziehen aus dieser Erkenntnis den falschen Schluss, man müsse nun das Kernsystem austauschen. Das ist selten richtig und für Institute im Verbund meist gar nicht möglich. Das Kernsystem bleibt, was es ist, die zentrale, hochregulierte Plattform, auf der das Geschäft läuft. Der Hebel liegt nicht im Austausch, sondern in einer Schicht davor, die die Funktionen des Kernsystems kontrolliert nach außen verfügbar macht.

Diese vermittelnde Schicht erlaubt es, Agenten anzubinden, ohne das Kernsystem zu berühren. Sie definiert, welche Funktionen ein Agent nutzen darf, protokolliert jeden Zugriff und setzt klare Grenzen. So entsteht Anschlussfähigkeit, ohne das Risiko, ein bewährtes und geprüftes System zu destabilisieren. Der Weg ist evolutionär, nicht revolutionär, und genau deshalb ist er für regulierte Institute überhaupt gangbar.

Governance gehört von Anfang an dazu

Sobald ein Agent eigenständig Aktionen in Kernsystemen auslöst, wird die Frage der Kontrolle zentral. Wer darf was, in welchen Grenzen, mit welcher Nachvollziehbarkeit? Ein Agent, der theoretisch jede Funktion auslösen kann, ist nicht nur mächtig, sondern auch ein Risiko. Die offene Architektur muss deshalb von Beginn an mit einer klaren Rechte- und Protokollierungslogik einhergehen, die festlegt, welche Aktionen automatisiert ablaufen dürfen und welche zwingend eine menschliche Freigabe verlangen.

Das ist kein Widerspruch zur Geschwindigkeit, sondern ihre Bedingung. Nur eine Architektur, die kontrolliert öffnet, lässt sich gegenüber der internen Revision und der Aufsicht verantworten. Wer dagegen unkontrolliert öffnet, um schnell zu sein, baut ein Risiko ein, das beim ersten Vorfall die gesamte Automatisierungsstrategie diskreditiert.

Der Reihenfolge-Fehler bei Agenten-Projekten

Viele Institute starten Agenten-Projekte am falschen Ende. Sie beginnen mit dem spektakulären Anwendungsfall, einem Agenten, der einen kompletten Prozess autonom durchläuft, und stoßen sofort auf die verschlossene Architektur. Das Projekt verzettelt sich in Integrationsarbeit, bevor es einen Nutzen zeigt. Der bessere Weg beginnt mit der Anschlussfähigkeit: Erst werden die wichtigsten Funktionen über saubere Schnittstellen verfügbar gemacht, dann werden Agenten darauf gesetzt.

Dieser Weg ist unspektakulärer, aber er trägt. Jede Schnittstelle, die geschaffen wird, nutzt nicht nur einem Agenten, sondern allen künftigen Automatisierungen und auch der besseren Verzahnung der bestehenden Systeme. Die Investition in Anschlussfähigkeit zahlt sich also mehrfach aus, während die Investition in einen einzelnen, auf eine geschlossene Architektur aufgesetzten Agenten verpufft, sobald sich die Anforderungen ändern.

Was das für die nächste Systementscheidung heißt

Die praktische Konsequenz betrifft jede anstehende Beschaffung. Wer heute ein neues System auswählt, sollte dessen Offenheit zu einem zentralen Kriterium machen: Lassen sich seine Funktionen über dokumentierte Schnittstellen ansprechen, oder ist es ein weiterer geschlossener Block? Diese Frage entscheidet über Jahre, wie flexibel das Haus bleibt, und sie wird in klassischen Auswahlverfahren oft erst gar nicht gestellt.

Die gute Nachricht ist, dass sich die Architektur Schritt für Schritt öffnen lässt, ohne Bruch. Jede neue Komponente, die anschlussfähig gewählt wird, und jede Schnittstelle, die gezielt vor ein Bestandssystem gesetzt wird, erhöht die Beweglichkeit des Ganzen. So entsteht über die Zeit eine Landschaft, in der Agenten und Automatisierungen andocken können, ohne dass je ein riskanter Komplettumbau nötig war.

Technische Schuld ist eine strategische Entscheidung

Der Kern der Sache ist unbequem: Eine geschlossene Architektur ist nicht nur ein technischer Zustand, sie ist eine strategische Festlegung darauf, wie schnell ein Institut künftig auf neue Möglichkeiten reagieren kann. Wer die Anbindungsfähigkeit seiner Systeme ignoriert, entscheidet sich, ob bewusst oder nicht, gegen die Geschwindigkeit, die im Wettbewerb mit agentenfähigen Häusern zählen wird.

Mehr zum Thema: 71 Prozent nutzen KI-Agenten. 11 Prozent haben sie in Produktion. Der Rest präsentiert Folien. und Banking Super-App: Was wirklich dahintersteckt und warum die meisten scheitern..

Wir analysieren mit Ihnen, wo Ihre Architektur heute anschlussfähig ist und wo gezielte Schnittstellen den größten Hebel für Automatisierung schaffen, ohne Ihr Kernsystem infrage zu stellen. Strategie und Umsetzung aus einer Hand. Beginnen Sie mit einer Potenzialanalyse.