2026 EU AI Act Article 50: Selbsthosting-Compliance

Gewinner der Prüfung ist nicht das offenste Modell, sondern die sauberste Nachweiskette: 2026 EU AI Act Article 50 Selbsthosting-Compliance beginnt mit der Rollenbestimmung und endet erst bei reproduzierbaren Tests für Markierung, Erkennung und Veröffentlichung. Open-Source-Lizenz und eigener Server sind keine automatische Ausnahme. Nur Systeme, die bereits vor dem 02.08.2026 auf dem EU-Markt waren oder in Betrieb genommen wurden, können die begrenzte Frist für Article 50(2) bis zum 02.12.2026 nutzen.

Diese Checkliste richtet sich an technische Leiter, Plattform- und MLOps-Teams sowie Compliance-Verantwortliche, die ein selbst gehostetes Open-Source-Modell für EU-Nutzer bereitstellen. Sie ist besonders relevant, wenn eine Anwendung Texte, Bilder, Audio oder Video erzeugt, einen AI Agent anbietet oder Inhalte über mehrere Export- und Veröffentlichungswege verteilt.

Letzte Aktualisierung: 03.08.2026. Datengrundlage: Europäische Kommission, veröffentlichte Article-50-Leitlinien vom 20.07.2026, offizielle FAQ mit Stand 24.07.2026 und der bewertete Code of Practice zur Transparenz KI-generierter Inhalte.

Selbsthosting entscheidet die Rolle nicht

Der häufigste Fehlstart lautet: „Das Modell läuft auf eigener Hardware, also ist nur der Betreiber verantwortlich.“ Für die Prüfung ist diese Abkürzung ungeeignet. Entscheidend ist nicht, wo die Gewichte gespeichert sind, sondern wer das AI-System entwickelt oder entwickeln lässt, unter welchem Namen es angeboten wird und wer seinen Einsatz tatsächlich kontrolliert.

Die Definition des Providers in Article 3(3) erfasst natürliche oder juristische Personen sowie öffentliche Stellen, die ein AI-System entwickeln oder entwickeln lassen und es unter eigenem Namen oder eigener Marke auf den Unionsmarkt bringen oder in Betrieb nehmen. Das gilt unabhängig davon, ob die Organisation innerhalb oder außerhalb der EU sitzt. Nach der offiziellen Article-50-FAQ der Europäischen Kommission können auch Anbieter außerhalb der EU erfasst sein, wenn der Output ihres Systems in der EU verwendet wird.

Für ein selbst gehostetes Open-Source-Modell sollte die Prüfung deshalb in dieser Reihenfolge erfolgen:

1. Wer hat das konkrete System entwickelt oder beauftragt?
   Das zugrunde liegende Modell, ein Inferenzserver, ein Prompting-Wrapper und die veröffentlichte Anwendung können unterschiedliche Verantwortliche haben.

2. Wer bringt das System nach außen?
   Maßgeblich sind Produktname, Marke, Dokumentation, Benutzeroberfläche, Vertragsbeziehung und die Organisation, die den Dienst anbietet.

3. Wer entscheidet über seinen Einsatz?
   Wer Zugriffsrechte, erlaubte Anwendungsfälle, Ausgabeformate, Moderation und Veröffentlichungswege kontrolliert, kann zusätzlich als Deployer auftreten.

4. Werden natürliche Personen direkt mit dem System konfrontiert?
   Dann ist Article 50(1) gesondert zu prüfen. Ein Chatbot oder AI Agent muss grundsätzlich erkennen lassen, dass die Person mit einem AI-System interagiert, sofern dies nicht ohnehin offensichtlich ist.

Prüffrage	Typischer Hinweis auf Provider-Rolle	Typischer Hinweis auf Deployer-Rolle
Außenauftritt	Das System wird unter eigenem Namen oder eigener Marke angeboten	Das System wird für interne oder geschäftliche Abläufe genutzt
Technische Kontrolle	Produktteam bestimmt Modell, Schnittstellen und Veröffentlichung	Fachabteilung bestimmt Zweck und Nutzung unter eigener Autorität
Vertrag	Kunden erwerben Zugang zum AI-System	Organisation nutzt einen Dienst oder ein internes System für eigene Prozesse
Verantwortung	Markierung und Erkennung werden in die Systemarchitektur eingebaut	Sichtbare Hinweise, Veröffentlichungsprüfung und Nutzungskontrolle werden organisiert

