Drei Dinge für die zweite Jahreshälfte 2025
1. Mapp deinen Stack gegen Annex III, bevor du etwas anderes machst
Annex III ist die Liste, die definiert, was als hochrisiko zählt. Sie umfasst acht Bereiche: Beschäftigung und Personalmanagement, Zugang zu Krediten, Bildung, grundlegende private und öffentliche Dienstleistungen, Strafverfolgung, Migration und Grenzüberwachung, Justiz und kritische Infrastruktur.
Dein erstes Ziel ist nicht, den vollständigen Act zu lesen. Es ist, dich hinzusetzen mit jemandem, der deine KI-Systeme betreut, und gemeinsam die Liste durchzugehen. Seid spezifisch. "Wir nutzen ein KI-gestütztes ATS" reicht nicht aus. Welche Entscheidungen beeinflusst es? Bewertet, scored oder filtert es Kandidaten, ohne dass ein Mensch die zugrunde liegende Logik überprüft? Diese Frage zählt.
Bei niederländischen KMU sind die häufigsten Risikopunkte Personaltools (ATS-Plattformen, Performance-Scoring), Credit- oder Versicherungs-Flows und Kundensegmentierung in Finanzprodukten. Fangt dort an. Eine einseitige Bestandsaufnahme, die jedes System den Annex-III-Kategorien zuordnet, ist ein sinnvoller Output. Es muss kein rechtliches Dokument sein. Es muss korrekt sein.
Die Tückefalle hier sind Third-Party-Tools. Wenn du ein vorkonfiguriertes SaaS-Produkt nutzt, das das Scoring oder Ranking übernimmt, unterliegt auch du dem Regelwerk als Anwender. Die Compliance des Anbieters wird nicht automatisch zu deiner.
2. Konformitätsbewertung, technische Dokumentation und CE-Kennzeichnung für hochrisiko-Systeme
Sobald du weißt, welche Systeme zum Anwendungsbereich gehören, verlangt das Gesetz drei konkrete Dinge vor der Inbetriebnahme:
Konformitätsbewertung. Für die meisten hochrisiko-Systeme außerhalb weniger kritischer Sektoren kannst du selbst bewerten. Das bedeutet, einen strukturierten Prozess zu durchlaufen, um sicherzustellen, dass dein System die Anforderungen des Gesetzes in Bezug auf Transparenz, Datenverwaltung, Genauigkeit und menschliche Überwachung erfüllt. Es ist keine Abhakübung. Es braucht Zeit und interne Abstimmung.
Technische Dokumentation. Das Gesetz legt fest, was diese enthalten muss: der beabsichtigte Zweck des Systems, seine Leistungskennzahlen, die verwendeten Trainingsdaten, bekannte Einschränkungen und wie die menschliche Überwachung umgesetzt wird. Diese Dokumentation muss gepflegt und aktuell gehalten werden. Wenn dein System sich ändert, ändert sich die Dokumentation.
CE-Kennzeichnung. Hochrisiko-KI-Systeme, die auf dem EU-Markt eingeführt werden, benötigen CE-Kennzeichnung, um die Konformität zu bestätigen. Für selbst bewertete Systeme erstellst du eine Konformitätserklärung und bringst die Kennzeichnung an. Für Systeme in bestimmten sensiblen Kategorien muss eine benannte Stelle beteiligt sein.
Die Tückefalle. Dokumentation, die im Nachhinein, kurz vor einer Überprüfung, geschrieben wird, ist für jeden Prüfer offensichtlich und schwach in jedem Streitfall. Schreib sie während du baust oder konfigurierst, nicht danach.
3. Ernennen eine Governance-Rolle, nicht ein Compliance-Formular
Das ist der Punkt, wo die meisten Unternehmen schiefgehen. Sie erstellen ein Richtliniendokument, legen es irgendwo ab und nennen es Governance. Das ist keine Governance. Das ist Papierkram.
Das EU-Gesetz über Künstliche Intelligenz erwartet fortlaufende menschliche Überwachung hochrisiko-Systeme. Das bedeutet, jemand in deiner Organisation trägt eine benannte Verantwortung, um Systemverhalten zu überwachen, Entscheidungen zu überprüfen, die Einzelne betreffen, Anomalien zu kennzeichnen und zu eskalieren, wenn etwas schiefläuft. Für ein großes Unternehmen könnte das ein dedizierter KI-Officer sein. Für ein niederländisches KMU oder kleines Product Team ist es eher eine bestehende Rolle mit definierter Scope-Erweiterung.
Was zählt ist, dass die Verantwortung real ist, die Person weiß, dass sie sie trägt, und es gibt einen Prozess für den Fall, dass etwas schiefgeht. Ein Formular macht das nicht. Eine Person mit Mandat tut es.
Die Tückefalle. Mach das nicht zu einer reinen Rechts- oder Compliance-Funktion. Die Person, die versteht, wie sich das System verhält, muss eingebunden sein. Das ist oft ein Product Manager oder ein Data Lead, nicht ein Anwalt.
