AI Act, NIS2 und Annex IV: Was Unternehmen 2026 wirklich umsetzen müssen

Stand: 25. Juni 2026

Viele Unternehmen behandeln KI-Regulierung, Cybersicherheit und technische Dokumentation noch als drei getrennte Aufgaben:

• Legal prüft den AI Act.
• IT-Security kümmert sich um NIS2.
• Entwicklung dokumentiert Modelle und Systeme.
• HR schult Mitarbeitende.
• Der Einkauf fordert einige Nachweise von Anbietern an.

Genau diese Trennung wird zum Risiko.

Denn der EU AI Act und NIS2 überschneiden sich an entscheidenden Stellen: bei Risikomanagement, Cybersecurity, Lieferketten, Verantwortlichkeiten, Vorfallsmeldungen, Dokumentation und Schulungen. Für Anbieter von Hochrisiko-KI kommt mit Anhang IV – englisch Annex IV – des AI Act eine weitere zentrale Anforderung hinzu: die technische Dokumentation des Systems.

Annahme: Mit „ANNEIV“ ist „Annex IV“, also Anhang IV des EU AI Act, gemeint.

Die wichtigste Botschaft für mittelständische Unternehmen lautet deshalb:

Compliance darf nicht als Sammlung einzelner Dokumente organisiert werden. Unternehmen brauchen ein gemeinsames Betriebsmodell für KI-Governance, Informationssicherheit und Kompetenzaufbau.

---

1. Wo stehen wir beim EU AI Act?

Der EU AI Act ist seit dem 1. August 2024 in Kraft. Seine Pflichten gelten schrittweise. Einige zentrale Vorschriften sind bereits anwendbar, andere folgen in den kommenden Monaten und Jahren.  

Bereits seit dem 2. Februar 2025 gelten insbesondere:

• das Verbot bestimmter KI-Praktiken,
• die Pflicht, bei Anbietern und Betreibern von KI-Systemen für ein ausreichendes Maß an KI-Kompetenz zu sorgen.

Seit dem 2. August 2025 gelten unter anderem Vorschriften zu General-Purpose-AI-Modellen, Governance und Sanktionen. Viele Transparenzpflichten, etwa für bestimmte KI-generierte Inhalte, sollen ab dem 2. August 2026 greifen.  

Die große Änderung im Jahr 2026

Ursprünglich sollten wesentliche Anforderungen an Hochrisiko-KI-Systeme ab August 2026 beziehungsweise August 2027 gelten. Inzwischen haben sich Europäisches Parlament und Rat im Rahmen des sogenannten Digital Omnibus on AI politisch auf spätere, feste Termine verständigt:

• 2. Dezember 2027 für eigenständige Hochrisiko-KI-Systeme, insbesondere aus den Bereichen Beschäftigung, Bildung, biometrische Identifizierung, kritische Infrastruktur, Migration und Strafverfolgung,
• 2. August 2028 für Hochrisiko-KI, die als Sicherheitskomponente in regulierte Produkte integriert ist.

Die politische Einigung wurde am 7. Mai 2026 erzielt. Zum Stichtag dieses Beitrags war die formale Verabschiedung des Änderungstextes noch nicht vollständig abgeschlossen. Unternehmen sollten die neuen Termine deshalb in ihre Planung aufnehmen, aber den Abschluss des Gesetzgebungsverfahrens weiter beobachten.  

Was die Verschiebung nicht bedeutet

Die zusätzlichen Monate sind kein Freibrief, KI-Governance aufzuschieben.

Mehrere Pflichten gelten bereits. Außerdem benötigen Unternehmen Zeit für:

• die vollständige Erfassung ihrer KI-Systeme,
• die Rollen- und Risikoklassifizierung,
• die Prüfung von Lieferanten,
• die technische und organisatorische Dokumentation,
• die Einführung von Kontrollprozessen,
• die Schulung von Mitarbeitenden,
• die Vorbereitung auf Audits und Behördenanfragen.

Wer erst wenige Monate vor dem jeweiligen Stichtag beginnt, wird vor allem bei komplexen Lieferketten und historisch gewachsenen KI-Lösungen Schwierigkeiten bekommen.

---

2. Für wen ist der AI Act relevant?

Der AI Act betrifft nicht nur Unternehmen, die eigene KI-Modelle entwickeln.

Er unterscheidet verschiedene Rollen. Dazu gehören insbesondere:

