Lernziele
- Sie können die neun Absätze von Art. 26 EU AI Act in eigenen Worten erläutern und die daraus resultierenden Pflichten für Ihre Organisation benennen.
- Sie verstehen den Unterschied zwischen Anbieter-Pflichten und Deployer-Pflichten und können die Verantwortungsverteilung in konkreten Einsatzszenarien bestimmen.
- Sie können eine 7-Schritte-Compliance-Roadmap für den Einsatz eines Hochrisiko-KI-Systems in Ihrer Organisation skizzieren.
- Sie sind in der Lage, ein Drei-Stufen-Freigabemodell (Grün / Gelb / Rot) für KI-Anwendungen in Ihrer Organisation zu beschreiben.
- Sie kennen die Dokumentationspflichten nach Art. 26 Abs. 6 und können beurteilen, welche Protokollierungsanforderungen für Ihre Organisation relevant sind.
Auf einen Blick
| Merkmal | Inhalt |
| UE-Nummer | 17 |
| Modul | Modul 2 — Recht, Ethik und EU AI Act |
| Dauer | 45 Minuten |
| Format | Seminar mit Übungen |
| Schwerpunkt | Deployer-Pflichten Art. 26, Compliance-Roadmap |
| Querverweise | UE 15 (AI Act Aufbau), UE 16 (Risikoklassen), UE 18 (AI Literacy), UE 23 (Betriebsvereinbarung) |
Worum geht es? — Der didaktische Einstieg
Art. 26 EU AI Act ist das operative Herzstück der Deployer-Compliance. Während UE 15 den Zeitplan und UE 16 die Risikoklassen behandelt, fragt UE 17: Was müssen Unternehmen konkret tun, wenn sie ein Hochrisiko-KI-System einsetzen? Die Antwort ist vielschichtig und betrifft Bereiche, die bisher selten mit KI verbunden wurden: Arbeitnehmerrechte, Grundrechte, technische Dokumentation, menschliche Aufsicht und Mitarbeiterschulung.
Besonders wichtig ist das Verständnis der Deployer-Rolle. Deployer sind Unternehmen, die ein KI-System einsetzen, das von einem anderen Anbieter (Provider) bereitgestellt wird. Die meisten mittelständischen Unternehmen sind Deployer — nicht Anbieter. Damit tragen sie Pflichten, die erheblich weiter gehen als das bloße Vertragsabschließen mit einem KI-Anbieter. Wer ein Hochrisiko-KI-System einsetzt, muss aktiv sicherstellen, dass die Anforderungen des AI Act erfüllt werden — nicht nur darauf vertrauen, dass der Anbieter das schon regelt.
Diese UE vermittelt das notwendige Wissen, um aus Deployer-Perspektive handlungsfähig zu sein.
Lerntext — Theorie und Konzepte

