AI Act & Risikoklassen: Die häufigsten Fehlklassifizierungen (und ihre Folgen)

AI Act & Risikoklassen: Die häufigsten Fehlklassifizierungen (und ihre Folgen)

Einordnung zum Veröffentlichungszeitpunkt: Die Risikoeinordnung richtet sich nach Zweck und Einsatzkontext. Sie ist von der Frage zu trennen, wann eine konkrete Pflicht anwendbar wird. Ein gemeinsamer Stichtag für sämtliche KI-Systeme wäre deshalb keine tragfähige Planungsgrundlage.

Auf dem Papier wirkt die Risikologik des EU AI Act zunächst wie eine saubere Sortierung: Einordnen, Pflichten ableiten, fertig. In der Praxis ist genau dieser Schritt einer der größten Stolpersteine. Nicht, weil Teams das Thema „nicht verstehen“, sondern weil Klassifizierung im Alltag selten an einem klaren, stabilen Entscheidungsprozess hängt. Stattdessen passiert sie oft nebenbei: im Projekt, im Einkauf, in der IT, manchmal in der Fachabteilung – je nachdem, wer gerade am schnellsten ist. Das Ergebnis ist dann eine Mischung aus gut gemeinten Annahmen und unvollständigen Informationen. Und genau dort entstehen Fehlklassifizierungen.

Warum ist das so kritisch? Weil die Risikoklasse im EU AI Act nicht nur ein Label ist. Sie steuert, wie streng Sie Anforderungen erfüllen müssen, welche Nachweise Sie brauchen, wie viel Governance-Takt sinnvoll ist – und welche Risiken Sie eingehen, wenn Sie zu locker oder zu streng einsortieren. Eine Fehlklassifizierung ist daher selten nur ein „Formfehler“. Sie führt typischerweise zu einem von zwei Problemen: Entweder Sie unterschätzen Pflichten und stehen später mit Lücken da. Oder Sie überziehen unnötig und bauen eine Governance, die Projekte bremst und dann umgangen wird. Beides ist gefährlich – nur auf unterschiedliche Weise.

In diesem Beitrag geht es deshalb nicht um juristische Detaildebatten, sondern um die häufigsten Fehlklassifizierungen, die ich in der Praxis immer wieder sehe – und um die Folgen, die daraus entstehen. Vor allem aber zeige ich Ihnen, wie Sie die Einordnung so aufsetzen, dass sie schnell, nachvollziehbar und skalierbar wird. Denn genau das brauchen Sie, wenn aus wenigen KI-Anwendungen in kurzer Zeit deutlich mehr werden.

Warum Fehlklassifizierungen so oft passieren

Die Einordnung scheitert selten am Willen. Sie scheitert an drei typischen Rahmenbedingungen. Erstens: Die Informationen, die man für eine saubere Einordnung braucht, liegen verteilt. Der Fachbereich kennt Zweck und Wirkung, IT kennt die technische Umsetzung, Einkauf kennt den Vertrag, Security kennt die Daten- und Schutzsicht. Wenn diese Perspektiven nicht in einem kleinen, klaren Prozess zusammenkommen, wird zwangsläufig mit Annahmen gearbeitet. Zweitens: Klassifizierung wird häufig als einmalige Entscheidung verstanden („am Anfang einsortieren, dann ist es erledigt“). In der Realität ändern sich KI-Anwendungen: Datenquellen wechseln, Modelle werden aktualisiert, Nutzergruppen wachsen, neue Features kommen hinzu. Drittens: Viele Teams klassifizieren zu stark nach dem „KI-Gefühl“ („das ist doch nur ein Chatbot“) statt nach der konkreten Wirkung im Prozess („was passiert, wenn das Ding irrt?“).

Ein hilfreicher Gedanke ist deshalb: Klassifizierung ist kein Etikett, sondern eine Entscheidung mit Begründung. Und Entscheidungen brauchen eine Spur, sonst wird es im Audit und im Betrieb unruhig.

Die häufigsten Fehlklassifizierungen – und warum sie so verlockend sind

