A screen against the EU AI Act prohibited AI practices has to settle three questions for each use case before launch: which point of Article 5(1) could attach, at which lifecycle trigger it attaches (placing on the market, putting into service or use), and whether the organisation acts as provider, deployer or both. The remainder of a launch checklist, including the records behind it, follows from those answers.
Two Layers of Article 5, One Set of Guidelines
The text of Article 5 now has two layers. Points (a) to (h) of Article 5(1) have applied since 2 February 2025. Points (ba) and (bb) and paragraphs 1a and 1b, inserted by Regulation (EU) 2026/1744, apply from 2 December 2026 under Article 113(a) as amended.
The Commission Guidelines on prohibited artificial intelligence practices carry the reference C(2025) 5052 final and are dated 29 July 2025. Paragraph 5 of the Guidelines states that they are non-binding and that authoritative interpretation rests with the Court of Justice of the European Union; the Commission’s publication page says the same. Regulation (EU) 2026/1744 is dated 8 July 2026, so the Guidelines pre-date it and contain no interpretation of points (ba) and (bb) or paragraphs 1a and 1b.
Published sources count the prohibitions inconsistently, some as eight and some as nine, and the new text adds two lettered points. This article therefore cites each prohibition by its point in Article 5(1).
Which Prohibition Attaches at Which Launch Trigger

