The 2 February 2025 EU AI Act Enforcement Cliff
Prohibited practices and AI literacy already binding
2 February 2025 was supposed to be a wake-up call.
On that date, two categories of EU AI Act obligations became legally binding; and most organizations did not notice. The first was a set of categorically prohibited AI practices that no organization can use under any circumstances. The second was an obligation on every provider and deployer of AI systems to ensure their people have sufficient AI literacy. Both have been enforceable for over a year. Both are being actively investigated by national competent authorities. And both are on the short list of what a regulator will ask about first.
If you have not audited your AI systems against the prohibited practices list, you do not know whether you are lawful. If you cannot demonstrate when your staff last received AI literacy training and what that training covered, you cannot demonstrate compliance with Article 4. These are not August 2026 problems. They are February 2025 problems — and the grace period is over.
Part 1: Prohibited AI Practices
Article 5 of the EU AI Act categorically prohibits eight types of AI system. These prohibitions are absolute — they apply regardless of risk classification, regardless of sector, and regardless of whether the system is high-risk or minimal risk. If your system falls into any of these categories, it is prohibited. There is no conformity assessment path, no CE marking route, no derogation. It is simply not allowed.
Screening all deployed and in-development AI systems against these eight categories should be the first item in any EU AI Act compliance workstream. It is remarkable how few organizations have done it.
Article 5(1)(a) : Subliminal techniques beyond awareness. AI systems that manipulate persons through subliminal mechanisms causing physical or psychological harm are prohibited. The “beyond awareness” threshold is narrow : systems that use persuasive but visible techniques are not captured. Harm is the key determinant. If your recommender system uses subliminal pattern nudging that users cannot consciously perceive and that causes them to behave in ways they would not otherwise choose, it may be in scope.
Article 5(1)(b) : Exploiting vulnerabilities. AI systems that exploit age, disability, social or economic situation to distort behaviour in ways that cause harm are prohibited. “Exploiting” requires intent to cause harm — not merely the presence of a vulnerability. Systems that do not specifically target vulnerability for distortion purposes are not captured. But a dark pattern designed to target compulsive gamblers, or a system that exploits cognitive vulnerabilities in elderly users to drive harmful purchasing behaviour, is a clear example of what this provision captures.
Article 5(1)(c) : Social scoring. AI systems that evaluate or classify natural persons based on social behaviour or personal characteristics across multiple contexts, resulting in detrimental treatment, are prohibited. Differential treatment based on social behaviour across multiple contexts is the threshold. A credit scoring system that uses financial behaviour is not captured. A system that layers social media behaviour onto lending decisions and produces materially worse outcomes for a demographic group is.
Article 5(1)(d) : Criminal risk profiling beyond scope. AI systems that profile natural persons for risk assessment in a criminal context beyond the scope of a specific investigation are prohibited. The distinction from legitimate investigation support is the key boundary. A system that helps an officer identify whether a specific person is a suspect in a specific open investigation is not prohibited. A system that scores a person’s general “criminal risk” across unrelated contexts and feeds those scores into sentencing, parole, or pre-trial detention decisions is.
Article 5(1)(e) : Emotion recognition in workplace and education. AI systems that infer emotional states in workplace or educational institutions are prohibited, with narrow exceptions for medical safety uses and age verification for minors. A performance management system that infers frustration from keystroke patterns or facial expressions in a call centre is prohibited. A system that detects pain indicators in a medical context, or one that verifies age to restrict access to age-inappropriate content, is not.
Article 5(1)(f) : Biometric categorization for sensitive attributes. AI systems that use biometric data to infer race, religion, sexual orientation, disability status, or migration status are prohibited. This prohibits inferential categorization; it is not a prohibition on processing biometric data generally. A facial recognition system that infers ethnicity to filter for demographic parity in a hiring process is prohibited. A fingerprint system used purely for biometric authentication is not.
Article 5(1)(g) : Real-time remote biometric identification in public spaces. AI systems for real-time biometric identification of individuals in public spaces for law enforcement purposes are prohibited, with very narrow exceptions. Those exceptions require: judicial or independent authority authorization, a pre-existing suspect list, temporal and geographic limitations, and human oversight. A body camera that flags a face against a watchlist in real time without all of these conditions met is almost certainly prohibited.
Article 5(1)(h) : Manipulation through nudging. AI systems that manipulate human behaviour through nudging techniques exploiting cognitive vulnerabilities in ways that cause significant harm are prohibited. “Nudging” in this context means overriding autonomous decision-making. The harm threshold is high : routine personalisation and recommendation systems are not captured. But a system that deliberately exploits impulse control disorders or cognitive biases to drive addictive behaviour in ways that cause significant harm to users is.
These eight categories are mutually exclusive and collectively exhaustive. If an AI system falls into any one of them, it is prohibited. There is no conformity assessment path, no CE marking route, no derogation. The only correct response is to not build or deploy that system.
Part 2: AI Literacy - The Most Overlooked Obligation
Article 4 is the most consistently underestimated obligation in the entire EU AI Act. It has been binding since 2 February 2025. It applies to every organization that places AI systems on the EU market or deploys AI systems in EU operations; without exception, without size threshold, and without a gradual implementation period.
Who is covered ? Every provider of AI systems and every deployer of AI systems. “Provider” means any organization that develops an AI system and places it on the market or puts it into service under its own name. “Deployer” means any organization that uses an AI system in its own operations. If your company has an AI system in production (a customer-facing model, an internal tool, an automated decision system) you are a deployer. You are covered.
What is sufficient AI literacy ? The regulation does not prescribe a fixed curriculum or a minimum number of training hours. It defines AI literacy by reference to the organization’s use case and risk profile. Staff working with or alongside AI systems must understand : how the system works, what it can and cannot do, how to oversee its operation, and what incidents to report. That understanding must be documented. And it must be kept current as systems change.
The critical evidence is not whether you ran a training session. It is whether you can show what the training covered, who attended, when it occurred, and how it was updated when the system changed.
Why documentation is the compliance evidence ? A regulator will not ask whether your staff are “generally AI literate.” They will ask: which AI systems are in scope, which personnel groups interact with them, what training did those groups receive, how did you verify sufficient understanding, and when was it last updated. If you cannot answer each of those questions with a controlled document, you cannot demonstrate compliance.
This is the failure mode we see consistently : organizations that have done work in this area but cannot produce evidence that maps to those specific questions. A training attendance sheet that shows a one-hour session on “AI basics” does not demonstrate that the team understands the specific system they operate, its limitations, their oversight role, or the incident reporting path. It demonstrates only that they sat in a room.
What AI Literacy Looks Like
AI literacy is not a generic concept. It is specific to the systems people work with and the decisions they make alongside those systems. The difference between compliant and non-compliant AI literacy is operational specificity.
A warehouse operations team using an AI-powered inventory management system understands what the model does : it predicts demand spikes based on seasonal patterns and supplier lead times. They know what it cannot do : it cannot account for sudden macroeconomic shifts, trade disruptions, or pandemic-era demand anomalies. They know what their oversight role is : they review and override system-generated purchase orders above a defined threshold, and they know what that threshold is. They know what to escalate : when the system consistently under-orders for a specific product category, when demand patterns shift outside the model’s training distribution, when a supplier fails and the model does not adapt. All of this is documented in their operating procedures and reflected in their training records.
A customer service team deploying an AI chatbot knows what the chatbot can resolve autonomously and what it cannot : it can handle password resets and order status queries, it cannot handle contractual disputes or emotional distress calls. They understand when to escalate : the routing logic is visible to them, the escalation triggers are defined, and they know what “confidently wrong” looks like in their specific context. They know what data the system accesses : it reads the customer record and order history, not internal financial data. When the chatbot fails to escalate a case that it should have, they know the incident reporting path. This is operational AI literacy.
A software engineering team integrating a GPAI model via API has reviewed the model’s capability and limitation documentation : the model card, the acceptable use policy, the known limitations list. They understand the boundaries of what the provider has committed to versus what the team is responsible for. They know what constitutes a model failure in their context : when the model’s outputs consistently misalign with their internal knowledge base, when the model’s confidence calibration is wrong for their domain. They know the serious incident reporting path : they have documented what they would report to the provider and under what timeline, and they know that certain failures may trigger obligations under Articles 11 and 17.
A compliance team monitoring AI systems in production understands the logging mechanisms available for each system : what each system records, what the log format is, how to query it. They know what constitutes a reportable incident under the Act : a system failure that causes harm or that could have caused harm if not caught. They know the documentation retention requirements : how long logs must be preserved, which incidents require formal documentation versus informal tracking. They can demonstrate, within 24 hours of a regulator’s request, evidence of their post-market monitoring activities for any given system.
What AI Literacy Is Not
AI literacy is not a one-hour e-learning module on “What is Artificial Intelligence” completed once in 2023 and never updated. It is not a company-wide Slack message stating that employees should “use AI responsibly.” It is not a generic “Introduction to Machine Learning” course that covers neural networks and gradient descent without ever touching the systems your teams actually operate. And it is not a policy document that defines AI literacy in abstract terms without specifying what it means for each role and each system in your environment.
These are not hypothetical failures. They are the actual documentation we see when organizations first conduct their AI literacy gap analysis. The obligation has been binding for over a year with this level of specificity required. Many organizations are not close.
What Compliance Actually Requires Right Now
For prohibited practices : audit every deployed and in-development AI system against the eight categories before your next quarterly risk review. If any system falls into a prohibited category, the compliance path is not a documentation exercise; it is a product decision. Those systems either get redesigned outside the prohibited scope or they get retired.
For AI literacy : identify every AI system in your environment, map it to the personnel groups that interact with it, assess what each group needs to understand about that specific system, deliver and document training against those requirements, and establish a trigger for when that training must be refreshed. The trigger is always a system change, but annual refresh is a minimum baseline.
Both obligations have been enforceable since February 2025. National competent authorities are building enforcement caseloads. The organizations that have addressed these obligations face a regulator’s question. The organizations that have not face penalties.
AI Literacy Compliance Evidence Template
The AI Literacy Compliance Evidence Template is a structured document that maps your AI systems to personnel groups and generates the documentation trail required to demonstrate Article 4 compliance. It covers: system mapping, training topic documentation, evidence of delivery, acknowledgment records, and change-triggered refresh triggers.
Use it to close the gap before a regulator asks the question.
Next: Agentic AI and the EU AI Act - The Governance Gap No One Is Addressing