Sebastien Rousseau

Der Agentic-AI-Index für Banken 2026: Autonomie, Governance, Audit

Agentic AI in Banken ist ein Engineering-Problem im AI-Kostüm. Das Modell ist austauschbar; die OAuth-skopierten Service-Konten, der deterministische semantische Router, die Open-Policy-Agent-Gates, das WORM-Audit-Protokoll und die getestete Notabschaltung sind es nicht.

12 Min. Lesezeit
Banner for: Der Agentic-AI-Index für Banken 2026: Autonomie, Governance, Audit

Der Agentic-AI-Index für Banken 2026: Autonomie, Governance, Auditierbarkeit und Geschäftsauswirkungen

Agentic AI im Banking ist inzwischen ein Engineering-Problem im AI-Kostüm. Das Modell ist austauschbar; die Kontrollebene ist es nicht. Die Herausforderung 2026 ist nicht die Einführung — Cambridge CCAF beziffert sie bereits auf 52 % —, sondern die Frage, ob die autonomen Systeme, die Ihre Bank heute betreibt, im nächsten Quartal eine SR-11-7-Prüfung bestehen. Die meisten können das nicht.


Executive Summary / Wichtige Erkenntnisse

  • Hören Sie auf, sie Chatbots zu nennen. Die produktive Einheit ist ein eingegrenzter Workflow mit strikten Werkzeugaufruf-Berechtigungen. Die Arbeit geschieht innerhalb des Workflows, nicht innerhalb des LLM.
  • OSWorld bei 66,3 % ist die Zuverlässigkeitsobergrenze. Der Stanford-HAI-Benchmark, der dem Enterprise-Werkzeugeinsatz am nächsten kommt, scheitert weiterhin an einer von drei strukturierten Aufgaben. Das ist eine Zahl, die eine aggressive Human-in-the-Loop-Bereitstellung rechtfertigt; sie rechtfertigt keine unbeaufsichtigte Ausführung von irgendetwas, das Kundengelder berührt.
  • Klassifizieren Sie nach Berechtigungen, nicht nach Intelligenz. Die Autonomieleiter reicht von Level 0 (lesende ISDA-Klauselextraktion) bis Level 4 (mehrwerkzeugbasierte Zahlungskorrektur mit verpflichtenden Checkpoints). Level 5 — selbstorchestrierende Ausführung ohne Checkpoints — sollte 2026 nicht im produktiven Banking existieren.
  • Die Agent-Kontrollebene besteht aus fünf konstruierten Komponenten, nicht aus einem Policy-Dokument. OAuth-skopierte Service-Konten, deterministisches semantisches Routing, Open-Policy-Agent-Gating, WORM-Audit-Protokollierung und eine getestete Notabschaltung. Alles Fehlende ist ein Befund.
  • SR 11-7 und PRA SS1/23 gelten bereits. Die Fed hat wiederholt klargestellt, dass jedes Input-zu-Output-Entscheidungssystem in den Anwendungsbereich fällt. Banken, die argumentieren, ein LLM sei kein Modell, haben das regulatorische Argument verloren, bevor sie es vorgebracht haben.

Warum 2026 das Jahr ist, in dem dieser Index zählt #

Die Verschiebung von Chat zu eingegrenzten Workflows ist das Einzige, was 2026 bei Agentic AI für Banken zählt. Ein Chatbot, der eine Kunden-E-Mail entwirft, lässt sich überprüfen. Ein Agent, der POST /accounts/{id}/freeze gegen Ihre produktive Kartenplattform aufruft, ist prüffähiger Nachweis. Die Produktion hat den Rahmen eingeholt: Die Cambridge-CCAF-Erhebung 2026 berichtet 52 % aktive Agentic-Adoption und 23 % auf Scaling- oder Transforming-Reifegrad (Cambridge CCAF ⧉). Die Schwelle „isolierter Pilot" wurde irgendwann Ende 2025 überschritten.

Zwei Dinge haben sich parallel zur Adoption verschoben.

Erstens haben Aufsichtsbehörden aufgehört, LLMs als Neuheit zu behandeln. Die Federal Reserve hat klargestellt, dass SR 11-7 ⧉ auf LLM-basierte Entscheidungsfindung anwendbar ist, unabhängig davon, ob das LLM intern als Modell klassifiziert wird. Die SS1/23 ⧉ der PRA war ohnehin breit genug, um sie zu erfassen. Die Hochrisiko-Klassifizierung des EU-AI-Acts deckt die meisten Finanzdienstleistungs-LLM-Anwendungen ab. Es bleibt kein „wir sind nicht sicher, ob das zählt"-Argument mehr übrig.