The wording of Article 5(1) does not give every point the same triggers. Points (a), (b), (c), (ba) and (bb) prohibit placing on the market, putting into service or use. Points (d), (e), (f) and (g) prohibit placing on the market, putting into service “for this specific purpose”, or use. Point (h) prohibits use only. The table sets this out and adds an editorial suggestion for where in a launch process each point is best screened.
| Article 5(1) point | Subject | Triggers in the text | Screening gate (editorial) |
|---|---|---|---|
| (a) | Subliminal, purposefully manipulative or deceptive techniques | Placing on the market, putting into service, use | Design review and pre-release behaviour testing |
| (b) | Exploitation of vulnerabilities due to age, disability or a specific social or economic situation | Placing on the market, putting into service, use | Audience definition and design review |
| (ba), from 2 December 2026 | Intimate or sexually explicit material of an identifiable person without explicit consent | Placing on the market, putting into service, use, narrowed by paragraph 1a | Capability and safeguards review before release; deployer purpose check |
| (bb), from 2 December 2026 | Material or performance within Article 2, points (c) and (e), of Directive 2011/93/EU | Placing on the market, putting into service, use, narrowed by paragraph 1a | Capability and safeguards review before release; deployer purpose check |
| (c) | Social scoring | Placing on the market, putting into service, use | Use-case definition and data-source review |
| (d) | Criminal-offence risk assessment based solely on profiling or personality traits | Placing on the market, putting into service for this specific purpose, use | Intended-purpose statement and customer screening |
| (e) | Untargeted scraping of facial images to build or expand facial recognition databases | Placing on the market, putting into service for this specific purpose, use | Data acquisition review |
| (f) | Emotion inference in the workplace and education institutions | Placing on the market, putting into service for this specific purpose, use | Procurement, configuration and deployment-context review |
| (g) | Biometric categorisation to infer sensitive characteristics | Placing on the market, putting into service for this specific purpose, use | Feature and intended-purpose review |
| (h) | Real-time remote biometric identification in publicly accessible spaces for law enforcement | Use only | Customer and deployment-context check for law-enforcement use |
Paragraphs 12 to 14 of the Guidelines define the triggers. Placing on the market covers supply by API, cloud access, download or embedding in a physical product. Putting into service covers supply for first use and in-house development and deployment. “Use” extends across the lifecycle after placing on the market or putting into service and, for Article 5 purposes, includes any misuse, foreseeable or not, that may amount to a prohibited practice. The Guidelines illustrate the last point with an employer inferring emotions in the workplace: the prohibition applies to the deployer even where the provider’s terms of use excluded that use.
Two consequences follow, offered here as analysis. Terms of use alone do not close a deployer’s exposure under Article 5. An organisation that builds a system for its own use reaches the putting-into-service trigger at first internal use, so no customer-facing release event exists to hang the screen on; the gate has to sit earlier, at the point where internal deployment is approved.
Paragraphs 39 to 41 of the Guidelines add that the prohibitions apply to general-purpose systems as well as systems with an intended purpose. Deployers are expected not to bypass safeguards built in by providers, and providers are expected to take effective and verifiable safeguards where misuse is reasonably foreseeable and to exclude prohibited uses in their terms. For prohibitions tied to a very specific purpose, which the Guidelines identify as points (d) to (h), paragraph 41 says providers may have limited technical options and will rely primarily on instructions for use and restrictions on prohibited use. Their example is a general-purpose system able to infer emotions, which deployers should not use in workplaces or education institutions outside the medical or safety exception.
Scope Gates That Close Before Launch
Article 2 removes some activities from the Act, and the Guidelines (paragraphs 22 to 36) explain how far each exclusion reaches. Several of them read differently once Article 5 is the question.
- Article 2(8) excludes research, testing and development before an AI system is placed on the market or put into service, but not testing in real-world conditions. Paragraph 32 of the Guidelines gives the example of a municipality testing a remote biometric identification system on volunteers during a carnival: the test must comply with the Act unless it runs in a sandbox or under the real-world testing regime of Articles 60 and 61.
- Article 2(6) excludes systems and models, including their outputs, specifically developed and put into service for the sole purpose of scientific research and development.
- Article 2(12) exempts free and open-source systems except where they are placed on the market or put into service as high-risk systems or as systems falling under Article 5 or Article 50. Paragraph 36 of the Guidelines draws the conclusion that providers cannot use the exclusion for a prohibited practice.
- Article 2(3) excludes systems used exclusively for military, defence or national security purposes. Paragraphs 24 and 25 of the Guidelines state that a system also placed on the market or put into service for a civilian or law-enforcement purpose falls within scope.
- Article 2(1)(c) brings in providers and deployers established in a third country where the output of the system is used in the Union.
For a launch screen, the useful reading is positional: the research exclusion ends where real-world testing begins. A pilot that meets the definition of testing in real-world conditions (paragraph 32 and footnote 26 of the Guidelines refer to Article 3(57)) needs its Article 5 screen before the pilot, not before general availability.
Role Determination and Ownership of the Gate
Paragraphs 16 to 19 of the Guidelines treat an operator that develops a system and then uses it as both provider and deployer. A legal person also remains a deployer when contractors or external staff operate the system on its behalf under its control. Paragraph 20 describes compliance with the Act as continuous across the lifecycle, so a role recorded at launch needs revisiting when the system or its context changes.
Which function signs off the screen is a structural decision. AIGovernanceDesk’s comparison of centralized, federated and hybrid AI governance operating models covers how that ownership can be allocated for EU AI Act duties.
Screening Article 5(1)(a) to (h) Against the Use Case
Manipulation and exploitation under points (a) and (b)
The Guidelines break point (a) into four cumulative conditions (paragraph 60): a placing on the market, putting into service or use; a subliminal, purposefully manipulative or deceptive technique; the objective or effect of materially distorting behaviour; and significant harm, or reasonable likelihood of it. Point (b) follows the same structure with an exploited vulnerability due to age, disability or a specific social or economic situation in place of the technique (paragraphs 98 and 99). A screen that finds one condition missing, and records why, produces a more useful file than a bare “not applicable”.
Three passages of the Guidelines matter for product teams. Paragraph 69 states that the prohibition covers manipulation by the system itself without a human intending it, for example techniques learned from training data or from reinforcement learning from human feedback. Paragraph 78 places lawful persuasion outside the prohibition. Paragraph 73 treats a generative system that incidentally hallucinates as not necessarily deploying deceptive techniques, where users were informed of its limitations, safeguards were integrated, and the system is not intended for or deployed in sensitive contexts such as health, education or elections. Paragraph 95 lists measures providers and deployers are encouraged to take: transparency and user control, compliance with other applicable legislation, and adherence to state-of-the-art practice and industry standards.
The Guidelines illustrate these conditions with examples, which paragraph 7 describes as indicative and without prejudice to the case-by-case assessment each situation requires. The table maps the examples that bear most directly on a product launch to the point and condition each one illustrates.
| Example in the Guidelines | Point | What the example illustrates | Paragraph |
|---|---|---|---|
| A chatbot that impersonates a friend or relative with a synthetic voice and pretends to be that person, causing scams and significant harm | (a) | A deceptive technique deployed by the system | 73 |
| A generative system that incidentally presents false information and hallucinates | (a) | May not amount to a deceptive technique where users were informed of the system’s limitations, safeguards were integrated, and the system is not intended for or deployed in sensitive contexts such as health, education or elections | 73 |
| A well-being chatbot that exploits individual vulnerabilities to steer users toward dangerous activity, such as excessive exercise without rest or water | (a) | Material distortion by effect without provider intent; the Guidelines state that capability to impair autonomy in a significantly harmful way, without appropriate preventive and mitigating measures, suffices | 84 |
| An AI companionship application using anthropomorphic features and emotional cues to make users emotionally dependent and to encourage addiction-like behaviour | (a) | Psychological harm as a type of significant harm | 88 |
| A chatbot that offers fraudulent products causing significant financial harm | (a) | Financial and economic harm as a type of significant harm | 89 |
| A general-purpose system able to infer emotions, used by a deployer in a workplace or education institution | (f) | A provider may not know the deployment context; it can exclude the use in its terms and instructions and is expected to act if it learns of misuse | 41 |
Read together, the examples show where a screening record earns its place. The wellbeing-chatbot example makes the absence of provider intent irrelevant where harm is reasonably likely and mitigation is missing, and the hallucination example makes documented limitations, safeguards and context part of the finding. A record that captures documented limitations, safeguards and deployment context for a feature gives a reviewer the same variables the Guidelines use.
Scoring and criminal-offence prediction under points (c) and (d)
Point (c) requires evaluation or classification of persons over a period of time based on social behaviour or personality characteristics, with a social score leading to detrimental treatment in unrelated social contexts or treatment unjustified or disproportionate to the behaviour. The Guidelines’ table of contents confirms the prohibition applies whether the system is provided or used by public or private persons (section 4.2.3). A Covington summary of the Guidelines notes that the Guidelines treat profiling as a form of evaluation and describe legitimate scoring in line with Union and national law, such as certain credit scoring, as outside the prohibition.
Point (d) is limited to risk assessments of natural persons based solely on profiling or personality traits and characteristics, and its text excludes systems supporting a human assessment already based on objective and verifiable facts directly linked to a criminal activity. For a launch screen, the practical record is the intended-purpose statement and the customer segments to whom the system is supplied, since the trigger for this point includes putting into service for this specific purpose.
Biometric points (e) to (h)
Point (e) addresses untargeted scraping of facial images from the internet or CCTV footage to create or expand facial recognition databases. The Covington summary reports that the Guidelines treat databases not used for the recognition of persons, such as sets used for model training or testing where persons are not identified, as outside the prohibition.
Point (f) prohibits inferring emotions of a natural person in the workplace and education institutions, except where the system is intended for medical or safety reasons. Recital 18 defines the concept by reference to emotions or intentions such as happiness, sadness, anger or shame inferred from biometric data, and excludes physical states such as pain or fatigue, including systems detecting fatigue in pilots or drivers. It also excludes the mere detection of readily apparent expressions, gestures or movements unless they are used to identify or infer emotions. The Covington summary reports that the Guidelines apply the prohibition to workers’ emotions and not to those of customers. Article 2(11) preserves national and collective rules more favourable to workers, which a screen for workplace products has to read alongside Article 5(1)(f).
Point (g) prohibits biometric categorisation that deduces or infers race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation; the text carves out labelling or filtering of lawfully acquired biometric datasets and categorisation in the area of law enforcement.
Point (h) concerns use only, by or for law enforcement. It permits real-time remote biometric identification in publicly accessible spaces only where strictly necessary for one of three listed objectives, and paragraphs 2 to 4 of Article 5 attach conditions: a fundamental rights impact assessment under Article 27, registration in the EU database under Article 49 (with a provision for urgent cases), prior authorisation by a judicial authority or an independent administrative authority whose decision is binding, and notification of each use to the market surveillance authority and data protection authority. For most commercial launches the recorded finding is whether any customer or deployment context involves law enforcement.
The Two Prohibitions Applying From 2 December 2026

