EU AI Act für Betreiber: Pflichten nach Rolle, Risikoklasse und Datum
12 Min. Lesezeit
Jetzt lesenPolicies beruhigen, Artefakte bestehen Prüfungen. Wie Freigabeprotokoll, Evaluationsbericht, Incident-Log und Berechtigungstest aus guten Absichten ein auditfähiges Kontrollsystem machen.
Steuerungsfähig wird KI-Governance erst durch Artefakte: datierte, auffindbare Belege mit klarem Owner. Sechs Stück tragen das System — Systemsteckbrief, Freigabeprotokoll, Evaluationsbericht, Incident-Log, Berechtigungstest und Abschaltprotokoll. Die Tiefe je System folgt der Risikoklasse, nicht dem Umfang der Richtlinie. Wer diese Artefakte pflegt, besteht Kundenaudits, Revisionsfragen und Behördenanfragen ohne Hektik. Wer nur Policies vorweisen kann, hat Absichten dokumentiert, aber keine Kontrolle.
Der KI-Einsatz in deutschen Unternehmen hat sich binnen eines Jahres fast verdoppelt: 36 Prozent nutzen KI, weitere 47 Prozent planen oder diskutieren den Einsatz (Bitkom, 2025). Die Kontrollseite hält nicht Schritt. Im McKinsey AI Trust Maturity Survey 2026 erreicht nur rund ein Drittel der etwa 500 befragten Organisationen bei Strategie und Governance einen hohen Reifegrad. Gleichzeitig nennen 53 Prozent der deutschen Unternehmen rechtliche Unsicherheit als größtes Hemmnis beim KI-Einsatz (Bitkom, 2025).
Diese Lücke wird teurer. Seit Februar 2025 verlangt Artikel 4 der Verordnung (EU) 2024/1689 KI-Kompetenz von Anbietern und Betreibern. Ab August 2026 greift die Hauptgeltung der Verordnung, unter anderem mit Transparenzpflichten. Kunden und Wirtschaftsprüfer fragen schon heute nach Nachweisen. Wer dann Ordner öffnen kann, gewinnt Zeit und Vertrauen. Wer erst suchen muss, verliert beides.
Der häufigste Fehler in KI-Governance-Projekten ist die Verwechslung von Regelwerk und Kontrolle. Eine Richtlinie sagt, was gelten soll. Eine Kontrolle beweist, dass es gilt. Dazwischen liegt die Ausführung, und deren Spur ist das Artefakt.
Ein brauchbares Artefakt erfüllt vier Bedingungen. Es ist datiert, sonst lässt sich kein Zustand zu einem Zeitpunkt belegen. Es ist auffindbar, also an einem bekannten Ort abgelegt, nicht im Postfach eines Einzelnen. Es hat einen Owner, der für Inhalt und Aktualität geradesteht. Und es ist reproduzierbar: Ein Dritter kann nachvollziehen, wie der Beleg entstand.
An diesem Maßstab scheitern viele gut gemeinte Dokumente. Eine „KI-Richtlinie v2.3“ ohne Freigabevermerk belegt nichts. Ein Testprotokoll ohne Datum und Prüfer ebenso wenig. Die Prüferfrage lautet nie „Haben Sie eine Policy?“, sondern „Zeigen Sie mir die Freigabe für dieses System, mit Datum und Unterschrift.“
Governance-Reife misst sich nicht an der Seitenzahl der Richtlinie, sondern an der Antwortzeit auf die Frage: „Zeigen Sie mir das Freigabeprotokoll für System X.“ Alles über 24 Stunden ist ein Befund.
Die Abgrenzung zum Inventar ist wichtig. Das Inventar beantwortet, welche Systeme existieren. Artefakte beantworten, ob diese Systeme kontrolliert betrieben werden. Beides gehört zusammen, ist aber nicht dasselbe. Ebenso wenig ersetzen Artefakte die Pflichtenanalyse nach der KI-Verordnung; sie machen deren Erfüllung belegbar.
Sechs Artefakte decken den Lebenszyklus eines KI-Systems ab: von der Aufnahme über Freigabe und Betrieb bis zur Abschaltung. Jedes beantwortet eine konkrete Prüferfrage.
| Artefakt | Prüferfrage | Mindestinhalt | Prüfbar, wenn |
|---|---|---|---|
| Systemsteckbrief | Was läuft hier, wozu, mit welchen Daten? | Zweck, Datenkategorien, Anbieter, Risikoklasse, Owner | Eine Seite, datiert, im Register verlinkt |
| Freigabeprotokoll | Wer hat den Produktivbetrieb wann erlaubt? | Entscheidung, Bedingungen, Entscheider, Datum | Vor Go-live erstellt, Auflagen nachverfolgt |
| Evaluationsbericht | Woher wissen Sie, dass es gut genug arbeitet? | Testfälle, Metriken, Schwellen, Ergebnis, Prüfer | Wiederholbar, mit definierter Bestehensgrenze |
| Incident-Log | Was ging schief und was folgte daraus? | Vorfall, Schwere, Maßnahme, Status, Meldeweg | Auch Beinahe-Vorfälle erfasst, Pfad geübt |
| Berechtigungstest | Wer kommt an das System und seine Daten? | Rollen, Rechte, Testergebnis, Abweichungen | Regelmäßig wiederholt, Abweichungen geschlossen |
| Abschaltprotokoll | Können Sie das System geordnet stoppen? | Auslöser, Verfahren, Datenverbleib, Verantwortlicher | Aussetzung mindestens einmal durchgespielt |
Zwei dieser Artefakte werden regelmäßig unterschätzt. Der Berechtigungstest deckt das häufigste reale Risiko ab: zu breite Zugriffe auf Systeme, die vertrauliche Daten verarbeiten. Er ist in einer Stunde durchgeführt und in einer Tabelle dokumentiert. Das Abschaltprotokoll wiederum trennt Theorie von Praxis. Viele Unternehmen können ein System technisch abschalten, aber niemand weiß, wer es entscheiden darf und was mit laufenden Prozessen geschieht.
Für die Ablage genügt am Anfang eine strukturierte Dokumentenbibliothek mit Namenskonvention. Spezialsoftware wird erst sinnvoll, wenn die Systemzahl zweistellig wird. Entscheidend ist ein einziger, allen bekannter Ort.
Nicht jedes System verdient alle sechs Artefakte in voller Tiefe. Wer das versucht, erzeugt Bürokratie und Widerstand. Sinnvoll sind drei Stufen, die an die Risikoklassifizierung anknüpfen.
Die Basisstufe gilt für Werkzeuge ohne Außenwirkung und ohne sensible Daten, etwa interne Textassistenten. Hier reichen Steckbrief, einfache Freigabe und ein Jahresreview. Die Standardstufe gilt für Systeme mit Kundenkontakt, Personaldaten oder Entscheidungsunterstützung. Sie verlangt alle sechs Artefakte mit Quartals- oder Halbjahresrhythmus. Die auditnahe Stufe gilt für Systeme, die unter die Hochrisiko-Kategorien der KI-Verordnung fallen könnten, etwa in Personalauswahl oder Kreditentscheidung. Hier kommen vertiefte Evaluation, dichtere Protokollierung und juristische Prüfung hinzu. Die Pflichten im Einzelnen sind Gegenstand der Betreiberpflichten-Analyse, nicht dieses Beitrags.
Der Mechanismus dahinter ist einfach: Die Risikoklasse aus dem Inventar bestimmt die Stufe, die Stufe bestimmt Artefaktumfang und Reviewfrequenz. Damit ist der Aufwand begründbar, gegenüber der Geschäftsführung ebenso wie gegenüber Fachbereichen, die sich über Formulare beklagen. ISO/IEC 42001 stützt genau dieses Vorgehen: Die Norm verlangt Risikobewertung und Wirkungsanalyse als Grundlage der Kontrollauswahl, nicht Maximaldokumentation für alles.
Ein Beispiel macht die Logik greifbar. Ein Maschinenbauer mit 800 Beschäftigten betreibt drei Systeme: einen internen Übersetzungsassistenten, einen Chatbot für Serviceanfragen und ein Prognosemodell für Ersatzteilbedarf mit Preiswirkung. Der Assistent landet in der Basisstufe: Steckbrief, Freigabe, Jahresreview. Der Chatbot spricht mit Kunden und fällt in die Standardstufe mit allen sechs Artefakten. Das Prognosemodell beeinflusst Preise und Lieferzusagen; es bekommt die Standardstufe plus vierteljährliche Re-Evaluation. Kein System bekommt mehr, keines weniger. Der Aufwand bleibt erklärbar.
Ausnahmen sind erlaubt, aber nur befristet, begründet und mit Owner. Eine dauerhafte, unreviewte Ausnahme ist keine Ausnahme mehr, sondern eine stille Regeländerung.
Der zweite große Fehler nach der Policy-Gläubigkeit ist das Projektdenken. Freigabe erteilt, Ordner zu, Governance erledigt. KI-Systeme ändern sich aber im Betrieb: Anbieter tauschen Modelle aus, Datenqualität driftet, Nutzer finden neue Anwendungen. Eine Freigabe von Januar sagt wenig über den Oktober.
Drei Routinen halten das System aktuell. Erstens die Re-Evaluation: Der Evaluationsbericht wird je nach Stufe quartalsweise oder jährlich wiederholt, mit denselben Testfällen und Schwellen. Sinkt das Ergebnis unter die Bestehensgrenze, greift ein vorab definierter Eskalationsweg. Zweitens die Incident-Übung: Einmal jährlich wird ein fiktiver Vorfall durchgespielt, vom Erstverdacht bis zur Managemententscheidung. Erst die Übung zeigt, ob der Meldeweg im Ernstfall trägt. Drittens das Review der Berechtigungen und Ausnahmen mit fester Frist.
Der wahre Reifegradtest ist der erste Schattenfund: Behandelt die Organisation das ungemeldete KI-Tool als Störfall mit Prozess, oder als Anlass für Schuldzuweisungen? Im zweiten Fall meldet nie wieder jemand freiwillig etwas.
Schatten-KI verdient dabei besondere Aufmerksamkeit. Ungemeldete Werkzeuge sind in wachsenden Organisationen der Normalfall, nicht die Ausnahme. Ein funktionierendes Kontrollsystem hat dafür einen Standardpfad: Fund aufnehmen, binnen einer Woche klassifizieren, dann Freigabe oder geordneter Stopp. Ohne Sanktionsreflex gegenüber den Meldenden, sonst versiegt die wichtigste Informationsquelle. Die Zahl der Schattenfunde pro Quartal ist übrigens eine ehrlichere Governance-Kennzahl als jede Policy-Abdeckungsquote: null Funde bedeuten fast nie null Schatten.
Für die Führungsrunde genügt ein knappes Quartals-Reporting mit vier Größen. Erstens der Registerstand: Systeme gesamt, davon mit gültiger Freigabe. Zweitens die überfälligen Artefakte, mit Namen und Frist. Drittens Vorfälle und Beinahe-Vorfälle samt Status der Maßnahmen. Viertens die Schattenfunde des Quartals und ihre Behandlung. Diese vier Zahlen passen auf eine Seite. Sie zeigen der Geschäftsführung den echten Zustand, und sie zeigen jedem Prüfer, dass das System lebt.
Bis Tag 30
Bis Tag 60
Bis Tag 90
Für ein Unternehmen mit 250 bis 2.000 Beschäftigten ist der Startaufwand überschaubar: ein Owner mit 20 bis 40 Prozent Kapazität, ein Kernteam aus IT, Recht und Fachbereich sowie vorhandene Werkzeuge wie Ticketsystem und Dokumentenablage. Teuer wird nicht das Anlegen der Artefakte, sondern das Nachziehen unter Zeitdruck, etwa bei einer Kundenauditanfrage. Eine Zertifizierung nach ISO/IEC 42001 verursacht zusätzliche externe Kosten und lohnt erst, wenn Kunden oder Ausschreibungen sie verlangen. Die sechs Kern-Artefakte selbst brauchen keine neue Software, sondern Disziplin und ein Quartalsreview.
Dann trägt die Geschäftsführung ein doppeltes Risiko: Sie kann Pflichten aus der Verordnung (EU) 2024/1689 nicht belegen und verliert bei Kunden- und Revisionsprüfungen Glaubwürdigkeit. Die KI-Verordnung verlangt von Betreibern je nach Risikoklasse Aufsicht, Protokolle und Meldewege; bei Verstößen drohen nach Artikel 99 empfindliche Bußgelder. Eine Policy ohne Nachweis schützt davor nicht, denn Prüfer fragen nach Belegen, nicht nach Absichten. Hinzu kommt der operative Schaden: Ohne Evaluationsberichte und Incident-Logs erkennt niemand, ob ein System schleichend schlechter wird.
Mit einem Steckbrief pro produktivem KI-System und einer nachgeholten Freigabe, beides innerhalb von 30 Tagen. Der Steckbrief braucht nur eine Seite: Zweck, Datenkategorien, Anbieter, Risikoklasse, Owner. Danach folgen die nächsten Artefakte in Prioritätsreihenfolge: Evaluationsbericht für das wichtigste System, Incident-Pfad mit Testlauf, Berechtigungstest. Wichtig ist, klein und vollständig zu starten statt groß und lückenhaft. Ein Register mit sechs sauber gepflegten Systemen schlägt eine 80-seitige Richtlinie ohne einen einzigen datierten Nachweis.
Nein, für die meisten Mittelständler ist die Zertifizierung optional; die Norm taugt aber als Bauplan. ISO/IEC 42001 beschreibt seit Dezember 2023 ein zertifizierbares Managementsystem für KI mit Rollen, Risikobewertung, Lebenszyklus-Kontrollen und Lieferantensteuerung. Wer seine Artefakte an der Norm ausrichtet, kann später mit geringem Zusatzaufwand zertifizieren, wenn Kunden oder Ausschreibungen es fordern. Umgekehrt gilt: Ein Zertifikat ohne gelebte Betriebskontrollen besteht zwar das Audit, aber nicht den ersten echten Vorfall. Erst Artefakte, dann Zertifikat.
Genug ist erreicht, wenn jedes produktive System eine Risikoklasse, eine datierte Freigabe und einen Owner hat und die Kontrolltiefe der Klasse folgt. Ein internes Textwerkzeug braucht einen Steckbrief und ein Jahresreview, kein Vollprogramm. Ein System mit Kundenwirkung oder Personaldaten braucht zusätzlich Evaluationsbericht, Incident-Log und Berechtigungstest. Überbürokratie entsteht fast immer, wenn alle Systeme gleich behandelt werden. Die Faustregel: Wer ein Artefakt in einem Review nie zeigen musste und keinen Risikogrund dafür benennen kann, darf es streichen.
Belegt sind die regulatorischen Anker (Verordnung (EU) 2024/1689 mit Artikel 4 und dem Sanktionsrahmen des Artikels 99), der Normrahmen ISO/IEC 42001:2023 sowie die zitierten Studienbefunde von Bitkom (2025) und McKinsey (2026). Redaktionelle Einschätzung sind der Zuschnitt auf sechs Kern-Artefakte, die drei Ausbaustufen und die Kapazitätsempfehlungen; sie stammen aus der Prüfpraxis, nicht aus einer Norm. Der Beitrag leistet keine Rechtsberatung und keine Klassifizierung einzelner Systeme nach der KI-Verordnung. Die konkreten Betreiberpflichten nach Rolle, Risikoklasse und Datum sowie der Aufbau des Inventars sind Gegenstand eigener Beiträge dieses Themenclusters.
Methodik: Erstellt mit KI-Unterstützung auf Basis eigener Web-Recherche in Primär- und Studienquellen (Stand 23.07.2026); menschliche Faktenprüfung und redaktionelle Freigabe vor Veröffentlichung vorgesehen. Alle Zahlen- und Rechtsclaims sind den nummerierten Quellen zugeordnet. Der Beitrag ersetzt keine Rechtsberatung.
| Datum | Änderung |
|---|---|
| 2026-07-23 | Vollständige Neufassung: Artefakt-Systematik, Prüfbarkeits-Tabelle, Ausbaustufen, FAQ, verifizierte Quellen |
| 2026-07-23 | Erstfassung Launch-Korpus (Status: draft) |
Ein Briefing pro Woche: Entscheidungsfragen, eingeordnete Zahlen und Fristen. Ihre Adresse geben wir nicht weiter.
12 Min. Lesezeit
Jetzt lesen12 Min. Lesezeit
Jetzt lesen13 Min. Lesezeit
Jetzt lesen