Art. 50 AI Act für Entwickler: KI-Agenten, Chatbots und KI-Inhalte technisch kennzeichnen

Seit dem 2. August 2026 gelten die Transparenzpflichten aus Artikel 50 der KI-Verordnung (Art. 50 AI Act). Wer einen Chatbot, einen Voice-Agenten oder eine Pipeline für KI-generierte Inhalte betreibt, muss drei Dinge im System abbilden: Menschen erfahren, dass sie mit einer KI sprechen. Synthetische Inhalte tragen eine maschinenlesbare Markierung. Veröffentlichte KI-Texte sind entweder gekennzeichnet oder nachweisbar von einem Menschen verantwortet.

Viele Texte zu Art. 50 kommen aus Kanzleien. Sie erklären die Pflichten, aber selten, wo sie in der Architektur landen. Darum geht es hier: Welche Pflicht trifft welche Rolle, an welcher Stelle im System setzt man sie um, und was ist bis zum 2. Dezember 2026 zu erledigen? An diesem Tag endet die Übergangsfrist für die maschinenlesbare Markierung bei Systemen, die schon vor dem 2. August 2026 auf dem Markt waren (Kommissions-FAQ zu Art. 50). Den breiteren Sicherheitsrahmen für Agenten beschreibt der Beitrag zur KI-Agenten Sicherheit.

Keine Rechtsberatung. Dieser Artikel beschreibt technische Umsetzungsmuster aus Engineering-Sicht. Er ersetzt keine rechtliche Prüfung des eigenen Falls. Die Rechtsaussagen stützen sich auf Veröffentlichungen der EU-Kommission und der Bundesnetzagentur (Stand Oktober 2026). Wo nur Kanzleiblogs oder andere Sekundärquellen vorliegen, steht das dabei.

Art. 50 im Überblick: Wer muss was ab wann?

Art. 50 verteilt die Pflichten auf Anbieter und Betreiber. Anbieter müssen ihre Systeme so gestalten, dass Nutzer erfahren, wenn sie direkt mit einer KI interagieren. Außerdem müssen sie „machine-readable marks“ anbringen, damit KI-generierte oder manipulierte Inhalte erkennbar sind. Die Pflichten „start to apply on 2 August 2026“, schrieb die EU-Kommission am 20. Juli 2026, als sie die finalen Leitlinien veröffentlichte.

Drei Punkte für die Projektplanung:

• Die Frist 02.12.2026 gilt nur für Abs. 2. Sie betrifft Anbieter von Systemen, die synthetische Audio-, Bild-, Video- oder Textinhalte erzeugen und vor dem 2. August 2026 in Verkehr gebracht wurden, und nur die Markierungs- und Erkennungspflicht. Alle anderen Pflichten, also auch der KI-Hinweis nach Abs. 1 und die Kennzeichnung nach Abs. 4, gelten laut Kommissions-FAQ seit dem 2. August 2026.
• Keine rückwirkende Kennzeichnung. Inhalte, die vor dem 2. August 2026 erzeugt wurden, müssen laut Kommissions-FAQ nicht nachträglich markiert werden. Rechtsgrundlage der Übergangsfrist ist Art. 111 Abs. 4 der KI-Verordnung, den der AI-Omnibus neu eingefügt hat (AI Act Service Desk der Kommission). Der AI-Omnibus ist die VO (EU) 2026/1744; laut der Kanzlei Cuatrecasas (Sekundärquelle) wurde sie am 24. Juli 2026 im Amtsblatt veröffentlicht.
• Aufsicht und Sanktionen. Seit Inkrafttreten des KI-MIG (Gesetz zur Marktüberwachung und Innovationsförderung von künstlicher Intelligenz) am 29. Juli 2026 ist die Bundesnetzagentur Marktüberwachungsbehörde, unter anderem für die Transparenzpflichten, sowie Anlauf- und Beschwerdestelle für die KI-Verordnung. In vollharmonisierten Produktbereichen bleiben die etablierten Behörden zuständig, etwa die BaFin im Finanzsektor und die Landesmedienanstalten im Medienbereich. Verstöße gegen Art. 50 können nach Art. 99 Abs. 4 mit bis zu 15 Mio. Euro oder 3 Prozent des weltweiten Jahresumsatzes geahndet werden, je nachdem, welcher Betrag höher ist. Für KMU gilt nach Abs. 6 der jeweils niedrigere Betrag.