• Anbieter, die ein KI-System entwickeln oder unter eigenem Namen auf den Markt bringen,
• Betreiber, die ein KI-System beruflich einsetzen,
• Importeure und Händler,
• Hersteller, die KI in ein Produkt integrieren,
• Anbieter von General-Purpose-AI-Modellen.

Ein Unternehmen kann gleichzeitig mehrere Rollen einnehmen.

Ein Beispiel:

Ein Maschinenbauer nutzt einen externen KI-Assistenten zur Erstellung technischer Anleitungen. Hier ist er in der Regel Betreiber. Entwickelt er auf Basis eines externen Sprachmodells zusätzlich eine eigene Lösung, versieht sie mit seinem Namen und stellt sie Tochtergesellschaften oder Kunden bereit, kann er regulatorisch in die Rolle eines Anbieters rutschen.

Die Frage lautet daher nicht nur:

„Entwickeln wir selbst KI?“

Sondern:

„Welche Rolle übernehmen wir bei jedem einzelnen KI-System?“

---

3. Hochrisiko-KI: Warum HR und Weiterbildung besonders aufmerksam sein müssen

Der AI Act verfolgt einen risikobasierten Ansatz. Besonders umfangreiche Pflichten gelten für sogenannte Hochrisiko-KI-Systeme.

Anhang III nennt unter anderem KI-Systeme, die in folgenden Bereichen eingesetzt werden:

• Zugang zu Bildung und beruflicher Weiterbildung,
• Bewertung von Lernergebnissen,
• Recruiting und Bewerberauswahl,
• Entscheidungen über Arbeitsverhältnisse,
• Aufgabenverteilung,
• Überwachung und Bewertung von Beschäftigten,
• Zugang zu wesentlichen privaten oder öffentlichen Leistungen.

Damit können auch Anwendungen aus HR, Learning & Development und Personalentwicklung betroffen sein.

Praxisbeispiel: KI im Recruiting

Ein System bewertet Lebensläufe, erstellt Ranglisten und empfiehlt Kandidatinnen und Kandidaten für Interviews.

Das Unternehmen betrachtet die Anwendung vielleicht nur als Produktivitätswerkzeug. Tatsächlich kann sie erhebliche Auswirkungen auf die beruflichen Chancen von Menschen haben. Je nach konkreter Funktion und Nutzung kann sie als Hochrisiko-KI einzuordnen sein.

Dann reichen eine Datenschutzerklärung und ein Vertrag mit dem Softwareanbieter nicht aus. Relevant werden unter anderem:

• Risikomanagement,
• Datenqualität,
• Protokollierung,
• Transparenz gegenüber Betreibern,
• menschliche Aufsicht,
• Genauigkeit und Robustheit,
• Cybersecurity,
• Konformitätsbewertung,
• laufende Überwachung.

Praxisbeispiel: KI im LMS

Ein Learning Management System empfiehlt Lerninhalte auf Basis von Rolle, Lernverhalten und Testergebnissen.

Eine reine Empfehlung freiwilliger Lerninhalte ist nicht automatisch Hochrisiko-KI. Anders kann es aussehen, wenn das System:

• Prüfungen automatisch bewertet,
• über Zulassungen oder Zertifizierungen entscheidet,
• Kompetenzen mit Auswirkungen auf Beförderung oder Beschäftigung bewertet,
• Beschäftigte automatisiert miteinander vergleicht,
• Entscheidungen über Einsatzmöglichkeiten vorbereitet.

Entscheidend ist nicht das Etikett „Lernplattform“, sondern der konkrete Verwendungszweck.

---

4. Annex IV: Die technische Akte für Hochrisiko-KI

Anhang IV des AI Act beschreibt, welche technische Dokumentation Anbieter eines Hochrisiko-KI-Systems mindestens erstellen müssen.

Diese Dokumentation soll Behörden und Prüfstellen nachvollziehbar zeigen:

• wie das System funktioniert,
• wofür es vorgesehen ist,
• welche Risiken bestehen,
• wie diese Risiken kontrolliert werden,
• wie das System getestet wurde,
• wie es über seinen gesamten Lebenszyklus überwacht wird.

Annex IV ist deshalb weit mehr als eine Produktbeschreibung. Er verlangt eine belastbare Verbindung zwischen Entwicklung, Risikoanalyse, Tests, Governance und Betrieb.  

Was Annex IV konkret verlangt

