Stellen Sie sich vor, die Revision stellt eine scheinbar einfache Frage: «Zeigen Sie uns, woher diese Kennzahl kommt, wer sie verändert hat und warum das Modell so entschieden hat.»
In vielen Organisationen beginnt dann keine Antwort, sondern eine Suche: Dateien, Exportpfade, E-Mails, manuelle Korrekturen, lokale Logiken. Am Ende gibt es eine Erklärung – aber keinen Beweis.
Genau das ist der Punkt, an dem DORA und AI Act nicht wie «Regulatorik» wirken, sondern wie ein Betriebsstresstest. Nicht für Juristen, sondern für Datenprozesse.
Worum es praktisch geht
DORA und AI Act sind unterschiedlich, aber sie treffen denselben Nerv: Sie verlangen belastbare, nachvollziehbare und kontrollierte Abläufe.
DORA drückt vor allem auf:
- Betriebssicherheit von Datenpipelines und Plattformen
- Monitoring und Incident-Handling
- Wiederherstellbarkeit (Backup/Recovery)
- Kontrolle von Drittanbietern und Abhängigkeiten
AI Act drückt vor allem auf:
- Daten- und Modellgovernance
- Dokumentation der Trainingsdaten (Herkunft, Bereinigung, Risiken)
- Monitoring von Modellen (Drift, Bias, Performance)
- Logging von Modellentscheidungen und Nachvollziehbarkeit
Beidem ist gemeinsam: Wenn Ihre Datenprozesse «funktionieren», aber nicht nachweisbar sind, wird es teuer. Nicht weil Sie böse Absichten haben, sondern weil der Aufwand zur Rekonstruktion explodiert.
Häufigste Schwachstelle: «funktionierend» statt «kontrolliert»
Viele Finance-Organisationen haben Prozesse, die Ergebnisse liefern. Aber Ergebnisse allein sind nicht das Ziel. Kontrollierte Prozesse bedeuten:
- Sie wissen, welche Datenquelle welche Zahl liefert.
- Sie wissen, welche Transformationen passiert sind (und wann).
- Sie wissen, wer Zugriff hatte und wer Änderungen vorgenommen hat.
- Sie erkennen Abweichungen früh (Monitoring), nicht erst in der Prüfung.
- Sie haben einen Incident-Prozess, der nicht improvisiert ist.
Das klingt banal, ist aber genau die Linie zwischen «wir sind handlungsfähig» und «wir sind im Ausnahmezustand».
DORA in Datenprozessen:
Controls, die wirklich zählen
End-to-End Monitoring
Nicht nur «läuft der Job», sondern: Datenvollständigkeit, Latenz, Anomalien, Fehlerraten.
Incident-Definition und Triage
Was ist ein Incident im Datenkontext? Fehlende Daten? Veraltete Daten? Falsche Werte? Wer entscheidet die Kritikalität? Wie wird dokumentiert?
Recovery-Fähigkeit
Können Sie Datenstände wiederherstellen? Können Sie nachweisen, dass Sie es getestet haben?
Third-Party Abhängigkeiten
Datenflüsse hängen an Providern, SaaS, externen Quellen. DORA verlangt, dass Sie Risiken kennen und kontrollieren können: Abhängigkeiten dokumentieren, SLAs klären, Monitoring etablieren.
AI Act in Datenprozessen:
Weniger «KI», mehr Disziplin
Trainingsdaten-Dokumentation
Welche Daten? Aus welchen Quellen? Welche Bereinigung? Welche Risiken (Bias, Lücken, Veralterung)?
Modell-Monitoring
Nicht nur «funktioniert es», sondern: Drift, Bias, Performance-Veränderungen.
Logging
Welche Eingaben führten zu welcher Ausgabe? Wann? Mit welcher Modellversion?
Risikobetrachtung
Welche Fehlentscheidungen können auftreten? Wie erkennen wir sie? Wie verhindern wir Schaden?
Der AI Act zwingt Organisationen, von «wir haben ein Modell» zu «wir betreiben ein Modell» zu wechseln.
Ein pragmatischer 90‑Tage‑Start:
Evidence-First statt Grossprojekt
Hier machen 90 Tage Sinn – nach dem Prinzip Evidence-First: In 90 Tagen bauen Sie die minimalen Nachweise und Kontrollen für die kritischsten Datenflüsse.
Tag 1-30: Transparenz + Prioritäten
- kritische Reports, Kennzahlen, Datenflüsse inventarisieren
- Verantwortungen festlegen (Owner, Betrieb, Eskalation)
- Incident-Kriterien definieren
Tag 31-60: Monitoring + Nachvollziehbarkeit
- Logging, Lineage, Versionsstände für kritische Flüsse
- Monitoring und Alerting (Latenz, Vollständigkeit, Qualität)
- Recovery-Szenarien testen und dokumentieren