1) „Das ist nur Unterstützung, wir entscheiden ja selbst.“
Das ist vermutlich die häufigste Aussage, wenn Teams eine Anwendung als „niedrig“ einstufen wollen. Das Problem: In der Praxis wird aus „Unterstützung“ schnell eine faktische Entscheidung. Menschen vertrauen Empfehlungen, insbesondere wenn sie Zeit sparen, „intelligent“ wirken oder in einem Workflow bereits vor-sortieren. Wenn dann keine klare Qualitätssicherung, keine Grenzen und kein sauberes Monitoring existieren, kippt die Unterstützung in eine stille Automatisierung. Die Folge ist, dass Pflichten unterschätzt werden, obwohl die tatsächliche Wirkung hoch ist.

Woran Sie das erkennen: Wenn Nutzer in der Praxis selten widersprechen, wenn Ergebnisse direkt in Folgeprozesse laufen oder wenn die Empfehlung den Engpass steuert (z. B. Priorisierung, Auswahl, Ablehnung), dann ist die Wirkung stärker als „nur Unterstützung“.
Typische Folge: Zu niedrige Einstufung → zu wenig Anforderungen in Tests, Dokumentation und Betrieb → spätere Nacharbeit oder unangenehme Fragen.

2) „Intern ist weniger kritisch als extern.“
Interne Nutzung wird häufig automatisch als geringes Risiko gewertet. Das ist verständlich, aber gefährlich. Interne Anwendungen können enorme Auswirkungen haben: Personalauswahl, Leistungsbewertung, Zugriff auf Systeme, Priorisierung von Security-Vorfällen, Kredit- oder Schadensentscheidungen, Genehmigungen. Der Unterschied „intern/extern“ ist nicht der Kern. Der Kern ist: Welche Rechte, Chancen oder Belastungen beeinflusst das System?

Typische Folge: Unterschätzung interner Anwendungsfälle, die in sensiblen Prozessen wirken → Governance zu schwach → spätere Eskalation, wenn Beschwerden, Fehler oder Prüfungen auftreten.

3) „Der Anbieter ist groß, der wird das schon richtig machen.“
Viele Unternehmen verlassen sich bei der Einordnung stark auf Aussagen des Anbieters oder auf Marketingformulierungen („compliant“, „enterprise-ready“, „responsible AI“). Das kann hilfreich sein, ersetzt aber keine eigene Einordnung. Der EU AI Act stellt nicht nur auf den Anbieter ab, sondern auch auf Ihre Rolle und Ihren Einsatzkontext. Selbst eine gut gebaute Lösung kann im falschen Prozess hohe Risiken erzeugen.

Typische Folge: Klassifizierung nach Vendor-Aussagen statt nach tatsächlichem Einsatz → falsche Pflichten abgeleitet → Vertrags- und Nachweislücken.

4) „Wir klassifizieren das Modell.“
In der Praxis wird oft das Modell bewertet („das Modell ist doch harmlos“) statt der Anwendung im konkreten Prozess. Aber Risiken entstehen nicht im Modell isoliert, sondern in der Kombination aus Zweck, Daten, Nutzergruppe, Entscheidungskontext, Konsequenzen und Betrieb. Ein identisches Modell kann in einem Informations-Chatbot niedrig riskant sein und in einem Auswahl- oder Zugriffsprozess hoch riskant.

Typische Folge: Zu grobe Einordnung, weil nur der technische Baustein betrachtet wird → Governance passt nicht zur tatsächlichen Wirkung.

5) „Das ist ein Chatbot, also niedriges Risiko.“
Chatbots sind ein Klassiker, weil sie „harmlos“ aussehen. In Wirklichkeit hängt die Risikoklasse stark davon ab, was der Chatbot tut. Gibt er nur allgemeine Informationen? Oder steuert er Transaktionen, gibt rechtlich relevante Auskünfte, beeinflusst Entscheidungen, sammelt sensible Daten oder leitet Nutzer in Prozesse mit Konsequenzen? Ein Chatbot kann vom netten FAQ bis zum kritischen Prozessbaustein alles sein.

Typische Folge: Falsche Einordnung durch Schubladendenken („Chatbot = niedrig“) → fehlende Grenzen, fehlende Qualitätssicherung, fehlende Transparenz im Einsatz.

