Was muss erfüllt sein, bevor eine Bank einen KI-Agenten vom Pilot in die Produktion überführt? Sechs Gates

Warum Gates statt einer regulatorischen Checkliste?

Piloten bestehen meist mit Demonstrationen. Produktionsprüfungen scheitern an Nachweisen: ein Registereintrag, den niemand geschrieben hat, ein Datenfluss, den niemand gezeichnet hat, ein Test, der nach einem Modellwechsel nicht wiederholt wurde. Der abschliessende Bericht des Financial Stability Board (FSB) "Sound practices for responsible adoption of artificial intelligence" (15. Oktober 2026) ist die aktuellste länderübergreifende Referenz. Er beschreibt seine 12 Praktiken als solche, die Finanzinstitute "encouraged to consider" sind; sie seien "non-prescriptive and do not constitute a binding international standard" (FSB-Schlussbericht, S. 2). Die FINMA-Aufsichtsmitteilung 08/2024, die Hinweise der BaFin zu IKT-Risiken bei KI (23. Januar 2026), das Rundschreiben SR 26-2 der Federal Reserve sowie der EU AI Act und DORA ergänzen nationale und rechtliche Details.

Zwei Vorbemerkungen sind vor den Gates wichtig:

• Das meiste ist Leitlinie, nicht hartes Recht. Die BaFin bezeichnet ihre Hinweise als unverbindlich ("non-mandatory advice", keine "binding interpretation of DORA"). SR 26-2 "does not set forth enforceable standards or prescriptive requirements". Wenn dieser Artikel schreibt, eine Quelle "verlangt" oder "empfiehlt" etwas, entspricht das der Stärke der Formulierung. DORA und der AI Act sind verbindliches Recht; die Abschnitte unten sagen, wo sie gelten.
• Die Gates folgen dem Weg einer Bankklassifizieren, Daten verankern, Funktion belegen, begrenzen, beobachten und den Ausstieg planen.

Die schrittweise Lieferperspektive derselben Reise finden Sie in AI proof of concept to production for banks (EN). Die FSB-Praktiken im Einzelnen stehen in unserer FSB-Übersicht (EN).

Gate 1. Ist der Agent inventarisiert und risikoklassifiziert?

Was die Quellen erwarten. Praxis 5 des FSB: "Financial institutions implement an effective and systematic approach to assess the materiality and risk of AI use cases at the inception stage and thereafter." Praxis 3 verlangt von Risikomanagement-Rahmenwerken, "include processes for documentation of AI use, as well as for materiality and risk assessment." (FSB-Schlussbericht, Praxis 5 S. 31, Praxis 3 S. 24; Seitenzahlen sind die gedruckten Berichtsseiten.)

Die BaFin (S. 16, unverbindlich) geht den Weg über IKT-Assets: "Information and ICT assets (including components of AI systems) must be identified, classified, documented and continuously monitored. This also applies, for example, to training data sets, model implementations, software libraries, hardware, and internally and externally developed software." Die BaFin verknüpft das mit Art. 8 Abs. 4 DORA.

Die FINMA-Aufsichtsmitteilung 08/2024 (18. Dezember 2024, S. 4) hält fest, dass sie bei Instituten mit vielen oder wesentlichen Anwendungen geprüft hat, ob "a centrally managed inventory with a risk classification and resulting measures" besteht. Sie beobachtete, dass "some supervised institutions defined AI narrowly in order to focus on supposedly larger or new risks", und dass es "a challenge to ensure the completeness of inventories" sei, weil "since the advent of generative AI, applications are accessible to everyone" (S. 4). Sie hält zudem fest: "AI is not a high-risk application per se"; das Risiko hängt von Komplexität, Adaptivität und Autonomie, vom Anwendungsbereich und von der Integration in Prozesse ab (Fussnote 7, S. 5). Sie nennt nicht abschliessende Wesentlichkeitsfaktoren wie die Zahl der betroffenen Kunden und die Folgen von Fehlern oder Ausfällen (Fussnote 2, S. 3). Die Kriterien für die Klassifizierung "should be defined by the supervised institutions" (Fussnote 5, S. 4).