Zählt ein selbst gehostetes Open-Source-Modell nach der Bereitstellung als Provider oder als Deployer?
Eine pauschale Antwort wäre rechtlich nicht belastbar. Eine Organisation kann Provider des konkreten AI-Systems und zugleich Deployer für bestimmte Arbeitsabläufe sein. Die Leitlinien der Europäischen Kommission zu Article 50 sind eine wichtige Auslegungshilfe, ersetzen aber keine Prüfung der konkreten Vertrags-, Produkt- und Kontrollstruktur.

Achtung: Eine freie oder offene Modelllizenz ist keine allgemeine Article-50-Ausnahme. Auch ein kostenlos angebotener Dienst kann unter den Anwendungsbereich fallen, wenn das konkrete System unter eigenem Namen bereitgestellt oder professionell eingesetzt wird.

Die Übergangsfrist gilt nur für einen engen Teil

Article 50 gilt seit dem 02.08.2026. Das Datum betrifft nicht nur neue Systeme. Die Europäische Kommission erklärt, dass die Transparenzpflichten ab diesem Tag für Systeme im Anwendungsbereich gelten. Die begrenzte Übergangsregel betrifft ausschließlich bestimmte bereits vor diesem Datum auf dem Markt befindliche oder in Betrieb genommene Systeme und nur die Markierungs- und Erkennungspflicht aus Article 50(2). Für diese Systeme endet die Frist am 02.12.2026.

Damit ist die Übergangsfrist keine allgemeine Schonfrist für alle Transparenzpflichten:

Sachverhalt	Prüfung am 03.08.2026	Bedeutung für die Frist
AI-System erstmals nach dem 02.08.2026 bereitgestellt	Article 50 ist grundsätzlich sofort zu prüfen	Keine pauschale Verlängerung bis Dezember
System vor dem 02.08.2026 auf dem Markt oder in Betrieb	Nachweis des Bestandsstatus erforderlich	Article 50(2)-Markierung und Erkennung können bis 02.12.2026 nachgerüstet werden
Inhalt vor dem 02.08.2026 erzeugt und veröffentlicht	Keine rückwirkende Kennzeichnungspflicht laut FAQ	Veröffentlichungsdatum muss nachweisbar sein
Inhalt vor dem 02.08.2026 erzeugt, aber erst danach veröffentlicht	Veröffentlichung ist separat zu bewerten	Nicht automatisch vom Bestandsschutz erfasst
Direct Interaction mit Personen	Article 50(1) separat prüfen	Nicht in die Article-50(2)-Frist hineinlesen
AI-generierter Text zu öffentlichem Interesse	Article 50(4) und menschliche Prüfung prüfen	Nicht durch die Markierungsfrist ersetzen

Können alle Systeme, die vor dem 02.08.2026 online waren, bis Dezember warten?
Nein. Das Team muss mindestens drei Zeitpunkte auseinanderhalten: die erste Bereitstellung oder Inbetriebnahme des Systems, die Erzeugung des konkreten Inhalts und dessen Veröffentlichung. Ein vorhandener Endpunkt ist außerdem nicht automatisch ein Beleg dafür, dass genau dieses System bereits vor dem Stichtag auf dem Markt war.

Die Zeitakte sollte deshalb folgende Nachweise enthalten:

• Commit- oder Release-ID der eingesetzten Anwendung;
• Freigabeprotokoll der produktiven Modellversion;
• Datum der ersten öffentlichen Bereitstellung;
• Änderungsprotokoll für Modell, Inferenzserver und Ausgabepipeline;
• Zeitstempel für Generierung und Veröffentlichung einzelner Testinhalte;
• Entscheidung, ob die Anwendung unter eigenem Namen oder einer fremden Marke betrieben wird.

Die juristische Einordnung zur zeitlichen Anwendung und zu bestehenden Systemen ist als ergänzende Analyse nützlich, aber nicht mit einer verbindlichen Gerichtsentscheidung gleichzusetzen.

Output-Klassen müssen vor der Technikprüfung feststehen

