EU AI Act: Artikel-50-Checkliste für SaaS und KI-Agenten

Artikel 50 des EU AI Act gilt ab dem 2. August 2026. Wenn dein Produkt einen Chatbot, einen KI-Agenten oder irgendein Feature einsetzt, das Text, Bilder, Audio oder Video generiert, schuldest du deinen Nutzern eine Offenlegung und dem Output eine maschinenlesbare KI-Kennzeichnung. Das ist eine Engineering-Aufgabe, kein Policy-Memo. Die Kommission hat ihre finalen Leitlinien am 20. Juli 2026 veröffentlicht, zehn Tage vor der Frist. Das meiste, was du online findest, ist eine juristische Zusammenfassung dieser Leitlinien. Das hier ist stattdessen die Build-Checkliste: was in die UI gehört, was in die Output-Pipeline geschrieben wird, was geloggt wird und welche Nachweise du aufbewahren musst.

Zwei Dinge unterscheiden Artikel 50 vom Rest des AI Act. Er greift bei Systemen mit begrenztem Risiko, ein simpler SaaS-Chatbot fällt also in den Anwendungsbereich, obwohl er meilenweit von "hohem Risiko" entfernt ist. Und die meiste Arbeit landet bei Produkt- und Engineering-Teams, nicht bei der Rechtsabteilung. Irgendwer muss den Hinweis einbauen, den Output kennzeichnen, den Deepfake labeln und den Nachweis aufbewahren. Wenn du noch am Budget für das größere Programm sitzt, lies unsere Kostenaufstellung zum EU AI Act für ein kleines Startup und, für die Überschneidung mit dem Datenschutz, wie sich DSGVO und AI Act für DACH-SaaS stapeln. Dieser Beitrag bleibt bei Artikel 50 und bleibt bei der Umsetzung.

Ein Vorbehalt vorweg: Das ist praktische Anleitung aus einem Build-Team, keine Rechtsberatung. Die Pflichten unten sind unsere Lesart der Verordnung und der Leitlinien vom Juli 2026. Lass den Anwendungsbereich für dein konkretes Produkt von einem Juristen bestätigen, bevor du dich darauf verlässt.

Die zwei Daten, die dich wirklich binden

Es gibt eine Frist, die alle zitieren, und ein Übergangsfenster, das die meisten übersehen. Wenn du das zweite falsch verstehst, nimmst du an, du hättest vier Monate mehr, die du nicht hast.

Lies die zweite Zeile genau. Das Dezember-Fenster gilt für eine einzige Pflicht (maschinenlesbare Kennzeichnung nach Artikel 50(2)) und nur für Systeme, die vor August auf den Markt gebracht wurden. Es verschiebt weder die Chatbot-Offenlegung noch das Deepfake-Labeling noch irgendetwas, das ein Betreiber tut. Wenn du im September ein neues generatives Feature startest, kennzeichnest du ab dem ersten Tag. Bei der Durchsetzung drohen Bußgelder von bis zu 15 Mio. EUR oder 3 Prozent des gesamten weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

Schritt 1: Inventarisiere, welche Features in den Anwendungsbereich fallen

Artikel 50 hat vier Unterpflichten, die jeweils auf einen anderen Akteur zeigen. Ordne jeden KI-Berührungspunkt in deinem Produkt einer Zeile zu, bevor du irgendetwas baust. Die meisten SaaS-Unternehmen stellen fest, dass sie sowohl Anbieter (für den eigenen Chatbot) als auch Betreiber (für ein Marketingvideo, das mit einem Drittanbieter-Tool erstellt wurde) sind.

Halte außerdem pro Feature fest, ob das System vor oder nach dem 2. August 2026 auf den Markt gebracht wurde. Dieses eine Flag entscheidet, ob das Dezember-Übergangsfenster für deine Kennzeichnungsarbeit gilt. Bewahre dieses Inventar auf. Es ist das Erste, wonach eine Behörde oder ein Enterprise-Käufer fragen wird, und es dient gleichzeitig als Checkliste, gegen die du baust. Wenn dir der Enterprise-Einkauf schon Fragebögen schickt, deckt unser Leitfaden zum KI-Sicherheitsfragebogen für Anbieter ab, wo Transparenzfragen inzwischen auftauchen.

