The New CSAM and Non-Consensual Imagery Prohibition: What the December 2026 Article 5 Addition Bans

Most of the Digital Omnibus coverage has been about relief — deadlines pushed, obligations softened. Buried in the same package is the opposite: a new, absolute prohibition that takes effect on 2 December 2026 and that no risk-acceptance memo can make go away.

The Digital Omnibus on AI, which the co-legislators settled in mid-2026, is remembered mostly for delaying the high-risk regime. It did something else at the same time. It added two new entries to Article 5 of the AI Act — the list of prohibited practices — banning AI systems that generate or manipulate child sexual abuse material (CSAM) and non-consensual intimate imagery of identifiable people. Unlike almost everything else in the omnibus, these bans were not deferred. They apply from 2 December 2026. If you run, host, fine-tune or expose a generative image or video model, this is not a compliance obligation you plan around. It is a line you are not allowed to cross.

What the addition actually bans

The first new prohibition covers AI systems that generate or manipulate realistic depictions of an identifiable person’s intimate parts or sexually explicit conduct without that person’s freely given, specific, informed, unambiguous and explicit consent. This is the “nudify” and deepfake-pornography case, written into the Act’s most serious tier. The consent standard is deliberately high — it borrows the language the GDPR uses for the most sensitive processing — and “identifiable” is the operative word: a synthetic likeness of a real, recognisable person is what the ban reaches, not an invented character.

The second prohibition is a parallel one for AI systems that generate or manipulate CSAM, subject only to a narrow carve-out where a “without right” defence applies under national law — the kind of exemption that lets law-enforcement and vetted research handle such material lawfully. For any commercial deployment, there is no exemption to reach for. The material is illegal to produce, and now the tool that produces it is illegal to place on the market or use for that purpose.

Sitting in Article 5 matters, because Article 5 carries the Act’s heaviest penalty tier: administrative fines of up to 35 million euro or 7% of total worldwide annual turnover, whichever is higher. That is the same exposure as running a banned social-scoring or manipulative system. The regulator does not have to prove harm to a data subject or walk through a risk-management deficiency. The practice itself is the infringement.

Where the duty lands: provider versus deployer

The interesting engineering question is not “is this banned” — it plainly is — but “when am I on the hook for a model I did not build.” The addition draws the line differently for providers and deployers, and the difference decides where your controls have to sit.

A provider is caught in two situations. The first is obvious: generating this material is the system’s intended purpose — you built a nudifier. The second is the one that catches ordinary generative products. A provider is also caught where producing the banned output is a reasonably foreseeable and reproducible outcome, without significant technical modification, and the provider has not implemented reasonable and adequate technical safety measures to prevent it. Read that clause slowly. If a user can reliably coax banned output out of your model with ordinary prompting — no jailbreak toolkit, no weight surgery — and your filters do not stop it, the foreseeability limb is met and the absence of guardrails is the violation. You do not have to intend the output. You have to have failed to reasonably prevent it.

Deployers get a narrower test. A deployer breaches the prohibition where it intentionally uses a system to generate the banned material — including by circumventing the provider’s safety measures or misusing an otherwise lawful system. Accidental generation is expressly excluded on the deployer side. So if you integrate a third-party image model into your product, your primary risk is not a stray output; it is a workflow, a prompt template, or a fine-tune that steers the system toward the banned result, or a decision to strip out the safety layer to “reduce false refusals.” That last one is the trap. Turning down a provider’s filters to improve usability can convert a lawful integration into a prohibited use.

The controls that actually evidence compliance

“Reasonable and adequate technical safety measures” is the phrase a supervisor will test, and it is not satisfied by a policy document. For a generative image or video deployment, the concrete layers are:

• Input filtering. Prompt classification that blocks requests for intimate imagery of real people and any CSAM-adjacent request before generation, including obfuscated and multilingual phrasings, not just an English blocklist.
• Refusal training and output filtering. Model-level refusal behaviour backed by a downstream classifier on the generated frame or clip, so that a prompt that slips through input filtering is still caught at the output. The two layers exist because neither is sufficient alone.
• Identity-grounding controls. Restrictions on image-to-image and face-conditioning paths, which are the route by which “realistic depiction of an identifiable person” is actually produced from an uploaded photo.
• Tamper-evident logging. Records of blocked and flagged requests, retained long enough to show the filters were live and operating — the evidence that your guardrails are real, not aspirational.

Filters you have never adversarially tested are filters you cannot claim work. The same discipline the Act’s accuracy, robustness and cybersecurity requirements demand of high-risk systems is the right standard here too: red-team the blocked categories, keep the test set, and keep the results. And the logging is not optional housekeeping — the retention and tamper-evidence expectations already familiar from the Act’s automatic-logging duties are what let you prove, months later, that the guardrail was operating on the day in question.

Provenance is the other half

The prohibition does not sit on its own. It shares a 2 December 2026 date with the Act’s marking-and-detection duties for synthetic media, and the two are meant to work together: prevention at the point of generation, and machine-readable provenance on whatever is generated. If you are building the filtering layer, build the synthetic-content marking pipeline in the same programme of work rather than as a separate project — they touch the same generation path and the same logs. Treating them as one workstream is how you avoid instrumenting the pipeline twice.

What to do before December

Three things, in order. Inventory every generative image or video capability you provide or embed — including the ones a product team stood up on a hosted API without telling anyone. For each, decide whether you are provider or deployer, because the test that applies to you turns on that. Then adversarially probe the safety filters against the two banned categories and keep the evidence, because “we assumed the vendor handled it” is not a defence the foreseeability limb leaves open to you.

The rest of the Digital Omnibus gave technology functions time. This part gave them a wall. And unlike the deferred obligations, where the extra months are a chance to do the work properly, there is nothing to phase here. On 2 December 2026 the filter either blocks the banned output or it does not — and a supervisor gets to find out which by typing the prompt.