Lernziele
Sie erklären den Unterschied zwischen Provider-Pflichten und Deployer-Pflichten nach EU AI Act und ordnen Ihre Organisation korrekt als Deployer ein.
Sie benennen die sechs Deployer-Pflichten nach Art. 26 EU AI Act und ordnen jede Pflicht einem konkreten Umsetzungsschritt zu.
Sie erstellen eine Vorlage für ein KI-Systemverzeichnis (analog zum DSGVO-Verarbeitungsverzeichnis nach Art. 30) für einen konkreten Use-Case.
Sie erklären den Zeitplan der EU-AI-Act-Umsetzungspflichten (2024–2026) und wissen, welche Pflichten bereits gelten.
Sie klassifizieren einen gegebenen KI-Use-Case als Hochrisiko oder Nicht-Hochrisiko.
Auf einen Blick
| Dauer | 45 Min |
| Methodik | Input + Fallarbeit (Dokumentationscheckliste ausfüllen) |
| Vorwissen | EU AI Act Grundlagen (Modul 2 UE 23), DSGVO-Grundlagen |
| AI-Act-Kompetenz | Anwendungskompetenz — zwingend förderrelevant (Art. 26 Deployer-Pflichten + Art. 4 KI-Kompetenz-Pflicht) |
| Querverweise | UE 100 (Datenklassifizierung), UE 102 (Vendor Assessment), UE 104 (Monitoring), UE 107 (KI-Beauftragter) |
Worum geht es?
Im August 2024 ist der EU AI Act in Kraft getreten. Seit dem 2. Februar 2025 gilt Artikel 4 — die Pflicht zur Sicherstellung von KI-Kompetenz bei Mitarbeitenden. Diese Schulung ist die direkte Antwort darauf. Aber Art. 4 ist nicht die einzige Pflicht, die Organisationen als KI-Betreiber trifft.
Der EU AI Act unterscheidet klar zwischen denen, die KI-Systeme entwickeln und vermarkten (Provider) — das sind OpenAI, Microsoft, Google — und denen, die KI-Systeme in einem eigenen professionellen Kontext einsetzen (Deployer). In fast allen relevanten Szenarien des Unternehmensalltags sind Organisationen Deployer.
Als Deployer trägt Ihre Organisation spezifische Verantwortung — unabhängig davon, ob das eingesetzte KI-System ein Hochrisikosystem ist oder nicht. Diese Lerneinheit macht diese Pflichten konkret und greifbar: Was muss dokumentiert werden? Bis wann? Durch wen?
Zentrales Werkzeug ist das KI-Systemverzeichnis — das Analogon zum DSGVO-Verarbeitungsverzeichnis nach Art. 30. Es ist das Herzstück der KI-Governance und bündelt alle Informationen, die für Compliance, Audit und laufenden Betrieb benötigt werden.
Lerntext — Theorie und Konzepte
Grundstruktur: Wer ist wer im EU AI Act?
Der EU AI Act definiert verschiedene Rollen in der KI-Wertschöpfungskette:
Provider (Anbieter): Entwickelt ein KI-System und bringt es in den Verkehr oder in Betrieb. Beispiele: OpenAI, Microsoft, Anthropic, ein Software-Unternehmen, das ein KI-gestütztes HR-Tool entwickelt.
Deployer (Betreiber): Setzt ein KI-System im eigenen beruflichen Kontext ein. Wenn Ihre Organisation ChatGPT, Microsoft 365 Copilot oder einen eigenen KI-Assistenten für Mitarbeitende oder Kunden nutzt, ist sie Deployer.
Importer / Distributor: Weitere Rollen, für die meisten Organisationen weniger relevant.
Wichtig: Bei selbst entwickelten KI-Systemen — etwa einem selbst programmierten Assistenten auf Basis einer OpenAI-API — übernehmen Organisationen auch Provider-Pflichten, wenn das System extern eingesetzt wird. Für interne Systeme bleibt die Organisation primär Deployer.
Merksatz
„Provider = entwickelt und vermarktet.” „Deployer = setzt ein und betreibt.” In fast allen Alltagsszenarien ist die eigene Organisation Deployer — das bedeutet Pflichten nach Art. 26, unabhängig von der Risikokategorie.
Geltungsbereich: Welche Systeme unterliegen dem EU AI Act vollständig?
Der EU AI Act gilt in vollem Umfang für Hochrisiko-KI-Systeme (Art. 6, Anhang III). Für die meisten internen KI-Assistenten, Produktivitäts-Tools und Automatisierungen in Organisationen gilt die Kategorie „geringes Risiko” oder „minimales Risiko” — was schlankere Pflichten bedeutet.
Hochrisiko wird ein System, wenn es:
Für Personalentscheidungen eingesetzt wird (Recruiting, Leistungsbewertung — Anhang III, Ziffer 4)
Für Kreditbewertungen oder Bonitätsprüfungen verwendet wird (Anhang III, Ziffer 5)
In kritischer Infrastruktur eingesetzt wird
Für die Bewertung von Schülerinnen und Schülern genutzt wird
Kritisch: Ein KI-gestützter Recruiting-Screener, der Lebensläufe bewertet und Empfehlungen für Einstellungsentscheidungen gibt, ist nach Anhang III Ziffer 4 ein Hochrisikosystem — mit deutlich erweiterten Dokumentationspflichten.

