Was der EU AI Act von Ihnen erwartet — konkret und ohne Juristendeutsch

 

📋 MANAGEMENT SUMMARY — Was Sie in 5 Minuten wissen müssen

Der EU AI Act (Verordnung EU 2024/1689) ist seit August 2024 in Kraft. Er gilt nicht nur für Unternehmen, die KI entwickeln — er gilt auch für Sie als Nutzer. Wer Microsoft Copilot, Azure OpenAI oder eigene KI-Anwendungen einsetzt, ist im Sinne des AI Acts ein Deployer oder User. Das bedeutet: konkrete Pflichten, konkrete Stichtage, konkrete Bußgelder bei Verstoß. Die gute Nachricht zuerst: Copilot M365 als Produktivitätstool fällt in der Regel in die Kategorie „geringes Risiko“. Ein Transparenzhinweis und eine interne Nutzungsrichtlinie genügen. Was Sie nicht tun dürfen: KI zur Bewertung von Mitarbeitern nach Verhaltensmustern einsetzen, biometrische Kategorisierung vornehmen oder Personen unterbewusst manipulieren. Das sind Verbote nach Art. 5 — seit Februar 2025 rechtswirksam. Die wichtigste Pflicht, die sofort gilt: AI Literacy nach Art. 4. Sie müssen sicherstellen, dass alle Personen, die KI einsetzen, über ausreichende Kompetenz verfügen. Das ist kein Wunsch — das ist eine Rechtspflicht. Und es muss nachweisbar sein. Ein E-Learning-Abzeichen in Teams wird bei einer Prüfung nicht als ausreichend Nachweis gelten. Bis August 2026 müssen Unternehmen, die hochriskante KI-Systeme einsetzen, Konformitätsbewertungen, Fundamentalrechte-Folgenabschätzungen und eine Registrierung vorweisen. Hochriskant wird es, sobald KI an HR-Entscheidungen, Kreditbewertung oder kritischer Infrastruktur beteiligt ist. Die meisten Standard-Copilot-Einsätze fallen nicht darunter — aber sobald Sie anfangen, eigene KI-Workflows zu bauen, sollten Sie genau hinschauen.

 

Abb. 7.1 — EU AI Act Zeitplan 2024–2027: Fünf Stichtage, drei Pflichten-Ebenen, eine Botschaft — es ist schon länger Ernst als viele denken

 

7.1 Der EU AI Act als Nutzer — warum er auch für Unternehmen gilt, die keine KI entwickeln

Der häufigste Irrtum, den man in Geschäftsführungsetagen hört, lautet: „Wir entwickeln keine KI, also betrifft uns das nicht.“ Dieser Satz ist falsch. Und er ist teuer.

Die Verordnung (EU) 2024/1689 — kurz EU AI Act — unterscheidet drei Rollen. Erstens den Provider (Anbieter): Das ist Microsoft, OpenAI, Google. Sie entwickeln die KI-Modelle und KI-Systeme. Zweitens den Deployer (Betreiber): Das sind Sie. Jedes Unternehmen, das ein KI-System für eigene Zwecke einsetzt oder es seinen Mitarbeitern bereitstellt, ist Deployer. Drittens den User (Endnutzer): Das sind Ihre Mitarbeiter, die Copilot, Bing oder Azure OpenAI direkt verwenden.

Der Unterschied zwischen Provider und Deployer klingt akademisch. Er ist es nicht. Microsoft als Provider muss die technische Dokumentation bereitstellen, die Konformitätsbewertung für das KI-System durchführen und die Transparenzpflichten des Systems selbst erfüllen. Sie als Deployer müssen sicherstellen, dass das System in Ihrem Unternehmenskontext korrekt eingesetzt wird, die Mitarbeiter qualifiziert sind, menschliche Aufsicht existiert und verbotene Praktiken nicht stattfinden.

Art. 3 Nr. 4 definiert den Deployer als „eine natürliche oder juristische Person […], die ein KI-System unter ihrer eigenen Verantwortung für einen anderen als den persönlichen Nicht-Berufs-Zweck einsetzt“. Das trifft auf jedes Unternehmen zu, das seinen Mitarbeitern Copilot bereitstellt — auch wenn es die Lizenzen nur bei Microsoft kauft und nichts weiter konfiguriert.

Ein Trugschluss mit teuren Folgen ist die Annahme: „Microsoft ist verantwortlich, wir sind nur Nutzer.“ Richtig ist das nur für die technische Seite des KI-Systems. Was Sie daraus machen, wie Sie es einsetzen, für welche Entscheidungen Sie es nutzen und ob Ihre Mitarbeiter ausreichend qualifiziert sind — das liegt in Ihrer Verantwortung. Microsoft liefert das Werkzeug. Sie sind der Schreiner.

Abb. 7.2 — EU AI Act Ampel: Was verboten ist, was Hochrisiko bedeutet und wo Copilot als Produktivitätstool einzuordnen ist

Der AI Act hat für Deployer sehr konkrete Ansatzpunkte in Art. 26. Dort steht unter anderem, dass Betreiber sicherstellen müssen, dass die Personen, die das KI-System überwachen, die Kompetenz dafür besitzen. Das ist keine Empfehlung — das ist eine Pflicht. Wer einen Mitarbeiter Copilot nutzen lässt, ohne ihn zu schulen, erfüllt diese Pflicht nicht.

Besonders relevant für die Praxis: Der AI Act unterscheidet nicht, ob Sie Copilot für Textzusammenfassungen nutzen oder für automatisierte Entscheidungen über Mitarbeiter. Die Rolle als Deployer ist dieselbe. Was sich ändert, sind die Pflichten — je nach Risikoklasse des Einsatzes. Und genau das müssen Sie verstehen und dokumentieren.

Das Missverständnis hat System. Wenn Microsoft auf seiner Webseite schreibt, dass Copilot den AI Act berücksichtigt, und wenn der Microsoft-Vertrieb Ihnen versichert, dass alle Compliance-Anforderungen erfüllt seien, dann ist das korrekt — für Microsoft. Für den Anbieter. Der Anbieter hat seine Pflichten erfüllt. Das ist wie zu sagen, das Auto ist nach StVZO zugelassen — stimmt. Das entbindet Sie trotzdem nicht vom Führerschein. Und wenn Sie das Auto fahren, ohne einen zu haben, wird der Fahrzeughersteller nicht bußen zahlen.

Ein weiterer Irrtum, der sich hartnäckig hält: „Der AI Act gilt erst ab 2026, wir haben noch Zeit.“ Die Verbote gelten seit Februar 2025. AI Literacy ist eine Pflicht, die heute gilt. GPAI-Regeln gelten ab August 2025. Nur die Hochrisiko-Pflichten nach Annex III haben einen Stichtag in 2026 — und selbst dafür braucht die Vorbereitung ein Jahr. Wer im Frühjahr 2026 anfängt, wird den Termin verpassen. Nicht wegen mangelnden Willens, sondern wegen mangelnder Zeit.

Zur Frage, wie viel Aufwand AI-Act-Compliance für ein durchschnittliches Unternehmen bedeutet: Das hängt stark davon ab, was Sie mit KI machen. Ein Unternehmen, das Copilot M365 für Produktivität einsetzt und keine eigenen KI-Anwendungen baut, kommt mit vertretbarem Aufwand durch. Schulungsprogramm, interne Richtlinie, KI-Inventar, Aufsichtsperson benennen — das ist in einem Quartal erledigt. Ein Unternehmen, das Azure OpenAI für eigene Applikationen in Hochrisiko-Bereichen nutzt, hat einen deutlich größeren Aufwand vor sich. Der erste Schritt ist immer derselbe: KI-Inventar anlegen und Risikoklassen bestimmen.

⚠️ RISIKO — Die „Microsoft regelt das“-Falle