1. Allgemeine Beschreibung des Systems

Dazu gehören unter anderem:

• vorgesehener Verwendungszweck,
• Anbieter und Systemversion,
• Abhängigkeiten von Hardware und Software,
• Schnittstellen zu anderen Systemen,
• Bereitstellungsformen wie API, Download oder eingebettete Software,
• Nutzeroberfläche,
• Gebrauchsanweisung.

Die Beschreibung muss klar genug sein, damit Dritte verstehen, was zum KI-System gehört und was nicht.

2. Beschreibung der Entwicklung

Der Anbieter muss unter anderem dokumentieren:

• verwendete Methoden und Entwicklungsschritte,
• eingesetzte vortrainierte Modelle und Drittanbieterwerkzeuge,
• Systemarchitektur,
• Designentscheidungen,
• Optimierungsziele,
• verwendete Rechenressourcen,
• Trainings-, Validierungs- und Testverfahren,
• relevante Datenquellen,
• Kennzeichnungs- und Bereinigungsverfahren,
• Maßnahmen zur menschlichen Aufsicht,
• Cybersecurity-Maßnahmen.

Besonders wichtig ist die Abhängigkeit von Dritten. Wer ein Sprachmodell über eine API integriert, muss nachvollziehbar beschreiben können, wie dieses Modell eingesetzt, konfiguriert und kontrolliert wird.  

3. Leistungsfähigkeit und Grenzen

Die Dokumentation muss nicht nur zeigen, was das System gut kann. Sie muss ebenso offenlegen:

• bekannte Einschränkungen,
• erwartbare Fehlanwendungen,
• Genauigkeit für relevante Personengruppen,
• mögliche diskriminierende Auswirkungen,
• Risiken für Gesundheit, Sicherheit und Grundrechte,
• Anforderungen an die Eingabedaten,
• notwendige menschliche Kontrollen.

Eine Aussage wie „Das Modell erreicht 92 Prozent Genauigkeit“ reicht nicht.

Unternehmen müssen erklären:

• Was bedeutet diese Kennzahl?
• Für welche Daten und Nutzergruppen gilt sie?
• Welche Fehler sind besonders kritisch?
• Welche Folgen hat ein falsch positives oder falsch negatives Ergebnis?
• Wann muss ein Mensch eingreifen?

4. Risikomanagement

Annex IV verlangt eine detaillierte Beschreibung des Risikomanagementsystems.

Das umfasst keinen einmaligen Workshop vor dem Produktstart. Der AI Act betrachtet Risikomanagement als fortlaufenden Prozess über den gesamten Lebenszyklus.

Dazu gehören:

• Risiken identifizieren,
• Risiken analysieren und bewerten,
• geeignete Maßnahmen auswählen,
• Restrisiken beurteilen,
• Tests durchführen,
• neue Risiken im Betrieb erkennen,
• Maßnahmen aktualisieren.

5. Änderungen und Versionen

Anbieter müssen relevante Änderungen am System dokumentieren.

Das ist bei KI besonders anspruchsvoll, weil sich Systeme verändern können durch:

• neue Modellversionen,
• veränderte Prompts,
• zusätzliche Datenquellen,
• neue Schnittstellen,
• geänderte Schwellenwerte,
• neue Nutzergruppen,
• veränderte Einsatzkontexte.

Eine scheinbar kleine Änderung kann die Leistung, das Risikoprofil oder sogar die regulatorische Einordnung verändern.

6. Standards und Konformität

Die Dokumentation muss aufzeigen, welche harmonisierten Standards oder anderen technischen Spezifikationen angewendet wurden.

Harmonisierte Standards sollen Anforderungen des AI Act in technische Verfahren übersetzen. Sie entstehen unter anderem in den Bereichen Risikomanagement, Datenqualität, Protokollierung, Transparenz, menschliche Aufsicht, Robustheit, Cybersecurity und Qualitätsmanagement. Die Arbeiten daran laufen 2026 noch.  

7. Überwachung nach der Markteinführung

Annex IV verlangt zudem einen Plan für die laufende Überwachung des Systems.

Unternehmen müssen also festlegen:

• Welche Leistungsdaten werden beobachtet?
• Welche Vorfälle werden erfasst?
• Wann wird eine Abweichung kritisch?
• Wer entscheidet über Korrekturen?
• Wann wird ein System deaktiviert?
• Wie fließen Rückmeldungen in neue Versionen ein?

