Das EU-KI-Gesetz und dein Produktstack 2026

Am 2. August 2026 bekommt das EU-Gesetz über Künstliche Intelligenz Zähne. Das ist der Termin, an dem Verpflichtungen für hochrisiko-KI-Systeme in der gesamten EU durchsetzbar werden. Bei den meisten niederländischen Gründern und Product Teams lautet die Antwort bislang: "Kümmern wir uns später drum."

Später ist jetzt sechs Monate entfernt.

Das Unangenehme ist nicht die Frist selbst. Es ist, dass eine beachtliche Anzahl von Unternehmen, die KI für HR-Screening, Kreditvergabe oder Kundensegmentierung nutzen, nicht realisiert, dass diese Systeme unter Annex III als hochrisiko eingestuft werden. Sie gehen davon aus, hochrisiko bedeutet Roboter bei Operationen oder autonome Fahrzeuge. Das tut es nicht. Es bedeutet dein Recruiting-Tool, das CVs bewertet. Es bedeutet der Credit-Flow in deinem Fintech-Stack, der Anträge genehmigt oder ablehnt. Es bedeutet das Scoring-Modell, das Kunden für Angebote klassifiziert.

Wenn du eines dieser Systeme betreibst oder für Kunden entwickelst, gelten die Verpflichtungen auch für dich.

Was das Digital Omnibus ändert und was nicht

Es gibt eine gesetzliche Bestimmung, die du kennen solltest. Der Digital Omnibus Vorschlag, der derzeit durch die EU-Verfahren läuft, enthält Bestimmungen, die bestimmte KI-Act-Verpflichtungen verzögern oder abschwächen könnten. Einige Product Teams verlassen sich darauf. Das ist ein Fehler.

Selbst wenn das Digital Omnibus in einer Form verabschiedet wird, die die Zeitpläne verschiebt, kommt es nicht rechtzeitig an, um es mit Sicherheit zu planen. Der parlamentarische Zeitplan ist wirklich unsicher. Deine Compliance-Strategie auf einen legislativen Ausgang zu setzen, der noch nicht entschieden ist, ist keine Strategie. Es ist ein Aufschub, der sich als einer verkleidet.

Plan für 2. August 2026 als festes Datum. Wenn das Omnibus dir später zusätzliche Zeit gibt, wird das zum Bonus. Wenn es das nicht tut, bist du vorbereitet.

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.

Praktische Checkliste für die nächsten 90 Tage

Das ist kein vollständiges Compliance-Programm. Es ist der minimal sinnvolle Startpunkt für einen Gründer oder Product Lead, der vorankommen muss, ohne ein Heer von Beratern einzustellen.

• Annex-III-Audit. Listet jedes KI-System auf, das ihr betreibt oder einsetzt. Ordnet jedes einem der acht Annex-III-Bereiche zu. Kennzeichnet alles, das als hochrisiko qualifizieren könnte.
• Anwender vs. Anbieter Klarheit. Stellt für jedes Tool fest, ob ihr der Anbieter seid (ihr habt es gebaut oder trainiert) oder der Anwender (ihr nutzt das System von jemand anderem). Eure Verpflichtungen unterscheiden sich.
• Datenverwaltungs-Check. Hochrisiko-Systeme erfordern dokumentierte Datenverwaltung. Für jedes betroffene System: Könnt ihr beschreiben, welche Daten verwendet wurden, woher sie kamen und wie Bias bewertet wurde? Falls nicht, fangt diese Unterhaltung mit eurem Anbieter oder Data Team an.
• Menschliche Überwachung Design. Für jedes hochrisiko-System schreib einen Absatz, der beschreibt, wie ein Mensch eingreifen, das System überschreiben oder anhalten kann. Wenn du das nicht schreiben kannst, ist die Überwachung nicht real.
• Governance-Verantwortlicher. Nennt die Person. Schreibt es auf. Sagt ihr Bescheid.
• Dokumentations-Startdatum. Setzt ein Datum in den nächsten zwei Wochen fest und fangt mit der technischen Dokumentation für euer höchstrisiko-System an. Wartet nicht, bis es sich komplett anfühlt.

Keines davon erfordert einen Rechtsanwaltsvertrag am ersten Tag. Es erfordert etwa zwei fokussierte Arbeitstage und die richtigen Leute im Raum.

Wo Studio Hyra ankommt

Wir sind nicht eine Anwaltskanzlei. Wir reichen deine Konformitätsbewertungen nicht ein und geben keine rechtliche Genehmigung. Das, was wir tun, ist Product und Design Teams helfen zu verstehen, welche ihrer KI-Systeme echtes Risiko tragen, die Governance um diese Systeme so zu strukturieren, dass sie operativ realistisch ist, und die Dokumentation zu erstellen, die zwischen der rechtlichen Anforderung und dem tatsächlichen Produkt sitzt.

Für niederländische KMU und kleine Product Teams ist diese Lücke oft der schwierigste Teil. Die Verordnung wurde für große Organisationen mit dedizierten Compliance-Funktionen geschrieben. Sie in etwas zu übersetzen, das ein Team von zehn tatsächlich umsetzen kann, ist eine andere Fähigkeit. Das ist, wo wir arbeiten.

Wenn du deinen Stack durchgehen möchtest und herausfinden möchtest, wo du tatsächlich stehst, dauert dieses Gespräch eine Stunde. Fangt dort an.