Ein mittelständischer Maschinenbauer stellt seinem Vertriebsteam Copilot bereit. Acht Monate später zeigt eine Prüfung: keine Schulungsnachweise, keine Nutzungsrichtlinie, kein Nachweis menschlicher Aufsicht bei automatisierten Berichten. Die Antwort der Geschäftsführung: „Das hat Microsoft doch alles berücksichtigt.“ Hat Microsoft nicht. Microsoft hat für sein System die Konformitätspflichten erfüllt. Was der Betreiber daraus macht — wer es wie nutzt, ob Mitarbeiter qualifiziert sind, ob verbotene Praktiken ausgeschlossen sind — das ist Betreiberpflicht. Art. 26 ist eindeutig. Unwissenheit schmälert das Bußgeld nicht.

 

7.2 Risikoklassen — welche Einstufung Ihre Microsoft-KI-Tools trifft

Der EU AI Act sortiert KI-Systeme in vier Risikoklassen. Die Einstufung bestimmt, was Sie tun müssen. Falsch eingestuft — falsch vorbereitet. Und „falsches Gefühl der Sicherheit“ ist die teuerste Form des Compliance-Irrtums.

Verbotene KI-Praktiken (Art. 5) sind komplett untersagt. Hochriskante KI-Systeme (Art. 6, Annex III) sind erlaubt, aber mit erheblichen Pflichten verbunden. KI mit begrenztem Risiko (Art. 50) unterliegt primär Transparenzpflichten. KI mit minimalem Risiko bleibt weitgehend ungeregelt. Die meisten Microsoft-Produkte im Standard-Unternehmenseinsatz landen in der dritten Kategorie: begrenzt riskant, Transparenzpflichten, fertig.

Wo Copilot M365 einzuordnen ist: Als reine Produktivitätsanwendung — Texte zusammenfassen, E-Mail-Entwürfe erstellen, Teams-Meetings transkribieren — ist Copilot kein Hochrisiko-System. Es trifft keine wesentlichen Entscheidungen über Personen, es ist nicht in kritische Infrastruktur eingebunden, es fällt nicht unter Annex III. Das bedeutet: Sie müssen keinen Konformitätsnachweis erbringen. Sie müssen aber sicherstellen, dass Nutzer wissen, dass sie mit KI arbeiten, und dass eine interne Nutzungsrichtlinie existiert.

Abb. 7.3 — Microsoft KI-Produkte nach AI-Act-Risikoklasse: Wer unbedenklich ist, wer Aufmerksamkeit braucht und wer nicht in den Unternehmenskontext gehört

Wann Copilot doch hochriskant wird: Sobald Sie Copilot oder Azure OpenAI in Entscheidungsprozesse einbinden, die Annex III berühren. Konkret: Wenn die KI-Ausgabe direkt in HR-Entscheidungen einflügt — Einstellungen, Entlassungen, Beurteilungen — liegt Hochrisiko vor. Wenn Copilot Studio einen Chatbot erzeugt, der Kreditwürdigkeit bewertet, liegt Hochrisiko vor. Wenn Azure OpenAI API-Aufrufe in kritische Infrastruktur eingebettet sind, liegt Hochrisiko vor.

GPAI-Modelle sind eine eigene Kategorie nach Art. 51–55. General Purpose AI Models — also Modelle mit sehr breitem Einsatzbereich wie GPT-4 — haben eigene Pflichten für die Anbieter. Als Nutzer von Azure OpenAI sind Sie nicht direkt Adressat der GPAI-Anbieter-Pflichten. Aber: Sie nutzen ein GPAI-Modell, und das hat Konsequenzen. Sie müssen die Nutzungsbedingungen von Microsoft einhalten, Ihre Einsatzszenarien klassifizieren und sicherstellen, dass Ihre Anwendung die GPAI-Grenzen nicht überschreitet.

Besonders relevant: GPT-4 überschreitet nach derzeitigem Kenntnisstand die Schwelle von 10^25 FLOP Training — das macht es zum GPAI-Modell mit systemischen Risiken. Microsoft als Anbieter unterliegt verschärften Aufsichtspflichten. Als Nutzer müssen Sie sicherstellen, dass Ihre Einsatzszenarien diese systemischen Risiken nicht verstärken. Massenskalierung ohne menschliche Aufsicht, Nutzung für kritische Entscheidungen ohne Prüfung — das ist der Bereich, in dem Nutzer-Mitverantwortung entsteht.

Ein wichtiger Hinweis zur Kategorisierung: Der AI Act verwendet den Begriff „KI-System“ sehr weit. Es müssen nicht nur eigenständige KI-Produkte wie Copilot gemeint sein — auch in andere Software eingebettete KI-Funktionen können darunter fallen. Power Automate-Flows mit KI-Komponenten, Dynamics 365-Module mit ML-Prädiktionen, SAP-Erweiterungen mit Azure-Konnektoren — all das kann unter den AI Act fallen, wenn es eine Entscheidungsfunktion übernimmt. Das KI-Inventar muss deshalb breiter angesetzt werden als nur „uns lizenzierten Copilot-Produkte“.

Die Einstufung eines KI-Systems ist keine einmalige Aufgabe — sie muss regelmäßig überprüft werden. Ein Copilot-basierter Workflow, der heute für Textzusammenfassungen genutzt wird, kann morgen — weil jemand eine gute Idee hatte — für Mitarbeiterbeurteilungen verwendet werden. Aus geringem Risiko wird schlagartig Hochrisiko. Ohne Überprüfungsprozess merkt das niemand, bis es zu spät ist. Eine jährliche Review aller KI-Systeme im KI-Inventar ist das Minimum.

ℹ️ HINWEIS FÜR DSBs — Wo AI Act und DSGVO sich überschneiden

Der AI Act ist kein Ersatz für die DSGVO — er ist eine Ergänzung. Beide gelten gleichzeitig, und beide haben Bereiche, wo sie sich überschneiden. Konkret: Eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO und eine Fundamentalrechte-Folgenabschätzung (FRIA) nach AI Act können in einem Dokument kombiniert werden. Das spart Aufwand und ergibt ein vollständigeres Bild. Transparenzpflichten nach Art. 13/14 DSGVO und Art. 50 AI Act ergänzen sich. Protokollierungspflichten nach Art. 30 DSGVO und Art. 12 AI Act können in einem Verzeichnis zusammengeführt werden. Wer die DSGVO gut umsetzt, hat die Grundlage — der AI Act fügt neue Schichten hinzu.

 

Verbotene KI-Praktiken nach Art. 5 EU AI Act

Verbotene Praktik	Beschreibung	Für Microsoft-KI-Nutzer relevant?	Was zu prüfen ist
Social Scoring	Bewertung oder Einstufung von Personen nach Verhalten, persönlichen Eigenschaften oder sozioökonomischen Merkmalen	Ja — wenn Copilot-Outputs in Beurteilungssysteme einflügen	Wird KI-Output zur Mitarbeiterbewertung nach Charakter oder Verhalten verwendet?
Unterbewusste Manipulation	Techniken, die das Unterbewusstsein oder Schwachstellen ansprechen, um Verhalten zu beeinflussen	Begrenzt — bei Copilot Studio-Chatbots	Sind eigene Copilots so gestaltet, dass sie Nutzer zu Entscheidungen drängen?
Echtzeit-Biometrie öffentlicher Raum	Live-Gesichtserkennung und biometrische Identifizierung in öffentlichen Räumen	Nein — nicht Bestandteil von Copilot M365	Kein Handlungsbedarf, sofern keine Kamera-Analyse-Lösungen eingesetzt werden
Biometrische Kategorisierung	Kategorisierung nach Rasse, politischer Meinung, Gewerkschaftszugehörigkeit etc.	Ja — wenn Mitarbeiterdaten ausgewertet werden	Werden Mitarbeiterdaten durch KI nach schützenswürdigen Merkmalen sortiert?
Emotion-Erkennung Arbeitsplatz	Erkennung von Emotionen bei Mitarbeitern oder Schülern in Einrichtungen	Ja — manche Meeting-Analyse-Tools	Werden Teams-Aufzeichnungen auf emotionale Zustände von Mitarbeitern analysiert?