Die technische Dokumentation endet nicht mit dem Go-live.

---

5. NIS2: In Deutschland längst keine Zukunftsmusik mehr

Die europäische NIS2-Richtlinie musste ursprünglich bis zum 17. Oktober 2024 in nationales Recht umgesetzt werden. Deutschland hat diese Frist deutlich überschritten. Das deutsche Umsetzungsgesetz wurde schließlich am 5. Dezember 2025 verkündet und trat am 6. Dezember 2025 in Kraft.  

Es gab keine allgemeine Übergangsfrist für die Einführung der Sicherheitsmaßnahmen. Betroffene Einrichtungen mussten daher unmittelbar mit Inkrafttreten die gesetzlichen Anforderungen erfüllen.

Die Registrierung beim Bundesamt für Sicherheit in der Informationstechnik musste grundsätzlich innerhalb von drei Monaten erfolgen. Für bereits betroffene Unternehmen ist diese Frist inzwischen abgelaufen. Das BSI weist ausdrücklich darauf hin, dass noch nicht registrierte Einrichtungen dies umgehend nachholen müssen.  

Welche Unternehmen sind betroffen?

NIS2 erfasst zahlreiche Unternehmen in gesellschaftlich oder wirtschaftlich wichtigen Sektoren. Dazu gehören unter anderem:

• Energie,
• Verkehr,
• Gesundheit,
• Wasser und Abwasser,
• digitale Infrastruktur,
• IT- und Managed Services,
• Post- und Kurierdienste,
• Abfallwirtschaft,
• Lebensmittel,
• Chemie,
• Forschung,
• bestimmte produzierende Unternehmen.

Neben dem Sektor spielen Unternehmensgröße und weitere gesetzliche Kriterien eine Rolle. Typischerweise werden mittlere und große Unternehmen in den erfassten Sektoren relevant. Bestimmte Einrichtungen können unabhängig von ihrer Größe erfasst sein.

Für Unternehmen mit mehr als 250 Beschäftigten ist eine Prüfung besonders dringlich. Die Größe allein führt zwar nicht automatisch zur NIS2-Pflicht. In einem erfassten Sektor ist die Wahrscheinlichkeit einer Einordnung jedoch hoch.

---

6. Was NIS2 von Unternehmen verlangt

NIS2 macht Cybersicherheit ausdrücklich zur Leitungsaufgabe.

Geschäftsleitungen müssen die Risikomanagementmaßnahmen billigen, ihre Umsetzung überwachen und sich selbst regelmäßig fortbilden. Verantwortlichkeit kann nicht vollständig an IT-Leitung, Informationssicherheitsbeauftragte oder externe Dienstleister delegiert werden.  

Zu den zentralen Anforderungen gehören:

• Risikoanalyse und Sicherheitskonzepte,
• Bewältigung von Sicherheitsvorfällen,
• Business Continuity und Wiederherstellung,
• Backup- und Krisenmanagement,
• Sicherheit der Lieferkette,
• sichere Entwicklung und Wartung,
• Schwachstellenmanagement,
• Bewertung der Wirksamkeit von Sicherheitsmaßnahmen,
• Cyberhygiene und Schulungen,
• Kryptografie und Verschlüsselung,
• Zugriffskontrollen,
• Multi-Faktor-Authentifizierung.

Meldepflichten bei Sicherheitsvorfällen

Erhebliche Sicherheitsvorfälle lösen gestufte Meldepflichten aus. Die europäische Richtlinie sieht grundsätzlich vor:

• eine Frühwarnung innerhalb von 24 Stunden,
• eine ausführlichere Meldung innerhalb von 72 Stunden,
• einen Abschlussbericht spätestens nach einem Monat.

Unternehmen brauchen deshalb nicht nur ein Security-Tool. Sie benötigen einen eingeübten Prozess, der Technik, Management, Kommunikation, Datenschutz, Recht und gegebenenfalls Kundenbetreuung miteinander verbindet.  

---

7. Wo sich AI Act, Annex IV und NIS2 überschneiden

Die Regelwerke verfolgen unterschiedliche Ziele:

• Der AI Act konzentriert sich auf sichere, transparente und grundrechtskonforme KI.
• NIS2 konzentriert sich auf die Widerstandsfähigkeit von Netz- und Informationssystemen.
• Annex IV konkretisiert die technische Dokumentation für Hochrisiko-KI.