Zweitens hat die Benchmark-Realität nachgezogen. Der 2026 AI Index von Stanford HAI verzeichnet OSWorld — den verfügbar nächsten Benchmark zu echtem Enterprise-Werkzeugeinsatz — bei 66,3 % Genauigkeit (Stanford HAI ⧉). Eine von drei strukturierten Aufgaben scheitert weiterhin. Diese Zahl setzt 2026 die technische Obergrenze der Autonomie. Hoch genug, um eingegrenzte Level-3-Deployments unter HITL-Aufsicht zu rechtfertigen; nicht hoch genug, um eine unbeaufsichtigte Ausführung gegen eine API zu rechtfertigen, die Kundengelder berührt.

Der Agentic-AI-Index für Banken muss für LLM-basierte Entscheidungsfindung leisten, was der Basel-Rahmen für Kapital geleistet hat: „Wir haben Kontrollen"-Behauptungen in messbaren, prüffähigen Nachweis pro Workflow überführen.

Die Architektur des 2026-Index #

Index-Ebene Wie „Bereit" aussieht Reifekennzahl Fehlermodus
Autonomiestufe Jeder produktive Workflow ist mit Level 0–4 markiert; kein Level 5 in Produktion % Workflows je Stufe; Anteil bei Level 3+ Produktiver Agent sendet eine pacs.008 an eine halluzinierte Beneficiary-BIC, weil keine statische Allow-List die Payload vor SWIFTNet absichert
API-Berechtigungen Jeder Agent ist genau einem Service-Konto mit Least-Privilege-OAuth-Scopes zugeordnet (z. B. card-freeze:write:lt-5000usd); MTLS zum Legacy-Core % Agenten mit Least-Privilege; Anzahl verwaister Berechtigungen Agent wiederverwendet ein überprivilegiertes Service-Konto; iteriert Konten, die er nicht hätte lesen dürfen; GDPR-Artikel-33-Meldung innerhalb von 72 Stunden
Deterministische Schutzmechanismen Jeder Werkzeugaufruf läuft über einen semantischen Router (NeMo Guardrails / LangChain Guardrails) plus JSON-Schema-Validator vor der API % abgefangener Werkzeugaufrufe; Ablehnungsrate je Kategorie LLM emittiert einen transfer-Aufruf mit amount: 0; nachgelagerte API validiert nicht; Ledger-Reconciliation-Alarm landet 18 Stunden später in einer anderen Zeitzone
Human-in-the-Loop-Abdeckung Jede Level-3-Ausführung blendet eine Freigabe-UI mit hartem Timeout ein; Auto-Approve ist per Policy deaktiviert Freigabedurchsatz; Rubber-Stamp-Rate (Freigaben unter 2 Sekunden) Operator klickt in 4 Minuten 200 Alarme auf „approve"; SAR wird gegen einen legitimen Kunden eingereicht; Aufsichtsbeschwerde binnen einer Woche
Audit-Vollständigkeit Unveränderliches WORM-Protokoll erfasst System-Prompt + abgerufenen Kontext + LLM-Ausgabe + Werkzeugaufruf + Tool-Ergebnis + Freigeber-UID; kryptographisch signiert zum Schreibzeitpunkt % Aufrufe mit vollständigem Trace SR-11-7-Prüfer fragt, warum Agent #4421 einen Wire über 4,8 Mio. USD freigegeben hat; Bank hat die Wire-Quittung und die Model Card; kein Prompt-Level-Nachweis; Prüfungsbefund
Unit Economics Kosten pro abgeschlossener Entscheidung inklusive Rückabwicklungs- und Reparaturkosten erfasst; positiv gegenüber manueller Baseline Nettokosten je Entscheidung; Reversal-Rate Token-Ausgaben für Edge-Case-Agenten übersteigen die manuellen Ermittlerkosten, die sie ersetzt haben; CFO stoppt das Programm im Q3

Aktuelle Signale, die es zu verfolgen gilt #

