EU AI Act Article 50: Build the Evidence Log Before You Decide You Are Out of Scope

Four duties, not one

Purpose and scope: Article 50 transparency only

The decision is not whether your business should build a full EU AI Act compliance programme tomorrow. The narrower decision is whether you should build an internal evidence log and a “who must do what” workflow for Article 50 transparency obligations.

For an owner-operator in the Middle East, the starting point is simple: do not assume that being outside the EU ends the question. CMS states that the EU AI Act is extraterritorial and can apply to businesses outside the EU, including where providers place AI systems or general-purpose AI models on the EU market, or where providers and deployers outside the EU produce AI-system output that is used in the EU.

That does not mean every use of AI in the region is automatically caught. It means your workflow should first decide whether your activity has an EU-facing branch, then decide whether you are acting as a provider, deployer, or both, and only then map the Article 50 transparency timing.

This article is deliberately limited to Article 50 transparency duties. It is not a full high-risk AI system workflow, and it is not an analysis for anyone who provides a general-purpose AI model.

The first branch: provider, deployer, or both

Article 50 distinguishes between providers and deployers. The obligations attach differently to those roles: Article 50(2) as a provider-side technical-marking obligation, and Article 50(4) as relevant to employers/deployers for certain deepfake or AI-generated public-interest publications. The workflow should therefore collect role-specific facts rather than treating transparency as a single duty owned by whoever uses the system.

For provider review, record the system involved, where it is made available, and, where relevant, whether it is offered under your own name or trade mark. Those are practical facts to put in front of legal review when assessing EU-facing scope and provider-side Article 50 duties. Because deployer duties turn on use, exposure, publication context, and EU-facing output, a deployer-side record should identify the system used, the business process it supports, who is exposed to or receives the output, and whether any output is used in the EU.

Do not reduce this to a staff title. A business can be a deployer in one workflow and a provider in another. Using a third-party AI tool internally is not the same operational posture as packaging an AI-enabled service for customers. The exact legal classification should be checked against the Commission guidance and the official EUR-Lex text, but your internal workflow can still force the right facts to be collected before legal review.

The date branch: 2 August 2026, then 2 December 2026 for Article 50(2)

For Article 50, the important date is 2 August 2026. That is the Regulation’s own general application date under Article 113, and none of the three exceptions listed there covers the transparency chapter. DLA Piper adds that the European Commission confirmed enforcement from that date for the new transparency requirements.

There is also a narrower transitional point, and it is narrower than it first appears. Article 111(4) gives providers of AI systems that generate synthetic audio, image, video or text content, where those systems were placed on the market before 2 August 2026, until 2 December 2026 to comply with Article 50(2). It is a provider-side reprieve for synthetic-content systems, not a general grace period for everything already in use. That paragraph was added by Regulation (EU) 2026/1744, so it does not appear in the original 2024 text of the Act — which is worth knowing if you are reading a copy that predates it.

That means your internal workflow should not just ask, “Do we use AI?” It should ask what the system is, whether you are provider, deployer, or both, whether the system was already placed on the market before 2 August 2026, and — if it generates synthetic content and you are its provider — whether the Article 50(2) transition to 2 December 2026 reaches you.

This keeps the decision tied to the actual dates and roles, not to a vague AI policy discussion.

The four Article 50 branches: do not assign the wrong owner

One common mistake is to treat transparency as a single duty owned by whoever uses the system. The Article 50 split is more precise.

Article 50 sets out four branch-specific transparency obligations in paragraphs 1 to 4: Article 50(1) covers systems intended to interact directly with people, Article 50(2) covers systems that generate synthetic audio, image, video or text, Article 50(3) covers emotion recognition and biometric categorisation, and Article 50(4) covers deepfakes and certain AI-generated public-interest publications.

Article 50(1) sits with the provider. If you are the provider of a system intended to interact directly with people — a chatbot, a voice agent, an automated booking line — the people using it have to be told they are dealing with an AI system, unless that is already obvious to a reasonably well-informed and observant person in the circumstances. The judgement call is what counts as obvious, so record the reasoning rather than assuming it.

Article 50(3) sits with the deployer, and it is the one an operator is most likely to trip over without noticing. If you run an emotion recognition or biometric categorisation system, you must inform the people exposed to it. The log should not treat this as a deepfake-only issue; it should ask directly whether anyone is exposed to emotion recognition or biometric categorisation.

DLA Piper states that Article 50(2) is primarily a provider-side technical-marking obligation. For an operator, that means a deployer using someone else’s system should not automatically assume it owns the technical marking work. The practical file can identify the provider, keep the provider’s information about machine-readable marking and detection, and record whether the system was placed on the market before 2 August 2026 if the Article 50(2) transition could matter. The duty also has a limit worth writing down: it does not apply to the extent the system only performs an assistive function for standard editing, or does not substantially alter the input or its meaning. A business using AI to tidy up its own copy may be on the right side of that line, but the file should say why.