Auf der EU-Seite ist die Einstufung eine echte Frage und keine Formalität. Anhang III Nr. 5 Buchstabe b des AI Act nennt "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud". Nach der Verordnung (EU) 2026/1744 (dem "Digital Omnibus on AI", vom 8. Juli 2026, ABl. L, 24.7.2026) gelten die Pflichten für Hochrisiko-Systeme ab dem 2. Dezember 2027 für Systeme nach Art. 6 Abs. 2 und Anhang III und ab dem 2. August 2028 für Systeme nach Art. 6 Abs. 1 und Anhang I. Die meisten Kundensupport-, AML- und KYC-Agenten fallen nicht unter Anhang III; diese Schlussfolgerung muss der Einstufungsschritt jedoch dokumentieren, nicht voraussetzen. Details in EU AI Act and AI agents in banks (EN).

Nachweis, den eine Bank braucht. Ein Registereintrag pro Agent: Verantwortliche Person, Zweck, Modell und Version, Datenquellen, die Werkzeuge und Berechtigungen, die der Agent aufrufen kann, Autonomiestufe, Wesentlichkeitsbewertung mit Kriterien, Freigabedatum und der Auslöser für eine Neubewertung (neues Werkzeug, neue Modellversion, neue Daten).

Typischer Fehler. Der Pilot lief als Sandbox ohne Registereintrag, und die Werkzeuge, die der Agent aufrufen kann, wurden nie aufgelistet; der tatsächliche Wirkungsradius ist beim Go-live unbekannt.

Checkliste

• Der Agent hat einen Registereintrag mit namentlich benannter verantwortlicher Person.
• Die Liste der Werkzeuge und Berechtigungen ist vollständig und aktuell.
• Wesentlichkeitsbewertung und die AI-Act-Frage zu Anhang III sind schriftlich beantwortet.
• Auslöser für eine Neubewertung sind definiert.

Gate 2. Wissen Sie, welche Daten der Agent sieht und wo sie verarbeitet werden?

Was die Quellen erwarten. FSB-Praxis 7 (S. 35): "Financial institutions establish appropriate data governance to maintain data that is fit-for-purpose for training, testing and using AI (i.e. accurate, complete, consistent, reliable, secure)."

Die BaFin (S. 10) beobachtet, dass "many financial entities adopt risk-based requirements for the use of AI systems, depending on the criticality of the data used and the location of storage and processing." Zur Cloud-Nutzung (S. 18) heisst es: "entities are encouraged to perform a risk inventory of the AI application (materiality, data sensitivity, technical requirements)"; sie nennt "the risks of unauthorised data leakage, including to the cloud service provider". Auf S. 19 erwartet sie, dass das Institut den Überblick behält, "where (location/region)" die Verarbeitung stattfindet, unter Verweis auf Art. 30 Abs. 2 Buchstabe b DORA. Die FINMA stellte fest, dass "some supervised institutions have not defined any requirements or controls to ensure data quality for AI applications" und dass "data quality is therefore often more important than the selection of the specific model" (Aufsichtsmitteilung 08/2024, S. 5). Sie hält ausserdem fest, dass Institute bei zugekauften Lösungen "often have no influence on or knowledge of the underlying data" (S. 5).

Nachweis, den eine Bank braucht. Ein Datenflussdiagramm, das zeigt, was die Bank verlässt und in welche Region; Datenklassifizierung pro Feld; Nachweis von Maskierung oder Datenminimierung; Aufbewahrungsregeln für Prompts und Ausgaben; und die vertragliche Liste der Verarbeitungsstandorte.

Typischer Fehler. Der Pilot nutzte eine Kopie von Produktionsdaten in einem Entwickler-Tenant. Erst beim Produktionsdesign fragt jemand, wo die Inferenz läuft und ob Prompts gespeichert werden.

Antworten zum Datenstandort hängen vom jeweiligen Anbieter und der Bereitstellungsoption ab; stützen Sie sich daher auf die eigene Dokumentation des Anbieters statt auf eine pauschale Aussage. Zum Schweizer Blickwinkel siehe Claude for Swiss banks: data residency (EN).

Checkliste

• Das Datenflussdiagramm ist von der Informationssicherheit genehmigt.
• Klassifizierung auf Feldebene; Maskierung, wo möglich.
• Aufbewahrung von Prompts und Ausgaben ist definiert und mit dem Datenschutz abgestimmt.
• Verarbeitungsstandorte sind im Vertrag aufgeführt.

Gate 3. Können Sie belegen, dass der Agent funktioniert und nach Modelländerungen weiter funktioniert?

