Module 6 — Building Downstream: You Are the Provider of the System

Module 6 of the AI Act GPAI certification: Art. 50 transparency for generative systems, the Art. 25 trap for downstream builders, and what to demand from a model provider before depending on them.

Most organisations reading this track will never train a model. They build on one, and their obligations come from three places: Art. 50 because their system is generative, Art. 25 because purpose can change under them, and their contract because everything they owe depends on information the model provider holds.

You are the provider of the system

Building a product on a third-party model and putting it into service under your own name makes you the provider of an AI system under Art. 3(3). Chapter V duties for the underlying model stay with whoever provided it. Nothing about using someone else's model shelters your system.

That is the whole of it, and it is worth stating plainly because the instinct — we didn't build the AI, they did — is both natural and wrong.

Art. 50, in force now

Two of the four Art. 50 duties will apply to a typical generative product, and they applied from 2 August 2026.

Art. 50(1) — interaction disclosure. Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed so that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a reasonably well-informed, observant and circumspect natural person, taking into account the circumstances and the context of use. There is a carve-out for systems authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to safeguards.

The "obvious" exception is narrower than product teams hope. A chat interface labelled with a product name is not self-evidently an AI system to a member of the public.

Art. 50(2) — machine-readable marking. Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs are marked in a machine-readable format and detectable as artificially generated or manipulated. Providers shall ensure their technical solutions are effective, interoperable, robust and reliable as far as this is technically feasible, taking into account the specificities and limitations of various types of content, the costs of implementation and the generally acknowledged state of the art.

This obligation is tier-independent — it does not matter whether your system is high-risk — and it is a provider duty, so it is yours, not your model vendor's, for the system you ship. A transitional rule gave providers of generative systems already on the market before 2 August 2026 until 2 December 2026 to comply.

The Art. 50(3) and 50(4) duties — emotion recognition and biometric categorisation notices, deepfake and public-interest text disclosure — sit on deployers, which means your customers. Your Art. 13-equivalent job is to make it possible for them to comply.

The Art. 25 trap, from the downstream seat

Art. 25(1)(c) makes you the provider of a high-risk AI system where you modify the intended purpose of a system — including a general-purpose AI system that has not been classified as high-risk — such that it becomes high-risk.

The pattern is always the same and never looks like a decision:

• A general assistant licensed for drafting, pointed at CV screening. Annex III point 4.
• A summarisation product, used to draft adverse benefit decisions. Annex III point 5.
• A classification pipeline built for content moderation, reused for creditworthiness. Annex III point 5(b) — and note that had it been reused for fraud detection it would have been carved out.

When it fires, Art. 16 and the whole of Chapter III attach: risk management, data governance for training data you have never seen, Annex IV documentation, conformity assessment, CE marking, registration, post-market monitoring.

The control is procedural and cheap. Every new use case for an existing system goes through the same classification step as a new system. One form, five minutes, at the moment of reuse. Without it, purpose creep is invisible by construction, because reusing a working pipeline is what good engineering practice tells a team to do.

What to demand from a model provider

Everything you owe depends on information they hold. Ask before you depend on them, while you still have commercial leverage.

The Annex XII information, as a document. Art. 53(1)(b) obliges them to provide information enabling downstream providers to understand capabilities and limitations and to comply with their own obligations. A marketing page is not that document. Confidentiality qualifies the level of detail, not the existence of the duty.

Systemic-risk status. Is the model on the Commission's published list; if not, do they expect it to be. It changes their obligations and, through them, your exposure.

The acceptable use policy, and specifically what it says about high-risk uses. If it prohibits them, you know that a high-risk deployment puts you outside your licence as well as into Art. 25.

The incident path. Their Art. 55(c) duty runs to the AI Office. Your Art. 26(5) duty, if you deploy high-risk, runs to your market surveillance authority. If you are in the middle, you need a channel in both directions with a stated timeframe.

Change and deprecation policy. Model versions are withdrawn and behaviour shifts. If your Annex IV documentation describes performance you can no longer reproduce because the underlying model changed, you have a conformity problem caused by someone else's release schedule.

Cooperation commitments. If Art. 25 ever makes you the provider of a high-risk system built on their model, Art. 25(2) gives you a statutory cooperation claim — unless they clearly specified the model was not to be used that way, which they very likely did. Contract for it instead.

A short checklist for a downstream build

1. Are we generating synthetic content? Then Art. 50(2) marking is ours, now.
2. Does the system interact directly with people? Then Art. 50(1) disclosure is ours, now.
3. What is the declared intended purpose of our system, in writing?
4. Is there a gate on new use cases that would catch an Annex III purpose change?
5. Do we hold the Annex XII information, the acceptable use policy and a change policy from the model provider?
6. If we deploy for customers, have we written instructions for use that let them meet Art. 26?

The last is the one that separates a product from a liability. Everything your customers owe under Art. 26 depends on what you tell them, and Art. 13 makes inadequate instructions a defect in your product rather than a gap in theirs.

Check yourself

1. Our model vendor marks its outputs, so Art. 50(2) is covered. — Art. 50(2) binds the provider of the system generating the content. You ship the system; the duty is yours.
2. We only expose a chat box; surely it is obvious it is AI. — The exception is judged from the point of view of a reasonably well-informed, observant and circumspect person in context. A product-branded chat interface is rarely self-evident.
3. A team started using our summariser to draft benefit decisions. — Art. 25(1)(c). The intended purpose has changed into an Annex III use and you are now the provider of a high-risk system.
4. The model vendor says everything is a trade secret. — Art. 53(1)(b) and Annex XII require information enabling downstream compliance. Ask for it in writing, and contract for it before you depend on them.

Previous: Module 5 — Becoming a model provider

You have completed the six modules. Together they cover Chapter V and the obligations that reach a downstream builder — sit the GPAI examination →