Article 50 of the EU AI Act became applicable on August 2, 2026. It is the transparency chapter, and it is likely to affect ordinary engineering teams because it does not depend on whether a system is high-risk. It depends on whether people can tell they are interacting with AI-generated or AI-manipulated content.
Most coverage focuses on model providers. For example, Anthropic signing the Article 50(2) Code of Practice and adding watermarking to Claude concerns Anthropic's provider obligations. If you call that API and ship its output in your product, you may have separate deployer obligations. Your provider being compliant does not make your product compliant.
This guide translates Article 50 into API engineering work: identify the paragraphs that apply to you, document the decisions, expose disclosure through your API contract, and enforce it in CI with Apidog.
The five paragraphs and who they apply to
| Paragraph | Who | What it requires |
|---|---|---|
| 50(1) | Provider | Systems that interact directly with people must make it clear they are AI, unless that is obvious to a reasonably well-informed person. |
| 50(2) | Provider | Generative systems must mark synthetic audio, image, video, and text in a machine-readable format detectable as artificially generated or manipulated. |
| 50(3) | Deployer | Emotion-recognition and biometric-categorisation systems must inform people exposed to them. |
| 50(4) | Deployer | Deepfakes must be disclosed. AI-generated text published to inform the public on matters of public interest must also be disclosed. |
| 50(5) | Both | Disclosure must be clear, accessible, and provided no later than the first interaction or exposure. |
The provider/deployer distinction is not about company size. It is a role you occupy for each system:
- You are a provider when you build and place a generative system on the EU market.
- You are a deployer when you use a system under your own authority.
- If you wrap and rebrand a third-party model in your product, you may be both for different parts of the stack.
Start by documenting that role per product surface. It determines which Article 50 obligations apply.
Article 50(2): machine-readable marking
Article 50(2) applies to providers of systems that generate synthetic audio, image, video, or text. They must ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated.
The requirement is not absolute. It requires solutions that are effective, interoperable, robust, and reliable as far as technically feasible, taking into account:
- Content-type limitations
- Implementation costs
- The generally acknowledged state of the art
This is why the market has converged on multiple approaches rather than one universal mechanism:
- Statistical watermarking for text
- Signed C2PA manifests for files
Neither is perfect, and the law acknowledges those constraints.
50(2) exemptions that matter to product teams
Assistive function for standard editing
A system used for assistive standard editing is out of scope. Examples include spell checking, formatting, or autocomplete that finishes text the user was already typing.
No substantial alteration of input data
If your system does not substantially alter the data it receives, Article 50(2) does not apply.
The boundary is not always clear:
- Reordering JSON keys is not generating synthetic content.
- A spell checker is assistive editing.
- Rewriting a paragraph for tone is not equivalent to spell checking.
That boundary is a legal decision. Engineering should implement and preserve the classification, not independently redefine it.
If you use a marked model, model-level marking can cover text that passes through that model. That is useful, but it only addresses the provider-side marking obligation. It does not discharge deployer obligations under 50(1), 50(4), or 50(5).
Article 50(4): the deployer obligation most API teams miss
Article 50(4) creates two main deployer duties.
Disclose deepfakes
If you deploy a system that generates or manipulates image, audio, or video content that constitutes a deepfake, disclose that the content is artificially generated or manipulated.
Artistic, satirical, fictional, and similar works receive lighter treatment. You still disclose the presence of generated content, but in a way that does not hamper display or enjoyment of the work.
Disclose AI-generated public-interest text
If you deploy a system that generates or manipulates text published to inform the public on matters of public interest, disclose that the text was artificially generated or manipulated.
There is an important exemption: the requirement does not apply where content has undergone human review or editorial control and a natural or legal person holds editorial responsibility for publication.
That is a process requirement, not a checkbox:
- “A human skimmed it” is not necessarily editorial control.
- A named person or accountable entity with editorial responsibility is materially different.
- For AI-assisted newsrooms, policy blogs, or health-information sites, evidence of the editorial workflow can be as important as the technical control.
Article 50(4) does not cover every public piece of AI-generated text. Product copy, support macros, code comments, and internal summaries are not automatically text published to inform the public on matters of public interest.
Articles 50(1) and 50(5): chatbot and first-contact disclosures
Article 50(1) requires systems intended to interact directly with natural persons to tell those people they are interacting with AI, unless that is obvious to a reasonably well-informed, observant, and circumspect person.
Do not rely on “obvious” unless the product experience makes it genuinely clear:
- A widget labelled “AI assistant” or “bot” is easier to justify.
- A support channel where a model responds under a human name with no disclosure is much harder to justify.
Article 50(5) defines timing and presentation. The information must be:
- Provided no later than the first interaction or exposure
- Clear
- Distinguishable
- Accessible
A disclosure buried in terms of service is not a first-interaction disclosure. A disclaimer that fails accessibility requirements is not accessible.
API implication: make disclosure part of the contract
If your API powers another team's chat UI, you cannot reliably deliver the user-facing disclosure yourself. Your API consumer owns that UI. But they can only implement disclosure consistently if your API tells them when a response is model-generated.
That is the core reason to add AI disclosure metadata to your API, as covered in adding AI disclosure to your own API.
For example, expose both the resolved model and disclosure metadata in the response:
{
"id": "msg_01HXYZ",
"output": "Here is the generated response.",
"model": "example-model-v2",
"ai_generated": true,
"disclosure": {
"required": true,
"message": "This response was generated by an AI system."
}
}
You can also expose an explicit response header:
X-AI-Generated: true
X-AI-Disclosure-Required: true
X-Resolved-Model: example-model-v2
The exact schema is a product decision. The key is to version, document, and test it like any other API guarantee.
Dates to track
August 2, 2026
Article 50 became applicable. This is the key date.
June 10, 2026
The Code of Practice on Transparency of AI-generated Content was published. The Commission and the AI Board confirmed it as an adequate voluntary tool for demonstrating compliance. Roughly 190 organisations had signed by the end of July, including Anthropic. Signing is voluntary; organisations that do not sign can be assessed individually by a market-surveillance authority.
December 2, 2026
This date has been widely reported as an extension for generative systems already on the market before August 2, 2026 to meet the Article 50(2) machine-readable marking requirement, through the AI Omnibus package provisionally agreed in May 2026. Treat this as a moving target and confirm the final text with counsel rather than planning against a headline.
Anthropic's transition fits within this window: Claude models launched on or after August 2, 2026 mark output at launch, while older models are being retrofitted. If your product pins an older model ID, track whether that retrofit has landed.
What non-compliance can cost
Article 50 breaches fall under the second penalty tier in Article 99:
- Up to €15 million
- Or 3% of total worldwide annual turnover for the preceding financial year
- Whichever is higher
For qualifying SMEs, the applicable amount is whichever is lower.
For comparison:
- Prohibited practices: up to €35 million or 7%
- Supplying misleading information to authorities: up to €7.5 million or 1%
Transparency is not the highest penalty tier, but 3% of global turnover is not a minor risk. Enforcement is handled through national market-surveillance authorities.
Turn Article 50 into engineering work
Legal teams decide applicability. API teams make those decisions durable in the product and delivery process.
1. Record your role for every system and surface
Create a lightweight inventory that answers:
| System or surface | Model owner | Your role | Relevant paragraphs | Owner |
|---|---|---|---|---|
| Customer-support chatbot | Third party | Deployer | 50(1), 50(5) | Product API team |
| Public AI-generated news summary | Third party | Deployer | 50(4), 50(5) | Publishing team |
| Internal JSON formatter | Your team | Provider | Assess 50(2) exemptions | Platform team |
Keep this near your architecture or service documentation. Update it when you rebrand a model, change providers, or introduce a new output surface.
2. Store marking status in model configuration
Mixed model fleets are normal during transitions. A cost-based fallback can silently change whether output comes from a marked or unmarked model.
Treat marking status as configuration:
models:
example-model-v2:
marks_output: true
marking_effective_from: "2026-08-02"
legacy-model-v1:
marks_output: false
marking_status: "retrofit_pending"
Resolve the chosen model at runtime and return it in a traceable field or header. Then assert it in tests. A fallback should not move traffic to a different marking state without a visible, failing build.
3. Define disclosure in OpenAPI
Do not leave disclosure entirely to a frontend banner. Banners do not help API consumers, integrations, or machine-to-machine workflows.
Add the field to your OpenAPI definition:
components:
schemas:
AIResponse:
type: object
required:
- output
- model
- ai_generated
- disclosure
properties:
output:
type: string
model:
type: string
ai_generated:
type: boolean
disclosure:
type: object
required:
- required
- message
properties:
required:
type: boolean
message:
type: string
If your endpoint can return model-generated content, make the disclosure behaviour explicit. Version changes to that field just as you would authentication, pagination, or error semantics.
4. Test disclosure on every model-output path
A disclosure field that disappears during a refactor is a compliance gap introduced by a merge. Test it as a contract guarantee.
At minimum, cover:
- Standard generated responses
- Cached generated responses
- Fallback-model responses
- Error responses that include generated content
- Streaming responses, if applicable
Example assertions:
pm.test("returns AI disclosure metadata", () => {
const body = pm.response.json();
pm.expect(body.ai_generated).to.eql(true);
pm.expect(body.disclosure.required).to.eql(true);
pm.expect(body.disclosure.message).to.be.a("string").and.not.empty;
});
pm.test("returns the resolved model", () => {
const body = pm.response.json();
pm.expect(body.model).to.be.a("string").and.not.empty;
});
Also validate the response against the OpenAPI schema. That prevents a field from quietly disappearing while endpoint-level tests still pass.
In Apidog, create a scenario that:
- Calls the endpoint that returns model output.
- Asserts the resolved model.
- Asserts the disclosure header and body field.
- Validates the response against the OpenAPI schema.
- Runs through
apidog-cliin CI.
Teams already running API tests in GitHub Actions can add these checks to the existing workflow. You can download Apidog to build and run the scenario.
For broader governance process guidance, see the essential API governance checklist and the best API governance tool for large teams.
FAQ
Does Article 50 apply if my company is not in the EU?
It can. The AI Act reaches providers placing systems on the EU market and, in defined circumstances, providers and deployers outside the EU whose system output is used in the EU. Incorporation location is not the only test.
My model provider marks output. Does that make my product compliant?
No. Provider marking under Article 50(2) is separate from deployer duties under Articles 50(1), 50(4), and 50(5). Assess what Article 50 requires for your own product and service.
Do I need to label every AI-generated text item I publish?
No. Article 50(4) is limited to text published to inform the public on matters of public interest. Even then, there is an exemption where the content received human review or editorial control and someone holds editorial responsibility.
Is a chatbot disclaimer in the terms of service enough?
No. Article 50(5) requires information no later than the first interaction, in a clear and distinguishable form.
What counts as a deepfake under Article 50(4)?
Generated or manipulated image, audio, or video that resembles real people, objects, places, or events and would falsely appear authentic. Artistic, satirical, and fictional works have a lighter disclosure obligation.
What are the fines?
Up to €15 million or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. For qualifying SMEs, whichever is lower.
Should we sign the Code of Practice?
It is voluntary and primarily aimed at providers. Signing provides a recognised route to demonstrating compliance. Not signing means an authority assesses your approach on its own merits. That is a legal decision rather than a technical one.
Takeaway
Article 50 is short. For most API teams, the practical scope is smaller than the legal text first suggests:
- Identify whether you are a provider, deployer, or both.
- Track which model IDs mark output and when that status changes.
- Expose AI disclosure metadata in your API contract.
- Test disclosure and resolved-model guarantees in CI.
You may not be responsible for embedding a watermark. You may still be responsible for telling users they are interacting with AI, disclosing relevant public-interest content, and doing so at the first interaction.
The difference between a policy and an engineering guarantee is a test that fails when the guarantee disappears.
Top comments (0)