Tab. 7.1 — Verbotene KI-Praktiken nach Art. 5 AI Act: Für die meisten Copilot-Einsätze kein Problem — sobald HR-Analytik ins Spiel kommt, wird es eng

 

7.3 Verbote und Hochrisiko — was Sie nicht tun dürfen

Verbote sind klar. Seit Februar 2025 gelten die Art.-5-Verbote ohne Übergangszeit. Unternehmen, die zum Zeitpunkt des Stichtags verbotene Praktiken betrieben haben, hatten keine Schonfrist. Das ist keine Besonderheit des AI Acts — so funktioniert EU-Recht: Entweder Sie erfüllen es, oder Sie tun es nicht.

Für den typischen Copilot-Einsatz gilt: Die direkten Verbote sind nicht das primäre Problem. Copilot transkribiert keine Biometrie in öffentlichen Räumen. Copilot bewertet nicht unterbewusst Mitarbeiter nach Charaktermerkmalen. Wo es kritisch wird, ist die eigene Kreativität der IT-Abteilung: Sobald Copilot Studio, Power Automate oder Azure OpenAI API genutzt werden, um eigene Prozesse zu automatisieren, kann schnell ein Einsatz entstehen, der in den Verbotsbereich fällt oder zumindest in die Hochrisiko-Grauzone.

Die Grauzone Mitarbeiterüberwachung: Produktivitätsanalysen auf Basis von Microsoft Viva Insights sind ein gutes Beispiel für grenzwertige Anwendungen. Viva Insights ist kein KI-System im Sinne des AI Acts — es ist ein Analyse-Dashboard. Aber wenn Sie die Insights-Daten in einen Copilot-Workflow einbinden, der Mitarbeiter nach Produktivitätsprofilen bewertet und entsprechende Empfehlungen ausgibt, kommen Sie dem Social-Scoring-Verbot gefährlich nah. Der Betriebsrat wird das auch so sehen.

Abb. 7.4 — Hochrisiko-Erkennungs-Prozess: Vier Fragen bestimmen, ob Ihre KI-Anwendung besondere Pflichten auslöst

Hochrisiko ist nicht automatisch verboten — es ist reguliert. Annex III des AI Acts listet die Bereiche, in denen KI als Hochrisiko gilt: Biometrie, kritische Infrastruktur, Bildung, Beschäftigung, essentielle private und öffentliche Dienstleistungen (Kredit, Versicherung), Strafverfolgung, Migration, Verwaltung der Justiz.

Im Unternehmenskontext besonders relevant ist der Bereich Beschäftigung. Art. 6 Abs. 2 i.V.m. Annex III Nr. 4 stellt klar: KI-Systeme, die zur Einstellung, Beurteilung, Versetzung oder Entlassung von Mitarbeitern eingesetzt werden, sind Hochrisiko-Systeme. Das betrifft jeden, der Copilot oder Azure OpenAI in HR-Prozesse einbindet — auch wenn der Mensch am Ende entscheidet. Sobald die KI eine maßgebliche Rolle in der Entscheidungsvorbereitung spielt, ist das System hochriskant.

Was Hochrisiko-Einstufung konkret bedeutet: Sie müssen vor der Inbetriebnahme eine Konformitätsbewertung durchführen. Sie müssen das System im EU-KI-Register eintragen (ab August 2026). Sie müssen eine Fundamentalrechte-Folgenabschätzung (FRIA) erstellen. Sie müssen eine dedizierte Person benennen, die die menschliche Aufsicht übernimmt. Sie müssen Logs führen, die Entscheidungen nachvollziehbar machen. Das ist kein Checkbox-Übungszettel — das ist operativer Aufwand.

Ein Blick auf die Konformitätsbewertung: Für die meisten Hochrisiko-Systeme ist die Konformitätsbewertung eine Selbstbewertung des Betreibers — keine externe Zertifizierung. Das klingt nach weniger Aufwand, ist aber eine zweischneidige Sache. Erstens müssen Sie tatsächlich prüfen, ob Ihr System die Anforderungen des AI Acts erfüllt: Transparenz, Datenqualität, Robustheit, menschliche Aufsicht, Prüfung der Trainingsdaten. Zweitens müssen Sie diese Prüfung dokumentieren. Und drittens: Im Streitfall müssen Sie nachweisen, dass die Selbstbewertung korrekt war. Eine schlecht dokumentierte Selbstbewertung ist schlechter als keine — sie zeigt, dass Sie die Anforderungen kennen, aber nicht erfüllt haben.

Der Begriff „menschliche Aufsicht“ verdient eine eigene Erörterung, weil er so oft missverstanden wird. Menschliche Aufsicht nach Art. 14 bedeutet nicht, dass ein Mensch jede einzelne KI-Entscheidung per Hand bestätigt — das würde den Zweck der Automatisierung aufheben. Es bedeutet, dass das System so gestaltet ist, dass Menschen — in einer Weise, die ihrer Ausbildung und ihrem Kontext entspricht — die Ausgaben des Systems verstehen, überprüfen und im Zweifelsfall ignorieren oder korrigieren können. Die Aufsichtsperson muss wissen: Was tut dieses System? Welche Faktoren beeinflusst es? Wann sollte ich stutzig werden? Und sie muss tatsächlich in der Lage sein zu stutzen — nicht nur formal benannt sein.

⚠️ RISIKO — HR-Automatisierung: Wo Copilot zum Hochrisiko-System wird

Ein Unternehmen baut mit Copilot Studio einen internen Assistenten, der bei Bewerber-Einschätzungen hilft: Die KI analysiert Bewerbungsunterlagen, vergleicht sie mit einem Profil, erstellt eine Empfehlung und gibt eine „Eigungsquote“ aus. Der HR-Manager schaut auf die Zahl und entscheidet. Das ist ein Hochrisiko-System nach Annex III Nr. 4. Es spielt keine Rolle, dass der Mensch formal entscheidet — die KI hat maßgeblichen Einfluss auf die Entscheidung. Ohne Konformitätsbewertung, FRIA und Protokollierung ist der Betrieb illegal. Bußgelder bis 15 Mio. EUR oder 3 % des Jahresumsatzes sind möglich. Dazu kommt Reputationsschaden. Und die Frage, wie man das dem Betriebsrat erklärt, der das nie abgesegnet hatte.

 

Hochrisiko-Szenarien mit Microsoft-KI

Einsatzszenario	Risiko-Kategorie	KI-Tool	Pflichten	Handlungsbedarf
Bewerberauswahl mit KI-Scoring	Hochrisiko (Annex III Nr. 4)	Azure OpenAI API / Copilot Studio	FRIA, Konformitätsbewertung, Registrierung, Protokollierung	Sofort prüfen — wahrscheinlich Umbau nötig
Mitarbeiterproduktivität analysieren und priorisieren	Grauzone / mögl. Hochrisiko	Viva Insights + Azure OAI	Betriebsrat einbinden, Verbot prüfen (Social Scoring)	DSGVO + AI Act Analyse erforderlich
Kreditantragsunterstützung durch KI	Hochrisiko (Annex III Nr. 5)	Azure OpenAI API	Konformitätsbewertung, FRIA, menschliche Aufsicht	Prüfen ob bereits im Einsatz
Copilot für Textzusammenfassungen	Geringes Risiko	Copilot M365	Nutzungsrichtlinie, AI Literacy, Transparenzhinweis	Geringer Aufwand — schnell umsetzbar
Copilot Studio-Chatbot für Kundendienst	Geringes bis mittleres Risiko	Copilot Studio	KI-Offenlegung, Datenschutz, Opt-out-Option	Transparenzpflicht sicherstellen

Tab. 7.2 — Hochrisiko-Szenarien mit Microsoft-KI: Die Spalte „Handlungsbedarf“ ist der Grund, warum dieses Kapitel existiert

 

7.4 Nutzerpflichten — was Sie als Deployer konkret leisten müssen

