EU AI Act Risikoklassifizierung durchführen

Ein KI-Assistent im SAP-Service, eine automatisierte Bonitätsbewertung oder eine Lösung zur Vorauswahl von Bewerbungen können technisch auf ähnlichen Modellen basieren. Regulatorisch sind sie jedoch nicht vergleichbar. Wer die EU AI Act Risikoklassifizierung durchführen will, muss deshalb nicht beim Modell beginnen, sondern beim konkreten Einsatzzweck, den betroffenen Personen und der tatsächlichen Wirkung im Prozess. Nur so entstehen belastbare Daten, regulatorische Sicherheit und ein stabiler Betrieb.

Der EU AI Act klassifiziert nicht abstrakt „KI“, sondern KI-Systeme in ihrer vorgesehenen Verwendung. Ein Sprachmodell kann in einem internen Wissenschatbot ein begrenztes Transparenzthema sein, als Entscheidungskomponente im Recruiting aber eine andere Einordnung auslösen. Die Risikoklassifizierung ist daher keine einmalige Rechtsfrage für die Beschaffung. Sie ist ein Steuerungsprozess zwischen Fachbereich, IT, Datenschutz, Compliance, Einkauf und Betrieb.

EU AI Act Risikoklassifizierung durchführen: Der richtige Ausgangspunkt

Die erste belastbare Entscheidung lautet: Welches System wird für welchen Zweck eingesetzt? Projektteams scheitern hier häufig, weil sie Produktnamen, Modellversionen oder allgemeine Herstellerbeschreibungen dokumentieren, nicht aber die reale Prozesswirkung. Für die Einordnung zählt, ob ein System Inhalte erzeugt, Empfehlungen abgibt, priorisiert, profiliert oder Entscheidungen vorbereitet und welche Handlungen Menschen oder nachgelagerte Systeme daran anschließen.

Erstellen Sie deshalb für jeden Use Case einen kompakten Systemsteckbrief. Er sollte die fachliche Zielsetzung, Nutzergruppen, betroffene Personengruppen, Datenarten, Ein- und Ausgaben, Schnittstellen sowie die Folgen einer fehlerhaften Ausgabe enthalten. Bei SAP-nahen Szenarien gehört insbesondere dazu, ob Ergebnisse in Workflows, Rollenfreigaben, Lieferantenbewertungen, Personalprozesse oder Steuerungskennzahlen zurückfließen.

Ebenso entscheidend ist die Rollenklärung. Der Anbieter eines Standardprodukts kann Anbieter im Sinn des EU AI Act sein. Ein Unternehmen, das ein System unter eigenem Namen bereitstellt, wesentlich verändert oder den vorgesehenen Zweck verändert, kann diese Rolle selbst übernehmen. Wer ein System innerhalb der Organisation nutzt, ist regelmäßig Betreiber. Je nach Rolle unterscheiden sich Nachweis-, Prüf- und Betriebspflichten erheblich. Diese Zuordnung muss für jede Lieferkette nachvollziehbar sein - vom Modellanbieter über den Implementierungspartner bis zum Fachbereich, der das System nutzt.

Nicht das Tool, sondern der Use Case wird bewertet

Ein typischer Fehler lautet: „Unser Anbieter sagt, die Plattform sei EU-AI-Act-konform.“ Das kann für Teile des Produkts zutreffen, ersetzt aber keine eigene Einordnung. Konformitätserklärungen, technische Dokumentationen und Vertragsanlagen sind wichtige Nachweise. Sie beantworten jedoch nicht automatisch, ob die konkrete Konfiguration, Datenanbindung und Nutzung im Unternehmen ein Hochrisiko-Szenario schafft.

Das gilt besonders für integrierte Architekturen. Wird ein generatives Modell mit HR-Stammdaten, Ticketdaten, Qualitätsmeldungen oder CRM-Informationen verbunden, verändert sich die Bewertung durch Kontext, Berechtigungen und Prozessfolgen. Auch ein menschlicher Freigabeschritt befreit nicht pauschal von Anforderungen. Relevant ist, ob die menschliche Aufsicht wirksam ist oder ob Mitarbeitende Ergebnisse faktisch nur noch bestätigen.

Die vier Risikobereiche korrekt unterscheiden

Der EU AI Act arbeitet mit einer risikobasierten Systematik. Für die Projektpraxis empfiehlt sich eine klare Trennung der vier Bereiche, ohne aus jeder KI-Anwendung vorschnell ein Hochrisiko-Projekt zu machen.