Schritt 2: Offenlegung bei Chatbots und KI-Agenten (Artikel 50(1))

Die Regel ist einfach: Eine Person muss spätestens bei der ersten Interaktion darüber informiert werden, dass sie mit einer KI interagiert. Die Fehlerquellen liegen alle in der Umsetzung.

Bau es in den Flow ein, nicht in den Footer. Die Leitlinien lehnen ausdrücklich eine Offenlegung ab, die in den AGB vergraben ist, eine Zeile technischer Metadaten ohne sichtbaren Hinweis oder ein vages Label wie "Assistent" oder "powered by LLMs". Die Person muss im Moment des Kontakts verstehen, dass das Gegenüber eine Maschine ist.

Eine Offenlegung, die durchgeht, sieht so aus:

• Text-Chat: eine Zeile in Klartext vor oder mit der ersten Nachricht, zum Beispiel "Du chattest mit einem KI-Assistenten." Halte sie sichtbar, nicht als Tooltip.
• Voice-Agent: eine hörbare Ansage zu Beginn des Gesprächs, dass der Anrufer mit einer KI spricht. Ein rein visueller Hinweis funktioniert für einen Sprachkanal nicht.
• Autonomer Agent: Wenn dein Agent im Auftrag eines Nutzers handelt und andere Menschen oder Systeme kontaktiert, muss er in jeder solchen Situation seine KI-Natur offenlegen, weil du nicht zuverlässig vorhersagen kannst, wer am anderen Ende ist.
• Persistenter Hinweis: Halte während der gesamten Session einen sichtbaren Indikator vor, nicht nur zu Beginn, besonders bei Kindern oder schutzbedürftigen Zielgruppen, bei denen die Leitlinien besondere Sorgfalt verlangen.

Die einzige Ausnahme ist der "offensichtliche" Fall: Eine Offenlegung ist nicht erforderlich, wenn es für ein angemessen informiertes, aufmerksames und verständiges Mitglied der Zielgruppe ohnehin offensichtlich ist, dass es mit einer Maschine spricht. Behandle das eng. Wenn du dich darauf berufst, schreib auf, warum, denn du trägst die Beweislast dafür, dass es offensichtlich war. Verlass dich nicht darauf bei einem Support-Widget, das einen menschlichen Mitarbeiter imitiert.

"Artikel 50 ist kein juristisches Dokument, das du abheftest. Es ist ein Diff in deinem Produkt: eine Zeile im Chat-Header, eine Funktion in der Output-Pipeline, eine Spalte in deinen Logs. Teams, die es als Papierkram behandeln, liefern den Papierkram und fallen beim Audit an der UI durch."

Schritt 3: Maschinenlesbare Kennzeichnung von generiertem Output (Artikel 50(2))

Wenn dein System synthetisches Audio, Bilder, Video oder Text generiert, muss der Output in einem maschinenlesbaren Format gekennzeichnet und als künstlich generiert erkennbar sein. Das ist der schwierigste Engineering-Punkt auf der Liste, weil die Leitlinien das Ziel vorgeben, ohne eine einzelne Technik vorzuschreiben. Die Kennzeichnung muss, in den Worten der Verordnung, "wirksam, interoperabel, robust und zuverlässig sein, soweit dies technisch machbar ist".

Was das in der Praxis bedeutet, nach Modalität:

• Bilder und Video: Hänge Provenienz-Metadaten mit dem C2PA-Standard an, der ein Manifest kryptografisch signiert, das beschreibt, wie der Inhalt erzeugt wurde. Kombiniere das mit einem eingebetteten Wasserzeichen als Fallback, denn Metadaten sind weg, sobald eine Datei neu kodiert oder gescreenshottet wird.
• Audio: Bette ein unhörbares Wasserzeichen ein und, wo das Format es erlaubt, signierte Metadaten.
• Text: Die ehrliche Antwort ist, dass robustes Text-Wasserzeichnen kein gelöstes Problem ist. Statistische Wasserzeichen zerfallen unter Paraphrasierung und leichter Bearbeitung. Wo du nicht zuverlässig kennzeichnen kannst, dokumentiere die Einschränkung, wende Metadaten auf API- und Datei-Ebene an und stütz dich stattdessen auf die sichtbaren Offenlegungspflichten.