Signal Was es für Banken bedeutet Quelle
52 % aktive Adoption Agentic AI ist über die Pilotphase hinaus; institutionsweite Governance ist überfällig Cambridge CCAF ⧉
23 % im Scaling oder Transforming Eine relevante Minderheit hat das Proof-of-Concept-Theater hinter sich gelassen Cambridge CCAF ⧉
OSWorld bei 66,3 % Eine von drei Fehlerquote beim strukturierten Werkzeugeinsatz. Eine unbeaufsichtigte Ausführung gegen Kundengelder-APIs ist auf diesem Zuverlässigkeitsniveau nicht vertretbar Stanford HAI ⧉
55 % nennen Verlust menschlicher Aufsicht als Top-Risiko Kontrolldesign ist das primäre Engineering-Anliegen, kein nachgelagertes Compliance-Thema Cambridge CCAF ⧉
76 % der großen FIs tun sich schwer, Wert zu messen Generische Produktivitätsversprechen halten einer CFO-Diskussion nicht stand. Messen Sie pro Workflow, nicht pro Programm Cambridge CCAF ⧉

Die Autonomieleiter #

Klassifizieren Sie Agenten danach, was sie tun dürfen, nicht danach, wie clever das zugrunde liegende Modell ist. Dieselbe GPT-5- / Claude-4- / Gemini-3-Instanz kann auf jeder Stufe sitzen; was sich unterscheidet, ist der Wrapper.

Die Agent-Kontrollebene #

Die Kontrollebene ist die Engineering-Schicht zwischen dem LLM und Ihren produktiven Systemen. Fünf Komponenten, alle zur Laufzeit, keine davon in einem Policy-Dokument niedergeschrieben.

1. Identität und Berechtigungen #

Jeder Agent ist genau einem Service-Konto zugeordnet. Dieses Konto hält OAuth-client_credentials-Tokens, die auf die minimal notwendige API-Oberfläche skopiert sind. Das Token des Karten-Sperre-Agenten kann POST /accounts/{id}/freeze mit amount-at-risk: 0..5000 usd aufrufen. Es kann nicht GET /accounts/{id}/balance für andere Kunden aufrufen. Es kann nichts in Custody, Treasury oder Trading aufrufen. Service-Konto-Geheimnisse rotieren wöchentlich; langlebige Credentials sind der häufigste Kontrollebenen-Fehler in produktiven Deployments.

2. Deterministische Schutzmechanismen für Werkzeugaufrufe #

Jeder LLM-Werkzeugaufruf läuft durch einen deterministischen semantischen Router (NeMo Guardrails, LangChain Guardrails oder Äquivalent), bevor der Aufruf die produktive API erreicht. Der Router klassifiziert die Absicht gegen eine endliche Allow-List; Aufrufe außerhalb der Liste werden abgelehnt und protokolliert. Anschließend prüft ein JSON-Schema-Validator die Payload — Pflichtfelder vorhanden, Geldbeträge innerhalb der Grenzen, ISO-Ländercodes gültig, Beneficiary-BIC auf der vorab genehmigten Gegenpartei-Liste der Bank. Der Validator sollte paranoid sein: Eine pacs.008 mit amount: 0 ist ein Modellfehler, keine legitime Transaktion. Genauso ein Wire in ein Land, das Ihr Sanktionsfilter für das ursprüngliche Kundensegment nicht vorab genehmigt hat.

3. Policy-as-Code #

Open Policy Agent (oder Äquivalent) sitzt zwischen Validator und API. Policies sind in Git versioniert; Ablehnungsentscheidungen werden protokolliert; dieselbe Policy-Engine, die Microservice-zu-Microservice-Aufrufe in Ihrer bestehenden Plattform absichert, sichert auch Agent-Werkzeugaufrufe ab. Agenten als Sonderklasse mit maßgeschneidertem Gating zu behandeln, führt dazu, dass Banken mit Schatten-Kontrollebenen enden, die sechs Monate später niemand im Plattform-Team mehr versteht.

4. Audit-Protokollierung #

Unveränderlicher WORM-Speicher — S3 Object Lock, Azure-Blob-Immutability oder eine ledger-basierte Datenbank. Jeder Aufruf erfasst: Zeitstempel, Agent-ID, Service-Konto-ID, System-Prompt-Hash, abgerufenen Kontext, LLM-Anbieter plus Modell plus Version, rohe LLM-Ausgabe, geparsten Werkzeugaufruf, OPA-Entscheidung, API-Antwort, nachgelagerten Effekt und gegebenenfalls Freigeber-UID. Datensätze werden zum Schreibzeitpunkt kryptographisch signiert. Dieses Protokoll werden SR-11-7- und SS1/23-Prüfer einfordern. Wenn Sie für eine beliebige Entscheidung keinen vollständigen Trace vorlegen können, betreiben Sie keinen unter Model Risk Management geführten Agenten.