In der Unternehmenspraxis treffen sie jedoch auf dieselben Systeme, Dienstleister, Daten und Verantwortlichen.

Überschneidung 1: Risikomanagement

NIS2 verlangt ein angemessenes Cyber-Risikomanagement.

Der AI Act verlangt bei Hochrisiko-KI ein kontinuierliches KI-Risikomanagement. Dazu gehören nicht nur Cyberrisiken, sondern auch:

• Fehlentscheidungen,
• Diskriminierung,
• mangelnde Genauigkeit,
• unzureichende menschliche Kontrolle,
• Gefahren für Gesundheit und Sicherheit,
• Grundrechtsrisiken.

Ein gemeinsames Risikoregister kann Doppelarbeit reduzieren. Die Bewertung muss jedoch verschiedene Risikodimensionen getrennt sichtbar machen.

Überschneidung 2: Lieferkette

Viele Unternehmen trainieren keine eigenen Basismodelle. Sie beziehen:

• Cloud-Plattformen,
• KI-APIs,
• vortrainierte Modelle,
• HR-Software,
• Lernplattformen,
• Analysewerkzeuge,
• Managed Services.

NIS2 verlangt, Cyberrisiken in der Lieferkette zu berücksichtigen. Annex IV verlangt Angaben zu vortrainierten Systemen und Drittanbieterwerkzeugen. Der AI Act verteilt Pflichten entlang der KI-Wertschöpfungskette.

Der Einkauf muss daher mehr prüfen als Preis, Funktionsumfang und Datenschutz.

Relevante Fragen sind:

• Welche regulatorische Rolle übernimmt der Anbieter?
• Welche Dokumentation stellt er bereit?
• Wie werden Sicherheitsvorfälle gemeldet?
• Welche Änderungen am Modell werden angekündigt?
• Wo werden Daten verarbeitet?
• Welche Unterauftragnehmer werden eingesetzt?
• Welche Protokolle können exportiert werden?
• Wie unterstützt der Anbieter menschliche Aufsicht?
• Welche Audit- und Informationsrechte erhält der Kunde?

Überschneidung 3: Cybersecurity von KI-Systemen

Annex IV verlangt eine Beschreibung der umgesetzten Cybersecurity-Maßnahmen.

Bei KI entstehen zusätzliche Angriffsflächen, etwa durch:

• Manipulation von Trainings- oder Eingabedaten,
• Prompt Injection,
• ungewollte Offenlegung vertraulicher Informationen,
• Modell- oder Datenextraktion,
• manipulierte Schnittstellen,
• kompromittierte Drittmodelle,
• missbräuchliche Automatisierung,
• vergiftete Wissensdatenbanken.

NIS2 liefert den organisatorischen Rahmen. Der AI Act verlangt zusätzlich, die spezifischen Risiken und Schutzmaßnahmen des KI-Systems nachvollziehbar zu dokumentieren.

Überschneidung 4: Vorfälle und Monitoring

Ein Vorfall kann gleichzeitig mehrere Prozesse auslösen.

Beispiel:

Ein KI-System zur Personaleinsatzplanung wird durch manipulierte Daten beeinflusst. Es verteilt Schichten systematisch falsch und benachteiligt bestimmte Beschäftigtengruppen.

Mögliche Folgen:

• Cybersecurity-Vorfall,
• Beeinträchtigung des Geschäftsbetriebs,
• Datenschutzverletzung,
• Grundrechts- oder Diskriminierungsrisiko,
• Fehlfunktion eines Hochrisiko-KI-Systems,
• arbeitsrechtlicher Konflikt.

Ein rein technisches Incident-Response-Verfahren greift hier zu kurz.

Überschneidung 5: Kompetenzen und Schulung

Beide Regelwerke machen Qualifizierung zu einem Bestandteil wirksamer Compliance.

Beim AI Act geht es um angemessene KI-Kompetenz. Bei NIS2 geht es unter anderem um Cyberhygiene, Sicherheitsbewusstsein und Managementfortbildung.

Ein jährliches Standard-E-Learning mit zehn Multiple-Choice-Fragen erfüllt den Zweck meist nicht.

Mitarbeitende müssen in realistischen Situationen handeln können:

• Darf ich diese Daten in einen KI-Assistenten eingeben?
• Woran erkenne ich eine manipulierte Ausgabe?
• Wann muss ich einen Vorfall melden?
• Wann darf ich eine KI-Empfehlung überstimmen?
• Wie dokumentiere ich eine Entscheidung?
• Was tue ich, wenn ein Anbieter sein Modell verändert?
• Wer darf ein System freigeben?

---

8. Die häufigsten Fehlannahmen

„Wir nutzen nur Standardsoftware.“

Auch Standardsoftware kann KI-Funktionen enthalten. Entscheidend ist, wie sie eingesetzt wird und welche Auswirkungen sie hat.

„Unser Anbieter ist verantwortlich.“

Der Anbieter trägt möglicherweise zentrale Pflichten. Das entbindet das nutzende Unternehmen nicht von seinen Betreiber-, Auswahl-, Kontroll- und Schulungspflichten.

„Wir haben ISO 27001, also erfüllen wir NIS2 und den AI Act.“

Ein bestehendes Informationssicherheitsmanagementsystem ist eine starke Grundlage. Es ersetzt aber weder die rechtliche Betroffenheitsprüfung noch alle spezifischen Anforderungen aus NIS2 und AI Act.

„Annex IV ist nur für Entwickler relevant.“

Die technische Dokumentation benötigt Informationen aus Entwicklung, Produktmanagement, Datenschutz, Security, Qualitätssicherung, Recht, Betrieb und Fachbereich. Sie ist eine unternehmensweite Leistung.

„Die Hochrisiko-Regeln wurden verschoben. Wir haben noch Zeit.“

Die Verschiebung schafft Vorbereitungszeit. Sie beseitigt weder bereits geltende Pflichten noch den Aufwand für Inventarisierung, Verträge, Dokumentation, Tests und Qualifizierung.

---

9. Ein pragmatischer Umsetzungsplan für mittelständische Unternehmen

Phase 1: Betroffenheit und Bestand klären

Erstellen Sie ein gemeinsames Register für:

• KI-Systeme,
• KI-Funktionen in bestehender Software,
• relevante Informationssysteme,
• Anbieter und Unterauftragnehmer,
• Datenarten,
• Geschäftsprozesse,
• verantwortliche Personen.

Vermeiden Sie getrennte Excel-Listen in IT, HR, Datenschutz und Einkauf.

Phase 2: Rollen und Risiken klassifizieren

Bewerten Sie für jedes KI-System:

• Sind wir Anbieter oder Betreiber?
• Fällt die Anwendung unter eine verbotene Praxis?
• Bestehen Transparenzpflichten?
• Handelt es sich möglicherweise um Hochrisiko-KI?
• Ist ein NIS2-relevanter Prozess betroffen?
• Welche Folgen hätte ein Fehler?
• Welche Daten und Personengruppen sind betroffen?

Phase 3: Governance festlegen

Definieren Sie klare Verantwortlichkeiten:

• Wer genehmigt neue KI-Anwendungen?
• Wer führt die rechtliche Einordnung durch?
• Wer verantwortet technische Sicherheit?
• Wer dokumentiert Tests?
• Wer überwacht Anbieter?
• Wer entscheidet über Änderungen?
• Wer meldet Vorfälle?
• Wer stoppt ein System?

Die Geschäftsleitung braucht ein übersichtliches Berichtswesen mit Risiken, Maßnahmen, Fristen und Verantwortlichen.

Phase 4: Gemeinsame Kontrollen aufbauen

Nutzen Sie Kontrollen, die mehrere Anforderungen gleichzeitig bedienen:

• Lieferantenprüfung,
• Versions- und Änderungsmanagement,
• Zugriffskontrollen,
• Protokollierung,
• Risikobewertung,
• Test- und Freigabeprozesse,
• Incident Response,
• Business Continuity,
• Schulungsnachweise,
• Wirksamkeitskontrollen.

Phase 5: Annex-IV-Dokumentation vorbereiten

Auch wenn die eigene Hochrisiko-Einstufung noch nicht abschließend geklärt ist, können Anbieter frühzeitig eine Dokumentationsstruktur aufbauen:

1. Systembeschreibung
2. Verwendungszweck
3. Architektur und Abhängigkeiten
4. Daten und Datenherkunft
5. Designentscheidungen
6. Testmethoden und Ergebnisse
7. Genauigkeit und Grenzen
8. menschliche Aufsicht
9. Cybersecurity
10. Risikomanagement
11. Versionshistorie
12. Standards und Konformität
13. Post-Market-Monitoring