6) „Wir schauen nur auf die Daten.“
Daten sind wichtig, aber nicht ausreichend. Viele Klassifizierungen fokussieren zu stark auf Datensensitivität (z. B. personenbezogen ja/nein) und übersehen den Entscheidungskontext. Ein System kann mit wenig sensiblen Daten trotzdem hochkritisch sein, wenn es Rechte oder Chancen beeinflusst. Umgekehrt können sensible Daten in einem klar begrenzten, gut kontrollierten Kontext beherrschbar sein. Die Frage ist nicht nur „welche Daten“, sondern „welche Wirkung“.

Typische Folge: Fehleinschätzung, weil Datensicht die Wirkung überdeckt → Pflichten passen nicht zum Risiko.

7) „Einmal klassifiziert, immer klassifiziert.“
Das ist ein leiser Fehler, der erst später teuer wird. KI-Anwendungen verändern sich: neue Datenquellen, neue Nutzergruppen, neue Funktionen, neue Ziele. Oft passiert das schrittweise, ohne dass jemand den Risikosprung bemerkt. Genau deshalb gehört Klassifizierung in den Lebenszyklus: Bei wesentlichen Änderungen muss die Einordnung überprüft werden.

Typische Folge: Das Register wird „historisch“ → die Governance stimmt nicht mehr → Auditfähigkeit sinkt, operative Risiken steigen.

Was Fehlklassifizierungen in der Praxis anrichten

Die Folgen sind meist sehr konkret. Wenn Sie zu niedrig klassifizieren, fehlen typischerweise saubere Anforderungen in Tests, Dokumentation und Betrieb: keine klaren Qualitätskriterien, keine robuste Überwachung, keine definierte Verantwortlichkeit, keine nachvollziehbare Freigabe. Dann kommt der Moment, in dem ein Problem auftritt – oder ein Prüfer fragt – und Sie müssen nachträglich aufrüsten. Nachrüsten ist immer teurer als sauber starten, weil Sie bereits live sind, weil Prozesse schon laufen und weil Stakeholder ungeduldig werden.

Wenn Sie zu hoch klassifizieren, passiert etwas anderes: Sie bauen zu viel Prozess für Fälle, die es nicht brauchen. Projekte werden langsamer, Teams frustriert, und irgendwann entsteht „Schatten-KI“: Anwendungen werden an der Governance vorbei genutzt, weil man „schnell mal etwas ausprobieren“ will. Das ist das gefährlichste Ergebnis überhaupt, weil Sie dann Sichtbarkeit verlieren. Eine überstrenge Klassifizierung kann deshalb genauso riskant sein wie eine zu lockere – nur indirekter.

Im Kern geht es also um Balance: So wenig Governance wie möglich, so viel Governance wie nötig. Und diese Balance hängt direkt an einer sauberen, nachvollziehbaren Einordnung.

Ein pragmatisches Vorgehen, das Einordnung stabil macht

Wenn Sie Klassifizierung skalieren wollen, brauchen Sie keinen großen Apparat. Sie brauchen einen kleinen Prozess, der konsequent dieselben Fragen stellt und zu einer dokumentierten Entscheidung führt. In der Praxis haben sich vier Schritte bewährt, die Sie in vielen Organisationen innerhalb weniger Wochen etablieren können.

Schritt 1: Einsatzkontext in einem Satz festhalten.
Was macht die Anwendung – im Prozess, nicht technisch? Ein Satz reicht oft: „Das System priorisiert eingehende Fälle und schlägt Bearbeitungsreihenfolgen vor.“ Oder: „Das System generiert Textbausteine für Kundenkommunikation, die vor Versand freigegeben werden.“ Dieser Satz verhindert viele Missverständnisse, weil er das „KI-Gefühl“ durch eine konkrete Wirkung ersetzt.

Schritt 2: Wirkung statt Technik bewerten.
Fragen Sie konsequent: Welche Entscheidung oder welcher Prozess wird beeinflusst? Welche Konsequenz hat ein Fehler? Wer ist betroffen? Gibt es eine echte Alternative oder hängt der Betrieb daran? Diese Fragen sind für die Einordnung oft relevanter als „welches Modell“ oder „welcher Anbieter“.