Bin ich Anbieter oder Betreiber?

Vereinfacht gesagt: Anbieter ist, wer ein KI-System entwickelt oder entwickeln lässt und es unter eigenem Namen oder eigener Marke in Verkehr bringt oder in Betrieb nimmt, entgeltlich oder unentgeltlich. Betreiber ist, wer ein KI-System in eigener Verantwortung verwendet, außer im Rahmen einer persönlichen, nicht beruflichen Tätigkeit. Die maßgeblichen Definitionen stehen in Art. 3 Nr. 3 und 4 der Verordnung.

Die Rolle entscheidet, welche Absätze greifen: Abs. 1 und 2 richten sich an Anbieter, Abs. 3 und 4 an Betreiber. Der Code of Practice zu KI-generierten Inhalten bildet das ab. Abschnitt 1 richtet sich an Anbieter (Abs. 2, Markierung und Erkennung), Abschnitt 2 an Betreiber (Abs. 4, Deepfakes und Texte); wer beides ist, kann laut Kommission den gesamten Code unterzeichnen (Kommissions-FAQ zur Unterzeichnung).

Für Entwickler ergibt sich daraus eine unbequeme Konstellation. Wer ein Sprachmodell per API einbindet, daraus einen eigenen Chatbot baut und ihn auf der eigenen Website betreibt, sollte prüfen, ob er beide Rollen zugleich hat. Das LLM stammt von einem Dritten. Das System, mit dem Menschen sprechen, stammt aber vom Entwickler. Wie sich Rollen durch eigene Anpassungen verschieben können, beschreibt der Beitrag zum Rollenwechsel nach Art. 25.

Wie unterschiedlich die Lage schon in einem kleinen Portfolio ist, zeigen meine eigenen Projekte. Eine rechtliche Bewertung ist das nicht. Der Sprachagent Hermes ist ein persönliches Projekt, das ich selbst baue und nutze. Der Meeting-Assistent, der SEO-Agent und der Grounding Page Generator sind im beruflichen Kontext entstanden. Welche Rolle dort gilt, hängt vom jeweiligen Einsatz ab, nicht von meiner Einschätzung als Entwickler.

Wie gibt sich ein KI-Agent nach Abs. 1 als KI zu erkennen?

Aus Engineering-Sicht am verlässlichsten über einen festen Hinweis, den der Code spätestens bei der ersten Interaktion ausgibt, nicht das Modell. Nach Abs. 1 müssen Menschen erfahren, dass sie mit einer KI interagieren. Für offensichtliche Fälle gibt es eine Ausnahme. Diese Ausnahme „sollte restriktiv ausgelegt werden“, schreibt die EU-Kommission in ihrer FAQ zu Art. 50. Für die Architektur heißt das: Den Hinweis fest einbauen, statt im Einzelfall auf Offensichtlichkeit zu setzen.

Zeitpunkt und Form

Der Hinweis muss nach Art. 50 Abs. 5 klar und unterscheidbar sein und spätestens bei der ersten Interaktion oder Exposition erfolgen. Außerdem muss er die geltenden Barrierefreiheitsanforderungen erfüllen. Die Kommissions-FAQ formuliert es so, dass Menschen von Beginn der ersten Interaktion an informiert werden müssen.

Warum der Hinweis nicht in den Systemprompt gehört

Die naheliegende Lösung ist ein Satz im Systemprompt: „Stelle dich zu Beginn als KI vor.“ Das ist eine Bitte, keine Grenze. Das Modell kann den Satz auslassen, umformulieren oder nach einer präparierten Eingabe ignorieren. Prüfen lässt sich so ein Hinweis nur, indem man jedes Gespräch nachliest.

Robuster ist ein Hinweis, den der Code ausgibt, nicht das Modell. Je nach Kanal sieht das unterschiedlich aus:

• Chat und Web: fester UI-Bestandteil über dem Eingabefeld oder als erste Nachricht, die der Client rendert. Der Text kommt aus der Konfiguration, nicht aus dem LLM.
• Voice: eine fest hinterlegte Ansage, die vor dem ersten Modell-Turn abgespielt wird. Unterbricht der Anrufer die Ansage, sollte das System sie nicht stillschweigend als gehört werten.
• Agenten mit Außenkontakt (E-Mails, Tickets, Anrufe): Kennzeichnung in Absendername, Signatur oder Begrüßung, gesetzt durch das Template, nicht durch die generierte Antwort.

Ein Minimalmuster für den Sitzungsstart:

const AI_DISCLOSURE = {
  id: "ai-disclosure",
  version: "2026-10-21",
  text: "Hinweis: Sie kommunizieren mit einem KI-System.",
} as const;

async function startSession(session: Session): Promise<void> {
  // Fester Text aus der Konfiguration, nicht vom Modell erzeugt
  await session.send(AI_DISCLOSURE.text);

  await auditLog.write({
    event: "ai_disclosure_shown",
    sessionId: session.id,
    channel: session.channel,
    disclosureVersion: AI_DISCLOSURE.version,
    at: new Date().toISOString(),
  });

  // Erst danach darf das LLM antworten
  await runAgentLoop(session);
}

Ob ein solches Protokoll rechtlich verlangt ist, lässt sich aus den hier geprüften Quellen nicht ableiten. Als Nachweis ist es aber günstig: Ein Log-Eintrag pro Sitzung mit Textversion zeigt später, welcher Hinweis wann in welchem Kanal ausgespielt wurde.

Agenten ohne vorhersehbaren Menschenkontakt

Schwieriger wird es bei Agenten, die meist mit anderen Systemen arbeiten und nur manchmal auf Menschen treffen. Die Kommissions-FAQ nennt KI-Agenten ausdrücklich als Beispiel für Systeme, die direkt mit Menschen interagieren. Systeme, die ausschließlich im Hintergrund, per Machine-to-Machine-Kommunikation oder ohne direkten Kontakt mit Menschen arbeiten, fallen laut FAQ nicht unter die Pflicht. Für den Graubereich dazwischen gibt es nur Sekundärquellen: Laut artificialintelligenceact.eu hieß es im Leitlinienentwurf, ein Agent solle seinen KI-Charakter in jeder solchen Situation offenlegen, wenn nicht verlässlich vorhersehbar ist, ob er mit einem Menschen interagiert. Reed Smith fasst die finalen Leitlinien so zusammen, dass Agenten schon auf Architekturebene so zu gestalten sind, dass sie ihre KI-Natur offenlegen, wo ein direkter Kontakt mit Menschen vernünftigerweise wahrscheinlich ist. Im Wortlaut der finalen Leitlinien ist das nicht bestätigt.

Technisch heißt das: Jeder Ausgabekanal eines Agenten, der bei einem Menschen landen kann, braucht den Hinweis im Template. Das betrifft auch den E-Mail-Versand eines Agenten, der eigentlich nur Tickets sortieren soll.

Ein Beispiel für den Voice-Fall: Bei Hermes, einem Sprachagenten auf einem Handgerät, läuft jede Aufnahme zuerst über ein eigenes Voice Relay, bevor der Text ans Modell geht. Solange nur ich das Gerät nutze, ist die Frage nach dem Hinweis eher theoretisch. Würden andere Personen damit sprechen, wäre dieses Relay der richtige Ort für die feste Ansage: Es liegt vor dem ersten Modell-Turn, und die Ansage hängt nicht davon ab, was das Modell antwortet.

Nicht jeder Meeting-Assistent interagiert direkt mit Menschen. Der Meeting-Assistent aus meinen Projekten verarbeitet Besprechungsmitschriften mit einem LLM und verteilt die Action Items anschließend in Slack und per Mail. Er spricht nicht selbst im Meeting. Ob Empfänger trotzdem erkennen sollten, dass ein Modell die Zusammenfassung erstellt hat, ist eine Abwägung. Ein fester Absender oder ein Satz im Nachrichtentemplate kostet wenig.

