GPAI-Transparenzpflichten: Was Integratoren von General-Purpose AI 2026 offenlegen müssen

Eine verbreitete Annahme in SaaS-Teams, die ein Drittanbieter-Modell hinter dem eigenen Feature kapseln: GPAI Compliance ist das Problem des Modellanbieters. OpenAI, Anthropic, Google, Mistral - sie haben das Modell trainiert, also tragen sie die Pflichten aus dem EU AI Act, oder?

Teilweise. Die Regeln für General-Purpose AI (GPAI) im EU AI Act legen die schwersten Dokumentationspflichten tatsächlich den Unternehmen auf, die die Modelle trainieren und auf den Markt bringen. Aber die Transparenzpflichten, die deine Nutzer tatsächlich sehen - Menschen sagen, dass sie mit einer KI sprechen, generierte Inhalte kennzeichnen, synthetische Medien labeln - liegen beim Anbieter des KI-Systems. Wenn dein Produkt ein Foundation-Modell über eine API aufruft und den Output unter deiner Marke präsentiert, bist du dieser Anbieter. Und die Deadline, die für diese nutzerseitigen Pflichten zählt, ist der 2. August 2026.

Dieser Beitrag kartiert die Offenlegungslandschaft für Integratoren: welche Pflichten dem Modellanbieter gehören, welche du in dem Moment erbst, in dem du ein KI-Feature auslieferst, was sich beim Fine-Tuning ändert und wie du die Offenlegungen umsetzt, ohne dass sich dein Produkt wie ein juristischer Hinweistext anfühlt.

Die zwei Regelwerke, die ständig verwechselt werden

Die meiste Verwirrung rund um GPAI Compliance entsteht daraus, dass zwei separate Kapitel des AI Act vermischt werden.

Artikel 53 und das GPAI-Kapitel richten sich an Anbieter von General-Purpose-AI-Modellen: die Organisationen, die ein Foundation-Modell trainieren und es auf dem EU-Markt bereitstellen. Diese Pflichten gelten seit dem 2. August 2025 und umfassen technische Dokumentation, Informationen für nachgelagerte Anbieter, eine Copyright-Policy und eine veröffentlichte Zusammenfassung der Trainingsdaten. Modelle mit systemischem Risiko unterliegen zusätzlichen Pflichten zu Evaluierung, Incident-Reporting und Cybersicherheit.

Artikel 50 richtet sich an Anbieter und Betreiber von KI-Systemen - die Produkte, die auf diesen Modellen aufbauen. Seine Transparenzpflichten werden am 2. August 2026 durchsetzbar, und genau diese kann ein Integrator nicht nach oben delegieren.

Der praktische Test ist simpel. Hast du das Foundation-Modell trainiert? Falls nein, ist Artikel 53 vor allem etwas, wovon du profitierst, nicht etwas, das du schuldest. Lieferst du ein Produkt mit einem KI-Feature unter deinem eigenen Namen aus? Dann ist Artikel 50 deine Liste.

Was Modellanbieter offenlegen müssen (und was du einfordern kannst)

Auch wenn Artikel 53 nicht deine Pflicht ist, prägt er deine GPAI-Compliance-Arbeit, denn er definiert, was du von deinem Modellanbieter verlangen darfst.

Modellanbieter müssen nachgelagerten Anbietern - also dir - die Informationen geben, die nötig sind, um Fähigkeiten und Grenzen des Modells zu verstehen und die eigenen Pflichten aus dem Act zu erfüllen. In der Praxis kommt das als Modelldokumentation, Nutzungsrichtlinien und die Art von Model-Card-Material, die der GPAI Code of Practice 2025 formalisiert hat.

Wenn du einen Modellanbieter evaluierst oder einen Vertrag verlängerst, behandle das als Procurement-Kriterien. Frag nach dem Dokumentationspaket für nachgelagerte Anbieter. Frag, wie der Anbieter die maschinenlesbare Kennzeichnung generierter Outputs unterstützt. Frag, ob seine Vertragsbedingungen die Verteilung der AI-Act-Verantwortlichkeiten zwischen Anbieter und Integrator regeln. Ein Vendor, der diese Fragen 2026 nicht beantworten kann, erzeugt Compliance-Schulden, die bei dir landen. Das gehört in deine Tech-Stack-Entscheidungen mit demselben Gewicht wie Preis und Latenz.

Was Integratoren 2026 offenlegen müssen

Artikel 50 enthält vier Transparenzpflichten. Nicht alle treffen jedes Produkt, also ist die erste Aufgabe eine Inventur: Liste jede KI-gestützte Interaktion in deinem Produkt auf und prüfe sie gegen diese Kategorien.

1. Sag Nutzern, wenn sie mit einer KI interagieren

Wenn dein Produkt einen Chatbot, einen KI-Assistenten, einen Voice-Agent oder irgendein Interface enthält, in dem eine Person direkt mit einem KI-System interagiert, müssen Nutzer darüber informiert werden, dass sie es mit KI zu tun haben - es sei denn, das ist für eine vernünftig informierte Person aus dem Kontext offensichtlich. Ein Support-Widget, das unter einem menschlich klingenden Namen in natürlicher Sprache antwortet, besteht den Offensichtlichkeits-Test nicht. Ein explizit als KI-Assistent bezeichnetes Feature vermutlich schon, aber ein kurzer, klarer Hinweis beseitigt jeden Zweifel und kostet dich eine Zeile UI.

2. Kennzeichne KI-generierte Inhalte maschinenlesbar

Anbieter von Systemen, die synthetische Audio-, Bild-, Video- oder Textinhalte generieren, müssen sicherstellen, dass Outputs in einem maschinenlesbaren Format als künstlich erzeugt gekennzeichnet sind. Das ist für Integratoren der technisch anspruchsvolle Teil, denn die Kennzeichnung muss deine Pipeline überleben. Wenn dein Backend Modell-Output empfängt, transformiert, in ein PDF rendert oder für späteren Export speichert, kann ein vom Modellanbieter gesetztes Wasserzeichen oder Metadaten-Tag unterwegs verloren gehen. Standards wie C2PA Content Credentials für Medien und metadatenbasierte Ansätze für Text sind die Richtung, in die es geht; deine Engineering-Aufgabe ist, die Kennzeichnung Ende-zu-Ende zu verifizieren, nicht anzunehmen, dass der API-Anbieter das erledigt hat.

3. Labele Deepfakes und synthetische Medien

Betreiber von Systemen, die Bild-, Audio- oder Videoinhalte generieren oder manipulieren, die echten Personen, Orten oder Ereignissen ähneln, müssen offenlegen, dass der Inhalt künstlich erzeugt oder manipuliert wurde. Wenn dein Produkt Kunden Avatar-Videos, Voice-Clones oder fotorealistische Bilder generieren lässt, ist das sichtbare Label Pflicht, mit engen Ausnahmen für künstlerische und satirische Werke, bei denen die Offenlegung angepasst, aber nicht weggelassen werden darf.

4. Lege Emotionserkennung und biometrische Kategorisierung offen

Wenn ein Feature Emotionen ableitet oder Menschen anhand biometrischer Daten kategorisiert, müssen die betroffenen Personen informiert werden. Die meisten B2B-SaaS-Produkte bewegen sich nicht in diesem Terrain, aber Callcenter-Analytics, Interview-Tooling und Engagement-Scoring rutschen schneller hinein, als Teams erwarten. Beachte, dass einige dieser Anwendungsfälle zusätzlich das Hochrisiko-Regime auslösen; diesen Weg haben wir in unserem Leitfaden zur EU AI Act Konformitätsbewertung behandelt.

In allen vier Fällen muss die Offenlegung klar, unterscheidbar und bei der ersten Interaktion oder Exposition erfolgen. Sie in den Nutzungsbedingungen zu vergraben, erfüllt die Anforderung nicht.

Wann Fine-Tuning dich zum Modellanbieter macht

Es gibt ein Szenario, in dem ein Integrator in das Territorium von Artikel 53 wechselt: die Veränderung des Modells selbst. Wenn du ein Foundation-Modell fine-tunst und das Ergebnis auf den Markt bringst, kannst du in Bezug auf deine Modifikation zum Anbieter eines GPAI-Modells werden. Die Leitlinien der Europäischen Kommission von 2025 verfolgen eine verhältnismäßige Sichtweise: Pflichten für nachgelagerte Modifizierer greifen bei wesentlichen Modifikationen, mit dem für die Modifikation eingesetzten Trainings-Compute als zentralem Indikator, und die Pflichten betreffen dann die Modifikation, nicht das gesamte Ursprungsmodell.