Schritt 3: Mindestkontrollen je Stufe festlegen.
Damit Klassifizierung nicht nur ein Label ist, müssen Sie je Stufe klare Mindestanforderungen definieren. Für niedrig kann das sehr schlank sein (z. B. Owner, Zweck, Transparenzhinweis, Basis-Test). Für mittlere Stufen kommen Monitoring, klarere Tests, dokumentierte Grenzen hinzu. Für hohe Stufen brauchen Sie einen strengeren Freigabepunkt und deutlich robustere Nachweise. Der Clou: Je klarer diese Mindestkontrollen sind, desto weniger wird später diskutiert.

Schritt 4: Re-Klassifizierung an „wesentliche Änderungen“ koppeln.
Definieren Sie wenige Trigger, bei denen die Einordnung erneut geprüft wird. Zum Beispiel: neue Nutzergruppe, neue Datenquelle, neues Modell, neuer Zweck, deutliche Reichweitensteigerung oder Integration in kritische Prozesse. So bleibt Ihr Register lebendig und Ihre Governance passend.

Dezente Mini-Checkliste: 6 Fragen, die Fehlklassifizierungen verhindern

• Welche konkrete Entscheidung oder Prozesswirkung hat die Anwendung?
• Was ist die realistische Folge, wenn das System irrt?
• Wer ist betroffen (Kunden, Mitarbeitende, besonders sensible Gruppen)?
• Wie stark verlassen sich Nutzer faktisch auf die Ergebnisse?
• Was ändert sich bei Updates, neuen Daten oder neuen Funktionen?
• Welche Mindestkontrollen sind für diese Stufe zwingend?

Wenn Sie diese sechs Fragen sauber beantworten, ist Ihre Einordnung in der Regel belastbar – und vor allem erklärbar. Und „erklärbar“ ist im Audit fast genauso wichtig wie „richtig“, weil es zeigt, dass Sie nicht geraten, sondern entschieden haben.

Ein Praxisbild: Der Klassiker „wächst sich hoch“

Ein typisches Muster, das ich häufig sehe, ist das „wächst sich hoch“-Szenario. Eine Anwendung startet klein: ein Team nutzt ein KI-Tool, um interne Anfragen schneller zu sortieren. Es hilft, spart Zeit, wird als niedrig eingestuft. Dann passiert schrittweise folgendes: Die Anwendung wird in ein Ticketsystem integriert, die Vorschläge werden zum Standard, mehr Teams nutzen es, irgendwann werden Prioritäten automatisch gesetzt, und aus „Sortierung“ wird faktisch Steuerung. Spätestens dann ist die ursprüngliche Einordnung nicht mehr passend. Wenn aber niemand „wesentliche Änderung“ getriggert hat, bleibt das Register stehen, während die Realität weiterläuft.

Genau deshalb ist der Lebenszyklus so wichtig. Sie müssen nicht jedes Detail neu bewerten. Sie müssen nur sicherstellen, dass Wachstum und Änderungen nicht unbemerkt die Risikoklasse verändern.

Schlussgedanke

Die Einordnung in Risikoklassen ist kein lästiger Formalakt. Sie ist der Moment, in dem Sie Governance skalierbar machen – oder unbeabsichtigt sabotieren. Wenn Sie zu locker sind, fehlt Ihnen später die Basis, um Anforderungen sauber nachzuweisen. Wenn Sie zu streng sind, verlieren Sie Akzeptanz und Sichtbarkeit. Eine gute Klassifizierung ist deshalb vor allem eines: eine klare, begründete Entscheidung, die mit dem System mitwächst.

Im nächsten Beitrag können wir darauf aufbauen und praktisch zeigen, wie man ein KI-Register so gestaltet, dass Klassifizierung, Verantwortlichkeiten, Nachweise und Änderungen nicht in Tabellen sterben, sondern im Alltag tatsächlich genutzt werden – von Fachbereich, IT, Risk und Revision gleichermaßen.