Was verlangt Abs. 2 bei der maschinenlesbaren Markierung?

Anbieter müssen „machine-readable marks“ anbringen, damit KI-generierte oder manipulierte Inhalte erkennbar sind (EU-Kommission, 20.07.2026). Die technischen Lösungen müssen nach Art. 50 Abs. 2, soweit technisch möglich, wirksam, interoperabel, belastbar und zuverlässig sein. Die Pflicht entfällt unter anderem, wenn das System nur eine unterstützende Funktion für die Standardbearbeitung erfüllt oder die Eingabedaten nicht wesentlich verändert. Für Systeme, die vor dem 2. August 2026 in Verkehr gebracht wurden, läuft die Frist bis zum 2. Dezember 2026.

Infrage kommen Metadaten, Wasserzeichen und Herkunftsnachweise nach dem C2PA-Standard (Content Credentials). Die geprüften Kommissionsseiten zum Code of Practice nennen nur allgemein Markierung, Herkunftsnachweis, Wasserzeichen und Erkennung; welche Verfahren Abschnitt 1 des Codes im Einzelnen vorsieht, ist nicht am Originaldokument geprüft.

Was Modellanbieter heute schon liefern

Anthropic ist ein gutes Beispiel dafür, was auf Modellebene passiert. Laut den Claude Release Notes vom 1. September 2026 trägt Text von Claude Fable 5.1 und Mythos 5.1 ein Anthropic-Text-Wasserzeichen. Unterstützte Bild-, Video- und Audiodateien aus dem Code-Execution-Tool tragen C2PA Content Credentials, wenn sie über die Files API abgerufen werden. Änderungen am Request sind dafür nicht nötig. Den datenschutzrechtlichen Rahmen für Claude im Unternehmen behandelt der Beitrag Claude DSGVO-konform nutzen.

Was beim eigenen System bleibt

Eine Markierung des Modellanbieters beantwortet nicht die Frage, ob das eigene System Anbieter nach Abs. 2 ist. Sie garantiert auch nicht, dass die Markierung beim Empfänger ankommt. Zwischen Modell und Veröffentlichung liegen oft Schritte, die Metadaten verändern können: Skalieren, Zuschneiden, Neukodieren, Komprimieren durch ein CDN oder der Upload in ein CMS. Ob ein C2PA-Manifest diese Kette übersteht, sollte man testen, nicht annehmen.

Bei Text ist die Lage unklarer. Wird ein Modell-Output umformuliert, übersetzt oder mit anderem Text gemischt, ist offen, was von einem Wasserzeichen übrig bleibt. Wer Text für Dritte erzeugt, sollte deshalb nicht allein auf das Wasserzeichen des Modellanbieters bauen.

In meinen eigenen Projekten geht es dabei vor allem um Text. Der Grounding Page Generator erzeugt Seiten als HTML mit JSON-LD, die zur Veröffentlichung gedacht sind. Für solche Texte hilft das Wasserzeichen des Modellanbieters am wenigsten, weil der Text nach der Generierung noch bearbeitet und in ein CMS übernommen wird.

Wann muss ein KI-Text nach Abs. 4 gekennzeichnet werden?

Laut Kommissions-FAQ sind KI-Texte zu kennzeichnen, die veröffentlicht werden, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren. Ausgenommen sind Texte, die menschlich geprüft oder redaktionell kontrolliert wurden, wenn eine Person die endgültige rechtliche Verantwortung für die Veröffentlichung trägt. Oberflächliche, rein formale Kontrollen wie eine Rechtschreib- oder Grammatikprüfung zählen laut FAQ nicht als menschliche Prüfung.

