Stand 11. August 2026. Artikel 50 des EU AI Act (Transparenz für bestimmte Systeme, die mit Personen interagieren, synthetische Inhalte generieren, Emotionserkennung oder biometrische Kategorisierung betreiben oder Deepfakes veröffentlichen) gilt ab dem 2. August 2026. Die Europäische Kommission hat mit der Durchsetzung dieser Transparenzanforderungen begonnen. Dies ist geltendes Recht für Anwendungscode, kein zukünftiger Stichtag.
Der Großteil der Hochrisiko-Anforderungen aus Kapitel III (Artikel 8 bis 15: Risikomanagement, Datenverantwortung, technische Dokumentation, Aufzeichnungspflichten, Anweisungen für Anwender, menschliche Aufsicht sowie Genauigkeit, Robustheit und Cybersicherheit) trat nicht zum ursprünglichen Termin am 2. August 2026 in Kraft. Die Verordnung (EU) 2026/1744, das Digital Omnibus zur KI, wurde am 24. Juli 2026 im Amtsblatt veröffentlicht und trat am 27. Juli 2026 in Kraft. Sie verschiebt die Anwendung dieser Hochrisiko-Pflichten auf den 2. Dezember 2027 für Systeme, die nach Artikel 6(2) und Anhang III als Hochrisiko eingestuft werden (selbstständige Systeme wie Beschäftigung, wesentliche Dienstleistungen und Strafverfolgungsinstrumente), und auf den 2. August 2028 für Systeme nach Artikel 6(1) und Anhang I (in andere Produkte eingebettete KI, z. B. Medizinprodukte oder Maschinen). Pläne, die August 2026 weiterhin als Stichtag für die Hochrisiko-Compliance betrachten, basieren auf einem Termin, der bereits verschoben wurde.
Dieser Leitfaden richtet sich an Entwickler. Er klassifiziert Ihr Produkt nicht als Hochrisiko, führt keine Konformitätsbewertung durch und ersetzt keine Rechtsberatung. Er benennt den Zeitplan, die Artikel-50-Pflichten, die nun als UI-Text und Metadaten in einem Diff auftauchen, und zeigt, wie eine Compliance-Prüfung eines Pull Requests das häufige Problem erkennt: Eine Bereinigung, die die Offenlegung entfernt.
Was jetzt gilt (Artikel 50)
Artikel 50 legt vier Hauptkategorien von Transparenzpflichten fest, aufgeteilt zwischen Anbietern (die Organisation, die das System entwickelt) und Anwendern (die Organisation, die es einsetzt), vorbehaltlich Ausnahmen, einschließlich bestimmter Strafverfolgungszwecke. Diese Pflichten tauchen häufig im laufenden Code auf, nicht nur in Dokumenten. Art. 50(1): Ein System, das ein Anbieter so gestaltet, dass es direkt mit einer Person interagiert, muss dieser Person mitteilen, dass sie mit einer KI spricht, es sei denn, dies wäre für eine vernünftig gut informierte Person offensichtlich. Ein Chat-Widget, ein Sprachassistent oder ein Support-Bot benötigt eine Offenlegung, die tatsächlich wahrgenommen wird. Art. 50(2): Ein Anbieter, dessen System synthetische Audio-, Bild-, Video- oder Textinhalte generiert, muss diese Ausgabe in einem maschinell lesbaren Format als KI-generiert kennzeichnen. Für Systeme, die bereits vor dem 2. August 2026 auf dem Markt waren, wird die maschinell lesbare Kennzeichnung nach Art. 50(2) häufig mit einer Übergangsregelung bis zum 2. Dezember 2026 beschrieben. Überprüfen Sie den genauen Übergangstext im Omnibus und in den Leitlinien der Kommission für Ihre Produktlinie, da andere Artikel-50-Pflichten diese Frist nicht teilen. Art. 50(3): Ein Anwender, der Emotionserkennung oder biometrische Kategorisierung an Personen durchführt, muss diesen Personen mitteilen, dass dies geschieht. Art. 50(4): Ein Anwender, der ein Deepfake veröffentlicht, muss weiterhin offenlegen, dass es künstlich generiert oder manipuliert wurde. Bei Inhalten, die Teil eines offensichtlich künstlerischen, kreativen, satirischen, fiktionalen oder ähnlichen Werks sind, beschränkt sich die Offenlegungspflicht darauf, dass sie in einer Weise erfolgt, die die Darstellung oder den Genuss des Werks nicht beeinträchtigt, anstatt erlassen zu werden. Separate Regelung: KI-generierte oder manipulierte Texte, die zur Information der Öffentlichkeit über ein Thema von öffentlichem Interesse veröffentlicht werden, benötigen dieselbe Offenlegung, es sei denn, der Inhalt wurde einer menschlichen Prüfung oder redaktionellen Kontrolle unterzogen und eine Person oder Organisation trägt die redaktionelle Verantwortung für die Veröffentlichung.
Jede dieser Pflichten wird häufig als UI-Element, Metadaten-Eintrag oder Textbaustein umgesetzt, was bedeutet, dass sie genau die Art von Dingen sind, die bei einem Refactoring entfernt werden können, ohne dass jemand dies als Compliance-Änderung markiert. Ab August 2026 ist eine solche Entfernung keine "vorzeitige" Maßnahme mehr, sondern eine tatsächliche Transparenzlücke.
Praktisches Beispiel: Eine UI-Bereinigung entfernt die Offenlegung
Angenommen, ein Support-Chatbot wurde mit einer dauerhaften Zeile unter seiner ersten Nachricht ausgeliefert: "Sie chatten mit einem KI-Assistenten." Ein späterer Pull Request gestaltet das Widget für einen saubereren Erstzustand um und entfernt diese Zeile zusammen mit drei anderen Einleitungstexten, da ein Designer diese als überflüssige Onboarding-Elemente markiert hat. Das Redesign ist an sich nicht falsch: Das Widget wirkt aufgeräumter, und die anderen drei Zeilen waren tatsächlich Fülltext. Da die Offenlegung nach Art. 50(1) jedoch als eine dieser Zeilen umgesetzt war, wurde mit der Entfernung auch die Offenlegungspflicht entfernt, nicht nur der überflüssige Text. Am Diff selbst ist nichts Ungewöhnliches zu erkennen: Eine Textkürzung in einer Chat-Komponente ist nicht die Art von Änderung, die ein Bug-Scanner, ein QA-Test oder eine Designprüfung standardmäßig erkennt.
Genau das prüft eine Compliance-Überprüfung in einem Diff: Wenn eine Änderung ein Element entfernt oder schwächt, das mit einer Kontrolle verknüpft ist, die ein Team verfolgt, wird Art. 50(1) direkt im Pull Request zitiert, anstatt dies erst durch eine Beschwerde oder eine Durchsetzungskontaktaufnahme nachträglich zu erfahren.
Hochrisiko ist verschoben, nicht abgesagt
Die Verschiebung der Hochrisiko-Anforderungen für eigenständige Systeme aus Anhang III auf Dezember 2027 macht die grundsätzliche Frage, ob ein System nach Anhang III als Hochrisiko eingestuft wird, nicht einfacher, als sie jetzt ist. Die Kontrollen hinter den Artikeln 8 bis 15 sind vom selben Typ "Änderungen in einem Diff": eine Risikominderung, die geschwächt wurde, eine Datenverantwortungsprüfung, die entfernt wurde, oder eine menschliche Übersteuerung, die als toter Code gelöscht wurde. Diese Gewohnheiten jetzt aufzubauen, ist günstiger, als Lücken unter dem Druck eines 2027er Zeitplans zu entdecken.
Zwei weitere Termincluster bleiben von diesem Omnibus unberührt und gelten bereits: die Verbote und KI-Alphabetisierungsverpflichtungen ab dem 2. Februar 2025 sowie die Regeln für GPAI-Modelle und Governance-Verpflichtungen ab dem 2. August 2025. Eine weitere wichtige Änderung aus demselben Paket: Ein neues Verbot für Anbieter von Systemen, die dazu bestimmt sind, nicht einvernehmliche intime Inhalte oder Material zur sexuellen Ausbeutung von Kindern zu generieren oder zu manipulieren, oder für Systeme, bei denen ein solcher Output ein vernünftigerweise vorhersehbarer und reproduzierbarer Ergebnis ohne erhebliche technische Änderungen und ohne angemessene und ausreichende Schutzmaßnahmen dagegen ist, sowie für Anwender, die ein solches System zu diesem Zweck nutzen. Dieses Verbot wurde der Liste der verbotenen Praktiken des AI Act hinzugefügt und gilt ab dem 2. Dezember 2026.
Die Rolle von heygrc und die Ehrlichkeitsgrenze
heygrc ist darauf ausgelegt, jeden Pull Request gegen die von Ihnen ausgewählten Frameworks zu prüfen, einschließlich des EU AI Act, wenn dieser aktiviert ist, und den Artikel zu benennen, den eine Änderung möglicherweise betrifft (z. B. Art. 50(1) bei einer entfernten Chat-Offenlegung). Das Ergebnis ist ein Review-Kommentar mit dem verknüpften Artikel, damit Autor und Prüfer mit allen Informationen entscheiden können. Es zertifiziert keine AI Act-Compliance, klassifiziert keinen Hochrisiko-Status, führt keine Konformitätsbewertung durch, reicht keine Aufsichtsbenachrichtigungen ein und ersetzt keine Rechtsberatung. Ein grünes heygrc-Review ist keine Bestätigung durch die Kommission, sondern ein früheres, artikelbasiertes Signal, dass eine Änderung etwas betrifft, das diese Programme wichtig finden.
Wenn Ihr Team bereits einen Bug- oder Qualitätsprüfer für denselben Pull Request verwendet, behalten Sie diesen bei. Diese Tools prüfen, ob der Code korrekt und sicher ist. Artikel-50-Fragen betreffen, ob eine Person immer noch weiß, dass sie mit einer KI spricht, oder ob synthetische Inhalte weiterhin gekennzeichnet sind. Die oben beschriebene Bereinigung kann sauber, typisiert und gut getestet sein und trotzdem Art. 50(1) nicht erfüllen. Führen Sie beide Ebenen durch, da keine die andere ersetzt.