Vom Asset zum Anwendungsfall
Ein KI-Register listet Systeme auf. Das ist notwendig, aber nicht ausreichend. Für die Compliance-Arbeit zählt nicht das Tool, sondern wofür es eingesetzt wird. Dieselbe KI kann je nach Verwendung minimal riskant oder hochriskant sein. Die Verbindung zwischen System und Zweck herzustellen, ist die zentrale Aufgabe der DEFINE-Phase im NADOVO Framework.
Warum die Asset-Liste nicht reicht
Die DISCOVER-Phase erfasst alle KI-Systeme im Unternehmen: eingekaufte Software, Cloud-Dienste, eingebettete Funktionen, Schatten-KI. Das Ergebnis ist ein vollständiges KI-Register. Doch diese Bestandsaufnahme beantwortet noch nicht die entscheidende Frage: Welche regulatorischen Anforderungen gelten?
Der EU AI Act klassifiziert nicht nach Technologie, sondern nach Verwendungszweck. Ein großes Sprachmodell ist kein Hochrisiko-System, nur weil es technisch komplex ist. Es wird zum Hochrisiko-System, wenn es für Bewerberauswahl, Leistungsbewertung oder Kreditwürdigkeitsprüfung eingesetzt wird. Die Technologie bleibt gleich, der Zweck macht den Unterschied.
Die Gleichung: Asset plus Anwendungsbereich gleich KI-Prozess
In der DEFINE-Phase wird jedes Asset mit seinen konkreten Anwendungsfällen verknüpft. Ein KI-System kann mehrere Anwendungsfälle haben, jeder bildet einen eigenen KI-Prozess. ChatGPT für Marketingtexte ist ein Prozess. ChatGPT für Kundenbeschwerden ist ein anderer. ChatGPT für HR-Screening ein dritter. Alle nutzen dasselbe Asset, aber jeder Prozess hat eine eigene Risikoklasse.
Diese Unterscheidung ist kein bürokratischer Selbstzweck. Sie spiegelt die Logik der Verordnung wider. Artikel 6 definiert die Risikoklasse über den beabsichtigten Verwendungszweck, nicht über technische Eigenschaften. Wer diese Logik versteht, kann Compliance gezielt steuern statt pauschal alles als Hochrisiko zu behandeln.
Was ein KI-Prozess dokumentiert
Jeder KI-Prozess braucht eine klare Beschreibung. Welches Asset wird verwendet? In welchem Geschäftsbereich? Für welchen konkreten Zweck? Welche Personen sind betroffen? Welche Entscheidungen werden beeinflusst? Welche Daten fließen ein?
Die Zweckbestimmung muss präzise sein. Nicht nur welcher Bereich, sondern welche konkrete Aufgabe. Nicht Recruiting, sondern Vorauswahl von Bewerbungen anhand von Lebensläufen. Nicht Kundenservice, sondern automatische Beantwortung von Standardanfragen. Die Präzision zahlt sich bei der Risikoklassifizierung aus.
Betroffene Personen zu identifizieren ist entscheidend. Der EU AI Act schützt primär natürliche Personen, deren Grundrechte durch KI-Entscheidungen berührt werden. Mitarbeiter bei HR-Systemen, Kunden bei Scoring, Bewerber bei Recruiting. Wer betroffen ist, bestimmt mit, welche Schutzvorschriften greifen.
Von der Prozessdefinition zur Risikoklasse
Mit der vollständigen Prozessbeschreibung lässt sich die Risikoklasse bestimmen. Die Prüfung folgt einem klaren Schema. Fällt der Anwendungsfall unter Annex III des EU AI Act? Dann ist das System grundsätzlich Hochrisiko. Greift eine Ausnahme, weil das System keine wesentliche Entscheidungsbeeinflussung hat? Dann bleibt es bei Limited oder Minimal Risk.
Die Klassifizierung erfolgt pro Prozess, nicht pro Asset. Ein Unternehmen kann dasselbe KI-System gleichzeitig in verschiedenen Risikoklassen betreiben. Das erhöht die Komplexität, aber auch die Steuerungsmöglichkeiten. Ein hochriskanter HR-Prozess erfordert den vollen Compliance-Aufwand. Derselbe Chatbot für allgemeine FAQ-Beantwortung bleibt davon unberührt.
Der Compliance-Pfad verzweigt sich
Die Risikoklasse bestimmt den weiteren Weg durch das NADOVO Framework. Hochrisiko-Prozesse durchlaufen die ASSESS-Phase mit systematischer Risikobewertung, Mitigationsplanung und Grundrechte-Prüfung. Limited Risk erfordert primär Transparenzmaßnahmen. Minimal Risk kann direkt in die IMPLEMENT-Phase übergehen.
Diese Verzweigung ist beabsichtigt. Der EU AI Act folgt einem risikobasierten Ansatz. Aufwand soll dort entstehen, wo Risiken bestehen. Wer seine Prozesse sauber klassifiziert, vermeidet sowohl Unter-Compliance bei kritischen Systemen als auch Über-Compliance bei unkritischen.
Stakeholder früh einbinden
Die DEFINE-Phase ist der richtige Zeitpunkt, um betroffene Stakeholder zu identifizieren. Wer nutzt das System? Wer ist von Entscheidungen betroffen? Wer trägt Verantwortung? Diese Fragen klären nicht nur regulatorische Anforderungen, sondern auch organisatorische Zuständigkeiten.
Für Hochrisiko-Systeme am Arbeitsplatz gilt eine explizite Informationspflicht gegenüber Arbeitnehmervertretern. Für bestimmte Deployer ist eine Grundrechte-Folgenabschätzung erforderlich. Diese Pflichten setzen voraus, dass die betroffenen Personen und Gruppen bereits in der DEFINE-Phase identifiziert wurden.
Das Ergebnis: Ein klassifiziertes Prozessregister
Am Ende der DEFINE-Phase steht ein vollständiges Prozessregister. Jedes Asset ist mit seinen Anwendungsfällen verknüpft. Jeder Prozess hat eine dokumentierte Risikoklasse. Stakeholder sind identifiziert. Der weitere Compliance-Pfad ist klar.
Dieses Register ist die Arbeitsgrundlage für alles, was folgt. Die ASSESS-Phase arbeitet nur mit den Hochrisiko-Prozessen. Die IMPLEMENT-Phase weiß, welche Maßnahmen für welche Risikoklasse umzusetzen sind. Die MONITOR-Phase überwacht nach Priorität. Ohne saubere DEFINE-Phase bleibt jede weitere Arbeit ineffizient.
Über den Autor
Jochen Stier ist AI Compliance Experte mit über 20 Jahren Erfahrung in Prozessmanagement und IT Service Management. Er unterstützt deutsche KMUs dabei, die Anforderungen des EU AI Act systematisch und pragmatisch umzusetzen. Sein 5-Phasen Framework NADOVO verbindet regulatorische Anforderungen mit praktischer Umsetzbarkeit, ohne Enterprise-Budgets oder komplexe Tools.
Weiterführende Informationen:
