Das Risiko einer KI steckt im Einsatz, nicht im Modell

Dasselbe Modell kann einen internen Textentwurf formulieren, Bewerbungen vorsortieren oder ein sicherheitsrelevantes System steuern. Technisch ähnlich heißt regulatorisch und organisatorisch nicht gleich riskant.

Wenn Organisationen KI-Inventare anlegen, beginnt die erste Spalte häufig mit Produkt- und Modellnamen. Das ist verständlich: Der Name ist sichtbar, lässt sich einkaufen und technisch konfigurieren. Für eine Risikobewertung ist er jedoch nur ein Baustein. Ein allgemeines Sprachmodell kann in einem unverbindlichen Ideenworkshop eingesetzt werden oder eine Entscheidung über Zugang zu Bildung, Beschäftigung oder öffentlichen Leistungen wesentlich beeinflussen. Der Kern bleibt derselbe, doch Zweck, Wirkung und Verantwortung verändern sich vollständig.

Belastbare Governance fragt deshalb nicht zuerst: „Welches Modell verwenden wir?" Sie fragt: Was tut das Gesamtsystem, für wen, in wessen Verantwortung, mit welchen Daten, mit welchem Einfluss auf Entscheidungen und mit welchen Folgen, wenn es irrt? Erst danach wird geprüft, welche Rechtsregime, technischen Kontrollen und Nachweise erforderlich sind.

Ein Modell ist noch kein Einsatzsystem

Ein KI-Modell erzeugt Ausgaben aus Eingaben. Das reale System umfasst mehr: Benutzeroberfläche, Prompts, Wissensquellen, Regeln, Datenpipelines, Werkzeuge, Automationen, menschliche Rollen, Schwellenwerte und nachgelagerte Entscheidungen. Auch die organisatorische Praxis gehört dazu. Ein offiziell nur „beratender" Score kann faktisch entscheidend werden, wenn Beschäftigte ihm fast immer folgen oder für Abweichungen eine besondere Begründung benötigen.

Darum reicht eine Lieferantenliste nicht als KI-Inventar. Eine belastbare Systemkarte beschreibt mindestens Eigentümer, Anbieter, Version, beabsichtigten Zweck, tatsächlich beobachtete Nutzung, Nutzergruppen, betroffene Personen, Eingaben, Ausgaben, Datenflüsse, Integrationen, Entscheidungspunkte, menschliche Eingriffsmöglichkeiten und vorhersehbaren Fehlgebrauch.

Die Systemgrenze muss konkret sein. „Wir nutzen generative KI" ist nicht klassifizierbar. „Ein internes Assistenzsystem fasst öffentliche Produktunterlagen für einen redaktionell geprüften Entwurf zusammen" ist prüfbar. „Ein System bewertet Bewerbungsunterlagen und priorisiert Personen für Interviews" ist ein anderer Use Case, selbst wenn beide denselben Modell-Endpunkt aufrufen.

Sechs Dimensionen machen den Kontext sichtbar

Eine erste Risikokarte lässt sich mit sechs Fragen aufbauen.

1 · Zweck: Welche Aufgabe soll das System erfüllen, und welche Aufgabe ausdrücklich nicht?

2 · Rolle: Wer entwickelt, anbietet, importiert, vertreibt oder betreibt das System? Wer ändert seinen Zweck?

3 · Betroffene: Wer erlebt die Folgen, auch wenn diese Person das System nie selbst bedient?

4 · Entscheidungswirkung: Informiert die Ausgabe nur, priorisiert sie Fälle oder bestimmt sie ein Ergebnis faktisch mit?

5 · Daten und Umgebung: Welche Daten fließen wohin, wie sensibel sind sie, und welche weiteren Systeme werden ausgelöst?

6 · Autonomie und Konsequenz: Welche Aktionen kann das System ohne wirksamen Zwischenstopp ausführen, und wie reversibel ist ein Fehler?