Art. 26 des EU AI Acts listet die Deployer-Pflichten in einer Art, die man „missverstehlich klar“ nennen könnte: jeder Satz ist eindeutig, aber die Gesamtheit wirkt so selbstverständlich, dass viele Unternehmen davon ausgehen, sie erfüllten die Pflichten schon. Das ist selten der Fall.

Art. 26 Abs. 1 verpflichtet Deployer zu geeigneten technischen und organisatorischen Maßnahmen (TOM) für KI. Das klingt wie DSGVO — und ist auch genauso gemeint. Die TOM müssen den Einsatz gewährleisten, der den Anforderungen des AI Acts entspricht. Konkret: Logging der KI-Nutzung für Hochrisiko-Systeme, Datenqualitätssicherung bei Eingabedaten, technische Dokumentation vorhalten.

Abb. 7.5 — Deployer vs. User-Pflichten nach Art. 26/27 AI Act: Zwei Rollen, zwei Pflichten-Profile, ein gemeinsamer Nenner: AI Literacy

Art. 26 Abs. 2 fordert, dass Deployer die notwendigen menschliche Aufsicht sicherstellen. Art. 14 beschreibt, was das bedeutet: Personen, die das System überwachen, müssen in der Lage sein, die Funktionsweise zu verstehen, Anomalien zu erkennen und im Zweifelsfall zu übersteuern. Das ist keine Formalität — die Aufsichtsperson muss tatsächlich qualifiziert sein. Wer einen Sachbearbeiter zur „KI-Aufsicht“ erklärt, der nicht weiß, wie das System Empfehlungen generiert, erfüllt Art. 14 nicht.

Art. 26 Abs. 3 verpflichtet Deployer zur Information der betroffenen Personen. Wenn ein Hochrisiko-KI-System Entscheidungen vorbereitet, die eine Person betreffen, muss diese Person informiert werden. Das trifft direkt auf HR-Szenarien zu: Bewerber müssen wissen, wenn KI an ihrer Beurteilung beteiligt war.

Art. 26 Abs. 4 ist der Abschnitt, den viele überlesen: Die Verpflichtung zur Fundamentalrechte-Folgenabschätzung (FRIA) für öffentliche Stellen und bestimmte private Einrichtungen. Für private Unternehmen greift die FRIA-Pflicht bei Hochrisiko-Systemen in bestimmten Bereichen, insbesondere, wenn die Systeme einen breiten Personenkreis betreffen. Banken, Versicherungen, große HR-Arbeitgeber: hier lohnt ein genauer Blick.

Was eine FRIA konkret enthält: Eine Bewertung, wie das KI-System Grundrechte der betroffenen Personen beeinflussen könnte — Recht auf Nichtdiskriminierung, Recht auf Privatsphäre, Recht auf effektiven Rechtsschutz. Das klingt nach Verfassungsrecht und ist es auch — in vereinfachter, auf KI-Anwendungen adaptierter Form. Wenn Ihr HR-KI-System Bewerbungen filtert, muss die FRIA zeigen, dass das System nicht systematisch Personen aufgrund von Merkmalen diskriminiert, die Sie nicht diskriminieren dürfen. Wenn es das doch tut, müssen Sie das wissen — bevor das System live geht.

Die Kosten einer FRIA sind überschaubar, wenn man frühzeitig beginnt. Typisch für ein mittelständisches Unternehmen: ein bis drei Tage Analysework mit einem Spezialisten, danach ein paar Stunden Dokumentationsarbeit. Wer später anfängt — weil das System schon live ist, die Aufsichtsbehörde bereits angefragt hat und der Vorstand gerade im Panik-Modus ist — zahlt mehr. Deutlich mehr. Und hat zusätzlich das Problem, dass das System möglicherweise bereits gegen die Anforderungen verstoßen hat.

💡 TIPP — DSFA und FRIA kombinieren statt doppelt schreiben

Die Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO und die Fundamentalrechte-Folgenabschätzung (FRIA) nach Art. 26 Abs. 4 AI Act überschneiden sich erheblich. Beide prüfen Risiken für Personen, beide erfordern Dokumentation, beide müssen vor dem Einsatz vorliegen. Statt zwei separate Dokumente zu erstellen, empfiehlt sich ein integriertes Dokument: DSFA mit AI-Act-Erweiterungsmodul. Der Vorteil: ein konsistenter Befund, ein Freigabeprozess, ein Archiv. Die meisten Datenschutzbeauftragten werden das bevörzugen — es macht auch ihre Arbeit übersichtlicher.

 

Ein häufig unterschätzter Aspekt der Deployer-Pflichten ist die Verantwortung bei der Konfiguration. Wenn Sie Copilot Studio einsetzen und eigene Copilots konfigurieren, sind Sie nicht nur Nutzer eines fertigen Systems — Sie sind in gewissem Sinne auch Mitgestalter des Systems. Die Konfigurationsentscheidungen, die Sie treffen, beeinflussen das Verhalten des KI-Systems. Welche Datenquellen hat der Copilot Zugriff auf? Welche Antworten sind erlaubt? Welche Prompts werden blockiert? Diese Entscheidungen sind Bestandteil der Deployer-Verantwortung.

Auf die Rolle des Betriebsrats beim AI Act muss an dieser Stelle hingewiesen werden. Das ist ein Kapitel für sich — ausführlich behandelt in Kapitel 5 — aber der Zusammenhang ist relevant: Art. 26 des AI Acts verpflichtet Betreiber zur Information der betroffenen Arbeitnehmer, wenn KI für wesentliche Entscheidungen genutzt wird. Das ergänzt das BetrVG, das in bestimmten Konstellationen die Zustimmung des Betriebsrats erfordert. Wer den Betriebsrat beim KI-Einsatz übergeht, riskiert nicht nur eine Verweigerung der Zustimmung — er riskiert auch, dass die Nutzung des KI-Systems bis zur Einigung ausgesetzt wird. Das hat nichts mehr mit dem AI Act zu tun — es ist deutsches Arbeitsrecht. Aber es trifft denselben Zeitplan.

Protokollierung nach Art. 12: Hochrisiko-KI-Systeme müssen so ausgelegt sein, dass sie automatisch Ereignisse aufzeichnen, die für die spätere Aufsicht relevant sind. Als Deployer müssen Sie sicherstellen, dass diese Logs verfügbar sind und aufbewahrt werden. Für Azure OpenAI bedeutet das: Aktivieren Sie das Logging, konfigurieren Sie Aufbewahrungszeiten und stellen Sie sicher, dass die Logs nicht gelöscht werden, bevor ein eventueller Untersuchungszeitraum abläuft.

Eine häufig unterschatzte Pflicht: Art. 26 Abs. 5 verpflichtet Deployer, Vorfälle und Fehlfunktionen dem Anbieter zu melden. Wenn Copilot systematisch falsche oder schadhafte Outputs produziert, und Sie das bemerken, müssen Sie es melden. Das ist nicht nur ethisch geboten — es ist gesetzliche Pflicht. Ohne dokumentierten Meldeprozess haben Sie auch hier eine Lücke.

Für Copilot M365 als Standardprodukt ist die Protokollierungspflicht für die meisten Unternehmen kein akuter Aufwand — Microsoft verwaltet die Systeme und Logs auf seiner Seite. Die Frage, die Sie sich stellen müssen: Haben Sie Zugriff auf diese Logs, wenn eine Aufsichtsbehörde sie anfragt? Das Microsoft 365 Compliance Center bietet Audit-Logs und eDiscovery-Funktionen — diese müssen aktiv konfiguriert sein, und die Aufbewahrungszeiträume müssen Ihren Anforderungen entsprechen. Der Standard-Aufbewahrungszeitraum von 90 Tagen ist für AI-Act-Compliance nicht ausreichend.

