GPAI Transparency Obligations: What General-Purpose AI Integrators Must Disclose in 2026
A common assumption in SaaS teams that wrap a third-party model behind their own feature: GPAI compliance is the model provider's problem. OpenAI, Anthropic, Google, Mistral - they trained the model, so they carry the EU AI Act obligations, right?
Partly. The general-purpose AI (GPAI) rules in the EU AI Act do put the heaviest documentation duties on the companies that train and place the models on the market. But the transparency obligations that your users actually see - telling people they are talking to an AI, marking generated content, labelling synthetic media - sit with the provider of the AI system. If your product calls a foundation model through an API and presents the output under your brand, that provider is you. And the deadline that matters for those user-facing duties is 2 August 2026.
This post maps the disclosure landscape for integrators: which obligations belong to the model provider, which ones you inherit the moment you ship an AI feature, what changes if you fine-tune, and how to implement the disclosures without making your product feel like a legal notice.
The Two Rule Sets People Confuse
Most of the confusion around GPAI compliance comes from mixing up two separate chapters of the AI Act.
Article 53 and the GPAI chapter target providers of general-purpose AI models: the organisations that train a foundation model and place it on the EU market. These obligations have applied since 2 August 2025 and include maintaining technical documentation, providing information to downstream providers, implementing a copyright policy, and publishing a summary of the training data. Models classified as carrying systemic risk face additional evaluation, incident reporting, and cybersecurity duties.
Article 50 targets providers and deployers of AI systems - the products built on top of those models. Its transparency obligations become enforceable on 2 August 2026, and they are the ones an integrator cannot delegate upstream.
The practical test is simple. Did you train the foundation model? If not, Article 53 is mostly something you benefit from rather than owe. Do you ship a product with an AI feature under your own name? Then Article 50 is your list.
What Model Providers Must Disclose (and What You Can Demand)
Even though Article 53 is not your obligation, it shapes your GPAI compliance work, because it defines what you are entitled to receive from your model vendor.
Model providers must give downstream providers - that is you - the information needed to understand the model's capabilities and limitations and to meet your own obligations under the Act. In practice this arrives as model documentation, usage policies, and the kind of model card material the GPAI Code of Practice formalised in 2025.
When you evaluate or renew a model vendor, treat this as procurement criteria. Ask for the documentation pack intended for downstream providers. Ask how the provider supports the machine-readable marking of generated output. Ask whether their terms address the allocation of AI Act responsibilities between provider and integrator. A vendor that cannot answer these questions in 2026 is creating compliance debt that lands on you. This belongs in your tech stack decisions with the same weight as pricing and latency.
What Integrators Must Disclose in 2026
Article 50 contains four transparency duties. Not all of them will apply to every product, so the first task is an inventory: list every AI-driven interaction in your product, then check it against these categories.
1. Tell users when they are interacting with an AI
If your product includes a chatbot, an AI assistant, a voice agent, or any interface where a person interacts directly with an AI system, users must be informed they are dealing with AI - unless it is already obvious from context to a reasonably informed person. A support widget that answers in natural language under a human-sounding name does not pass the obviousness test. A feature explicitly labelled as an AI assistant probably does, but a short, clear notice removes the doubt entirely and costs you one line of UI.
2. Mark AI-generated content in machine-readable form
Providers of systems that generate synthetic audio, image, video, or text must ensure outputs are marked as artificially generated in a machine-readable format. This is the technically demanding one for integrators, because the marking has to survive your pipeline. If your backend receives model output, transforms it, renders it into a PDF, or stores it for later export, a watermark or metadata tag applied by the model provider can get stripped along the way. Standards like C2PA content credentials for media and metadata-based approaches for text are the direction of travel; your engineering task is to verify the marking end to end, not to assume the API vendor handled it.
3. Label deepfakes and synthetic media
Deployers of systems that generate or manipulate image, audio, or video content resembling real people, places, or events must disclose that the content was artificially generated or manipulated. If your product lets customers generate avatar videos, voice clones, or photorealistic imagery, the visible label is mandatory, with narrow exceptions for artistic and satirical works where the disclosure can be adapted rather than dropped.
4. Disclose emotion recognition and biometric categorisation
If a feature infers emotions or categorises people based on biometric data, the people exposed to it must be informed. Most B2B SaaS products are not in this territory, but call-center analytics, interview tooling, and engagement scoring features can wander into it faster than teams expect. Note that some of these use cases also trigger the high-risk regime; we covered that route in our EU AI Act conformity assessment guide.
In all four cases the disclosure must be clear, distinguishable, and delivered at the first interaction or exposure. Burying it in terms of service does not meet the bar.
When Fine-Tuning Makes You a Model Provider
There is a scenario where an integrator crosses the line into Article 53 territory: modifying the model itself. If you fine-tune a foundation model and place the result on the market, you can become the provider of a GPAI model with respect to your modification. The European Commission's 2025 guidelines took a proportionate view, indicating that obligations for downstream modifiers attach to substantial modifications, with the training compute used for the modification as the key indicator, and that the duties then concern the modification rather than the entire original model.
For most teams doing light fine-tuning or retrieval-augmented setups, this threshold is unlikely to be met. But document your reasoning: record what you modified, the compute involved, and why you concluded you did or did not become a model provider. Prompt engineering and RAG pipelines do not modify the model and do not trigger this. A silent assumption, on the other hand, is exactly the kind of gap an enterprise customer's legal review will find.
Designing Disclosures That Don't Scare Users
The teams that handle this well treat disclosure as product design, not legal copy. Three patterns work consistently.
Make the AI label part of the feature's identity. Products that present AI assistance as a capability ("Drafted with AI, review before sending") see better user trust than products that hide the AI and append a disclaimer. The disclosure and the value proposition can be the same sentence.
Put the notice at the interaction boundary, once. Article 50 requires disclosure at first interaction, not on every message. A persistent but quiet indicator - an AI badge in the chat header, a content credential on exported media - satisfies the rule without nagging.
Pair every visible label with a machine-readable one. The visible label is for the user; the embedded marking is for platforms and regulators. Build both into the same output path so they cannot drift apart, and add a test to your CI that asserts generated artifacts carry the marking.
A Pre-August Checklist for Integrators
Use this as the skeleton for your GPAI compliance sprint before 2 August 2026:
- Inventory every AI feature and classify it against the four Article 50 categories.
- Collect vendor documentation from each model provider and confirm what marking support they give you.
- Implement interaction notices for chat and assistant features that are not obviously AI.
- Verify machine-readable marking end to end, including exports, transformations, and stored content.
- Add visible labels for any synthetic media features, with the deepfake rule in mind.
- Document your fine-tuning analysis, even if the conclusion is that you are not a model provider.
- Check for high-risk overlap: emotion recognition, biometrics, and employment-related features trigger more than transparency duties.
None of these items is individually hard. The risk is that they cut across frontend, backend, and vendor contracts, so no single team owns them and the deadline arrives with the work half done. An external review of your AI feature surface, the same way you would run a code quality audit before a due diligence event, is the fastest way to find the gaps while there is still time to close them. And if the remediation turns into real engineering work, marking pipelines, disclosure UX, logging, that is custom development worth doing once and doing properly.
If you want a second pair of eyes on your AI Act exposure before August, write to hello@wolf-tech.io or visit wolf-tech.io. We help SaaS teams turn regulatory deadlines into shipped, tested features.