Was die Quellen erwarten. FSB-Praxis 9 (S. 43): "Financial institutions evaluate the performance of AI use cases proportionately to their materiality and risk, including through performance assessments, testing and ongoing monitoring." Praxis 8 zur Erklärbarkeit (S. 38): "If appropriate and feasible, financial institutions adopt more explainable AI or consider compensating controls."

Die BaFin ist am konkretesten (S. 14, unverbindlich): "Financial entities are required to develop, document and implement tests. The level of testing must be commensurate to the criticality of the business procedures and ICT assets concerned." Sie ergänzt: "Since generative AI is suitable for general purposes, testing is more difficult than with internally developed software that has been designed for a specific application." Auf S. 15 nennt sie ein Risiko, das Agentenprogramme oft übersehen: "Another challenge for testing arises from unannounced model changes where an AI model obtained from third parties is used." Je nach Kritikalität nennt sie Adversarial Testing, adversariale Penetrationstests und "stress-testing the performance of AI systems, e.g. with significantly modified data distributions or in overload scenarios". Die FINMA-Aufsichtsmitteilung 08/2024 geht in dieselbe Richtung (S. 5 bis 6): Sie prüfte, ob Institute Tests einplanen, "which include checks for accuracy, robustness and stability and, if necessary, bias", mit im Voraus definierten Leistungskennzahlen; Fussnote 9 sagt, je wesentlicher und komplexer die Anwendung, desto wichtiger sei die Beurteilung, ob sie funktioniert, "before productive use, in the event of changes and ... on an ongoing basis", und die Prüfung von Rückfallmechanismen. Auf S. 6 nennt sie ausserdem die Überwachung von Änderungen der Eingabedaten ("data drift") und die Analyse von Fällen, in denen Nutzer das Ergebnis ignorierten oder änderten. Zurück zur BaFin: Auf S. 13 brauchen Änderungen "an independent review, documented testing and specifying fall-back procedures", dazu "Systematic archiving of all model versions and parameters".

Für AML- und KYC-Agenten hat die EU-Behörde AMLA am 3. Juni 2026 Entwurfsleitlinien zur laufenden Überwachung zur Konsultation veröffentlicht (Konsultation bis 3. September 2026; laut AMLA werden die endgültigen Leitlinien "will be issued in Q4 2026"). Der Entwurf sagt, Werkzeuge sollen "maintain the expected performance over time, including through appropriate monitoring and, where relevant, the identification of material performance degradation or drift" (Rz. 95), und dass der Einsatz solcher Werkzeuge "should not, in itself, be considered an indicator of effectiveness" (Rz. 93). Es ist ein Entwurf und kann sich ändern.

Hinweis USA. SR 26-2 der Federal Reserve (17. April 2026), das SR 11-7 ersetzt, hält in Fussnote 3 fest: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. Nonetheless, a banking organization's risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document." Die Grundsätze gelten für traditionelle statistische und nicht-generative, nicht-agentische Modelle. Eine US-Bank, die Agenten einsetzt, wendet dieselbe Validierungsdisziplin daher aus eigener Entscheidung im Rahmen der allgemeinen Governance an, nicht weil SR 26-2 Agenten abdeckt.

Nachweis, den eine Bank braucht. Ein Golden-Test-Set mit Bestehensschwellen pro Aufgabe; Red-Team-Ergebnisse; ein Regressionslauf bei jeder Änderung von Modell, Prompt oder Werkzeug; ein dokumentierter Rückfall; und eine namentlich benannte Person, die die Freigabe unterzeichnet.

Typischer Fehler. Der Pilot wird auf Demofällen und einer vom Projektteam geprüften Stichprobe abgenommen; der Anbieter tauscht die Modellversion aus, und niemand wiederholt die Tests.

Checkliste

• Testset mit expliziten Bestehensschwellen, verantwortet von jemandem ausserhalb des Build-Teams.
• Adversariale und Stresstests durchgeführt und dokumentiert.
• Automatische Wiederholung bei jeder Änderung von Modell, Prompt oder Werkzeug; Modellversionen fixiert und archiviert.
• Rückfallverfahren getestet.

Gate 4. Wer kann den Agenten stoppen oder übersteuern, und was darf er allein tun?