Entferne bestehende Kennzeichnungen nicht. Wenn KI-Inhalte als Input in deine Pipeline zurückfließen, bewahre alle bereits angehängten Provenienzdaten. Kennzeichnungen zu entfernen oder AGB zu schreiben, die dir das Entfernen erlauben, arbeitet gegen die Pflicht.

Die Ausnahmen sind hier eng. Unterstützende Bearbeitung, die den Input nicht wesentlich verändert (Grammatik- und Rechtschreibkorrektur), fällt aus dem Anwendungsbereich, ebenso Inhalte, die nicht wesentlich verändert werden, und Systeme, die per Gesetz zur Aufdeckung von Straftaten autorisiert sind. Ein Feature, das einen Absatz oder ein Bild generiert, ist keine unterstützende Bearbeitung.

Die Kennzeichnung ist die Pflicht, die am ehesten für das Übergangsfenster im Dezember 2026 in Frage kommt, aber nur, wenn das System vor August auf dem Markt war. Neue Features kennzeichnen ab dem Start.

Schritt 4: Deepfake- und Synthetic-Media-Labels (Artikel 50(4))

Wenn du KI-generierte oder manipulierte Bild-, Audio- oder Videoinhalte veröffentlichst, die realen Personen, Objekten oder Ereignissen ähneln und authentisch wirken würden, musst du (als Betreiber) klar offenlegen, dass sie künstlich sind. Das ist breiter, als die meisten Teams erwarten.

• Eine realistische synthetische Darstellung einer fiktiven, aber natürlich wirkenden Person ist trotzdem ein Deepfake. Es muss keine reale, identifizierbare Einzelperson geben.
• Das Label muss für die gesamte Zielgruppe klar sein, einschließlich Kindern, älteren Menschen und Zuschauern mit geringerer KI-Kompetenz, nicht nur für die primäre Zielgruppe.
• Eindeutig fantastische oder physikalisch unmögliche Inhalte (Drachen, Menschen, die ohne Hilfsmittel fliegen) fallen aus der Definition.
• Kreative, künstlerische, satirische oder fiktionale Werke werden lockerer behandelt: Die Offenlegung beschränkt sich darauf, das Vorhandensein des generierten Inhalts so anzuzeigen, dass das Werk nicht verdorben wird.

Praktische Label-Muster nach Modalität: ein persistentes sichtbares Label auf Bildern, ein Eröffnungshinweis oder eine Einblendung im Video und eine hörbare Ansage bei Audio. Der Betreiber bleibt verantwortlich, selbst wenn das vorgelagerte Tool bereits eine maschinenlesbare Kennzeichnung angebracht hat. Ein verstecktes Wasserzeichen ist kein Ersatz für ein Label, das die Zielgruppe wahrnehmen kann.

Schritt 5: KI-generierter Text zu Themen von öffentlichem Interesse (Artikel 50(4))

Wenn du KI-generierten oder KI-bearbeiteten Text veröffentlichst, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren, lege offen, dass er künstlich generiert ist. Das zielt auf Publishing im Newsroom-Stil, nicht auf deine internen Dokumente oder Marketing-Microcopy.

Die redaktionelle Ausnahme ist real, aber eng. Beide Bedingungen müssen gleichzeitig erfüllt sein:

1. Eine Person mit einschlägiger Expertise hat den Text speziell auf seinen Inhalt hin geprüft. Reine Rechtschreib- oder Grammatikkorrektur zählt nicht.
2. Eine identifizierbare Person oder Organisation trägt die redaktionelle Verantwortung, mit öffentlich zugänglichem Namen und Kontaktdaten.

Wenn ein menschlicher Redakteur den Beitrag tatsächlich verantwortet, entfällt die Offenlegungspflicht, aber halte den redaktionellen Papierweg fest. Dieser Nachweis ist dein Beleg.

Schritt 6: Hinweise zu Emotionserkennung und Biometrie (Artikel 50(3))

