Compliance-Teams in Banken sollten jeden Agenten-Anwendungsfall mit erheblichen Auswirkungen den bereits geltenden Risikokontrollen zuordnen. Der am 4. November veröffentlichte Leitfaden der OCC für Bankprüfer gibt Anlass, diese Zuordnung zu überprüfen. Er schafft ausdrücklich keine neuen regulatorischen Erwartungen; von Banken wird nicht erwartet, dass sie ihn zur Selbstbewertung verwenden. Ein sinnvoller erster Schritt ist eine kurze, überprüfbare Zuordnung, die die geschäftliche Handlung eines Agenten mit der bereits zuständigen Person für den jeweiligen Kontrollmechanismus und einem vorhandenen Nachweis verknüpft.
Was die OCC veröffentlicht hat
OCC Bulletin 2026-54 führt einen Rahmen für Prüfer ein. Der darin verwendete Begriff Super Intelligence umfasst Technologien, die zuvor als KI bezeichnet wurden. In der Ankündigung heißt es, Prüfer sollten KI nicht als eigene Risikokategorie behandeln, und Banken sollten nicht verpflichtet werden, eine eigene Risikobereitschaft für KI festzulegen. Reuters berichtet unabhängig über die Veröffentlichung und den Fokus auf Folgen statt auf die technische Raffinesse eines Modells.
Das Bulletin schließt neue aufsichtliche Erwartungen, durchsetzbare Standards und präskriptive Anforderungen ausdrücklich aus. Diese Einordnung ist wichtig, wenn aus einem internen Briefing ein Projektantrag wird. Dies als verpflichtenden neuen KI-Kontrollrahmen zu bezeichnen, würde die Quelle falsch darstellen. Die nachstehende Zuordnung ist eine Analyse von Maetra zur Organisation bestehender Arbeit, keine OCC-Checkliste und keine Feststellung zu den rechtlichen Pflichten einer bestimmten Bank.
Mit dem konkreten Bankvorgang beginnen
Ein Inventareintrag wie „Assistent auf Basis eines Sprachmodells“ lässt dem Risikoverantwortlichen zu wenig Information. Beschreiben Sie zuerst die geschäftliche Handlung: die Erstellung einer internen Analyse, das Verfassen einer Kundennachricht, die Änderung eines Falldatensatzes oder die Auslösung einer Transaktion. Beschreiben Sie dann, wie Mensch und Agent die Aufgabe untereinander aufteilen.
Für einen hypothetischen Agenten im Kundenservice sollte festgehalten werden, ob er lediglich eine Antwort vorschlagen, einen Entwurf speichern, die Nachricht absenden oder Änderungen am Konto des Kunden vornehmen kann. Diese Berechtigungen erzeugen unterschiedliche Prüfanforderungen, auch wenn jede Version dasselbe Modell nutzt. Stellen Sie fest, welche Grenze im laufenden Betrieb tatsächlich gilt, und ermitteln Sie, wer sie ändern kann. Eine Fähigkeit auf der Roadmap gehört in ein anderes Feld als eine Berechtigung, die heute aktiv ist.
Halten Sie den Eintrag eng genug, damit er geprüft werden kann. Ein Agent mit mehreren wesentlich unterschiedlichen Aktionen kann mehrere Einträge auf Aktionsebene benötigen. Ein einziges abteilungsweites Label wie „KI freigegeben“ kann verschleiern, welcher Arbeitsablauf geprüft wurde und welche spätere Ergänzung den zuständigen Verantwortlichen nie erreicht hat.
Bestehende Kontrollen und zuständige Personen zuordnen
Maetra empfiehlt einen kleinen Zuordnungsdatensatz mit sechs Feldern:
- Anwendungsfall und Aktion: der geschäftliche Zweck und die genaue Handlung, die der Agent ausführen darf.
- Bestehender Risikobereich: die bankeigene zutreffende Klassifizierung mit einer Begründung für die Zuordnung.
- Kontrollverantwortlicher: die Person, die für die relevante Zugriffs-, Änderungs-, Prüf- oder Überwachungskontrolle verantwortlich ist.
- Betriebsgrenze: die Daten, Systeme, Transaktionsgrenzen und Prüfschritte mit menschlicher Beteiligung, die die Handlung derzeit begrenzen.
- Nachweisreferenz: die Konfigurations-, Test- oder Prüfdokumentation, die die genannte Grenze stützt.
- Prüfanlass: die Änderung, die dazu führen würde, dass der Nachweis erneut geprüft werden muss.
Der Wert liegt in den Beziehungen zwischen diesen Feldern. Ein Verantwortlicher für Zugriffskontrollen sollte die Berechtigungskonfiguration finden können, ohne das Modellteam um die Rekonstruktion einer Präsentation bitten zu müssen. Ein Geschäftsverantwortlicher sollte erklären können, warum eine bestimmte externe Wirkung innerhalb des freigegebenen Ablaufs bleibt.
Manche Handlungen berühren mehrere bestehende Risikobereiche. Weisen Sie einen koordinierenden Verantwortlichen zu und benennen Sie die mitwirkenden Verantwortlichen, statt konkurrierende Kopien derselben Kontrolle anzulegen. Halten Sie Meinungsverschiedenheiten ausdrücklich fest. Eine ungeklärte Zuordnung ist nützliche Information, eine saubere Tabelle mit nur unterstellter Einigkeit ist weniger nützlich.
Eine Grenze an einem konkreten Beispiel testen
Betrachten Sie einen hypothetischen Agenten, der eine Zahlungsanweisung zur Prüfung durch einen Mitarbeiter vorbereitet. Bitten Sie den technischen Verantwortlichen, in einer geeigneten Testumgebung zu zeigen, was den Agenten daran hindert, sie selbst zu übermitteln. Der Nachweis könnte eine Rollenkonfiguration, die einschlägigen Integrationsberechtigungen und einen Test umfassen, der zeigt, dass der Übermittlungsversuch abgewiesen wurde.
Wenn der Agent innerhalb eines Grenzwerts selbst übermitteln kann, erfassen Sie diese andere Grenze und die für den Grenzwert verantwortliche Person. Verwenden Sie den Test für den reinen Entwurfsmodus nicht erneut als Nachweis für den Übermittlungsablauf. Ein erfolgreicher Test braucht außerdem ein Datum und eine Konfigurationsreferenz, damit eine spätere Berechtigungsänderung nicht stillschweigend das frühere Ergebnis übernimmt.
Dieser Ansatz hilft, drei Fragen voneinander zu trennen: was das System tun sollte, wozu es konfiguriert war und was der Test tatsächlich gezeigt hat. Wenn diese Antworten voneinander abweichen, beschreiben Sie die Lücke, bevor Sie eine neue Aussage zur Absicherung hinzufügen. Der Leitfaden von Maetra zur Zuordnung von KI-Systemen zu Compliance-Pflichten erläutert die umfassendere Zuordnungsaufgabe.
Die Reaktion verhältnismäßig halten
Eine neu veröffentlichte Ressource für Prüfer rechtfertigt nicht die Verdopplung jedes Risikoprozesses. Beginnen Sie mit einem wesentlichen Anwendungsfall, identifizieren Sie seine bestehenden Verantwortlichen und bestimmen Sie die Nachweise, die bereits gepflegt werden. Ergänzen Sie fehlende Referenzen oder einen gezielten Test dort, wo die aktuelle Dokumentation eine konkrete Frage nicht beantworten kann.
Maetra Comply unterstützt Framework-Zuordnung und wiederverwendbares Nachweismanagement. Discover unterstützt das Inventar von Agenten und Fähigkeiten, das dieser Zuordnung überhaupt einen Gegenstand gibt. Keines von beiden stellt die regulatorische Compliance einer Bank fest oder ersetzt ihre eigene Bewertung der anwendbaren Anforderungen. Teams, die diese Arbeit prüfen, können die Framework-Abdeckung von Maetra nutzen, um eine klar begrenzte Zuordnungsübung zu planen.