Architektur und wo sie tatsächlich in eine Bankplattform eingebunden ist

Ein Jahr ist in der Welt von Agentic AI eine geologische Ära. Vor zwölf Monaten stand in einem typischen Diagramm einer „AI-Agent-Plattform“ – wir betrachten hier eines aus der Mitte des Jahres 2025 – eine Vektordatenbank im Zentrum. Agenten wurden als Unterkomponente einer „AI Layer“ behandelt, jede Tool-Integration wurde individuell verdrahtet, Monitoring verteilte sich auf vier Dashboards für Kosten, Nutzung, Daten und LLMs, und Deployment folgte klassischem CI/CD – Prompts waren eher ein nachträglich ergänztes Artefakt.

Nichts davon war falsch. Aber vieles davon ist inzwischen überholt. Dieser Artikel zeigt, wie ein produktionsreifer AI-Agent Mitte 2026 aufgebaut ist, warum sich die Architektur verändert hat und – der Teil, den viele Architekturbeiträge auslassen – wie sich das Ganze tatsächlich in eine realistische digitale Banking-Plattform mit Batch Core, ESB und bestehenden Legacy-Komponenten einfügt.

Was sich in zwölf Monaten verändert hat

Drei Entwicklungen erklären fast alles, was sich im Architekturmodell verändert hat.

Tool Access wurde standardisiert. Das von Anthropic im November 2024 eingeführte Model Context Protocol wurde zum De-facto-Standard für die Verbindung von Agenten mit Tools und Daten. Es wurde von OpenAI, Google, Microsoft und AWS übernommen, im Dezember 2025 an die „Agentic AI Foundation“ der Linux Foundation übergeben und verzeichnet monatlich rund 97 Millionen SDK-Downloads. Bis Mitte 2026 setzten laut Umfragen 78 % der Enterprise-AI-Teams MCP-gestützte Agenten in Produktion ein.

Die Spezifikationsrevision vom November 2025 ergänzte Funktionen, auf die Unternehmen gewartet hatten: asynchrone Long-Running Tasks, formale Server Identity und strukturierte Audit Trails. Die Konsequenz für die Architektur ist wesentlich: Integration ist nicht länger der Mittelpunkt des Diagramms. Statt massgeschneiderter Verbindungen zeichnet man ein standardisiertes Protokoll mit einer governed Tool Registry dahinter.

Für Multi-Agent Coordination übernimmt ein zweites Protokoll eine wichtige Rolle: Googles A2A, das inzwischen ebenfalls unter dem Dach der Linux Foundation steht. Der sich abzeichnende Architekturansatz ist ein Layered Stack: MCP gibt einem Agenten seine „Hände“, A2A ermöglicht die Koordination mehrerer Agenten.

Retrieval wurde – bewusst – zurückgestuft. Was 2025 noch das Zentrum vieler Architekturdiagramme war – Landing Zone → Chunking → Vectorization → Vector DB → Knowledge API – ist heute eines von mehreren Tools, die ein Agent aufrufen kann.

Produktionsagenten beantworten 2026 viele Fragen, indem sie governed Business APIs aufrufen oder direkt auf Datenplattformen zugreifen – unter denselben Access Controls, die auch für menschliche Nutzer gelten. Retrieval bleibt wichtig, ist aber nicht mehr die Architektur selbst.

Ein besonders deutliches Signal ist, wer heute Managed MCP Interfaces bereitstellt: die Datenplattformen selbst. Sie stellen governed Query Tools zur Verfügung, sodass Agenten die bestehenden ACLs der Plattform übernehmen, anstatt sie über exportierte Vektorkopien zu umgehen.

Identity und Governance sind Teil der Architektur geworden – nicht nur Teil von Policy-Dokumenten. Das ist der grösste kulturelle Wandel. Agenten authentifizieren sich, erhalten Credentials und führen Aktionen aus. Damit wird jeder Agent zu einer privilegierten Non-Human Identity.

Die Zahlen dazu sind bemerkenswert: Eine Umfrage der Cloud Security Alliance ergab, dass 68 % der Unternehmen AI-Agent-Aktivitäten nicht zuverlässig von menschlichen Aktivitäten unterscheiden können. Der Gravitee Agent Security Report 2026 stellte zudem fest, dass 45,6 % der Befragten Shared API Keys für die Authentifizierung von Agenten einsetzen.

Klassisches IAM wurde für deterministische Software mit vorhersehbaren Zugriffsmustern entwickelt. Agenten entscheiden jedoch zur Laufzeit, auf welche Ressourcen sie zugreifen. Deshalb lassen sich Berechtigungen nicht immer vollständig im Voraus festlegen.

