Prohibited AI practices under the EU AI Act — what Article 5 actually bans

The high-risk tier (Annex III) works by category: certain use cases — recruitment, credit scoring, biometric identification, critical infrastructure, law enforcement, migration — are high-risk because of what the system is used for, and the obligations that follow are about how the system is built and operated. A well-built system in a high-risk category can be lawfully deployed. The regulation's theory is that risk can be managed with controls, documentation and oversight.

Article 5's theory is different. Each of the eight practices it names is one the regulation treats as unacceptable regardless of how well it is engineered. There is no control set that makes subliminal manipulation of behaviour acceptable. There is no documentation package that makes untargeted facial-image scraping acceptable. The prohibition applies to the practice itself, not to the quality of its implementation.

This has a direct consequence for how a security review has to be structured. The high-risk question — “what controls does this system need?” — is the wrong first question for a system near an Article 5 boundary. The first question is “does this system do the thing Article 5 prohibits, at all?” If the answer is yes, the review is not scoping controls. It is telling the product team the feature as designed cannot ship in the EU, and the redesign conversation needs to happen before any further engineering investment.

High-risk obligations tell you how to build the system safely. Article 5 tells you the system cannot exist in this form. Confusing the two means a review spends its time on the wrong question until it is too late to matter.

Article 5(1) lists eight practices across eight sub-paragraphs, (a) through (h). They cluster into four themes: manipulation and exploitation, social and predictive scoring of individuals, untargeted biometric data collection, and biometric inference or identification that crosses a defined line. The table below is a working reference; the sections that follow walk through each cluster with the boundary detail that actually matters for a review.

Article 5(1)(a) prohibits 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 a person's or group's behaviour in a way that causes or is reasonably likely to cause significant harm. Article 5(1)(b) prohibits the same material distortion of behaviour achieved by exploiting the vulnerabilities of a specific group — due to age, disability, or a specific social or economic situation.

The harm threshold is what does the work in both provisions, and it is the part reviews most often skip past. A recommendation engine that uses persuasive design — urgency framing, social proof, personalised offers — is not automatically caught by 5(1)(a). What Article 5 prohibits is the combination of a technique the subject cannot perceive or consciously resist, deployed on purpose, causing or reasonably likely to cause significant harm to that person's health, safety, financial interests, or similar. Ordinary persuasive UX design, disclosed and resistible, sits outside the prohibition; the same design pattern aimed at, say, exploiting a known cognitive vulnerability of elderly users to induce a financially harmful purchase does not.

5(1)(b) works the same way for vulnerable groups: it does not prohibit building products for children, people with disabilities, or people in financial hardship. It prohibits exploiting the vulnerability associated with that group to materially distort behaviour and cause significant harm. An accessibility feature is not in scope. A dark pattern deliberately tuned to a disability-linked vulnerability, to drive a harmful outcome, is.

Article 5(1)(c) prohibits AI systems that evaluate or classify natural persons over a period of time based on their social behaviour or known, inferred or predicted personal or personality characteristics, where the resulting score leads to detrimental or unfavourable treatment in social contexts unrelated to the context in which the data was originally generated, or treatment that is unjustified or disproportionate to the behaviour itself.

The context-transfer element is the part that most distinguishes a prohibited social-scoring system from a lawful risk-scoring one. Credit scoring, insurance underwriting, and fraud scoring all evaluate individuals based on behaviour, and none of them are automatically prohibited — they fall instead under high-risk obligations where applicable, because the treatment they produce (a credit decision, a premium) is contextually related to the data used to make it (repayment history, claims history). What tips a scoring system into Article 5(1)(c) territory is scoring someone in one context (say, workplace conduct) and using that score to determine an unrelated outcome (say, access to a public service), especially where the resulting treatment is disproportionate to the behaviour that produced the score.

A review should trace, for any scoring or evaluation mechanic, exactly what data generates the score, what decision the score feeds, and whether that decision sits in the same context as the data. If the answer is no — the score generated from one domain is being used to gate an unrelated domain — that is the specific pattern Article 5(1)(c) targets.

Article 5(1)(d) prohibits AI systems that assess or predict the risk of a natural person committing a criminal offence based solely on profiling of that person or on assessing their personality traits and characteristics. The explicit carve-out: this does not prohibit AI used to support a human assessment of a person's involvement in a criminal activity, where that assessment is already based on objective and verifiable facts directly linked to a criminal activity.

The distinction is between predicting who might offend, based on who they are, and supporting an assessment of specific, evidenced criminal activity a person is already suspected of. “This individual's demographic and behavioural profile correlates with future offending” is the prohibited pattern. “This individual is a suspect in a specific offence, and here is an AI-assisted analysis of the evidence linked to that offence” sits outside it, provided the assessment does not collapse back into profiling-based prediction dressed up as evidence review.

Article 5(1)(e) prohibits the untargeted scraping of facial images from the internet or CCTV footage to create or expand facial recognition databases. This one has the fewest edge cases of the eight: there is no proportionality test, no harm threshold, no exception for research or product development. Building a facial-recognition training or matching database by scraping images at scale, without a targeted, lawful collection basis for each individual's image, is prohibited outright.

For a review, the relevant question is upstream of the system under assessment: where did the facial-recognition dataset the vendor or the internal team is using come from. “We licensed a commercial dataset” and “we scraped public images” are different answers with different exposure, and a vendor security questionnaire for any system with a facial recognition component should ask the question directly rather than inferring an answer from a model card that does not address provenance.