5. Notabschaltung #

Eine Red-Button-API, die alle in Flight befindlichen Agent-Aufrufe innerhalb einer Berechtigungsklasse in unter 60 Sekunden abbricht. Quartalsweise in einer Tabletop-Übung getestet. Die Notabschaltung ist das Einzige, was Sie aus einem Vendor-Modell-Release rettet, das still regrediert, aus einem Prompt-Injection-Vektor, den Sie nicht antizipiert haben, oder aus einem Drift-Ereignis, das False-Positive-Raten über Ihre operative Schwelle treibt. Ungetestete Notabschaltungen funktionieren nicht; planen Sie die Übungszeit ein.

Model Risk Management #

Banken, die argumentieren „ein LLM ist kein Modell unter SR 11-7", haben bereits verloren. Die Federal Reserve hat wiederholt klargestellt, dass jedes Input-zu-Output-System, das in einem Entscheidungs-Workflow verwendet wird, im Anwendungsbereich liegt. Die SS1/23 der PRA ist noch breiter. Die richtige Haltung: Jeden produktiven Agenten ab Tag eins als SR-11-7- / SS1/23-Modell behandeln. Die Kosten, einen bereits ausgerollten Agenten nachträglich als Modell einzuordnen, sind ein Vielfaches der Kosten, ihn von Beginn an als solches zu konzipieren.

Drei Verteidigungslinien, angewendet auf Agenten:

Kontinuierliches Monitoring ist wichtiger als Punkt-in-Zeit-Validierung. Bank-spezifische Eval-Suiten, die wöchentlich neu laufen, fangen Modell-Update-Regressionen ab, die Vendor-Benchmarks nicht offenlegen. Die Release-Frequenz von OpenAI, Anthropic und Google ist schneller als Ihre Validierungsfrequenz; entweder schließt sich die Lücke dadurch, dass Sie kontinuierliche Evals fahren, oder sie schließt sich durch einen Prüferbefund.

Geschäftsauswirkungen messen #

Generische Produktivitätsversprechen halten einer CFO-Diskussion nicht stand. Messen Sie Agenten so, wie Sie andere operative Veränderungen messen:

Wenn ein Workflow schneller, aber weniger erklärbar wird, muss der Index ihn bestrafen. Der billigste Weg, eine regulatorische Prüfung zu verlieren, ist, auf Durchsatz zu optimieren und den Trace zu verlieren.

Was das je Banktyp bedeutet #

Global Systemrelevante Banken #

Das harte Problem ist Governance im Skalierungsmaßstab: Hunderte Agenten quer über Geschäftsbereiche, jeder mit eigenem Model Owner, jeder ein potenzieller Prüfungsbefund. Die Investition ist kein weiterer Pilot. Sie ist die zentrale Kontrollebene, die einheitliche Audit-Protokoll-Infrastruktur und ein MRM-Team, das 50-plus Agenten pro Quartal validieren kann. Ohne diese Kapazität landen Agenten schneller, als sie governed werden können, und das Institut akkumuliert SR-11-7-Exposure im Stillen.

Transaction- und Corporate-Banken #

Die ROI-stärksten Workflows sind Payment Repair, KYC-Dokumentenextraktion, Treasury-Services-FAQ-Deflection und Reconciliation Breaks. Alles Level-2 oder eingegrenztes Level-3. Den Firmenkunden interessiert es nicht, dass ein Agent die Arbeit erledigt hat; ihn interessiert, dass das SLA besser wurde und die Disputrate flach blieb. Führen Sie mit den Kennzahlen, nicht mit der Technologie.

Regionalbanken #

Kaufen, nicht bauen. Wählen Sie einen Vendor, dessen Agent-Plattform die Kontrollebenen-Primitive bereits mitbringt — OAuth-Scoping, OPA-Integration, WORM-Audit-Protokollierung, getestete Notabschaltung — und validieren Sie diese Plattform gegen Ihr MRM-Framework. Eine maßgeschneiderte Kontrollebene zu bauen, ist eine mehrjährige Investition, die im regionalen Maßstab nicht differenziert. Setzen Sie die Engineering-Kapazität stattdessen für Workflow-Design und Operator-UX ein.

