EU AI Act Prohibited AI Systems Checklist for Engineering Teams
A technical breakdown of Article 5 bans, compliance deadlines, and infrastructure requirements for ML pipelines.
Magnus Grünewald
June 13, 2026 · CEO at Lyceum Technology
The regulatory landscape for machine learning deployment shifted permanently on February 2, 2025. On that date, the prohibitions outlined in Article 5 of the EU AI Act became legally enforceable. Regulators no longer assess internal policies or intent. They evaluate operational controls, data provenance, and technical artifacts. For infrastructure leads and ML engineers, compliance requires translating legal text into system architecture. Fines for violating prohibited practices scale up to €35 million or 7% of global annual turnover, exceeding the maximum penalties under the GDPR. This guide provides a concrete technical checklist to audit your current models against the prohibited tier, ensuring your deployment pipelines remain compliant as we approach the broader high-risk enforcement deadline in August 2026.
The Article 5 Prohibited Systems Checklist
The EU AI Act classifies AI systems into four risk tiers: unacceptable, high, limited, and minimal. Systems falling into the unacceptable tier are strictly prohibited. If your model inventory includes any of the following architectures or use cases, you must decommission them immediately.
1. Subliminal Manipulation and Deceptive Techniques
The Act bans AI systems that deploy subliminal techniques beyond a person's consciousness or exploit vulnerabilities (such as age, disability, or socioeconomic situation) to materially distort behavior, causing physical or psychological harm.
Technical Reality
This directly impacts reinforcement learning (RL) systems optimizing for user engagement. If your reward function strictly maximizes session length or click-through rates by serving increasingly extreme content, and your user base includes vulnerable demographics, you operate in a gray area that crosses into prohibited territory. You must audit your objective functions. If the model architecture deliberately exploits cognitive biases to force actions the user would not otherwise take, it violates Article 5.2. Social Scoring Mechanisms
Evaluating individuals based on social behavior or personal traits over time is prohibited if it leads to detrimental treatment in contexts unrelated to the data's original collection purpose, or if the treatment is disproportionate to the behavior.
Technical Reality
Models relying on graph neural networks or multi-modal data fusion to aggregate disparate user data, such as financial history, social media activity, and physical location, to generate a unified "trustworthiness" score are banned. If you build risk assessment models, you must isolate the features. A model predicting credit default must rely on financial data relevant to credit, not the user's social media sentiment or mobility patterns.3. Untargeted Biometric Scraping
Creating or expanding facial recognition databases through the untargeted scraping of facial images from the internet or CCTV footage is strictly prohibited.
Technical Reality: This represents a massive data governance challenge. If your training pipeline ingests uncurated web scrapes (e.g., Common Crawl subsets) containing human faces to train embedding models or vision transformers, your dataset is contaminated. You cannot use these datasets to build identity verification models. ML teams must implement strict filtering mechanisms to drop biometric data during the ETL phase unless explicit, targeted consent is documented.
4. Emotion Recognition in the Workplace and Education
Inferring the emotions of individuals in workplaces or educational institutions is prohibited, except for specific medical or safety reasons.
Technical Reality: Computer vision models and audio sentiment analysis tools deployed on office cameras, meeting software, or educational platforms to gauge engagement, stress levels, or productivity must be removed from production. If your architecture uses CNNs to classify facial micro-expressions into emotion categories (e.g., angry, sad, attentive) and the deployment target is an enterprise HR tool, you violate the Act.
5. Predictive Policing Based on Profiling
AI systems used to assess the risk of an individual committing a criminal offense based solely on profiling or personality traits are banned.
Technical Reality: Risk assessment algorithms that rely on historical demographic data, socioeconomic indicators, or personality assessments rather than objective, verifiable facts about a specific individual's past criminal conduct fall into this category. Models using tabular data frameworks (like XGBoost or LightGBM) trained on biased historical arrest records to predict future individual criminality are toxic assets.
6. Real-Time Remote Biometric Identification
Using real-time remote biometric identification systems in publicly accessible spaces for law enforcement is prohibited, subject to extremely narrow, pre-authorized exceptions.
Technical Reality: Edge-deployed inference models running on public camera feeds that match faces against a database in real-time are banned for general law enforcement use. If you build these systems, your customer base is severely restricted, and the operational controls required to ensure they operate only within the legal exceptions are immense.
Technical Boundaries: When Does a Model Become Prohibited?
Determining whether a model crosses the line into prohibited territory requires examining the intended purpose, the input data, and the deployment context. A model architecture is rarely illegal in isolation; the illegality stems from how and where it is applied.
Scenario A: Customer Support Sentiment Analysis
You deploy a Natural Language Processing (NLP) model to analyze customer support tickets, routing angry customers to senior agents.
Verdict: Compliant
This is not emotion recognition in a workplace or educational setting used against employees or students. It is a limited-risk application requiring transparency (informing the user they are interacting with an AI system).Scenario B: Driver Monitoring Systems
You build a computer vision model for fleet vehicles that detects driver drowsiness by analyzing eye movement and facial expressions.
Verdict: Compliant
While this involves emotion and state recognition in a workplace context, it falls under the explicit safety-critical exception outlined in the Act.Scenario C: Employee Productivity Tracking
You integrate a model into internal communication tools that analyzes the tone of employee messages to flag "burnout risk" or "low engagement" to HR.
Verdict: Prohibited
This constitutes emotion recognition in the workplace. The system must be decommissioned immediately.Scenario D: Educational Proctoring Software
You build a model for online exam proctoring that tracks eye movement to detect cheating.
Verdict: High-Risk (Not Prohibited)
Tracking gaze direction to ensure the student looks at the screen is not emotion recognition. However, if the model attempts to infer whether the student is "anxious" or "confused," it crosses into the prohibited emotion recognition category.Decision Framework for ML Teams
- Does the model process biometric data? If yes, verify it does not perform untargeted scraping or real-time public identification.
- Does the model infer psychological states? If yes, ensure the deployment environment is not a workplace or educational institution.
- Does the model aggregate behavioral data? If yes, confirm the output is not used to deny services in unrelated contexts (social scoring).
How to Audit Your Existing ML Pipelines
Compliance cannot remain a legal abstraction. It must translate into governed product processes. To prepare your infrastructure, execute the following audit steps across your ML pipelines to ensure you do not violate the prohibited practices outlined in Article 5.
Step 1: Dataset Provenance Review and ETL Governance
You cannot deploy a compliant model trained on non-compliant data. Audit your data lakes and feature stores immediately. Identify any datasets containing biometric information, especially facial images. Trace the lineage of this data. If it was acquired through untargeted web scraping or uncurated CCTV footage, models trained on this data must be retrained from scratch using clean datasets. Implement automated checks in your continuous integration and continuous deployment pipelines to flag unverified data sources before they enter the training loop. This means updating your data ingestion scripts to automatically drop or quarantine image data lacking explicit consent metadata. The untargeted scraping prohibition is absolute, and regulators will look at your training data provenance just as closely as your final model weights.
Step 2: Objective Function Analysis for RL and Recommenders
For teams deploying recommendation engines or reinforcement learning agents, review your loss functions and reward structures. Are you optimizing solely for engagement metrics without guardrails? The EU AI Act prohibits subliminal manipulation that materially distorts behavior and causes harm. Implement constraints in your training loops that penalize the model for serving content that exploits known vulnerabilities, such as age or socioeconomic status. Document these constraints thoroughly, as regulators will request access to your model cards and training parameters during an audit. You must mathematically prove that your optimization targets do not cross the line into prohibited deceptive techniques.
Step 3: Deployment Context Mapping and API Controls
A model's compliance status often depends on where it is deployed. Map every API endpoint to its end-user application. If you provide a natural language processing sentiment analysis API, update your Terms of Service to explicitly forbid its use for employee monitoring, and implement usage monitoring to detect violations. You must maintain a clear boundary between your general-purpose infrastructure and the specific, potentially prohibited applications built on top of it. If a customer uses your API for workplace emotion recognition, and you lack the controls to detect or stop it, you risk shared liability under the Act.
The Extraterritorial Trap for Non-EU Teams
A dangerous misconception among United States and Asian engineering teams is that the EU AI Act applies only to European companies. The regulation operates on a strict extraterritorial basis. According to the Act, providers and deployers outside the European Union are in scope whenever the AI output is intended for use in the Union.
The Illusion of Geographic Immunity
If you host a prohibited AI system on servers in Virginia, but European users can access the application and experience its effects, you are liable. The location of your compute infrastructure does not shield you from the maximum penalty of 35 million euros or seven percent of global annual turnover. The argument that your corporate headquarters is not based in Europe holds absolutely no legal weight. Regulators focus on where the impact of the AI system occurs, not where the model weights are stored. If your system performs social scoring or subliminal manipulation on EU citizens, you are violating Article 5.
Provider Versus Deployer Liability
Furthermore, your role in the supply chain dictates your obligations. The Act distinguishes between providers, who develop and market the system, and deployers, who use the system under their authority. If you procure an open-source model, fine-tune it for a prohibited use case, and deploy it to EU customers, you become the provider of a prohibited system. You cannot pass the liability upstream to the original model creators. You own the compliance burden for the final deployed artifact.
Supply Chain Contamination Risks
This extraterritorial reach also affects business-to-business software vendors. If you build an API that performs emotion recognition and sell it to an enterprise customer who deploys it in their European offices, your technology is facilitating a prohibited practice. Engineering teams must implement strict geographical fencing or robust contractual and technical safeguards to prevent their tools from being utilized in banned contexts within the EU. Failure to audit your downstream users can result in severe regulatory action, making compliance a mandatory component of your global deployment strategy.
Infrastructure, Data Sovereignty, and Compliance
While Article 5 dictates what you cannot build, the broader EU AI Act and GDPR dictate how you must build and host compliant systems. For high-risk and limited-risk systems, proving data residency and maintaining strict operational controls are mandatory steps toward compliance.
The Risks of Shared Hyperscaler Infrastructure
Renting shared infrastructure from hyperscalers introduces significant compliance ambiguity. When you cannot guarantee exactly where your data is processed, or when your provider relies on complex international data transfers, passing an ISO 27001 or AI Act conformity assessment becomes difficult. EU-regulated teams need provable data residency to ensure that training data and model outputs do not inadvertently cross borders into jurisdictions with weaker privacy protections. Relying on opaque cloud environments makes auditing data provenance nearly impossible.
Sovereign GPU Infrastructure with Lyceum
Lyceum Technology provides EU-sovereign GPU cloud infrastructure, ensuring all data stays strictly within European data centers. By owning the infrastructure, Lyceum offers structural cost advantages and complete transparency over the hardware running your models. This sovereignty is critical for teams building high-risk systems that require rigorous documentation and localized data processing to meet the August 2026 compliance deadlines.
High-Performance Instances and Open Architecture
When provisioning a virtual machine through Lyceum, users get raw GPU access via SSH in 18 seconds. H100 instances offer a significant cost reduction compared to hyperscaler alternatives. The platform operates on an open-stack philosophy utilizing vLLM and NVIDIA Dynamo, ensuring teams avoid the vendor lock-in associated with proprietary inference engines. This flexibility allows engineering teams to maintain full control over their software stack while meeting strict regulatory requirements.
Optimized Resource Management for Compliance Workloads
For teams managing complex training runs, the Pythia AI Scheduler predicts VRAM requirements and automates GPU selection to deliver significant cost savings per job. Lyceum offers flexible billing with no minimum commitments, and S3-compatible storage comes with zero egress fees. If you need to deploy inference endpoints, you can host any large language model on the platform and serve it via an OpenAI-compatible API. Because the system can scale to zero, you pay only when serving traffic, combining the developer experience of managed APIs with the security of dedicated infrastructure.
Audit Readiness for the August 2026 High-Risk Deadline
With prohibited systems officially banned as of February 2025, the next critical milestone for engineering teams is August 2, 2026. On this date, the stringent requirements for high-risk AI systems, outlined in Annex III of the EU AI Act, take full effect.
Identifying High-Risk AI Systems
If your models are used in critical infrastructure, education, employment, essential private services, or law enforcement, they are likely classified as high-risk. Unlike prohibited systems, high-risk systems are allowed to operate, but they require massive operational oversight. You must implement continuous risk management systems throughout the model lifecycle as mandated by Article 9. This requires identifying known and foreseeable risks, implementing mitigation measures, and testing their effectiveness before deployment. Teams can no longer deploy models and monitor them reactively.
Mandatory Data Governance and MLOps
Data governance, covered under Article 10, becomes a strict legal requirement rather than an engineering suggestion. You must ensure training datasets are relevant, representative, and free of errors. This necessitates rigorous MLOps pipelines that track data provenance, model lineage, and evaluation metrics. If your model exhibits bias that leads to discriminatory outcomes in an employment screening tool, the lack of data governance documentation will be treated as a severe regulatory failure. You must prove that your datasets were audited for bias prior to the training phase.
Building a Compliance Architecture
Start by creating a comprehensive AI system inventory today. Document the intended purpose, input data types, output decisions, and affected user groups for every model in production. Map each system to its corresponding risk tier. This inventory serves as the foundation of your compliance architecture. Furthermore, establish automated logging for all model inferences to satisfy the traceability requirements. By integrating these compliance checks into your standard deployment pipelines now, you ensure your organization is fully prepared when the August 2026 deadline arrives, avoiding last-minute architecture overhauls.
Penalties and Enforcement Mechanisms for Prohibited Systems
Understanding the enforcement mechanisms of the EU AI Act is crucial for engineering leaders who must justify compliance budgets to executive teams. The penalties for violating Article 5 are designed to be punitive enough to deter even the largest global technology companies from deploying prohibited systems.
Maximum Financial Penalties
The financial consequences for operating a prohibited AI system are severe. Companies found in violation face fines of up to 35 million euros or seven percent of their global annual turnover from the preceding financial year, whichever figure is higher. This penalty structure significantly exceeds the maximum fines established under the General Data Protection Regulation. For multinational corporations, a seven percent global turnover fine could amount to billions of dollars, making the risk of deploying non-compliant models an existential threat to the business.
Market Surveillance and Regulatory Audits
Enforcement is not left to chance. The EU AI Act establishes a comprehensive market surveillance framework. National competent authorities within each EU member state are granted the power to audit AI systems, request access to source code, and review training datasets. If a regulator suspects that a model is performing untargeted biometric scraping or workplace emotion recognition, they can demand full access to your MLOps pipelines and model registries. Engineering teams must maintain audit-ready documentation at all times, as regulators will look for technical proof of compliance rather than accepting policy statements.
Immediate Decommissioning Orders
Beyond financial penalties, regulators possess the authority to order the immediate withdrawal or decommissioning of prohibited AI systems. If a system is found to violate Article 5, you will be forced to shut down the application instantly, resulting in severe service disruptions for your users. Furthermore, any downstream models or applications that rely on the prohibited system will also be compromised. This cascading effect highlights the importance of isolating potentially risky models and ensuring that your core infrastructure remains entirely free of prohibited AI practices.
Transitioning from Prohibited to Compliant Architectures
If your current model inventory includes systems that border on prohibited practices, you must execute a technical pivot to bring your architecture into compliance. This transition requires a systematic approach to model retraining, feature engineering, and deployment constraints.
Isolating and Removing Toxic Features
For systems that currently rely on social scoring or profiling, the first step is feature isolation. You must audit your feature stores and remove any data points that aggregate unrelated behavioral data or exploit vulnerabilities. For example, if a credit risk model currently ingests social media sentiment data, you must strip those features from the pipeline. Retrain the model using only objective, verifiable financial data. This process often results in a temporary drop in model accuracy, which engineering teams must communicate to stakeholders as the necessary cost of regulatory compliance.
Implementing Consent-Driven Data Ingestion
To resolve issues related to untargeted biometric scraping, teams must overhaul their data ingestion pipelines. Move away from bulk web scraping and implement consent-driven data collection mechanisms. If you require facial images for identity verification models, you must build user interfaces that explicitly request and document user consent before capturing biometric data. Update your ETL pipelines to automatically reject any image data that lacks a cryptographic signature verifying user consent. This ensures your training datasets remain uncontaminated by prohibited scraping practices.
Redefining the Deployment Context
In some cases, a model can be saved by strictly redefining its deployment context. If you have an emotion recognition model currently deployed in a workplace setting, you must immediately disable it for those users. However, if the same model architecture can be repurposed for a permitted use case, such as a safety-critical driver monitoring system, you can migrate the model to the new context. This requires implementing hard technical constraints, such as API rate limits and geographic fencing, to guarantee the model cannot be accessed by enterprise HR departments or educational institutions.