EU AI Act Prohibited AI Systems: What SaaS Developers Must Stop Building Before August 2, 2026

Post #5 in the EU AI Act Final Countdown Series — 56 Days to August 2, 2026

The EU AI Act creates three tiers of risk: prohibited, high-risk, and limited/minimal risk. The previous posts in this series covered high-risk classification sprints, GPAI obligations, and transparency requirements. This final sprint addresses the one tier where there is no conformity assessment path, no CE marking process, and no risk management system that makes your product compliant: prohibited AI practices under Art.5.

If your SaaS product includes any of the seven prohibited practices, you have until August 2, 2026 to remove them. After that date, deploying prohibited AI in the EU carries fines of up to €35 million or 7% of global annual turnover — the highest penalty tier in the regulation.

Understanding Art.5: The Absolute Prohibitions

Art.5 prohibits specific AI practices regardless of how they are implemented, who uses them, or what safeguards are in place. The prohibition is categorical. There is no exception path through Annex III high-risk classification, no conformity assessment that unlocks these features, and no contract clause that shifts liability to your customers.

The seven prohibited categories as of August 2, 2026:

1. Subliminal manipulation — AI systems that deploy subliminal techniques below a person's threshold of consciousness to distort behavior in a way that causes or is likely to cause harm (Art.5(1)(a))
2. Exploitation of vulnerabilities — AI that exploits vulnerabilities of specific groups (age, disability, socioeconomic situation) to distort behavior causing harm (Art.5(1)(b))
3. Social scoring by public authorities — AI used by public authorities or on their behalf to evaluate or classify individuals based on social behavior or predicted personal characteristics, resulting in detrimental treatment (Art.5(1)(c))
4. Individual predictive policing — AI that assesses risk of an individual committing a crime based solely on profiling or assessed personality traits, without objective fact-based suspicion (Art.5(1)(d))
5. Untargeted scraping for facial recognition databases — AI that creates or expands facial recognition databases by scraping images from the internet or CCTV without targeted consent (Art.5(1)(e))
6. Emotion recognition in workplace and education — AI that infers emotions of individuals in workplace or educational institution contexts (Art.5(1)(f)), with narrow exceptions for medical/safety reasons
7. Biometric categorization using sensitive attributes — AI that categorizes individuals based on biometric data to infer race, political opinion, trade union membership, religious beliefs, or sexual orientation (Art.5(1)(g))
8. Real-time remote biometric identification in public spaces — Law enforcement use of real-time RBI systems in publicly accessible spaces (Art.5(1)(h)), with specific narrow law enforcement exceptions

Note: Art.5(1)(h) applies specifically to law enforcement. Points 1–7 apply to all AI system providers and deployers.

The SaaS Developer's Prohibited Systems Checklist

Most SaaS developers are not building law enforcement tools. But Arts. 5(1)(a)–(g) are broader than they appear and can catch common product patterns.

Pattern 1: Behavioral Manipulation Features

What's prohibited: Any AI-driven feature that uses techniques operating below conscious awareness (subliminal messaging, dark-pattern recommendation loops calibrated to override rational agency) to push users toward behavior they would not choose if aware of the mechanism.

What's NOT prohibited: Standard A/B-tested UX optimization, personalization based on stated preferences, recommendation systems users can see and override, conversion optimization that uses visible CTAs.

Gray zone for SaaS: Engagement optimization algorithms in social platforms, notification timing systems that target moments of emotional vulnerability, and "persuasion AI" features that optimize for compliance rather than informed choice. If your documentation describes the feature as "nudging users below their awareness threshold," that description itself is a legal risk signal.

Sprint action: Audit your product roadmap for any feature described as "nudging," "subliminal," or "behavioral override." Review whether recommendation or notification systems have explicit caps that prevent exploitation of psychological vulnerabilities. Document the design intent.

Pattern 2: Vulnerability Exploitation in Pricing or Engagement

What's prohibited: AI that identifies users as being in a vulnerable state (financial distress, addiction signals, emotional crisis, cognitive impairment signals, age-based vulnerability) and uses that identification to push them toward decisions they would not otherwise make.

What's NOT prohibited: Age-appropriate content filtering, accessibility features for users with disabilities, fraud prevention that protects vulnerable users.

Gray zone for SaaS: Dynamic pricing algorithms that detect financial distress signals and charge higher prices to users who appear to have fewer alternatives. Engagement systems in gaming, gambling-adjacent, or social applications that increase push cadence when vulnerability signals are detected. B2C subscription apps that use cancellation prediction to target users who appear "desperate" with retention offers designed to trap rather than inform.