Ein praxisnaher Hinweis zur Implementierungsreihenfolge: Beginnen Sie nicht mit der technischen Infrastruktur. Beginnen Sie mit dem KI-Inventar und der Risikoklassifizierung. Erst wenn Sie wissen, was Sie betreiben und in welche Kategorie es fällt, können Sie die richtigen technischen Maßnahmen bestimmen. Viele Unternehmen machen den Fehler, zunächst einen umfassenden Logging-Stack zu bauen — und dann festzustellen, dass sie keine Hochrisiko-Systeme betreiben und der ganze Aufwand nicht zwingend notwendig war. Oder umgekehrt: Sie haben Hochrisiko-Systeme, aber keine Logs. Das Inventar kommt zuerst.

Pflicht	Artikel	Was konkret zu tun ist	Fälligkeitsdatum	Priorität
Technische und organisatorische Maßnahmen	Art. 26 Abs. 1	TOM-Konzept für KI erstellen, Logging aktivieren, Dokumentation vorhalten	Sofort (Aug 2025 für GPAI, Aug 2026 Hochrisiko)	Hoch
Menschliche Aufsicht sicherstellen	Art. 26 Abs. 2, Art. 14	Qualifizierte Aufsichtsperson benennen, Qualifikation nachweisen	Sofort für alle KI-Systeme	Hoch
Betroffene informieren	Art. 26 Abs. 3, Art. 13	Datenschutz- und KI-Hinweis für betroffene Personen bereitstellen	Sofort — überschneidet sich mit DSGVO	Mittel
Fundamentalrechte-Folgenabschätzung (FRIA)	Art. 26 Abs. 4	FRIA für Hochrisiko-Systeme vor Inbetriebnahme erstellen	Vor Go-Live Hochrisiko-System	Hoch, wenn Hochrisiko
Vorfallmeldung	Art. 26 Abs. 5	Meldeprozess für KI-Vorfälle etablieren, Anbieter informieren	Ab sofort — keine Schonfrist	Mittel
AI Literacy sicherstellen	Art. 4	Schulungsprogramm umsetzen, Nachweise dokumentieren	Ab sofort geltendes Recht	Sehr hoch
KI-Registrierung (Hochrisiko)	Art. 51	Hochrisiko-Systeme im EU-KI-Register eintragen	Ab August 2026	Hoch, wenn Hochrisiko

Tab. 7.3 — Deployer-Pflichten nach AI Act im Überblick: Die Spalte „Priorität“ ist eine ehrliche Einschätzung — nicht eine Aufforderung, den Rest zu ignorieren

 

Abb. 7.6 — AI-Act-Readiness-Entscheidungsbaum: Acht Schritte von „Setzen Sie KI ein?“ bis zur konkreten Pflichtenliste

 

7.5 Zeitplan — alle Stichtage mit konkreten Handlungspflichten

Der AI Act ist kein Kündigungsschreiben mit Auslaufdatum. Er ist ein rollierendes Regelwerk, das mit jedem Stichtag neue Pflichten aktiviert. Wer heute mit dem Verständnis beginnt, ‚Wir müssen erst 2026 aktiv werden’, verpasst, dass zwei entscheidende Stichtage bereits verstrichen sind.

August 2024: In Kraft getreten

Die Verordnung (EU) 2024/1689 wurde am 12. Juli 2024 im Amtsblatt der Europäischen Union veröffentlicht und trat 20 Tage später in Kraft. Ab diesem Moment war klar: Das Regelwerk existiert, und es wird kommen. Unternehmen, die im August 2024 noch nichts unternommen haben, hatten ab diesem Moment keinen guten Grund mehr.

Februar 2025: Verbote gelten — und Governance-Strukturen

Seit dem 2. Februar 2025 sind die Verbote nach Art. 5 rechtswirksam. Wer zu diesem Zeitpunkt verbotene KI-Praktiken betrieben hat, hat seitdem einen Gesetzesverstoß begangen. Die Übergangszeit ist keine Entschuldigung — die Verbote waren seit August 2024 bekannt. Zusätzlich gelten ab Februar 2025 die Anforderungen an Governance-Strukturen nach Art. 64: Mitgliedstaaten müssen nationale Aufsichtsbehörden benennen. Das bedeutet für Unternehmen: Es gibt jetzt tatsächlich eine Behörde, die prüfen kann.

Was Sie bis Februar 2025 hätten getan haben sollen: Prüfung aller aktiven KI-Systeme auf Art.-5-Verbote, Abstellung verbotener Praktiken, erste Schulungsmaßnahmen für AI Literacy, Benennung eines Verantwortlichen für AI-Act-Compliance.

August 2025: GPAI-Modell-Pflichten

Ab August 2025 gelten die Pflichten für General Purpose AI Models nach Kapitel III Abschnitt 2. Das betrifft primär Microsoft als Anbieter von GPT-4 und Azure OpenAI. Aber auch als Nutzer haben Sie jetzt klarere Pflichten: Sie müssen die Nutzungsbedingungen von Microsoft für GPAI-Modelle aktiv prüfen und einhalten. Sie müssen Ihre Einsatzszenarien gegen die GPAI-Einschränkungen abgleichen.

Was Sie bis August 2025 tun müssen: KI-Inventar erstellen (alle genutzten KI-Systeme, Klassifizierung, Einsatzbereich), GPAI-Nutzung dokumentieren, interne KI-Governance-Struktur aufbauen, AI-Literacy-Schulungen anlaufen lassen.

Zur GPAI-Regelung im Detail: Kapitel III Abschnitt 2 des AI Acts verpflichtet Anbieter von GPAI-Modellen zu Transparenz, Urheberrechts-Richtlinien und — bei systemischen Risiken — zu verstärkter Aufsicht. Für Sie als Nutzer bedeutet das konkret: Microsoft muss ab August 2025 für Azure OpenAI eine Modellkarte bereitstellen, die die Fähigkeiten und Einschränkungen des Modells beschreibt. Sie müssen diese Modellkarte für Ihre Compliance-Dokumentation beschaffen und aufbewahren. Es ist ein kleiner Schritt — aber einer, der bei einer Prüfung erwartet wird.

Darüber hinaus gilt ab August 2025 die Pflicht, die eigene Nutzung von GPAI-Modellen so zu dokumentieren, dass sie im Kontext des AI Acts erklärbar ist. Das ist keine aufwendige Analyse — es reicht ein einfacher Eintrag im KI-Inventar: Welches Modell wird genutzt? Für welche Aufgaben? Welche Einschränkungen aus der Microsoft-Nutzungsrichtlinie sind relevant? Wer ist im Unternehmen verantwortlich? Dieser Eintrag ist das Minimalmaß.

Abb. 7.7 — 12-Monate-Sprint zur AI-Act-Compliance: Was in welcher Phase zu tun ist — und was sofort, in dieser Woche

August 2026: Hochrisiko-Systeme

Ab August 2026 müssen Deployer von Hochrisiko-KI-Systemen (Annex III) ihre Pflichten vollständig erfüllen. Konformitätsbewertung, FRIA, Registrierung im EU-KI-Register, Protokollierung, menschliche Aufsicht — all das muss vor dem 12. August 2026 stehen, wenn Sie ein Hochrisiko-System betreiben. Das klingt weit weg. Ist es nicht. Eine Konformitätsbewertung vorzubereiten, die halbwegs belastbar ist, dauert Monate. Wer im Frühjahr 2026 anfängt, hat ein Problem.

Was Sie bis August 2026 tun müssen: Finale Identifikation aller Hochrisiko-Systeme im Unternehmen, Konformitätsbewertung für diese Systeme durchführen, FRIA erstellen, Protokollierungssystem produktiv stellen, qualifizierte Aufsichtspersonen für alle Hochrisiko-Systeme benennen, Registrierung im EU-KI-Register abschließen.