Ein Team kann keine sinnvolle Markierung testen, solange es nicht definiert hat, welche Ausgaben tatsächlich in den Prüfbereich fallen. Article 50(2) betrifft nach der offiziellen FAQ synthetische Audio-, Bild-, Video- und Textinhalte, die durch ein generatives AI-System erzeugt oder manipuliert werden. Die Markierung muss maschinenlesbar sein und die Erkennung als künstlich erzeugt oder manipuliert ermöglichen, soweit dies technisch möglich ist.

Für die interne Klassifizierung eignet sich folgende Matrix:

Ausgabe	Erste technische Prüfung	Typische rechtliche Einordnung
Langer Text für Kunden, Website oder Redaktion	Metadaten, Wasserzeichen oder andere maschinenlesbare Kennzeichnung	Article 50(2) möglich; bei Veröffentlichung zu öffentlichem Interesse zusätzlich Article 50(4)
Bild, Audio oder Video	Erkennung nach Export, Kompression und Plattform-Upload	Article 50(2) grundsätzlich prüfen
Kurze Zeichen- oder Zahlenfolge	Zweck und menschliche Sichtbarkeit dokumentieren	Kann laut Leitlinien außerhalb der Markierungspflicht liegen
Quellcode	Zweck, Ausgabeweg und Sichtbarkeit prüfen	Quellcode ist in den Leitlinien als möglicher Ausnahmebereich genannt
Reine Maschine-zu-Maschine-Ausgabe	Sicherstellen, dass keine natürliche Person exponiert wird	Kann außerhalb der Interaktionspflicht liegen
Interne Forschungs- oder Produktionspipeline	Abgrenzung zur finalen Veröffentlichung	Geschlossene Entwicklungsumgebung nicht vorschnell auf Endinhalte übertragen

Muss von einem Open-Source-Modell erzeugter Quellcode maschinenlesbar markiert werden?
Die offiziellen Leitlinien nennen Quellcode als eine Kategorie, die unter bestimmten Voraussetzungen außerhalb der Markierungspflicht liegen kann. Das ist keine Freigabe für jede Coding-Anwendung. Sobald derselbe Inhalt als Dokumentation, Anleitung, Kundenkommunikation oder öffentliches Informationsmaterial erscheint, ändern sich Zweck und Exposition. Die Ausnahme darf daher nicht vom Dateityp allein abgeleitet werden.

Auch die folgenden Grenzen sind eng zu lesen:

• reine Maschine-zu-Maschine-Kommunikation ohne Kontakt zu Menschen;
• kurze Sequenzen aus Zahlen, Buchstaben oder Symbolen;
• geschlossene industrielle oder produktbezogene Entwicklungsumgebungen, sofern es sich nicht um das finale Ergebnis handelt;
• standardmäßige Assistenzfunktionen bei redaktioneller Bearbeitung.

Eine Rechts- oder Grammatikprüfung ist nicht automatisch eine substanzielle menschliche Kontrolle. Die Kommission stellt ausdrücklich klar, dass rein formale Korrekturen wie Rechtschreib- oder Grammatikprüfungen keine ausreichende menschliche Prüfung für die Ausnahme bei Article 50(4) darstellen.

Sichtbares Label und maschinenlesbare Markierung sind zwei verschiedene Kontrollen

Die technische Umsetzung scheitert häufig an einer Verwechslung: Ein sichtbarer Hinweis im Benutzerinterface erfüllt nicht automatisch die Provider-Pflicht zur maschinenlesbaren Markierung. Umgekehrt ersetzt ein unsichtbares Metadatum nicht zwingend die sichtbare Offenlegung gegenüber natürlichen Personen.

Die drei Ebenen sollten in der Architektur getrennt dokumentiert werden:

1. Article 50(1): Interaktionshinweis
   Der Nutzer muss zu Beginn einer direkten Interaktion erkennen können, dass ein AI-System antwortet. Das betrifft etwa Chatbots, Sprachschnittstellen und AI Agents.

2. Article 50(2): Provider-seitige Markierung und Erkennung
   Generierte oder manipulierte Audio-, Bild-, Video- und Textinhalte benötigen eine wirksame, zuverlässige, robuste und interoperable maschinenlesbare Kennzeichnung, soweit dies technisch möglich ist.