Verbotene Praktiken stehen am Anfang der Prüfung. Bestimmte Anwendungen sind nicht zulässig, etwa einzelne Formen manipulativer oder ausbeuterischer KI, Social Scoring oder bestimmte biometrische Kategorisierungen. Für solche Fälle ist nicht Risikominderung, sondern ein Nutzungsstopp die richtige Maßnahme. Die Verbote gelten bereits seit dem 2. Februar 2025.

Hochrisiko-KI-Systeme können entweder als Sicherheitskomponente oder Produkt in regulierten Bereichen betroffen sein oder unter die in Anhang III benannten Einsatzfelder fallen. Dazu gehören unter anderem Beschäftigung, Bildung, Zugang zu wesentlichen privaten oder öffentlichen Leistungen, Strafverfolgung, Migration und bestimmte Bereiche kritischer Infrastruktur. Im Unternehmenskontext ist Recruiting besonders relevant: Systeme zur Vorauswahl, Bewertung oder Steuerung von Bewerbenden können Hochrisiko-KI sein.

Bei Anhang-III-Fällen gibt es eine begrenzte Ausnahme, wenn ein System nur eine eng umrissene verfahrensrechtliche oder vorbereitende Aufgabe erfüllt und keine erhebliche Gefahr für Gesundheit, Sicherheit oder Grundrechte besteht. Diese Ausnahme verlangt eine begründete Einzelfallentscheidung. Sobald das System Personen profiliert, greift sie nicht. Ein einfacher Terminassistent kann daher anders einzuordnen sein als ein Tool, das Bewerbungen priorisiert oder Leistungspotenziale prognostiziert.

KI-Systeme mit Transparenzpflichten betreffen beispielsweise Interaktionen mit Chatbots oder die Erzeugung bestimmter synthetischer Inhalte. Hier stehen klare Hinweise für Nutzende, Kennzeichnung und organisatorisch kontrollierte Kommunikationswege im Mittelpunkt. Ein Kundenchatbot braucht nicht automatisch ein umfassendes Hochrisiko-Regime. Er darf aber auch nicht so gestaltet sein, dass Kundinnen und Kunden über die maschinelle Interaktion getäuscht werden.

KI mit geringem oder minimalem Risiko bleibt der größte Anwendungsbereich. Auch dort sind Governance-Regeln sinnvoll, etwa Freigaben für Datenquellen, Berechtigungskonzepte, Qualitätsprüfungen und Schulungen. Der EU AI Act verlangt nicht, jede interne Textzusammenfassung wie ein kritisches Regulierungsvorhaben zu behandeln. Ein einheitlicher Mindeststandard verhindert jedoch Schatten-KI und unkontrollierte Datenabflüsse.

General-Purpose AI gesondert betrachten

General-Purpose-AI-Modelle wie große Sprachmodelle sind kein Ersatz für die Use-Case-Prüfung. Für ihre Anbieter gelten eigene Anforderungen, die seit dem 2. August 2025 stufenweise relevant sind. Ein Unternehmen, das ein solches Modell lediglich in eine interne Lösung integriert, muss vor allem seine Betreiberrolle, die Vertragslage und die konkrete Systemfunktion bewerten.

Wird ein Modell jedoch wesentlich verändert, unter eigenem Namen bereitgestellt oder in eine Anwendung mit hohem Risiko überführt, verschiebt sich die Verantwortung. Beschaffung und Architekturentscheidung gehören deshalb früh zusammen. Wer erst vor dem Go-Live nach Trainingsdaten, Logging oder Änderungen am Modell fragt, produziert unnötige Nacharbeit und gefährdet den Terminplan.

Ein prüfbarer Ablauf für laufende Projekte

Eine tragfähige Klassifizierung lässt sich in bestehende Projektsteuerung integrieren. Sie muss weder ein Parallelprojekt noch ein reines Compliance-Dokument sein. Entscheidend sind eindeutige Prüfpunkte und nachvollziehbare Entscheidungen.

Zunächst wird ein vollständiges Use-Case-Inventar aufgebaut. Dabei werden auch Pilotlösungen, Fachbereichsprototypen und extern beschaffte SaaS-Funktionen erfasst. Anschließend prüft das interdisziplinäre Team Zweck, Prozesswirkung, Rollen und Risikokategorie. Das Ergebnis sollte nicht nur „hoch“ oder „niedrig“ lauten, sondern eine begründete Entscheidung mit Quellen, Annahmen und Verantwortlichen enthalten.