Ein konkreter Blick auf das EU-KI-Register: Dieses öffentliche Verzeichnis — betrieben von der EU-Kommission — soll Transparenz über Hochrisiko-KI-Systeme schaffen. Deployer müssen ihre Hochrisiko-Systeme dort registrieren. Die Registrierung ist kein bürokratischer Selbstzweck: Sie ermöglicht es betroffenen Personen und Behörden, herauszufinden, welche KI-Systeme in welchen Bereichen eingesetzt werden. Für Sie als Unternehmen bedeutet das: Eine fehlende Registrierung ist nicht nur ein Bußgeldrisiko — sie signalisiert der Aufsichtsbehörde, dass die übrigen Compliance-Maßnahmen vermutlich auch nicht stimmen.

Wer noch kein Hochrisiko-System betreibt, sollte August 2026 trotzdem im Blick haben — weil bis dahin Klarheit herrschen muss, ob man eines betreibt oder nicht. Die Frage „Betreiben wir Hochrisiko-Systeme?“ ist keine triviale. Es braucht eine strukturierte Analyse, und diese Analyse braucht Zeit. Unternehmen, die im Frühjahr 2026 mit der Analyse beginnen, und dann feststellen, dass doch Hochrisiko-Systeme vorhanden sind, haben keinen ausreichenden Zeitpuffer mehr für Konformitätsbewertung und FRIA.

August 2027: Volle Geltung

Ab August 2027 gilt der AI Act vollständig — einschließlich der älteren Hochrisiko-Systeme nach der ursprünglichen Annex-I-Liste (Maschinen, Fahrzeuge, medizinische Geräte). Für die meisten IT-Verantwortlichen ist dieser Stichtag weniger relevant als August 2026. Aber er ist der Punkt, an dem auch die letzten Übergangsregelungen enden. Ab August 2027 gibt es keine Begründung mehr, die bei einer Behörde zieht.

Was konkret bis wann umgesetzt sein muss

Der Zeitstrahl allein ist keine Handlungsanleitung. Was Unternehmen brauchen, ist eine konkrete Antwort auf die Frage: Was müssen wir bis zu welchem Datum tatsächlich erledigt haben — nicht als abstrakte Pflicht, sondern als abgehakter Punkt auf einer Checkliste?

Bis August 2025: GPAI-Modell-Transparenz intern sicherstellen

Auch wenn Sie kein KI-Entwickler sind, gilt: Wer Azure OpenAI über die API direkt nutzt, interagiert mit einem GPAI-Modell. Die Transparenzpflichten nach Art. 50 EU AI Act gelten bereits ab August 2025. Ob und wie Ihr Unternehmen diese intern umsetzt, muss bis dahin geklärt sein. Konkret heißt das: Haben alle Mitarbeiter, die Azure OpenAI oder ähnliche GPAI-Systeme nutzen, eine Schulung erhalten? Wissen sie, dass KI-generierte Inhalte als solche gekennzeichnet werden müssen? Ist diese Anforderung in der KI-Richtlinie des Unternehmens verankert?

Microsoft stellt ab August 2025 für Azure OpenAI eine Modellkarte bereit, die Fähigkeiten und Einschränkungen des Modells beschreibt. Diese Modellkarte müssen Sie aktiv beschaffen und in Ihrer Compliance-Dokumentation ablegen — nicht als zukünftige Aufgabe, sondern vor dem Stichtag. Es ist ein kleiner Schritt, aber einer, der bei einer Prüfung als erstes verlangt wird.

Bis August 2026: Hochrisiko-Pflichten für Annex-III-Systeme

Ab August 2026 gelten die vollen Pflichten für Hochrisiko-KI-Systeme nach Annex III. Wer Copilot für HR-Entscheidungen nutzt — Auswahl, Beurteilung, Entlassung — ist als Deployer direkt betroffen. Sie brauchen bis dahin drei Dinge: Erstens eine schriftliche Bewertung, ob Ihre Copilot-Nutzung Hochrisiko-Tatbestände erfüllt. Zweitens, falls ja: eine Fundamentalrechte-Folgenabschätzung, eine Konformitätsbewertung und eine technische Dokumentation. Drittens, falls nein: einen dokumentierten Entscheid, der begründet, warum kein Hochrisiko vorliegt.

Das Nein ist also keine Freifahrt. Auch wer zu dem Ergebnis kommt, kein Hochrisiko-System zu betreiben, muss dieses Ergebnis begründen und dokumentieren. Eine Aufsichtsbehörde, die prüft und keinerlei Analyse vorfindet, wird nicht einfach annehmen, dass kein Hochrisiko vorliegt — sie wird annehmen, dass keine Analyse stattgefunden hat.

Bis August 2027: Vollständiges KI-Inventar und Abschluss-Audit

Ab 2027 gilt der EU AI Act vollständig — auch für KI-Systeme, die bisher unter Übergangsregeln fielen. Für die meisten Unternehmen bedeutet das: Spätestens jetzt muss ein vollständiges KI-Inventar vorliegen, jedes System muss klassifiziert sein, und die Dokumentation muss aktuell und revisionssicher abgelegt sein. August 2027 ist kein neuer Starttermin — er ist die Endstation der Übergangsphase.

Ein Hinweis zur nationalen Umsetzung, der häufig missverstanden wird: Der EU AI Act ist eine EU-Verordnung. Er gilt unmittelbar — ohne nationale Umsetzung, ohne Wartezeit auf deutsches Ausführungsgesetz. Die Zuständigkeit der nationalen Marktüberwachungsbehörden wird durch nationales Recht geregelt, aber die Pflichten selbst gelten bereits. In Deutschland ist die Bundesnetzagentur als federlführende Behörde im Aufbau. Warten Sie nicht auf die nationale Konkretisierung. Handeln Sie auf Basis der Verordnung selbst — denn die gilt.

 

Stichtag	Was gilt ab dann	Was zu erledigen ist	Warum es dringend ist
August 2024	AI Act in Kraft	Projekte starten, Zuständige benennen	Basiswissen aufbauen — sollte erledigt sein
Februar 2025	Art.-5-Verbote, Governance-Strukturen	Art.-5-Prüfung abschließen, erste Schulungen	Bereits verstrichen — Nachholen erforderlich
August 2025	GPAI-Modell-Pflichten (Kap. III)	KI-Inventar, GPAI-Compliance, Governance	Aktuell läuft die Uhr — 8 Monate Zeit
August 2026	Hochrisiko-Pflichten (Annex I + III)	FRIA, Konformitätsbewertung, Registrierung	Vorbereitung braucht 12+ Monate
August 2027	Volle Geltung aller Hochrisiko-Systeme	Audit, Dokumentation komplett	Endstation — kein Puffer mehr

Tab. 7.4 — AI-Act-Stichtage im Überblick: Die Spalte „Warum es dringend ist“ ist eine Erinnerung daran, dass 2026 näher ist als 2027

 

Abb. 7.8 — AI Act vs. DSGVO: Wo sich Pflichten überschneiden, wo jedes Gesetz allein gilt und wie man Synergien nutzt

 

7.6 Dokumentation und AI Literacy — was nachweisbar vorliegen muss

Wer dem AI Act begegnet, begegnet einem Gesetz, das auffällig oft das Wort „nachweisbar“ oder „dokumentiert“ verwendet. Das ist kein Zufall. Die Gesetzgeber wissen, dass Compliance nur dann prüfbar ist, wenn sie dokumentiert ist. Was nicht aufgeschrieben ist, hat nicht stattgefunden — jedenfalls nicht aus Sicht einer Aufsichtsbehörde.

AI Literacy: Art. 4 und was er bedeutet

Art. 4 des EU AI Acts verpflichtet Betreiber dazu sicherzustellen, dass Personen, die mit KI-Systemen arbeiten, über ausreichende KI-Kompetenz verfügen. Das gilt für alle Mitarbeiter, die KI einsetzen — nicht nur für IT-Spezialisten. Ausreichende Kompetenz ist dabei kein absoluter Maßstab, sondern relativ zur konkreten Aufgabe.

Ein Mitarbeiter, der Copilot für Textzusammenfassungen nutzt, braucht weniger KI-Kompetenz als ein Entwickler, der Azure OpenAI-Workflows baut. Aber auch der einfache Nutzer muss verstehen: Was ist KI? Was kann sie nicht? Wo liegen Grenzen? Was darf er damit nicht tun? Das sind Grundkenntnisse — kein Informatikstudium.

Abb. 7.9 — AI Literacy-Anforderungen nach Zielgruppe: Vier Profile, vier Schulungsformate, eine gemeinsame Pflicht

Das wichtigste an Art. 4 ist der Nachweisaspekt. Es genügt nicht, Schulungen anzubieten — es müssen Schulungsnachweise vorliegen. Wer an einer Schulung teilgenommen hat, welche Inhalte abgedeckt wurden, wann die nächste Auffrischung fällig ist — das muss dokumentiert sein. Bedenken Sie: Im Fall einer Prüfung wird eine Behörde diese Nachweise verlangen. Ein E-Learning-Kurs in Microsoft Viva Learning ohne Teilnahmeliste ist kein Nachweis.

Was als AI Literacy gilt, ist nicht statisch. Der Gesetzgeber hat bewusst keine genaue Definition vorgegeben, weil KI-Systeme zu unterschiedlich sind und sich zu schnell verändern. Stattdessen wird ein risikobasierter Ansatz erwartet: Je höher die Auswirkung des KI-Systems auf Personen, desto höher muss die Kompetenz der beteiligten Personen sein. Ein Mitarbeiter, der mit Copilot E-Mails zusammenfasst, braucht andere Kenntnisse als ein HR-Manager, der KI-gestützte Bewerberanalysen nutzt. Das Schulungsprogramm sollte diese Unterschiede abbilden.

Praktische Empfehlung für AI-Literacy-Programme: Bauen Sie es dreistufig auf. Stufe eins für alle: Grundlagen (Was ist KI, was nicht, Grenzen, verbotene Nutzung), zwei Stunden, E-Learning mit abschließendem Nachweis. Stufe zwei für Fachbereiche und mittleres Management: Risiken und Pflichten im eigenen Kontext, halber Tag, geleiteter Workshop. Stufe drei für IT, DSB, Compliance: Technische Tiefe, rechtliche Details, Governance-Verantwortung, ein voller Tag. Das Programm einmal durchführen und alle drei Jahre wiederholen — mit jährlicher Aktualisierung für neue Mitarbeiter.

Zur Abgrenzung zwischen AI Literacy und Datenschutz-Schulungen: AI-Literacy-Schulungen nach Art. 4 AI Act und DSGVO-Schulungen nach Art. 39 DSGVO sind rechtlich separate Anforderungen, können aber inhaltlich kombiniert werden. Viele der relevanten Themen überschneiden sich: Was ist personenbezogenes Datum, was ist sensitives Datum, welche Rechte haben Betroffene, was darf ich mit KI-Daten nicht tun. Eine kombinierte Schulung ist effizienter und konsistenter als zwei separate Schulungen mit überlappenden Inhalten.

Was „AI Literacy“ in der Praxis bedeutet

Art. 4 EU AI Act verlangt, dass Unternehmen sicherstellen, dass ihr Personal über „ausreichende KI-Kompetenz“ verfügt. Die Norm ist absichtlich vage — „ausreichend“ hängt von der konkreten KI-Nutzung ab. Das klingt zunächst unbefriedigend. Aber es ist tatsächlich sinnvoll: Ein Unternehmen, das Copilot für E-Mail-Zusammenfassungen einsetzt, hat andere Anforderungen als eines, das KI-gestützte Kreditentscheidungen trifft.

Was das für verschiedene Rollen in Ihrem Unternehmen bedeutet:

Mitarbeiter, die Copilot täglich nutzen: Grundlagenschulung — Was ist KI, wo liegen ihre Grenzen, was darf ich damit nicht tun, wie erkenne ich Fehler in KI-Ausgaben. Dauer: 30–60 Minuten, mit Nachweis.

Führungskräfte, die KI-gestützte Entscheidungen treffen (z. B. HR): Vertiefungsschulung — Risikoklassen, Diskriminierungsrisiken, Aufsichtspflichten, Haftung. Dauer: 90 Minuten, mit Nachweis.

IT-Administratoren, die KI-Systeme konfigurieren: Technische Schulung — Logging, Zugriffskontrolle, Datenanforderungen, Sicherheitseinstellungen. Dauer: halber Tag.

Compliance-Verantwortliche und DSB: Rechtliche Tiefe — AI Act, DSGVO-Schnittstellen, Dokumentationspflichten, Meldeverpflichtungen. Dauer: voller Tag.

Was Sie dokumentieren müssen, geht über eine einfache Teilnehmerliste hinaus. Für jede Schulungsmaßnahme sollte festgehalten sein: Datum und Dauer der Schulung, Inhalt und Schulungsformat (E-Learning, Präsenz, Workshop), welche Rollen und Abteilungen teilgenommen haben, und wann eine Auffrischung geplant ist. Zusätzlich sollte dokumentiert sein, wie Sie bestimmt haben, welches Schulungsniveau für welche Rolle ausreicht. Dieser Begründungsschritt wird bei einer Behördenprüfung erwartet — und von den meisten Unternehmen nicht erbracht.

Praktische Empfehlung: Verknüpfen Sie die AI-Literacy-Anforderungen mit dem bestehenden Schulungsmanagement Ihres Unternehmens — ob das ein LMS, SharePoint-Listen oder Excel-Tracking ist. Erstellen Sie drei Schulungspfade: Endnutzer (30–60 Minuten), Führungskräfte (90 Minuten), IT und Compliance (halber Tag). Halten Sie die Absolventen-Liste aktuell und stellen Sie sicher, dass neue Mitarbeiter die Schulung vor dem ersten KI-Einsatz absolvieren — nicht irgendwann im ersten Quartal.

KI-Inventar und Systemdokumentation

Ein KI-Inventar ist das Fundament jeder AI-Act-Compliance. Es listet alle im Unternehmen genutzten KI-Systeme, ihre Klassifizierung nach AI Act, ihren Einsatzbereich, die verantwortlichen Personen und den Status der Compliance-Maßnahmen. Ohne KI-Inventar können Sie nicht wissen, ob Sie Hochrisiko-Systeme betreiben. Und ohne dieses Wissen können Sie die richtigen Maßnahmen nicht ergreifen.

Für Hochrisiko-Systeme fordert Art. 11 eine technische Dokumentation, die vom Anbieter bereitgestellt werden muss. Als Deployer müssen Sie sicherstellen, dass diese Dokumentation vorliegt und aktuell ist. Microsoft stellt für Azure OpenAI entsprechende Dokumentationen bereit — aber Sie müssen sie aktiv beschaffen und aufbewahren.

Abb. 7.10 — GPAI-Modell-Pflichten: Was Microsoft als Anbieter tun muss und was Sie als Nutzer von Azure OpenAI konkret tun müssen

Art. 51 regelt die Registrierungspflicht: Hochrisiko-KI-Systeme müssen in der EU-Datenbank für KI-Systeme eingetragen werden. Das betrifft Deployer ab August 2026. Die Registrierung ist kein Selbstzweck — sie macht KI-Systeme für Aufsichtsbehörden auffindbar und nachvollziehbar. Wer nicht registriert ist, riskiert nicht nur ein Bußgeld für die fehlende Registrierung — sondern signalisiert der Behörde auch, dass die übrigen Pflichten wahrscheinlich ebenfalls nicht erfüllt wurden.

Ein KI-Inventar ist keine komplizierte Datenbank — es kann als Excel-Tabelle beginnen. Was jeder Eintrag enthalten sollte: Name des Systems, Anbieter, Version, Einsatzbereich im Unternehmen, Risikoklasse nach AI Act, betroffene Personengruppen, verantwortliche Person im Unternehmen, Status der Compliance-Maßnahmen, Datum der letzten Überprüfung. Das ist in einem Nachmittag für ein Unternehmen mit zehn KI-Systemen erstellt. Was nicht in einem Nachmittag gemacht werden kann: die Risikoklassen korrekt bestimmen. Dafür braucht es eine strukturierte Analyse — und die beginnt mit der Lektüre von Annex III.

