KI-Risiko und der EU AI Act

2023 zwang ein Skandal bei der niederländischen Steuerbehörde, die *toeslagenaffaire*, ein komplettes Regierungskabinett zum Rücktritt. Der Auslöser: ein Algorithmus, der Familien wegen mutmaßlichen Betrugs bei der Kinderbetreuungsbeihilfe markierte, dabei Haushalte mit doppelter Staatsbürgerschaft überproportional traf und Zehntausenden Unschuldigen Geld zurückforderte. Kein CDO hat ein „Hochrisiko-KI-System" abgesegnet. Abgesegnet wurde ein Modell zur Betrugserkennung. Genau diese Lücke zwischen dem, wie das Business ein System bezeichnet, und dem, wie eine Aufsichtsbehörde es bezeichnen wird, ist das Terrain, das der EU AI Act nun kartiert. Ihre Aufgabe ist nicht, den Rechtsakt zu memorieren. Sie ist, eine Triage-Funktion aufzubauen, die Ihnen an jedem Montag sagt, welche Ihrer 200 Modelle zur *toeslagenaffaire* von morgen werden kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnten und welche langweilig genug sind, um sie in Ruhe zu lassen.

Der zentrale Reframe: Das Risiko liegt im Use Case, nicht im Modell

Der teuerste Fehler, den ein CDO mit dem AI Act machen kann, ist, auf der falschen Höhe zu steuern. Teams fragen instinktiv: „Ist dieses Modell riskant?" Der Rechtsakt stellt eine andere Frage: „**Wofür wird dieses System *eingesetzt*, und bei wem?**"

Derselbe Gradient-Boosted-Klassifikator ist unreguliert, wenn ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → Marketing-Leads rankt, und hochriskant, wenn er Bewerbungen vorsortiert. Die Technologie ist identisch. Die Risikostufe wird vollständig vom Einsatzkontext bestimmt. Deshalb scheitert modellzentrierte Governance: Sie können keine .pkl-Datei inspizieren und daraus die regulatorische Exposition ableiten. Sie müssen sie zu einer Entscheidung zurückverfolgen, die den Zugang eines Menschen zu Beschäftigung, Kredit, Bildung, wesentlichen Dienstleistungen oder Freiheit betrifft.

Der Rechtsakt sortiert Systeme in vier Stufen, und Ihr Operating Model sollte sie genau abbilden:

• Unannehmbares Risiko (verboten): Social Scoring durch Behörden, biometrische Echtzeit-Fernidentifizierung in öffentlichen Räumen (mit engen Ausnahmen), Emotionserkennung am Arbeitsplatz und in Schulen, manipulative unterschwellige Techniken. Hier heißt es nicht „sorgfältig steuern", sondern „nicht bauen". Seit Februar 2025 sind diese Verbote bereits in Kraft.
• Hohes Risiko: Systeme im Einsatz bei Beschäftigung, Kreditwürdigkeit, wesentlichen öffentlichen und privaten Dienstleistungen, Bildung, kritischer Infrastruktur, Strafverfolgung, Migration und Rechtspflege. Außerdem Produkte oder Sicherheitskomponenten, die bereits vom EU-Produktsicherheitsrecht erfasst sind. Diese Stufe trägt das volle Gewicht der Pflichten des Rechtsakts.
• Begrenztes Risiko: Systeme, die mit Menschen interagieren (Chatbots) oder synthetische Inhalte erzeugen. Die Pflicht ist im Wesentlichen Transparenz: den Leuten sagen, dass sie mit KI zu tun haben, Deepfakes kennzeichnen.
• Minimales Risiko: alles andere, Spamfilter, Bestandsoptimierung, Recommendation Engines im Retail. Keine verpflichtenden Anforderungen. Hier liegt der ganz überwiegende Teil Ihres Portfolios, und hier zerstört Über-Governance leise Wert.

Der strategische Insight: Der Rechtsakt ist darauf ausgelegt, Prüfaufwand zu konzentrieren. Wenn Ihr Governance-Programm alle 200 Modelle mit derselben Strenge behandelt, haben Sie die gesamte regulatorische Absicht missverstanden. Proportionalität ist kein Nice-to-have, sie ist das Betriebsprinzip, das die Gesetzgeber codiert haben.

Die Foundation-Model-Ebene separat beobachten