Article 50(4) is different. DLA Piper states that it is directly relevant to employers and concerns labelling deepfakes and AI-generated publications intended to inform the public on matters of public interest where no human editorial control has been exercised. For a business, that points to a practical question: are you publishing AI-generated or manipulated content externally, and is it intended to inform the public on a matter of public interest?

If the answer may be yes, the evidence log should capture the content type, audience, publication channel, editorial-control process, and labelling decision.

The internal evidence log: keep it small, but make it decision-grade

A useful Article 50 evidence log does not need to become a legal encyclopaedia. It should be a table that lets an owner, operations manager, and lawyer see the same facts.

Use these fields:

• System name and vendor or internal owner.
• Business process using the system.
• EU-facing trigger considered: placed on EU market, output used in the EU, EU importer/distributor involvement, or no identified EU-facing branch.
• Role conclusion: provider, deployer, or both.
• Evidence for that role conclusion.
• Placement-on-market timing: before or after 2 August 2026, if applicable.
• Article 50(1) relevance: does the system interact directly with people, are you its provider, what tells them they are dealing with an AI, and — if you are relying on it being obvious — why.
• Article 50(2) relevance: does it generate synthetic audio, image, video or text; what the provider says about machine-readable marking and detection; whether the assistive-editing limit applies; and the Article 111(4) timing if it was on the market before 2 August 2026.
• Article 50(3) relevance: emotion recognition or biometric categorisation, who is exposed to it, and how they are informed.
• Article 50(4) relevance: deepfake or qualifying public-interest text, who holds editorial responsibility for it, and the labelling decision.
• Disclosure timing and form: what the person is actually told, evidence that they are told clearly and distinguishably at or before the first interaction or exposure, and whether applicable accessibility requirements are met.
• Guidance checked: Commission transparency guidelines, Code of Practice on Transparency of AI-Generated Content, and official EUR-Lex text.
• Owner and next review date.

This log is not a substitute for legal advice. Its value is operational: it stops the company from rediscovering the same facts every time the Article 50 question comes back.

Where this stops: providing a general-purpose AI model

Everything above assumes you are a provider or deployer of an AI system under Article 50. If your business actually provides a general-purpose AI model — not uses one, provides one — treat that as a separate workstream. Commission and AI Act Service Desk materials set out distinct rules for general-purpose AI model providers, including systemic-risk classification criteria, application dates, and notification requirements for models with systemic risk. That is a separate analysis and it does not belong inside an Article 50 transparency file.

If your business only deploys models built by someone else, record that conclusion and the reason for it in the log, and move on.

External guidance to attach to the workflow

Point the team to the Commission guidelines on transparency obligations for providers and deployers of AI systems. Also attach the European Commission’s Code of Practice on Transparency of AI-Generated Content, while remembering that signing a code and meeting a legal obligation are not the same thing; DLA Piper notes that the Code is voluntary to sign while the underlying Article 50 transparency obligations remain mandatory.

For legal specifics, use the official EUR-Lex text. The AI Act Service Desk links to EUR-Lex for the official text, and its summaries are helpful orientation rather than the legal source to rely on for final interpretation.

The AI Office also has tools for individuals and businesses to report suspected non-compliance. That matters operationally because transparency failures are not only internal governance issues; they can become externally visible.

A practical 30–60 day implementation plan

In the first pass, do not try to classify every theoretical AI risk. Build the Article 50 file.

Assign one owner for the AI system inventory. Ask each department to list AI systems used in customer service, marketing, content generation, HR, operations, and product delivery. For each system, record whether any output is used in the EU or whether the system or model is made available in the EU.

Then assign role mapping: provider, deployer, or both. Where the answer is uncertain, mark it uncertain and attach the facts that make it uncertain. Do not guess silently.

Then run all four Article 50 branches against every system on the list — 50(1) direct interaction, 50(2) synthetic content, 50(3) emotion or biometric categorisation, 50(4) deepfakes and public-interest text — and record “not applicable” with a reason rather than leaving a branch blank. A blank is indistinguishable from a branch nobody checked.

Next, run the date branch. For each system, record whether placement before 2 August 2026 is relevant and whether the Article 50(2) transition to 2 December 2026 may apply.

Finally, write down whether your business provides a general-purpose AI model at all. Recording the answer, and the reason for it, takes a line. If the answer is yes, stop and get that assessed separately; it is not an Article 50 question.

After one pass, you should have three artifacts: a system list, a role map, and a date-and-transition table. That is the minimum Article 50 evidence base an operator in the Middle East can build now without pretending to have solved the whole EU AI Act.