Zwei Abgrenzungen: Die Ausnahme für reine Assistenz bei der Standardbearbeitung steht in Abs. 2 und betrifft die maschinenlesbare Markierung durch den Anbieter, nicht die Textkennzeichnung nach Abs. 4. Und Deepfakes sind unabhängig davon offenzulegen. Das ist eine Betreiberpflicht nach Abs. 4, und die maschinenlesbare Markierung des Anbieters reicht dafür laut FAQ nicht aus. Ob ein Fachblog oder ein Unternehmensblog „Angelegenheiten von öffentlichem Interesse“ behandelt, beantwortet dieser Artikel nicht. Das ist eine Rechtsfrage des Einzelfalls.

Freigabe als nachweisbarer Workflow-Schritt

Für Entwickler steckt in Abs. 4 eine Architekturfrage. Die Ausnahme setzt menschliche Prüfung und redaktionelle Verantwortung voraus. Beides muss man im Zweifel zeigen können. Ein Häkchen „wurde gelesen“ in einem Chat reicht dafür kaum. Ein Freigabeschritt, der Teil der Pipeline ist, lässt sich dagegen belegen. Das ist Human in the Loop mit Protokoll.

Ein Muster, das ohne große Infrastruktur auskommt, die Freigabe mit Hash-Bindung:

1. Zustände statt Flags. Ein Inhalt durchläuft draft → in_review → approved → published. Nur ein Mensch kann approved setzen.
2. Freigabe-Datensatz. Wer hat freigegeben (benannte, verantwortliche Person), wann und welche Version. Die Version hält man als Hash des freigegebenen Inhalts fest.
3. Harte Prüfung beim Veröffentlichen. Der Publish-Endpunkt veröffentlicht nur, wenn ein Freigabe-Datensatz existiert und dessen Hash zum aktuellen Inhalt passt. Ändert jemand den Text nach der Freigabe, ist eine neue Prüfung fällig.
4. Automatische Prüfschritte setzen nie approved. Lint, Rechtschreibprüfung oder ein zweites Modell als Gutachter sind nützlich. Eine menschliche Prüfung im Sinne der FAQ ersetzen sie nicht.
5. Fallback Kennzeichnung. Fehlt die Freigabe, setzt die Pipeline die KI-Kennzeichnung automatisch, statt den Text unmarkiert zu veröffentlichen.

Wichtig ist Punkt 3. Eine Freigaberegel, die nur in einer Werkzeugbeschreibung oder einem Prompt steht, ist eine weiche Regel. Im Beitrag zum n8n MCP Server habe ich beschrieben, dass Claude bei mir Entwürfe anlegt und erst nach meiner Freigabe veröffentlicht. Dort steht die Freigabe als Regel in der Werkzeugbeschreibung. Technisch erzwungen wird sie nicht. Für Abs. 4 ist eine harte Grenze außerhalb des Modells die belastbarere Variante. Mehr dazu unter Guardrails. Dieselbe Frage stellt sich bei Pipelines, die Seiten für KI-Suchsysteme erzeugen (GEO).

Dass es auf die Position des Freigabeschritts ankommt, zeigt der Grounding Page Generator. Dort liegt die Freigabe vor der Generierung: Ein Research-Agent füllt die Felder, ein Mensch bestätigt oder korrigiert jedes Feld, erst danach erzeugt ein zweiter Modellaufruf Titel, Beschreibung, JSON-LD und Seitentext. Das sichert die Fakten ab. Für die Ausnahme nach Abs. 4 kommt es aber auf die Prüfung des Textes an, der tatsächlich veröffentlicht wird. Wer die Freigabe vor die Generierung legt, braucht deshalb zusätzlich einen Prüfschritt danach, oder der fertige Text wird gekennzeichnet.

Was ist an Leitlinien und Code of Practice verbindlich?

Verbindlich ist die Verordnung selbst. Die finalen Leitlinien vom 20. Juli 2026 sind die Auslegung der EU-Kommission; eine ausdrückliche Aussage zu ihrer Verbindlichkeit enthalten die geprüften Kommissionsseiten nicht (das Leitlinien-PDF selbst ist nicht geprüft). Der Code of Practice zur Transparenz KI-generierter Inhalte wurde laut Kommission am 10. Juni 2026 veröffentlicht. Kommission und AI Board haben ihn als angemessenes freiwilliges Instrument bestätigt, laut Reed Smith (Sekundärquelle) am 8. bzw. 9. Juli 2026.