Es gibt einen fünften Strang, der quer zu den Stufen liegt: General-Purpose-AI-Modelle (GPAI), einschließlich Large Language Models. Wenn Sie auf einem Foundation Model aufbauen, liegen manche Pflichten beim Anbieter (OpenAI, Anthropic, Mistral). Aber wenn Sie substanziell fine-tunen oder wenn das Modell die Compute-Schwelle für systemisches Risiko überschreitet (10²⁵ FLOPs), können Pflichten auf Sie übergehen. Der praktische CDO-Move: ein Register führen, welche Foundation Models Sie konsumieren, ob Sie sie fine-tunen und welche Dokumentation der Anbieter Ihnen gibt. Wenn Ihr Legal-Team fragt „Sind wir Anbieter oder Betreiber dieses GPAI-Systems?", brauchen Sie die Antwort in einem Spreadsheet, nicht in einer Slack-Ausgrabung.

Die Triage-Funktion bauen: von 200 Systemen zu einer priorisierten Queue

Hier ist das Montagmorgen-Problem. Sie haben ein KI-Inventar (falls nicht, ist das die vorausgesetzte Lektion). Jetzt müssen Sie jeden Eintrag einer Stufe zuordnen, ohne ein Legal-Team einzustellen, das jedes Modell prüft. Die Antwort ist ein zweistufiger Funnel: ein günstiges automatisiertes Screening, dann eine menschliche Entscheidung für alles, was einen Draht auslöst.

Stufe eins, der Screening-Fragebogen. Hängen Sie fünf Fragen an jedes System in Ihrem Registry, beantwortet vom Product Owner, nicht vom Data Scientist:

1. Trifft das System eine Entscheidung über eine bestimmte Person oder beeinflusst sie mamaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßgeblich?
2. Betrifft diese Entscheidung deren Zugang zu Beschäftigung, Kredit, Bildung, Gesundheitsversorgung, öffentlichen Leistungen oder rechtlicher Stellung?
3. Wird das System von Strafverfolgung, Migrationsbehörden oder der Justiz genutzt?
4. Nutzt es biometrische Daten oder schließt es auf emotionale bzw. geschützte Merkmale?
5. Interagiert es direkt mit einer Person oder erzeugt es synthetische Medien?

Jedes „ja" bei F3 oder F4 eskaliert sofort. Ein „ja" bei F1 *und* F2 markiert hohes Risiko. Ein „ja" nur bei F5 markiert Transparenzpflichten bei begrenztem Risiko. Durchgängig „nein" landet bei minimalem Risiko. Sie können das als Entscheidungstabelle codieren, sodass die Klassifikation reproduzierbar und auditierbar ist und nicht Ansichtssache:

# ai_risk_triage_rules.yaml — deterministic first-pass classifier
rules:
  - id: prohibited_check
    if: uses_social_scoring OR realtime_biometric_public OR workplace_emotion_recognition
    then: PROHIBITED           # Stopp: Rechtsprüfung vor jeder weiteren Arbeit
  - id: high_risk_domain
    if: affects_individual AND domain in [employment, credit, education,
         essential_services, critical_infra, law_enforcement, migration, justice]
    then: HIGH_RISK
  - id: transparency_only
    if: interacts_with_human OR generates_synthetic_content
    then: LIMITED_RISK
  - id: default
    then: MINIMAL_RISK
review:
  HIGH_RISK: mandatory_human_adjudication   # bei hohem Risiko nie automatisch final
  PROHIBITED: mandatory_human_adjudication

Der Punkt der Konfiguration ist nicht die Syntax, sondern die Disziplin. Klassifikation wird zu einem Policy-Artefakt, das Sie versionieren, auditieren und gegenüber einer Aufsichtsbehörde verteidigen können, statt zu einer Einschätzung, die verdampft, sobald der Analyst geht, der sie getroffen hat.

Stufe zwei, die menschliche Entscheidung. Lassen Sie das automatisierte Screening nie ein Label „hohes Risiko" oder „verboten" final setzen. In den Grenzfällen liegt das Geld. Ein Kreditmodell, das nur einen internen Risiko-Score produziert, den ein menschlicher Kreditsachbearbeiter überstimmen kann, ist hochriskant oder auch nicht, je nachdem, wie stark der Mensch sich ihm tatsächlich beugt. Das ist die Frage der „wirksamen menschlichen Aufsicht", und sie entscheidet sich an der operativen Realität, nicht am Organigramm-Theater. Wenn Ihre Kreditsachbearbeiter 99,3 % der Modellempfehlungen genehmigen, haben Sie keine menschliche Aufsicht, Sie haben einen Gummistempel mit Puls, und eine Aufsichtsbehörde wird das System als hochriskant behandeln.