Für die meisten Teams mit leichtem Fine-Tuning oder Retrieval-Augmented-Setups wird diese Schwelle kaum erreicht. Aber dokumentiere deine Begründung: Halte fest, was du modifiziert hast, welcher Compute im Spiel war und warum du zu dem Schluss gekommen bist, Modellanbieter geworden zu sein oder nicht. Prompt Engineering und RAG-Pipelines verändern das Modell nicht und lösen das nicht aus. Eine stillschweigende Annahme dagegen ist genau die Art von Lücke, die das juristische Review eines Enterprise-Kunden findet.

Offenlegungen gestalten, die Nutzer nicht verschrecken

Teams, die das gut lösen, behandeln Offenlegung als Produktdesign, nicht als juristischen Text. Drei Muster funktionieren durchgängig.

Mach das KI-Label zum Teil der Feature-Identität. Produkte, die KI-Unterstützung als Fähigkeit präsentieren ("Mit KI entworfen, vor dem Senden prüfen"), erzeugen mehr Nutzervertrauen als Produkte, die die KI verstecken und einen Disclaimer anhängen. Die Offenlegung und das Wertversprechen können derselbe Satz sein.

Platziere den Hinweis an der Interaktionsgrenze, einmal. Artikel 50 verlangt die Offenlegung bei der ersten Interaktion, nicht bei jeder Nachricht. Ein dauerhafter, aber dezenter Indikator - ein KI-Badge im Chat-Header, ein Content Credential auf exportierten Medien - erfüllt die Regel, ohne zu nerven.

Kopple jedes sichtbare Label mit einem maschinenlesbaren. Das sichtbare Label ist für den Nutzer; die eingebettete Kennzeichnung ist für Plattformen und Behörden. Baue beide in denselben Output-Pfad, damit sie nicht auseinanderdriften können, und ergänze einen CI-Test, der prüft, dass generierte Artefakte die Kennzeichnung tragen.

Eine Checkliste für Integratoren vor August

Nutze das als Skelett für deinen GPAI-Compliance-Sprint vor dem 2. August 2026:

1. Inventarisiere jedes KI-Feature und klassifiziere es gegen die vier Artikel-50-Kategorien.
2. Sammle Vendor-Dokumentation von jedem Modellanbieter und kläre, welche Kennzeichnungsunterstützung er dir gibt.
3. Implementiere Interaktionshinweise für Chat- und Assistenz-Features, die nicht offensichtlich KI sind.
4. Verifiziere die maschinenlesbare Kennzeichnung Ende-zu-Ende, einschließlich Exporten, Transformationen und gespeicherten Inhalten.
5. Ergänze sichtbare Labels für alle Features mit synthetischen Medien, mit der Deepfake-Regel im Blick.
6. Dokumentiere deine Fine-Tuning-Analyse, auch wenn das Ergebnis ist, dass du kein Modellanbieter bist.
7. Prüfe auf Hochrisiko-Überschneidungen: Emotionserkennung, Biometrie und beschäftigungsbezogene Features lösen mehr als nur Transparenzpflichten aus.

Keiner dieser Punkte ist für sich genommen schwer. Das Risiko ist, dass sie quer durch Frontend, Backend und Vendor-Verträge schneiden, sodass kein einzelnes Team sie verantwortet und die Deadline kommt, während die Arbeit halb erledigt ist. Ein externes Review deiner KI-Feature-Oberfläche, so wie du vor einem Due-Diligence-Termin ein Code-Quality-Audit fahren würdest, ist der schnellste Weg, die Lücken zu finden, solange noch Zeit bleibt, sie zu schließen. Und wenn die Behebung zu echter Engineering-Arbeit wird, Kennzeichnungs-Pipelines, Offenlegungs-UX, Logging, dann ist das individuelle Entwicklung, die man einmal und richtig macht.

Wenn du vor August ein zweites Paar Augen auf deine AI-Act-Exponierung haben möchtest, schreib an hello@wolf-tech.io oder besuche wolf-tech.io. Wir helfen SaaS-Teams, regulatorische Fristen in ausgelieferte, getestete Features zu verwandeln.