Was die Quellen erwarten. FSB-Praxis 10 (S. 49): "Financial institutions implement appropriate and effective human oversight relevant to the materiality, risk, autonomy, complexity and explainability of different AI use cases." Praxis 2 (S. 22) verlangt von Instituten, "define clear roles and responsibilities, and maintain an appropriate governance framework to enable responsible AI adoption." Beachten Sie die Skalierung: Die Aufsicht ist verhältnismässig, nicht ein Mensch bei jeder Aktion.

Die BaFin (S. 10) erwartet, dass Verantwortlichkeiten "defined within the organisation ... e.g. for the use of AI-generated results in decision-making processes" sind, wobei IKT-Risikomanagement, Kontroll- und Revisionsfunktionen eingebunden sind, "depending on the criticality of the AI system, while maintaining independence and avoiding conflicts of interest." Die Beobachtungen der FINMA weisen in dieselbe Richtung: Sie prüfte, ob die Governance "the definition of responsibilities and accountabilities for the development, implementation, monitoring and use of AI" umfasst (S. 4), und sie "did not observe a clear distinction between the development of AI applications and the independent review in all cases"; nur "a few supervised institutions" führen eine unabhängige Prüfung des gesamten Modellentwicklungsprozesses "by qualified personnel" durch (S. 7).

AML ist das schärfste Beispiel. Der AMLA-Entwurf (Rz. 78 bis 79, S. 39) würde das automatische Schliessen nur für Fälle zulassen, die nach automatisierter Analyse "do not indicate suspicious or unusual transactions", nicht "where there are indicators of heightened risk", und "subject to effective human oversight, including periodic validation through sampling". Auch hier gilt der Entwurfsstatus. Siehe AI agents for AML transaction monitoring (EN) und die deutsche Seite KI-Agenten für AML und Transaktionsüberwachung.

Die Bestimmung des AI Act zur menschlichen Aufsicht bei Hochrisiko-Systemen, Art. 14, verlangt, dass solche Systeme "can be effectively overseen by natural persons during the period in which they are in use" (Art. 14 Abs. 1), mit Aufsichtsmassnahmen "commensurate with the risks, level of autonomy and context of use" (Art. 14 Abs. 3), und dass die Aufsichtspersonen sich der "automation bias" bewusst bleiben können (Art. 14 Abs. 4 Buchstabe b). Sie gilt nur, wenn das System im Anwendungsbereich liegt, was zu Gate 1 zurückführt.

Nachweis, den eine Bank braucht. Eine Autonomiematrix pro Aktionstyp (lesen, entwerfen, mit Freigabe handeln, allein handeln); Freigabeschwellen; eine namentlich benannte verantwortliche Person; Nachweis, dass Übersteuerungen funktionieren (ein Notaus, der tatsächlich getestet wurde); ein Stichprobenplan für automatisch geschlossene oder automatisch genehmigte Fälle.

Typischer Fehler. "Human in the loop" besteht nur auf dem Papier, weil der Prüfer nur die Zusammenfassung des Agenten sieht und die Freigabe zum Durchwinken wird; oder der Agent hält Schreibrechte, die er nie braucht.

Checkliste

• Autonomiestufe pro Aktion definiert; Berechtigungen nach dem Prinzip der minimalen Rechte.
• Der Prüfer sieht die Quellbelege, nicht nur die Schlussfolgerung des Agenten.
• Notaus und Rollback getestet.
• Stichproben- und Eskalationsregeln sind schriftlich festgehalten.

Gate 5. Können Sie jede Entscheidung rekonstruieren und Drift früh erkennen?

Was die Quellen erwarten. FSB-Praxis 9 (S. 43) umfasst "ongoing monitoring", und Praxis 3 (S. 24) verlangt "documentation of AI use". Die BaFin (S. 17, unverbindlich) hält fest: "Continuous monitoring of AI systems has proven useful for the early detection of anomalies (Article 10 of DORA)" und "entities are encouraged to ensure comprehensive, risk-based logging of AI decisions, model versions and training data (to the extent permitted by data protection law), depending on the criticality and area of application of the relevant AI systems." Auf S. 16 verweist sie auf die Dokumentation von Betriebsaktivitäten wie "log files from model inference processes". KI-Systeme sollen ausserdem in Notfallplänen berücksichtigt werden, die "at least annually" getestet werden (S. 17). Der AMLA-Entwurf ergänzt wiederum Drift und "material performance degradation". Die FINMA stellt fest, dass Ergebnisse "often cannot be understood, explained or reproduced and therefore cannot be critically assessed" (S. 6), und erwartet bei wesentlichen Anwendungen eine Dokumentation von Zweck, Daten, Leistungskennzahlen, Einschränkungen, Tests, Kontrollen und Rückfalllösungen (S. 6).

