KI-Compliance Monitoring: Warum einmalige Inventarisierung nicht reicht

Inventarisiert ist nicht gleich compliant – warum Monitoring Pflicht ist

Das KI-Inventar steht. Die Risikoklassen sind zugeordnet. Die KI-Richtlinie ist verabschiedet. Und jetzt? Viele Unternehmen behandeln die KI-Compliance wie ein Projekt: einmal aufsetzen, abhaken, fertig. Das ist ein Fehler – und zwar einer mit regulatorischen Konsequenzen.

Der AI Act verlangt von Deployern eine laufende Überwachung ihrer KI-Systeme. Art. 26 Abs. 5 ist unmissverständlich: Betreiber überwachen den Betrieb des Hochrisiko-KI-Systems auf Grundlage der Gebrauchsanweisung. Wer Grund zu der Annahme hat, dass das System ein Risiko darstellt, muss den Anbieter und die Marktüberwachungsbehörde unverzüglich informieren – und die Nutzung aussetzen.

Das gilt nicht nur für Hochrisiko-Systeme. Auch KI mit begrenztem Risiko verändert sich: Provider liefern Updates, Mitarbeitende nutzen neue Tools, Geschäftsprozesse verschieben sich. Wer sein Inventar als Momentaufnahme behandelt, hat nach sechs Monaten ein veraltetes Dokument – und im Ernstfall keine Nachweisgrundlage.

Dieser Artikel zeigt Ihnen, wie Sie ein pragmatisches Monitoring-System aufbauen: mit vier Bausteinen, konkreten Prüfzyklen nach Risikoklasse und einem Deployer-tauglichen Incident-Log.

Was sich nach der Ersterfassung ändert

Ihr KI-Inventar bildet den Stand zum Zeitpunkt der Erstellung ab. Aber KI-Landschaften sind dynamisch. Innerhalb weniger Monate können sich mehrere Dimensionen gleichzeitig verschieben:

5 typische Veränderungen, die Ihr Inventar veralten lassen

Die 4 Bausteine eines KI-Monitoring-Systems

Ein wirksames Monitoring muss nicht komplex sein. Für die meisten KMU reichen vier Bausteine, die sich in bestehende Compliance-Prozesse integrieren lassen:

Baustein 1: Status-Tracking

Jedes KI-System im Inventar bekommt einen Status: aktiv, in Prüfung, deaktiviert oder abgelöst. Einmal pro Quartal gleichen Sie das Inventar mit der Realität ab: Wird das System noch genutzt? Hat sich der Einsatzzweck verändert? Stimmen die Verantwortlichkeiten noch?

Das klingt banal – aber ohne diesen Schritt wächst die Lücke zwischen Dokumentation und Wirklichkeit schneller, als die meisten erwarten.

Baustein 2: Prüfzyklen nach Risikoklasse

Nicht jedes KI-System braucht die gleiche Aufmerksamkeit. Die Prüftiefe und -frequenz richtet sich nach der Risikoklassifizierung:

Baustein 3: KI-Incident-Log

Der AI Act spricht in Art. 26 Abs. 5 von „schwerwiegenden Vorfällen", die unverzüglich gemeldet werden müssen. Aber was ist ein Vorfall? Für die meisten KMU fehlt eine klare Definition. Hier ist eine pragmatische Abgrenzung:

Ein KI-Vorfall liegt vor, wenn:

• Ein KI-System eine falsche oder diskriminierende Entscheidung trifft, die Personen betrifft (z. B. Bewerbungsabsage ohne sachlichen Grund)

• Ein System außerhalb des vorgesehenen Zwecks eingesetzt wird (z. B. ChatGPT für Personalentscheidungen)

• Ein Datenschutzverstoß durch KI-Nutzung entsteht (z. B. personenbezogene Daten in einem externen KI-Tool verarbeitet)

• Ein Provider-Update die Funktionsweise wesentlich verändert, ohne dass dies geprüft wurde

• Mitarbeitende die KI-Richtlinie wiederholt verletzen (z. B. nicht genehmigte Tools nutzen)

8 Felder für Ihr Incident-Log

Baustein 4: Änderungs-Log