Point (ba) prohibits AI systems that generate or manipulate realistic images, video, audio or similar material of an identifiable natural person’s intimate parts, or of that person engaged in sexually explicit activities, without the person’s freely given, specific, informed, unambiguous and explicit consent. Point (bb) prohibits systems that generate or manipulate material or performance within Article 2, points (c) and (e), of Directive 2011/93/EU, except where a “without right” defence applies under national law. Paragraph 1a then sets different conditions for providers and deployers.
| Actor and trigger | Prohibited where (Article 5(1a)) |
|---|---|
| Provider: placing on the market or putting into service, paragraph 1a(a) | The generation or manipulation is the intended purpose of the system; or the system’s design, training, architecture, capabilities or user-facing functionalities make it a reasonably foreseeable and reproducible outcome without significant technical modification, and the system lacks reasonable and adequate technical safety measures and other safeguards to reliably prevent it, taking into account reasonably foreseeable misuse, and to correct observed or reported misuse. |
| Deployer: use, paragraph 1a(b) | The deployer uses the system for the purpose of generating or manipulating the material or performance. |
Paragraph 1b adds that, for point (ba), manipulation of material that does not increase the exposure of any depicted intimate parts or alter the nature of any depicted sexually explicit activities does not constitute manipulation.
The following is analysis. The provider test in paragraph 1a(a)(ii) turns two engineering questions into legal ones: whether the output is reasonably foreseeable and reproducible without significant technical modification, and whether the safeguards reliably prevent it and correct misuse that has been observed or reported. A launch record for an image or video generation capability therefore has two parts. One records test results and design choices bearing on reproducibility and prevention. The other records how reports of misuse reach someone able to correct it, because the text includes correction of observed or reported misuse. Because the Guidelines pre-date these points, the Act’s own wording in Article 5(1a) is the operative source for this record, and Commission interpretation of that wording is not part of the Guidelines.
When an Exception Applies, Annex III Classification Follows
An Article 5 finding of “not prohibited” does not end the screen. Paragraph 37 of the Guidelines states that most AI systems falling under an exception to a prohibition will qualify as high-risk, and gives emotion recognition outside the conditions of point (f) as an example, classified under Article 6(2) and Annex III, point 1(c). Annex III also lists biometric categorisation by sensitive attributes (point 1(b)), education uses (point 3), recruitment and worker-management uses (point 4), creditworthiness (point 5(b)) and risk assessment and pricing in life and health insurance (point 5(c)). The Guidelines add credit scoring and life and health insurance risk assessment as examples of scoring systems that are high-risk where they do not meet the conditions of point (c).
Under Article 113(c), the Chapter III obligations for systems classified as high-risk under Article 6(2) and Annex III apply from 2 December 2027, and those for systems classified under Article 6(1) and Annex I apply from 2 August 2028. The Article 5 prohibitions are not deferred by those dates. A launch planned for 2027 around an exception to point (f) or (g) therefore carries both a present Article 5 record and a future high-risk classification.
Two further statements in the Guidelines belong in the same record. Paragraph 38 states that an Annex III system treated as non-high-risk under Article 6(3) may still fall within Article 5, since Article 6(3) only affects high-risk status. Paragraph 43 states that satisfying the AI Act prohibitions does not establish compliance with other Union law; for example, emotion recognition used in the workplace for medical or safety reasons remains subject to data protection law and to Union and national employment and health-and-safety law.
What an Authority Can Weigh and the Records That Answer It
Market surveillance authorities enforce the prohibitions, acting on their own initiative or on complaint (paragraph 53 of the Guidelines). Article 85 allows any natural or legal person with grounds to consider that there has been an infringement to lodge a complaint with the relevant authority. Chapter XII on penalties applies from 2 August 2025 under Article 113(b), and penalty rules themselves are laid down by Member States under Article 99(1).
Article 99(3) provides for administrative fines for non-compliance with Article 5 of up to EUR 35,000,000 or, for an undertaking, up to 7% of total worldwide annual turnover for the preceding financial year, whichever is higher. Under paragraph 6, for SMEs including start-ups each fine is up to the percentage or amount in paragraphs 3, 4 and 5, whichever is lower. Paragraph 6a, which applies to SMCs, refers to paragraphs 4 and 5 and does not mention paragraph 3; that is the text as written, and readers relying on it should read it against the consolidated version. Paragraph 57 of the Guidelines adds that, because the prohibitions interfere most with the freedoms of others and carry the highest fines, their scope should be interpreted narrowly.
Because Article 99 leaves the rules on penalties to Member States, a launch across several Member States meets several penalty regimes. Article 99(2) requires Member States to notify those rules, and later amendments to them, to the Commission. Article 99(8) leaves to each Member State the extent to which administrative fines may be imposed on public authorities and bodies established there, and Article 99(9) allows fines to be imposed by national courts or other bodies depending on the legal system. As analysis, the Article 99(7) factors in the table below are the Act’s own, while the procedure through which a national authority or court applies them is set nationally, so the documentary record should be read against the national rules of each Member State where the system is placed on the market, put into service or used.
Article 99(7) lists the circumstances to be taken into account in deciding whether to fine and in what amount. The table pairs six of them with records a launch screen can produce. The pairing is editorial analysis and not an authority’s published checklist.
| Article 99(7) factor | Record that speaks to it (editorial) |
|---|---|
| (a) Nature, gravity and duration; purpose of the system; number of affected persons | Use-case description, intended-purpose statement and the groups the system is used on |
| (f) Cooperation with national competent authorities | Named contact and a retrievable file per use case |
| (g) Technical and organisational measures implemented | Design review outputs, safeguards documentation, terms of use and instructions for use excluding prohibited uses |
| (h) How the infringement became known, including whether the operator notified it | Incident intake and escalation log, with dates |
| (i) Intentional or negligent character | Dated screening decision with the reasoning for each point considered |
| (j) Action taken to mitigate harm to affected persons | Remediation actions and their completion dates |
These records bear on how an authority weighs a fine. They do not alter whether the conditions of an Article 5 point are met, which depends on the text of Article 5 and the facts of the use case.
Why Article 5 Screening Belongs in the Launch Gate, Not the Compliance Calendar

