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.
- Level 0 — Beobachten. Lesender Zugriff auf Protokolle, Traces oder Transaktionen. Der Agent legt Muster oder Anomalien offen; nirgendwo Schreibzugriffe. Beispiel: Drift in
pacs.008-Ablehnungsraten je Korridor erkennen und das Operations-Team alarmieren. - Level 1 — Lesender Abruf. Liest aus operativen Systemen; gibt strukturierten Output für menschlichen Konsum aus. Beispiel: CSA-Klauselvariationen aus dem ISDA-Rahmenvertrag einer Gegenpartei extrahieren und Abweichungen vom Standard-Template der Bank kennzeichnen. Der Agent schreibt niemals in den Vertragsspeicher zurück.
- Level 2 — Entwurf für menschliche Einreichung. Erzeugt Inhalte, die ein Mensch prüft und einreicht. Beispiel: Entwurf einer Verdachtsmeldung aus einem Fraud-System-Alarm plus KYC-Datensatz plus Transaktions-Trace; der BSA-Officer liest, bearbeitet bei Bedarf und reicht ein. Das System of Record sieht nur die menschlich freigegebene Version.
- Level 3 — Eingegrenzte Ausführung. Ruft eine produktive API mit harten, deterministischen Limits auf, die der Wrapper durchsetzt. Beispiel: Karten-Sperre-API-Aufruf mit
max-amount-at-risk: 5000 USD, durchgesetzt über eine Allow-List-Policy; der Agent kann keine Karte sperren, die mit Beständen oberhalb dieser Schwelle verknüpft ist, ohne eine Level-2-Eskalation. Das Limit lebt in Policy-as-Code, nicht im Prompt — Prompts sind keine Sicherheitsgrenze. - Level 4 — Mehrwerkzeug-Orchestrierung mit verpflichtenden Checkpoints. Führt eine Sequenz über Systeme hinweg aus; jeder Zustandsübergang wird protokolliert; Checkpoints erfordern menschliche Freigabe vor dem nächsten Werkzeugaufruf. Beispiel: Payment-Repair-Workflow — gescheiterte
pacs.008aus der Dead-Letter-Queue extrahieren → korrekten Beneficiary über das SWIFT-KYC-Register nachschlagen → korrigierte Nachricht erzeugen → in Outbound-Queue schreiben → Mensch genehmigt das erneute Senden. Scheitert ein Schritt am Schema-Validator, hält der Workflow an und erzeugt einen Ausnahmefall. - Level 5 — Selbstorchestrierung. Der Agent plant und führt ohne Checkpoint-Freigabe aus. Kein produktiver Banking-Workflow sollte 2026 auf Level 5 stehen. Das ist keine Reifeaussage, sondern eine Zuverlässigkeitsaussage. OSWorld bei 66,3 % multipliziert sich über verkettete API-Aufrufe hinweg. Drei Werkzeugaufrufe à 66 % ergeben 29 % End-to-End-Erfolg. Fünf ergeben 13 %. Lassen Sie es.
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:
- Erste Linie (Model Owner). Dokumentiert den vorgesehenen Einsatz des Agenten, die Trainings- und Eval-Daten-Lineage, das System-Prompt-Schema, die Werkzeugaufruf-Allow-List und die Ergebnisse der Notabschaltungstests. Verantwortet das Drift-Monitoring in Produktion.
- Zweite Linie (MRM-Team). Validiert den Agenten vor Produktion. Der Validierungsbericht umfasst Vendor-veröffentlichte Eval-Scores (MMLU, HumanEval, HellaSwag sind nützlich, aber nicht ausreichend), bank-spezifische Eval-Scores (Ihre eigene Held-out-Evaluationsmenge aus operativen Beispielen — die Arbeit, in die die meisten Banken zu wenig investieren), Prompt-Injection-Red-Team-Ergebnisse, Bias- und Fairness-Analyse, wo der Workflow Kundenauswirkungen hat, und eine quantifizierte Restrisiko-Aussage.
- Dritte Linie (Interne Revision). Prüft die Kontrollebenen-Gates und die Audit-Protokoll-Vollständigkeit gegen eine Stichprobe produktiver Entscheidungen. Der Audit-Zyklus 2027 wird sehr anders aussehen als jener von 2025; planen Sie das Budget jetzt ein.
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:
- Kosten pro abgeschlossener Entscheidung inklusive Rückabwicklungs- und Reparaturkosten gescheiterter Entscheidungen. Ein SAR-Entwurfs-Agent, der die Zeit des BSA-Officers um 40 % reduziert, aber 12 % falsch-positive Meldungen erzeugt, hat Wert vernichtet, nicht geschaffen.
- Vermiedene manuelle Eingriffe, gerechnet abzüglich neuer Eingriffe, die durch Kontrollebenen-Überwachung und Ausnahmebehandlung entstehen. Es geht nicht darum, menschliche Aufmerksamkeit zu minimieren, sondern sie auf hebelstärkere Entscheidungen umzulenken.
- Reversal-Rate — Prozentsatz der vom Agenten ausgeführten Aktionen, die binnen 24 Stunden rückabgewickelt werden. Eine Reversal-Rate über 2 % in einem Level-3-Workflow ist ein Zuverlässigkeitsproblem. Über 5 % ist es ein Kontrollebenen-Problem.
- Audit-Trace-Vollständigkeit — Prozentsatz der Entscheidungen, deren vollständige Provenienz aus dem WORM-Protokoll rekonstruierbar ist. Sollte in Level-3- und Level-4-Workflows 100 % betragen. Alles darunter ist ein Policy-Versagen, das in der Revision auffallen wird.
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 #
- Stanford HAI, (2026). Der 2026 AI Index Report ⧉.
- Stanford HAI, (2026). Kapitel Technical Performance ⧉.
- Cambridge Centre for Alternative Finance, (2026). 2026 Global AI in Financial Services Report ⧉.
- Federal Reserve, (2011). SR 11-7: Leitlinien zum Model Risk Management ⧉.
- Prudential Regulation Authority, (2023). Supervisory Statement SS1/23: Grundsätze des Model Risk Management für Banken ⧉.
- Europäische Kommission, (2024). Verordnung (EU) 2024/1689 — AI Act ⧉.
- NVIDIA, (2024). NeMo-Guardrails-Framework ⧉.
- Cloud Native Computing Foundation, (2018). Open Policy Agent (OPA) ⧉.
Zuletzt geprüft .
Zuletzt überprüft .
