All illustrations in this article are AI-generated conceptual images. They do not show a real product, compliance system or client environment.
Current as of 23 July 2026 · Engineering implementation guide · Not legal advice
Short answer
Article 50 of the EU AI Act starts applying on 2 August 2026. For product teams, the work is not one generic “AI label”. It depends on what the system does and whether your organisation is acting as a provider, a deployer, or both.
The practical minimum is to:
- inventory every AI-enabled user surface and generated-content flow;
- classify your role and the relevant Article 50 paragraph for each flow;
- show a clear, accessible disclosure from the start of an in-scope AI interaction;
- preserve machine-readable marking or provenance where Article 50(2) applies;
- add visible labels for in-scope deepfakes and certain public-interest text;
- record the decision, implementation version, tests and responsible owner.
The European Commission's Article 50 FAQ was updated on 20 July 2026. It is now specific enough for teams to translate the rules into product requirements. It is not a substitute for a legal scope decision, but waiting for another generic compliance memo is no longer a good engineering strategy.
What changes on 2 August — and what does not
The AI Act follows a phased timeline. Prohibited practices and AI-literacy obligations have already applied since February 2025, while obligations for general-purpose AI models started applying in August 2025. The Commission confirms that the transparency rules apply from August 2026.
This matters because “the AI Act deadline” is often presented as if every obligation for every AI system lands on the same day. That is inaccurate. Following the 2026 political agreement on the AI Omnibus, the Commission's current AI Act timeline lists later dates for certain high-risk systems.
Article 50 remains an immediate product concern. It covers specific transparency situations:
| Situation | Primary actor | Product obligation to investigate |
|---|---|---|
| An AI system directly interacts with a person | Provider | Inform the person that they are interacting with AI, unless this is obvious |
| A generative AI system produces synthetic audio, image, video or text | Provider | Make in-scope output machine-readably marked and detectable |
| Emotion recognition or biometric categorisation is used | Deployer | Inform people exposed to the system |
| Deepfakes or certain AI-generated public-interest text are published | Deployer | Provide a clear, visible or audible disclosure where the rule applies |
Do not turn this table into an automatic legal classification. A company can be a deployer in one flow and a provider in another. A SaaS team that integrates a third-party model into a product sold under its own name should not assume it is “only a customer of the model vendor”.
Step 1: build an AI surface inventory, not a vendor list
A list of OpenAI, Anthropic, Google or open-source models is not an AI inventory. Article 50 obligations attach to systems and uses, not merely to procurement records.
For each production flow, record:
- the user-facing purpose;
- who encounters or is affected by the AI output;
- whether there is a genuine two-way interaction;
- whether output is exposed to people or remains machine-to-machine;
- the organisation's provider/deployer role;
- the model, model version and upstream provider;
- output types: text, image, audio, video or structured data;
- where disclosure or provenance is introduced;
- who approves the classification and who owns the control;
- the production release that contains the measure.
This inventory should include less obvious surfaces: support assistants, AI search summaries, voice agents, avatar-based onboarding, content-generation features, internal tools that publish externally, and automated workflows that hand output to a human before publication.
The Commission's current guidance sets four cumulative criteria for the direct-interaction duty: the system qualifies as AI, supports a genuine two-way exchange, communicates directly rather than through a human intermediary, and interacts with natural persons. Background machine-to-machine systems are treated differently. That distinction is useful, but it must be made per flow rather than inferred from a feature name.
Step 2: make AI interaction disclosure part of the interface contract
For an in-scope chatbot, agent or avatar, a disclosure hidden in the privacy policy is not a product control. The Commission says people should be informed from the start of the first interaction, clearly, distinguishably and accessibly.
A defensible interface implementation has four properties:
It appears at the right moment. The disclosure is visible before or when the first AI response becomes part of the interaction. It is not shown only after consent, after the first generated answer or behind an information icon.
It says what matters. Plain language such as “You are chatting with an AI assistant” is usually more useful than a vague “smart support” badge. Add an explanation of limits or escalation where misunderstanding could affect a decision.
It survives every entry point. Test the embedded widget, full-page assistant, mobile layout, shared conversation link, restored session and accessibility mode. A correct desktop banner does not prove the control exists in the product.
It is versioned. Store the disclosure copy, locale, effective date, UI component version and release reference. If the message changes later, the team should be able to explain what users saw in a previous release.
The “obvious interaction” exception should not become a design shortcut. The Commission says it should be interpreted restrictively. If reasonable users could confuse a conversational surface with a person, disclose it.
Step 3: treat machine-readable marking as a pipeline property
Article 50(2) is not satisfied by adding “AI-generated” to a caption. Providers of in-scope generative systems must design outputs so that artificial generation or manipulation can be detected through effective, reliable, robust and interoperable machine-readable marking.
That requirement affects more than the model call:
generation → transformation → storage → export → CDN → download → re-upload
Metadata can disappear during resizing, transcoding, optimisation, screenshotting or export. If the product relies on an upstream provider's provenance signal, the team must verify that its own pipeline preserves it.
A useful test matrix covers:
- each output type and supported file format;
- original generation and edited variants;
- image optimisation and audio/video transcoding;
- browser download and API export;
- social or CMS publishing paths under your control;
- batch processing and retry;
- the final artefact delivered to the user.
The Commission guidance also describes exclusions and a narrow possible treatment for certain B2B or industrial contexts. Source code, some machine-to-machine output and assistive standard editing may be treated differently. Do not encode these as broad engineering exemptions. Record the exact rationale and get the classification reviewed.
Step 4: separate machine marking from visible labelling
Provider marking and deployer disclosure are different controls. The Commission explicitly notes that a deployer cannot rely only on an embedded machine-readable mark when a visible deepfake disclosure is required.
For in-scope deepfake content, disclosure should be understandable and perceivable without special tools, at first exposure at the latest. For text published to inform the public on matters of public interest, the Article 50 test includes the purpose, subject and whether meaningful human review or editorial control exists.
The current guidance says substantive human review is more than grammar correction. The reviewer must have relevant knowledge and the authority to approve, change or reject the substance. This creates a product and workflow requirement:
- assign a named editorial role;
- present the source material and generated draft;
- allow substantive edit/reject actions;
- record the version reviewed;
- store the approval and publication relationship;
- prevent an automated republish from bypassing the control.
“A person was somewhere in the loop” is not durable evidence of editorial responsibility.
Step 5: build an evidence record alongside the feature
Compliance evidence should not be reconstructed from Slack messages after a complaint or audit. For every material AI surface, keep a compact, versioned record:
| Evidence item | What it should prove |
|---|---|
| System and role decision | Which feature was assessed, by whom, under which provider/deployer role |
| Disclosure specification | Exact copy, locale, placement, timing and accessibility behaviour |
| Provenance specification | Marking method, supported formats and where the signal can be lost |
| Test evidence | Screenshots, automated checks and artefact inspection from the actual release |
| Editorial workflow | Who can review, reject and publish; what “reviewed” means in this context |
| Exception rationale | Exact scope, source and approval for any exclusion relied on |
| Release traceability | Commit, build, environment, deployment date and rollback owner |
| Monitoring and incidents | How missing labels, lost provenance or bypassed review are detected and corrected |
This evidence pack is also useful when a model or media provider changes. A provider migration is not complete if output quality looks similar but the provenance behaviour, disclosure contract or supported formats changed silently.
A rollout plan product teams can use now
1. Classify before changing UI
Inventory production AI surfaces, identify natural persons affected by each flow and record provider/deployer roles. Escalate uncertain, high-impact or biometric use cases to qualified counsel. Do not let the visual design of a feature decide its regulatory category.
2. Implement the smallest complete control
For each in-scope flow, ship the disclosure, marking preservation or visible label together with accessibility behaviour, locale coverage and error handling. Avoid a site-wide “AI may be used” banner that says nothing about the actual interaction.
3. Test the final artefact and every entry path
Verify the rendered user experience and inspect generated files after the full production pipeline. Test mobile, restored sessions, embeds, exports and content transformations. Record results against the exact release.
4. Give failures an owner
Define what happens when a provenance signal is missing, a third-party model changes behaviour, an editor bypasses review or a disclosure component fails to render. Depending on the risk, the safe response may be to block publication, disable export or fall back to a non-AI path.
5. Recheck before release
The Commission published its transparency code and guidelines close to the application date. Its Code of Practice FAQ says signing is voluntary; organisations that do not sign still need adequate alternative evidence. It also describes proposed transitional treatment for some pre-existing Article 50(2) systems. Do not assume that proposal covers your system without checking its final legal status and exact conditions.
Common implementation mistakes
“Our model provider handles compliance”
An upstream provider may supply marking or documentation. Your organisation still needs to classify its own role, preserve the control through its pipeline and meet deployer duties that apply to publication or use.
“The AI badge is in the settings”
The disclosure must meet the relevant timing and clarity requirements. A discoverable setting is not the same as informing someone from the start of an interaction.
“A human reviewed it”
Record who reviewed which version, what evidence they had and whether they could reject publication. A spelling pass or nominal approval is not substantive editorial control.
“The watermark exists in the original file”
Test the final delivered artefact. Image optimisation, video export and CMS processing can remove or alter machine-readable signals.
“The August deadline was delayed”
Some high-risk dates changed in the current implementation timeline. That does not justify treating Article 50 transparency obligations as generally postponed.
The practical engineering standard
A strong Article 50 implementation is not a compliance banner added before launch. It is a traceable system property:
classified use case → correct disclosure or marking → preserved through delivery → verified in the release → monitored after launch
Product, legal and engineering teams have different responsibilities, but they need one shared record. Legal owners decide how the rule applies to the use case. Product owners define the user-facing behaviour. Engineering makes the control reliable across interfaces, content pipelines and releases. Operations ensures it remains true after provider, model and workflow changes.
If you are reviewing an existing AI feature, start with the inventory and evidence gaps before redesigning it. If you are building a new one, make disclosure, provenance, review and evaluation part of the architecture rather than a pre-launch ticket.
H-Studio helps teams design and operate AI automation with explicit human control and build AI evals, observability and guardrails around production systems. If you need an engineering review of an existing AI workflow, send us the system context and current release stage.
Official sources checked
- European Commission: AI Act overview and application timeline
- European Commission: Transparency obligations under Article 50 of the AI Act
- European Commission: Signing the Code of Practice on Transparency of AI-generated Content
- EUR-Lex: Regulation (EU) 2024/1689
This article explains product and engineering implementation patterns. It is not legal advice, does not classify a specific system, and does not establish compliance. Check the current law, guidance, final implementation timeline and your organisation's role with qualified counsel before relying on an exemption or releasing a regulated flow.