Die Unterzeichnung ist freiwillig. Laut Kommissions-FAQ zur Unterzeichnung ist es kein Verstoß, den Code nicht zu unterzeichnen. Wer nicht unterzeichnet, muss die Einhaltung aber auf anderem Weg nachweisen.

Für kleine Teams ist das vor allem eine Dokumentationsfrage: welcher Hinweis, welche Markierung, welcher Freigabeschritt. Die Checkliste unten liefert die Bausteine.

Checkliste für Entwickler bis 2. Dezember 2026

Vorab zur Einordnung: Der 2. Dezember 2026 ist die Frist für Abs. 2 bei Bestandssystemen. Abs. 1 und Abs. 4 gelten bereits seit dem 2. August 2026. Wer dort noch Lücken hat, ist nicht in einer Übergangsphase.

1. Inventar anlegen (alle Absätze). Jedes System mit Kanal, Rolle (Anbieter, Betreiber oder beides) und Datum des Inverkehrbringens erfassen. Vor oder nach dem 2. August 2026 entscheidet, ob die Übergangsfrist nach Abs. 2 greift.
2. KI-Hinweis bei der ersten Interaktion (Abs. 1). Fester Text aus der Konfiguration, ausgegeben vor der ersten Modellantwort. Nicht im Systemprompt, nicht nur in den AGB. Bei Voice: feste Ansage vor dem ersten Modell-Turn, Verhalten bei Unterbrechung testen.
3. Ausgabekanäle von Agenten (Abs. 1). Jede E-Mail, jedes Ticket und jeder Anruf, der bei einem Menschen landen kann, trägt den Hinweis im Template.
4. Hinweis protokollieren (Abs. 1). Ein Log-Event pro Sitzung mit Sitzungs-ID, Kanal, Zeitstempel und Version des Hinweistexts.
5. Ausgabepfade für Inhalte erfassen (Abs. 2). Welche Systeme erzeugen Text, Bild, Audio oder Video für Dritte? Welche Markierung liefert der Modellanbieter bereits?
6. Markierung durch die Pipeline testen (Abs. 2). Pro Format ein automatisierter Test am Ende der Pipeline: Sind Metadaten oder C2PA-Manifest noch vorhanden und lesbar? Schritte, die sie entfernen, anpassen.
7. Freigabe als Zustand mit Datensatz (Abs. 4). Wer, wann, welche Version als Hash. Veröffentlichen nur mit passender Freigabe. Rechtschreibprüfung und Modell-Reviews setzen keine Freigabe.
8. Fallback-Kennzeichnung (Abs. 4). Ohne Freigabe automatisch kennzeichnen. Deepfakes immer offenlegen.
9. Entscheidungen dokumentieren (alle Absätze). Rolle, gewählte Umsetzung, Stand der genutzten Quellen und Code-of-Practice-Status schriftlich festhalten. Bei Unsicherheit über Rolle oder Anwendungsbereich rechtlich prüfen lassen.

Fazit: Transparenz ist eine Architekturentscheidung

Art. 50 klingt nach einer Formulierungsfrage: ein Satz im Chatfenster, ein Label unter dem Bild. In der Umsetzung ist es eine Architekturfrage. Ein Hinweis, den das Modell vergessen kann, ist nicht verlässlich. Eine Markierung, die beim Skalieren verloren geht, kommt beim Empfänger nicht an. Eine Freigabe, die nirgends protokolliert ist, lässt sich nicht nachweisen.

Die Bausteine sind klein: Ein fester Text vor der ersten Antwort, ein Log-Event, ein Test auf Metadaten und ein Freigabe-Datensatz mit Hash. Für die maschinenlesbare Markierung nach Abs. 2 bleibt bei Bestandssystemen Zeit bis zum 2. Dezember 2026. Der Hinweis nach Abs. 1 und die Kennzeichnung nach Abs. 4 gelten bereits seit dem 2. August 2026.

Dieser Artikel ist keine Rechtsberatung. Stand der Quellen: Oktober 2026.