DORA gilt seit dem 17. Januar 2025 vollständig. Der EU AI Act hat seine Pflichten für GPAI-Modelle am 2. August 2025 in Kraft gesetzt. Finanzinstitute, die Claude-Modelle von Anthropic für LLM-Anwendungen im Finanzsektor einsetzen, stehen unmittelbar unter Beobachtung ihrer eigenen Risikoverantwortlichen. Die Engineering-Entscheidungen von heute bestimmen, ob Ihre Systeme die kommenden Aufsichtsprüfungen bestehen – genau deshalb ist die DORA-Konformität von Claude AI zum festen Punkt auf der Agenda von Compliance-Teams geworden.
Aufsichtsbehörden wie EBA, ESMA und FCA prüfen solche Deployments inzwischen aktiv. Die Vorgaben treffen unmittelbar Kreditinstitute, Zahlungsdienstleister, Wertpapierfirmen und Versicherungsunternehmen. Systeme für automatisiertes Credit Scoring und Risikoprüfung, die nach Anhang III als Hochrisiko-KI-Systeme gelten, müssen bis zum 2. August 2026 konform sein.
In unserer Arbeit mit Fintech-Teams, die DORA umsetzen, gehen wir diese Sicherheitsgrenzen systematisch durch. Dieser technische Bauplan verbindet konkrete Regulierungsartikel mit den Infrastrukturmustern, die für den Produktivbetrieb von Claude AI im Finanzsektor tatsächlich nötig sind.
Hinweis: Dieser Beitrag dient ausschließlich der Information und stellt keine Rechts-, Finanz- oder Compliance-Beratung dar. Welche Pflichten konkret gelten, hängt von Ihrer Unternehmensform, Ihrer Jurisdiktion und Ihrem Anwendungsfall ab. Ziehen Sie qualifizierte Rechtsberatung und Ihr Compliance-Team hinzu, bevor Sie regulatorische Entscheidungen treffen.
- Die Konzentrationsregeln aus DORA Artikel 29 verlangen von Engineering-Teams Failover-Strecken über mehrere Regionen für alle Interaktionen mit der Claude-API.
- Finanzanwendungen, die Kreditwürdigkeit oder Versicherungsprämien bewerten, lösen die Hochrisiko-Kriterien aus Anhang III aus – die Konformitätsprüfung ist damit bis zum 2. August 2026 verpflichtend.
- Produktivsysteme brauchen zustandsbehaftete Prompt-Proxys, lokale Validierungsschichten und unveränderliche Aktivitätsprotokolle, um die Nachweispflichten aus Artikel 12 zu erfüllen – das Rückgrat jedes belastbaren LLM-Audit-Trails im Finanzsektor.
- Anthropic betreibt eine ISO-27001-zertifizierte Infrastruktur, doch Artikel 26 des AI Act legt die Durchsetzung der Datenresidenz im Betrieb vollständig in Ihre Hand – im Rahmen der Beziehung zu Anthropic als IKT-Drittdienstleister.
- Ob Sie künftige Prüfungen bestehen, hängt davon ab, ob deterministische Validierungs-Queues vor dem Go-live direkt in Ihre Modell-Routing-Architektur eingebaut sind.
Warum DORA und der EU AI Act den Einsatz von Claude AI 2026 zur Compliance-Priorität machen
In unserer Arbeit mit Fintech-Teams sehen wir viele Entwickler, die Claude-Modelle in abgeschotteten Entwicklungs-Sandboxes testen. Der Schritt in die Produktion löst mehrere Compliance-Pflichten gleichzeitig aus – dieselben Pflichten, die den Einsatz von KI in regulierten Finanzprozessen grundlegend von einem Consumer-Chatbot unterscheiden. Unter der Verordnung (EU) 2022/2554 (DORA) stehen Kreditinstitute, Zahlungsdienstleister, Wertpapierfirmen, Versicherer und unter MiCA zugelassene Kryptowerte-Dienstleister unmittelbar unter Infrastrukturprüfung.
Die Europäische Kommission und das EU-KI-Büro setzen unter der Verordnung (EU) 2024/1689 (EU AI Act) klare systemische Grenzen. Für grenzüberschreitende Tätigkeiten gelten in Nachbarjurisdiktionen vergleichbar strenge Leitlinien. Die FCA setzt Erwartungen an operationale Resilienz durch, die den kontinentalen Regeln sehr nahekommen und Teil der breiteren Aufsicht über KI-Betriebsstabilität im Finanzsektor sind. Die gemeinsame Aufsicht von EBA, ESMA und EIOPA stellt klar: Für Fehler externer Modelle haftet die Finanzplattform vollständig selbst.
Eine unzureichend gesicherte Deployment-Architektur bringt erhebliche Bußgelder mit sich – genau deshalb lässt sich IKT-Risikomanagement nach DORA nicht als Papierübung abhandeln. Bei DORA-Verstößen können Aufsichtsbehörden Sanktionen nach nationalen Bußgeldregimen verhängen; Artikel 50 verlangt, dass diese „wirksam, verhältnismäßig und abschreckend“ sind. Verstöße gegen die Hochrisiko-Bestimmungen des EU AI Act führen zu Geldbußen von bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes.
| Datum | Regulierung | Was in Kraft tritt |
|---|---|---|
| 17. Januar 2025 | DORA | Vollständige Anwendung – IKT-Risikomanagement, Drittparteien-Aufsicht, Meldung von Vorfällen |
| 2. August 2025 | EU AI Act | Pflichten für GPAI-Modelle (Anthropic) + Anforderungen an die KI-Policy der Betreiber |
| 2. August 2026 | EU AI Act | Hochrisiko-KI-Systeme nach Anhang III – vollständige Konformitätsbewertung erforderlich |
| 2. August 2027 | EU AI Act | KI-Systeme, die in regulierte Produkte eingebettet sind |
Sie wollen sicher sein, dass Ihr Setup von Claude AI im Finanzsektor keine Compliance-Probleme auslöst? Lassen Sie uns Ihre Produktivarchitektur gemeinsam durchgehen.
Wie DORA Claude AI einordnet und was das für Ihr IKT-Risikoframework bedeutet
DORA Artikel 8 stuft Softwaresysteme, große Sprachmodelle eingeschlossen, als IKT-Assets ein. Nach Artikel 3(19) gilt Anthropic damit als IKT-Drittdienstleister. In unserer Arbeit mit Fintech-Teams zeigt sich: Der Einsatz von Claude verpflichtet Unternehmen zu formalen Risikobewertungen nach Artikel 28 der Verordnung (EU) 2022/2554 – die Grundlage jedes funktionierenden IKT-Risikomanagements nach DORA.
Damit Ihre Deployment-Architektur und Ihr Governance-Rahmen europäische Aufsichtsbehörden überzeugen, müssen sie folgende Punkte abdecken:
Vertragliche Pflichten (Art. 30)
Ihre Dienstleistungsverträge müssen SLAs, Speicherorte der Daten und überprüfbare technische Exit-Strategien ausdrücklich festlegen.
Sicherheit und Prüfrechte (Art. 17)
Verträge müssen strenge Sicherheitsstandards, kooperative Auditrechte und klare Kündigungsauslöser regeln.
Kontinuitätstests (Art. 11)
Engineering-Teams müssen Betriebskontinuitätstests durchführen und nachweisen, dass Finanzprozesse einen Ausfall der Anthropic-API überstehen.
Konzentrationsrisiko (Art. 32)
Risikoteams müssen systemische IKT-Konzentrationsrisiken dokumentieren und abmildern, wenn Claude Ihr einziger Modellanbieter ist.
| DORA-Artikel | Anforderung |
|---|---|
| Art. 3(19) | Definition des IKT-Drittdienstleisters – Anthropic fällt darunter |
| Art. 8 | Identifikation von IKT-Assets – LLMs sind IKT-Assets |
| Art. 11 | IKT-Kontinuität – Claude-abhängige Prozesse auf Ausfallszenarien testen |
| Art. 17 | Vertragliche Anforderungen an IKT-Vereinbarungen |
| Art. 28 | Pflichten zum IKT-Drittparteien-Risikomanagement |
| Art. 30 | Zentrale Vertragsklauseln: SLA, Auditrechte, Exit-Plan |
| Art. 32 | Bewertung des IKT-Konzentrationsrisikos |
Risikoklassifizierung nach dem EU AI Act: Ist Ihr Claude-Anwendungsfall hochriskant?
Der AI Act staffelt die Pflichten über vier Stufen: verboten, hochriskant, begrenztes Risiko und minimales Risiko. Claude selbst ist ein GPAI-Modell nach Artikel 51, wodurch Artikel 53 die Dokumentations- und Systemevaluierungspflichten vorgelagert bei Anthropic verortet – die Anwendungssicherheitsschicht verantwortet Ihr Team. Das ist die zentrale Unterscheidung, die jedes Programm zu DORA- und AI-Act-Konformität intern klar kommunizieren muss: zwei Regulatoren, zwei Rollen, eine gemeinsame Architektur.
Welche nachgelagerten Pflichten greifen, hängt vollständig von Ihrem konkreten Anwendungsfall nach Anhang III ab. Prozesse, die als Hochrisiko-KI-System gelten, lösen die Artikel 9 bis 16 aus und verlangen umfassende Risikoframeworks, Prüf-Queues mit menschlicher Aufsicht und Data-Governance-Protokolle. Verstöße können Ihr Unternehmen bis zu 35 Millionen Euro oder 7 Prozent des weltweiten Jahresumsatzes kosten.
| Anwendungsfall | Risikostufe | Auslöser im EU AI Act | Zentrale Pflicht |
|---|---|---|---|
| Credit Scoring / Kreditwürdigkeitsprüfung | HOCHRISIKO | Anhang III, Punkt 5(b) | Konformitätsbewertung + Art. 9, 14 |
| Versicherungstechnische Risikobewertung | HOCHRISIKO | Anhang III, Punkt 5(c) | Konformitätsbewertung + Art. 9, 14 |
| Betrugserkennung (nachteilige Einzelfallentscheidungen) | HOCHRISIKO (prüfen) | Prüfung nach Anhang III erforderlich | Risikomanagementsystem (Art. 9) |
| Kundenservice-Chatbot (KI-generiert) | Begrenztes Risiko | Art. 52 | Transparenzhinweis für Nutzer |
| Interne Dokumentenverarbeitung / Zusammenfassung | Minimales Risiko | — | nur Best Practice |
| Codegenerierung / Entwicklerwerkzeuge | Minimales Risiko | — | nur Best Practice |
Unsicher, ob Ihr Claude-Deployment in den Hochrisikobereich fällt? Lassen Sie uns Ihr Setup jetzt prüfen, damit Sie sich später keine Sorgen um die Aufsicht machen müssen.
Was Ihre Claude-Architektur für DORA- und EU-AI-Act-Konformität enthalten muss
Der Weg von der Sandbox in die Produktion bedeutet, Rechtsklauseln in konkrete Systemkomponenten zu übersetzen. Unsere Engineering-Teams entwerfen Finanzarchitekturen mit expliziten Isolationsschichten – im Rahmen unserer KI-Integration. Diese trennen Ihre Geschäftslogik von der Modellschicht. Indem Sie technische Kontrollen direkt auf DORA- und AI-Act-Vorgaben abbilden, entsteht eine Infrastruktur, die in kommenden Prüfungen verteidigungsfähig ist.
1. Unveränderlicher Audit Trail und Entscheidungsprotokollierung
Erfassen Sie pseudonymisierte Eingaben, Prompt-Strings, Ausgaben und Zeitstempel an Ihrem API-Gateway, bevor die Anfrage an Claude geht. Leiten Sie diese Daten in WORM-Ziele (Write Once, Read Many) wie AWS S3 Object Lock oder Azure Immutable Blob Storage. Das erfüllt DORA Artikel 10 und EU AI Act Artikel 12 – und ist die praktische Definition eines LLM-Audit-Trails, den Prüfer im Finanzsektor tatsächlich akzeptieren. Es erfüllt zugleich die Aufbewahrungserwartungen der EBA und die verlängerte Aufbewahrungsfrist, die für Hochrisikosysteme empfohlen wird.
2. Erklärbarkeitsschicht (XAI)
Aus Sicht des Betreibers ist Claude eine Blackbox. Sie müssen eine eigenständige Erklärbarkeits-Pipeline aufbauen, um EU AI Act Artikel 13 und die EBA-Leitlinien zum maschinellen Lernen zu erfüllen. Genau hier werden die Anforderungen an KI-Erklärbarkeit in der Bankenregulierung erfüllt – nicht durch das Modell, sondern durch die Schicht, die Sie darum herum bauen. In unserer Umsetzung laufen Modellantworten durch Parsing-Proxys, die strukturierte JSON-Begründungen anfordern oder Metriken im Stil von SHAP und LIME berechnen. Halten Sie diese Telemetrie getrennt von Ihren Haupt-Audit-Logs, um die Trennung der Datenpipelines klar zu belegen.
3. Human-in-the-Loop-Kontrollen (HITL)
Um EU AI Act Artikel 14 und die Governance-Erwartungen aus DORA zu erfüllen, müssen Sie Eingriffs-Queues für Menschen fest in Ihre Prozesse für Kreditvergabe und Betrugswarnungen einbauen. Echte HITL-Konformität bedeutet einen bewusst gestalteten Prüfpunkt, nicht ein optionales Dashboard, das niemand öffnet. Gibt Claude eine Ausgabe mit niedriger Konfidenz zurück, muss die Transaktion in ein manuelles Prüf-Dashboard laufen. Protokollieren Sie jedes menschliche Override ausdrücklich und testen Sie diese Validierungsmechanismen regelmäßig, um die Wirksamkeit der Aufsicht zu belegen.
4. IKT-Drittparteien-Risikomanagement für Anthropic
Erfassen Sie Anthropic gemäß DORA Artikel 28.3 in Ihrem IKT-Drittparteienregister. Prüfen Sie im Einkauf die Zertifizierungen SOC 2 Type II und ISO 27001, setzen Sie die vertraglichen Pflichten aus Artikel 30 aber selbst durch. Ihre Architektur braucht eine aktive Exit-Strategie oder einen Backup-Anbieter, um einen API-Ausfall zu überstehen. Dokumentieren Sie diese Wechselpfade zwischen Modellen, um Konzentrationsrisiken nach Artikel 32 abzumildern.
5. Kontrollen für Datenresidenz und Datensouveränität
Die Standard-API von Anthropic leitet Payloads international. Um den Erwartungen von BaFin, CNIL und FCA an Datensouveränität zu genügen, müssen Sie Ihre Datenflüsse explizit kartieren. Betreiben Sie Claude über regionale Infrastruktur wie AWS Bedrock (EU-West) oder die EU-Datenresidenz-Optionen von Azure AI Studio. Entfernen oder pseudonymisieren Sie personenbezogene Daten vor der Übertragung und schließen Sie Standardvertragsklauseln (SCC) ab, um Artikel 46 DSGVO zu erfüllen.
6. Erkennung und Behandlung von IKT-Vorfällen
Integrieren Sie Latenzspitzen der Claude-API, anomale Payloads und unerwartete Ausgaben in Ihr zentrales SIEM-Monitoring. DORA Artikel 19 schreibt strenge Meldefristen für schwerwiegende Vorfälle vor. Binden Sie die Statusseite von Anthropic an Ihr Alerting an und erstellen Sie eigene Runbooks für unerwarteten Modell-Drift – ein Kernstück der KI-Betriebsstabilität im Finanzsektor, das die Aufsicht getestet und nicht bloß dokumentiert sehen will.
7. Framework für Modellrisikomanagement (MRM)
Behandeln Sie Claude als formales Modell in Ihrer MRM-Policy, im Einklang mit SR 11-7 der Federal Reserve und EU AI Act Artikel 9. Legen Sie die Produktionsversion des Modells ausdrücklich fest, um unerwarteten Drift zu verhindern. Dokumentieren Sie Angriffsvektoren für Prompt Injection, Zielwerte für Halluzinationsraten und Ausführungsparameter. Aktualisieren Sie Ihre Modellvalidierungsunterlagen jährlich anhand der neuen Model Cards von Anthropic.
Eine prüfungsfähige Deployment-Architektur für Claude AI im regulierten Finanzsektor
Der Einsatz von Claude in einem regulierten Prozess verlangt eine deterministische Architektur. Das ist das Referenzmuster für Teams, die Claude AI im Finanzsektor auf eine Prüfung hin bauen, nicht auf eine Demo. Die folgenden Schichten beschreiben die verbindlichen Softwaregrenzen, Datenprüfpunkte und Validierungs-Gates Ihres Produktivstacks – dieselbe Referenzarchitektur, die unser Team für LLM-Entwicklung beim Scoping eines regulierten Deployments verwendet.
1. API-Gateway-Schicht
Diese Sicherheitsgrenze erzwingt Authentifizierung und Autorisierung, bevor irgendein Payload weitergeleitet wird. Sie fängt eingehenden Text ab, um personenbezogene Daten zu entfernen oder zu pseudonymisieren, und erfüllt damit die Datenminimierung. Anschließend kopiert das Gateway die Metadaten der Anfrage direkt in WORM-Speicherziele.
2. Orchestrierungsschicht
Diese Schicht steuert Modell-Routing, Prompt-Aufbau und strukturelle Vorgaben. Sie hält Ihre System-Prompts in einem Versionskontroll-Repository fest. Die Engine erzwingt strikte JSON-Schemata und zwingt Claude damit zu Antworten mit explizitem Feld für Entscheidung und Begründung.
3. Der Claude-API-Endpunkt
Legen Sie die Modellversion fest, um unerwartete Verhaltensänderungen zu verhindern. Leiten Sie diese API-Aufrufe ausschließlich über regionale Infrastruktur wie AWS Bedrock eu-west. Halten Sie unterzeichnete Standardvertragsklauseln (SCC) vor, um die Rechtsgrundlage der Datenverarbeitung zu dokumentieren.
4. Schicht zur Antwortverarbeitung
Diese Schicht fängt die Modellantwort ab, bevor sie den Nutzer erreicht. Sie streamt den Rohtext unmittelbar in Ihren WORM-Speicher. Die Komponente extrahiert die Begründungs-Tokens für Ihre Erklärbarkeits-Pipeline und berechnet einen numerischen Konfidenzwert.
5. Prüf-Queue mit menschlicher Kontrolle
Ausgaben mit niedriger Konfidenz laufen direkt in ein manuelles Prüf-Dashboard statt automatisch ausgeführt zu werden. Menschliche Prüfer sehen Prompt-Eingabe und Modellbegründung nebeneinander. Die Oberfläche protokolliert jedes manuelle Override – wer die Transaktion freigegeben hat und warum.
6. Entscheidungsausgabe und Prüfunterlagen
Die geprüfte Entscheidung und die menschenlesbare Begründung gehen direkt in Ihr zentrales Finanzbuch. Das System bewahrt dieses Bündel fünf bis zehn Jahre im WORM-Speicher auf. Monitoring-Agenten streamen Anomalie-Telemetrie an Ihr SIEM, um unerwartete Latenz oder Halluzinationen zu erkennen.
[Nutzer / internes System]
↓
[API-Gateway-Schicht]
— Authentifizierung & Autorisierung
— Entfernen / Pseudonymisieren personenbezogener Daten (vor dem Versand an Claude)
— Anfrage-Logging: Zeitstempel, Nutzer-ID, Prompt-Version (WORM)
↓
[Orchestrierungsschicht]
— Versionskontrolle der Prompts (fixiertes Template + Modellversion)
— HITL-Auslöser: Konfidenz < Schwelle → in die menschliche Prüf-Queue
— Erzwungene Ausgabestruktur: JSON mit Feldern für Entscheidung + Begründung
↓
[Claude-API — Anthropic]
— Modellversion fixiert
— Rechtsgrundlage für EU-Datentransfer dokumentiert (SCC oder AWS Bedrock eu-west)
↓
[Schicht zur Antwortverarbeitung]
— Ausgabe-Logging (WORM, unveränderlich)
— XAI-Extraktion der Begründung
— Konfidenzbewertung
↓
[HITL-Prüf-Queue] ← ausgelöst bei Konfidenz < Schwelle
— Oberfläche für menschliche Prüfer
— Override-Logging (wer / wann / Entscheidung)
↓
[Entscheidungsausgabe + Prüfunterlage]
— Endgültige Entscheidung + Begründung (menschenlesbar)
— Unveränderliches Audit-Log (WORM, 5–10 Jahre Aufbewahrung)
— Monitoring & Alerting (Anomalieerkennung nach DORA Art. 17)
Dieses Schema ist illustrativ. Ihre konkrete Umsetzung hängt von Ihrer Risikoklassifizierung nach Anhang III des EU AI Act und Ihrem IKT-Risikoframework nach DORA ab.
«Unternehmen verwechseln häufig die Compliance von Anthropic mit ihrer eigenen. Die Aufsicht prüft Ihre individuelle Architektur, nicht nur die Cloud des Anbieters. Unser Team für Entwicklung generativer KI löst diese Lücke mit geprüften Blaupausen: lokales WORM-Logging, Proxys zur Prompt-Validierung und verbindliche Prüf-Queues. Damit ist Ihr technischer Stack darauf ausgelegt, strenge aufsichtsrechtliche Prüfungen unmittelbar zu bestehen.»
— Anastasia Timoshenko, Senior IT Consultant bei Elinext
Pre-Production-Checkliste für Claude-Deployments unter DORA und EU AI Act
Der Weg in den Live-Betrieb verlangt eine formale Prüfung über mehrere Rahmenwerke hinweg. Diese Checkliste hilft Engineering-Teams, die infrastrukturelle Reife ihres LLM-Einsatzes im Finanzsektor zu prüfen, bevor sie die Anwendung zur endgültigen Compliance-Freigabe einreichen.
DORA: Checkliste zur Betriebsreife
Unter der Verordnung (EU) 2022/2554 muss Ihr Team Anthropic als kritischen digitalen Partner innerhalb Ihres IKT-Risikomanagements behandeln. Dieser Abschnitt prüft, ob Dateninfrastruktur und Notfallpläne die strengen Vorgaben zur Drittparteien-Aufsicht erfüllen.
- ☐ Anthropic ist im IKT-Drittparteienregister erfasst (DORA Art. 28.3)
- ☐ Vertragsklauseln nach Art. 30 mit Anthropic vereinbart: SLA, Datenstandort, Auditrechte, Exit
- ☐ Bewertung des IKT-Konzentrationsrisikos abgeschlossen (Art. 32)
- ☐ Exit- und Notfallplan dokumentiert für den Fall, dass die Anthropic-API nicht verfügbar ist
- ☐ Claude-Prozess in die Erkennung und Meldung von IKT-Vorfällen eingebunden
- ☐ DORA-Kontinuitätstests umfassen Claude-abhängige Prozesse
EU AI Act: Compliance-Checkliste
Die Verordnung (EU) 2024/1689 stellt technische Designanforderungen nach dem Risiko der Anwendung. Wer KI in regulierten Finanzprozessen einsetzt, braucht diese Prüfsequenz, um sicherzustellen, dass Hochrisiko-Modellpipelines die vorgeschriebenen Schutzmechanismen enthalten.
- ☐ Risikoklassifizierung des Anwendungsfalls abgeschlossen (Prüfung nach Anhang III)
- ☐ Falls hochriskant: Konformitätsbewertung eingeleitet, Registrierung in der EU-Datenbank erfolgt
- ☐ KI-Risikomanagementsystem dokumentiert (Art. 9)
- ☐ Transparenzmaßnahmen für betroffene Personen umgesetzt (Art. 13)
- ☐ HITL-Kontrollen dokumentiert, getestet und protokolliert (Art. 14)
- ☐ Audit-Logging aktiv, WORM, Aufbewahrung ≥ 10 Jahre bei Hochrisikosystemen (Art. 12)
Governance und Datenschutz: allgemeine Checkliste
Grenzüberschreitende Deployments erfordern die Abstimmung lokaler Datenschutzvorgaben mit den technischen Rahmenbedingungen. Diese letzten Punkte prüfen, ob Ihre organisatorischen Schutzmaßnahmen den langfristigen Modellbetrieb tragen.
- ☐ Rechtsgrundlage für DSGVO-Transfers geschaffen: SCC mit Anthropic oder AWS Bedrock EU-Region
- ☐ Modellversion in der Produktion fixiert
- ☐ Freigabe durch Datenschutzbeauftragten und Rechtsabteilung liegt vor
- ☐ Mitarbeitende haben die Schulung zur KI-Policy abgeschlossen
Wichtigste Erkenntnisse
- Hochriskante Claude-Anwendungsfälle wie Credit Scoring müssen bis zum 2. August 2026 vollständig EU-AI-Act-konform sein.
- DORA verlangt, Anthropic als IKT-Drittdienstleister zu behandeln – mit formaler Eintragung im Risikoregister und Failover-Strategien über mehrere Modelle.
- Produktivsysteme brauchen eigenständige Validierungs-Proxys, unveränderliche WORM-Logging-Strecken und fest verdrahtete HITL-Prüf-Queues.
- Anthropic hält Infrastrukturzertifizierungen vor, doch für die Durchsetzung regionaler Datenresidenz ist allein Ihr Unternehmen verantwortlich.
- Sobald Modelle die Entwicklungs-Sandbox verlassen, greift die Compliance-Aufsicht unmittelbar – mit Bußgeldern von bis zu 7 Prozent des weltweiten Umsatzes.
Fazit
Der Einsatz von Claude AI in Finanzprozessen verlangt strikte architektonische Disziplin. Solange der 2. August 2026 als Frist für die Hochrisiko-Rahmenwerke nach Anhang III gilt, entscheidet allein Ihr Produktivsetup über die Konformität. Die regulatorische Haftung lässt sich nicht an Anthropic delegieren: DORA-Konformität von Claude AI ist ein Ergebnis Ihrer Architektur, kein Feature des Modells.
Ihr Engineering-Team muss die unveränderlichen Logging-Speicher, die Proxys zur Prompt-Isolierung und die menschlichen Prüf-Queues selbst bauen. Diese Komponenten jetzt zu errichten – etwa mit Unterstützung durch Chatbot-Entwicklung oder umfassendere Softwareentwicklung für die Finanzbranche – sichert Ihr Deployment und belegt Konformität, bevor die aufsichtsrechtlichen Prüfungen beginnen. Für jedes Team, das Claude AI im Finanzsektor ernsthaft einsetzen will, entscheidet diese Vorarbeit darüber, ob eine Prüfung Routine bleibt oder zu einer aufsichtsrechtlichen Feststellung führt.
Wenn Sie Claude integrieren, verhindert eine Prüfung Ihrer Architektur jetzt spätere Nacharbeit. Lassen Sie uns Ihren technischen Bauplan gegen die Anforderungen von DORA und AI Act abgleichen, bevor Ihre nächste Prüfung ansteht.
FAQ
Welche Auswirkungen hat DORA auf KI-Systeme im Finanzsektor?
Nach DORA Artikel 8 gelten LLM-Architekturen als IKT-Software-Assets. Artikel 3(19) stuft Anthropic als IKT-Drittdienstleister ein. Kredit- und Versicherungsunternehmen unter Aufsicht von EBA, ESMA und EIOPA müssen operationale Risiken seit dem 17. Januar 2025 nach den Artikeln 28 bis 30 und Artikel 32 steuern. Verstöße können mit einem Bußgeld von einem Prozent des weltweiten Tagesumsatzes belegt werden.
Ist Claude AI ein Hochrisiko-KI-System nach dem EU AI Act?
Nach Artikel 51 ist Claude ein GPAI-Modell, sodass Anthropic über Artikel 53 die vorgelagerten Anbieterpflichten trägt. Nachgelagerte Betreiber müssen die Risiken anhand der Kriterien aus Anhang III bewerten. Credit Scoring löst Punkt 5(b) aus, versicherungstechnische Risikobewertung Punkt 5(c) – damit greifen die Artikel 9, 10, 13 und 14 vollständig. Interne Werkzeuge bleiben in der Stufe mit minimalem Risiko.
Welches Audit-Logging ist für Claude AI im Finanzsektor erforderlich?
Um DORA Artikel 10 und EU AI Act Artikel 12 zu erfüllen, protokollieren Sie pseudonymisierte Eingaben, Prompt-Versionen, Modellversionen, Ausgaben, Zeitstempel, Nutzer-IDs und Ergebnisse. Derselbe Datensatz trägt auch Prüfungen zur KI-Erklärbarkeit in der Bankenregulierung, denn Prüfer fragen nach der Begründung einer Entscheidung, nicht nur nach der Entscheidung. Speichern Sie diese Aufzeichnungen in WORM-Konfigurationen auf unveränderlichem Objektspeicher. Die Aufbewahrungsfristen richten sich nach den Vorgaben Ihres Sektors, bei Hochrisikosystemen ist eine längere Aufbewahrung zu erwarten.
Wie wirkt sich der EU AI Act seit August 2025 auf Claude-Deployments aus?
Am 2. August 2025 haben die Pflichten für GPAI-Modelle Transparenzanforderungen und Governance-Parameter für nachgelagerte Betreiber eingeführt. Die Europäische Kommission und das EU-KI-Büro setzen die vorgelagerten Anbieterpflichten gegenüber Anthropic über Artikel 53 aktiv durch. Betreiber sollten die verbleibenden Monate nutzen, um die technischen Schichten aufzubauen, bevor die Pflichten aus Anhang III greifen.
Darf ich Claude AI in der EU für Credit Scoring einsetzen?
Anhang III Punkt 5(b) stuft die Kreditbewertung als hochriskant ein und löst die Artikel 9, 10, 13 und 14 aus. Betreiber müssen die Beschränkungen aus Artikel 22 DSGVO und die EBA-Leitlinien zur Erklärbarkeit von Kreditmodellen einbeziehen. Claude ausschließlich für das Vorscreening einzusetzen senkt die Risikostufe – holen Sie aber vor dem Go-live die Freigabe der Rechtsabteilung ein.
Welche vertraglichen Anforderungen stellt DORA an Anthropic als IKT-Anbieter?
DORA Artikel 30 schreibt ausdrückliche Regelungen vor: SLAs, Datenstandort, Sicherheit, Auditrechte, Exit-Strategien, Leistungsbeschreibungen, Kündigungsfristen und Kooperationszusagen. Der Einkauf muss die Auftragsverarbeitungsvereinbarung von Anthropic sowie deren SOC-2-Type-II- und ISO-27001-Nachweise gegen die technischen Regulierungsstandards der EBA zum IKT-Outsourcing abgleichen. Die Rechtsabteilung muss die Anforderungen aus Artikel 17 und die Konzentrationsrisiken aus Artikel 32 adressieren.