Abb. 17.1 — Art. 26 EU AI Act: Acht Deployer-Pflichten im Überblick
Art. 26 EU AI Act im Überblick
Art. 26 EU AI Act enthält neun Absätze, die unterschiedliche Pflichten für Deployer von Hochrisiko-KI-Systemen regeln. Zusammenfassend lassen sich diese Pflichten in sieben thematische Bereiche gruppieren:
1. Nutzung gemäß Bedienungsanleitung (Abs. 1): Deployer müssen das KI-System gemäß der Gebrauchsanweisung des Anbieters einsetzen. Klingt simpel — ist es in der Praxis nicht. Gebrauchsanweisungen für KI-Systeme können komplex sein und erfordern technisches Verständnis. Abweichungen vom vorgesehenen Einsatzbereich (Out-of-Scope) machen den Deployer mitverantwortlich für entstehende Schäden.
2. Menschliche Aufsicht (Abs. 1 i.V.m. Art. 14): Bei Hochrisiko-Systemen muss sichergestellt werden, dass menschliche Aufsicht möglich und tatsächlich vorhanden ist. Das bedeutet: Es muss eine qualifizierte Person geben, die die Ergebnisse des Systems versteht, hinterfragen kann und im Zweifel eingreift. Rubber-Stamping — das blinde Bestätigen von KI-Empfehlungen — erfüllt diese Anforderung nicht.
3. Schutz vor Missbrauch und unbefugtem Zugriff (Abs. 2): Deployer müssen technische und organisatorische Maßnahmen ergreifen, um das KI-System vor Missbrauch, unbefugtem Zugriff und Manipulation zu schützen. Das überschneidet sich erheblich mit DSGVO-Anforderungen nach Art. 32.
4. Grundrechtefolgenabschätzung (Abs. 3 / Art. 27): Deployer, die öffentliche Einrichtungen sind oder bestimmte Anwendungsbereiche nutzen (z. B. Bildung, kritische Infrastruktur, Beschäftigung), müssen vor dem Einsatz eine Grundrechtefolgenabschätzung durchführen. Diese prüft, welche Grundrechte durch den KI-Einsatz potenziell beeinträchtigt werden und welche Maßnahmen zur Risikominderung ergriffen werden.
5. Protokollierung und Aufzeichnung (Abs. 6): Deployer müssen Protokolle über den Betrieb des KI-Systems führen und aufbewahren. Die Protokollierungspflicht ermöglicht es, im Nachhinein zu rekonstruieren, wie das System zu einer Entscheidung gelangt ist — wichtig für Audit, Haftungsfragen und regulatorische Prüfungen.
6. Information der betroffenen Personen (Abs. 9 i.V.m. Art. 50): Wenn KI-Systeme Entscheidungen über natürliche Personen treffen oder vorbereiten, müssen betroffene Personen informiert werden. Diese Pflicht überlappt mit Art. 22 DSGVO (automatisierte Einzelentscheidungen).
7. Meldung von Vorfällen und schwerwiegenden Ereignissen (Abs. 5): Deployer müssen schwerwiegende Vorfälle — also Situationen, in denen das KI-System Schäden verursacht oder verursacht haben könnte — an den Anbieter und ggf. an die Marktüberwachungsbehörde melden.
8. Schulung der Mitarbeitenden (Abs. 5 + Art. 4): Deployer müssen sicherstellen, dass Mitarbeitende, die mit dem KI-System arbeiten, ausreichend geschult sind. Diese Schulungsmaßnahme ist der Nachweis, dass die Organisation dieser Pflicht nachkommt. Dokumentation ist Pflicht.
9. Zusammenarbeit mit dem Anbieter (Abs. 7): Im Falle von Nichtkonformitäten oder Sicherheitsvorfällen müssen Deployer mit dem Anbieter kooperieren und dessen Anweisungen zur Fehlerbehebung befolgen.
Merksatz
Deployer sind nicht passive Nutzer — sie sind aktive Compliance-Verantwortliche. Wer ein Hochrisiko-KI-System einsetzt, übernimmt damit regulatorische Pflichten, die über einen einfachen Softwarevertrag weit hinausgehen.
Anbieter vs. Deployer — Die Verantwortungsverteilung
Ein häufiges Missverständnis: Wenn der Anbieter alle Anforderungen des AI Act erfüllt hat (Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation), ist der Deployer automatisch compliant. Das stimmt nicht.
Die Pflichten sind komplementär:
| Anbieter-Pflichten (Art. 16 ff.) | Deployer-Pflichten (Art. 26) |
| Konformitätsbewertung | Nutzung gemäß Anweisung |
| Technische Dokumentation | Menschliche Aufsicht sicherstellen |
| CE-Kennzeichnung | Grundrechtefolgenabschätzung (wenn anwendbar) |
| EU-Konformitätserklärung | Protokollierung des Betriebs |
| Registrierung in EU-Datenbank | Schulung der Mitarbeitenden |
| Gebrauchsanweisung erstellen | Vorfallmeldung |
Wichtig: Wenn ein Deployer das KI-System zweckentfremdet oder für einen Bereich einsetzt, der nicht in der Gebrauchsanweisung vorgesehen ist, wird der Deployer zum Anbieter mit allen entsprechenden Pflichten (Art. 25).
Merksatz
Zweckentfremdung eines KI-Systems macht den Deployer zum Anbieter. Wer ein für Bereich A zertifiziertes System in Bereich B einsetzt, trägt alle Anbieter-Pflichten für diesen Einsatz.
Das Drei-Stufen-Freigabemodell (Grün / Gelb / Rot)
Eine praxiserprobte Methode zur internen Governance von KI-Anwendungen ist das Drei-Stufen-Freigabemodell. Es klassifiziert KI-Anwendungen nach Risiko und legt fest, welche Genehmigungsschritte erforderlich sind:
Grün — Freie Nutzung: Anwendungen in dieser Kategorie sind ohne besondere Genehmigung nutzbar. Typisch: öffentlich verfügbare KI-Tools für nicht-kritische Aufgaben, keine personenbezogenen Daten, kein Hochrisiko-Kontext. Beispiel: Nutzung eines KI-Übersetzungstools für Pressetexte.
Gelb — Nutzung mit Einschränkungen: Anwendungen in dieser Kategorie erfordern eine Prüfung und ggf. organisatorische Maßnahmen vor der Nutzung. Typisch: Tools, die personenbezogene Daten verarbeiten könnten, Tools in sensiblen Arbeitsbereichen, Tools mit unklarer Risikoklasse. Beispiel: Nutzung eines LLM-Tools für interne Analysen, die ggf. Kundendaten berühren.
Rot — Gesperrte Anwendungen: Anwendungen in dieser Kategorie sind ohne ausdrückliche Genehmigung durch Compliance, Datenschutz und ggf. Betriebsrat nicht nutzbar. Typisch: Hochrisiko-KI-Systeme, Tools, die vertrauliche Daten verarbeiten, Tools ohne klare Datenschutzgrundlage. Beispiel: Ein KI-System zur automatischen Bewerbungsanalyse ohne durchgeführte Grundrechtefolgenabschätzung.
7-Schritte Compliance-Roadmap für Deployer
Wenn Ihre Organisation ein neues Hochrisiko-KI-System einführen möchte, empfiehlt sich folgendes strukturiertes Vorgehen:
Schritt 1 — Identifikation: Handelt es sich um ein Hochrisiko-System nach Anhang III? Nutzung der Vier-Fragen-Prüfheuristik aus UE 16.
Schritt 2 — Anbieter-Dokumentation prüfen: Existiert eine Konformitätsbewertung, CE-Kennzeichnung und vollständige technische Dokumentation seitens des Anbieters? Ohne diese Dokumente darf das System in der EU nicht eingesetzt werden.
Schritt 3 — Grundrechtefolgenabschätzung: Ist eine Grundrechtefolgenabschätzung nach Art. 27 erforderlich? Wenn ja: durchführen und dokumentieren.
Schritt 4 — DSGVO-Prüfung: Gleichzeitig DSGVO-Konformität sicherstellen: Rechtsgrundlage, DPIA wenn erforderlich, AVV mit Anbieter.
Schritt 5 — Menschliche Aufsicht konfigurieren: Klären, wer im Unternehmen die menschliche Aufsicht ausübt, wie Eskalationswege aussehen und wie Eingriffsmöglichkeiten technisch sichergestellt sind.
Schritt 6 — Schulung: Alle Mitarbeitenden, die das System nutzen, müssen geschult werden. Schulungsnachweis dokumentieren.
Schritt 7 — Protokollierung aktivieren: Sicherstellen, dass die Protokollierungsfunktionen des Systems aktiviert sind und Protokolle für die gesetzlich erforderliche Dauer aufbewahrt werden.
Vertiefung — Menschliche Aufsicht in der Praxis
Was „menschliche Aufsicht” wirklich bedeutet
Das Konzept der menschlichen Aufsicht ist zentral im EU AI Act — aber in der Praxis oft missverständlich. Art. 14 EU AI Act definiert, dass Hochrisiko-KI-Systeme so konzipiert und entwickelt sein müssen, dass sie von natürlichen Personen wirksam beaufsichtigt werden können. Für Deployer bedeutet das:
Verstehen: Die Aufsichtsperson muss die Funktionsweise des Systems grundlegend verstehen — was es tut, wie es entscheidet, welche Faktoren es berücksichtigt. Sie muss nicht die zugrundeliegenden Algorithmen kennen, aber sie muss die Ergebnisse interpretieren können.
Hinterfragen: Die Aufsichtsperson muss die Fähigkeit haben, Ergebnisse zu hinterfragen — und sich nicht aus Bequemlichkeit oder Zeitdruck auf die KI-Ausgabe zu verlassen.
Eingreifen: Wenn die Aufsichtsperson ein Problem erkennt, muss sie eingreifen können — entweder durch Überschreiben des KI-Ergebnisses, durch Eskalation oder durch Abschalten des Systems.
Stop-Taste: Das System muss technisch so ausgestattet sein, dass ein Mensch den Betrieb unterbrechen oder stoppen kann (sog. „Human Override”).
Was ausdrücklich nicht genügt: Das bloße „Bestätigen” von KI-Ergebnissen ohne inhaltliche Prüfung. Wenn eine Führungskraft täglich 200 KI-generierte Empfehlungen in 10 Minuten „abhakt”, ist das keine menschliche Aufsicht im Sinne des Art. 14 — auch wenn formell ein Mensch beteiligt ist.
Organisatorische Umsetzung
Die Implementierung echter menschlicher Aufsicht erfordert organisatorische Entscheidungen:
- Wie viel Zeit hat die Aufsichtsperson pro KI-Entscheidung realistisch?
- Ist die Aufsichtsperson ausreichend qualifiziert, um das System zu verstehen?
- Gibt es klare Eskalationswege, wenn Zweifel an KI-Ergebnissen bestehen?
- Werden Fälle, in denen die KI-Empfehlung überstimmt wurde, dokumentiert?
Empfehlung: Definieren Sie für jedes Hochrisiko-KI-System einen „AI Supervisor” — eine benannte Person, die für die menschliche Aufsicht verantwortlich ist, die entsprechende Schulung erhalten hat und die Eskalationswege kennt.
Branchen-Anwendungen
IT-Dienstleistung & Beratung
IT-Dienstleistungsunternehmen, die KI-Systeme für Kunden implementieren, tragen oft eine Doppelrolle: Sie sind Deployer bei der eigenen Nutzung und helfen Kunden bei der Deployer-Compliance. Für interne Tools (z. B. KI-gestützte Projektmanagement-Systeme mit Ressourcenallokation) gelten Art.-26-Pflichten direkt. Nach außen: Beratungsmandate sollten standardmäßig eine AI-Act-Compliance-Prüfung umfassen. Checkliste für Kundenmandate: Welche KI-Tools setzt der Kunde ein? Welche Risikoklasse? Ist Art. 26 erfüllt?
Industrie & Fertigung
Industrieunternehmen, die Hochrisiko-KI in der Qualitätskontrolle oder im Produktionsprozess einsetzen, müssen sicherstellen, dass Maschinenführer und Qualitätsverantwortliche die menschliche Aufsichtsfunktion tatsächlich ausüben können. Herausforderung: Produktionsumgebungen sind schnell — die KI entscheidet in Millisekunden, der Mensch hat kaum Zeit zur Prüfung. Lösung: Flagging-Systeme, die nur kritische Entscheidungen zur menschlichen Prüfung vorlegen, statt den gesamten Output zu überwachen.
Finanzdienstleistung & Versicherung
Im Finanzsektor trifft Art. 26 auf bereits bestehende regulatorische Anforderungen (BaFin, EBA, EIOPA). Deployer müssen die Anforderungen des AI Act mit bestehenden MaRisk- und DORA-Pflichten verzahnen. Empfehlung: Ein gemeinsames Compliance-Framework entwickeln, das AI-Act-Pflichten, DSGVO und sektorspezifische Regulierung in einem einheitlichen Prozess abbildet. Insbesondere die Grundrechtefolgenabschätzung (Art. 27) sollte in bestehende Due-Diligence-Prozesse integriert werden.
Öffentliche Verwaltung
Behörden als Deployer stehen vor besonderen Herausforderungen: Grundrechtefolgenabschätzungen sind für sie nahezu immer verpflichtend (Art. 27). Die Anforderungen an menschliche Aufsicht sind in bürokratischen Prozessen oft schwerer umzusetzen als in privatwirtschaftlichen Umgebungen. Zusätzlich gelten öffentliche Ausschreibungsregeln für die Beschaffung von KI-Systemen. Empfehlung: Frühzeitig Datenschutzbehörden und Beauftragte einbinden, bevor ein KI-System eingeführt wird.
Übung 1 — Art.-26-Analyse
Die Sieben-Schritte Compliance-Roadmap im Detail
Die 7-Schritte-Roadmap für Art.-26-Compliance ermöglicht eine systematische Herangehensweise:
Schritt 1 — Systemkatalog: Erstellen Sie einen vollständigen Katalog aller eingesetzten KI-Systeme. Viele Organisationen unterschätzen, wie viele KI-Systeme sie bereits nutzen — Cloud-basierte HR-Software mit KI-Funktionen, automatisierte E-Mail-Klassifizierung, KI-gestützte Kundenservice-Tools, etc. Der Katalog ist die Grundlage für alles Weitere.
Schritt 2 — Risikoklassifizierung: Ordnen Sie jedem System im Katalog eine Risikoklasse zu (Verboten / Hochrisiko / Begrenzt / Minimal). Nutzen Sie die Vier-Fragen-Prüfheuristik aus UE 16. Dokumentieren Sie die Begründung für die gewählte Klassifizierung.
Schritt 3 — Priorisierung: Konzentrieren Sie die Compliance-Ressourcen auf Hochrisiko-Systeme. Für minimal riskante Systeme reicht eine kurze Dokumentation der Klassifizierungsbegründung.
Schritt 4 — Anbieter-Dokumentation: Fordern Sie von den Anbietern Ihrer Hochrisiko-Systeme die erforderliche technische Dokumentation an (Art. 11 AI Act). Prüfen Sie, ob eine Konformitätserklärung vorliegt (Art. 47) und ob das System ordnungsgemäß in der EU-Datenbank für Hochrisiko-KI registriert ist (Art. 71).
Schritt 5 — Human-in-the-Loop: Implementieren Sie für alle Hochrisiko-Systeme klare Verfahren zur menschlichen Aufsicht (Art. 14). Definieren Sie: Wer ist verantwortlich? In welchen Situationen muss menschliche Aufsicht aktiv eingreifen? Wie wird dies dokumentiert?
Schritt 6 — Mitarbeiterschulung: Stellen Sie sicher, dass alle Mitarbeitenden, die Hochrisiko-Systeme einsetzen, eine angemessene AI Literacy-Schulung erhalten haben (Art. 26 Abs. 5 in Verbindung mit Art. 4). Diese Schulungsmaßnahme dokumentiert die Erfüllung dieser Pflicht.
Schritt 7 — Laufende Überwachung: Richten Sie ein System zur laufenden Überwachung (Post-Market Monitoring) ein. Wenn das System unerwartetes Verhalten zeigt oder neue Risiken auftreten, müssen Deployer den Anbieter informieren (Art. 26 Abs. 7) und ggf. die Nutzung aussetzen.
Merksatz
Art. 26 EU AI Act stellt keine akademischen Anforderungen — er verlangt gelebte Compliance. Für jeden Schritt der 7-Schritte-Roadmap sollte eine dokumentierte Nachweisführung existieren: Katalog, Klassifizierungsbegründung, Schulungsnachweise, Überwachungsberichte.
Unterschied zwischen Anbieter und Deployer — Praxisfälle
In der Praxis ist die Abgrenzung zwischen Anbieter und Deployer oft komplex:
Fall 1 — Standardsoftware mit KI: Ein Unternehmen kauft eine HR-Software, die KI-gestützte Bewerbungsauswahl enthält (z. B. SAP SuccessFactors mit KI-Add-on). Das Unternehmen ist Deployer; SAP ist Anbieter. Das Unternehmen muss die Art.-26-Pflichten erfüllen, kann aber auf die Compliance-Dokumentation von SAP zurückgreifen.
Fall 2 — Eigenentwicklung auf API-Basis: Ein Unternehmen entwickelt eine eigene HR-Anwendung auf Basis der OpenAI API. In diesem Fall ist das Unternehmen selbst Anbieter (und gleichzeitig Deployer) — es muss sowohl Anbieter- als auch Deployer-Pflichten erfüllen, einschließlich technischer Dokumentation und Konformitätsbewertung.
Fall 3 — Fine-Tuning eines Basismodells: Ein Unternehmen nimmt ein Open-Source-Basismodell und fine-tuned es für einen spezifischen Hochrisiko-Anwendungsfall (z. B. automatisierte Kreditentscheidungen). Dieses Unternehmen wird zum Anbieter des resultierenden Systems — auch wenn es das Basismodell nicht selbst trainiert hat.
Diese Unterscheidungen sind wichtig, weil sie bestimmen, welche Pflichten in welchem Umfang gelten.
Aufzeichnungspflichten und Dokumentation
Art. 26 Abs. 6 verpflichtet Deployer, Aufzeichnungen über den Betrieb ihrer Hochrisiko-KI-Systeme zu führen. Diese Aufzeichnungen umfassen: Datum und Dauer der Nutzung, die verarbeiteten Eingabedaten (soweit verfügbar), Ausgaben des Systems, und besondere Vorkommnisse oder Anomalien.
In der Praxis bedeutet dies: Organisationen müssen Logging-Infrastruktur für KI-Systeme aufbauen. Manche Cloud-KI-Dienste bieten native Logging-Funktionen an — diese müssen jedoch so konfiguriert werden, dass sie die AI-Act-Anforderungen erfüllen und gleichzeitig DSGVO-konform sind (Speicherbegrenzung, Zweckbindung).
Vertragliche Absicherung gegenüber KI-Anbietern
Art. 26 AI Act enthält Anforderungen, die Deployer nur mithilfe der Anbieter erfüllen können. Es ist daher essenziell, diese Anforderungen vertraglich zu verankern:
Technische Dokumentation (Art. 11): Der Anbieter muss dem Deployer die technische Dokumentation des Hochrisiko-Systems zur Verfügung stellen. Dies sollte im Vertrag oder AVV explizit geregelt sein.
Gebrauchsanleitung (Art. 13): Der Anbieter muss dem Deployer eine klare Gebrauchsanleitung zur Verfügung stellen, die die bestimmungsgemäße Nutzung des Systems beschreibt.
Informationspflicht bei Änderungen: Wenn der Anbieter das System wesentlich ändert (was die Konformitätsbewertung berühren könnte), muss er den Deployer informieren. Dies muss vertraglich geregelt sein.
SLA für Sicherheitsvorfälle: Bei einem Sicherheitsvorfall oder einer schwerwiegenden Fehlfunktion des Systems muss der Anbieter den Deployer unverzüglich informieren (Art. 26 Abs. 7 erlaubt Deployers die Weiterleitung an Behörden). Ein klarer SLA (Service Level Agreement) für die Incidentkommunikation ist daher wichtig.
Audit-Rechte: Der Deployer sollte das Recht haben, die Compliance des Anbieters zu prüfen — direkt oder über Drittprüfer. Bei großen Cloud-Anbietern geschieht dies oft über standardisierte Audit-Reports (ISO 27001, SOC 2).
KI-Governance-Rollen — Wer ist wofür verantwortlich?
Art. 26 benennt den Deployer als Verantwortlichen — aber in der Organisation müssen klare Rollen verteilt sein:
Chief AI Officer (CAIO) oder KI-Verantwortliche/r: Gesamtverantwortung für die KI-Strategie und -Compliance. Koordiniert zwischen Fachabteilungen, IT, Legal und HR. Berichtet direkt an Geschäftsführung. In Deutschland noch nicht weit verbreitet, aber zunehmend als Rolle etabliert.
Datenschutzbeauftragte/r (DSB): Verantwortlich für DSGVO-Compliance aller KI-Systeme, die personenbezogene Daten verarbeiten. Muss in alle KI-Projekte einbezogen werden.
IT-Security: Verantwortlich für die technischen Sicherheitsmaßnahmen (Art. 32 DSGVO, Art. 15 AI Act — Cybersicherheit).
Legal/Compliance: Prüfung der vertraglichen Grundlagen (AVV, Anbieterverträge), Überwachung der regulatorischen Entwicklungen.
Betriebsrat/Personalrat: Mitbestimmungsrechte nach BetrVG (→ UE 23). Frühzeitige Einbindung verhindert spätere Blockaden.
Fachabteilung: Versteht den Anwendungsfall am besten. Verantwortlich für die inhaltliche Validierung der KI-Outputs und die menschliche Aufsicht im laufenden Betrieb.
Merksatz
Art.-26-Compliance ist eine Teamaufgabe — sie kann nicht allein von der IT oder allein von Legal geleistet werden. Erfolgreiche KI-Governance braucht klare Rollen, klare Verantwortlichkeiten und klare Kommunikationswege zwischen den beteiligten Funktionen.
Übung 1 — Art.-26-Analyse: Wer ist verantwortlich?
Ausgangslage: Ein mittelständisches Logistikunternehmen (50 MA) setzt ein KI-System zur automatischen Routenoptimierung und Fahrerzuweisung ein. Das System stammt von einem Anbieter, der eine CE-Kennzeichnung und technische Dokumentation bereitstellt. Das System berücksichtigt auch Fahrerperformance-Daten und beeinflusst, welcher Fahrer welche Route bekommt.
Aufgabe: Identifizieren Sie alle Art.-26-Pflichten, die für das Logistikunternehmen als Deployer entstehen. Welche dieser Pflichten sind wahrscheinlich schon erfüllt, welche noch nicht?
Bearbeitungszeit: 15 Minuten, Partnerarbeit.
Musterlösung:
Pflichten und Status: - Nutzung gemäß Anweisung (Abs. 1): Zu prüfen — nutzt das Unternehmen das System wirklich nur für den vorgesehenen Zweck? - Menschliche Aufsicht (Abs. 1): Wahrscheinlich unzureichend — wer prüft die Fahrerzuweisungen inhaltlich? - Schutz vor Missbrauch (Abs. 2): IT-Sicherheitsmaßnahmen sollten vorhanden sein — prüfen. - Grundrechtefolgenabschätzung (Abs. 3 / Art. 27): Da Fahrerleistungsdaten genutzt werden und Beschäftigte betroffen sind (Anhang III Nr. 4) — wahrscheinlich erforderlich, aber vermutlich noch nicht durchgeführt. - Protokollierung (Abs. 6): Prüfen, ob Protokollierungsfunktionen aktiviert sind. - Betroffene informieren (Abs. 9): Fahrer müssen wissen, dass KI bei der Routenzuweisung beteiligt ist — wahrscheinlich noch nicht kommuniziert. - Schulung der Disponenten (Art. 4): Sind die Disponenten, die das System bedienen, ausreichend geschult? - Betriebsrat einbinden: §87 BetrVG (Leistungsüberwachung) wahrscheinlich relevant — BV erforderlich.
Übung 2 — Compliance-Roadmap erstellen
Übung 2 — Compliance-Roadmap für ein KI-System
Aufgabe: Wählen Sie ein KI-System, das in Ihrer Organisation eingesetzt wird oder eingesetzt werden könnte (oder nutzen Sie das Beispiel aus Übung 1). Erstellen Sie eine 7-Schritte-Compliance-Roadmap für dieses System, inkl. konkreter Zuständigkeiten und Zeitplan.
Nutzen Sie folgendes Template: | Schritt | Maßnahme | Zuständig | Bis wann | |—|—|—|—| | 1 | Risikoklassen-Identifikation | | | | 2 | Anbieter-Dokumentation prüfen | | | | 3 | Grundrechtefolgenabschätzung | | | | 4 | DSGVO-Prüfung | | | | 5 | Menschliche Aufsicht konfigurieren | | | | 6 | Schulungsnachweis dokumentieren | | | | 7 | Protokollierung aktivieren | | |
Bearbeitungszeit: 20 Minuten, Einzel- oder Gruppenarbeit.
Musterlösung: (Exemplarisch für das Logistik-System aus Übung 1)
| Schritt | Maßnahme | Zuständig | Bis wann |
| 1 | Risikoklassen-Check → Hochrisiko (Anhang III Nr. 4) bestätigen | IT/Compliance | Woche 1 |
| 2 | Anbieter-Dokumentation anfordern und prüfen | IT | Woche 2 |
| 3 | Grundrechtefolgenabschätzung durchführen | Datenschutzbeauftragter | Woche 3–4 |
| 4 | DPIA nach Art. 35 DSGVO, AVV mit Anbieter prüfen | DSB | Woche 3–4 |
| 5 | Disponent als „AI Supervisor” benennen, Überschreibungsprozess definieren | Geschäftsführung | Woche 5 |
| 6 | Schulung der Disponenten, Protokollierung der Teilnahme | HR/IT | Woche 6 |
| 7 | Logging im System aktivieren, Aufbewahrungsfristen festlegen | IT | Woche 6 |
Human Oversight — Was bedeutet „menschliche Aufsicht” konkret?
Art. 14 EU AI Act definiert Anforderungen an die menschliche Aufsicht bei Hochrisiko-KI-Systemen. In der Praxis stellen sich viele Deployer die Frage: Was genau bedeutet das? Muss eine Person bei jeder KI-Entscheidung dabei sein?
Die Antwort ist nuancierter: Art. 14 verlangt, dass Hochrisiko-KI-Systeme so gestaltet sind, dass sie von natürlichen Personen wirksam überwacht werden können. Die Aufsicht muss nicht bei jeder einzelnen Entscheidung live erfolgen — aber die Möglichkeit zur Aufsicht und zum Eingriff muss strukturell gegeben sein.
Praktische Implementierungsformen:
Human-in-the-Loop: Eine Person überprüft jeden Einzelfall, bevor eine Entscheidung umgesetzt wird. Höchste Sicherheitsstufe; bei automatisierten Massenentscheidungen (z. B. Kreditwürdigkeitsprüfung im Retail-Banking) praktisch schwer umsetzbar.
Human-on-the-Loop: KI-System trifft automatisiert Entscheidungen; eine Person überwacht die Outputs und kann eingreifen. Üblich bei Systemen mit niedrigem Einzelentscheidungs-Risiko und hohem Volumen.
Human-in-Command: KI-System macht Empfehlungen; die endgültige Entscheidung liegt immer beim Menschen. Die häufigste Form in der Unternehmensrealität.
Art. 22 DSGVO vs. Art. 14 AI Act: Während Art. 22 DSGVO ein individuelles Recht gewährt, nicht allein einer automatisierten Entscheidung unterworfen zu sein, schreibt Art. 14 AI Act dem Deployer die Pflicht auf, die technischen und organisatorischen Voraussetzungen für menschliche Aufsicht zu schaffen. Beide Normen ergänzen sich.
Post-Market Monitoring — Laufende Überwachung
Art. 26 Abs. 6 und 7 AI Act verpflichten Deployer zu einem aktiven Post-Market Monitoring ihrer Hochrisiko-KI-Systeme. Was bedeutet das in der Praxis?
Deployer müssen: - Systematisch Informationen über die Leistung des Systems sammeln - Anomalien, unerwartete Ergebnisse und mögliche schwerwiegende Vorfälle aufzeichnen - Bei Vorfällen den Anbieter informieren - Bei schwerwiegenden Vorfällen (die Gesundheit, Sicherheit oder Grundrechte betreffen) die zuständige nationale Behörde informieren
Was ist ein „schwerwiegender Vorfall”? Art. 3 AI Act definiert schwerwiegende Vorfälle als Ereignisse, die direkt oder indirekt zum Tod einer Person, zu ernsthaften Schäden an Gesundheit oder Eigentum, oder zu schwerwiegenden Auswirkungen auf die Grundrechte führen oder führen könnten. Im Unternehmenskontext: Wenn ein KI-System eine Entscheidung trifft, die nachweislich zu einem konkreten Schaden geführt hat.
Praxis-Empfehlung: Richten Sie ein KI-Incident-Log ein — ähnlich einem IT-Security-Incident-Log. Jede Anomalie, jeder Verdacht auf fehlerhaftes Verhalten, jede Nutzerbeschwerden über das KI-System werden dokumentiert. Regelmäßige Reviews (z. B. quartalsweise) identifizieren Muster.
Warnung — Compliance-Risiko: Deployer-Haftung unterschätzen
Viele Unternehmen gehen davon aus, dass die Compliance-Verantwortung vollständig beim KI-Anbieter liegt. Das ist ein gefährlicher Irrtum. Als Deployer eines Hochrisiko-KI-Systems tragen Sie eigenständige Pflichten nach Art. 26 EU AI Act — unabhängig davon, ob der Anbieter seine Pflichten erfüllt hat. Bußgelder nach dem AI Act können auch Deployer treffen: bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes bei Verstößen gegen Hochrisiko-Anforderungen. Hinzu kommen zivilrechtliche Haftungsrisiken, wenn KI-gestützte Entscheidungen Personen schaden und nachgewiesen wird, dass die erforderliche menschliche Aufsicht nicht gewährleistet war. Praktischer Tipp: Verlassen Sie sich nicht allein auf Zusicherungen des Anbieters. Prüfen Sie selbst, ob die Gebrauchsanweisung klar ist, ob menschliche Aufsicht wirklich umsetzbar ist und ob Protokollierungsfunktionen verfügbar sind.
Cheatsheet — Art. 26 Deployer-Pflichten
| Pflicht | Rechtsgrundlage | Kernmaßnahme |
| Nutzung gemäß Anweisung | Art. 26 Abs. 1 | Gebrauchsanweisung studieren, Abweichungen dokumentieren |
| Menschliche Aufsicht | Art. 26 Abs. 1 + Art. 14 | AI Supervisor benennen, Eingriffsmöglichkeiten sichern |
| Schutz vor Missbrauch | Art. 26 Abs. 2 | TOMs nach Art. 32 DSGVO, Zugriffskontrollen |
| Grundrechtefolgenabschätzung | Art. 26 Abs. 3 + Art. 27 | Durchführen wenn anwendbar, dokumentieren |
| Protokollierung | Art. 26 Abs. 6 | Logging aktivieren, Aufbewahrungsfristen festlegen |
| Betroffene informieren | Art. 26 Abs. 9 + Art. 50 | Transparenzhinweise implementieren |
| Schulung | Art. 26 Abs. 5 + Art. 4 | Schulung dokumentieren, Nachweise aufbewahren |
| Drei-Stufen-Freigabe | Interne Governance | Grün / Gelb / Rot nach Risikobewertung |
Checkliste — Art. 26 Compliance im Überblick
Die folgende Checkliste ermöglicht eine schnelle Selbstbewertung des Art.-26-Compliance-Status für ein konkretes Hochrisiko-KI-System:
| Anforderung (Art. 26) | Status (✓/✗/?) | Maßnahme bei ✗ |
| KI-System im Inventar erfasst | KI-Register aktualisieren | |
| Risikoklasse dokumentiert und begründet | Klassifizierungsanalyse durchführen | |
| Konformitätserklärung des Anbieters vorhanden | Beim Anbieter anfordern | |
| AVV mit Anbieter abgeschlossen | AVV verhandeln und unterzeichnen | |
| Gebrauchsanleitung des Anbieters vorhanden | Beim Anbieter anfordern | |
| Human-in-the-Loop-Verfahren definiert | Verfahrensanweisung erstellen | |
| Verantwortliche Personen für menschliche Aufsicht benannt | Rollen definieren und dokumentieren | |
| Schulungsnachweis für nutzende Mitarbeitende | Schulung durchführen und dokumentieren | |
| DPIA abgeschlossen (wenn personenbezogene Daten) | DPIA beauftragen | |
| Post-Market-Monitoring-Prozess eingerichtet | Monitoring-Prozess definieren | |
| Betriebsrat informiert/eingebunden (wenn zutreffend) | BR-Prozess einleiten | |
| Vorfallberichterstattungs-Prozess definiert | Eskalationspfad dokumentieren |
Diese Checkliste ist kein vollständiger Compliance-Nachweis, aber ein gutes Werkzeug für den internen Review-Prozess.
Prompt-Beispiel: Deployer-Compliance-Roadmap nach Art. 26 EU AI Act erstellen
Rolle: Sie sind ein erfahrener KI-Compliance-Manager und unterstützen Unternehmen bei der Umsetzung der Deployer-Pflichten nach Art. 26 EU AI Act. Ihre Empfehlungen sind praxisorientiert und auf mittlere Unternehmen ausgelegt.
Aufgabe: Erstellen Sie eine strukturierte 7-Schritte-Compliance-Roadmap für die Einführung des folgenden Hochrisiko-KI-Systems in der beschriebenen Organisation. Beziehen Sie sich auf konkrete Absätze von Art. 26 EU AI Act und geben Sie für jeden Schritt an: (a) was zu tun ist, (b) wer verantwortlich ist (Rolle), (c) bis wann es erledigt sein muss (Zeitrahmen relativ zum Go-Live).
Kontext: KI-System: [Beschreiben Sie das geplante Hochrisiko-KI-System und seinen Einsatzzweck] Organisation: [Branche, Größe, ob ein Betriebsrat vorhanden ist, Erfahrungsstand mit KI-Compliance]
Format: Tabellarische Roadmap mit sieben Zeilen (Schritt 1–7) und den Spalten: Schritt | Inhalt | Art. 26 Bezug | Verantwortliche Rolle | Zeitrahmen. Abschließend ein kurzer Abschnitt (max. 100 Wörter) zu den Top-3-Risiken bei Nichterfüllung.
Prompt-Beispiel: KI-Nutzungsrichtlinie für Mitarbeitende formulieren
Rolle: Sie sind ein KI-Governance-Experte und unterstützen Unternehmen bei der Entwicklung interner KI-Nutzungsrichtlinien, die rechtliche Anforderungen (EU AI Act Art. 26 Abs. 5, Art. 4) mit praktischer Handhabbarkeit verbinden.
Aufgabe: Formulieren Sie eine interne KI-Nutzungsrichtlinie für Mitarbeitende, die in verständlicher Sprache die wichtigsten Verhaltensregeln beim KI-Einsatz im Unternehmen beschreibt. Die Richtlinie soll Art. 26 Abs. 5 EU AI Act (Schulungspflicht) und die AI-Literacy-Anforderungen aus Art. 4 berücksichtigen.
Kontext: Unternehmen: [Branche, Größe, welche KI-Tools sind zugelassen, welche Bereiche betreffen KI-Anwendungen am stärksten]
Format: Richtlinien-Dokument (max. 2 DIN-A4-Seiten) mit: Präambel (Zweck und Geltungsbereich), Do’s und Don’ts als nummerierte Regelliste, Abschnitt über meldepflichtige Vorfälle und Ansprechpersonen, Hinweis auf Schulungspflicht und Dokumentationsanforderungen. Sie-Form, klarer Behördensprachstil.
Branchen-Vignette — Deployer-Pflichten in der Personaldienstleistung
Eine Personaldienstleistungsgesellschaft mit bundesweiten Standorten setzt ein KI-gestütztes Matching-System ein, das Bewerberprofile automatisch mit offenen Stellen abgleicht und Empfehlungen für Personalberaterinnen und -berater generiert. Das System ist ein zugekauftes SaaS-Produkt eines US-amerikanischen Anbieters.
Art. 26-Pflichten im Detail:
Art. 26 Abs. 1: Die Gesellschaft prüft beim Anbieter: Ist das System als Hochrisiko klassifiziert? Liegt die technische Dokumentation vor? → Ergebnis: Das System ist nach Anhang III Nr. 2 lit. b Hochrisiko (Beschäftigung, Management von Arbeitnehmerinnen und Arbeitnehmern).
Art. 26 Abs. 5: Alle 45 Personalberaterinnen und -berater erhalten eine 3-stündige Pflichtschulung: Wie funktioniert das System? Welche Schwächen hat es? Wann darf ich dem KI-Ranking nicht folgen?
Art. 26 Abs. 8: Der Betriebsrat wird eingebunden — eine Betriebsvereinbarung KI wird parallel zur Systemeinführung verhandelt.
Art. 26 Abs. 9: Eine Grundrechtebewertung prüft AGG-Diskriminierungsrisiken (Alter, Geschlecht, Herkunft im Profiling) und definiert Gegenmaßnahmen.
Ergebnis: Nach sechs Wochen intensiver Vorbereitung — und nicht sofortigem Go-Live — kann das Unternehmen Art. 26 nachweisbar erfüllen. Der Mehraufwand rechnet sich: Bei einem Auditing durch die Aufsichtsbehörde ist die Gesellschaft vollständig dokumentiert.
Vertiefung II — Art. 26 EU AI Act im Volltext-Überblick
Art. 26 EU AI Act enthält neun Absätze, die zusammen das vollständige Pflichtenprogramm für Deployer beschreiben. Für die Praxis ist es wichtig, jeden Absatz zu kennen:
Art. 26 Abs. 1: Deployer verwenden Hochrisiko-KI-Systeme nur gemäß der Gebrauchsanleitung des Anbieters. Sie ergreifen technische und organisatorische Maßnahmen für den bestimmungsgemäßen Gebrauch. Sie stellen menschliche Aufsicht sicher — die Aufsichtspersonen müssen die notwendige Kompetenz, Ausbildung und Befugnis haben.
Art. 26 Abs. 2: Deployer weisen die Inputs zu, die mit der Gebrauchsanleitung des Anbieters kompatibel sind.
Art. 26 Abs. 3: Deployer melden dem Anbieter oder Importeur Fehler, die erhebliche Risiken darstellen. Sie müssen den Betrieb aussetzen, wenn sie Hochrisiken feststellen.
Art. 26 Abs. 4: Deployer stellen die Protokolle, die vom System automatisch generiert werden, für die zuständigen nationalen Behörden bereit (Art. 12 Log-Pflicht).
Art. 26 Abs. 5: Deployer stellen sicher, dass natürliche Personen, die für die menschliche Aufsicht eingesetzt werden, die notwendige Ausbildung erhalten — Bezug zu Art. 4 AI Literacy.
Art. 26 Abs. 6: Deployer im Bereich Beschäftigung informieren die betroffenen Arbeitnehmerinnen und Arbeitnehmer.
Art. 26 Abs. 7: Deployer für Systeme im Bereich Strafverfolgung, Migration, Justiz führen eine Grundrechte-Folgenabschätzung durch.
Art. 26 Abs. 8: Deployer informieren Arbeitnehmervertreter (Betriebsrat) über den Einsatz von Hochrisiko-KI.
Art. 26 Abs. 9: Deployer bestimmter Systemtypen führen eine Grundrechtebewertung durch, die auch Umwelt- und gesellschaftliche Risiken erfasst.
Übung 3 — Art. 26 auf einen konkreten Fall anwenden
Aufgabe (Gruppenarbeit, 15 Minuten): Ein Krankenhaus setzt ein KI-System ein, das radiologische Bilder analysiert und Verdachtsdiagnosen an Radiologen weiterleitet. Der Radiologe trifft die finale Diagnose.
Diskutieren Sie: (a) Ist das System Hochrisiko? Welcher Anhang-III-Tatbestand? (b) Welche Absätze von Art. 26 sind besonders relevant? (c) Was bedeutet „menschliche Aufsicht” in diesem konkreten Kontext — was muss der Radiologe wirklich prüfen?
Zeitrahmen: 10 Minuten Gruppenarbeit, 5 Minuten Plenumsdiskussion.
Musterlösung Übung 3: (a) Das System fällt unter Anhang III Nr. 5 lit. a (Bestimmung des Zugangs zu wesentlichen Diensten — Gesundheitsversorgung). Hochrisiko-Einstufung sehr wahrscheinlich. (b) Besonders relevant: Art. 26 Abs. 1 (menschliche Aufsicht durch Radiologen), Abs. 3 (Fehler-Meldepflicht), Abs. 5 (Schulungspflicht für Radiologinnen und Radiologen). (c) Menschliche Aufsicht bedeutet: Der Radiologe muss das KI-System kritisch hinterfragen können — er muss wissen, wie das System funktioniert, wo seine Schwächen liegen (z. B. seltene Diagnosen), und er muss die Freiheit und Kapazität haben, von der KI-Empfehlung abzuweichen.
Zusammenfassung UE 17
Art. 26 EU AI Act definiert neun Kernpflichten für Deployer von Hochrisiko-KI: Konformitätsprüfung, Gebrauchsanleitung befolgen, menschliche Aufsicht sicherstellen, Risikomanagement umsetzen, Datenschutz-Folgenabschätzung, AI-Literacy-Schulungen, Aufzeichnungspflichten, Vorfallmeldung und Betriebsrats-/Arbeitnehmervertretungsrechte respektieren. Die 7-Schritte-Compliance-Roadmap — Inventar, Klassifizierung, Priorisierung, Anbieter-Dokumentation, Human-in-the-Loop, Schulung, Monitoring — bietet eine pragmatische Umsetzungsstruktur. Der Unterschied zwischen Anbieter (stellt System bereit) und Deployer (setzt System ein) bestimmt, welche Pflichten in welchem Umfang gelten. Eigenentwicklungen auf API-Basis machen das Unternehmen zum Anbieter mit entsprechend weitergehenden Pflichten. Dokumentation ist der zentrale Compliance-Nachweis.
Querverweise zu anderen UEs
UE 17 (Deployer-Pflichten) ist die zentrale operative UE von Modul 2. Sie verbindet Risikoklassen (UE 16), AI Literacy (UE 18), DSGVO-Anforderungen (UE 13–14) und Betriebsvereinbarung (UE 23) zu einem kohärenten Compliance-Bild. Art. 26 ist die Norm, die Deployer am direktesten in die Pflicht nimmt. Das 7-Schritte-Vorgehen überträgt diese Pflichten in umsetzbare Maßnahmen. In der Fallstudie (UE 24) wird Art. 26 als Teil von Block B direkt angewendet.
Reflexionsfragen
- Welche der neun Art.-26-Pflichten erachten Sie für Ihre Organisation als besonders herausfordernd? Warum?
- Wie würden Sie „menschliche Aufsicht” in einem schnellen Produktionsprozess praktisch umsetzen, ohne die Effizienzvorteile der KI zu verlieren?
- Was passiert, wenn ein Deployer ein KI-System für einen Zweck nutzt, der nicht in der Gebrauchsanweisung des Anbieters vorgesehen ist?
- Welche Rolle spielt der Betriebsrat bei der Einführung eines Hochrisiko-KI-Systems? (Vorschau auf UE 23)
- Wie unterscheidet sich das Drei-Stufen-Freigabemodell von einem einfachen „Erlaubnis-/Verbotsliste”-Ansatz?
- Art. 26 Abs. 8 EU AI Act sieht vor, dass Deployer die Arbeitnehmervertreter über den Einsatz von Hochrisiko-KI informieren müssen. Warum hat der Gesetzgeber dieses Recht ausdrücklich in den EU AI Act aufgenommen — und nicht nur im Betriebsverfassungsrecht belassen?
- Stellen Sie sich vor, Sie sind KI-Verantwortliche/-r in Ihrem Unternehmen. Welcher der sieben Compliance-Schritte aus der Roadmap würde in Ihrer Organisation die größte Herausforderung darstellen — und woran liegt das?
Praktischer Leitfaden: Erstes Audit Ihres KI-System-Portfolios
Wenn Ihre Organisation noch kein formales KI-Inventar hat, ist dies der erste Schritt. Folgendes praktisches Vorgehen hat sich in der Praxis bewährt:
Schritt 1 — Workshop mit IT: Die IT-Abteilung kennt alle offiziell beschafften Software-Lizenzen und Cloud-Dienste, die KI-Funktionen enthalten. In einem 2-Stunden-Workshop erstellen Sie gemeinsam eine erste Liste.
Schritt 2 — Survey mit Fachabteilungen: Viele KI-Tools werden direkt von Fachabteilungen ohne IT-Beteiligung beschafft (Shadow AI). Ein kurzer Online-Survey fragt alle Abteilungsleiter: Welche KI-Tools nutzt Ihr Team? Dies deckt Shadow AI auf.
Schritt 3 — Konsolidierung: Zusammenführung der Listen aus IT und Fachabteilungen. Erste Priorisierung: Welche Systeme sind potenziell Hochrisiko?
Schritt 4 — Risikoklassifizierung: Für jeden Eintrag: Prüfung nach der Vier-Fragen-Heuristik aus UE 16. Klassifizierung und Begründung dokumentieren.
Schritt 5 — Priorisierung der Compliance-Maßnahmen: Hochrisiko-Systeme zuerst. Für jedes Hochrisiko-System: Was fehlt noch für Art.-26-Compliance?
Dieses erste Audit nimmt typischerweise 2–4 Wochen in Anspruch (je nach Organisationsgröße) und schafft die Grundlage für alle weiteren KI-Governance-Maßnahmen.
Merksatz zu UE 17: Art. 26 EU AI Act ist kein bürokratisches Regelwerk — er ist ein Qualitätsrahmen für verantwortungsvollen KI-Einsatz. Deployer, die Art. 26 konsequent umsetzen, schützen sich, ihre Mitarbeitenden und ihre Kunden vor den Risiken unkontrollierten KI-Einsatzes.
Quellen & Weiterlesen
| Quelle | Typ | URL |
| EU AI Act Art. 26 — Deployer-Pflichten | Primärrecht | https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689 |
| EU AI Act Art. 14 — Menschliche Aufsicht | Primärrecht | https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689 |
| EU AI Act Art. 27 — Grundrechtefolgenabschätzung | Primärrecht | https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32024R1689 |
| EU AI Office — Deployer Guidance | Behördeninfo | https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai |
| Bitkom — Praxisleitfaden AI Act für Unternehmen | Studie | https://www.bitkom.org/Bitkom/Publikationen/Umsetzungsleitfaden-zur-KI-Verordnung |
| IAPP — AI Act Deployer Obligations | Studie | https://artificialintelligenceact.eu/article/26/ |
Ergänzung: Art. 26 EU AI Act — Absatz-für-Absatz-Übersicht
| Absatz | Inhalt | Priorität für Deployer |
| Art. 26 Abs. 1 | Nutzung gemäß Gebrauchsanleitung, menschliche Aufsicht sicherstellen | Hoch — Kernpflicht |
| Art. 26 Abs. 2 | Kompatible Inputs gemäß Anleitung | Mittel |
| Art. 26 Abs. 3 | Fehler mit erheblichem Risiko dem Anbieter melden, ggf. Betrieb aussetzen | Hoch |
| Art. 26 Abs. 4 | Protokolle für Behörden bereithalten | Mittel |
| Art. 26 Abs. 5 | Schulung der Aufsichtspersonen (→ Art. 4 AI Literacy) | Hoch |
| Art. 26 Abs. 6 | Information betroffener Arbeitnehmerinnen und Arbeitnehmer | Hoch (Beschäftigung) |
| Art. 26 Abs. 7 | Grundrechte-Folgenabschätzung (Strafverfolgung, Migration, Justiz) | Sehr hoch (Sektor) |
| Art. 26 Abs. 8 | Information der Arbeitnehmervertreter (Betriebsrat) | Hoch (Mitbestimmung) |
| Art. 26 Abs. 9 | Grundrechtebewertung bei bestimmten Systemtypen | Hoch (falls anwendbar) |
Deployer-Pflichten und KMU
Art. 26 gilt grundsätzlich auch für kleine Unternehmen. Die Intensität der Umsetzungsmaßnahmen kann jedoch verhältnismäßig angepasst werden:
- Dokumentation kann vereinfacht sein, wenn die inhaltlichen Anforderungen erfüllt werden
- Eine einseitige Grundrechtebewertung ist besser als keine
- Eine formlose Schulungsbestätigung mit Teilnahmeliste erfüllt Art. 26 Abs. 5 im KMU-Kontext
- Dokumentieren Sie Ihre Prüfschritte, auch wenn das Ergebnis „kein Handlungsbedarf” ist
Was nicht vereinfacht werden darf: Die menschliche Aufsicht (Art. 26 Abs. 1) und die Grundpflichten gegenüber dem Anbieter.
Trainer-Hinweise
Art. 29 AI Act — Pflichten der Nutzer von KI-Systemen
Neben Art. 26 (Deployer) enthält der EU AI Act in Art. 29 auch Pflichten für die tatsächlichen Nutzer von KI-Systemen — also Mitarbeitende, die KI im Arbeitsalltag einsetzen. Die wichtigsten Nutzerpflichten:
Nutzung gemäß Gebrauchsanleitung: Nutzer sind verpflichtet, das KI-System nur gemäß der vom Anbieter bereitgestellten Gebrauchsanleitung zu verwenden. Eigenmodifikationen oder Nutzungen außerhalb des vorgesehenen Anwendungsbereichs können die Compliance des Deployers gefährden.
Meldepflicht bei Anomalien: Wenn ein Nutzer bemerkt, dass das KI-System fehlerhaft oder unerwartet funktioniert, ist er verpflichtet, dies zu melden — an die intern verantwortliche Person oder an den Deployer. Dieses Reporting ist Teil des Post-Market-Monitoring-Prozesses.
Kein Umgehungsverbot: Nutzer dürfen keine Maßnahmen ergreifen, die die im System implementierten Human-in-the-Loop-Mechanismen umgehen (z. B. systematisches Übernehmen aller KI-Empfehlungen ohne eigene Prüfung).
Die Verbindung zwischen Art. 26 (Deployer) und Art. 29 (Nutzer): Der Deployer ist für die Schulung der Nutzer verantwortlich (Art. 26 Abs. 5 in Verbindung mit Art. 4) — damit diese ihre Pflichten nach Art. 29 kennen und erfüllen können. Dieser Zirkelschluss macht die AI Literacy-Schulung zur Brücke zwischen beiden Normen.
Praxishinweis: Fuehren Sie ein jaehrliches Art.-26-Compliance-Review durch. Gehen Sie die Checkliste fuer alle Hochrisiko-Systeme durch und aktualisieren Sie die Dokumentation. Dieses Review kann mit dem jaehrlichen Datenschutz-Audit kombiniert werden, um Ressourcen zu sparen.
Hinweise für AI Champions — So vermitteln Sie das Thema UE 17
Timing: 45 Minuten — empfohlen: 20 Min. Theorie (Art. 26 Absätze + Drei-Stufen-Modell), 25 Min. Übungen.
Methodik: Die neun Absätze von Art. 26 sind viel — strukturieren Sie sie in die sieben thematischen Gruppen. Das Drei-Stufen-Freigabemodell ist ein wirksames visuelles Hilfsmittel: Ampel-Metapher auf dem Flipchart. Betonen Sie, dass die Ampel ein internes Governance-Tool ist, keine gesetzliche Anforderung — aber eine bewährte Praxis.
Stolpersteine: Die häufigste Fehlannahme: „Der Anbieter hat CE-Kennzeichen → wir sind compliant.” Korrigieren Sie dies mit konkreten Beispielen, wo Deployer trotz CE-gekennzeichnetem System in Haftung geraten können (z. B. Zweckentfremdung, fehlende Schulung).
Diskussionsfragen: Was wäre, wenn ein KI-System die menschliche Aufsicht faktisch unmöglich macht (zu schnell, zu komplex)? Darf man es dann überhaupt einsetzen?
Tafelbild: Anbieter-Pflichten vs. Deployer-Pflichten als zwei Spalten, verbunden durch Pfeile. Drei-Stufen-Ampel daneben.
Differenzierung: Für Gruppen mit Rechts-Hintergrund: Das Konzept der Verantwortungsverteilung (Art. 25 — Deployer wird Anbieter bei Zweckentfremdung) ist besonders relevant. Für technische Gruppen: Wie werden Logging und menschliche Override-Funktionen in realen Systemen implementiert?
Materialliste: Flipchart, Ampel-Poster (Grün/Gelb/Rot), Handout, Fallkarten für Übung 1.
Übergang zu UE 18: „Deployer müssen Mitarbeitende schulen — aber was genau muss die Schulung vermitteln? Art. 4 EU AI Act gibt die Antwort: AI Literacy.”
Branchenauswahl-Tipp: Für gemischte Gruppen: Das Logistik-Beispiel aus den Übungen ist branchenübergreifend verständlich und enthält viele typische Deployer-Konstellationen.
Art. 26 und das Verhältnis zu anderen europäischen Rechtsakten
Art. 26 EU AI Act existiert nicht im Vakuum — er interagiert mit anderen europäischen Rechtsakten:
DSGVO: Wo Art. 26 AI Act auf personenbezogene Daten trifft, gilt auch die DSGVO. Die Dokumentationspflichten des Art. 26 AI Act können mit der DPIA nach Art. 35 DSGVO zusammengeführt werden — ein Dokument, das beide Anforderungen erfüllt, spart Zeit und Ressourcen.
ePrivacy-Richtlinie: Wenn KI-Systeme für elektronische Kommunikation eingesetzt werden (z. B. E-Mail-Analyse, Chat-Überwachung), gelten zusätzlich die Anforderungen der ePrivacy-Richtlinie (in Kürze: ePrivacy-Verordnung).
Digitale-Dienste-Gesetz (DSA): Sehr große Online-Plattformen (VLOP) müssen nach dem DSA Empfehlungssysteme offenlegen und Nutzern ermöglichen, diese zu deaktivieren. Der DSA ergänzt die AI-Act-Transparenzanforderungen für Online-Plattformen.
Cyber Resilience Act (CRA): Für KI-Systeme, die als Produkte mit digitalen Elementen klassifiziert werden, gelten zusätzlich die Anforderungen des CRA (ab 2027). Cybersicherheitsanforderungen aus Art. 15 AI Act und CRA können gemeinsam adressiert werden.
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