NBK Legal · Audit-Vorbereitung · 2026
Drei Regulierungen, dreißig Fragen, eine Vorbereitung. Dieses Dokument simuliert, was Aufsichtsbehörden unter DORA, NIS2 und dem AI Act tatsächlich fragen – mit den richtigen Antworten, den falschen Antworten und dem, was hinter jeder Frage an Haftungsrisiko steckt.
Gelb
Haftungslogik: Was Ihnen persönlich droht, wenn Sie diese Frage nicht beantworten können.
Grün
Die gute Antwort: Was ein vorbereitetes Management sagt – konkret, dokumentiert, souverän.
Rot
Die schlechte Antwort: Was die meisten sagen – und was dabei sofort als Governance-Lücke registriert wird.
Blau
So machen Sie Ihren Job richtig: Was Sie vor dem Audit konkret tun müssen.
Kapitel 1 · Digital Operational Resilience Act
DORA ist seit Januar 2025 in Kraft. Aufsichtsbehörden prüfen nicht nur, ob Systeme vorhanden sind, sondern ob das Management versteht, was es genehmigt hat – und ob es das nachweisen kann.
Was geprüft wird
Ob die Genehmigung formal und nachvollziehbar dokumentiert ist – nicht ob das Framework existiert. «Das Board hat zugestimmt» ohne Protokoll, Datum und namentliche Zuordnung ist für die Aufsicht wertlos.
❌ Schlechte Antwort
Das signalisiert sofort: keine formale Board-Genehmigung, Verantwortung delegiert, kein Protokollnachweis.
→ Führt direkt zu einem Finding der Kategorie «Governance-Defizit».
✓ Gute Antwort
Zeigt: Datum, formaler Beschluss, Board-Ebene, Nachvollziehbarkeit, Dokument verfügbar.
→ Schließt diese Prüfungsdimension ab.
Haftungslogik
Art. 5 Abs. 1 DORA verpflichtet das Leitungsorgan zur aktiven Genehmigung – nicht zur Kenntnisnahme. Wer das Framework «zugelassen» hat, ohne es zu genehmigen, erfüllt die Anforderung nicht. Die persönliche Haftung der Board-Mitglieder ist damit unmittelbar ausgelöst – auch wenn operativ alles korrekt umgesetzt wurde.
So machen Sie Ihren Job richtig
Das Framework liegt jährlich zur formellen Beschlussfassung vor dem Board. Tagesordnungspunkt mit Protokoll, namentlicher Abstimmung und Versionsnummer des genehmigten Dokuments. Das Protokoll ist innerhalb von 48 Stunden nach der Sitzung finalisiert und archiviert. Sie müssen das Framework inhaltlich auf Ebene kennen können, die zeigt, dass Sie es verstanden haben – nicht auswendig, aber substanziell.
Was geprüft wird
Ob das Register vollständig, aktuell und nach Kritikalität geordnet ist – und ob das Management die kritischen Einträge kennt und erklären kann, warum sie so klassifiziert wurden.
❌ Schlechte Antwort
Kein Register im regulatorischen Sinne, keine Kritikalitätsklassifikation, Nachlieferung signalisiert fehlende Vorbereitung.
→ Sofortiges Follow-up-Audit, erhöhte Aufsichtsintensität.
✓ Gute Antwort
→ Zeigt Systembewusstsein und operative Kontrolle.
Haftungslogik
Art. 28 Abs. 2 DORA verpflichtet Finanzunternehmen, ein vollständiges Register aller ICT-Drittdienstleister zu führen. Fehlt dieses oder ist es unvollständig, ist das ein direkter Verstoß gegen eine Dokumentationspflicht – nicht ein «noch in Arbeit»-Befund. Für das Leitungsorgan bedeutet das: Sie haben eine Pflicht nicht erfüllt, die Art. 5 Ihnen zuweist.
So machen Sie Ihren Job richtig
Das Register ist ein lebendiges Dokument mit verantwortlichem Owner und Quartals-Review. Vor jedem Audit: Kurz-Briefing durch den CISO – Sie kennen die Top-5 der kritischen Anbieter, den letzten Update-Termin und wer für die Exit-Strategien verantwortlich ist. Sie müssen nicht jeden Eintrag kennen – aber Sie müssen das System kennen und die kritischen Einträge.
Was geprüft wird
Ob Tests tatsächlich unter realistischen Bedingungen stattgefunden haben – nicht ob Pläne existieren. Die Folgefrage ist immer: Was haben Sie aus dem Test gelernt, und was haben Sie geändert?
❌ Schlechte Antwort
Kein konkretes Datum, keine Ergebnisse, keine Nachweise. «Im Rahmen» ist keine Antwort.
→ Folgeaufforderung zur Vorlage von Testprotokollen, die dann nicht existieren.
✓ Gute Antwort
→ Zeigt: Datum, Szenario, ehrliches Ergebnis, Maßnahme, Planung.
Haftungslogik
DORA Art. 11 verlangt regelmäßige, realistische Tests – und die systematische Einarbeitung der Ergebnisse. Ein Test ohne dokumentierte Lessons-Learned-Schleife erfüllt die Anforderung nicht. Kann das Leitungsorgan keine Testergebnisse benennen, signalisiert das fehlende Oversight – eine der Kernpflichten nach Art. 5.
So machen Sie Ihren Job richtig
Tests mindestens jährlich, unter realistischen Bedingungen. Ergebnisse in einem Bericht, der dem Board vorgelegt wird. Als Mitglied des Leitungsorgans erhalten Sie nach jedem Test eine Executive Summary: Szenario, Ergebnis, offene Punkte, Maßnahmenplan. Sie lesen ihn. Sie können ihn erklären. Wenn Sie im Audit von Testprotokollen überrascht werden, haben Sie Ihr Oversight-Recht nicht wahrgenommen.
Was geprüft wird
Ob die Eskalationskette funktioniert, das Leitungsorgan rechtzeitig eingebunden wurde und ob die Meldeentscheidung nachvollziehbar dokumentiert ist – auch wenn nicht gemeldet wurde.
❌ Schlechte Antwort
«Keine schwerwiegenden Vorfälle» klingt für einen Auditor nach mangelhafter Erkennungsfähigkeit oder Herunterstufen von Incidents. «Intern gehandhabt» ohne Dokumentation ist ein Warnsignal.
→ Auditor fragt weiter: Zeigen Sie mir Ihr Incident-Log der letzten 12 Monate.
✓ Gute Antwort
→ Zeigt funktionierende Governance-Kette.
Haftungslogik
DORA Art. 19 verlangt, dass das Leitungsorgan über schwerwiegende ICT-Incidents informiert wird. Nicht nur nach oben eskaliert – sondern das Leitungsorgan selbst. Wer nicht informiert wurde, hat keine Oversight ausgeübt. Wer informiert wurde, aber nichts unternommen hat, hat seine Verantwortung nach Art. 5 nicht wahrgenommen. Beide Szenarien sind persönlich haftungsrelevant.
So machen Sie Ihren Job richtig
Definieren Sie intern: Ab welchem Schwellenwert wird das Leitungsorgan informiert – und in welchem Zeitfenster? Diese Eskalationsregel ist schriftlich fixiert. Sie erhalten bei Major Incidents eine direkte Benachrichtigung innerhalb von [X] Stunden – nicht als CC in einem E-Mail-Thread, sondern als persönliche Meldung. Und Sie dokumentieren Ihre Kenntnisnahme.
Was geprüft wird
Ob das Management das systemische Risiko versteht, das aus der Abhängigkeit von wenigen Anbietern entsteht – und ob es dokumentierte Maßnahmen zur Risikosteuerung gibt.
❌ Schlechte Antwort
Microsoft und AWS gleichzeitig zu nutzen ist keine Diversifikation im Sinne von DORA – beide unterliegen US-Recht und zeigen strukturelle Konzentrationsrisiken auf regulatorischer Ebene.
→ Zeigt konzeptionelles Missverständnis des DORA-Konzentrationsrisikobegriffs.
✓ Gute Antwort
→ Zeigt Bewusstsein, Steuerungsansatz und Board-Einbindung.
Haftungslogik
Art. 29 DORA verpflichtet Finanzunternehmen, Konzentrationsrisiken aus ICT-Drittanbieterabhängigkeiten aktiv zu bewerten und zu steuern. Wer das Konzentrationsrisiko nicht kennt, kann es nicht steuern – und das Leitungsorgan hat nach Art. 5 die Pflicht, die wesentlichen Risiken zu verstehen. Die Aufsicht kann bei systemischem Konzentrationsrisiko Maßnahmen anordnen – unabhängig davon, ob das Unternehmen selbst einen Ausfall erlebt hat.
So machen Sie Ihren Job richtig
Das Konzentrationsrisiko ist einmal jährlich explizit im Board-Bericht als eigene Kennzahl ausgewiesen: Welcher Prozentsatz kritischer Funktionen hängt an welchem Anbieter? Sie kennen die Antwort auf diese Frage – nicht aus dem Kopf, aber Sie wissen, wo sie steht und können sie sofort abrufen.
Kapitel 2 · Network and Information Security Directive 2
NIS2 ist seit Oktober 2024 in nationales Recht umzusetzen. Das Novum: persönliche Haftung der Geschäftsleitung. Das Leitungsorgan muss Cybersicherheitsmaßnahmen nicht nur genehmigen – es muss sie verstehen und nachweislich selbst geschult worden sein.
Was geprüft wird
Ob das Leitungsorgan nachweisbar geschult wurde – nicht das Unternehmen, nicht der CISO. Art. 20 Abs. 2 ist explizit: Das Leitungsorgan muss Schulungen absolvieren und sicherstellen, dass alle Mitglieder ausreichende Kenntnisse haben, um Risiken zu erkennen und Auswirkungen auf Dienstleistungen bewerten zu können.
❌ Schlechte Antwort
Awareness-Trainings erfüllen die Anforderung nicht. CISO-Kontakt ist keine Schulung. Kein Datum, kein Nachweis, kein Inhalt.
→ Unmittelbarer Compliance-Befund nach Art. 20 Abs. 2.
✓ Gute Antwort
→ Erfüllt Art. 20 Abs. 2 vollständig, Nachweis vorhanden.
Haftungslogik
Art. 20 Abs. 2 NIS2 ist die unmittelbarste persönliche Pflicht in der gesamten EU-Regulierungsgeschichte: Sie müssen geschult worden sein – nicht Ihr Unternehmen. Fehlt der Nachweis, liegt ein persönlicher Verstoß vor, nicht ein organisatorischer. Die nationale Aufsicht kann das direkt feststellen und sanktionieren – unabhängig davon, wie gut Ihr Sicherheitsteam aufgestellt ist.
So machen Sie Ihren Job richtig
Externe Schulung, einmal jährlich, für das gesamte Leitungsorgan. Kein internes Awareness-Modul – eine strukturierte Schulung mit Inhalt, Nachweis und Protokoll. Auf dem Kalender: [Name der Schulung], [Datum], [Anbieter]. Das Zertifikat liegt in Ihrer Personalakte und im Compliance-Archiv. Nicht verhandelbar.
Was geprüft wird
Ob die Einstufung bewusst und dokumentiert erfolgt ist – oder ob das Unternehmen schlicht angenommen hat, dass es nicht betroffen ist. 80 % der NIS2-betroffenen Unternehmen wissen nicht, dass sie betroffen sind.
❌ Schlechte Antwort
«Wir haben geprüft» ohne Dokumentation, ohne Methodik und ohne Referenz auf die 16 NIS2-Sektoren ist keine Einstufungsentscheidung – es ist eine Annahme.
→ Auditor fragt: Zeigen Sie mir die Dokumentation dieser Prüfung.
✓ Gute Antwort
→ Vollständige und nachvollziehbare Antwort.
Haftungslogik
«Wir wussten nicht, dass wir betroffen sind» ist keine Haftungsbefreiung. NIS2 gilt kraft Gesetzes – die Pflicht zur Einstufung liegt beim Unternehmen, nicht bei der Behörde. Ein Unternehmen, das seine NIS2-Pflichten nicht erfüllt hat, weil es sich nicht als betroffen eingestuft hat, haftet für alle daraus entstandenen Versäumnisse – rückwirkend ab dem Stichtag der nationalen Umsetzung.
So machen Sie Ihren Job richtig
Die Einstufungsentscheidung ist ein formeller, dokumentierter Prozess – mit Datum, Methodik, Ergebnis und Verantwortlichem. Das Dokument liegt in Ihrem Compliance-Archiv. Wenn Sie sich in einem der 16 NIS2-Sektoren bewegen oder Ihre Kunden dort operieren, holen Sie externe Einschätzung ein – die Konsequenz einer Fehleinschätzung ist teurer als die Beratung.
Was geprüft wird
Ob Sicherheitsanforderungen strukturell in Lieferantenbeziehungen verankert sind – nicht nur vertraglich erwähnt. Das schließt kleine Zulieferer und Spezialsoftware-Anbieter ein, die intern oft nicht als «Sicherheitsrisiko» wahrgenommen werden.
❌ Schlechte Antwort
SOC2-Zertifikate sind vergangenheitsbezogen, decken nicht alle Anforderungen und sagen nichts über aktuelle Vorfälle beim Zulieferer. Kein Monitoring, keine Incident-Integration.
→ Unvollständige Antwort, Monitoring-Frage wird nachgezogen.
✓ Gute Antwort
→ Zeigt strukturelles Supply-Chain-Management, nicht nur formale Prüfung.
Haftungslogik
Art. 21 Abs. 2 lit. d NIS2 verlangt Sicherheit in der Lieferkette – explizit. Ein Cybervorfall, der über einen Zulieferer in Ihre Systeme eingedrungen ist, ist kein Entschuldigungsgrund – er ist ein Nachweis, dass Ihre Supply-Chain-Security nicht ausreichend war. Die Haftung des Leitungsorgans für unzureichende Maßnahmen greift auch dann, wenn der Ursprung außerhalb des eigenen Unternehmens lag.
So machen Sie Ihren Job richtig
Jeder kritische Zulieferer hat eine vertragliche Sicherheitsklausel, eine jährliche Risikobewertung und eine Incident-Meldepflicht Ihnen gegenüber. Sie sehen jährlich eine Liste der kritischen Zulieferer und deren Bewertungsstatus. Sie wissen, welcher Zulieferer in den letzten 12 Monaten einen sicherheitsrelevanten Vorfall hatte – und wie Sie darauf reagiert haben.
Was geprüft wird
Ob die dreistufige Meldepflicht bekannt und operationalisiert ist, ob die Meldeentscheidung dokumentiert ist – auch bei Nicht-Meldung – und ob das Leitungsorgan in den Prozess eingebunden war.
❌ Schlechte Antwort
Ohne Klassifikationsmatrix und Dokumentation ist «kein meldepflichtiger Vorfall» keine Aussage – es ist eine Behauptung. Und «intern gehandhabt» ohne Nachweis ist für die Aufsicht ein rotes Signal.
→ Auditor verlangt das Incident-Log der letzten 24 Monate.
✓ Gute Antwort
→ Vollständige Abbildung aller drei Meldepflicht-Stufen.
Haftungslogik
NIS2 Art. 23 definiert Meldefristen, die keine Ausnahmen kennen: 24 Stunden für die Early Warning – nicht nach Abschluss der internen Analyse, sondern nach Erkennung. Eine verspätete Meldung ist ein eigenständiger Verstoß, unabhängig davon, ob der Vorfall selbst gut gemanagt wurde. Das Leitungsorgan hat sicherzustellen, dass die Eskalationskette diese Fristen operativ ermöglicht.
So machen Sie Ihren Job richtig
Die drei Meldestufen (24h / 72h / 1 Monat) sind in Ihrem Incident-Response-Plan als Schritt mit Verantwortlichem, Vorlage und Eskalationsweg hinterlegt. Es gibt eine Person, die rund um die Uhr die Meldung auslösen kann – und diese Person weiß, an wen zu melden ist. Sie als Mitglied des Leitungsorgans sind in der Kontaktliste für Incidents oberhalb des definierten Schwellenwerts.
Was geprüft wird
Die substanziellste Frage im NIS2-Audit: Versteht das Leitungsorgan tatsächlich, welche Auswirkungen ein Cybervorfall auf die eigenen Dienste hätte – oder delegiert es diese Beurteilung vollständig an Technik und CISO?
❌ Schlechte Antwort
Diese Antwort ist die häufigste – und die am deutlichsten haftungsbegründende. Art. 20 sagt explizit, dass die Verantwortung beim Leitungsorgan liegt. Der CISO ist operativer Umsetzer, nicht Verantwortungsträger auf Board-Ebene.
→ Direkter Hinweis auf mangelnde Governance-Fähigkeit nach Art. 20 Abs. 1.
✓ Gute Antwort
→ Zeigt strukturiertes Board-Enablement und eigene Urteilsfähigkeit.
Haftungslogik
Art. 20 Abs. 1 NIS2 ist klar: Das Leitungsorgan muss Risikobeurteilungen selbst vornehmen können. Nicht delegieren, nicht «auf Basis von CISO-Empfehlungen zustimmen». Wer diese Fähigkeit nicht hat, erfüllt seine Sorgfaltspflicht nicht – und haftet persönlich für daraus entstehende Schäden. Das ist die strukturelle Innovation von NIS2 gegenüber allen früheren EU-Regulierungen.
So machen Sie Ihren Job richtig
Sie kennen die drei kritischsten Dienste Ihres Unternehmens und deren Ausfallwirkung. Sie wissen, was ein 24-Stunden-Ausfall dieser Dienste für Kunden, Lieferkette und Regulierung bedeuten würde. Das ist kein technisches Wissen – das ist Unternehmensverständnis. Wenn Sie das nicht antworten können, haben Sie eine Lücke in Ihrer Governance-Kompetenz nach Art. 20.
Kapitel 3 · EU Artificial Intelligence Act
Der AI Act ist seit Februar 2025 schrittweise in Kraft. Die ersten Audits betreffen verbotene Praktiken (sofort) und GPAI-Anforderungen (ab August 2025). Hochrisiko-Anforderungen folgen ab August 2026 – aber Vorbereitungsfragen sind jetzt.
Was geprüft wird
Ob das Unternehmen eine vollständige Inventur seiner KI-Systeme vorgenommen hat – und ob die Klassifizierungsentscheidung für jedes System dokumentiert und begründet ist. Die häufigste Lücke: Unternehmen kennen ihre «offensichtlichen» KI-Systeme, aber nicht alle eingebetteten Modelle in Softwareprodukten.
❌ Schlechte Antwort
Kein KI-Inventar, keine Methodik, keine Prüfung der Drittanbieter-KI. «Standard-Software» kann hochriskante KI-Komponenten enthalten – das ist kein Argument für Nicht-Betroffenheit.
→ Auditor fragt nach KI-Inventar und Drittanbieter-Analyse.
✓ Gute Antwort
→ Zeigt Vollständigkeit, Methodik, Dokumentation, Board-Einbindung.
Haftungslogik
Die Klassifizierungsentscheidung liegt beim Provider oder Deployer – nicht bei einer Behörde. Wer ein Hochrisiko-System als Nicht-Hochrisiko klassifiziert und betreibt, begeht einen Compliance-Verstoß ab dem Stichtag – unabhängig davon, ob etwas schiefgegangen ist. Die nachträgliche Hochstufung kostet typisch sechsstellig (Konformitätsbewertung, Dokumentation, Risikomanagementsystem). Im M&A-Kontext ist eine falsch klassifizierte KI ein direkter Bewertungsabschlag.
So machen Sie Ihren Job richtig
KI-Inventar als lebendiges Register, mit Klassifizierungsstatus, Eigentümer und Datum der letzten Überprüfung. Jede neue Software-Beschaffung enthält einen KI-Check: Enthält dieses Produkt KI-Komponenten? Wenn ja: Klassifizierung prüfen. Sie als Mitglied des Leitungsorgans erhalten einmal jährlich eine Ein-Seiten-Übersicht: Welche KI-Systeme betreiben wir, welche sind Hochrisiko, was sind die Pflichten daraus?
Was geprüft wird
Ob menschliche Aufsicht operativ verankert ist – nicht nur als Prinzip erklärt. Der Auditor will wissen: Wer ist die konkrete Person? Welche Entscheidungen kann sie übersteuern? Ist das dokumentiert?
❌ Schlechte Antwort
«Alle Entscheidungen» ist unglaubwürdig bei System mit hohem Output-Volumen. «Richtlinien» sind kein Nachweis von gelebter Aufsicht. Kein Name, keine Funktion, kein Prozess.
→ Folgeaufforderung: Zeigen Sie den Überwachungsprozess in der Praxis.
✓ Gute Antwort
→ Zeigt operationalisierte Aufsicht, keine Papierregelung.
Haftungslogik
Art. 26 Abs. 2 AI Act verpflichtet Deployer, sicherzustellen, dass ausreichend kompetente Personen die menschliche Aufsicht ausüben können. «Ausüben können» bedeutet: wirklich eingreifen können, nicht nur theoretisch. Wenn ein Hochrisiko-System eine falsche Entscheidung trifft und die menschliche Aufsicht nachweislich nicht funktioniert hat, ist das ein direkter Compliance-Verstoß – mit der Gesellschaft als Haftungssubjekt und dem Leitungsorgan in seiner gesellschaftsrechtlichen Sorgfaltspflicht.
So machen Sie Ihren Job richtig
Human Oversight ist eine Funktion mit Namen, Schulung, Befugnissen und Log. Sie kennen den Namen der Person, die für jedes Hochrisiko-System Human Oversight ausübt. Sie wissen, dass diese Person entsprechend geschult ist. Und Sie stellen sicher, dass das System diese Person nicht mit Output-Volumen überwältigt. Wenn die Aufsichtsperson jeden Tag 500 KI-Entscheidungen «freigeben» soll, ist das keine echte Aufsicht.
Was geprüft wird
Ob das Unternehmen die verbotenen Praktiken kennt und bewusst ausgeschlossen hat – und ob das dokumentiert ist. Nicht ob das Unternehmen sagt «nein, natürlich nicht» – sondern ob diese Prüfung methodisch erfolgt ist.
❌ Schlechte Antwort
Verbotene Praktiken sind nicht immer «offensichtlich». Sublimale Beeinflussung, Ausnutzung von Schwächen, Verhaltensvorhersage zur Beeinflussung – diese Grenzen sind nicht intuitiv. «Offensichtlich» ist keine regulatorische Methodik.
→ Auditor fragt: Was genau ist «offensichtlich» und wer hat das geprüft?
✓ Gute Antwort
→ Zeigt Methodik, Vollständigkeit, externe Validierung.
Haftungslogik
Verbotene Praktiken nach Art. 5 sind seit Februar 2025 sofort verboten. Das Bußgeld beträgt bis zu 35 Mio. EUR oder 7 % des weltweiten Jahresumsatzes – das höchste im gesamten AI Act. «Wir wussten nicht» ist bei einer Prüfpflicht, die seit dem Inkrafttreten bestand, kein Entlastungsgrund. Und: Reputationsrisiko durch öffentliche Enforcement-Entscheidungen der nationalen Behörden ist erheblich.
So machen Sie Ihren Job richtig
Art. 5-Prüfung einmalig, dokumentiert, für jedes KI-System. Bei neuen Systemen: Prüfung als Genehmigungsvoraussetzung. Das Marketing-Team, das ein Empfehlungssystem einführt, das Kundenverhalten prognostiziert und beeinflusst, muss diese Prüfung durchlaufen haben – bevor es live geht. Das ist eine Freigabepflicht, nicht eine nachträgliche Aufgabe.
Was geprüft wird
Ob das Unternehmen seine Deployer-Pflichten beim Einsatz von Foundation Models kennt – und ob es die Verantwortungsabgrenzung zwischen Provider (OpenAI, Anthropic etc.) und Deployer (dem eigenen Unternehmen) verstanden hat.
❌ Schlechte Antwort
OpenAI ist Provider. Wer das Modell in ein Produkt oder einen Prozess einbettet, ist Deployer – und trägt eigene Pflichten. Die Compliance des Providers entbindet den Deployer nicht.
→ Zeigt grundlegendes Missverständnis der Verantwortungskette.
✓ Gute Antwort
→ Zeigt Verständnis der Deployer-Rolle und eigene Pflichten.
Haftungslogik
Als Deployer eines GPAI-Modells trägt das eigene Unternehmen Verantwortung für den konkreten Einsatz – für die Angemessenheit der Nutzung, das Monitoring, die Dokumentation und die Einhaltung der Transparenzpflichten nach Art. 50. Wenn das eingebettete GPAI-Modell eine falsche oder schädliche Ausgabe produziert, stellt die Aufsicht zuerst die Frage: Hat der Deployer seine Pflichten erfüllt?
So machen Sie Ihren Job richtig
Jede Nutzung eines GPAI-Modells im Unternehmenskontext ist dokumentiert: Welches Modell, welcher Use Case, welche Deployer-Pflichten entstehen. «Wir nutzen das intern» ist kein Freifahrtschein – interne Nutzung in Entscheidungsprozessen kann Deployer-Pflichten auslösen, je nach Sensitivität der Entscheidung.
Was geprüft wird
Ob Transparenzpflichten operativ umgesetzt sind – nicht als allgemeine Datenschutzerklärung, sondern als konkrete Kennzeichnung im Moment der Interaktion. Betroffen: Chatbots, synthetische Stimmen, Deepfakes, automatisierte Entscheidungssysteme.
❌ Schlechte Antwort
Eine Datenschutzerklärung ist keine Transparenz im Sinne von Art. 50 – sie wird nicht im Moment der Interaktion wahrgenommen und erfüllt nicht die Pflicht zur klaren Kennzeichnung.
→ Direkter Compliance-Befund für alle interaktiven KI-Systeme ohne Echtzeit-Kennzeichnung.
✓ Gute Antwort
→ Zeigt operationalisierte Transparenzpflicht, nicht nur Deklaration.
Haftungslogik
Art. 50 AI Act gilt ab dem Stichtag für alle interaktiven KI-Systeme. Ein Unternehmen, das einen Chatbot ohne KI-Kennzeichnung betreibt, verstößt unmittelbar gegen Art. 50. Das ist kein Hochrisiko-Tatbestand, aber eine eigenständige Pflichtverletzung mit Bußgeldpotenzial nach nationalem Recht. Und: Im Streit mit einem Kunden, der eine KI-generierte Entscheidung anficht, ist fehlende Kennzeichnung ein erhebliches prozessuales Risiko.
So machen Sie Ihren Job richtig
Alle Kundenkontaktpunkte mit KI-Interaktion sind inventarisiert und auf Art.-50-Transparenz geprüft. Neue digitale Produkte durchlaufen einen KI-Transparenz-Check vor Launch. Das ist eine Aufgabe von drei Wochen – nicht eines externen Projekts. Jemand muss einmal alle Touchpoints durchgehen und sicherstellen, dass die Kennzeichnung dort ist, wo der Kunde interagiert.
Diese Antworten beenden das Audit nicht – sie eröffnen ein Finding. Jeder dieser Sätze signalisiert der Aufsicht: fehlende Governance-Kompetenz auf Leitungsebene.
«Das liegt bei unserer IT-Abteilung / beim CISO.»
Zeigt: Verantwortung delegiert. DORA, NIS2 und AI Act begründen Pflichten auf Leitungsebene. Delegation ist operativ, nicht haftungsbefreiend.
«Wir sind compliant – Details kann Ihnen unser Team erklären.»
«Compliant» ohne Nachweis ist eine Behauptung. Und: Sie müssen die Details nicht auswendig kennen, aber Sie müssen auf der substanziellen Ebene antworten können.
«Wir arbeiten gerade daran.»
Im Audit gilt: Entweder umgesetzt oder nicht. «Wir arbeiten daran» ist eine Bestätigung des Defizits – mit offenem Ende. Besser: «Die Maßnahme ist bis [Datum] abgeschlossen, Verantwortlicher ist [Name].»
«Das hat uns nicht betroffen, deshalb war das nicht nötig.»
Regulatorische Pflichten existieren unabhängig davon, ob ein Vorfall eingetreten ist. Die Abwesenheit eines Incidents beweist nicht die Anwesenheit von Compliance.
«Das haben wir immer so gemacht.»
DORA gilt seit Januar 2025, NIS2 seit Oktober 2024, AI Act Art. 5 seit Februar 2025. Bisherige Praxis ist kein Maßstab für regulatorische Anforderungen, die diesen Zeitraum überlagern.
«Ich bin kein Techniker – das müssen Sie mit unserem CTO besprechen.»
Sie müssen kein Techniker sein. Sie müssen auf substanzieller Ebene erklären können, welche Entscheidungen Sie getroffen haben, warum, und was die Auswirkung auf das Risikoprofil ist. Das ist Führungsverantwortung, keine Technikfrage.
Abschlusstest · 12 Fragen · ca. 8 Minuten
Jede Frage beschreibt eine reale Audit-Situation. Wählen Sie die Antwort, die Sie in diesem Moment geben würden. Keine Tricks — aber auch keine offensichtlich falschen Antworten.
Der Auditor legt Ihnen das ICT-Risikomanagement-Framework vor und fragt: «Können Sie mir erklären, was in Abschnitt 3 dieses Dokuments geregelt ist?»
Der Auditor fragt: «Ihr Backup-System wurde zuletzt vor 14 Monaten getestet. Wer hat das genehmigt, und wie wurde das Leitungsorgan informiert?»
Der Auditor fragt: «Was würde passieren, wenn Ihr wichtigster Cloud-Anbieter morgen den Betrieb einstellt?»
Der Auditor fragt: «Wann haben Sie zuletzt persönlich — als Mitglied des Leitungsorgans — eine Schulung zu Cybersicherheitsrisiken absolviert?»
Während des Audits stellt sich heraus, dass Ihr Unternehmen vor 8 Monaten einen Cybervorfall hatte, der 40 Minuten gedauert hat und eine kritische Kundenfunktion betraf. Es wurde nicht gemeldet. Der Auditor fragt: «Warum nicht?»
Der Auditor fragt Sie direkt: «Nennen Sie mir drei Ihrer kritischsten IT-Systeme und beschreiben Sie, was ein 24-Stunden-Ausfall für Ihre Kunden bedeuten würde.»
Ihr Hauptlieferant für eine kritische Software hatte vor drei Monaten einen Ransomware-Angriff. Der Auditor fragt: «Was haben Sie nach Bekanntwerden dieses Vorfalls unternommen?»
Der Auditor fragt: «Ihr Unternehmen nutzt ein KI-gestütztes Bewerbermanagementsystem. Haben Sie dieses als Hochrisiko klassifiziert?»
Ihr Unternehmen setzt ChatGPT-basierte Antwortvorschläge im Kundensupport ein. Der Auditor fragt: «Werden Ihre Kunden informiert, wenn sie mit einem KI-generierten Text interagieren?»
Der Auditor fragt: «Wie stellen Sie sicher, dass keines Ihrer KI-Systeme die nach Art. 5 verbotenen Praktiken umsetzt?»
Am Ende des DORA-Audits fragt der Prüfer: «Wenn ich Ihnen eine Frage zu Ihrer ICT-Risikoarchitektur stelle und Sie diese nicht beantworten können — wie erklären Sie das?»
Am Ende des AI-Act-Audits sagt der Prüfer: «Ich habe heute mehrere Lücken in Ihrer KI-Governance festgestellt. Was sagen Sie dazu?»