Fintechs, PSPs und Infrastrukturanbieter #

Die Produktfrage an Vendors lautet nicht „performt Ihr KI-Agent besser als Menschen". Sie lautet „erzeugt Ihre Plattform einen SR-11-7-konformen Audit-Trace ab Werk". Vendors, die das mit Ja beantworten, werden Enterprise-Deals abschließen. Vendors, die das nicht können, bleiben in Proof-of-Concept-Schleifen stecken, während das MRM-Team der Bank Gründe findet, die Validierung scheitern zu lassen.

Schlussbetrachtung #

Agentic AI in Banken 2026 ist ein Engineering-Problem. Die interessante Arbeit liegt in der Kontrollebene, nicht im Modell. Das Modell ist austauschbar; das OAuth-Scoping, der deterministische semantische Router, die OPA-Policy-Gates, das unveränderliche Audit-Protokoll und die Notabschaltung sind es nicht.

Die Institute, die in 18 Monaten gegenüber Aufsichtsbehörden glaubwürdig wirken, sind diejenigen, die jeden produktiven Agenten ab Tag eins als SR-11-7- / SS1/23-Modell behandeln, mit bank-spezifischen Eval-Suiten, die kontinuierlich laufen, und einer Kontrollebene, die so konstruiert ist, dass sie sicher scheitert. Die Institute, die das nicht tun, werden herausfinden, ob ihr MRM-Team 50-plus Remediation-Befunde pro Quartal bewältigen kann.

Messen Sie Agenten so, wie Sie jede operative Veränderung messen: Kosten, Zuverlässigkeit, Reversibilität, Nachweis. OSWorld bei 66,3 % ist Ihre Zuverlässigkeitsobergrenze. Planen Sie entsprechend.

Häufig gestellte Fragen #

Was ist Agentic AI im Banking?

Ein eingegrenzter Workflow, der ein LLM mit Werkzeugaufrufen in produktive Systeme, Laufzeit-Schutzmechanismen und Human-in-the-Loop-Checkpoints kombiniert. Die Arbeit geschieht innerhalb des Workflows, nicht innerhalb des Modells. Wer das Wort „Chatbot" gehört hat, ist in der falschen Kategorie.

Wo sollten Banken starten?

Bei Level-1- und Level-2-Workflows, in denen der Wert messbar und der Downside eingrenzbar ist: ISDA-Klauselextraktion, SAR-Entwurf, Payment-Repair-Triage, interne Wissensrecherche, Code-Review-Assistenz, KYC-Dokumentenklassifikation. Lassen Sie Level 3 aus, bis Ihre Kontrollebene OAuth-Scoping, semantisches Routing, OPA-Gating, WORM-Protokollierung und eine getestete Notabschaltung beherrscht.

Was ist das größte Risiko?

Agenten gegen produktive APIs ausführen zu lassen, ohne deterministische Schutzmechanismen zwischen LLM-Ausgabe und API. Die OSWorld-Zahl von 66,3 % ist die Warnung. Ungehüllte Werkzeugaufrufe bei dieser Fehlerrate gegen eine SWIFT-MT103- oder eine Kundengelder-API schreiben die Worst-Case-Schlagzeile des nächsten Aufsichtszyklus.

Gilt SR 11-7 für LLM-basierte Agenten?

Ja. Die Federal Reserve hat klargestellt, dass jedes Input-zu-Output-System, das in Entscheidungs-Workflows eingesetzt wird, unter SR 11-7 fällt. Die SS1/23 der PRA deckt im Vereinigten Königreich denselben Bereich ab. Die Hochrisiko-Klassifizierung des EU-AI-Acts deckt die meisten Finanzdienstleistungs-Anwendungsfälle ab. Die Debatte „ist das ein Modell" ist vorbei; handeln Sie entsprechend.

Wie sollte Agentic AI an Boards berichtet werden?

Vier Zahlen pro Workflow: Autonomiestufe, Audit-Trace-Vollständigkeit, Reversal-Rate, Nettokosten je Entscheidung. Plus eine Top-fünf-Liste der Restrisiken. Verzichten Sie auf die Model-Card-Foliengrafik.

Quellen #

Zuletzt geprüft .

Zuletzt überprüft .