Diese Dimensionen sind kein Ersatz für die gesetzliche Prüfung. Sie verhindern aber typische Kurzschlüsse. Sensible Daten erhöhen Schutzbedarf, machen ein System jedoch nicht allein deshalb nach dem AI Act zu einem Hochrisiko-System. Umgekehrt kann ein Use Case grundrechtsrelevant sein, obwohl er nur wenige personenbezogene Daten verarbeitet. Auch „agentisch" ist keine eigene gesetzliche Risikoklasse. Entscheidend bleiben Funktion und Einsatz.

Der AI Act ist kein einfacher Vier-Farben-Aufkleber

In Einführungen wird der EU AI Act oft als Pyramide aus unzulässigem, hohem, begrenztem und minimalem Risiko dargestellt. Das hilft bei der Orientierung, darf aber nicht zur automatischen Klassifizierung werden. Der verbindliche Text arbeitet mit verschiedenen Regelungswegen.

Artikel 5 benennt verbotene Praktiken unter ihren jeweiligen Voraussetzungen. Artikel 6 verbindet Hochrisiko-Einstufungen einerseits mit bestimmten regulierten Produkten und Sicherheitskomponenten aus Anhang I, andererseits mit den in Anhang III beschriebenen Einsatzfeldern. Dazu gehören unter anderem bestimmte Anwendungen in Biometrie, Bildung, Beschäftigung, wesentlichen privaten und öffentlichen Diensten, Strafverfolgung, Migration und Rechtspflege.

Für einzelne in Anhang III genannte Systeme enthält Artikel 6 Absatz 3 eine Ausnahme, wenn sie kein erhebliches Risiko für Gesundheit, Sicherheit oder Grundrechte darstellen und insbesondere das Entscheidungsergebnis nicht wesentlich beeinflussen. Profiling natürlicher Personen bleibt innerhalb dieser Konstellation besonders behandelt. Wer die Ausnahme als Anbieter nutzt, muss die Bewertung vor dem Inverkehrbringen oder der Inbetriebnahme dokumentieren.

Artikel 50 schafft daneben Transparenzpflichten für bestimmte Systeme und Inhalte, etwa bei direkter Interaktion mit Menschen, synthetischen Inhalten, Deepfakes sowie bestimmten Emotionserkennungs- und biometrischen Kategorisierungssystemen. Die Vorschriften für General-Purpose-AI-Modelle bilden wiederum einen eigenen Regelungsstrang. Ein System kann daher mehrere Pflichtenpfade gleichzeitig berühren.

Personenbezogene Daten und Hochrisiko sind zwei verschiedene Prüfungen

Ein häufiger Fehler lautet: „Sobald personenbezogene oder sensible Daten vorkommen, ist die KI Hochrisiko." So funktioniert die Einstufung nicht. Der AI Act und die DSGVO haben unterschiedliche Tatbestände, Rollen und Rechtsfolgen. Sie müssen parallel geprüft, dürfen aber nicht ineinander aufgelöst werden.

Die DSGVO fragt unter anderem nach Rechtsgrundlage, Zweckbindung, Datenminimierung, Transparenz, Sicherheit, Betroffenenrechten und gegebenenfalls einer Datenschutz-Folgenabschätzung. Artikel 22 betrifft Entscheidungen, die ausschließlich automatisiert erfolgen und rechtliche Wirkung entfalten oder Personen ähnlich erheblich beeinträchtigen, einschließlich der dort geregelten Voraussetzungen und Ausnahmen. Nicht jede KI-Assistenz fällt darunter; ein dekorativer „Human-in-the-Loop" verhindert die Anwendung aber nicht automatisch, wenn der menschliche Beitrag faktisch keine Bedeutung hat.

Der AI Act fragt bei Hochrisiko vor allem nach dem beabsichtigten Zweck und den Klassifizierungsregeln aus Artikel 6 und den Anhängen. Besondere Kategorien personenbezogener Daten können die Risikobetrachtung verschärfen und andere Pflichten auslösen, ersetzen aber nicht diese Prüfung. In der Praxis braucht man daher eine Rechtslandkarte statt eines einzigen Risikoetiketts.

Die Rolle entscheidet mit über die Pflicht

