Prohibited practicesArticle 5
2 Feb 2025The banned-uses list — social scoring, untargeted facial-image scraping, emotion inference in workplaces and schools, and the rest. Not deferred, and in force for over a year.
// regulatory_state
The deadline moved six days before it landed, and a great deal of published guidance never caught up. Here is what is actually in force, what was deferred, and — the part written for engineers rather than counsel — what each obligation means for code you have to write.
The Digital Omnibus on AI — Regulation (EU) 2026/1744 — was published in the Official Journal on 24 July 2026 and entered into force on 27 July, six days before the original deadline. It deferred standalone high-risk obligations to 2 December 2027 and high-risk AI embedded in regulated products to 2 August 2028.
What did take effect on 2 August 2026 is Article 50, the transparency regime — and that reaches far more teams than the high-risk rules ever would, because it applies to ordinary chatbots, agents and generated content rather than to a regulated category.
The banned-uses list — social scoring, untargeted facial-image scraping, emotion inference in workplaces and schools, and the rest. Not deferred, and in force for over a year.
Obligations on providers of general-purpose models: technical documentation, copyright policy, training-data summaries. If you fine-tune and distribute a model you may be a GPAI provider yourself.
Chatbot and agent disclosure, machine-readable marking of synthetic output, notice for emotion recognition and biometric categorisation, and visible deepfake labels. This is the one that applies to nearly everyone building with AI, and it was NOT deferred.
Deferred 16 months from the original 2 August 2026 date by the Digital Omnibus. Covers standalone high-risk uses such as employment, credit, education and essential services.
Deferred 12 months. Covers AI inside products already governed by EU product-safety law — medical devices, machinery, vehicles.
Four obligations, split between providers and deployers. Getting that split wrong is the most common mistake teams make here — if you build a product on someone else's model API you are typically a deployer of that model, and simultaneously the provider of the system you built on top of it.
Design and build it so a person is informed they are interacting with an AI system, unless that is obvious to a reasonably well-informed user.
// engineering consequence
A disclosure in the system prompt is not compliance — the model can be talked out of it. Put it in the interface: a persistent label on the surface, and a deterministic disclosure on session start that no prompt can suppress.
Mark outputs in a machine-readable format, detectable as artificially generated or manipulated. Solutions must be effective, interoperable, robust and reliable as far as is technically feasible.
// engineering consequence
This is the genuinely technical obligation. Recital 133 names watermarks, metadata, cryptographic provenance, logging and fingerprinting. C2PA Content Credentials — standardised as ISO/IEC 21694 — is the strongest fit for the machine-readable half.
Inform the people exposed to it that the system is operating, and process their data lawfully.
// engineering consequence
Note the overlap with Article 5 — emotion inference in workplaces and schools is prohibited outright, not merely subject to notice. Check the ban before designing the notice.
Disclose that the content is artificially generated or manipulated, through a label a person can understand without running a detection tool.
// engineering consequence
Two separate artefacts are needed: the machine-readable mark from the provider obligation, and a human-visible or audible label here. Embedded metadata alone does not satisfy this one — most social platforms strip it on upload anyway.
Article 50(2) requires generated output to be machine-readable and detectable as artificially generated, with solutions that are “effective, interoperable, robust and reliable as far as this is technically feasible.” It names an outcome, not a technology. Recital 133 lists the acceptable techniques: watermarks, metadata identification, cryptographic provenance methods, logging and fingerprinting — explicitly as things that may be combined.
The practical answer that has emerged is layered, because the associated Code of Practice states plainly that no single technique is sufficient on its own:
C2PA Content Credentials — tamper-evident, cryptographically signed provenance, standardised as ISO/IEC 21694. The strongest fit for the machine-readable requirement.
The durable layer. Metadata is fragile — most platforms strip it on upload — so a watermark is what survives the round trip through a social feed.
Evaluate only where the use case justifies the operational cost. It is the expensive option and rarely the first thing to reach for.
The marking duty and the deepfake labelling duty are two different artefacts, and satisfying one does not satisfy the other. Machine-readable provenance is for systems; the deepfake label has to be understandable by a person without running a detection tool. You need both, and they live in different layers of your stack.
An agent that interacts directly with people triggers Article 50(1), and the engineering consequence is sharper than the legal text suggests: a disclosure written into the system prompt is not a control. The model can be argued out of it. An agent that has been talked into denying it is an AI is a compliance failure, not a bug report — which means the disclosure belongs in deterministic code around the model, not inside it.
Agents acting on a person's behalf against third parties push the same question one layer outward: the merchant, the support desk or the API on the other end is also interacting with an AI. That is the same problem the agentic commerce protocols are trying to solve with signed mandates — proving what was authorized, by whom, and on what terms — and the audit trail you build for one is largely the audit trail you need for the other. See AI agent authentication for the identity and logging side of it.
| Breach | Fixed cap | Turnover |
|---|---|---|
| Prohibited practices (Article 5) | €35M | 7% |
| Most other breaches — including Article 50 | €15M | 3% |
| Supplying incorrect information | €7.5M | 1% |
Percentages are of total worldwide annual turnover for the preceding financial year, and for larger undertakings the applicable fine is whichever is higher. SMEs and start-ups get that inverted in their favour — the lower of the two. Enforcement runs through national competent authorities, not a single EU regulator.
No, and this is the single most common error in current guidance. The Digital Omnibus on AI — Regulation (EU) 2026/1744 — was published in the Official Journal on 24 July 2026 and entered into force on 27 July, six days before the original deadline. It deferred standalone high-risk obligations (Annex III) to 2 December 2027 and high-risk AI embedded in regulated products (Annex I) to 2 August 2028. What did take effect on 2 August 2026 is Article 50, the transparency regime. A great deal of published material was written before the deferral was finalised and still shows high-risk obligations as live — check the date on anything you read about this, including this page.
Three things, if you ship AI in or into the EU. The Article 5 prohibited-practices list has been in force since February 2025 and was never deferred. General-purpose AI provider obligations have applied since August 2025. And Article 50 transparency applies from 2 August 2026: telling people they are talking to an AI, marking synthetic output in a machine-readable way, giving notice for emotion recognition and biometric categorisation, and labelling deepfakes. Most teams building products on top of model APIs have no high-risk system at all and still land squarely inside Article 50.
It decides which obligations are yours, and most engineers guess wrong. A provider develops an AI system and places it on the market or puts it into service under its own name. A deployer uses one under its own authority. If you build a product on someone else's model API, you are typically a deployer of that model — but you may simultaneously be the provider of the system you built on top of it, which is what catches people out. Article 50 splits along this line: the marking obligations sit with providers of generative systems, while the deepfake and biometric disclosure obligations sit with deployers. Putting your name on a system, or substantially modifying one, can make you a provider.
The Act names an outcome, not a technology. Recital 133 lists watermarks, metadata identification, cryptographic methods for proving provenance, logging methods and fingerprinting as techniques that may be combined. In practice the emerging answer is layered, because the associated Code of Practice is explicit that no single technique suffices: signed, tamper-evident metadata in the C2PA Content Credentials format — standardised as ISO/IEC 21694 and backed by a large cross-industry membership — plus an imperceptible watermark for durability when metadata is stripped, with fingerprinting and registry lookups only where the use case justifies the operational cost. Metadata alone is fragile; most platforms strip it on upload, which is precisely why the durable layer matters.
If it interacts directly with people, yes — that is Article 50(1), and it applies unless the AI nature is obvious to a reasonably well-informed person. The engineering consequence is what matters: a disclosure written into the system prompt is not a control, because the model can be argued out of it, and a jailbroken agent that denies being an AI is a compliance failure rather than a bug report. Implement it deterministically in the surface around the model — a persistent interface label and a disclosure emitted on session start by code, not by the model. Agents acting on a person's behalf against third parties raise the same question one layer out: the third party is also interacting with an AI.
Article 50 breaches sit in the middle tier of Article 99: up to €15 million or 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. For context the tiers are €35 million or 7% for prohibited practices, €15 million or 3% for most other breaches including transparency, and €7.5 million or 1% for supplying incorrect information. SMEs and start-ups get the cap inverted in their favour — the lower of the fixed sum and the percentage, rather than the higher. Enforcement runs through national competent authorities rather than a single EU regulator.
It can. The Act reaches providers placing systems on the EU market regardless of where they are established, and extends to situations where the output produced by a system is used in the EU. A US company with EU users generally cannot treat this as somebody else's problem. Where exactly the line falls for a specific product is a legal question rather than an engineering one — the point here is that "we are not an EU company" is not by itself an answer.
Primary and named sources for every claim above, last checked August 21, 2026.
Provisional political agreement on the Digital Omnibus, 7 May 2026.
Deferral to 2 December 2027 (Annex III) and 2 August 2028 (Annex I).
Article 50 applicable and enforceable from 2 August 2026; not delayed.
The Commission’s own reading of the four Article 50 obligations.
Provider and deployer duties, including the 50(2) machine-readable marking wording.
Fine tiers, including the €15M / 3% band covering Article 50.
This is engineering guidance, not legal advice. It describes what the obligations mean for systems you build; whether a specific product is in scope, and what your organisation must do about it, is a question for counsel. Dates and deferrals in this area have already moved once — check the verification date above before relying on any of it.