Das Modell, auf das sich die Branche zunehmend zubewegt – häufig als Blended Identity bezeichnet –, gibt jeder Agenteninstanz eine eigene überprüfbare Identität, die mit dem Menschen verknüpft ist, für den sie handelt, aber von dessen Identität getrennt bleibt. Zur Laufzeit werden kurzlebige, task-spezifische Credentials ausgegeben und Least Privilege direkt am Zugriffspunkt durchgesetzt. Das NIST startete im Februar 2026 eine „AI Agent Standards Initiative“, die genau diesen Bereich von Identity und Authorization adressiert.

Wenn Ihre Agentenarchitektur noch immer einen Service Account zeigt, ist es ein Diagramm aus 2024 mit einem Titel aus 2026.

Die Architektur von 2026

Im Zentrum des Diagramms steht eine persistente Agent Runtime: ein Reasoning Loop aus Plan → Act → Observe → Reflect mit begrenzten Schritten und Budget Limits, Context Assembly, Session- und Long-Term Memory sowie ein expliziter Task Lifecycle für Long-Running, resumable und idempotente Workflows. Optional können Aufgaben über A2A an Sub-Agents delegiert werden.

Darunter liegt ein Model Gateway: Frontier Models, kleinere oder lokale Modelle für Klassifikation und PII-sensitive Aufgaben sowie Embeddings – alles routbar und, entscheidend, austauschbar. Das Modell selbst ist eine der am leichtesten ersetzbaren Komponenten des Stacks. Runtime, Tools, Policies und Evidence sind die Teile, die langfristig Ihnen gehören.

Rechts davon befindet sich der Tool Plane: ein MCP Client mit einer agentenspezifischen Allowlist vor den governed Tools – Business APIs mit Read-, Propose- und Execute-Scopes, Retrieval, Datenplattformen, eine Code Sandbox ohne Production Credentials und geprüfte SaaS-Server.

Alle Tools werden über eine Private MCP Registry mit Schema Review, Security Scanning und Approval Workflow zugelassen. Diese Registry ist keine bürokratische Zusatzschicht. Unabhängige Scans zeigen, dass viele öffentliche MCP-Server ausnutzbare Risiken enthalten und nur ein kleiner Anteil standardmässig OAuth nutzt. In einem Unternehmen muss „Wir haben einen MCP-Server aus dem Internet installiert“ genauso undenkbar sein wie „Wir haben ein beliebiges npm-Paket direkt ins Core-Banking-System installiert“.

Um diese Komponenten herum liegen drei Ebenen, die im Architekturdiagramm von 2025 weitgehend fehlten:

• Policy & Gates – Input- und Output-Guardrails, eine Pre-Action Policy Engine und Human Approval Gates als First-Class Infrastructure für Aktionen mit relevanten Auswirkungen.
• Agent Identity – instanzspezifische Identity, JIT Credentials und On-Behalf-Of User Context, sodass jede Aktion sowohl einem Agenten als auch einem Menschen zugeordnet werden kann.
• Evidence – Step-Level Traces, ein tamper-evident Log für Intent, Approval, Action und Result, ein als Merge Gate in CI/CD integriertes Eval Harness sowie Cost Controls und Runaway Protection mit Kill Switch.

Monitoring hat sich damit zu Evidence weiterentwickelt. Dashboards zeigen, was passiert ist. Ein Evidence Log erlaubt Ihnen, gegenüber einem Auditor nachzuweisen, warum und unter welchen Kontrollen es passiert ist. Unter den Erwartungen der FINMA-Mitteilung 08/2024 zu Inventarisierung, Dokumentation und Erklärbarkeit ist genau das ein wesentlicher Unterschied zwischen einem Pilot und einem produktiven System in einem Schweizer Finanzinstitut.

Die realistische Banking-Plattform

Referenzarchitekturen zeigen gerne die ideale Bank. Reale Plattformen sehen eher wie das obige Diagramm aus: Channels wie Mobile, E-Banking, Advisor Workplace und Callcenter laufen über BFFs und ein API Gateway. Dahinter liegt ein Digital Services Layer mit Komponenten aus unterschiedlichen Generationen – ein Payments Microservice aus 2022 neben einem Cards-Modul aus 2014 innerhalb eines Monolithen, daneben eine KYC-Suite eines externen Anbieters.