Article 5(1)(f) prohibits AI systems that infer emotions of a natural person in the workplace or in education institutions, except where the AI system is intended to be used for medical or safety reasons. This is one of the narrower provisions in scope — it applies specifically to workplace and education contexts, not to emotion recognition generally — but it is the one product teams are most likely to walk into unintentionally, because emotion-inference features are common in customer-facing products (call centre sentiment analysis, video-interview tone assessment) and it is easy to assume the same feature is fine when repurposed for an internal HR or training tool.

The medical-or-safety exception is narrow and functional — a driver drowsiness-detection system in a safety-critical role, or a clinical tool used in a medical context, is not caught. A wellbeing dashboard that infers employee mood from meeting audio to flag disengagement is exactly what this provision targets, and “it is for employee wellbeing” is not, on its own, a medical or safety justification.

Article 5(1)(g) prohibits biometric categorisation systems that infer or categorise natural persons based on their biometric data to deduce or infer their race, political opinions, trade union membership, religious or philosophical beliefs, or sex life or sexual orientation. Two exceptions exist: labelling or filtering of lawfully acquired biometric datasets (for example, sorting images by apparent hair colour or eye colour for a non-inferential purpose), and law-enforcement categorisation of biometric data, which is instead governed by the law-enforcement-specific rules elsewhere in the regulation.

The distinction to hold onto: categorising an observable physical characteristic (hair colour, apparent age range for content-rating purposes) is not the same as inferring a protected characteristic that is not directly observable from the biometric signal (political opinion, religious belief, sexual orientation). A system that infers the latter from facial geometry, voice, or gait data is squarely inside this prohibition even if the stated product purpose is something else — personalisation, content moderation, ad targeting.

Article 5(1)(h) prohibits the use of real-time remote biometric identification systems in publicly accessible spaces for law-enforcement purposes, subject to a narrow set of exceptions: targeted search for specific victims of abduction, trafficking, or sexual exploitation, or missing persons; prevention of a specific, substantial and imminent threat to life or a terrorist attack; or localisation or identification of a person suspected of a serious criminal offence carrying a defined minimum penalty. Even within those exceptions, use requires prior authorisation from a judicial authority or an independent administrative authority, except in duly justified urgent situations.

This is the most tightly scoped of the eight — it applies to law enforcement, to real-time (not retrospective) identification, and to publicly accessible physical spaces. A retrospective biometric identification system used by law enforcement to identify a suspect from recorded footage days later is governed by different provisions, not this one. A private company's biometric access-control system in its own office building is outside the “publicly accessible space” and “law enforcement” conditions entirely. The provision is narrow by design, and organisations outside law enforcement rarely trigger it directly — but any product sold into a law-enforcement or public-security customer with a real-time biometric matching capability needs this provision named explicitly in the review, with the authorisation requirement documented as a control dependency rather than assumed.

Across the systems we have seen reviewed near an Article 5 boundary, four patterns recur. None of them are exotic; all of them are the kind of feature a product team adds without connecting it to the prohibition list.

• The wellbeing or engagement dashboard. Sentiment or emotion inference, repurposed from a customer-facing feature into an internal HR tool, lands directly on 5(1)(f) without anyone re-running the analysis for the new context.
• The cross-context reputation score. A behavioural score built for one purpose (say, platform trust and safety) gets reused to gate access to an unrelated feature or service. The reuse is the trigger for 5(1)(c), not the original scoring purpose.
• The “risk profile” feature that never names an offence. A fraud or insider-risk tool that scores individuals on demographic or behavioural profile similarity to past bad actors, without any evidenced link to a specific offence, drifts toward 5(1)(d) even when the product team frames it as anomaly detection.
• The biometric personalisation feature. A feature that infers demographic or affinity attributes from face or voice data for personalisation purposes can slide into 5(1)(g) if any of the inferred attributes fall on the protected list, even when the product framing is “better recommendations,” not “categorisation.”

Each of these is catchable at design-time review, before the feature ships, if the review explicitly asks the Article 5 question rather than jumping straight to Annex III tiering. Once the feature has shipped and users depend on it, the fix is a product redesign under time pressure instead of a design change on paper.

A design-time security review that has actually addressed Article 5 produces a short, specific artefact — not a checkbox saying “not applicable.” For each of the eight practices, the record should state: whether the system's mechanism resembles the practice at all, and if so, the specific factual basis for concluding the prohibition does not apply — the harm threshold is not met, the context of use and the context of data generation are the same, the exception condition is satisfied and documented.

That record belongs alongside the system's EU AI Act system inventory entry as the first gate a system passes through, before the Annex III high-risk determination is even relevant. “Not high-risk” is a meaningless answer to give an AI Committee if the system was never checked against Article 5 in the first place — a system can be low-friction to score under Annex III and still fail the prohibited-practices gate entirely.

“We didn't find it in Annex III” answers the wrong question. The first question is whether the system does one of the eight things Article 5 bans outright — no tier, no controls, no path through.

Where a system does land close to one of the eight practices, the record should say so plainly and route the decision to the people who can actually make it — product leadership and legal counsel, not the security review alone. A security review can identify that a feature resembles a prohibited pattern. Whether it crosses the line is frequently a fact-specific legal judgment, and the review's job is to surface the question early enough that the answer still has time to change the design.