Der Änderungs-Log erfasst alles, was sich zwischen zwei Prüfzyklen verändert hat: neue Tools, deaktivierte Systeme, Provider-Updates, Rollenänderungen, neue Einsatzzwecke. Jede Änderung wird mit Datum, betroffener Person und Bewertung dokumentiert.

Der Änderungs-Log ist das Bindeglied zwischen Inventar und Prüfzyklus: Was sich ändert, wird erfasst – und fließt in die nächste Prüfung ein.

Praxis-Beispiel: Ihr Unternehmen nutzt Microsoft 365 mit Copilot. Microsoft kündigt ein Update an, das Copilot-Funktionen in Outlook und Teams erweitert. Der Änderungs-Log erfasst: Datum, betroffenes System (Copilot), Art der Änderung (Funktionserweiterung), potenzieller Risikoklassen-Impact (prüfen, ob neue Datenflüsse entstehen) und Verantwortlichen für die Bewertung. Im nächsten Prüfzyklus wird gezielt geprüft, ob die Erweiterung die bisherige Klassifizierung verändert.

Vergessen Sie nicht die Schnittstelle zur DSGVO: Wenn ein KI-System neue personenbezogene Daten verarbeitet, löst das nicht nur eine KI-Compliance-Prüfung aus, sondern potenziell auch eine Anpassung der bestehenden Datenschutz-Folgenabschätzung.

Vorfälle und Auffälligkeiten dokumentieren – was ein KI-Incident-Log leistet

Die meisten Unternehmen haben Incident-Management-Prozesse für IT-Sicherheit oder Datenschutz. Ein KI-Incident-Log funktioniert nach dem gleichen Prinzip – mit einem entscheidenden Unterschied: KI-Vorfälle sind oft nicht technisch sichtbar.

Ein Spamfilter, der plötzlich legitime E-Mails blockiert, fällt auf. Ein Recruiting-Tool, das systematisch Bewerber mit bestimmten Merkmalen benachteiligt, fällt erst auf, wenn jemand hinschaut. Deshalb braucht KI-Compliance ein eigenes Meldesystem – idealerweise mit einer niedrigschwelligen Meldeoption für alle Mitarbeitenden.

3 Maßnahmen, die Vorfälle sichtbar machen:

1. Melde-Kanal einrichten: E-Mail-Alias oder Formular, über das Mitarbeitende KI-Auffälligkeiten melden können – ohne Hürde, ohne Schuldzuweisung.

2. Regelmäßige Stichproben: Bei Hochrisiko-Systemen quartalsweise Outputs prüfen – z. B. Auswertung der letzten 50 Entscheidungen eines KI-gestützten Scoring-Systems.

3. Provider-Kommunikation: Aktiv bei Anbietern nach Updates, bekannten Problemen und Änderungen fragen – nicht warten, bis es im Changelog steht.

Entscheidend ist die Verknüpfung mit der KI-Richtlinie: Der Incident-Prozess sollte dort als eigenständiger Abschnitt verankert sein. Mitarbeitende müssen wissen, an wen sie sich wenden, was als Vorfall zählt und dass eine Meldung keine negativen Konsequenzen für sie hat. Ohne diese Klarheit bleibt das schönste Incident-Log leer.

Für die Bewertung der Schwere hat sich ein Vierstufenmodell bewährt:

• Niedrig: Abweichung vom vorgesehenen Einsatzzweck ohne Personenbezug. Beispiel: Mitarbeitender nutzt DeepL für interne Übersetzung statt des genehmigten Tools.

• Mittel: Regelverstoß mit begrenztem Personenbezug, aber ohne Schaden. Beispiel: Personenbezogene Daten in ChatGPT eingegeben, aber keine sensiblen Kategorien.

• Hoch: Verstoß mit potenziellem Schaden für betroffene Personen. Beispiel: KI-gestütztes Scoring-Tool liefert erkennbar verzerrte Ergebnisse über mehrere Wochen.

• Schwerwiegend: Meldepflicht nach Art. 26 Abs. 5. Beispiel: Hochrisiko-System trifft diskriminierende Entscheidungen, die Personen direkt betreffen.