Dokumentieren Sie während der Entwicklung. Eine technische Akte nachträglich zu rekonstruieren ist deutlich teurer und fehleranfälliger.

Phase 6: Rollenbasiert qualifizieren

Nicht alle Beschäftigten benötigen dieselbe Schulung.

Ein wirksames Lernkonzept unterscheidet mindestens:

• allgemeine KI- und Security-Grundlagen für alle,
• sichere Anwendung für KI-Nutzende,
• vertiefte Trainings für HR, Einkauf und Fachbereiche,
• technische Trainings für Entwicklung und IT,
• Incident-Simulationen für Krisenteams,
• Entscheidungs- und Haftungsszenarien für Geschäftsleitungen.

Kurze Lernmodule sollten durch Fallbeispiele, Simulationen und konkrete Arbeitshilfen ergänzt werden.

Phase 7: Wirksamkeit messen

Messen Sie nicht nur Teilnahmequoten.

Aussagekräftiger sind:

• Anteil erfasster KI-Systeme,
• Anteil klassifizierter Anwendungen,
• offene Hochrisiko-Prüfungen,
• dokumentierte Lieferanten,
• Zeit bis zur Vorfallmeldung,
• Ergebnisse von Simulationen,
• Zahl nicht genehmigter KI-Nutzungen,
• Qualität der technischen Dokumentation,
• Anteil geschlossener Risikomaßnahmen,
• beobachtete Fehler- und Abweichungsraten.

---

10. Was das für LMS- und E-Learning-Strategien bedeutet

Der Aufbau von KI- und Cyberkompetenz ist keine begleitende Kommunikationsmaßnahme. Er ist Teil des Kontrollsystems.

Ein LMS kann dabei mehrere Funktionen übernehmen:

• rollenbasierte Zuweisung verpflichtender Lernpfade,
• Nachweis von Schulungen und Wiederholungen,
• Versionierung von Lerninhalten,
• zielgruppenspezifische Szenarien,
• Tests und Praxissimulationen,
• Erinnerung bei auslaufenden Qualifikationen,
• Reporting an Management und Compliance,
• Dokumentation gegenüber Auditoren und Behörden.

Entscheidend ist jedoch die didaktische Qualität.

Eine Geschäftsführerin benötigt andere Inhalte als ein Softwareentwickler. Eine Recruiterin braucht andere Fallbeispiele als ein Mitarbeiter im Vertrieb. Ein Einkaufsteam muss andere Risiken erkennen als ein IT-Administrator.

Wirksame Compliance entsteht nicht durch möglichst viele Inhalte, sondern durch die richtige Handlungskompetenz am richtigen Arbeitsplatz.

---

Fazit: Aus drei Pflichten muss ein gemeinsames System werden

Der AI Act, NIS2 und Annex IV markieren einen grundlegenden Wandel.

Unternehmen müssen nicht mehr nur nachweisen, dass sie Richtlinien veröffentlicht und Schulungen durchgeführt haben. Sie müssen zeigen, dass Risiken systematisch erkannt, kontrolliert, dokumentiert und überwacht werden.

Für den Mittelstand ist das zunächst eine Belastung. Gleichzeitig bietet die Entwicklung eine Chance:

• bessere Transparenz über eingesetzte KI,
• robustere digitale Prozesse,
• weniger Schatten-KI,
• klarere Verantwortlichkeiten,
• sicherere Lieferketten,
• schnelleres Incident Management,
• höhere Akzeptanz bei Mitarbeitenden und Kunden.

Die Unternehmen mit dem größten Vorsprung werden nicht diejenigen sein, die die meisten Compliance-Dokumente produzieren.

Es werden diejenigen sein, die Governance, Technologie, Prozesse und Lernen miteinander verbinden.

---

Handlungsempfehlung

Starten Sie nicht mit einer weiteren isolierten Schulung oder Richtlinie. Beginnen Sie mit einem gemeinsamen Workshop von Geschäftsleitung, IT, Informationssicherheit, Datenschutz, HR, Einkauf und relevanten Fachbereichen. Das erste Ergebnis sollte ein priorisiertes Register aller KI-Systeme, NIS2-relevanten Prozesse, Verantwortlichkeiten und Dokumentationslücken sein.

Hinweis: Dieser Beitrag dient der strategischen Orientierung und ersetzt keine rechtliche Beratung.