Article 5: prohibited AI practices developers must avoid

Why Article 5 matters for developers

Most of the EU AI Act deals with obligations: risk management, documentation, conformity assessments. Article 5 is different. It draws hard lines. If your system falls into one of these categories, there is no conformity assessment path and no risk mitigation plan that makes it compliant. The system cannot be deployed in the EU.

This matters at the code level because prohibited practices can appear in systems that were not designed to be harmful. A recommendation engine can cross into manipulative techniques if it exploits psychological vulnerabilities. A facial recognition module built for access control can cross into biometric categorisation if it infers race or religion. The line between high-risk and prohibited is in the implementation details.

The prohibitions have been in force since 2 February 2025 (Article 113(a)). If you are building or deploying AI systems that reach EU users, these rules apply now.

The eight prohibited categories

Article 5(1) lists eight categories of prohibited AI practice, with a ninth added by the Digital Omnibus. Here is what the legislation says and where the boundaries sit.

5(1)(a): Subliminal and manipulative techniques

Prohibited: AI systems that deploy subliminal techniques beyond a person's consciousness, or purposefully manipulative or deceptive techniques, with the objective or effect of materially distorting behaviour and causing or likely causing significant harm.

The operative elements are "beyond consciousness" and "significant harm." A/B testing a button colour is not subliminal manipulation. An AI system that uses psychological profiling to exploit cognitive biases — dynamically altering interface patterns to prevent users from disengaging — is closer to the line. If your system uses behavioural profiling to alter content delivery, ask whether a reasonable person would be aware of the technique and whether the outcome could cause them harm.

5(1)(b): Exploiting vulnerabilities

Prohibited: AI systems that exploit vulnerabilities due to age, disability, or social or economic situation, where the effect is to materially distort behaviour and cause significant harm.

This targets systems that take advantage of specific vulnerabilities. An AI marketing system that targets elderly users with confusing subscription flows, or a lending AI that offers predatory terms to people in financial distress, would fall here. For recruitment and hiring systems, this means extra caution around age-related signals — treating candidates differently based on inferred age or disability is not just a discrimination risk under high-risk rules, it may be a prohibited practice.

5(1)(c): Social scoring

Prohibited: AI systems used by public authorities, or on their behalf, for evaluating or classifying natural persons based on their social behaviour or personal characteristics, where the resulting social score leads to detrimental or unfavourable treatment that is either:

1. (i) in social contexts unrelated to the contexts in which the data was originally collected, or
2. (ii) disproportionate to the social behaviour or its gravity.

The scope is narrower than it first appears. It applies to public authorities (or those acting on their behalf), not private companies. And it triggers on the combination of social scoring plus detrimental treatment in unrelated contexts or disproportionate to the behaviour. A bank's credit scoring is not caught because it is a private entity and the scoring is contextually related. A local authority AI that uses parking fine data to deny housing applications would be.

$ regula classify --input "system using social credit scoring for citizens"
PROHIBITED: Social scoring by public authorities or on their behalf

Regula's classify command checks system descriptions against Article 5 categories. Verify the classification against the full legislative text, because context matters.

5(1)(d): Criminal risk prediction from profiling

Prohibited: AI systems that assess criminal risk based solely on profiling or personality traits. The exception covers AI used to support human assessment already based on objective, verifiable facts directly linked to criminal activity.

The word "solely" does the heavy lifting. Predicting who will commit crimes based on demographic data or personality profiles is prohibited. Analysing case evidence to support a human investigator's assessment of an identified suspect is not — provided the assessment is based on objective facts linked to a specific criminal activity. See Article 14: human oversight requirements for the oversight obligations that apply to permitted law enforcement AI.

5(1)(e): Untargeted facial image scraping

Prohibited: AI systems that create or expand facial recognition databases through untargeted scraping of facial images from the internet or CCTV footage.

The prohibition is on untargeted scraping — building a database by hoovering up every face from publicly available images or surveillance footage. Targeted collection under lawful authority (e.g., mugshots taken during a lawful arrest) is not covered, though it may trigger other obligations. If your code includes web scraping modules that collect images, check whether facial images are being gathered and whether the collection is targeted or a bulk trawl.

5(1)(f): Emotion inference in workplace and education

Prohibited: AI systems that infer emotions in the workplace or in educational institutions, except where the AI system is intended to be put into service or placed on the market for medical or safety reasons.

If your system detects stress, engagement, or emotional states of workers or students, it falls here unless it has a medical or safety purpose. A factory system that monitors workers for fatigue to prevent industrial accidents may qualify for the safety exception. A call centre AI that monitors agent emotions to optimise customer service does not. The exception is narrow. If you are building AI systems in Python or any other language that processes audio, video, or biometric signals from employees or students, check what inferences the system draws and what the purpose is.

5(1)(g): Biometric categorisation by protected characteristics

Prohibited: AI systems that categorise persons based on biometric data to infer race, political opinions, trade union membership, religious beliefs, sex life, or sexual orientation. Exception: labelling or filtering of lawfully acquired biometric datasets, or law enforcement categorisation.

This is about deducing or inferring protected characteristics from biometric data — using facial features to infer ethnicity, gait analysis to infer political affiliation, or voice patterns to infer sexual orientation. If your model's feature pipeline extracts biometric signals and your output categories include any of the listed characteristics, this prohibition applies. The dataset labelling exception is narrow: it covers filtering an existing lawfully acquired dataset, not building a classifier to sort people by protected characteristics.