Wenn du ein System betreibst, das Emotionen erkennt oder Menschen anhand biometrischer Daten kategorisiert, informiere die betroffene Person bei oder vor der ersten Exposition, in klarer und zugänglicher Form. Das ist getrennt von den Verboten aus Artikel 5 in Arbeitsplätzen und Schulen; Artikel 50(3) gilt für die Einsatzbereiche, die weiterhin erlaubt sind. Wenn dein Produkt keine Emotions- oder Biometriedaten berührt, halte das im Inventar fest und geh weiter.

Schritt 7: Logging und Aufbewahrung von Nachweisen

Die Leitlinien machen Compliance zu einer Beweisübung. Compliant zu sein reicht nicht; du musst es belegen können, wenn eine Behörde oder ein Kunde fragt. Bau den Nachweis auf, während du das Feature baust.

Zwei harte Regeln für die Pipeline: Entferne nie Provenienz-Kennzeichnungen, wenn du KI-Inhalte als Input wiederverwendest, und schreib nie AGB, die das Entfernen erlauben. Behandle Provenienzdaten als append-only.

Was durchgeht und was durchfällt

Das mit Abstand Nützlichste in den Leitlinien vom Juli ist die Grenze zwischen ausreichender und unzureichender Offenlegung. Nutze sie als Akzeptanztest im Code-Review.

Die Realitätslücke beim Wasserzeichnen

Sei ehrlich mit dir selbst bei Artikel 50(2). Die Verordnung verlangt eine Kennzeichnung, die robust und zuverlässig ist, und die Technik ist noch nicht so weit, was die Kommission mit der Formulierung "soweit technisch machbar" anerkennt. C2PA-Metadaten sind stark, aber spröde: Ein Screenshot, eine Neukodierung oder eine Plattform, die Metadaten entfernt, löscht sie. Wasserzeichen überleben besser, können aber durch Zuschneiden, Kompression oder adversariale Bearbeitung geschwächt werden. Text-Wasserzeichen überleben kaum eine Paraphrasierung.

Die konforme Haltung besteht nicht darin, auf perfekte Technik zu warten. Sie besteht darin, die beste verfügbare Methode pro Modalität anzuwenden, Metadaten und Wasserzeichen zu schichten, sodass eines das Versagen des anderen abdeckt, zu dokumentieren, was du getan hast und wo es bricht, und das Ganze mit sichtbarer Offenlegung zu untermauern. Ein Team, das einen begründeten, geschichteten Ansatz vorweisen kann, steht deutlich stärker da als eines, das nichts geliefert hat, während es auf einen Standard wartete.

Solltest du den Code of Practice unterzeichnen?

Das AI Office hat einen freiwilligen Code of Practice zur Kennzeichnung und Labeling von KI-generierten Inhalten veröffentlicht. Die Einhaltung eines als angemessen eingestuften Codes kann ein Weg sein, die Konformität mit Artikel 50(2), (4) und (5) nachzuweisen. Nicht-Unterzeichner können weiterhin auf anderen Wegen konform sein, aber die Leitlinien deuten an, dass sie eine schwerere Beweislast tragen könnten.

Für einen Anbieter generativer KI ist die Unterzeichnung ernsthaft erwägenswert: Sie gibt dir eine verteidigbare Vorlage und ein Safe-Harbour-Signal. Für einen reinen Betreiber, dessen einzige Berührung ein Chatbot-Hinweis und das gelegentliche gelabelte Video ist, bringt der Code weniger, und dein Aufwand ist bei den Offenlegungen selbst besser aufgehoben. Entscheide danach, ob du Inhalte im großen Stil generierst oder sie bloß einsetzt.

Quellen und Methodik

Diese Checkliste ist Wavects Engineering-Lesart von Artikel 50 der Verordnung (EU) 2024/1689 und der finalen Leitlinien der Europäischen Kommission zu den Transparenzpflichten, angenommen am 20. Juli 2026. Pflichten, Daten und Ausnahmen wurden am 23. Juli 2026 gegen die Leitlinien der Kommission und den konsolidierten Text von Artikel 50 geprüft. Die Beispiele für Bestehen und Durchfallen spiegeln die in diesen Leitlinien festgelegten Tests zur Angemessenheit der Offenlegung wider. Das ist Umsetzungsanleitung, keine Rechtsberatung.