Article 5(1a) of the AI Act: how far the new prohibitions reach providers

Article 5(1a) of the AI Act did not exist in June 2026. It was inserted by Article 1(7) of Regulation (EU) 2026/1744, the Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force since 27 July. It is a new, free-standing paragraph, and it is not Article 5(1), point (a), the prohibition on subliminal and deliberately manipulative techniques that has applied since 2 February 2025 and which the Omnibus left untouched. The numbering is unhelpfully close and the two provisions have nothing in common.

Paragraph 1a prohibits nothing on its own. It decides who the two new prohibitions in Article 5(1), points (ba) and (bb), actually reach, and it is drafted so that the answer extends well past the applications those prohibitions were written for. Both points apply from 2 December 2026 under Article 113 as amended, one of several dates the Omnibus rearranged across the AI Act calendar. Breach sits in the highest penalty tier under Article 99(3): up to EUR 35 million or 7% of total worldwide annual turnover, whichever is higher.

What points (ba) and (bb) prohibit

Point (ba) prohibits placing on the market, putting into service or using an AI system that generates or manipulates realistic images, videos, audio or similar material of an identifiable natural person's intimate parts, or of an identifiable natural person engaged in sexually explicit activities, absent that person's freely given, specific, informed, unambiguous and explicit consent to that generation or manipulation.

Point (bb) uses the same three verbs and covers material or performance within the meaning of Article 2, points (c) and (e), of Directive 2011/93/EU, except where a "without right" defence applies under national law. Recital 13 indicates what that defence is expected to cover: activity under domestic legal powers, including by authorities for criminal proceedings or for preventing, detecting or investigating crime, and legitimate use of a system in red-teaming and evaluation directed at assessing compliance with the prohibition itself. That last limb matters to any provider testing its own safeguards, with the caveat that the defence is a creature of national law and is not uniform across the twenty-seven.

Point (bb) adds little to the provider perimeter beyond point (ba), because the safeguards that take a general-purpose system outside one take it outside the other. The analytical work sits in point (ba), and paragraph 1a governs both. Note also what both points regulate: the system, through the acts of placing on the market, putting into service and use. Article 5 does not make material unlawful. Other instruments do that, and recital 15 preserves them.

Article 5(1a) and the closing clause

Paragraph 1a sets two independent tests, one for each side of the market.

For providers, placing on the market or putting into service is prohibited in two cases only. The first is where that generation or manipulation is the intended purpose of the system. The second is where the system's design, training, architecture, capabilities or user-facing functionalities make that generation or manipulation a "reasonably foreseeable and reproducible" outcome, without requiring significant technical modification, and the system lacks "reasonable and adequate" technical safety measures and other safeguards to reliably prevent it, taking reasonably foreseeable misuse into account, and to correct observed or reported misuse.

For deployers, use is prohibited only where the deployer uses the system for the purpose of generating or manipulating that material.

The second provider limb is the closing clause of the provision and the whole of its practical reach. The first limb catches the purpose-built application, and nobody building one is in any doubt about what they are building. The second reaches systems built for something else entirely.

It has four cumulative elements, each a factual question about the system rather than about how it is marketed: the sources of the capability, listed as design, training, architecture, capabilities and user-facing functionality; foreseeability and reproducibility of the outcome; the absence of any need for significant technical modification; and the adequacy of the safeguards. The last one carries the weight. A general-purpose image or video model will frequently satisfy the first three, since its architecture makes the outcome foreseeable, the outcome is reproducible, and obtaining it requires no significant modification. Everything then depends on the fourth. Whether a general-purpose image model sits inside or outside Article 5 on 2 December 2026 turns on whether its safeguards are reasonable and adequate, and on nothing else.

Recital 12 confirms the legislature knew exactly what it was doing here. The prohibition, it says, should not prevent providers from developing the technical capability of AI systems to generate or manipulate images, videos and audio. The capability is not the offence. The unguarded capability is.

Adequacy, not impossibility

The most tempting compliance position available here is also the weakest: that the system cannot produce the output at all. The text asks for nothing of the sort. It asks for measures that are reasonable and adequate, that reliably prevent the outcome with reasonably foreseeable misuse taken into account, and that correct observed or reported misuse.

Recital 12 sets the calibration. Measures count as adequate where they align with state-of-the-art measures and demonstrably prevent or sufficiently reduce, in the specific case, the likelihood of the material being generated, taking into account known and reasonably foreseeable misuse, including foreseeable circumvention of those measures without significant technical modification.

The difference between the two positions is the difference between a file that survives contact with evidence and one that does not. A claim of impossibility is falsified by a single successful red-teaming result, and every such claim eventually meets one. An adequacy position absorbs that result, because the provision contemplates it: the express requirement to correct observed or reported misuse presupposes that misuse will be observed. A provider that has documented its measures, tested them, recorded the failures and corrected them is describing precisely what the provision asks for. A provider that has asserted impossibility has, at the first counterexample, nothing left to say. Recital 14 makes the same point in the proportionality analysis, noting that for systems not intended to generate the prohibited material the prohibition requires no more than reasonable and adequate measures.

Release strategy is the decisive variable

Suppressing the capability outright is not the only compliant route, and recital 12 does not present it as one. It sets out a graduated range of measures: data cleaning, refusal training, safe prompt design and output controls, runtime prompt guardrails, content classification and filtering, usage restrictions, abuse detection, and notice and action mechanisms. For providers retaining effective control over the system, through a platform or web interface, it contemplates methods for following up and reporting misuse cases in full compliance with Union privacy and data protection law.

