EU AI Act Article 5 Is Already Live: Scanning Your Code for Prohibited AI Practices
Eight categories of AI practice have been prohibited in the EU since 2 February 2025, with two more added by the Digital Omnibus (taking effect 2 December 2026). Article 99 provides for fines up to EUR 35 million or 7% of global annual turnover. Here is what the original eight prohibitions mean in code, how to scan for indicators, and what to review when something is flagged. Primary legislation.
This is already law
Article 5 of the EU AI Act has applied since 2 February 2025. Article 99 provides for fines up to EUR 35 million or 7% of worldwide annual turnover for prohibited-practice infringements. The Digital Omnibus does not change the original categories or their application date; it adds two prohibitions taking effect on 2 December 2026. Read Articles 5, 99 and 113.
I keep meeting developers who think the EU AI Act is a future problem. Something to deal with in 2027 or 2028, once the Omnibus delay sorts itself out.
For high-risk systems, Regulation (EU) 2026/1744 now sets 2 December 2027 for Annex III obligations and 2 August 2028 for Annex I product-embedded systems. Those deferrals do not make every other AI Act provision inapplicable.
But Article 5 is not part of that delay. It has applied since 2 February 2025. Article 99 provides for fines up to EUR 35 million or 7% of worldwide annual turnover for prohibited-practice infringements, and up to 3% for certain other infringements. Primary legislation: Articles 5, 99 and 113.
A code match does not establish that a prohibited practice exists. If the deployed system meets the full legal test for one of the original Article 5 prohibitions, the relevant prohibition has applied since 2 February 2025. Conditions, exceptions, intended purpose and actual use must be assessed.
The eight prohibited categories
The eight practices banned under Article 5 are: subliminal manipulation, exploiting vulnerabilities of specific groups, social scoring by public authorities, individual criminal risk prediction based solely on profiling, untargeted facial recognition scraping, emotion inference in workplaces and schools, biometric categorisation of sensitive attributes, and real-time biometric identification in public spaces for law enforcement.
Article 5 lists eight specific practices. Some are obvious. Others are narrower than you'd expect. Here's each one, and what it looks like when it shows up in code.
Subliminal manipulation
AI systems that deploy techniques operating beyond a person's consciousness to materially distort their behaviour, causing or likely to cause significant harm. Think dark patterns backed by AI that the user literally can't perceive. The key word is "beyond consciousness": if the user can see the nudge, it isn't subliminal in the legal sense.
In code, Regula looks for patterns like: subliminal, beyond_consciousness, subconscious_influence. Developers building these systems tend to name things what they are.
Exploiting vulnerabilities
AI systems that exploit the vulnerabilities of specific groups (due to age, disability, or socio-economic situation) to materially distort behaviour and cause significant harm. This is about targeting people because they are vulnerable, not about serving them.
Regula looks for target_elderly, exploit_disabil, vulnerable_group_target. The distinction matters. Building accessibility features for elderly users is fine. Building a system that targets elderly users because they're less likely to recognise a manipulative interface is not.
Social scoring
Evaluating or classifying people based on their social behaviour or personal traits, where this leads to detrimental treatment that is disproportionate to the context. The prohibition applies to scoring by public authorities or on their behalf.
Patterns include social_score, social_credit, citizen_score, and behaviour_scoring when combined with public-authority context. A gamification leaderboard is not necessarily social scoring; deployment context and effects require human review. Pattern source.
Individual criminal risk prediction
Predicting whether a person will commit a crime based solely on profiling or personality traits. The word "solely" is doing real work here. A system that uses multiple evidence sources (case facts, prior convictions with human review) may be lawful. One that predicts criminality from someone's profile alone is not.
Matched by: crime_predict, criminal_risk_assess, predictive_policing, recidivism. The recidivism pattern comes up most often in practice. If you're building a recidivism scoring model, look at this carefully.
Untargeted facial recognition scraping
Creating or expanding facial recognition databases by scraping facial images from the internet or CCTV in an untargeted way. This is the Clearview AI prohibition. If your system scrapes faces from public sources to build a recognition database, it's prohibited regardless of the purpose.
Patterns: face_scrap, facial_database_untarget, mass_facial_collect. Straightforward.
Emotion inference in workplaces and schools
Inferring emotions in workplace and educational settings. There's a narrow exception: medical or safety purposes, such as detecting driver fatigue or monitoring a patient's wellbeing in a clinical setting. But "let's see if our employees are happy" is prohibited.
Patterns: emotion.*workplace, emotion.*school, sentiment.*employee, workplace.*emotion, employee.*emotion. Regula matches these with a 40-character window between terms to catch common code structures like detect_emotion(frame, context="workplace").
Biometric categorisation of sensitive attributes
Using biometric data to categorise people by race, political opinions, trade union membership, religious beliefs, sex life, or sexual orientation. There's a narrow exception for labelling lawfully acquired biometric datasets (photo sorting, for example) where no categorisation of individuals actually occurs.
Patterns: race_detect (with a negative lookahead to exclude race_condition and thread contexts), ethnicity_infer, political_opinion_biometric, religion_detect, sexual_orientation_infer. The race condition guard is there because race_detect in a concurrent programming context is an extremely common false positive.
Real-time biometric identification in public spaces
Real-time remote biometric identification in publicly accessible spaces for law enforcement. Narrow exceptions exist but require prior judicial authorisation: searching for victims of abduction or trafficking, preventing an imminent terrorist threat, or identifying suspects of serious criminal offences listed in Annex II.
Patterns: real_time_facial_recogn, live_biometric_public, public_space_biometric, mass_surveillance_biometric.
What a scan actually looks like
Running regula check . on a project with prohibited patterns produces a verdict of PROHIBITED, lists each flagged file with its line number and Article 5 sub-paragraph, and shows confidence scores from 0 to 100. All prohibited findings are classified as BLOCK tier regardless of confidence, because the regulation has no partial-prohibition category.
Enough theory. Here's what happens when you run regula check against a project that contains prohibited patterns. This is Regula's actual output format.
Say you have a Python file called hr_analytics.py that analyses employee sentiment from webcam feeds, and a scoring.py that builds a social credit system for a government client:
Three things immediately: your verdict (prohibited), which files caused it, and what to do next. The confidence scores (92, 88, 85) reflect how closely the matched code resembles a real prohibited practice. A score of 92 on an emotion-in-workplace finding means the pattern matched sentiment.*employee or emotion.*workplace with strong surrounding context.
All prohibited findings are automatically BLOCK tier, regardless of confidence score. There's no scenario where a prohibited pattern gets downgraded to WARN or INFO. The Act doesn't have a "sort of prohibited" category.
False positives are real, and that's fine
Regex-based scanning will produce false positives. That's a deliberate trade-off: I'd rather flag something that turns out to be fine than miss something that isn't.
Here are the most common ones I've seen across the prohibited categories:
Emotion analysis for UX research. Running sentiment analysis on product feedback to improve your interface isn't the same as inferring emotions in a workplace setting under Article 5(1)(f). The prohibition is specifically about workplace and educational contexts. A pattern like sentiment_analysis(user_feedback) won't trigger the prohibited patterns because the regex requires the workplace, school, or employee context term nearby. But sentiment_analysis(employee_feedback) will, because the word employee appears within the 40-character match window.
Gamification scoring. A leaderboard system that scores users on their activity in a game or app isn't social scoring under Article 5(1)(c). The prohibition requires evaluation by public authorities or on their behalf, and the scoring must lead to detrimental treatment disproportionate to the original context. If you have a variable called social_score in a gamification module, Regula will flag it. That's correct behaviour: document why it isn't a prohibited practice and move on.
Race condition detection. The biometric categorisation pattern under Article 5(1)(g) includes race_detect. In concurrent programming, detect_race_condition is extremely common. Regula's pattern has a negative lookahead excluding matches followed by condition, thread, or concurrent. Catches most of these, but not all. If you name your mutex debugging function race_detector, expect a flag.
Recidivism in academic research. If you're working on a paper about criminal justice outcomes and your code includes the word recidivism, Regula will flag it under Article 5(1)(d). The prohibition applies to systems that predict criminal risk based solely on profiling. Academic research analysing existing data isn't that. Document it and suppress.
What to do when something gets flagged
When Regula flags a prohibited pattern, you have three paths: if it is a true positive, remove or redesign the functionality before EU deployment. If it is a false positive, add a # regula-ignore comment with a rationale explaining why the code is not a prohibited practice. If you are unsure, get legal review, because some Article 5 categories have narrow exceptions that require professional judgment.
Depends on whether the flag is accurate.
If it's a true positive: Remove or redesign the functionality before deploying in the EU. Run regula fix --project . for guided remediation. Article 5 doesn't have a grace period or a "comply or explain" mechanism. The practice is either prohibited or it isn't. If it is, it must not ship.
If it's a false positive: Add a # regula-ignore comment to the relevant line or file, with a rationale explaining why this isn't a prohibited practice. Regula tracks suppressed findings and will remind you if a suppression lacks a rationale. The suppression becomes part of your compliance evidence.
A suppression with rationale looks like this in your code:
# regula-ignore: social_score is a gamification leaderboard,
# not public authority social scoring per Article 5(1)(c).
user_social_score = calculate_engagement_points(activity_log)If you're not sure: Get legal review. Some of these categories have exceptions that require actual legal judgment, not just a regex match. The emotion inference prohibition has a medical/safety exception. The criminal prediction prohibition hinges on whether the system uses "solely" profiling. Regula can tell you a pattern matched. It can't tell you whether your specific use case falls within a narrow exception. A lawyer can.
The Omnibus doesn't change this
The Digital Omnibus on AI, which reached provisional agreement on 7 May 2026 and was approved by the European Parliament on 16 June 2026, defers Annex III high-risk deadlines to 2 December 2027 (approved by Council on 29 June 2026; published in the Official Journal on 24 July 2026, in force from 27 July 2026). It does not modify the original 8 Article 5 prohibitions or their 2 February 2025 application date. The Omnibus does add 2 new prohibitions (non-consensual intimate imagery and CSAM generation), which take effect on 2 December 2026. The 8 categories described in this article remain fully enforceable now.
I keep seeing this cause confusion, so I want to be direct. The enacted Digital Omnibus on AI delays specified deadlines for high-risk AI systems. Article 5 has its own application dates, including amendments introduced by Regulation (EU) 2026/1744.
The original Article 5 prohibitions became applicable on 2 February 2025. Regulation (EU) 2026/1744 did not defer that application date. Check the enacted text for the scope and application dates of amendments introduced by the Omnibus.
If someone on your team is saying "we can wait for the Omnibus," they're wrong about Article 5. They may be right about Annex III high-risk obligations. Not about this.
The eight patterns in numbers
Regula defines 8 prohibited pattern categories (covering the original Article 5 prohibitions) containing 33 individual regex patterns. Every category has confidence: high, likelihood: high, impact: high in the pattern definitions. That's not a configurable risk weighting. It reflects the fact that Article 5 carries the highest penalty tier in the regulation. The 2 additional Omnibus prohibitions (non-consensual intimate imagery and CSAM generation, effective 2 December 2026) are tracked separately.
The patterns aren't trying to be clever. They match the terms that developers actually use when building these systems: social_credit, predictive_policing, face_scrap, emotion.*workplace. Intentionally direct. Prohibited practice detection isn't the place for fuzzy matching or probabilistic classification. If the pattern matches, look at it. If it's a false positive, document it and suppress it. If it isn't, stop deploying it.
Run the scan
Install Regula, point it at your project, and review the output. A clean scan means only that the current pattern set found no match in the scanned files; it does not prove that no prohibited practice exists or that no obligation applies. A match is an indicator for contextual review, not proof of a legal breach.
Scans your project for prohibited, high-risk, and limited-risk AI practices.
If you want only prohibited findings, filter with regula check . --format json | python3 -c "import sys,json; d=json.load(sys.stdin); [print(f['file'],f['description']) for f in d['data']['findings'] if f['tier']=='prohibited']". But honestly, just read the full output. It isn't long, and you should know your full risk profile.
Article 5 isn't coming. It's here. The scan takes seconds. The fines don't.
Last reviewed: 14 August 2026 · Author: Regula maintainers · Not legal advice. Regula identifies risk indicators for developer review.
Related reading
- EU AI Act risk tiers in actual code — What each risk tier looks like in Python with scanner output
- Scanning 10 real AI apps with Regula — 553 findings across 219,000-star open-source projects
- Does the EU AI Act apply to your AI app? — Decision tree for scope, provider vs deployer, and extraterritorial reach