3. Article 50(4): Deployer-seitige sichtbare Offenlegung
   Deepfakes sowie AI-generierte oder manipulierte Texte zu Themen von öffentlichem Interesse müssen klar gekennzeichnet werden, sofern keine eng begrenzte Ausnahme durch substanzielle menschliche Prüfung oder redaktionelle Kontrolle greift.

Was lösen Metadaten, Wasserzeichen und sichtbare Labels jeweils?
Metadaten sind für automatisierte Erkennung und Nachweisführung geeignet, können aber bei Exporten oder Plattformverarbeitung verloren gehen. Wasserzeichen können die Robustheit erhöhen, müssen aber auf Wahrnehmbarkeit, Manipulationsresistenz und Medienart geprüft werden. Sichtbare Labels richten sich an Menschen und müssen ohne spezielle technische Werkzeuge verständlich sein. Keine dieser Methoden ist allein schon deshalb konform, weil sie „Wasserzeichen“ oder „Metadaten“ genannt wird.

Der offizielle Code of Practice zur Transparenz KI-generierter Inhalte beschreibt Maßnahmen für Markierung und Erkennung und legt Wert auf technische Wirksamkeit, Interoperabilität, Robustheit und Zuverlässigkeit. Die Einhaltung ist freiwillig, die gesetzlichen Article-50-Pflichten sind es nicht.

Entscheidungshilfe für die technische Umsetzung

• Wenn das System nach dem 02.08.2026 erstmals bereitgestellt wird, dann Markierung und Erkennung vor dem öffentlichen Start testen; sonst zurück zu einer dokumentierten Bestandsprüfung.
• Wenn Inhalte den Prozess als Datei verlassen, dann Export, Kompression, Transkodierung und erneuten Import testen; sonst bleibt die Prüfung auf die interne Pipeline begrenzt.
• Wenn natürliche Personen den Inhalt sehen oder hören, dann sichtbare oder auditive Offenlegung getrennt von der Maschinenmarkierung implementieren.
• Wenn ein Inhalt zu einem Thema von öffentlichem Interesse veröffentlicht wird, dann redaktionelle Verantwortung und substanzielle Prüfung protokollieren.
• Wenn nur ein kurzes Token, Quellcode oder eine reine Maschine-zu-Maschine-Ausgabe erzeugt wird, dann die konkrete Ausnahme mit Zweck, Empfänger und Veröffentlichungsweg belegen; sonst den Inhalt wie einen markierungspflichtigen Output behandeln.
• Wenn die Markierung nach Drittplattformen nicht mehr erkennbar ist, dann Veröffentlichung stoppen oder einen alternativen, belastbareren Kennzeichnungsweg einsetzen.

Die Abnahme braucht einen reproduzierbaren Prüfpfad

Ein Screenshot mit einem sichtbaren Hinweis reicht für eine belastbare Article-50-Akte nicht aus. Die Abnahme muss zeigen, welche Anforderung geprüft wurde, mit welcher Version, an welchem Beispiel und mit welchem Ergebnis.

Welche Test- und Veröffentlichungsnachweise sollte die Article-50-Prüfung speichern?

Nachweisbereich	Mindestinhalt der Akte	Typischer Fehler
Anforderungszuordnung	Article 50(1), 50(2) oder 50(4), verantwortliche Rolle	Alle Pflichten werden unter „AI-Label“ zusammengefasst
Systemversion	Modell, Anwendung, Inferenzserver, Exportbibliothek	Nur der Modellname wird gespeichert
Testsample	Inhaltstyp, Format, Sprache, Promptklasse, Ausgabekanal	Nur ein einzelnes Bild oder Textbeispiel
Erkennungstest	Prüfwerkzeug, erwartetes Ergebnis, tatsächlicher Fund	Erkennung wird nur vor dem Export geprüft
Sichtbare Offenlegung	Position, Sprache, Barrierefreiheit, Zeitpunkt der Anzeige	Label erscheint erst nach der Veröffentlichung
Veröffentlichungsfreigabe	Verantwortliche Person, Prüfungsschritte, Zeitstempel	Rechtschreibprüfung wird als redaktionelle Kontrolle bezeichnet
Abweichungsprozess	Fehlerklasse, Sperrung, Korrektur, erneuter Test	Kein definierter Rückfall bei verlorener Markierung