Sprint action: If your AI models include financial distress indicators, emotional state classifiers, or disability-adjacent features as inputs to pricing, upsell timing, or engagement throttling — legal review is required before August 2.

Pattern 3: Social Scoring Systems

Art.5(1)(c) targets social scoring "by public authorities or on their behalf." This is narrower than it appears — private employers running internal scoring systems are not automatically covered. But the boundary is less clear in three scenarios:

Scenario A — Government API integrations: If your SaaS provides a social scoring feature that government or quasi-public entities use to make decisions about service access, benefits, or civil rights, you are within scope even as a private provider.

Scenario B — Insurance and credit adjacent: Insurance underwriting AI that uses behavioral tracking to create composite "risk scores" with social dimension inputs (neighborhood, social associations, online behavior patterns unrelated to the risk being assessed) is in gray territory. Pure actuarial risk assessment on relevant factors is not prohibited — the prohibition targets the systematic evaluation of people as citizens rather than as policyholders.

Scenario C — Employer reputation/behavior scoring: Internal HR AI that scores employees on behavioral "culture fit" metrics derived from monitored behavior (email tone, Slack activity, badge tracking) creates cumulative risk profiles that regulators may scrutinize under Art.5(1)(c) when the system affects employment decisions systematically.

Sprint action: Identify every feature that creates a persistent "score" or ranking of individuals and document what decisions that score feeds into. If the score affects access to services, opportunities, or treatment that goes beyond direct risk assessment, legal review is warranted.

Pattern 4: Predictive Policing and Risk Profiling

Art.5(1)(d) prohibits AI that predicts individual criminal risk based "solely on profiling of a natural person or on assessing their personality traits and characteristics." The key word is "solely" — this means the prohibition targets systems that make no use of objective behavioral facts and instead rely entirely on demographic or personality inference.

What's NOT prohibited: Fraud detection that flags specific transaction anomalies, behavioral authentication that responds to demonstrated behavior rather than predicted traits, threat detection that responds to observable indicators.

Gray zone for SaaS: Behavioral risk scoring in fintech, insurtech, or HR that predicts future negative behavior (fraud propensity, absenteeism, attrition, legal disputes) from demographic or personality proxies without grounding in specific behavioral observations. If your model's input features include inferred personality types, demographic group membership, or social profile data without any specific behavioral anchor, the output may constitute a prohibited predictive profiling output.

Sprint action: For any "risk" or "propensity" model: document the input features. If the model cannot produce a specific behavioral fact (not a demographic inference) that explains the score for any given individual, the scoring methodology may be within Art.5(1)(d) scope.

Pattern 5: Biometric Categorization for Protected Attributes

Art.5(1)(g) prohibits AI that uses biometric data (including behavioral biometrics — gait, typing patterns, voice characteristics) to infer race, political opinion, trade union membership, religious beliefs, sex life, or sexual orientation.

What's often missed: "Biometric data" under the GDPR definition (which applies here) includes keystroke dynamics, gait analysis, voice prints, and facial geometry — not just fingerprints. A behavioral biometrics feature that builds a unique behavioral signature and then uses that signature to infer any of the protected categories listed above is prohibited under Art.5(1)(g).

Sprint action: If your product uses behavioral biometrics for any purpose, confirm that the downstream inference does not include any of the Art.5(1)(g) protected attributes even as intermediate variables in a model. The prohibition covers both direct output and intermediate inference.

Pattern 6: Emotion Recognition in Workplace and Education

Art.5(1)(f) prohibits AI that "infer[s] the emotions of a natural person in the areas of workplace and educational institutions." The exceptions are narrow: medical necessity and safety applications.

What this catches: Employee productivity monitoring using facial expression analysis, meeting engagement software that scores "enthusiasm" or "focus" based on facial expressions or voice tone in workplace contexts, educational platforms that infer student engagement or emotional state from webcam feeds, and interview screening AI that rates candidate "enthusiasm" based on facial analysis.

What's NOT prohibited: Burnout prevention tools that ask users how they feel (self-reported data), accessibility features that respond to stated emotional state, mental health SaaS where emotion recognition is the explicit therapeutic product the user has consented to.

Sprint action: If your product includes camera or microphone input in workplace or educational contexts and processes that input to infer anything about the user's internal emotional state — this is a high-priority item for the prohibited systems review.