In der Integration Layer trägt der SOAP-ESB aus 2009 möglicherweise noch immer einen wesentlichen Teil der Last, während Kafka nur die neueren Flows transportiert. Dazu kommen Systems of Record mit einem batchorientierten Core der Avaloq-/Finnova-Klasse, nächtlichem General-Ledger-Close, Payment Rails, CRM, Screening Engines und Dokumentenarchiv.

Gleichzeitig existiert eine Datenlandschaft, in der das Legacy-DWH weiterhin Regulatory Reporting übernimmt, während ein Lakehouse daneben Analytics verarbeitet. Diese Koexistenz ist kein Fehlzustand. So sieht eine Organisation aus, die gleichzeitig eine Bank betreibt und ihre Plattform modernisiert – und genau in diesem Umfeld müssen AI-Agenten funktionieren.

Agenten werden an vier Stellen integriert:

• Als weiterer Client hinter dem API Gateway – mit Southbound Calls unter OAuth und Rate Limits wie jeder andere Client.
• Über eine MCP Tool Facade in der Integration Layer – ausgewählte APIs und ESB-Services werden als governed, schema-basierte Tools bereitgestellt.
• Als Event Consumer auf dem Bus – für triggerbasierte Workflows.
• Über IAM Federation – ein Agent Identity Broker erweitert den bestehenden Identity Stack, anstatt ihn zu ersetzen.

Was bereits gut genug ist

Eine realistische Einschätzung ist wichtig – denn „alles für AI neu bauen“ ist Vendor-Rhetorik, keine Architekturstrategie.

• API Gateway und BFF Layer. Agenten sind ein weiterer Client. OAuth2/OIDC, Throttling und WAF wurden bereits für nicht vertrauenswürdige Aufrufer entwickelt. In vielen Fällen ist Konfiguration erforderlich, kein vollständiger Neuaufbau.
• Event Backbone. Wo Kafka bereits vorhanden ist, können Agent Triggers und Result Events diese Infrastruktur direkt nutzen.
• Lakehouse Governance, falls vorhanden. Eine governed Data Platform ermöglicht Agenten Abfragen unter denselben ACLs wie menschlichen Nutzern – genau das Modell, das Managed-MCP-Datenplattformen zunehmend produktisieren.
• Observability-Infrastruktur. Ihr bestehender Tracing- und SIEM-Stack kann Agent Traces wie die eines anderen Services aufnehmen. Die Semantik ist neu, die technische Pipeline häufig nicht.
• CI/CD. Prompts, Tool Schemas und Policies sind versionierte Artefakte. Ihre bestehende Delivery-Infrastruktur kann sie transportieren – neu sind vor allem die Eval Gates.

Was angepasst werden muss – die sechs zentralen Workstreams

1. Identity und Authorization für Non-Human Identities. Agentenspezifische Identitäten, kurzlebige task-spezifische Credentials aus einem Broker, On-Behalf-Of Context Binding und Policies, die direkt auf Tool-Ebene durchgesetzt werden. Hier besteht eine der grössten Lücken zwischen Branchenrhetorik und praktischer Umsetzung – und es ist einer der ersten Bereiche, die ein Auditor prüfen wird.
2. API Semantics für Machine Consumers. APIs für menschlich bediente Anwendungen können gewisse Mehrdeutigkeiten tolerieren. Agent-callable APIs können das nicht. Sie benötigen Idempotency Keys, Dry-Run- oder Simulation Endpoints für kritische Operationen, fein abgestufte Scopes für Read, Propose und Execute sowie Error Responses, auf die ein Modell sinnvoll reagieren kann. Häufig handelt es sich dabei um Refactoring an den Rändern – doch genau das trennt einen Agenten, der sicher eine Zahlungskorrektur vorschlagen kann, von einem Agenten, den Sie niemals in die Nähe eines Zahlungssystems lassen würden.
3. Governed Access Paths zum Core. Der Batch Core ist die Einschränkung – nicht der Bösewicht. Agenten erhalten weder Screen Scraping noch direkten Datenbankzugriff. Der Modernisierungsschritt besteht aus einer schlanken, kontrollierten API-/CDC-Schicht über den stabilen Funktionen des Core. Das entspricht genau dem Strangler-Pattern-Ansatz, den ein Modernisierungsprogramm ohnehin verfolgt. Agent Readiness und Core Modernization sind in vielen Fällen dieselbe Roadmap unter zwei unterschiedlichen Namen.
4. Human Approval Infrastructure als Shared Service. Fast jedes ernsthafte Szenario endet irgendwann mit „… und ein Mensch genehmigt es“. Wenn jedes Team dafür eine eigene Approval UI entwickelt, entstehen inkonsistente Gates und nicht nachweisbare Human Oversight. Bauen Sie stattdessen einen gemeinsamen HITL-Service mit Approval Queues im Advisor Workplace und in Operations Tools – und schreiben Sie jede Entscheidung in den Evidence Store.
5. MCP Registry und Tool Governance. Enterprise-Architekturen bewegen sich in Richtung Private Registries mit Schema Review, Security Scanning und Approval Workflows, bevor ein Server produktiv genutzt werden darf. Behandeln Sie Tool Descriptions als Teil der Security Surface: Das Modell liest sie, um zu entscheiden, welches Tool aufgerufen wird.
6. Document & Knowledge Governance. Ein DMS enthält Verträge, Policies, KYC-Unterlagen und andere Informationen, die Agenten benötigen – häufig mit Berechtigungen, die ursprünglich für Menschen und Ordnerstrukturen entwickelt wurden. Retrieval aus unkontrollierten Dokumentenspeichern ist ein direkter Weg, vertrauliche Informationen in Antworten offenzulegen. Die Durchsetzung dokumentenspezifischer ACLs zum Zeitpunkt des Retrievals ist unspektakulär, aber unverzichtbar.