Was „hohes Risiko" operativ tatsächlich kostet

Wenn ein System in der Hochrisiko-Stufe landet, verlangt der Rechtsakt einen bestimmten Compliance-Stack. Als CDO müssen Sie wissen, was jede Pflicht von Ihren Teams fordert:

• Risikomanagementsystem: ein kontinuierlicher, dokumentierter Prozess, kein einmaliges Abnicken. Planen Sie laufende Headcount-Kosten ein.
• Data Governance: Trainings-, Validierungs- und Testdatensätze müssen relevant und repräsentativ sein und auf Bias geprüft werden. Hier zahlt sich Ihre bestehende Governance-Funktion aus, aber Sie brauchen jetzt dokumentierte Nachweise der Prüfung, nicht nur die Praxis.
• Technische Dokumentation und Logging: Das System muss seinen Betrieb automatisch loggen, um Nachvollziehbarkeit zu ermöglichen. Planen Sie das von Anfang an ein; Logging nachträglich in ein laufendes Modell einzubauen, ist brutal.
• Transparenz gegenüber Betreibern: klare Nutzungsanweisungen.
• Menschliche Aufsicht: eingebaut, nicht angeschraubt.
• Genauigkeit, Robustheit, Cybersicherheit: dokumentierte Performance-Schwellen und Resilienz gegen Angriffe.
• Konformitätsbewertung vor dem Inverkehrbringen und Registrierung in der EU-Datenbank.

Die entscheidende Unterscheidung, bei der die meisten CDOs falsch liegen: Sind Sie Anbieter oder Betreiber? Wenn Sie das Hochrisikosystem entwickeln (oder eines substanziell verändern), tragen Sie die vollen Anbieterpflichten. Wenn Sie lediglich das Hochrisikosystem eines anderen nutzen, sind Sie Betreiber mit einem leichteren, aber realen Pflichtenset: menschliche Aufsicht sicherstellen, Betrieb überwachen, Logs aufbewahren und es gemäß Anweisung nutzen. Die meisten Unternehmen sind gleichzeitig Betreiber von Vendor-Tools und Anbieter ihrer eigenen Entwicklungen. Ihr Registry muss für jedes System kennzeichnen, welchen Hut Sie tragen, denn Pflichten und Haftung unterscheiden sich stark.

Proportionalität als Designprinzip, nicht als Nachgedanke

Diese Lektion existiert, weil Angst schlechte Governance produziert. Wenn die Bußgelder zitiert werden, bis zu 35 Mio. € oder 7 % des globalen Umsatzes bei Verstößen mit verbotenen Systemen, ist der Instinkt der Führung, alles dichtzumachen. Dieser Instinkt macht Sie bei den 90 % Ihres Portfolios mit minimalem Risiko langsamer als Ihre Wettbewerber und gibt Ihnen dabei das falsche Gefühl, „KI-Governance gemacht" zu haben.

Die reife Haltung sind abgestufte Kontrollen, die abgestuftem Risiko entsprechen. Konkret:

• Systeme mit minimalem Risiko: registrieren, Ihre Standardpraktiken für Datenqualität und Model Monitoring anwenden, weitermachen. Keine Konformitätsbewertung, keine Sonderdokumentation. Lassen Sie nicht zu, dass ein gut gemeintes Risikokomitee Pflichten erfindet, die der Rechtsakt nicht verlangt.
• Systeme mit begrenztem Risiko: die Transparenzhinweise implementieren und prüfen, dass sie tatsächlich ausgelöst werden. Der Failure Mode hier ist ein Chatbot, der Nutzern nie sagt, dass er ein Bot ist, oder generierte Bilder ohne Herkunftskennzeichnung. Billig zu beheben, peinlich zu übersehen.
• Hochrisikosysteme: der volle Stack von oben, plus, und das ist der echte Wertbeitrag des CDO, ein *Gate vor dem Deployment*. Kein Hochrisikosystem geht ohne freigegebene Konformitätsbewertung live. Verdrahten Sie das als harten Block in Ihre Release-PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen →, genauso wie Sie ein Deploy blocken würden, das den Security-Scan nicht besteht.