Zur technischen Dokumentation nach Art. 11: Für Hochrisiko-Systeme muss der Anbieter eine technische Dokumentation bereitstellen, die unter anderem beschreibt, wie das System trainiert wurde, welche Daten verwendet wurden, wie es getestet wurde und welche Einschränkungen es hat. Microsoft stellt diese Dokumentation für Azure OpenAI und Copilot in Form von „Model Cards“ und „System Cards“ bereit. Als Deployer müssen Sie diese Dokumente beschaffen, aufbewahren und bei einer Prüfung vorlegen können. Es reicht nicht, zu wissen, wo man sie findet — sie müssen tatsächlich abgelegt sein.

Was dokumentiert sein muss — eine Checkliste

Folgende Dokumente müssen für eine AI-Act-konforme Organisation vorliegen:

KI-Inventar: Liste aller genutzten KI-Systeme mit Risikoklasse, Einsatzbereich, Verantwortlichen

Interne KI-Nutzungsrichtlinie: Was erlaubt ist, was verboten ist, wer entscheidet

AI-Literacy-Schulungsnachweise: Wer wann was gelernt hat, für alle relevanten Mitarbeiter

Technische Dokumentation (von Anbieter): Für alle genutzten Hochrisiko-Systeme

FRIA / DSFA: Für Hochrisiko-Systeme mit erheblichem Personenbezug

Protokoll-Konfiguration: Nachweis, dass Logging aktiv und aufbewahrt wird

Vorfallsregister: Dokumentation von KI-Vorfällen und Meldungen an Anbieter

Aufsichtspersonen-Benennung: Schriftliche Benennung und Qualifikationsnachweis

 

Zur Aufbewahrungsdauer: Der AI Act nennt für die meisten Dokumentationspflichten keine einheitliche Frist — das wird durch sektorspezifisches Recht und allgemeine Grundsatzüberlegungen ergänzt. Als Orientierungsgröße gilt: Dokumente, die einen Hochrisiko-Systembetrieb belegen, sollten mindestens zehn Jahre nach Abschaltung des Systems aufbewahrt werden, da potenzielle Schaden und Haftungsansprüche aus dem Betrieb entsprechend lange geltend gemacht werden können. Schulungsnachweise sollten für die Dauer des Beschäftigungsverhältnisses plus drei Jahre aufbewahrt werden. Für alles andere: mindestens drei Jahre nach Ende des Einsatzes des jeweiligen KI-Systems.

Ein besonderer Hinweis zur Aufsichtsbehörde: Der AI Act verpflichtet die Mitgliedstaaten, eine nationale Aufsichtsbehörde zu benennen. In Deutschland ist das voraussichtlich die Bundesnetzagentur, ggf. kombiniert mit der Datenschutzkonferenz für datenschutzrelevante Aspekte. Die Behörde hat das Recht, Unternehmen zu prüfen, Unterlagen anzufordern und Bußgelder zu verhängen. Sie wird in den ersten Jahren voraussichtlich eher beratend als sanktionierend auftreten — das ist bei neuen Regulierungen fast immer so. Aber dieser Puffer ist begrenzt. Wer bei der ersten Welle der Prüfungen „noch nichts“ vorweisen kann, riskiert mehr als ein Bußgeld: Er riskiert seinen Ruf als compliance-bewusstes Unternehmen.

Dokument	Rechtsgrundlage	Gilt ab	Wer zuständig	Aufbewahrung
KI-Inventar	Art. 26 AI Act	Sofort	IT + Compliance	Laufend aktualisiert
KI-Nutzungsrichtlinie	Art. 26 Abs. 1, Art. 4	Sofort	Compliance + HR	Mindestens 3 Jahre
AI-Literacy-Schulungsnachweise	Art. 4	Sofort	HR	Dauer des Beschäftigungsverhältnisses + 3 Jahre
Technische Dokumentation (Anbieter)	Art. 11, Art. 26	Aug 2025 (GPAI), Aug 2026 (HR)	IT	10 Jahre nach Systemabschaltung
FRIA / DSFA	Art. 26 Abs. 4, DSGVO Art. 35	Vor Go-Live Hochrisiko-System	DSB + Compliance	Mindestens 3 Jahre
Protokoll-Konfiguration und Logs	Art. 12, Art. 26	Aug 2026 (Hochrisiko)	IT	Mindestens 3 Jahre
Vorfallsregister	Art. 26 Abs. 5	Ab sofort	IT + Compliance	5 Jahre

Tab. 7.5 — Dokumentationspflichten nach AI Act: Das Wichtigste zuerst — wer sofort anfangen muss und wer noch etwas Zeit hat

 

⚠️ RISIKO — AI Literacy ist keine freiwillige Option

Ein Unternehmen, das 200 Mitarbeiter mit Copilot ausstattet und keine nachweisbaren AI-Literacy-Schulungen durchgeführt hat, verstößt ab sofort gegen Art. 4 des EU AI Acts. Das ist kein künftiges Risiko — das ist ein aktueller Verstoß. Die Nationale KI-Behörde (in Deutschland voraussichtlich die Bundesnetzagentur) kann jederzeit prüfen. Ein Bußgeld nach Art. 99 AI Act kann bis zu 15 Mio. EUR oder 3 % des globalen Jahresumsatzes betragen. Für einen versehentlichen Verstoß gegen die allgemeinen Deployer-Pflichten. Der Unterschied zwischen „wir haben eine Schulung gemacht“ und „wir haben Schulungsnachweise“ ist der Unterschied zwischen Compliance und nicht-nachweisbarer Compliance. Nur die erste Version hilft im Ernstfall.

 

➡️ WAS JETZT ZU TUN IST

Schritt 1 — KI-Inventar anlegen: Erfassen Sie alle KI-Systeme, die in Ihrem Unternehmen im Einsatz sind. Copilot M365, Azure OpenAI, eigene KI-Workflows, Tools von Drittanbietern. Ordnen Sie jedem System eine Risikoklasse zu. Das ist die Grundlage für alles weitere. Schritt 2 — Art.-5-Prüfung: Pruefen Sie für jedes KI-System, ob es potenziell verbotene Praktiken umsetzt oder unterstützt. Social Scoring, Verhaltensmanipulation, Emotion-Erkennung am Arbeitsplatz. Wenn ja: sofortiger Handlungsbedarf. Schritt 3 — AI Literacy starten: Planen Sie jetzt ein differenziertes Schulungsprogramm für alle KI-nutzenden Mitarbeiter. Unterschiedliche Tiefen je nach Rolle. Schulungsnachweise systematisch erfassen. Das lässt sich in bestehende Compliance-Schulungssysteme integrieren. Schritt 4 — KI-Nutzungsrichtlinie verabschieden: Erstellen Sie eine interne Richtlinie, die klar beschreibt, wer was mit KI tun darf. Verbotene Einsätze explizit benennen. Genehmigungsprozesse für neue KI-Anwendungen definieren. Diese Richtlinie ist auch die Grundlage für die Betriebsvereinbarung. Schritt 5 — Hochrisiko-Szenarien analysieren: Prüfen Sie, ob Sie Azure OpenAI oder Copilot Studio für Anwendungen nutzen, die unter Annex III fallen könnten: HR-Entscheidungen, Kreditbewertung, kritische Infrastruktur. Wenn ja: FRIA und Konformitätsbewertung einplanen. Zeit einkalkulieren: Diese Prozesse dauern länger als erwartet. Für die Ungeduld am Ende: Der AI Act ist kein Papiertiger. Die Böden für Behördenprüfungen sind gelegt. Wer jetzt nichts tut, wird später erklären müssen, warum — möglicherweise unter Zeitdruck und mit Bußd geldbescheid in der Hand. Das ist keine Prognose, das ist ein Erfahrungswert.

 

 

KAPITEL 8