The SaaS Compliance Sprint: 4 Weeks to Prohibited Systems Clearance

Unlike high-risk compliance (which requires extensive documentation and conformity assessment processes), prohibited systems compliance has a binary answer: the feature must be removed or fundamentally redesigned before August 2.

Week 1: Feature Inventory and Preliminary Assessment (Days 1–7)

Deliverable: Prohibited systems risk register

1. Pull every AI/ML feature from your product roadmap and production feature list
2. For each feature, answer four screening questions:
   • Does it process biometric data (including behavioral biometrics)?
   • Does it output a score, ranking, or category for an individual?
   • Does it operate on signals related to emotional state, vulnerability indicators, or demographic proxies?
   • Is it used in workplace, educational, or public safety contexts?
3. Any feature that answers "yes" to any question enters Week 2 deep review
4. Features that answer "no" to all four are low-priority — document the assessment

Week 2: Deep Review of Flagged Features (Days 8–14)

Deliverable: Legal opinion or documented self-assessment for each flagged feature

For each flagged feature:

• Map the input features → model → output → downstream decision chain
• Identify whether the pattern matches any of the 7 prohibited categories
• Document the specific argument for why the feature is or is not prohibited
• If ambiguous: obtain legal opinion. The cost of a legal opinion is orders of magnitude less than a €35M fine

Week 3: Redesign or Removal Plan (Days 15–21)

Deliverable: Engineering tickets with "ship before August 2" priority

Features that cannot be defended:

• Create a removal plan (API deprecation, data deletion, UI removal)
• Set target completion date: July 19 — leaves 2 weeks for verification
• Communicate deprecation to customers via email with regulatory context

Features that can be redesigned to compliance:

• Biometric categorization → redesign to avoid protected attribute inference
• Emotion recognition → redesign as opt-in self-reporting
• Predictive profiling → add behavioral fact grounding, remove demographic proxies

Week 4: Verification and Documentation (Days 22–28)

Deliverable: Prohibited systems clearance document

• Confirm all flagged features are either removed, redesigned to compliance, or have a documented legal opinion
• Update your AI system register to reflect status
• Add prohibited systems review to your standard feature intake process (prevents re-introduction after August 2)
• Archive the risk register and assessment documentation — regulators will ask

Common Misunderstandings About Art.5

"Our product is B2B, so Art.5 doesn't apply to us."

Wrong. Art.5 applies to providers and deployers. Your B2B customers are deployers. If you provide an API that enables a prohibited practice, and your customer deploys it, you remain liable as the provider. Your terms of service cannot contract away Art.5 liability.

"We're based outside the EU, so Art.5 doesn't reach us."

Wrong. Art.5 applies whenever the AI output is used in the EU, regardless of where the provider is located. This is the same extraterritorial scope as the GDPR.

"Our feature isn't technically AI, it's just a rule-based system."

The EU AI Act's definition of AI system covers rule-based systems that generate outputs (recommendations, decisions, content) that influence real or virtual environments. If your "rule-based" system makes individualized assessments that affect people, legal review is warranted.

"Social scoring is only about Chinese-style government systems."

Wrong. Art.5(1)(c) applies to any systematic evaluation of individuals that leads to detrimental or unfavorable treatment "unrelated to the context in which the data was originally generated." Private operators acting on behalf of or in the role of public authorities are included.

Infrastructure Note: Prohibited Systems Compliance and Data Residency

One dimension of Art.5 compliance that affects infrastructure decisions: the investigatory trail. When regulators investigate a prohibited system allegation, they will subpoena logs, model inputs, model outputs, and training data. If those artefacts are stored on infrastructure subject to non-EU legal process (US CLOUD Act, UK Investigatory Powers Act), the regulatory investigation intersects with a second jurisdiction's access claims.

EU-native infrastructure (Hetzner Germany, deployed via EU-native PaaS) means that the only legal process that can compel disclosure of compliance investigation artefacts is EU process. This isn't a workaround — it's basic legal hygiene for regulated products. Your compliance evidence should be under the same jurisdiction as your regulatory obligation.

EU AI Act Final Countdown: Series Wrap

This post closes the EU AI Act Final Countdown series:

56 days until August 2, 2026. The prohibited systems sprint is the most urgent: these features cannot be made compliant — they must be removed.

sota.io is EU-native managed PaaS built for teams that need their compliance infrastructure under EU jurisdiction. No US parent company, no CLOUD Act exposure, no jurisdiction risk for your compliance artefacts. Deploy your compliant AI product on sota.io →