Der EU AI Act gilt seit August 2024. Die meisten Unternehmen – vom Handwerksbetrieb bis zum Mittelständler – sind keine KI-Entwickler. Sie setzen KI ein. Damit sind sie im Sinne der Verordnung Deployer (Betreiber). Und Deployer haben eigene Pflichten. Nicht so umfangreich wie die der Provider – aber konkret, dokumentationspflichtig und bei Verstößen sanktionierbar.
Dieser Artikel zeigt, welche Pflichten Art. 26 AI Act für Deployer definiert, was Sie pro KI-System dokumentieren müssen und wie sich die Anforderungen bei 12 gängigen Tools konkret auswirken.
Die meisten Unternehmen sind Deployer – nicht Provider
Der AI Act unterscheidet drei Hauptrollen entlang der Wertschöpfungskette:
Rolle | Definition | Typisches Beispiel |
|---|---|---|
Provider (Anbieter) | Entwickelt oder lässt KI entwickeln und bringt sie unter eigenem Namen auf den Markt | OpenAI, Microsoft, SAP, Personio |
Deployer (Betreiber) | Setzt ein fremdes KI-System beruflich in eigener Verantwortung ein | Ihr Unternehmen, wenn es ChatGPT, Copilot oder Personio nutzt |
Distributor (Händler) | Vertreibt oder vermittelt KI-Systeme, ohne sie zu entwickeln oder selbst einzusetzen | IT-Reseller, Software-Distributoren |
Für geschätzte 95 % der KMU ist die Deployer-Rolle die relevante. Sie kaufen oder abonnieren KI-Systeme und setzen sie in HR, Marketing, Kundenservice, Finanzen oder Produktion ein. Die Provider-Pflichten (Konformitätsbewertung, CE-Kennzeichnung, technische Dokumentation) liegen beim Hersteller. Aber die Deployer-Pflichten liegen bei Ihnen.
Und genau hier liegt das Missverständnis, das viele Unternehmen teuer kosten kann: Wer KI nur einkauft, ist nicht pflichtenfrei.
Leitfaden: Für den Gesamtüberblick über alle AI-Act-Pflichten und die 5-Phasen-Umsetzungslogik lesen Sie unseren Pillar-Artikel: EU AI Act für KMU.
Art. 26 AI Act: Die 7 Kernpflichten für Deployer
Art. 26 der KI-Verordnung regelt die Pflichten für Betreiber von Hochrisiko-KI-Systemen. In der Praxis wirken einige dieser Pflichten aber über Hochrisiko hinaus – weil Art. 4 (KI-Kompetenz) und Art. 50 (Transparenz) für alle KI-Systeme gelten, unabhängig von der Risikoklasse.
Hier die 7 Kernpflichten im Überblick:
Nr. | Pflicht | Rechtsgrundlage | Gilt für |
|---|---|---|---|
1 | Bestimmungsgemäße Verwendung gemäß Betriebsanleitung | Art. 26 Abs. 1 | Hochrisiko |
2 | Menschliche Aufsicht durch kompetente Personen | Art. 26 Abs. 2 | Hochrisiko |
3 | Qualität und Repräsentativität der Eingabedaten sicherstellen | Art. 26 Abs. 4 | Hochrisiko |
4 | Betrieb überwachen, Risiken und Vorfälle melden | Art. 26 Abs. 5 | Hochrisiko |
5 | Automatisch erzeugte Protokolle mindestens 6 Monate aufbewahren | Art. 26 Abs. 6 | Hochrisiko |
6 | Betroffene Personen über KI-Einsatz informieren | Art. 26 Abs. 11 + Art. 50 | Hochrisiko + begrenztes Risiko |
7 | KI-Kompetenz des Personals sicherstellen | Art. 4 | Alle KI-Systeme |
Pflicht 7 ist die Auffälligste: Sie gilt seit dem 2. Februar 2025 für jedes Unternehmen, das KI einsetzt – egal ob Hochrisiko oder nicht. Mehr dazu in unserem Artikel AI Literacy nach Art. 4.
Was Sie pro KI-System dokumentieren müssen: Die 10 Felder
Die Pflichten aus Art. 26 lassen sich in eine konkrete Dokumentationsstruktur übersetzen. Für jedes KI-System in Ihrem Unternehmen brauchen Sie die folgenden 10 Felder:
Nr. | Dokumentationsfeld | Was einzutragen ist |
|---|---|---|
1 | Systembezeichnung | Name, Version, Anbieter (z. B. „Microsoft 365 Copilot, Version Enterprise, Microsoft Corp.“) |
2 | Einsatzzweck | Konkreter Use Case im Unternehmen (z. B. „E-Mail-Zusammenfassungen und Entwürfe in Outlook“) |
3 | Risikoklasse | Ergebnis der Einstufung: verboten / Hochrisiko / begrenztes Risiko / minimal (mit Begründung) |
4 | Rolle des Unternehmens | Deployer, ggf. Provider (bei Fine-Tuning oder eigenen Modellen) |
5 | Verantwortliche Person | Name + Funktion der Person mit Human-Oversight-Verantwortung |
6 | Eingabedaten | Welche Daten fließen in das System? Personenbezug? Sensitivität? |
7 | Transparenzmaßnahmen | Wie werden Betroffene informiert? (Datenschutzhinweis, Kennzeichnung, Betriebsratsinfo) |
8 | Protokollierung | Werden Logs erzeugt? Wo gespeichert? Aufbewahrungsfrist (mind. 6 Monate bei Hochrisiko) |
9 | Schulungsstatus | Wer wurde geschult? Wann? Nachweis vorhanden? |
10 | Letzte Überprüfung | Datum der letzten Prüfung, nächster Review-Termin, Änderungen seit letzter Prüfung |
Wer diese 10 Felder pro KI-System sauber pflegt, hat den operativen Kern der Deployer-Dokumentation abgedeckt – für jede Risikoklasse.
Nicht jedes Feld ist für jede Risikoklasse gleich kritisch. Bei Hochrisiko-Systemen (z. B. KI im Bewerbermanagement) müssen alle 10 Felder lückenlos sein. Bei Systemen mit minimalem Risiko (z. B. Spamfilter) reicht eine Basiserfassung der Felder 1–4 und 9.
Template statt Selbstbau: Das Deployer-Dokumentationstemplate enthält alle 10 Felder als vorstrukturiertes Excel – mit Dropdown-Auswahl für Risikoklassen, vorausgefüllten Beispielen für 12 gängige Tools und einer Anleitung pro Feld. Sofort einsatzbereit.
Für die Einstufung in Risikoklassen (Feld 3) nutzen Sie den Entscheidungsbaum aus unserem Artikel Risikoklassen im AI Act. Die Basiserfassung (Felder 1–4) entspricht im Wesentlichen Ihrem KI-Inventar.
Praxisbeispiel: Deployer-Dokumentation für 12 gängige Tools
Theorie ist das eine – aber wie sieht die Dokumentation für Tools aus, die tatsächlich in KMU im Einsatz sind? Hier eine Übersicht für 12 gängige KI-Systeme:
Minimales Risiko – Basisdokumentation ausreichend
Tool | Typischer Einsatz | Risikoklasse | Dokumentationstiefe |
|---|---|---|---|
Spamfilter (M365/Google) | E-Mail-Filterung | Minimal | Felder 1–4, 9 |
Grammarly / LanguageTool | Textkorrektur | Minimal | Felder 1–4, 9 |
Canva AI | Bildgenerierung Marketing | Minimal | Felder 1–4, 9 |
Begrenztes Risiko – Transparenzpflichten beachten
Tool | Typischer Einsatz | Risikoklasse | Dokumentationstiefe |
|---|---|---|---|
ChatGPT | Textgenerierung, Recherche, Analyse | Begrenzt | Felder 1–7, 9 |
Microsoft 365 Copilot | E-Mail, Dokumente, Meetings | Begrenzt | Felder 1–7, 9 |
DeepL Pro | Übersetzungen | Begrenzt | Felder 1–5, 7, 9 |
Zoom AI Companion | Meeting-Zusammenfassungen | Begrenzt | Felder 1–7, 9 |
Midjourney / DALL-E | Bildgenerierung | Begrenzt | Felder 1–7, 9 (Kennzeichnungspflicht!) |
Slack AI | Channel-Zusammenfassungen, Suche | Begrenzt | Felder 1–7, 9 |
Hochrisiko – Vollständige Dokumentation aller 10 Felder
Tool | Typischer Einsatz | Risikoklasse | Dokumentationstiefe |
|---|---|---|---|
Personio (KI-Funktionen) | Bewerbungs-Screening, HR-Scoring | Hochrisiko (Anhang III Nr. 4) | Alle 10 Felder + FRIA |
HubSpot (Lead-Scoring) | Automatisierte Kunden-Bewertung | Kontextabhängig* | Felder 1–10 bei Kreditwürdigkeit |
DATEV (KI-Belegprüfung) | Automatisierte Belegverarbeitung | Kontextabhängig* | Felder 1–10 bei Scoring-Funktion |
* Abhängig vom konkreten Einsatzzweck. Ein CRM-Tool wird durch KI-gestütztes Kredit-Scoring zum Hochrisiko-System – dieselbe Software ohne diese Funktion nicht.
Praxis-Hinweis: Die Risikoklasse bestimmt sich nicht durch das Tool, sondern durch den Einsatzzweck. Personio ist ein HR-Tool – es wird erst durch den Einsatz für Bewerbungs-Screening zum Hochrisiko-System. Wenn Sie Personio nur für Urlaubsverwaltung nutzen, liegt kein Hochrisiko vor.
Hochrisiko-Sonderfall: Wenn Ihre HR-KI unter Anhang III fällt
Der häufigste Hochrisiko-Fall für KMU ist KI im Personalwesen. Anhang III Nr. 4 des AI Act erfasst KI-Systeme, die für folgende Zwecke eingesetzt werden:
Stellenanzeigen gezielt ausspielen oder filtern
Bewerbungen sichten, sortieren oder vorselektieren
Kandidaten bewerten oder ranken
Vorstellungsgespräche analysieren (Mimik, Sprache, Stimmung)
Leistungsbeurteilungen automatisiert erstellen
Beförderungs- oder Kündigungsentscheidungen unterstützen
Wenn Sie ein Tool wie Personio, Workday, SAP SuccessFactors oder ein spezialisiertes Recruiting-Tool mit KI-Funktionen für einen dieser Zwecke nutzen, sind Sie Deployer eines Hochrisiko-KI-Systems.
Das bedeutet konkret:
Alle 10 Dokumentationsfelder müssen lückenlos ausgefüllt sein
Human Oversight muss einer konkreten Person zugewiesen sein – mit Befugnis, KI-Entscheidungen zu überstimmen
Logs müssen mindestens 6 Monate aufbewahrt werden
Betriebsrat muss vor Inbetriebnahme informiert werden (Art. 26 Abs. 7 + § 87 Abs. 1 Nr. 6 BetrVG)
Betroffene Bewerber müssen über den KI-Einsatz informiert werden (Art. 26 Abs. 11)
Eine Grundrechte-Folgenabschätzung (FRIA) kann erforderlich sein – für öffentliche Stellen und bestimmte private Deployer ist sie Pflicht
Mehr zur FRIA lesen Sie in unserem Artikel FRIA nach Art. 27 AI Act.
Transparenzpflichten nach Art. 50 – wann und wen Sie informieren müssen
Neben Art. 26 ist Art. 50 die zweite zentrale Norm für Deployer. Sie gilt unabhängig von der Risikoklasse für bestimmte KI-Anwendungen:
Szenario | Transparenzpflicht | Beispiel |
|---|---|---|
KI interagiert mit natürlichen Personen | Information, dass es sich um ein KI-System handelt | Chatbot auf Ihrer Website, KI-Telefonassistent |
KI erzeugt synthetische Inhalte (Text, Bild, Audio, Video) | Kennzeichnung als KI-generiert in maschinenlesbarem Format | Midjourney-Bilder, ChatGPT-Texte in Publikationen |
Emotionserkennung oder biometrische Kategorisierung | Information der betroffenen Personen vor der Verarbeitung | Stimmungsanalyse in Vorstellungsgesprächen |
KI trifft oder unterstützt Entscheidungen über Personen (Hochrisiko) | Information der betroffenen Personen + Recht auf Erläuterung | Bewerbungs-Screening, Kredit-Scoring |
Für die Praxis bedeutet das: Sobald Sie ChatGPT-generierte Texte veröffentlichen, Copilot-generierte E-Mails an Kunden senden oder einen KI-Chatbot auf Ihrer Website betreiben – greifen Transparenzpflichten.
Umsetzung in 3 Schritten
Inventar prüfen: Welche Ihrer KI-Systeme interagieren mit externen Personen oder erzeugen öffentliche Inhalte? (Nutzen Sie dafür Ihr KI-Inventar)
Informationspflichten zuordnen: Pro System bestimmen, welche Transparenzpflicht greift (Tabelle oben)
Umsetzungsmaßnahme definieren: Datenschutzhinweis ergänzen, Chatbot-Label einbauen, Bildkennzeichnung etablieren, Betriebsrats-Information dokumentieren
Dokumentieren Sie die Transparenzmaßnahmen in Feld 7 Ihrer Deployer-Dokumentation.
Achtung Rollenwechsel: Wann der Deployer zum Provider wird
Art. 25 AI Act regelt die Verantwortlichkeiten entlang der Wertschöpfungskette. Eine der gefährlichsten Fallen für Unternehmen: Unter bestimmten Umständen wird der Deployer zum Provider – mit allen Provider-Pflichten, die daran hängen.
Das passiert in folgenden 5 Szenarien:
Nr. | Trigger | Beispiel | Konsequenz |
|---|---|---|---|
1 | Sie ändern die Zweckbestimmung eines Hochrisiko-KI-Systems | Sie nutzen ein Marketing-Scoring-Tool für Bewerber-Ranking | Sie werden Provider für diesen Use Case |
2 | Sie nehmen wesentliche Änderungen am System vor | Fine-Tuning eines Sprachmodells mit eigenen Daten | Provider-Pflichten für das veränderte System |
3 | Sie bringen ein KI-System unter eigenem Namen auf den Markt | Sie verkaufen eine Chatbot-Lösung auf Basis von GPT-4 unter Ihrer Marke | Volle Provider-Pflichten |
4 | Sie erstellen Custom GPTs oder Agenten für Dritte | Ein Custom GPT für Kunden, der über API eingebunden wird | Kontextabhängig – bei eigenständigem Produkt: Provider |
5 | Sie trainieren ein eigenes Modell auf Basis eines Basismodells | LoRA-Adapter auf Llama 3 mit eigenen Kundendaten | Provider für das abgeleitete Modell |
Faustregel: Solange Sie ein KI-System wie vom Anbieter vorgesehen nutzen, bleiben Sie Deployer. Sobald Sie es wesentlich verändern, umwidmen oder unter eigenem Namen vertreiben, werden Sie Provider.
In der Praxis betrifft das vor allem Unternehmen, die: eigene Chatbots auf GPT-Basis für Kunden anbieten, KI-Tools intern so stark anpassen, dass sie praktisch ein neues Produkt darstellen, oder Open-Source-Modelle fine-tunen und im Geschäftsbetrieb einsetzen.
Dokumentieren Sie Ihre Rolle (Deployer oder Provider) in Feld 4 Ihrer Dokumentation – und überprüfen Sie diese Einschätzung bei jedem neuen Use Case. Die KI-Richtlinie Ihres Unternehmens sollte klare Regeln enthalten, ab wann ein Genehmigungsprozess greift.
Von der Dokumentation zum Monitoring
Deployer-Dokumentation ist kein einmaliges Projekt. Art. 26 Abs. 5 verlangt ausdrücklich, dass Deployer den Betrieb des KI-Systems laufend überwachen. Das bedeutet:
Regelmäßige Reviews der Dokumentation (empfohlen: halbjährlich für Hochrisiko, jährlich für andere Systeme)
Änderungs-Tracking: Neue KI-Funktionen (z. B. Copilot-Updates, Personio-Feature-Releases) können die Risikoklasse verändern
Vorfall-Dokumentation: Wenn ein KI-System fehlerhafte, diskriminierende oder unerwartet riskante Ergebnisse liefert – sofortige Dokumentation und ggf. Meldung an den Provider
Schwerwiegende Vorfälle: Bei Hochrisiko-Systemen müssen Sie den Provider und die Marktüberwachungsbehörde informieren (Art. 26 Abs. 5 Unterabs. 3)
Ein strukturiertes KI-Monitoring-System hilft, diese Pflichten operativ abzubilden. Mehr dazu in unserem Artikel KI-Compliance Monitoring.
Dokumentation im Zusammenspiel: Das Gesamtbild
Die Deployer-Dokumentation steht nicht allein. Sie ist ein Baustein in einem größeren System:
Dokument | Zweck | Verknüpfung |
|---|---|---|
Welche Systeme haben wir? | Basis für Felder 1–4 | |
Deployer-Dokumentation (dieser Artikel) | Welche Pflichten hat jedes System? | 10 Felder pro System |
Welche Regeln gelten intern? | Governance-Rahmen für Feld 5, 7, 9 | |
Grundrechteprüfung für Hochrisiko | Ergänzung bei Anhang-III-Systemen | |
Laufende Überwachung + Vorfälle | Pflege von Feld 8, 10 | |
Systematische Konformitätsprüfung | Verwendet Dokumentation als Prüfgrundlage |
Bußgelder und Haftung: Was Deployern droht
Der AI Act staffelt die Sanktionen nach Schwere des Verstoßes:
Verstoß | Bußgeld |
|---|---|
Einsatz verbotener KI-Praktiken | Bis 35 Mio. EUR oder 7 % des Jahresumsatzes |
Verstöße gegen Hochrisiko-Pflichten (Art. 26) | Bis 15 Mio. EUR oder 3 % des Jahresumsatzes |
Falsche oder unvollständige Angaben gegenüber Behörden | Bis 7,5 Mio. EUR oder 1 % des Jahresumsatzes |
Für KMU gilt jeweils der niedrigere der beiden Beträge. Aber auch 7,5 Mio. EUR sind für die meisten Mittelständler existenzbedrohend.
Dazu kommt: Private Durchsetzung ist bereits möglich. Bewerber, die durch KI-gestützte HR-Systeme benachteiligt werden, können Schadensersatzansprüche geltend machen – unabhängig von behördlichen Bußgeldern. Die Dokumentation ist dann Ihr wichtigstes Beweismittel.
Ihre nächsten 3 Schritte
KI-Inventar prüfen: Haben Sie alle KI-Systeme erfasst? Auch eingebettete KI in SaaS-Tools wie M365 Copilot, Personio, HubSpot, DeepL oder Canva? Wenn nicht: KI-Inventar erstellen.
Deployer-Dokumentation aufbauen: Pro System die 10 Felder ausfüllen. Priorisieren Sie Hochrisiko-Systeme (HR, Kredit-Scoring) und Systeme mit Transparenzpflicht (Chatbots, Bildgenerierung).
Review-Zyklus festlegen: Halbjährlich für Hochrisiko, jährlich für alle anderen. Tragen Sie den Termin ein – bevor er zum Audit-Thema wird.
Fertige Vorlage statt leeres Blatt: Das Deployer-Dokumentationstemplate liefert alle 10 Felder als Excel mit Dropdown-Menüs, 12 vorausgefüllten Tool-Beispielen und einer Schritt-für-Schritt-Anleitung. Oder sichern Sie sich das komplette AI Act Aufbau-Bundle – mit KI-Inventar, Risikoklassifizierung, KI-Richtlinie, Deployer-Dokumentation, FRIA-Template, Schulungskonzept, Monitoring-Kit und Audit-Prüfkatalog.