Beachten Sie die Wortwahl: Die BaFin sagt "encouraged", nicht "required", und die Protokollierung ist durch das Datenschutzrecht begrenzt.

Nachweis, den eine Bank braucht. Ein Protokoll pro Entscheidung (Eingabe, abgerufene Quellen, Werkzeugaufrufe, Modell- und Prompt-Version, Ausgabe, menschliche Aktion); eine mit dem Datenschutz abgestimmte Aufbewahrungsdauer; Dashboards für Drift und Qualität mit Alarmschwellen; ein Incident-Runbook und eine namentlich benannte Bereitschaftsperson.

Typischer Fehler. Die Protokolle erfassen die endgültige Antwort, aber nicht den abgerufenen Kontext oder die Werkzeugaufrufe, sodass eine bestrittene Entscheidung nicht wiedergegeben werden kann; oder die Protokolle enthalten Personendaten ohne Aufbewahrungsregel.

Zum Design von Audit-Trails im KYC siehe KYC AI audit trail and explainability (EN).

Checkliste

• Eine Entscheidung lässt sich aus den Protokollen von Anfang bis Ende wiedergeben.
• Aufbewahrung und Zugriff auf Protokolle sind mit dem Datenschutz abgestimmt.
• Drift- und Qualitätsalarme mit Schwellen und verantwortlicher Person.
• Incident-Runbook getestet, einschliesslich Ausfall des Modellanbieters.

Gate 6. Was passiert, wenn der Modellanbieter wechselt, ausfällt oder geht?

Was die Quellen erwarten. FSB-Praxis 12 (S. 60): "Financial institutions appropriately manage risks from third-party AI dependencies with a focus on performance, transparency, data quality, supply chain and concentration risks, and business continuity." Praxis 11 (S. 55) ergänzt, wo angemessen, "incorporating AI cyber and ICT risk scenarios into tests and exercises".

Die BaFin (S. 19, unverbindlich, unter Verweis auf DORA) ist beim Ausstieg direkt: "Entities are encouraged to ensure that models, training data and configuration scripts can be exported seamlessly to ensure portability to another environment." Sie warnt, dass "proprietary cloud functions (e.g. specialised AI offerings) can significantly increase the costs, duration and technical expertise required for a change (known as 'vendor lock-in')." Sie sagt ausserdem, Prüf- und Kontrollrechte "should also apply without exception to subcontracts that support critical or important functions", und erwartet einen Überblick über die Kette der Unterauftragnehmer. Vor Vertragsabschluss (S. 18) soll die Sorgfaltsprüfung Änderungen am KI-System berücksichtigen, "even if all changes to the model are made by the service provider".

DORA gilt seit dem 17. Januar 2025 (Art. 64). Art. 28 Abs. 3 verlangt ein Informationsregister zu allen vertraglichen Vereinbarungen über IKT-Dienste; für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen, verlangt Art. 28 Abs. 8 Ausstiegsstrategien, "comprehensive, documented" und "sufficiently tested and reviewed periodically"; und Art. 30 Abs. 2 Buchstabe b verlangt, dass jeder IKT-Dienstleistungsvertrag die Standorte (Regionen oder Länder) festlegt, an denen Dienste erbracht und Daten verarbeitet werden, einschliesslich Speicherung, mit Vorankündigung von Änderungen. Das Finanzunternehmen muss "at all times, remain fully responsible" für die Einhaltung sein (Art. 28 Abs. 1 Buchstabe a). Diese Pflichten liegen bei der Bank und erreichen einen Anbieter über den Vertrag; praktisch stellt sich also die Frage, was eine Bank von ihrem KI-Anbieter verlangt. Die FINMA nennt als Risiko zudem "a growing dependence on third parties such as providers of hardware solutions, models or cloud services in an increasingly concentrated market" (S. 3) und prüfte beim Outsourcing, ob Institute "additional tests, controls and contractual clauses governing responsibilities and liability issues" umgesetzt hatten (S. 4).