Dieselbe Organisation kann bei einem System Betreiberin und bei einem anderen Anbieterin sein. Wer ein fertiges Werkzeug nur innerhalb des vorgesehenen Rahmens einsetzt, hat andere Pflichten als jemand, der es unter eigenem Namen anbietet, wesentlich verändert oder seinen beabsichtigten Zweck so ändert, dass eine neue Einstufung entsteht. Artikel 25 regelt Verantwortlichkeiten entlang der Wertschöpfungskette und Fälle, in denen sich Rollen verschieben können.

Eine technische Änderung ist deshalb nicht nur Release Management. Neue Datenquellen, ein neuer Entscheidungspunkt, zusätzliche Autonomie oder eine Umwidmung können die Systemkarte und die rechtliche Analyse verändern. Jede Freigabe sollte festhalten: Was änderte sich? Bleibt der Zweck gleich? Ändert sich die betroffene Gruppe? Entsteht eine neue wesentliche Wirkung? Welche alte Bewertung ist dadurch überholt?

Rollen müssen auch vertraglich und operativ zusammenpassen. Wer überwacht Vorfälle? Wer hält technische Unterlagen? Wer informiert Betroffene? Wer kann das System stoppen? Ein Vertrag, der Verantwortung pauschal an einen Dienstleister schiebt, ändert nicht automatisch die tatsächliche Rolle.

Risikobewertung ist eine Behauptung mit Evidenz

„Kein Hochrisiko" darf kein unkommentiertes Dropdown sein. Die Einstufung ist eine begründete Aussage und braucht Belege. Dazu gehören der definierte Zweck, Prozessdiagramm, Nutzer- und Betroffenengruppen, Entscheidungseinfluss, Datenquellen, Modell- und Toolgrenzen, menschliche Kontrolle, Tests, bekannte Fehlermodi und die angewandten Vorschriften.

Ein nützlicher Klassifizierungsdatensatz trennt drei Ebenen: Tatsachen über das System, rechtliche oder fachliche Kriterien und Schlussfolgerungen. Tatsachen können technisch geprüft werden. Kriterien werden versioniert und mit Primärquellen verknüpft. Schlussfolgerungen tragen Autor, Datum, Geltungsbereich, Unsicherheiten und nächste Überprüfung.

Automatisierte Compliance-Checker können Fragen strukturieren und offensichtliche Lücken finden. Sie sind ein Triage-Werkzeug, kein Freigabestempel. Wenn Eingaben unvollständig oder Begriffe falsch verstanden werden, wird auch die Ausgabe überzeugend falsch. Für folgenreiche oder unklare Fälle braucht es qualifizierte Fachprüfung.

Sandbox ist Lernraum, nicht universelle Zertifizierung

Regulatorische Sandboxes sollen unter Aufsicht eine kontrollierte Umgebung für Entwicklung, Training, Test und Validierung innovativer KI-Systeme bieten. Mitgliedstaaten müssen nach dem AI Act mindestens eine Sandbox auf nationaler Ebene verfügbar machen; der offizielle Zeitplan nennt hierfür den 2. August 2027.

Daraus folgt nicht, dass jedes Hochrisiko-System zwingend eine Sandbox durchlaufen muss. Ebenso ist die Teilnahme kein allgemeines „grünes Licht", keine Garantie völliger Rechtskonformität und keine automatische Versicherungsvoraussetzung. Sie kann Rechtssicherheit und Compliance-Lernen unterstützen; Verantwortung und Aufsicht bleiben bestehen. Reale Tests außerhalb einer Sandbox haben eigene Voraussetzungen.

Diese Unterscheidung ist wichtig, weil Governance sonst zu einem einmaligen Zertifikatsprojekt verkommt. Risiko verändert sich mit Daten, Nutzern, Versionen und organisatorischer Praxis. Eine einmalige Prüfung ersetzt kein Post-Market-Monitoring, keine Vorfallbearbeitung und keine regelmäßige Re-Klassifizierung.

Zeitpunkte müssen Teil des Registers sein

Der AI Act gilt gestaffelt. Verbote und KI-Kompetenzpflichten gelten bereits seit dem 2. Februar 2025; weitere Governance- und GPAI-Bestimmungen seit dem 2. August 2025. Der Großteil der Verordnung einschließlich der Transparenzpflichten aus Artikel 50 gilt ab dem 2. August 2026. Für bestimmte Hochrisiko-Konstellationen greifen spätere Termine. Zudem existieren Übergangsregeln für bereits in Verkehr gebrachte Systeme.

Eine Klassifizierung ohne Stichtag ist daher unvollständig. Das Register braucht mindestens Bewertungsdatum, maßgebliche Rechtsfassung, geplanten Einsatzbeginn, Übergangsstatus und nächste Überprüfung. Ein System kann heute vorbereitet, ab August anders gekennzeichnet und später zusätzlichen Hochrisiko-Pflichten unterliegen.

Auch Leitlinien und Durchführungsvorschriften entwickeln sich. Governance sollte Primärtexte und offizielle Auslegungshilfen beobachten, ohne jede neue Zusammenfassung blind zu übernehmen. Änderungen werden wie Datenmigrationen behandelt: Quelle erfassen, Auswirkung analysieren, betroffene Systemkarten finden, Entscheidungen aktualisieren und Nachweis erhalten.

Aus der Klassifizierung wird ein Kontrollplan

Die Risikoklasse ist nicht das Endprodukt. Sie entscheidet, welche Kontrollen umgesetzt und nachgewiesen werden. Dazu können Daten-Governance, technische Dokumentation, Protokollierung, Transparenzhinweise, menschliche Aufsicht, Robustheits- und Sicherheitstests, Grundrechte- oder Datenschutz-Folgenabschätzungen, Lieferantenkontrollen und Vorfallprozesse gehören.

Ein praxistauglicher Ablauf sieht so aus:

1. System und Prozessgrenze definieren.

2. Zweck, Rollen, Betroffene und Entscheidungseinfluss dokumentieren.

3. AI Act, Datenschutz und sektorale Regeln getrennt abbilden.

4. Einstufung mit Primärquellen und Unsicherheiten begründen.

5. Kontrollen mit Eigentümer, Termin und Evidenz festlegen.

6. Vor dem Go-live Tests und wirksame menschliche Eingriffe nachweisen.

7. Nutzung, Änderungen, Vorfälle und Drift beobachten.

8. Bei Zweck-, Rollen- oder Wirkungsänderung neu klassifizieren.

So wird aus Compliance kein Formularfriedhof. Die Klassifizierung steuert Architektur, Datenzugang, Freigaben und Betrieb. Genau dort gehört sie hin: in den Lebenszyklus des Systems.

Übungsblatt: Klassifiziere einen Use Case statt eines Modellnamens

Wähle ein geplantes KI-System und beschreibe es so konkret, dass eine außenstehende Fachperson den tatsächlichen Einsatz versteht.

1. Formuliere Zweck, Nicht-Zweck und Systemgrenze.

2. Benenne Anbieter-, Betreiber- und weitere mögliche Rollen.

3. Zeichne Datenfluss, Toolaktionen und nachgelagerte Entscheidungen.

4. Beschreibe Nutzer, betroffene Personen und mögliche Schäden.

5. Prüfe Verbote, Hochrisiko-Regeln, Transparenzpflichten und GPAI-Bezüge getrennt.

6. Prüfe Datenschutz und sektorale Anforderungen als eigene Spuren.

7. Halte Evidenz, Unsicherheit, Prüfer und Stichtag fest.

8. Leite Kontrollen, Stop-Kriterien und Re-Klassifizierungs-Trigger ab.

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Dieser Artikel vermittelt eine technische und organisatorische Klassifizierungsmethode, keine Rechtsberatung. Begriffe wie „minimales" oder „begrenztes Risiko" sind als Kommunikationshilfen verbreitet, bilden aber keine vollständige juristische Entscheidungslogik. Ob Pflichten greifen, hängt unter anderem von Anwendungsbereich, Akteursrolle, beabsichtigtem Zweck, konkretem Use Case, Zeitpunkt und weiteren Rechtsregimen ab. Stand der redaktionellen Prüfung: 16. Juli 2026.