What decides which combination is adequate is stated in the same recital: corrective measures must be reasonable for the specific system, including its release and distribution strategy, with open-source releases given as the express example.

That clause carries a great deal. Publishing open weights and serving the same model through an API subject to terms of use, registration and abuse detection are materially different legal positions under an identical legal test. The API operator retains effective control and can rest a substantial part of its adequacy case on runtime and post-hoc measures. The operator publishing weights retains none of that control, and its case has to be made almost entirely at the level of the artefact, before release. The provision does not prohibit open release. It does mean the two strategies cannot borrow each other's compliance arguments, and a provider that has moved between distribution models without revisiting its safeguards has a gap where its reasoning should be.

The providers who do not know they are providers

The foundation model provider reading this already has counsel. The party most likely to be caught unprepared sits further down the stack, and often does not think of itself as a provider at all. Four positions deserve attention.

• The operator fine-tuning a third-party model and reclassified as a provider under Article 25 of the AI Act, which is the most common route into the full set of provider obligations for a company that never trained a model.
• The avatar, portrait or image-editing platform built on someone else's weights.
• The audiovisual content SaaS shipping generation or editing features.
• The white-label operator running a third-party API under its own brand.

Each of these puts the operator on the market side of the provision. Paragraph 1a attaches to whoever places the system on the market or puts it into service, which is a question about market position rather than about who trained the weights.

Two scoping points follow. Multimodal systems are caught through their image, video or audio capability, not through their text capability. And synthetic voice systems fall within point (ba) where the output depicts an identifiable person: recital 12 states that the required realism refers to depicting the person's face, voice or body in a credible real-life manner, regardless of whether the output fully corresponds to the actual voice or appearance of the person depicted. Where identifiability would rest on vocal timbre alone, the position is unsettled, and better named than resolved on current materials.

One further point on supervision. Under Article 75(1) as rewritten by the Omnibus, the AI Office holds exclusive competence over AI systems built on general-purpose AI models where the model and the system come from the same provider or from providers forming part of the same undertaking. A group that trains its own model and ships systems on top of it answers to the AI Office on this prohibition rather than to a national market surveillance authority.

Identifiability and consent are real limits

Point (ba) turns on two conditions: an identifiable natural person, and the absence of explicit consent. Both operate as genuine boundaries, and both are routinely overstated in the other direction.

The provision does not prohibit the generation of sexual content. The operative word is "identifiable". Recital 12 confirms that the prohibition does not affect material that does not depict identifiable natural persons, realistic partially nude depictions where intimate parts are not exposed and no sexually explicit activity is shown, or non-realistic artistic nude work. Cartoonish or physically impossible depictions fall outside the realism requirement, as do applications where intimate parts are not exposed or where exposure rests on the depicted person's consent, with try-on and medical applications given as examples.

The consent limb works the same way. An operator holding documented, verifiable, individual consent from the depicted person is outside point (ba) on the provision's own terms. Recital 12 is specific about what a system intended for such generation must therefore include: means of distribution enabling the reliable collection and demonstration of the depicted person's consent, in compliance with the GDPR. The standard is the GDPR standard, individual and specific to the generation in question. No collective, intermediated or terms-of-service arrangement satisfies it.

Two qualifications belong here. The new Article 5(1b) provides that manipulation which neither increases the exposure of depicted intimate parts nor alters the nature of depicted sexually explicit activity is not manipulation for the purposes of point (ba); recital 12 offers background changes, added headings and contrast adjustment as examples, and confirms that anything increasing exposure or altering the nature of the activity is inside. More importantly, none of this reaches point (bb). There, consent is legally irrelevant and no identifiability threshold applies. Safeguards calibrated only to the point (ba) carve-outs will not answer point (bb), and a compliance file that treats the two prohibitions as one exercise will fail on the second.

Two things that do not apply are worth stating, because both get asked. There is no FRIA here: the fundamental rights impact assessment is Article 27, it falls on deployers, it is confined to public bodies, private entities providing public services and deployers of Annex III, point 5(b) and (c) systems, it belongs to the high-risk regime the Omnibus deferred to 2 December 2027, and it has no application to Article 5. And there is no notification duty. Article 5 creates no registration or notification obligation to any authority; market surveillance appears on inspection or enforcement, not before.

What a provider should have documented before 2 December 2026

The date functions as a documentation deadline more than an engineering one. The question an authority puts to a provider will not be whether the output can be produced. It will be what the provider knew, what it did about it, and what it can show.

Four components make that answerable. A capability assessment recording whether the outcome is reasonably foreseeable and reproducible on the system as released, and the basis for that conclusion. A safeguards inventory mapping measures in place against the categories the recital contemplates, with the reasoning for the combination chosen. An adequacy record: testing performed, results including the failures, corrective action taken, all dated. And a distribution rationale explaining why those measures are reasonable for the release strategy actually in use, which is the element most likely to be tested wherever weights are published. Building that file is part of the provider's technical documentation rather than a separate content policy exercise, and it is considerably cheaper to assemble now than to reconstruct under a request for information.

The allocation of responsibility between provider and deployer belongs in the contract, and it should be settled there rather than assumed. Paragraph 1a does not shift liability downstream. The two tests are independent and both parties can be caught at once. A provider with inadequate safeguards stays inside the prohibition whatever its deployers do, and recital 12 says as much from the other direction: a deployer using a lawful system for lawful purposes is outside the prohibition even where the system lacks the safeguards the provider should have put in place. Contract can allocate the commercial consequences between the parties. It cannot move the prohibition.

If your situation calls for it, you can book a virtual consultation here (€90, deducted from your first invoice if we take on your matter).