Because the triggers sit at placing on the market, putting into service and use, the screen belongs at the decisions that create those events: approval of an internal deployment, approval of a pilot in real-world conditions, procurement of a system, and release of a feature. The ordered list below records one output per gate.
- Scope: record which Article 2 exclusion, if any, is relied on and the launch event that closes it, including the start of real-world testing.
- Role: record provider, deployer or both for the use case, including contractors operating the system.
- Trigger: record whether the event is placing on the market, putting into service (including in-house) or use.
- Points engaged: record each Article 5(1) point considered, the cumulative conditions examined, and the condition found missing where a point is ruled out.
- Exception relied on: record the exception and the reasoning, such as the medical or safety exception in point (f).
- Annex III: record whether the system falls under an Annex III point and the 2 December 2027 or 2 August 2028 application date.
- Other Union law: record data protection, employment, consumer and other regimes engaged.
- Terms and instructions: record the terms of use and instructions for use that exclude prohibited uses, and for general-purpose systems the safeguards deployers are expected not to bypass.
- Generative capability: for image and video generation, record the safeguards evidence and the misuse-reporting route under paragraph 1a.
- Re-screen triggers: record the changes that reopen the screen, such as a new intended purpose, a new feature, a new deployer context or a move to real-world testing.
The dated milestones relevant to a 2027 launch are 2 December 2026 for points (ba) and (bb), 2 December 2027 for Annex III obligations and 2 August 2028 for Annex I systems, all as set out in Article 113. Records for Article 5 screening sit alongside records for other measures the Act already requires; an AIGovernanceDesk analysis of Article 4 AI literacy readiness scores AI literacy measures across seven evidence dimensions, and the two sets of records can be kept in the same register.
Building practical AI governance, EU AI Act tooling, or literacy frameworks in production? We review and feature real work from practitioners.
[email protected]

Covering responsible AI, governance frameworks, policy, ethics, and global regulations shaping the future of artificial intelligence.