Abb. 105.1 — EU AI Act Dokumentationspflichten für Deployer (Art. 26): Die sechs Pflichtbereiche im Überblick
Die sechs Deployer-Pflichten nach Art. 26 EU AI Act
Pflicht 1: Geeignete technische und organisatorische Maßnahmen (Art. 26 Abs. 1)
Was dokumentiert werden muss: Welche TOMs sind für jeden KI-System-Einsatz implementiert? Das umfasst die Maßnahmen aus UE 98 (Guardrails, Filter), UE 100 (Datenklassifizierung) und UE 101 (Hosting-Wahl).
Dokumentationsform: KI-Systemverzeichnis mit einer Spalte für TOMs pro System.
Pflicht 2: Menschliche Aufsicht sicherstellen (Art. 26 Abs. 2)
Was dokumentiert werden muss: Wer hat die Human-in-the-Loop-Verantwortung für jeden KI-gestützten Prozess? Welche Entscheidungen trifft die KI eigenständig — welche müssen von einem Menschen bestätigt werden?
Dokumentationsform: Prozessübersicht KI-Einsatz mit benannten Verantwortlichen (Name + Funktion).
Pflicht 3: Nutzungsprotokoll und Logging (Art. 26 Abs. 5 — für Hochrisiko-Systeme Pflicht)
Für Hochrisikosysteme: Vollständige Protokollierung der KI-Nutzung. Für Nicht-Hochrisiko: Keine gesetzliche Pflicht, aber dringend empfohlen — ohne Logs ist ein strukturierter Incident Response (UE 106) nicht möglich.
Pflicht 4: Information betroffener Personen (Art. 26 Abs. 3)
Wenn KI-Entscheidungen oder KI-gestützte Empfehlungen Menschen betreffen: Information der betroffenen Personen, dass KI eingesetzt wird.
Praxis-Beispiel: Wenn Bewerbende durch einen KI-Assistenten vorgeschlagen werden, müssen diese informiert werden, dass KI im Auswahlprozess eingesetzt wird.
Dokumentationsform: Aktualisierte Datenschutzerklärung mit KI-Transparenzhinweis.
Pflicht 5: Meldepflicht bei schwerwiegenden Vorfällen (Art. 26 Abs. 5)
Bei schwerwiegenden Vorfällen mit Hochrisiko-Systemen: Meldung an die zuständige Marktaufsichtsbehörde. Was dokumentiert werden muss: Incident-Response-Prozess (UE 106), Kontaktdaten der Marktaufsichtsbehörde.
Pflicht 6: KI-Kompetenz der Mitarbeitenden sicherstellen (Art. 4)
Was dokumentiert werden muss: Nachweise über durchgeführte KI-Schulungen — Teilnahmelisten, Schulungsinhalte, Prüfungsergebnisse.
Praxishinweis: Diese Schulung ist das direkte Instrument zur Erfüllung von Art. 4. Die Teilnahme und der Abschluss sollte dokumentiert werden und als Nachweis der Art.-4-Compliance verfügbar sein.
Merksatz
Art. 4 gilt seit dem 2. Februar 2025. Diese Schulung ist der direkte Compliance-Nachweis. Teilnahmelisten sorgfältig aufbewahren — sie sind das Dokument, das bei einer Behördenanfrage vorgelegt werden kann.
Das KI-Systemverzeichnis — das zentrale Dokumentationsinstrument
Empfohlen wird ein schlichtes KI-Systemverzeichnis (analog zum DSGVO-Verarbeitungsverzeichnis nach Art. 30):
| Feld | Inhalt (Beispiel) |
| System-Name | Angebots-Assistent v1 |
| Einsatzzweck | Unterstützung bei der Erstellung von Kundenprojekt-Angeboten |
| Risikokategorie EU AI Act | Minimal |
| Anbieter | OpenAI (ChatGPT API) |
| Datenkategorien | Kundennamen, Projektdetails (intern/vertraulich) |
| Verantwortliche Person | KI-Beauftragte:r (Name + Funktion) |
| TOMs | Verweis auf Dokument TOM-KI-001 |
| AVV vorhanden | Ja — OpenAI DPA, Version 2024-09 |
| Human-in-the-Loop | Projektleiter:in prüft und genehmigt vor Versand |
| Letzte Überprüfung | Datum der letzten Bewertung |
Zeitplan der EU AI Act Umsetzungspflichten
| Datum | Pflicht |
| August 2024 | EU AI Act in Kraft getreten |
| Februar 2025 | Art. 4 gilt — KI-Kompetenz-Pflicht für Deployer |
| August 2025 | Verbote für inakzeptables Risiko (Art. 5) |
| August 2026 | Vollständige Hochrisiko-Pflichten (Art. 6–15) |
| August 2027 | Übergangsfrist für vor August 2026 auf dem Markt befindliche Systeme |
Vertiefung — Dokumentationstiefe nach Risikokategorie
Minimale Dokumentation für Nicht-Hochrisiko-Systeme
Für die meisten internen KI-Assistenten — Angebots-Assistent, Wissens-RAG, Meeting-Zusammenfassung — reicht eine schlanke Dokumentation:
Eine Zeile im KI-Systemverzeichnis (10 Felder, ausgefüllt in 30 Minuten)
Ein AVV-Nachweis des Anbieters (aus dem Vendor Assessment, UE 102)
Eine Notiz zur Hosting-Entscheidung (aus UE 101)
Ein Verweis auf den Monitoring-Plan (aus UE 104)
Schulungsnachweise dieser Schulung (Art.-4-Compliance)
Das sind fünf Dokumente oder Verweise — kein Bürokratie-Mammut. Wer sie vollständig hat, kann einer Behördenanfrage gelassen entgegensehen.
Vollständige Dokumentation für Hochrisiko-Systeme
Für einen Recruiting-Screener (Hochrisiko nach Anhang III Ziffer 4) ist der Umfang erheblich größer:
Vollständiges Risikomanagement-System nach Art. 9
Technische Dokumentation nach Art. 11 (Systemarchitektur, Trainingsdaten-Informationen)
Protokollierungsplan nach Art. 12
Transparenzdokumentation nach Art. 13 (Bewerber:innen-Information)
Human-Oversight-Nachweis nach Art. 14 (Prozessdokumentation)
Datenschutz-Folgenabschätzung nach DSGVO Art. 35
Registrierung in EU-Datenbank nach Art. 71 (wenn öffentlich zugänglich)
Gesamtaufwand initial: 20–40 Stunden, häufig mit externem Rechtsbeistand. Jährlicher Pflegeaufwand: ~10 Stunden. Diese Aufwandsschätzung sollte bei der Entscheidung für oder gegen einen Hochrisiko-Use-Case von Anfang an berücksichtigt werden.
Die Datenschutz-Folgenabschätzung (DSFA) als KI-Governance-Instrument
Die DSGVO enthält in Art. 35 ein Instrument, das für KI-Systeme zunehmend relevant wird: die Datenschutz-Folgenabschätzung (DSFA). Eine DSFA ist vorgeschrieben, wenn eine Verarbeitung „voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen” mit sich bringt:
Systematische und umfangreiche Bewertung von Personen (einschließlich Profiling) → Recruiting-KI
Verarbeitung besonderer Kategorien personenbezogener Daten in großem Umfang → Gesundheits-KI
Systematische Überwachung öffentlich zugänglicher Bereiche → Videoanalyse-KI
Eine DSFA umfasst: (1) Beschreibung der Verarbeitung und ihrer Zwecke, (2) Bewertung der Notwendigkeit und Verhältnismäßigkeit, (3) Bewertung der Risiken für betroffene Personen, (4) geplante Maßnahmen zur Risikominimierung.
Das Risiko-Assessment aus UE 108 ist inhaltlich eng verwandt mit einer DSFA — es fehlen primär die datenschutzrechtlichen Formalanforderungen. Wer das Assessment aus UE 108 dokumentiert hat, besitzt eine gute Grundlage für eine anschließende DSFA.
Zusammenspiel von EU AI Act, DSGVO und ISO 42001
In der Praxis überlappen die Dokumentationsanforderungen aus drei Regelwerken. Eine Zusammenführung vermeidet Doppelarbeit:
| Anforderung | EU AI Act | DSGVO | ISO 42001 |
| Systemverzeichnis / Register | Art. 49 (Hochrisiko) | Art. 30 (Verarbeitungsverzeichnis) | Kl. 8 (KI-Systemkatalog) |
| Risikoanalyse | Art. 9 (Risikomanagementsystem) | Art. 35 (DSFA) | Kl. 6.1 (Risikobewertung) |
| Technische Dokumentation | Art. 11 + Anhang IV | — | Kl. 8.4 |
| Logging und Nachvollziehbarkeit | Art. 12 | Art. 5 (Rechenschaftspflicht) | Kl. 9.1 |
| Schulungsnachweise | Art. 4 (AI Literacy) | Art. 32 (Schulung als TOMs) | Kl. 7.2 |
Empfehlung: Erstellen Sie ein einziges, integriertes „KI-Systemblatt” je Use-Case, das alle drei Anforderungssätze in einer Vorlage abdeckt. Das spart Zeit und erleichtert Audits erheblich.
Das KI-Systemverzeichnis als lebendiges Dokument
Das KI-Systemverzeichnis ist nur nützlich, wenn es aktuell gehalten wird. Typische Auslöser für eine Aktualisierung:
Einführung eines neuen KI-Systems (neue Zeile anlegen)
Update des Anbieters oder der Modellversion (Zeile aktualisieren)
Änderung der Datenkategorien oder des Einsatzzwecks
Abschluss oder Verlängerung eines AVV
Ergebnis eines Vendor Re-Assessments
Incident mit dem System (Incident-Verweis eintragen)
Empfohlene Governance-Regel: Die KI-Beauftragten prüfen das Verzeichnis monatlich auf Aktualität und stellen sicher, dass alle Einträge das Datum der letzten Überprüfung tragen. Ein Eintrag ohne Review-Datum ist ein Signal für einen unvollständigen Governance-Prozess.
Verbindung zu anderen Governance-Dokumenten
Das KI-Systemverzeichnis ist das Herzstück der KI-Governance-Dokumentation — aber es steht nicht allein:
KI-Nutzungsrichtlinie (UE 99): Definiert, was erlaubt ist. Das Systemverzeichnis dokumentiert, was tatsächlich eingesetzt wird.
Vendor-Assessment-Reports (UE 102): Ergänzen das Systemverzeichnis mit Details zu jedem Anbieter.
Incident-Reports (UE 106): Verweisen auf das Systemverzeichnis und umgekehrt.
Schulungsnachweise (Art.-4-Compliance): Werden im Systemverzeichnis verlinkt.
Risiko-Assessments (UE 108): Fließen als Risikokategorie in das Systemverzeichnis ein.
Diese Verzahnung aller Dokumente schafft ein konsistentes Governance-Bild, das bei einer Behördenprüfung überzeugend und vollständig wirkt.
Branchen-Anwendungen
IT-Dienstleistung & Beratung
IT-Dienstleistungsunternehmen befinden sich in einer doppelten Rolle: Sie sind Deployer eigener interner KI-Systeme und gleichzeitig Berater und Implementierungspartner für Kunden, die KI einführen. Das KI-Systemverzeichnis muss diese doppelte Rolle widerspiegeln.
Vignette: Ein IT-Beratungsunternehmen führt für drei Kunden KI-Systeme ein. Das interne KI-Systemverzeichnis enthält sowohl die eigenen internen Systeme als auch die im Kundenauftrag betriebenen Systeme — mit klarer Markierung, welches System für welchen Mandanten läuft. Die Vendor-Assessment-Reports (UE 102) sind als Anhänge verknüpft. Wenn ein Kunde bei einem Audit die KI-Compliance des Dienstleisters prüft, kann das vollständige Verzeichnis vorgelegt werden — ein Wettbewerbsvorteil gegenüber Wettbewerbern ohne Dokumentationssystem.
Industrie & Fertigung
In Fertigungsunternehmen werden KI-Systeme zunehmend für Predictive Maintenance, Qualitätskontrolle und Produktionsplanung eingesetzt. Diese Use-Cases betreffen häufig kritische Infrastruktur oder haben direkte Sicherheitsimplikationen — was die Dokumentationsanforderungen erhöht.
Vignette: Ein Maschinenbauunternehmen führt ein KI-System für die automatische Qualitätskontrolle an der Produktionslinie ein. Das KI-Systemblatt wird sorgfältig ausgefüllt: Risikokategorie wird nach eingehender Analyse als „gering” eingestuft (kein Anhang-III-Tatbestand, aber sicherheitsrelevanter Kontext). Ein Human-in-the-Loop-Prozess wird dokumentiert: Auffälligkeiten werden von einer Fachkraft bestätigt, bevor ein Produktionsstopp ausgelöst wird. Das dokumentierte Human-in-the-Loop-Protokoll schützt das Unternehmen im Fall eines Fehlers — die Entscheidungsverantwortung liegt nachweislich beim Menschen.
Finanzdienstleistung & Versicherung
Im Finanzsektor unterliegen KI-Systeme besonders strenger Aufsicht. Viele Use-Cases (Kreditscoring, Risikobewertung, Betrugserkennung) fallen unter Hochrisiko nach Anhang III. Die Dokumentation ist hier nicht nur EU-AI-Act-Pflicht, sondern auch Teil der BaFin-Aufsicht und des DORA-Reporting.
Vignette: Eine Versicherungsgesellschaft evaluiert den Einsatz eines KI-Systems für die automatische Erstbewertung von Schadenmeldungen. Die Rechtsabteilung stuft das System als Hochrisiko ein (Anhang III Ziffer 5: Bewertung von Kreditwürdigkeit und finanzieller Risikobeurteilung). Die vollständige Hochrisiko-Dokumentation wird aufgebaut — darunter ein technisches Dokumentationspaket nach Art. 11, ein Logging-Konzept nach Art. 12 und eine DSFA nach DSGVO Art. 35. Der Aufbau dauert drei Monate und kostet durch externe Rechtsberatung etwa 15.000 EUR. Die Entscheidung: Der Use-Case ist wirtschaftlich attraktiv genug — aber ohne diesen Vorlauf wäre er nicht compliance-konform umsetzbar gewesen.
Öffentliche Verwaltung
Behörden sind oft sowohl Deployer als auch regulatorisch verantwortliche Stellen. Sie müssen nicht nur die EU-AI-Act-Anforderungen erfüllen, sondern auch die spezifischen Anforderungen des Verwaltungsrechts (Begründungspflicht, Gleichbehandlungsgebot, Transparenzprinzip).
Vignette: Eine kommunale Verwaltung führt ein KI-System zur Unterstützung bei der Bearbeitung von Baugenehmigungen ein. Das KI-Systemblatt enthält einen ausführlichen Human-in-the-Loop-Eintrag: Das System gibt Empfehlungen, die Entscheidung trifft ausschließlich der zuständige Sachbearbeiter. Der Entscheidungsbrief an den Antragsteller enthält keinen KI-spezifischen Hinweis — die Entscheidung ist eine Behördenentscheidung. Die Verwaltung dokumentiert intern, dass KI die Bearbeitung unterstützt hat, ohne dieses Detail nach außen zu kommunizieren (rechtlich zulässig, da die KI-Empfehlung menschlich überprüft und bestätigt wurde).
Warnung — Sicherheitsrisiken
OWASP LLM Top 10 — Relevanz für Dokumentation:
LLM06 — Sensitive Information Disclosure in Dokumenten: KI-Systemverzeichnisse und technische Dokumentationsunterlagen enthalten sensible Informationen über die KI-Infrastruktur einer Organisation (welche Modelle, welche Daten, welche Schwachstellen wurden identifiziert). Diese Dokumente müssen mit angemessenen Zugriffsrechten versehen werden — nicht als öffentlich zugängliche Dokumente auf einem geteilten Laufwerk.
Dokumentation als Angriffsziel: Ein Angreifer, der Zugang zum KI-Systemverzeichnis erhält, bekommt eine vollständige Karte der KI-Infrastruktur — einschließlich Schwachstellen und Sicherheitsmaßnahmen. Zugriffsberechtigungen nach dem Need-to-know-Prinzip umsetzen.
Prompt Injection in Governance-Prozessen: Wenn KI-Tools selbst für das Erstellen oder Pflegen von Dokumentation eingesetzt werden (z. B. ein KI-Assistent, der Compliance-Formulare ausfüllt), besteht das Risiko, dass manipulierte Eingaben zu fehlerhafter oder irreführender Dokumentation führen. Menschliche Prüfung aller KI-generierten Governance-Dokumente ist Pflicht.
Handlungsprinzip: Governance-Dokumente sind schutzwürdige Unternehmensressourcen. Sie profitieren von denselben Schutzmaßnahmen wie andere vertrauliche Unternehmensdokumente — Zugriffsrechte, Versionierung, gesicherte Ablage.
Übung 1 — KI-Systemverzeichnis für einen Use-Case ausfüllen
Aufgabe: Sie befüllen eine Zeile des KI-Systemverzeichnisses für den Use-Case „Interner Wissensassistent” (RAG auf internen Dokumenten).
Material: KI-Systemverzeichnis-Template (Tabelle oben), Stift oder Laptop.
Schritt-für-Schritt:
Bestimmen Sie die EU AI Act Risikokategorie für einen RAG-basierten internen Wissensassistenten.
Füllen Sie alle Felder des KI-Systemverzeichnisses aus.
Identifizieren Sie: Welche Felder sind für diesen Use-Case am kritischsten?
Definieren Sie, wer die verantwortliche Person sein sollte — und welche Funktion sie hat.
Notieren Sie: Welche TOMs wurden aus den vorigen UEs für dieses System bereits implementiert?
Zeitrahmen: 12 Minuten Einzelarbeit
Musterlösung Übung 1:
| Feld | Inhalt |
| System-Name | Interner Wissens-Assistent v1 |
| Einsatzzweck | Antworten auf Mitarbeitenden-Fragen zu internen Prozessen und Projekten |
| Risikokategorie | Minimal (kein Anhang III, keine Entscheidungen über Personen) |
| Anbieter | OpenAI API |
| Datenkategorien | Interne Dokumente (Stufe 2), ggf. Projektdokumente (Stufe 3) |
| Verantwortliche Person | KI-Beauftragte:r |
| TOMs | Systemanweisungs-Härtung, Input-Filter, Access Control, Logging |
| AVV vorhanden | Ja — OpenAI DPA |
| Human-in-the-Loop | Keine finalen Entscheidungen — reine Informationsauskunft |
| Letzte Überprüfung | [Datum einzutragen] |
Übung 2 — Hochrisiko-Klassifizierung
Aufgabe: Sie analysieren vier Use-Cases und bestimmen jeweils die EU AI Act Risikokategorie.
Schritt-für-Schritt:
Lesen Sie die vier Use-Cases.
Prüfen Sie: Trifft einer der Hochrisiko-Tatbestände aus Anhang III zu?
Ordnen Sie jeden Use-Case zu: Minimal / Gering / Hoch.
Begründen Sie Ihre Klassifizierung in einem Satz.
Diskutieren Sie: Welche Use-Cases sind Grenzfälle?
Use-Cases: (A) KI fasst interne Besprechungsprotokolle zusammen. (B) KI bewertet Bewerbungsunterlagen und erstellt eine Rangfolge. (C) KI unterstützt beim Verfassen von Kundenangeboten. (D) KI analysiert Mitarbeiter-Performance-Daten und erstellt Bewertungsvorschläge für Jahresgespräche.
Zeitrahmen: 10 Minuten Gruppenarbeit (2–3 Personen), 5 Minuten Plenum
Musterlösung Übung 2:
| Use-Case | Kategorie | Begründung |
| A — Protokoll-Zusammenfassung | Minimal | Kein Anhang-III-Tatbestand, keine Entscheidungen über Personen |
| B — Bewerbungsbewertung | Hoch | Anhang III Ziffer 4: KI-gestützte Personalentscheidungen |
| C — Angebotserstellung | Minimal | Keine Entscheidungen über Personen, kein kritischer Bereich |
| D — Performance-Analyse | Hoch | Anhang III Ziffer 4: KI beeinflusst Entscheidungen über Mitarbeitende |
Cheat-Sheet — Dokumentationspflichten Kurzreferenz
Rollen: - Provider = entwickelt und vermarktet KI - Deployer = setzt ein und betreibt KI (das ist fast immer die eigene Organisation)
Art. 4 gilt seit Februar 2025 — Schulungsnachweis ist Compliance-Pflicht
Hochrisiko-Auslöser (Anhang III): - Personalentscheidungen (Recruiting, Leistungsbewertung) - Kreditbewertung / Bonitätsprüfung - Kritische Infrastruktur
Sechs Deployer-Pflichten (Art. 26): 1. TOMs dokumentieren 2. Menschliche Aufsicht sicherstellen 3. Nutzungsprotokoll (Hochrisiko: Pflicht) 4. Betroffene informieren (wenn relevant) 5. Vorfälle melden (Hochrisiko: Pflicht) 6. KI-Kompetenz nachweisen (Art. 4)
KI-Systemverzeichnis: Jedes KI-System = eine Zeile. Monatlich aktuell halten.
Ab August 2026: Vollständige Hochrisiko-Pflichten — jetzt mit Aufbau beginnen.
Dokumentationsaufwand: Minimal-Risiko ~2h | Hochrisiko ~20–40h
Prompt-Vorlage — KI-Systemkarte nach EU AI Act Anforderungen erstellen
Prompt für einen KI-Assistenten:
„Ich muss für unseren internen KI-Assistenten eine Systemdokumentation gemäß den Anforderungen des EU AI Act erstellen. Das System ist ein RAG-basierter Assistent für die Vertriebsunterstützung — er hilft Mitarbeitenden, Angebotsvorlagen zu erstellen und Projektinformationen zu recherchieren. Er wurde als ‚minimales Risiko’ eingestuft, da er nur interne Nutzer hat und keine Entscheidungen über Personen trifft.
Erstelle eine vollständige KI-Systemkarte (KI-System-Steckbrief) mit folgenden Pflichtfeldern:
Systemidentifikation: Name, Version, Verantwortliche Person, Datum der letzten Überprüfung
Systembeschreibung: Zweck, Funktionsweise, eingesetzte Basismodelle, Datenquellen
Risikoeinstufung: EU AI Act Kategorie mit Begründung (Verboten / Hochrisiko / GPAI / Minimales Risiko)
Datenschutz-Folgenabschätzung: Welche personenbezogenen Daten werden verarbeitet? Liegt eine DSFA vor?
Technische Sicherheitsmaßnahmen: Input-Filter, Guardrails, Zugriffskontrolle, Logging
Organisatorische Maßnahmen: Schulungsnachweis (Art. 4 AI Act), Verantwortliche, Nutzungsrichtlinie
Monitoring & Review: Wie wird das System überwacht? Wann findet die nächste Überprüfung statt?
Vorfalls-Protokoll: Referenz auf das Incident-Response-Playbook
Formatiere als Steckbrief-Vorlage (Tabelle oder strukturiertes Dokument), das direkt befüllt werden kann.”
Erwartetes Ergebnis: Eine vollständige, EU AI Act-konforme Systemkarte als Vorlage — einsatzbereit für das interne KI-Register und als Nachweis gegenüber Aufsichtsbehörden.
Reflexionsfragen
Ihre Organisation kauft ein fertiges KI-Tool eines anderen Unternehmens. Trägt sie Provider- oder Deployer-Pflichten — oder beides?
Wie begründen Sie gegenüber der Geschäftsführung den Aufwand für ein KI-Systemverzeichnis, wenn viele Systeme noch Minimal-Risiko sind?
Ein Mitarbeitender nutzt einen Consumer-KI-Dienst ohne Wissen der IT für eine Aufgabe, die Personaldaten enthält. Welche EU AI Act Pflicht könnte verletzt worden sein?
Warum ist es strategisch sinnvoll, das KI-Systemverzeichnis zu führen, auch bevor es für alle Systeme gesetzlich verpflichtend ist?
Welche konkreten Dokumente müsste Ihre Organisation bei einer Prüfung durch die Marktaufsichtsbehörde nach aktuellem Stand (2025) vorlegen können?
Inwiefern unterscheidet sich die DSFA nach DSGVO Art. 35 vom Risiko-Assessment (UE 108) — und wo überschneiden sie sich?
Quellen & Weiterlesen
| Quelle | Typ | URL |
| EU AI Act — vollständiger Text (EUR-Lex) | Rechtstext | https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32024R1689 |
| Europäisches KI-Büro — Leitlinien zu Deployer-Pflichten | Leitfaden | https://digital-strategy.ec.europa.eu/de/policies/european-approach-artificial-intelligence |
| Bitkom — EU AI Act Kompass für Unternehmen | Praxisleitfaden | https://www.bitkom.org/Bitkom/Publikationen/Umsetzungsleitfaden-zur-KI-Verordnung |
| ISO 42001 — AI Management System Standard | Norm | https://www.iso.org/standard/81230.html |
| Forum Privatheit — EU AI Act und Datenschutz | Positionierung | https://www.forum-privatheit.de/ |
| BSI — KI-Sicherheitsempfehlungen für Deployer | Leitfaden | https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche_Intelligenz/kuenstliche-intelligenz_node.html |
| DSGVO Art. 35 — Datenschutz-Folgenabschätzung (EUR-Lex) | Rechtstext | https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679#d1e3265-1-1 |
Hinweise für AI Champions — So vermitteln Sie das Thema
Timing: 45 Min — Empfohlene Aufteilung: 15 Min Input (Rollen, Risikokategorien, sechs Pflichten), 20 Min Übungen (Übung 1 oder 2 je nach Gruppe), 10 Min Auswertung und Diskussion.
Methodische Empfehlung: Der Einstieg über Art. 4 und den Bezug zu dieser Schulung ist wirkungsvoll — die Teilnehmenden befinden sich gerade in der Compliance-Maßnahme, die Art. 4 erfordert. Diese direkte Verbindung („Diese Schulung ist Ihr Compliance-Nachweis”) schafft Relevanz. Dann den Bogen schlagen zu den anderen fünf Deployer-Pflichten.
Stolpersteine: - Verwirrung über Provider vs. Deployer: Die Faustregel hilft — „Haben Sie das KI-Modell selbst trainiert und vermarkten Sie es? Dann Provider. Nein? Dann Deployer.” - „August 2026 ist noch weit weg”: Darauf eingehen, dass der Aufbau des KI-Systemverzeichnisses jetzt sinnvoll ist — nicht erst kurz vor der Deadline. Jedes heute eingeführte System, das jetzt dokumentiert wird, spart Aufwand im Jahr 2026. - Überschätzung des Aufwands: Die Minimal-Risiko-Dokumentation mit 2 Stunden initialem Aufwand ist für viele überraschend gering. Das Rechenbeispiel (5 Dokumente/Verweise, 30 Min. je Zeile im Verzeichnis) hilft, Hemmschwellen abzubauen.
Diskussionsfragen: 1. Welche KI-Systeme in Ihrer Organisation sind aktuell nicht dokumentiert — und welche davon sind potenziell Hochrisiko? 2. Wer sollte in Ihrer Organisation Eigentümer des KI-Systemverzeichnisses sein? 3. Wie verhalten Sie sich, wenn die Geschäftsführung die Dokumentation als unnötigen Bürokratieaufwand ablehnt?
Tafelbild:
EU AI ACT — ROLLEN UND PFLICHTEN
PROVIDER DEPLOYER (= wir)
OpenAI, Microsoft, ... Eigene Organisation
Art. 9–15 (Hochrisiko) Art. 26 — Sechs Pflichten:
Art. 11 Techn. Doku. 1. TOMs
Art. 12 Logging 2. Human Oversight
Art. 13 Transparenz 3. Logging (HR: Pflicht)
4. Betroffene informieren
5. Vorfälle melden
6. Art. 4 Kompetenz
KI-SYSTEMVERZEICHNIS
= eine Zeile pro System
= lebendiges Dokument
Differenzierung Power-User ↔ Einsteiger: - Einsteiger: Fokus auf Risikokategorisierung und KI-Systemverzeichnis-Konzept; Übung 1 (Verzeichnis ausfüllen) ist sehr praxisnah. - Power-User: Vertiefen mit DSFA-Parallelen, ISO-42001-Integration und dem vollständigen Hochrisiko-Dokumentationspfad; Diskussion über Compliance-Strategie für 2026.
Materialliste: - KI-Systemverzeichnis-Template (Tabelle, druckbar oder digital) - EU AI Act Anhang III (Hochrisiko-Liste) als Handout
Übergang zur nächsten UE: UE 106 behandelt Incident Response — was passiert, wenn etwas schiefläuft. Brückenformulierung: „Wir wissen jetzt, was dokumentiert sein muss. UE 106 zeigt, was zu tun ist, wenn trotz aller Dokumentation und Maßnahmen ein Incident eintritt — und wie dieser Incident selbst dokumentiert und gehandhabt wird.”
Tipp zur Branchenauswahl: Für Finanzgruppen: DORA-Reporting-Anforderungen als zusätzliche Dokumentationspflicht einführen. Für Industriegruppen: Betonung der Human-in-the-Loop-Dokumentation bei sicherheitskritischen Systemen. Für Verwaltungsgruppen: Begründungspflicht in Verwaltungsakten als Parallele zur KI-Transparenzpflicht erklären.
Vertiefung II — Praxis der EU AI Act Compliance: Typische Stolperfallen und wie man sie vermeidet
Stolperfalle 1: Das Provider-Deployer-Missverständnis bei hybriden Systemen
In der Praxis ist die Rollenabgrenzung zwischen Provider und Deployer nicht immer eindeutig — und genau hier entstehen gefährliche Compliance-Lücken. Ein häufiges Beispiel: Ein Unternehmen entwickelt auf Basis der OpenAI-API einen internen Wissensassistenten und stellt diesen auch Partnerunternehmen zur Verfügung. In diesem Szenario ist das Unternehmen gleichzeitig Deployer (für den internen Einsatz) und Provider (gegenüber den Partnerunternehmen). Diese doppelte Rolle verdoppelt die Pflichten — und wird in der Praxis häufig übersehen.
Konkrete Konsequenz: Als Provider gegenüber den Partnern treffen das Unternehmen potenziell Provider-Pflichten nach Art. 13 (Transparenzpflichten) und Art. 14 (Human Oversight) für ein System, das als „internes Tool" begann. Die Lösung ist eine klare dokumentierte Rollenentscheidung: Entweder wird der Einsatz bei Partnern als Deployer-zu-Deployer-Weitergabe mit AVV gestaltet — oder das Unternehmen akzeptiert bewusst die Provider-Pflichten und richtet die Dokumentation entsprechend aus.
Empfehlung: Wenn ein intern entwickeltes KI-System auch nur an einem anderen Unternehmen eingesetzt wird, ist die Provider-Frage zwingend rechtlich zu klären. Diese Klärung gehört ins KI-Systemverzeichnis.
Stolperfalle 2: Veraltete AVVs nach Modell-Updates
Ein AVV (Auftragsverarbeitungsvertrag) mit einem KI-Anbieter beschreibt eine spezifische Verarbeitungssituation — welche Daten, zu welchem Zweck, mit welchen Sicherheitsmaßnahmen. Wenn ein KI-Anbieter ein Modell-Update durchführt, können sich diese Parameter ändern: Das neue Modell verarbeitet Daten möglicherweise mit anderen Mechanismen, speichert möglicherweise länger oder kürzer, oder hat geänderte Sicherheitszertifikate.
In der Praxis werden AVVs oft einmalig beim Vertragsabschluss geprüft und danach nicht mehr aktualisiert. Nach einem Modell-Update von OpenAI, Microsoft oder einem anderen Anbieter kann der bestehende AVV inhaltlich überholt sein — ohne dass dies jemand bemerkt.
Governance-Empfehlung: Das KI-Systemverzeichnis enthält das Datum des aktuell gültigen AVV und ein Ablaufdatum (oder „nächste Prüfung"-Datum). Jedes Mal, wenn ein Anbieter eine wesentliche Systemänderung ankündigt (Release Notes, Changelog), wird der AVV-Status geprüft. Die KI-Beauftragten sind für diese Prüfung verantwortlich.
Stolperfalle 3: Schulungsnachweise als formales Dokument vs. gelebte Kompetenz
Art. 4 EU AI Act verlangt die Sicherstellung von KI-Kompetenz — nicht nur die Vorlage einer Teilnahmeliste. Die zuständige Aufsichtsbehörde kann fragen: „Wie stellen Sie sicher, dass die Mitarbeitenden nach der Schulung auch kompetent handeln?" Eine Teilnahmeliste allein beantwortet diese Frage nicht.
Empfehlung für eine robuste Art.-4-Dokumentation: 1. Teilnahmeliste mit Unterschriften (Nachweis der Teilnahme) 2. Kurzer Lernzieltest oder Reflexionsfragebogen am Schulungsende (Nachweis der Kompetenz) 3. Halbjährliche Auffrischung für kritische Nutzergruppen (Nachweis der Aktualität) 4. Dokumentierter Zusammenhang zwischen Schulungsinhalt und konkreten KI-Systemen im Einsatz (Nachweis der Relevanz)
Diese vier Elemente zusammen ergeben ein belastbares Compliance-Paket, das einer Behördenanfrage standhält.
Stolperfalle 4: Das Verzeichnis als statisches Dokument
Das häufigste Governance-Versagen in der Praxis: Das KI-Systemverzeichnis wird bei der Einführung sorgfältig erstellt und danach nie wieder aktualisiert. Nach sechs Monaten spiegelt es nicht mehr den tatsächlichen Stand der KI-Nutzung wider — neue Systeme wurden eingeführt, andere abgeschaltet, Anbieter haben Updates durchgeführt.
Ein statisches Verzeichnis ist schlimmer als kein Verzeichnis: Es vermittelt den Eindruck von Governance, wo keine ist, und kann bei einer Prüfung mehr Fragen aufwerfen als es beantwortet.
Lösung: Das KI-Systemverzeichnis bekommt einen definierten Pflegeprozess — wer ist verantwortlich, wie oft wird geprüft, was sind die Auslöser für eine sofortige Aktualisierung. Dieser Prozess wird selbst dokumentiert (eine Zeile im Governance-Handbuch) und ist Teil des monatlichen KI-Status-Reports.
Merksatz
Ein veraltetes KI-Systemverzeichnis ist bei einer Behördenprüfung möglicherweise schädlicher als gar kein Verzeichnis. Dokumentation muss gelebt werden — eine monatliche Überprüfung mit klarer Verantwortlichkeit ist die Mindestanforderung.
Internationale Perspektive: EU AI Act vs. US Executive Order vs. UK AI Governance
Europäische Organisationen, die auch in anderen Märkten tätig sind, müssen parallele Governance-Anforderungen berücksichtigen:
| Rahmen | Geltungsbereich | Dokumentationsansatz | Compliance-Tiefe |
| EU AI Act | Europäischer Wirtschaftsraum | Risikobasiert, verpflichtend | Hoch (Hochrisiko) bis niedrig (Minimal) |
| US Executive Order 14110 (2023) | USA / Bundesbehörden | Berichts- und Testpflichten für Frontier-Modelle | Derzeit auf Großanbieter fokussiert |
| UK Pro-Innovation AI Regulation | Großbritannien | Sektorbasiert, keine neuen Pflichtgesetze | Freiwillig, sektorale Behörden entscheiden |
| China AI Regulation | China | Registrierungspflicht für generative KI-Dienste | Hoch für auf dem Markt tätige Provider |
Für internationale Organisationen empfiehlt sich eine Dokumentationsarchitektur, die den strengsten Anforderungen (EU AI Act für den europäischen Markt) als Grundlage dient und für andere Märkte mit modularen Ergänzungen ausgebaut wird. Das spart Doppelarbeit.
ISO 42001: Der neue Standard für KI-Management-Systeme
Seit seiner Veröffentlichung im Dezember 2023 gewinnt ISO 42001 — der internationale Standard für KI-Management-Systeme — zunehmend an Bedeutung. Ähnlich wie ISO 27001 für Informationssicherheit bietet ISO 42001 einen zertifizierbaren Rahmen für das Management von KI in Organisationen.
Kernelemente von ISO 42001: - Kontextanalyse: Was ist der Einsatzzweck von KI in der Organisation? - Risikobewertung und -behandlung für KI-Systeme - Ziele und Maßnahmen für verantwortungsvolle KI - Interne Audits und Management-Review - Kontinuierliche Verbesserung
Verhältnis zu EU AI Act: ISO 42001 ist kein Ersatz für die rechtliche EU-AI-Act-Compliance — aber wer ISO 42001 zertifiziert ist, hat die meisten strukturellen Anforderungen des EU AI Act (Risikoanalyse, Dokumentation, Monitoring) bereits erfüllt. Die Zertifizierung kann bei Behördenanfragen als starkes Compliance-Signal fungieren.
Wer sollte ISO 42001 anstreben? Für KMU unter 150 Mitarbeitenden ist eine vollständige Zertifizierung oft unverhältnismäßig. Aber die ISO-42001-Struktur als Orientierungsrahmen — ohne formale Zertifizierung — ist für jede Organisation empfehlenswert. Der Standard ist öffentlich zugänglich und bietet eine gut strukturierte Checkliste für KI-Governance-Reife.
Vertiefung II — Strategische Ebene — Praktische Umsetzung: Das KI-Governance-Paket für eine Behördenprüfung
Was muss bei einer Behördenanfrage vorgelegt werden können?
Im Jahr 2025 kann eine Anfrage der zuständigen Datenschutzaufsichtsbehörde oder Marktaufsichtsbehörde eintreffen. Diese Anfrage könnte lauten: „Welche KI-Systeme setzen Sie ein, und wie stellen Sie die Einhaltung der EU-AI-Act-Anforderungen sicher?"
Ein vollständiges Antwortpaket für eine Nicht-Hochrisiko-Organisation umfasst:
Dokument 1 — KI-Systemverzeichnis (aktuell): Alle eingesetzten KI-Systeme mit Risikokategorie, Anbieter, Datenkategorien, Verantwortlichen und Human-in-the-Loop-Status. Letzte Überprüfung: nicht älter als 30 Tage.
Dokument 2 — Art.-4-Compliance-Nachweis: Schulungsdokumentation (Teilnahmelisten, Schulungsinhalt, Datum, Kurzbewertung der Lernziele). Diese Schulung ist das direkte Nachweisdokument.
Dokument 3 — KI-Nutzungsrichtlinie (Version und Datum): Die geltende Nutzungsrichtlinie mit Versionsnummer und Freigabedatum.
Dokument 4 — Vendor Assessment Summary: Für jeden Hauptanbieter: AVV-Status, Sicherheitszertifikate, Hosting-Region.
Dokument 5 — Incident-Register: Alle aufgetretenen KI-Vorfälle — auch wenn es keine gab: „Keine meldepflichtigen Vorfälle im Berichtszeitraum."
Diese fünf Dokumente bilden ein vollständiges Compliance-Paket für Nicht-Hochrisiko-Systeme. Bei Hochrisiko-Systemen erweitert sich das Paket um das vollständige Dokumentationspaket nach Art. 9–15.
Das Governance-Dokument-Paket: Aufwand und Pflege
Initiale Erstellung (Nicht-Hochrisiko, 3–5 KI-Systeme): - KI-Systemverzeichnis: 2–4 Stunden (einmalig) - Art.-4-Nachweis: Liegt nach dieser Schulung vor - Nutzungsrichtlinie: 4–8 Stunden (einmalig, aus UE 99) - Vendor Assessments: 2–4 Stunden pro Anbieter (einmalig, aus UE 102) - Incident-Register: Template einmalig einrichten, danach laufend pflegen
Gesamter initialer Aufwand: ca. 15–30 Stunden. Jährlicher Pflegeaufwand: ca. 8–12 Stunden.
Verhältnis zum potenziellen Bußgeld bei fehlendem Compliance-Nachweis: Der EU AI Act sieht bei Verstößen gegen Art. 26 Deployer-Pflichten Bußgelder von bis zu 15 Millionen EUR oder 3% des weltweiten Jahresumsatzes vor. 15–30 Stunden Compliance-Aufbau sind auch wirtschaftlich eine klare Investition.
Praxis-Checkliste: Art.-4-Compliance in drei Schritten sicherstellen
Viele Organisationen sind unsicher, ob ihre Schulungsmaßnahmen ausreichen, um Art. 4 EU AI Act zu erfüllen. Eine pragmatische Drei-Schritte-Prüfung:
Schritt 1 — Schulungsinhalt: Vermittelt die Schulung KI-Kompetenz im Sinne des Art. 4? Art. 4 verlangt Kenntnisse über die Fähigkeiten, Grenzen und Risiken von KI-Systemen — für die mit dem System arbeitenden Mitarbeitenden im Umfang, der für ihre Rolle relevant ist. Diese Schulung (Modul 9, 12 Lerneinheiten, 540 Min.) deckt alle wesentlichen Aspekte ab.
Schritt 2 — Zielgruppen-Differenzierung: Nicht alle Mitarbeitenden brauchen dieselbe Tiefe. Mitarbeitende, die KI-Systeme nur gelegentlich nutzen, benötigen Grundlagenwissen. KI-Beauftragte und Systemverantwortliche benötigen vertiefte Kompetenz. Diese Differenzierung sollte dokumentiert sein.
Schritt 3 — Nachweis-Kette: Teilnahmeliste + Inhaltsübersicht der Schulung + ggf. Lernzieltest = vollständige Art.-4-Nachweis-Kette. Diese Dokumente werden für mindestens drei Jahre aufbewahrt (analog zu anderen Compliance-Nachweisen).
Diese drei Schritte schaffen ein Compliance-Fundament, das einer behördlichen Überprüfung standhält.
Vertiefung IV — Schulungsnachweis nach Art. 4 EU AI Act: Diese Schulung als Compliance-Dokumentation
Art. 4 EU AI Act verpflichtet alle Deployer (Unternehmen, die KI-Systeme einsetzen) sicherzustellen, dass ihre Mitarbeitenden über ausreichende KI-Kompetenz verfügen — ›im Umfang, der für die jeweilige Rolle relevant ist‹. Diese Pflicht gilt seit dem 2. August 2025.
Was als Schulungsnachweis gilt:
Ein wirksamer Schulungsnachweis für Art. 4 muss drei Elemente enthalten: (1) Nachweis der Schulungsteilnahme (Anwesenheitsliste oder digitale Bestätigung), (2) Beschreibung des Schulungsinhalts mit Bezug zu KI-Fähigkeiten, Grenzen und Risiken sowie (3) Rollenbezug — wie die vermittelten Kompetenzen zur beruflichen Tätigkeit der teilnehmenden Person passen.
Diese Schulung als Art.-4-Nachweis:
Modul 9 (UE 97–108) deckt folgende Art. 4-relevante Kompetenzbereiche ab: Risikobewusstsein für KI-Systeme (UE 97–99), Datenschutz und Datensouveränität (UE 100–101), Anbieterbewertung und Qualitätssicherung (UE 102–103), Betriebsüberwachung und Dokumentationspflichten (UE 104–105) sowie Incident Response und Governance (UE 106–108). Die Schulung erfüllt damit alle inhaltlichen Anforderungen für Personen in technischen, beratenden und managementnahen Rollen.
Dokumentationsempfehlung: Erstellen Sie für jede teilnehmende Person ein Schulungs-Zertifikat mit: Name, Datum, Modulinhalte (Themenübersicht), Gesamtdauer (in Minuten), Unterschrift des Schulungsverantwortlichen. Dieses Dokument wird in die Personalakte aufgenommen und im KI-Systemregister als Schulungsnachweis für die jeweiligen KI-Deployer-Aktivitäten hinterlegt.
Jährliche Auffrischungspflicht: Art. 4 formuliert eine dynamische Kompetenzpflicht — KI entwickelt sich, und damit die Risikolandschaft. Planen Sie mindestens einmal jährlich eine Auffrischungsschulung ein, die aktuelle Entwicklungen (neue OWASP-Einträge, EU AI Act-Leitlinien, neue Angriffstypen) abdeckt.
Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.
Zurück zur Modul-Übersicht