Management Reporting: KI-Compliance auf die Vorstandsagenda bringen

Monitoring ohne Reporting ist Datensammlung ohne Wirkung. Die Geschäftsführung muss wissen, wie es um die KI-Compliance steht – nicht im Detail, sondern auf einen Blick. Ein kompaktes KI-Compliance-Dashboard liefert genau das.

5 Kennzahlen für Ihr KI-Compliance-Dashboard

Die Geschäftsführung trägt die Verantwortung für die Einhaltung des AI Act. Ein regelmäßiges Reporting schafft Transparenz und dokumentiert gleichzeitig, dass die Leitungsebene ihre Aufsichtspflicht wahrnimmt – ein zentraler Nachweis bei Behördenanfragen.

Was tun, wenn das Dashboard Rot zeigt?

Wenn ein oder mehrere Systeme im Status „rot" stehen – also überfällige Prüfungen oder offene Incidents haben –, ist ein klarer Eskalationspfad nötig:

1. Sofort: System auf „in Prüfung" setzen und Nutzung einschränken, bis der Sachverhalt geklärt ist.

2. Innerhalb von 5 Arbeitstagen: Root-Cause-Analyse durchführen. Liegt ein regulatorischer Verstoß vor oder handelt es sich um ein Prozessversäumnis?

3. Innerhalb von 20 Arbeitstagen: Korrekturmaßnahme dokumentieren, umsetzen und Wirksamkeit prüfen.

Dieser Dreischritt stellt sicher, dass ein gelbes oder rotes Signal im Dashboard nicht wochenlang ignoriert wird. Die Fristen sind Richtwerte – passen Sie sie an Ihre Unternehmensgröße an.

Wie oft prüfen? Empfehlungen für Prüfzyklen nach Risikoklasse

Die richtige Prüffrequenz hängt von drei Faktoren ab: der Risikoklasse, der Dynamik des Systems und der Anzahl betroffener Personen. Hier ist ein Rahmen, den Sie auf Ihr Unternehmen anpassen können:

Regelprüfungen

• Hochrisiko-Systeme: Quartalsweise Vollprüfung. Dokumentation, Datenflüsse, Bias-Indikatoren, Logs, Human-Oversight-Prozess.

• Begrenztes Risiko: Halbjährliche Stichprobe. Kennzeichnung korrekt? Nutzung gemäß KI-Richtlinie? Provider-Updates geprüft?

• Minimales Risiko: Jährlicher Status-Check. Noch aktiv? Einsatzzweck unverändert?

Trigger-Ereignisse für anlassbezogene Prüfungen

Neben den Regelprüfungen gibt es Ereignisse, die eine sofortige Ad-hoc-Prüfung auslösen sollten:

Von der Überwachung zum Audit

Monitoring und Audit sind nicht dasselbe – aber sie gehören zusammen. Das Monitoring liefert die Daten, der Audit bewertet sie systematisch.

Das Monitoring füllt die Wissenslücke zwischen zwei Audits. Ohne laufende Überwachung ist jeder Audit eine Momentaufnahme – und jede Momentaufnahme ist veraltet, sobald sie fertig ist.

Ihr KI-Monitoring in den AI-Act-Gesamtkontext einordnen

Das Monitoring ist der fünfte Baustein in der 5-Phasen-Umsetzungslogik des AI Act. Es baut auf allen vorherigen Schritten auf und sichert deren Ergebnisse langfristig ab:

3 nächste Schritte

1. Prüfzyklen festlegen: Ordnen Sie jedem KI-System im Inventar eine Prüffrequenz zu – basierend auf der Risikoklasse. Beginnen Sie mit den Hochrisiko-Systemen.

2. Incident-Log einrichten: Erstellen Sie ein einfaches Log mit den 8 Feldern aus diesem Artikel. Ein Excel-Sheet reicht für den Anfang – Hauptsache, der Prozess existiert.

3. Ersten Monitoring-Bericht erstellen: Nutzen Sie die 5 Kennzahlen für ein kompaktes Dashboard und legen Sie es der Geschäftsführung im nächsten Quartalsbericht vor.