5(1)(h): Real-time remote biometric identification in public spaces

Prohibited: the use of real-time remote biometric identification systems in publicly accessible spaces for law enforcement purposes, except under narrow circumstances with judicial authorisation.

The three permitted exceptions, each requiring prior judicial or independent administrative authorisation (or post-hoc authorisation in urgent cases within 24 hours), are:

• Targeted search for specific victims of abduction, trafficking, or sexual exploitation, or for missing persons
• Prevention of a specific, substantial, and imminent threat to life or a foreseeable terrorist attack
• Identification of suspects of criminal offences punishable by at least four years of imprisonment

Articles 5(2) through 5(6) set out the conditions and safeguards: necessity and proportionality assessments, judicial authorisation, notification to supervisory authorities, time and geographic limitations, and fundamental rights impact assessments. If you are building biometric identification for law enforcement, the Article 9 risk management obligations apply on top of these specific conditions.

5(1)(i): NCII and CSAM generation (Omnibus addition)

The Digital Omnibus (provisional agreement 7 May 2026, EP approved 16 June 2026, Council approved 29 June 2026; pending OJ publication) adds a ninth prohibited category: AI systems designed to generate non-consensual intimate imagery (NCII) or child sexual abuse material (CSAM). This takes effect on 2 December 2026. The obligation is on the design of the system, not just its use — image generation systems need technical safeguards to prevent generation of this material.

Timeline: what is already in force

The Article 5 prohibitions were the first part of the AI Act to take effect. Under Article 113(a), they have applied since 2 February 2025 — the original eight categories are enforceable now. The Omnibus addition under Article 5(1)(i) takes effect on 2 December 2026. For how Article 5 fits into the broader timeline, including the deferral of Annex III high-risk obligations to 2 December 2027, see risk tiers explained with code examples.

Penalties

Article 99 sets the penalty ceiling for prohibited practice violations at EUR 35 million or 7% of total worldwide annual turnover, whichever is higher. For comparison, high-risk non-compliance carries fines of up to EUR 15 million or 3%. Prohibited practices carry the highest penalties in the Act. National market surveillance authorities enforce these provisions; each Member State designates its own competent authority.

How to check your system

The first question is whether your system falls into any of the prohibited categories. Regula can help with the technical side.

Step 1: Classify your system

Use regula classify with a description of your system to check whether it matches a prohibited category:

$ regula classify --input "system using social credit scoring for citizens"
PROHIBITED: Social scoring by public authorities or on their behalf

If the classification returns PROHIBITED, that requires legal review. Regula matches on patterns in the description, but the legal determination depends on context that code scanning cannot fully assess.

Step 2: Scan your codebase for risk patterns

Run regula check . on your codebase to identify risk indicators. Patterns that may indicate proximity to prohibited practices include:

• Biometric data processing (facial recognition, emotion detection, gait analysis)
• Social scoring or behavioural profiling functions
• Web scraping modules that collect images at scale
• Predictive models with criminal justice or law enforcement labels in training data
• Emotion inference from audio, video, or physiological signals

A risk indicator is not a compliance finding. Emotion detection code does not mean your system is prohibited — context determines that. But it tells you where to look.

Step 3: Get a broader assessment

Use the web assessment tool if you want a non-technical overview of where your system sits. For a full applicability check, combine the classify output with a review of your system's purpose, deployment context, and user base.

Grey areas developers should watch

The prohibited categories have clear centres and blurry edges. Here are the areas where reasonable people disagree and where developers should tread carefully:

• Personalisation vs. manipulation. Article 5(1)(a) prohibits techniques that distort behaviour beyond a person's consciousness. Most recommendation algorithms will not cross this line, but engagement-maximisation systems that exploit psychological vulnerabilities might.
• Emotion detection vs. sentiment analysis. Article 5(1)(f) prohibits emotion inference in workplace and education. Processing text sentiment in customer reviews is different from inferring an employee's emotional state from their webcam. But if your system categorises employee messages as "frustrated" or "disengaged," seek legal advice.
• Demographic analysis vs. biometric categorisation. Article 5(1)(g) prohibits categorisation by protected characteristics from biometric data. Aggregate demographic statistics are different from individual-level categorisation by race from facial images.

What code scanning cannot tell you

Regula flags risk patterns and classifies system descriptions against Article 5 categories. It cannot determine whether your system is legally prohibited, because that depends on the deployer's identity, the system's actual effect, whether an exception applies, and jurisdiction-specific interpretation by national authorities.

Code scanning and legal review are complementary. Regula identifies where to look. A qualified legal professional determines what it means. See the guides and blog for more on AI Act compliance from a developer's perspective.

---

Related

• Article 9: risk management system requirements
• Article 14: human oversight for high-risk AI
• EU AI Act risk tiers explained with code examples
• How to classify your AI system under the EU AI Act
• Does the EU AI Act apply to you?
• About Regula: what it does and does not do

---

Last verified: 25 June 2026 · Author: Kuziva Muzondo · Not legal advice. Regula identifies risk indicators in code for developer review. It does not determine compliance or replace professional legal counsel.