Drei realistische Szenarien

Advisor Copilot – read-heavy und heute bereits realistisch. Ein Berater fragt im Kontext aktueller Richtlinien nach dem Portfolio eines Kunden. Der Agent ruft über MCP Retrieval-, CRM- und Portfolio-Tools im Namen der Identität des Beraters auf – und nichts erreicht den Kunden ohne Freigabe des Beraters. Dieses Szenario läuft weitgehend auf bereits vorhandener Infrastruktur. Die wesentlichen Anpassungen betreffen Identity Binding und das Output Gate. Deshalb sind Advisor Copilots 2026 deutlich verbreiteter als autonome Payment Agents.

Payment-Exception-Triage – propose, don't execute. Eine markierte oder fehlgeschlagene Zahlung landet auf dem Event Bus. Der Agent analysiert den Status über verschiedene Payment Rails hinweg, berücksichtigt Screening-Ergebnisse und Account Context und schreibt anschliessend einen Lösungsvorschlag mit Begründung in das Case Management System – wo Operations die eigentliche Aktion ausführt.

Write Access bleibt auf das Case Tool beschränkt und die Autonomie auf Propose. Was dieses Szenario heute häufig verhindert, ist nicht das Modell, sondern Workstream 2 – Simulation Endpoints und Scoped Writes – sowie ein Evidence Store, mit dem sich die Triage gegenüber einem Regulator nachvollziehbar erklären lässt.

Periodisches KYC-Review – long-running und evidence-critical. Zum geplanten Zeitpunkt sammelt der Agent Registerdaten, extrahiert Informationen aus Dokumenten im DMS, erstellt einen Entwurf für die Risk Reassessment und stellt ein Evidence Pack zusammen. Anschliessend prüft und unterzeichnet ein menschlicher Analyst das Ergebnis.

Dieses Szenario nutzt praktisch alle neuen Architekturbausteine gleichzeitig: einen asynchronen Task Lifecycle mit Checkpoints über mehrere Stunden, DMS Governance aus Workstream 6 und eine tamper-evident Evidence Chain, weil das Ergebnis selbst ein Compliance-Artefakt ist. Gleichzeitig ist hier der potenzielle Nutzen besonders hoch: Periodic Reviews sind volumenintensiv, stark prozessgetrieben und häufig von Backlogs betroffen.

Die richtige Reihenfolge

Bauen Sie zuerst die gemeinsamen Plattformbausteine auf: Identity Broker, MCP Registry, HITL-Service und Evidence Store. Jeder weitere Agent profitiert davon.

Nutzen Sie Szenario 1, um den Mehrwert auf bestehender Infrastruktur zu zeigen. Szenario 2 zwingt die Organisation dazu, die notwendige API Semantics sauber umzusetzen. Szenario 3 wird sinnvoll, sobald die Evidence Chain belastbar ist.

Und genau dabei wird etwas Grundsätzliches sichtbar: Ein Grossteil dessen, was für „Agent Readiness“ benötigt wird – governed APIs über dem Core, Event Access, Data Governance und machine-consumable Interfaces – ist klassische Modernisierungsarbeit mit einem neuen Sponsor. Banken, die beide Themen als eine gemeinsame Roadmap behandeln, können mit einem Programm zwei Ziele erreichen.