Ein Auswahl- und Testleitfaden für regulierte Banken, die KI-Agent-Governance-Plattformen auswählen: benannte Kandidaten nach Kategorie, Zuordnung der Kontrollverantwortung, Einsatzgrenzen und neun reproduzierbare Fähigkeitstests.
Für Risiko-, Compliance-, Architektur- und Plattformteams von Banken, die für agentische Workloads mit finanziellen, kundenbezogenen oder aufsichtsrelevanten Folgen eine belastbare Shortlist erstellen.
Zuletzt aktualisiert: 24. Aug. 2026 · Version v2.1 · Keine Rechtsberatung.
Kurzantwort
Für eine regulierte Bank gibt es keine einzelne beste KI-Agent-Governance-Plattform. Eine belastbare Shortlist verbindet Kategorien: ein Governance-System of Record (IBM watsonx.governance, Credo AI, Holistic AI, OneTrust), Observability und Evaluierung (Arthur, Fiddler, Arize, LangSmith), ein AI-Gateway für erforderliche Verkehrsvermittlung (Azure API Management, Kong, LiteLLM, Portkey) sowie eine Runtime-Governance-Control-Plane, die jede folgenreiche Agentenaktion entscheidet und aufzeichnet (KLA; neuere Anbieter sind Control Zero und Switchboard). Wählen Sie nach Kontrollgrenze aus und führen Sie anschließend dieselben reproduzierbaren Fähigkeitstests mit jedem Kandidaten an einem realen Bank-Workflow durch.
„KI-Governance-Plattform“ umfasst inzwischen mehrere unterschiedliche Aufgaben. Ein Beschaffungsprozess wird klarer, wenn er jede Grenze einzeln bewertet und anschließend entscheidet, wo ein einzelner Anbieter, eine native Funktion oder ein spezialisiertes Tool sie glaubwürdig abdecken kann.
Dieser Leitfaden erstellt kein Anbieterranking. Dafür wären aktuelle, unabhängig geprüfte Nachweise zu Integrationsarten, Einsatzmodell, Verfügbarkeit, Assurance-Positionierung, Preisen und Betriebsgrenzen jedes Produkts erforderlich. Nutzen Sie die folgenden Kategorien für eine Shortlist und verlangen Sie anschließend von jedem Anbieter eine Demonstration desselben Workflows.
| Grenze | Verantwortungsbereich | Erforderlicher Nachweis |
|---|---|---|
| Governance-System of Record | Systeminventar, verantwortliche Personen, Risikoentscheidungen, Kontrollzuordnung sowie Release- oder Assessment-Historie. | Benannte verantwortliche Person, versioniertes Assessment, Zuordnung von Kontrolle zu System und Prüfverlauf. |
| Identität und Berechtigungen | Befugnisse von Agent, Mensch, Service und Tool; delegierter Umfang; Widerruf. | Auswertung der effektiven Berechtigung, Least-Privilege-Prüfung und Widerrufstest. |
| Verkehr und Integration | Konfigurierte Modell-, MCP-, API- oder Toolpfade; Zugangsdaten; Routing; Limits. | Architektur mit jedem vorgesehenen Pfad und Test zur Umgehung über den direkten Pfad. |
| Runtime-Durchsetzung | Entscheidung vor der Ausführung einer folgenreichen Aktion. | Beobachtete Ergebnisse für Erlaubnis, Warnung, Freigabe und Blockierung an der repräsentativen Aktion. |
| Menschliche Entscheidungsfindung | Befugnis der prüfenden Person, Kontext, Funktionstrennung, Ausnahmen und Eskalation. | Abgeschlossener Entscheidungsdatensatz, verknüpft mit unveränderlichen Anfrageparametern und der resultierenden Aktion. |
| Evidenz und Assurance | Ausführungslineage, Exporte, Aufbewahrung, Integrität und unabhängige Prüfung. | Portables Beispiel mit Entscheidung, Akteur, Richtlinie, Eingaben, Ergebnis und Prüfverfahren. |
Eine repräsentative Shortlist enthält in der Regel mehrere Kategorien. Kontrollen von Modellanbietern und AI-Gateways können konfigurierten Verkehr vermitteln. Policy-Decision- und Enforcement-Services können Richtlinien auswerten und anwenden. Agenten-Runtimes und Orchestrierungsprodukte verwalten die Ausführung. Observability-Produkte erfassen Engineering-Signale. Governance-Systeme of Record verwalten den Portfolio-Lebenszyklus. Runtime-Control-Planes verbinden Entscheidungsfindung, Durchsetzung, menschliche Prüfung und Ausführungsevidenz für den von ihnen abgedeckten Aktionspfad.
Keine Kategoriebezeichnung belegt vollständige Abdeckung. Ein Gateway kann Policy-Funktionen besitzen. Eine Governance-Plattform kann Guardrails enthalten. Eine Agenten-Runtime kann Freigaben anbieten. Bitten Sie jeden Anbieter um die genaue Komponente, die die Aktion vermittelt, den Akteur, der ihre Konfiguration verantwortet, und die Evidenz, die bei Erlaubnis oder Blockierung der Aktion aufbewahrt wird.
Diese repräsentativen Produkte können als Ausgangspunkt für die Shortlist einer Bank dienen. Die Tabelle bildet eine Ausgangsmenge. Ein verifizierter Fähigkeitsvergleich ist damit nicht verbunden. Sie nennt die Behauptung, die jede Kategorie belegen muss. Fähigkeiten, Einsatzoptionen, Zertifizierungen und Preise ändern sich. Prüfen Sie jede Zeile anhand der aktuellen Primärdokumentation des Anbieters und einer Live-Demonstration, bevor Sie sie bewerten.
KLA erscheint in der Zeile für Runtime-Governance-Control-Planes und veröffentlicht eigene Testergebnisse sowie Einschränkungen. Wenden Sie auf jeden Kandidaten denselben Maßstab an: Ein Anbieter, der beobachtetes Verhalten und aktuelle Einschränkungen veröffentlicht, gibt dem Bewertungsteam einen prüfbaren Gegenstand. Ein Anbieter, der ausschließlich Fähigkeitsbehauptungen veröffentlicht, gibt dem Team einen Vertrauensvorschuss.
| Kategorie | Repräsentative Produkte | Zu belegende Behauptung |
|---|---|---|
| Governance-System of Record | IBM watsonx.governance, Credo AI, Holistic AI, OneTrust AI Governance | Jedes agentische System im Bestand besitzt eine benannte verantwortliche Person, eine aktuelle Risikobewertung und eine Kontrollzuordnung, die ein Auditor nachvollziehen kann. |
| Observability und Evaluierung | Arthur, Fiddler, Arize, LangSmith, Langfuse, W&B Weave | Ein Produktions-Trace lässt sich mit der Policy-Entscheidung und dem geschäftlichen Seiteneffekt verknüpfen, und Qualitätsregressionen werden vor den Kunden sichtbar. |
| AI- und API-Gateways | Azure API Management (GenAI gateway), Kong AI Gateway, LiteLLM, Portkey | Jeder relevante Modell-, MCP- oder Toolaufruf läuft tatsächlich durch das Gateway, einschließlich alternativer Pfade. |
| Policy-Decision- und Enforcement-Services | Cerbos, Open Policy Agent, NVIDIA NeMo Guardrails | Eine Deny-Entscheidung verhindert die Aktion physisch an einem Enforcement Point, und ein Auswertungsfehler führt zu einer Ablehnung. |
| Runtime-Governance-Control-Planes | KLA; neuere Anbieter: Control Zero, Checkrd, Switchboard, WYNet | Jede folgenreiche Aktion erhält vor der Ausführung eine Entscheidung, Freigaben sind an die exakten Parameter gebunden und der Datensatz lässt sich offline verifizieren. Neuere Anbieter veröffentlichen starke Multicloud- und Framework-Angaben; testen Sie diese mit denselben neun Fähigkeitstests. |
| Werkzeuge für die Integrität von Auditnachweisen | ChainProof, TraceSeal; vorgeschlagener AAS-1-Standard | Das exportierte Datensatzformat ist portabel, das Prüfverfahren läuft ohne Anbieterinfrastruktur und der Anbieter beschreibt, was der Nachweis der Unveränderbarkeit belegt und was er offenlässt. |
Verwenden Sie als regulierte Bank einen Workflow mit realem Seiteneffekt und den prüfenden Personen, die ihn betreiben werden. Eine Zahlungsfreigabe, eine Änderung eines Kundendatensatzes oder eine AML-Eskalation kann Lücken sichtbar machen, die eine Feature-Checkliste übersieht. Der Workflow sollte eine definierte verantwortliche Person, Agentenidentität, Toolbefugnis, Richtlinie, Freigaberegel und Evidenzanforderung enthalten.
Ziel ist ein entscheidungsreifer Datensatz. Erfassen Sie für jeden Kandidaten die Integrationsgrenze, das Policy-Verhalten, die menschliche Befugnis, den betrieblichen Fehlerfall, das Exportformat und die Ausstiegsverpflichtungen. Die rechtliche Einordnung und die regulatorische Anwendbarkeit bleiben institutions- und anwendungsfallspezifische Beurteilungen.
KLA veröffentlicht die vollständige Testsuite als reproduzierbares Verfahren: neun nummerierte Fähigkeitstests (RT-01 bis RT-09) zu Umgehung der Durchsetzung, Ausfall der Policy-Engine, geänderten Parametern nach der Freigabe, abgelaufenen Freigaben, Replay, Wiederholungen, Aufbewahrung von Zugangsdaten, Änderung von Datensätzen und Offline-Verifizierung von Evidenz. Die veröffentlichte Version enthält KLA’s eigene beobachtete Ergebnisse, die sie absichernden automatisierten Tests und KLA’s aktuelle Einschränkungen. Führen Sie dieselben neun Verfahren mit jedem Kandidaten durch und vergleichen Sie die Ergebnisse unter gleichen Bedingungen.
Dokumentieren Sie vor der Anbieterbewertung, welche Kontrollen unabhängig von der Produktwahl bei der Bank liegen müssen, welche bei einem Anbieter liegen können und welche gemeinsam verantwortet werden. Die folgende Matrix entspricht dem Ergebnis vieler Bankbewertungen. Die Einsatzgrenze ist ebenso wichtig wie die Verantwortung: Halten Sie für jede Kontrolle fest, wo sie läuft (in den Räumlichkeiten der Bank, in der Cloud-Mandantenumgebung der Bank, im SaaS des Anbieters) und was mit laufenden Aktionen geschieht, wenn die Verbindung zwischen diesen Grenzen ausfällt.
| Kontrolle | Verantwortlich | Hinweis zum Einsatz |
|---|---|---|
| Risikobereitschaft, Policy-Schwellenwerte, Prüferbefugnis | Bank | Von der Bank in der Policy-Oberfläche der Plattform erstellt; exportierbar und versioniert. |
| Geschäftsberechtigungen und Identität | Bank | Aus dem IAM der Bank bezogen; die Plattform konsumiert und bewertet, die Bank bleibt maßgeblich. |
| Policy-Auswertung und Enforcement Point | Gemeinsam | Der Anbieter betreibt die technische Grundlage; die Bank prüft Durchsetzungspfad und Fehlerverhalten (RT-01, RT-02). |
| Freigabewarteschlange und Vier-Augen-Regeln | Gemeinsam | Der Anbieter stellt die Entscheidungsoberfläche bereit; die Bank verantwortet Entscheider, Ablaufzeitfenster und Eskalation. |
| Evidenzdatensätze und Aufbewahrung | Bank | Datensätze müssen in einem ohne den Anbieter verifizierbaren Format in bankgesteuerten Speicher exportiert werden (RT-09); die Aufbewahrung folgt dem Zeitplan der Bank. |
| Ausstieg und Kontinuität | Bank | Geprüfter Export, Fallback-Betriebsmodus für den gesteuerten Workflow und vertragliche Unterstützung der Beendigung nach DORA-Vorgaben für Dritte. |
KLA ist eine Runtime-Governance-Control-Plane. Bei über das Gateway gerouteten Toolaufrufen wertet die Implementierung vor dem Start des Tool-Executors eine Entscheidung aus und kann erlauben, warnen, eine Freigabe verlangen oder blockieren. Sie erfasst Policy- und Autorisierungskontext für den von ihr gesteuerten Pfad. Pfadspezifische Abdeckung, Integrationskonfiguration, Verfügbarkeit des Signierers und Vollständigkeit der Evidenz müssen während der Implementierung geprüft werden.
Eine sinnvolle KLA-Bewertung ist daher ein begrenzter Test: Platzieren Sie den realen folgenreichen Toolaufruf auf dem gesteuerten Pfad, definieren Sie Richtlinie und Prüferbefugnis, führen Sie normale und negative Pfade aus und prüfen Sie anschließend die Ausführungslineage und den Export. Dadurch lässt sich das im Code vorhandene Verhalten von einer Aussage über jeden Pfad im Unternehmensbestand trennen. KLA’s beobachtete Ergebnisse zu allen neun Fähigkeitstests, die sie absichernden automatisierten Tests und die aktuellen Einschränkungen sind in der Testsuite für Runtime-Governance-Fähigkeiten veröffentlicht.
Beginnen Sie mit der Aktion, die die Folge auslöst. Klären Sie, welches System das Inventar und die verantwortliche Person besitzt, welche Identitäts- und Berechtigungskontrollen gelten, wo die Richtlinie ausgewertet wird, wie eine menschliche Entscheidung die Aktion pausiert oder verändert und wie der entstehende Datensatz geprüft oder exportiert werden kann.
Einige Produkte decken mehrere Ebenen ab, die Abdeckung ist jedoch eine Frage des Einsatzes und der Produktkategorie. Bestätigen Sie für die zu steuernde Aktion die genauen Pfade, Integrationsarten, Freigaben, das Fehlerverhalten, die Aufbewahrung und das Exportformat. Ein gut gestalteter Stack kann auch spezialisierte Produkte verbinden.
Verwenden Sie einen repräsentativen Workflow mit Folgen, etwa eine Zahlungsfreigabe, eine Änderung eines Kundendatensatzes oder eine Eskalation zur Finanzkriminalität. Testen Sie Identität und Befugnis, Umgehung über den direkten Pfad, Ausfall des Policy-Service, Bindung der Freigabe, Wiederholungen und Evidenzexport gemeinsam mit den Teams, die Risiko, Betrieb und Technologie verantworten.
Risikobereitschaft, Freigabebefugnis, Geschäftsberechtigungen und Verantwortung für den Ausstieg bleiben unter der Hoheit des Instituts. Entscheiden Sie anhand des tatsächlichen Integrationsaufwands und der Nachweisanforderungen, ob die technische Grundlage für Runtime-Durchsetzung, Freigabeworkflow, Evidenz und Betrieb selbst entwickelt, eingekauft oder kombiniert wird.
Erstellen Sie die Shortlist nach Kategorie und prüfen Sie jeden Kandidaten anhand seiner Primärdokumentation. Zu den Governance-Systemen of Record gehören IBM watsonx.governance, Credo AI, Holistic AI und OneTrust. Observability und Evaluierung umfassen Arthur, Fiddler, Arize und LangSmith. Zu den Gateways gehören Azure API Management, Kong, LiteLLM und Portkey. Zu den Runtime-Governance-Control-Planes gehört KLA; neuere Anbieter wie Control Zero, Checkrd und Switchboard sollten ihre Angaben im direkten Test belegen. Ausschlaggebend ist das beobachtete Verhalten jedes Kandidaten bei den neun Fähigkeitstests am eigenen Workflow der Bank.
Testsuite für Runtime-Governance-Fähigkeiten
/research/ai-agent-runtime-governance-test-suite
AI-Gateway oder Control-Plane
/guides/ai-gateway-vs-governance-control-plane
Entscheidungsrahmen für selbst entwickeln oder einkaufen
/guides/build-vs-buy-ai-agent-control-plane
KI-Governance im Bankwesen: Leitfaden 2026
/blog/ai-governance-banking-2026-guide
Lösung für Finanzdienstleister
/solutions/financial-services
Beispiel für die Ausführungslineage
/resources/evidence-room-sample