Die Stichprobe sollte mindestens nach Inhaltstyp, Modellversion, Ausgabedatei, Sprache und Veröffentlichungsweg segmentiert werden. Erfolgsquoten oder Leistungswerte gehören nur in die Dokumentation, wenn die Testbedingungen reproduzierbar gespeichert wurden. Ohne diese Bedingungen ist eine Prozentzahl eher Marketing als Nachweis.

Ein robuster Ablauf umfasst mindestens sieben Schritte:

1. Anwendungsinventar erstellen: Endpunkte, Benutzeroberflächen, Batch-Jobs, Agenten und Exportpfade erfassen.
2. Rollenmatrix freigeben: Provider, Deployer, technische Betreiber und redaktionell Verantwortliche benennen.
3. Output-Klassen definieren: Text, Quellcode, Bild, Audio, Video, Deepfake und Maschine-zu-Maschine-Ausgabe trennen.
4. Stichtage sichern: Erstes Inverkehrbringen, Inbetriebnahme, Generierung und Veröffentlichung getrennt protokollieren.
5. Markierung implementieren: Metadaten, Wasserzeichen oder alternative Verfahren je Medium dokumentieren.
6. Pipeline testen: Transkodierung, Kompression, Archivierung, CDN-Auslieferung und Drittplattformen einbeziehen.
7. Sichtbare Offenlegung prüfen: Interaktionshinweis, Deepfake-Label und Public-Interest-Text getrennt bewerten.
8. Fehlerpfad ausführen: Markierung absichtlich entfernen oder beschädigen, Veröffentlichung blockieren und Rollback dokumentieren.
9. Freigabe archivieren: Testbericht, Build-Artefakt, Prüfsamples und verantwortliche Freigabe gemeinsam speichern.

Für die operative Umgebung sollte ein separates Testsystem eingesetzt werden. Direkte Versuche in der Produktion erschweren den Vergleich zwischen Modellversionen, erhöhen das Risiko unmarkierter Inhalte und machen einen sauberen Rollback unnötig teuer.

Lokale Geräte oder Cloud-Mac für die Abnahme

Nicht jedes Team benötigt für diese Prüfung eine neue Hardwareumgebung. Ein lokaler Mac ist sinnvoll, wenn Datenschutz, physische Schnittstellen und eine dauerhaft reproduzierbare Einzelumgebung wichtiger sind als kurzfristige Parallelität. Eine gemietete Mac-Umgebung ist dagegen interessant, wenn mehrere Modellversionen, Exportpfade oder Betriebssystemstände zeitweise parallel geprüft werden müssen.

Option	Geeignet, wenn	Nachteil
Lokaler Mac	Sensible Samples lokal bleiben müssen und eine feste Einzelumgebung genügt	Parallele Regressionstests binden die vorhandene Hardware
Cloud-Mac für einen Projektzeitraum	Isolierte Testinstanzen, Remote-Zusammenarbeit und zeitlich begrenzte Abnahme benötigt werden	Zugriff, Datenlöschung und Berechtigungen müssen vertraglich und technisch geprüft werden
Gemeinsame Produktionsmaschine	Nur für kleine, nicht sensible Vorprüfungen	Keine saubere Trennung von Test, Freigabe und produktivem Betrieb
Dedizierte Testumgebung	Mehrere Modell- und Pipelineversionen reproduzierbar verglichen werden sollen	Zusätzliche Betriebs- und Dokumentationsarbeit

Bei einer gemieteten Umgebung muss die technische Prüfung um Datenschutz und Zugriffskontrolle ergänzt werden. Die Datenschutzhinweise von ProxyMac sollten gemeinsam mit den eigenen Anforderungen an Aufbewahrung, Zugang, Löschung und Protokollierung geprüft werden. Für die operative Verwaltung kann die ProxyMac-Hilfe als Ausgangspunkt dienen; die konkrete Article-50-Bewertung bleibt beim betreibenden Unternehmen.

Erfahrung aus der Praxis: Die entscheidende Frage lautet nicht, ob ein Wasserzeichen im ersten Export sichtbar ist. Entscheidend ist, ob ein unabhängiger Prüfer später denselben Build, dasselbe Sample und denselben Veröffentlichungsweg nachvollziehen kann.