Nachweis, den eine Bank braucht. Ein Eintrag im Informationsregister für den Modellanbieter und die Cloud; eine Liste der Unterauftragnehmer; die Klausel zu Prüfrechten; ein getesteter Ausstiegsplan (ein zweites Modell oder ein On-Premises-Rückfall, mit portablen Prompts, Evaluierungen und Konfigurationen); und eine Konzentrationssicht über die KI-Dienste der Bank.

Typischer Fehler. Agentenlogik, Prompts und Evaluierungen sind auf proprietäre Funktionen eines Anbieters geschrieben, sodass ein Ausstieg einen Neubau bedeutet; die Konzentration auf eine Cloud wird erstmals bei der Vertragsverlängerung besprochen.

Checkliste

• Anbieter und Unterauftragsverarbeiter sind im Register erfasst.
• Prüf- und Ausstiegsklauseln im Vertrag.
• Prompts, Evaluierungen und Werkzeugdefinitionen bleiben portabel und im Repository der Bank.
• Ausstieg oder Rückfall wurde mindestens einmal auf einer Nicht-Produktionskopie geübt.

Wie greifen die sechs Gates ineinander?

Zum Vergleichen wischen →

Die Gates bauen aufeinander auf: Eine Lücke in Gate 1 (ein nicht aufgeführtes Werkzeug) zeigt sich meist als Fehler in den Gates 4 und 5.

So unterstützt S-PRO Sie dabei

S-PRO ist ein Schweizer, international tätiges Unternehmen mit Sitz in Zürich (Löwenstrasse 45, 8001 Zürich), 2014 gegründet, mit 250+ Ingenieuren, R&D-Zentren in Zürich und Łódź sowie den Zertifizierungen ISO 27001 und ISO 27701. S-PRO ist zertifizierter Partner im Claude Partner Network.

Wir helfen Banken und Vermögensverwaltern, KI-Agenten vom Pilot in die Produktion zu führen: Wir bauen den Agenten so, dass die Nachweise für jedes Gate (Registerangaben, Testsets, Freigabeabläufe, Entscheidungsprotokolle, portable Konfigurationen) im Rahmen der Lieferung entstehen und nicht nachträglich rekonstruiert werden. Siehe AI proof of concept to production for banks (EN) und AI agent development (EN), oder sprechen Sie mit uns über einen konkreten Agenten, den Sie durch die Prüfung bringen wollen. Kostenloses Erstgespräch buchen (45 Min.)

Kontakt: S-PRO, Löwenstrasse 45, 8001 Zürich, +41 41 539 15 83.

S-PRO erbringt keine Rechts- oder Regulierungsberatung. Compliance-Entscheidungen bleiben beim Institut.

Quellen

• FSB, Sound practices for responsible adoption of artificial intelligence (AI), Schlussbericht, 15. Oktober 2026 (EN): fsb.org (PDF: https://www.fsb.org/uploads/P151026-1.pdf; Seitenzahlen in diesem Artikel sind die gedruckten Berichtsseiten, PDF-Seite = gedruckte Seite + 4)
• BaFin, Orientierungshilfe zu IKT-Risiken beim Einsatz von KI (23. Januar 2026), englische Fassung: bafin.de
• FINMA, Medienmitteilung zur Aufsichtsmitteilung 08/2024 (18. Dezember 2024): finma.ch
• FINMA-Aufsichtsmitteilung 08/2024, "Governance and risk management when using artificial intelligence", 18. Dezember 2024 (PDF, 7 S.): finma.ch
• Federal Reserve, SR 26-2 (17. April 2026): federalreserve.gov
• EU AI Act, Anhang III (AI Act Service Desk): ai-act-service-desk.ec.europa.eu
• DORA, Verordnung (EU) 2022/2554: eur-lex.europa.eu
• EU AI Act, Verordnung (EU) 2024/1689, Art. 14 und Anhang III: eur-lex.europa.eu
• Verordnung (EU) 2026/1744 (Digital Omnibus on AI, ändert die Fristen des AI Act), ABl. L, 24.7.2026: eur-lex.europa.eu
• AMLA, Entwurf der Leitlinien zur laufenden Überwachung einer Geschäftsbeziehung nach Art. 26 Abs. 5 der Verordnung (EU) 2024/1624 (Konsultation 3. Juni bis 3. September 2026): amla.europa.eu