KI Risikoklassifizierung durchführen im Unternehmen
Eine KI-Anwendung ist nicht deshalb unkritisch, weil sie zunächst nur einen einzelnen Prozess unterstützt. Wenn sie etwa Bewerbungen vorsortiert, Kreditentscheidungen vorbereitet, Lieferanten bewertet oder Wartungseinsätze priorisiert, beeinflusst ihr Ergebnis operative oder personenbezogene Entscheidungen. Wer eine KI Risikoklassifizierung durchführen will, muss daher nicht beim Modellnamen beginnen, sondern beim tatsächlichen Einsatz im Unternehmen.
Für viele Organisationen ist genau das der anspruchsvolle Teil: Die KI-Komponente ist häufig in eine SAP-nahe Prozesslandschaft, eine Fachanwendung oder ein extern bezogenes Produkt eingebettet. Datenquellen, Rollen, Entscheidungsschritte und Änderungen am System sind auf mehrere Teams verteilt. Eine belastbare Einordnung nach EU AI Act entsteht deshalb nicht durch ein einmaliges Formular, sondern durch ein nachvollziehbares Verfahren mit klaren Verantwortlichkeiten.
Warum die Risikoklassifizierung mehr als Compliance ist
Die Risikoklassifizierung schafft eine Arbeitsgrundlage für Governance, Beschaffung und Betrieb. Sie legt fest, welche Nachweise erforderlich sind, welche Kontrollen vor dem Go-live greifen müssen und wann Änderungen erneut bewertet werden. Das reduziert nicht nur regulatorische Unsicherheit. Es verhindert auch, dass kritische KI-Funktionen ohne ausreichende Datenbasis, menschliche Kontrolle oder dokumentierte Freigabe produktiv gehen.
Der EU AI Act unterscheidet insbesondere zwischen verbotenen KI-Praktiken, Hochrisiko-KI-Systemen, KI-Systemen mit Transparenzpflichten und Anwendungen, für die keine spezifischen Pflichten aus diesen Kategorien folgen. Diese Kategorien sind jedoch kein Ersatz für die eigene technische und organisatorische Risikobewertung. Datenschutz, Informationssicherheit, sektorale Vorgaben und interne Kontrollanforderungen können zusätzliche Maßnahmen erfordern.
Auch die Rolle des Unternehmens ist entscheidend. Wer ein System selbst entwickelt oder unter eigenem Namen bereitstellt, kann als Anbieter gelten. Wer eine Lösung lediglich nutzt, ist häufig Betreiber. Wird ein fremdes System wesentlich verändert oder sein Zweck so verändert, dass neue Auswirkungen entstehen, kann sich diese Zuordnung verschieben. Diese Frage sollte vor der fachlichen Klassifizierung geklärt werden, weil sich die Pflichten erheblich unterscheiden.
KI Risikoklassifizierung durchführen: der belastbare Ablauf
Ein pragmatischer Ablauf beginnt mit einer klaren Systemgrenze und führt anschließend von der Zweckbestimmung zu überprüfbaren Nachweisen. Fachbereich, IT, Informationssicherheit, Datenschutz, Compliance und Einkauf sollten dabei nicht nacheinander arbeiten. Sie benötigen ein gemeinsames Bewertungsobjekt und eine verbindliche Dokumentation.
1. Anwendungsfall und Systemgrenze präzise erfassen
Beschreiben Sie zunächst nicht die Technologie, sondern den Geschäftsvorgang. Welche Entscheidung oder Empfehlung erzeugt das System? Wer nutzt das Ergebnis? Welche Personen, Kunden, Beschäftigten, Lieferanten oder Anlagen können betroffen sein? Ebenso relevant ist, ob die KI autonom entscheidet, priorisiert, bewertet, klassifiziert, Inhalte generiert oder nur eine Suche verbessert.
Zur Systemgrenze gehören alle Komponenten, die das Ergebnis beeinflussen: Eingabedaten, Datenaufbereitung, Modell oder externe KI-API, Regeln im Fachsystem, Benutzeroberfläche, Schnittstellen und nachgelagerte Freigaben. In einer S/4HANA-nahen Anwendung kann beispielsweise ein Prognosemodell unkritisch erscheinen, während die automatische Übergabe seines Ergebnisses in eine Liefer- oder Sperrentscheidung die Risikolage verändert.
Die Zweckbestimmung muss konkret und versionsbezogen festgehalten werden. Formulierungen wie „Unterstützung im Vertrieb“ sind zu weit. Belastbar wäre etwa: „Priorisierung von Service-Tickets zur Einsatzplanung, ohne automatisierte Entscheidung über Leistungen oder Sanktionen.“ Nur mit einer solchen Beschreibung lässt sich später beurteilen, ob ein Update, ein neuer Datenbestand oder eine Prozessänderung den ursprünglichen Einsatzzweck verlässt.
2. Rollen und Lieferkette dokumentieren
Im zweiten Schritt wird die Lieferkette aufgenommen. Dazu zählen interne Entwicklungsteams, Fachbereiche, Cloud- oder Modellanbieter, Implementierungspartner, Datenlieferanten und die Instanz, die den produktiven Betrieb verantwortet. Gerade bei eingekauften KI-Funktionen genügt eine Herstellerbeschreibung nicht als Nachweis für die eigene Einordnung.
Prüfen Sie, welche Dokumentation vorliegt und welche Aussagen daraus tatsächlich für den konkreten Einsatz ableitbar sind. Dazu können technische Beschreibungen, Nutzungsvorgaben, Modellkarten, Testunterlagen, Sicherheitsinformationen und Vertragsunterlagen gehören. Fehlen wesentliche Informationen, ist das kein rein formales Beschaffungsproblem. Es begrenzt die Fähigkeit, Risiken fachlich zu bewerten und Kontrollen wirksam zu gestalten.
Für General-Purpose-AI-Modelle gelten eigene Anforderungen innerhalb des EU AI Act. Ihre Nutzung macht eine Fachanwendung nicht automatisch zum Hochrisikosystem. Umgekehrt entbindet der Rückgriff auf einen etablierten Modellanbieter nicht von der Prüfung des konkreten Anwendungsfalls, der Datenflüsse und der Prozessfolgen.
3. Verbotene Praktiken vor der Detailklassifizierung ausschließen
Bevor Teams umfangreiche Hochrisiko-Prüfungen aufsetzen, sollten sie klären, ob der geplante Einsatz überhaupt zulässig ist. Der EU AI Act enthält Verbote für bestimmte Praktiken, etwa in Bereichen manipulativer oder ausnutzender Einflussnahme sowie für weitere ausdrücklich geregelte Konstellationen. Die Bewertung hängt stark vom Zweck, Kontext und den betroffenen Personengruppen ab.
Hier ist eine frühzeitige Eskalation sinnvoll, wenn der Anwendungsfall sensible Verhaltensbewertung, biometrische Funktionen, besonders schutzbedürftige Gruppen oder weitreichende Folgen für Einzelpersonen berührt. Die rechtliche Einordnung sollte in solchen Fällen durch die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH erfolgen. Technisch muss parallel dokumentiert werden, welche Funktion tatsächlich vorgesehen ist und welche Funktionen wirksam ausgeschlossen werden.
4. Hochrisiko-Merkmale gegen den konkreten Einsatz prüfen
Die zentrale Frage lautet nicht, ob KI allgemein riskant sein kann. Maßgeblich ist, ob das System als Sicherheitskomponente eines regulierten Produkts eingesetzt wird oder unter einen im EU AI Act benannten Hochrisikobereich fällt. Dazu können unter bestimmten Voraussetzungen Anwendungen in Beschäftigung, Bildung, Zugang zu wesentlichen privaten oder öffentlichen Leistungen, Strafverfolgung, Migration oder Rechtspflege gehören.
Die Prüfung braucht eine Zuordnung von Funktion, Nutzerkreis, Entscheidungskontext und Wirkung. Ein System zur internen Wissenssuche hat eine andere Risikoprofilierung als eine Lösung, die Bewerbende bewertet oder die Kreditwürdigkeit beeinflusst. Auch ein menschlicher Freigabeschritt senkt das Risiko nicht automatisch. Entscheidend ist, ob die verantwortliche Person das Ergebnis tatsächlich verstehen, hinterfragen und ohne unverhältnismäßigen Druck überstimmen kann.
Das Ergebnis sollte als begründete Entscheidung festgehalten werden: Welche Vorschrift oder Kategorie wurde geprüft? Welche Tatsachen sprechen dafür oder dagegen? Welche Annahmen gelten? Wer hat die Bewertung freigegeben? Diese Dokumentation ist für revisionssicheres Reporting wichtiger als ein pauschales Etikett wie „geringes Risiko“.
5. Transparenz, Daten und Betrieb als eigene Prüffelder behandeln
Auch wenn kein Hochrisikosystem vorliegt, können Transparenzpflichten bestehen. Dies betrifft je nach Einsatz beispielsweise die Interaktion mit KI, erzeugte Inhalte oder bestimmte Erkennungsfunktionen. Fachbereich und Kommunikation müssen deshalb früh festlegen, welche Hinweise Nutzende oder Betroffene erhalten und an welcher Stelle sie im Prozess sichtbar sind.
Parallel sollten die Datenflüsse geprüft werden. Woher stammen Trainings-, Referenz- und Eingabedaten? Welche Daten werden an externe Dienste übertragen? Wie werden Zugriffe, Aufbewahrung, Löschung und Berechtigungen gesteuert? Bei SAP-Integrationen ist besonders darauf zu achten, dass Rollenmodelle, Schnittstellenfreigaben und Protokollierung zur tatsächlichen Datenverarbeitung passen.
Für den produktiven Betrieb braucht die Klassifizierung einen Kontrollrahmen. Dazu gehören messbare Qualitätskriterien, Tests vor Änderungen, Monitoring auf Fehlverhalten oder Leistungsabweichungen, ein Incident-Prozess und geregelte Eskalationswege. Bei Hochrisiko-Konstellationen steigen Tiefe und Formalisierung dieser Anforderungen deutlich. Aber auch bei anderen Anwendungen ist ein kontrollierter Betrieb sinnvoll, wenn Ergebnisse operative Entscheidungen beeinflussen.
Typische Fehler, die Projekte später ausbremsen
Der häufigste Fehler ist eine zu abstrakte Zweckbeschreibung. Sie führt dazu, dass Projektteams Risiken entweder übersehen oder vorsorglich Anforderungen erfüllen wollen, die für den konkreten Einsatz nicht gelten. Ebenso problematisch ist die Annahme, die Klassifizierung sei mit der Auswahl eines Anbieters abgeschlossen. Modellwechsel, neue Datenquellen, geänderte Prompt-Vorlagen, zusätzliche Schnittstellen oder eine stärkere Automatisierung können eine Neubewertung auslösen.
Ein weiterer Fehler liegt in der Trennung von Governance und Delivery. Wenn Testmanagement, Datenverantwortung, fachliche Abnahme und Compliance-Nachweise erst kurz vor dem Go-live zusammengeführt werden, fehlen häufig belastbare Testfälle und eindeutige Freigaben. Besser ist es, die Klassifizierung als Projektartefakt zu führen und bei jeder wesentlichen Änderung gezielt fortzuschreiben.
Klassifizierung in die Projektsteuerung integrieren
Für laufende Transformationsprogramme eignet sich ein gestuftes Vorgehen. Ein Quick Check schafft zunächst Transparenz über Anwendungsfälle, Rollen, Datenflüsse und offensichtliche Risikotreiber. Anschließend werden für priorisierte Systeme die Zweckbestimmung, die regulatorische Einordnung, die erforderlichen Nachweise und die Betriebsmaßnahmen vertieft.
Das Ergebnis sollte nicht in einer isolierten Compliance-Ablage enden. Es gehört in Architekturentscheidungen, Beschaffungsfreigaben, Testpläne, Cutover-Checklisten und das Betriebsmodell. So wird aus der Risikoklassifizierung eine steuerbare Entscheidung mit Verantwortlichen, Terminen und überprüfbaren Kriterien. Besonders bei produktionsnahen KI-Anwendungen lässt sich damit nachvollziehen, ob technische Leistungsfähigkeit und regulatorische Sicherheit im selben Takt entwickelt werden.
Einordnung vor dem produktiven Einsatz absichern
Quteco unterstützt Unternehmen mit Quick Checks und Workshops dabei, KI-Anwendungsfälle, Datenflüsse, Rollen und Betriebsanforderungen strukturiert zu erfassen. Für die rechtliche Bewertung zum EU AI Act kann die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH eingebunden werden. Entscheidend bleibt, die Einordnung vor dem Go-live in konkrete Test-, Freigabe- und Betriebsprozesse zu überführen - damit die Klassifizierung auch bei Änderungen belastbar bleibt.