Die Abnahme scheitert oft an Stabilität und Berechtigungen

Bei selbst gehosteten Systemen entstehen neben der Rechtsfrage mindestens drei technische Nebenkosten:

• Versionsdrift: Ein Modell- oder Bibliotheksupdate kann die Markierungspipeline verändern, obwohl die Benutzeroberfläche gleich bleibt.
• Medienverlust: Kompression, Transkodierung oder externe Plattformen können Metadaten entfernen oder Wasserzeichen schwächen.
• Berechtigungsunklarheit: Wenn Entwickler, Redaktion und Plattformbetrieb dieselben Freigaberechte besitzen, ist später nicht erkennbar, wer eine unmarkierte Ausgabe veröffentlicht hat.
• Testdatenrisiko: Öffentliche oder personenbezogene Samples können in Logs, temporären Verzeichnissen und Backups verbleiben.
• Rollback-Lücke: Ein Fehler wird zwar erkannt, aber die Anwendung kann nicht schnell auf eine geprüfte Version zurückgestellt werden.

Für die Betriebsakte sollten daher auch Build-Hashes, Konfigurationsstände, Zugriffsrollen, Log-Aufbewahrung, Löschfristen und Freigabestatus festgehalten werden. Ein internes Datenschutz- und Zugriffsmodell kann dabei als organisatorische Ergänzung dienen, ersetzt jedoch keine eigene Datenschutzprüfung nach DSGVO.

Vor dem Produktivstart genügt eine klare Abnahmeentscheidung

Die technische Leitung sollte die Freigabe erst erteilen, wenn jede der folgenden Bedingungen mit einem Nachweis hinterlegt ist:

• Die Organisation hat Provider- und Deployer-Rolle anhand realer Geschäfts- und Kontrollbeziehungen bewertet.
• Article 50(1), 50(2) und 50(4) sind getrennt dokumentiert.
• Die Bestandsfähigkeit für die Frist bis 02.12.2026 ist anhand von Release- und Inbetriebnahmedaten belegt.
• Die Output-Kategorien und möglichen Ausnahmen sind pro Anwendung beschrieben.
• Die maschinenlesbare Markierung übersteht die vorgesehenen Export- und Verteilungsschritte.
• Sichtbare Hinweise werden unabhängig von der technischen Markierung angezeigt.
• Für Public-Interest-Texte gibt es eine substanzielle menschliche Prüfung oder eine klare Kennzeichnung.
• Fehler, Markierungsverlust und Drittplattform-Rekodierung lösen einen definierten Sperr- oder Rollback-Prozess aus.
• Testumgebung, Prüfsamples, Versionen und Freigaben sind reproduzierbar archiviert.

Wer diese Punkte nicht erfüllen kann, sollte nicht einfach „Open Source“ oder „intern betrieben“ als Ausnahme in die Risikoakte schreiben. Für die konkrete rechtliche Einstufung ist eine Prüfung durch eine mit dem EU AI Act vertraute Rechtsberatung erforderlich.

Im Vergleich zu einer fest eingerichteten lokalen Umgebung bleiben bei einer gemeinsam genutzten Produktionsmaschine oft Versionskonflikte, fehlende Isolation und unklare Rollback-Wege bestehen. Ein eigener Ausbau bindet außerdem Kapital, muss dauerhaft gewartet werden und eignet sich schlecht für kurze Paralleltests. Wenn die vorhandene Hardware diese reproduzierbaren Modell-, Transkodierungs- und Erkennungsläufe nicht stabil unterstützt, kann eine zeitlich begrenzte, isolierte Cloud-Mac-Umgebung von ProxyMac die sachlich passendere Ergänzung sein: nicht als Ersatz für die rechtliche Verantwortung, sondern als kontrollierte Teststrecke vor der Produktionsfreigabe.

Für die nächste Entscheidung sollte das Team zunächst die Rollenmatrix, Output-Klassifizierung und Beweiskette aus dieser Checkliste in ein internes Abnahmeblatt übertragen. Erst wenn dort ein konkreter Engpass bei Isolation, Paralleltests oder Rückrollback sichtbar wird, lohnt sich die Prüfung einer projektbezogenen Mac-Umgebung über die ProxyMac-Konsole.