Danach folgt die Pflichtenanalyse. Bei Hochrisiko-Systemen betrifft sie je nach Rolle unter anderem Risikomanagement, Daten-Governance, technische Dokumentation, Protokollierung, Transparenz, menschliche Aufsicht, Genauigkeit, Cybersicherheit und Qualitätsmanagement. Betreiber müssen insbesondere sicherstellen, dass das System gemäß Anleitung eingesetzt wird, die menschliche Aufsicht organisatorisch wirksam ist und relevante Betriebsereignisse nachvollziehbar bleiben.

Im dritten Schritt werden die Anforderungen in Arbeitspakete übersetzt. Ein abstrakter Vermerk wie „Human Oversight sicherstellen“ genügt nicht. Benötigt werden benannte Rollen, Eskalationswege, Schulungen, Freigaberegeln und Nachweise. Wenn eine KI Lieferantenrisiken priorisiert, muss etwa klar sein, wer die Empfehlung prüft, welche Datenbasis zugelassen ist, wann eine Übersteuerung erforderlich wird und wie diese Entscheidung protokolliert wird.

Schließlich wird die Klassifizierung in Release-, Change- und Betriebsprozesse eingebunden. Neue Datenquellen, ein anderer Nutzerkreis, eine geänderte Entscheidungsschwelle oder eine neue Schnittstelle können die ursprüngliche Bewertung entwerten. Die Risikoklassifizierung braucht deshalb einen festen Review-Auslöser, etwa bei wesentlichen Releases, neuen Fachprozessen, Sicherheitsvorfällen oder Lieferantenwechseln.

Dokumentation schafft Steuerbarkeit, nicht Bürokratie

Revisionssicheres Reporting entsteht nicht durch lange Texte, sondern durch konsistente Artefakte. Bewährt haben sich ein zentraler Use-Case-Registereintrag, die dokumentierte Risikobewertung, Rollen- und Verantwortlichkeitsmatrix, Nachweise des Anbieters, Datenflussbild, Betriebsanweisung sowie ein Protokoll der Freigabeentscheidung. Diese Unterlagen sollten aufeinander verweisen und im Projekt nicht in getrennten Ablagen von IT, Recht und Fachbereich verschwinden.

Die Zeitachse verdient besondere Aufmerksamkeit. Viele Regelungen des EU AI Act gelten ab dem 2. August 2026, während für bestimmte Hochrisiko-KI als Sicherheitskomponente oder Teil regulierter Produkte abweichende Fristen bis zum 2. August 2027 relevant sind. Welche Pflichten zu welchem Zeitpunkt greifen, hängt vom Anwendungsfall und der Rolle ab. Eine Klassifizierung sollte daher immer auch eine Umsetzungsplanung mit Stichtagen enthalten.

Für mittelständische Unternehmen ist ein fokussierter Quick Check oft der richtige Einstieg: Welche KI-Systeme laufen bereits, welche davon beeinflussen Personen oder kritische Entscheidungen, und wo fehlen belastbare Nachweise? Bei komplexen Vorhaben - etwa einer S/4HANA-Transformation mit KI-gestützten Workflows - muss daraus ein verbindlicher Governance-Strang im Gesamtprojekt werden. Quteco verbindet diese Einordnung mit Datenflussanalyse, Rollenmodellen und produktionsnaher Umsetzung, damit rechtliche Anforderungen im Betrieb kontrollierbar bleiben.

Die beste Risikoklassifizierung ist nicht die umfangreichste. Sie ist diejenige, die eine konkrete Entscheidung trägt, Verantwortlichkeiten sichtbar macht und bei der nächsten Änderung noch verständlich ist. Genau dort wird aus regulatorischer Pflicht ein belastbarer Bestandteil des Projekt- und Betriebsmodells.

Sie möchten die KI-Systeme in Ihrem Unternehmen nach dem EU AI Act einordnen?

Quteco unterstützt Sie dabei, bestehende und geplante KI-Use-Cases zu erfassen, Rollen und Risiken zu bewerten und die erforderlichen Governance- und Dokumentationsstrukturen für Projekt und Betrieb aufzubauen. Bei rechtlichen Fragestellungen kann ergänzend die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH eingebunden werden.