Schauen Sie sich an, wie Klarna mit seiner Kundenservice-KI umgegangen ist. Als sie einen groß angelegten Assistenten ausgerollt haben, interagierte das System direkt mit Kunden, ein Transparenz-Trigger bei begrenztem Risiko, nicht hohes Risiko, weil es Serviceanfragen bearbeitet und keine Kreditentscheidungen. Ihre Kredit-Underwriting-Modelle liegen dagegen klar im hohen Risiko. Dasselbe Unternehmen, dieselbe KI-Investition, zwei völlig verschiedene Governance-Regime. Ein CDO, der beide identisch steuert, hat entweder den Chatbot abgeschnürt oder die Underwriting-Engine zu schwach geschützt. Proportionalität heißt, diese Trennung richtig zu ziehen.

Der Zeitplan ist Ihre Planungsrestriktion

Der Rechtsakt greift in Phasen, und Ihre Roadmap muss sich daran ausrichten:

• Februar 2025: Verbote verbotener Praktiken und Pflichten zur KI-Kompetenz sind bereits aktiv.
• August 2025: Pflichten für GPAI-Modelle gelten.
• August 2026: der Großteil der Hochrisikopflichten gilt.
• August 2027: Hochrisikopflichten für KI, die in regulierte Produkte eingebettet ist.

Diese Staffelung ist ein Geschenk. Sie sagt Ihnen genau, wo zuerst zu investieren ist: bestätigen, dass Sie keine verbotenen Systeme haben (existenziell), dann Ihre GPAI-Abhängigkeiten inventarisieren, dann den Hochrisiko-Konformitätsstack vor der Deadline 2026 aufbauen. Ein CDO, der das Audit verbotener Systeme nach vorne zieht und den Aufbau der Hochrisikodokumentation nach hinten legt, sequenziert intelligent. Wer versucht, im ersten Quartal das Meer auszuschöpfen, verbrennt Glaubwürdigkeit.

Wo das Urteilsvermögen wirklich gefordert ist

Der Rechtsakt gibt Ihnen Stufen; er gibt Ihnen keine Sicherheit an den Grenzen. Die echten Ermessensentscheidungen des CDO sind:

• Grenzfall hohes Risiko: ein HR-Tool, das Interviewfragen „vorschlägt", beeinflusst es eine Beschäftigungsentscheidung „maßgeblich"? Im Zweifel behandeln Sie es vorläufig als hochriskant und lassen Legal dagegen argumentieren. Es ist weit billiger, zu viel zu dokumentieren und neu einzustufen, als zu wenig zu dokumentieren und unter regulatorischem Druck die Historie zu rekonstruieren.
• Substanzielle Veränderung: wenn Sie ein Vendor-Modell stark fine-tunen, können Sie zum Anbieter werden. Legen Sie mit Legal eine Schwelle fest, was „substanziell" in Ihrem Kontext bedeutet, und loggen Sie jede Änderung daran.
• Extraterritoriale Reichweite: der Rechtsakt gilt, wenn der Output Ihres Systems in der EU genutzt wird, auch wenn Ihr Hauptsitz anderswo liegt. Ein CDO in den USA kann das nicht als Problem anderer Leute behandeln.

Key Takeaways

1. Klassifizieren Sie nach Use Case, nicht nach Modell. Bauen Sie ein deterministisches Triage-Screening, das an Ihr KI-Registry gekoppelt ist und jedes System einer Stufe zuordnet, basierend darauf, wen es betrifft und welche Entscheidung es treibt, nicht auf seiner technischen Raffinesse.
2. Prüfen Sie zuerst auf verbotene Systeme, in diesem Quartal. Die Verbote sind schon in Kraft und tragen die höchsten Bußgelder. Alles andere ist ein Planungsproblem; das hier ist ein existenzielles.
3. Kennzeichnen Sie für jedes System Anbieter vs. Betreiber. Pflichten und Haftung gehen stark auseinander, und die meisten Unternehmen sind beides gleichzeitig. Bringen Sie das jetzt ins Registry.
4. Passen Sie die Kontrollintensität an die Risikostufe an und verteidigen Sie die 90 % mit minimalem Risiko gegen Über-Governance. Proportionalität ist das Betriebsprinzip des Rechtsakts; sie nach unten zu verletzen ist illegal, sie nach oben zu verletzen macht Sie nur langsam.
5. Verdrahten Sie ein hartes Gate vor dem Deployment für Hochrisikosysteme in Ihre Release-Pipeline, bevor die Deadline August 2026 kommt, und planen Sie Logging und Dokumentation von Anfang an ein, sie nachträglich in laufende Modelle einzubauen ist der teuerste Weg.