EU AI Act: Schulungsleitfaden für Begriffe, Rollen und Module

Viele EU‑AI‑Act‑Trainings scheitern an der Basis: Begriffe und Rollen werden zu spät geklärt, RACI bleibt diffus, Nachweise sind lückenhaft. Der Dreh- und Angelpunkt jeder EU AI Act Schulung sind deshalb zwei frühe Bausteine: Erstens die sauberen Definitionen aus Artikel 3 (KI‑System, Anbieter, Betreiber, Einführer, Händler), die das Scoping und die Zuständigkeiten festlegen. Zweitens Artikel 4 zur KI‑Kompetenz: Er verpflichtet Anbieter und Betreiber, geeignete Maßnahmen für ein ausreichendes Kompetenzniveau zu treffen – kontextbezogen, rollenspezifisch und nachvollziehbar dokumentiert. Dieser Leitfaden zeigt, wie sich die Verordnung didaktisch in klare Module, Lernziele und Prüf‑/Nachweiskriterien übersetzen lässt und wo typische Fallstricke liegen. Eine vertiefende Einführung bietet unsere EU AI Act Schulung.

Artikel 3 zuerst: Begriffe, die Scoping und RACI bestimmen

Die Definition des KI‑Systems erfasst maschinengestützte Systeme mit unterschiedlichem Autonomiegrad, die Eingaben in Ausgaben wie Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen überführen – einschließlich generativer Modelle. Aus Trainingssicht sind zwei Punkte zentral: der Autonomiegrad (z.B. Entscheidungsunterstützung vs. automatisierte Entscheidung) und die Anpassungsfähigkeit nach Inbetriebnahme (Fine‑Tuning, laufendes Lernen). Beides beeinflusst die Risikobetrachtung und damit Tiefe und Fokus der Schulung.

Die Rollen sind der zweite Grundpfeiler: Anbieter verantworten Entwicklung, Inverkehrbringen und – je nach Setup – die Inbetriebnahme unter eigenem Namen. Betreiber sind diejenigen, die das System im eigenen Verantwortungsbereich verwenden. Einführer und Händler agieren in der Lieferkette und müssen Konformität, Kennzeichnung und Unterlagen prüfen. Trainings beginnen idealerweise mit einem Rollen‑Check: In welchem Szenario ist die Organisation Anbieter? Wann Betreiber? Liegt bei Drittlandssoftware eine Einführerrolle vor? Diese Klärung bestimmt die RACI‑Matrix und die Zielgruppen der Module.

Artikel 4 KI‑Kompetenz: Anforderungen, Stufen, Nachweise

Artikel 4 verlangt Maßnahmen, um „nach besten Kräften“ ein ausreichendes Kompetenzniveau sicherzustellen – für Personal und beauftragte Dritte, die mit Betrieb oder Nutzung befasst sind. Das ist risikoklassenunabhängig und betrifft damit Grundlagenschulungen für breite Zielgruppen ebenso wie vertiefende Formate für Spezialrollen. Gute Programme staffeln Kompetenzen entlang des Einsatzkontexts: Basiswissen für alle Nutzenden; vertiefte Pflichtenkenntnis für Betreiber (z.B. richtige Zweckbindung, Vorfallmeldungen, menschliche Aufsicht); technische und regulatorische Tiefe für Anbieter (z.B. Datenqualität, Risikomanagement, Transparenz, Robustheit).

Nachweise sollten pragmatisch, aber belastbar sein: dokumentierte Curricula, Teilnahmelisten, Lernziel‑Mapping auf Rollen, kurze Wissenschecks, Protokolle aus Use‑Case‑Reviews oder Incident‑Simulationen. Wichtig ist die Kontextbezug‑Dokumentation: Welche Systeme, welche betroffenen Personen, welche Risiken? So werden Trainings in Audits anschlussfähig.

Modulare EU‑AI‑Act‑Schulung: Aufbau und Lernziele

Eine didaktische Übersetzung der Verordnung funktioniert entlang ihrer Struktur. Bewährt haben sich acht Bausteine: (1) Art. 1–4: Zweck, Geltung, Begriffe, KI‑Kompetenz; (2) Art. 5: verbotene Praktiken („Red‑Flags“); (3) Art. 6–7 i.V.m. Anhang III: Hochrisiko‑Einstufung und Use‑Case‑Klassifikation; (4) Art. 8–15: materielle Anforderungen (Risikomanagement, Daten, Dokumentation, Logging, Transparenz, menschliche Aufsicht, Robustheit); (5) Art. 16–27: Pflichten der Marktakteure, inkl. Betreiberpflichten und FRIA; (6) Art. 43–50: Konformitätsbewertung, EU‑Konformitätserklärung, CE, Registrierung; (7) Art. 51–56: GPAI‑Modelle und systemische Risiken; (8) Governance, Marktüberwachung und Sanktionen.

• Beispiel‑Lernziele: „Rolle und Pflichten korrekt bestimmen“, „Hochrisiko‑Einstufung für einen Use‑Case vornehmen“, „Minimale Doku‑ und Logging‑Anforderungen benennen“, „Transparenzhinweise für Nutzergruppen formulieren“, „Konformitätspfad erläutern“.
• Formate und Dauer: kurze Grundlagenbausteine, vertiefende Halbtages‑/Tagesmodule und rollenspezifische Workshops; für technische Teams zusätzlich Hands‑on‑Einheiten zu Daten, Tests und Logs – siehe auch Schulungen für IT‑Teams.

Praxis: Prüfungen, Session‑Pläne, Fehler vermeiden, Metriken

Prüfungsformen sollten dem Risiko folgen: kompakte Online‑Checks für Basismodule; Fallbearbeitungen, Use‑Case‑Reviews oder Incident‑Drills für Betreiber; Mini‑Audits und Artefakt‑Reviews (Risikoregister, Daten‑Spezifikationen, Testprotokolle) für Anbieter. Beispiel‑Sessions: ein Einführungsblock zu Art. 1–4; ein „Red‑Flag“-Workshop zu Art. 5 mit Branchenfällen; ein Deep‑Dive zu Art. 8–15 mit Arbeitsblättern für Risiko, Daten und Logging; ein Konformitäts‑Block zu Art. 43–50 mit Checklisten für Release‑Gates.

Typische Fehler: fehlender KI‑System‑Katalog; unklare Rollen (insbesondere bei Fine‑Tuning oder White‑Label‑Modellen); Trainings ohne Bezug zur Risikoklasse; Fokus nur auf IT, während Fachbereiche und Management außen vor bleiben. Sinnvolle Metriken verbinden Output und Outcome: Teilnahmequoten, Qualität der Use‑Case‑Klassifikation, Vollständigkeit von FRIA, Korrektheit von Transparenzhinweisen, Meldedisziplin bei Vorfällen, Wiederauffälligkeiten in Audits sowie Aktualität der Richtlinien. Entscheidend ist die Rückkopplung: Erkenntnisse aus Vorfällen und Audits müssen in die Curricula zurückfließen.

Fazit: Wer Begriffe und Rollen früh klärt, KI‑Kompetenz risikobasiert staffelt und Trainings mit konkreten Pflichten aus der Verordnung verknüpft, schafft eine tragfähige Compliance‑Basis – und erhöht zugleich die Qualität von Entwicklung, Betrieb und Governance.