A prohibited AI practices checklist screens every AI use case against the EU AI Act’s Article 5 bans: harmful manipulation, exploitation of vulnerabilities, social scoring, predictive policing based solely on profiling, untargeted facial-image scraping, emotion recognition in workplaces and education, and restricted biometric practices. It is not a policy appendix. It is a front-line control for identifying whether an AI use case should be stopped, redesigned, or escalated before it creates regulatory exposure. For compliance, legal, and risk teams working against the EU AI Act, the hard part is rarely reading the prohibition. The hard part is applying it consistently across live systems, pilots, vendor tools, and business-led deployments that were never documented properly in the first place.
Why a prohibited AI practices checklist matters now
The EU AI Act does not treat prohibited practices as a soft governance issue. If a system or use case falls within a banned category, the question is not how to mitigate it into acceptability. The question is whether the activity must cease. That creates a very different workflow from ordinary risk management.
Many organisations still approach AI review as if every issue can be handled through controls, notices, or model testing. That is a mistake. Prohibited practices sit upstream of control optimisation. Before debating accuracy thresholds, human oversight, or record-keeping, you need a decision point on whether the intended purpose, deployment context, or behavioural effect is prohibited outright.
This is also where spreadsheet governance fails. Prohibitions are not easy to spot when AI inventory records are incomplete, ownership is vague, and procurement teams have approved tools under generic labels such as automation, analytics, or decision support. A workable checklist forces structured review at intake and gives second-line teams a defensible basis for challenge.
What a prohibited AI practices checklist should test
A useful prohibited AI practices checklist does not simply restate legal text. It translates the ban into operational questions that product owners, procurement leads, security reviewers, and compliance teams can answer with evidence. The checklist should be attached to intake, vendor assessment, and change management, not left sitting in a policy folder.
At minimum, the review should test five things. First, what the system is actually intended to do in practice, rather than what the supplier calls it. Secondly, who is affected and in what setting, including workers, consumers, children, vulnerable persons, or members of the public. Thirdly, whether the system influences behaviour, decisions, or treatment in a way that could trigger a prohibition. Fourthly, whether the organisation can evidence safeguards, purpose limitations, and legal basis. Fifthly, whether any part of the use case relies on prohibited data collection or prohibited forms of inference.
This sounds obvious until you review real deployments. Teams often describe a system as assisting human judgement, while internal process documents show that staff are expected to follow the score unless there is a clear reason not to. A supplier may call a feature sentiment analysis, while the practical effect is emotion recognition in a workplace or educational context. The naming does not decide the legal position. The substance does.
The prohibited categories compliance teams need to screen for
Harmful manipulation and deceptive influence
One screening question should ask whether the AI system uses subliminal techniques, deceptive techniques, or exploitative design to materially distort behaviour in a way that is likely to cause significant harm. This requires more than a generic review of user experience. You need to understand whether the system is intentionally engineered to bypass informed choice or exploit cognitive vulnerabilities.
The trade-off here is nuance. Not every persuasive design pattern is prohibited. Marketing personalisation, recommendation engines, or behavioural nudges are not automatically banned. The risk increases where the system targets vulnerabilities, conceals manipulation, or is deployed in contexts where individuals are less able to resist influence. Compliance review should focus on foreseeable effect, not just stated intent.
Exploitation of vulnerabilities
A separate question should address whether the system exploits vulnerabilities linked to age, disability, or a specific social or economic situation. This is particularly relevant in public services, financial stress scenarios, care settings, and products used by children. If the system is designed to pressurise, steer, or induce behaviour by taking advantage of a vulnerable condition, the use case requires immediate escalation.
Organisations often miss this because vulnerability is treated too narrowly. It is not limited to protected characteristics in an equality-law sense. Economic distress, dependency, limited digital literacy, and similar conditions may all be relevant depending on the context and deployment logic.
Social scoring
Your checklist should ask whether the system evaluates or classifies persons based on social behaviour, personal characteristics, or inferred traits in a way that leads to detrimental or unfavourable treatment that is either unrelated to the original data context or unjustified and disproportionate. This area is broader than many teams expect.
The key issue is not whether anyone uses the phrase social scoring. It is whether the organisation is generating composite trust, integrity, or behavioural scores and then using them to shape access, treatment, or scrutiny. Some internal fraud, HR, or customer risk models can drift towards this logic if governance is weak.
Predictive policing based solely on profiling
If your organisation operates in law enforcement or adjacent public-sector environments, the checklist should test whether any system predicts the risk of a natural person committing an offence based solely on profiling or assessment of personality traits or characteristics. That is a specific red flag and cannot be buried inside a broader analytics programme.
For most private-sector teams this may seem irrelevant, but consultancies, suppliers, and public-sector contractors should not assume they are outside scope. The operational question is simple: are you helping a client produce future-risk judgements about individuals in a way that matches the prohibited pattern?
Untargeted scraping for facial recognition databases
Another control point should ask whether any AI capability involves untargeted scraping of facial images from the internet or CCTV footage to build or expand facial recognition databases. If so, the issue is immediate. This is not a matter for later model assurance.
This matters not only to developers but also to downstream deployers procuring third-party biometric tools. Supplier diligence needs to test training data provenance and whether the vendor can demonstrate lawful sourcing. If they cannot, the procurement should stop.
Emotion recognition in work and education
Your prohibited AI practices checklist should explicitly ask whether the system infers emotions in workplaces or educational institutions, except where a narrow legal exception applies for medical or safety reasons. This is one of the areas where a product can be marketed as engagement analysis, attention tracking, or wellbeing support while still creating a prohibition issue.
The implementation challenge is classification. Teams need to distinguish between ordinary analytics, such as feedback surveys, and AI that purports to infer emotional states from biometrics, behaviour, voice, or facial signals. If the tool claims to detect stress, motivation, honesty, boredom, or similar states in staff or students, assume escalation is required.
Biometric categorisation and remote biometric identification
The checklist should also cover prohibited biometric categorisation based on sensitive attributes, and certain uses of real-time remote biometric identification in publicly accessible spaces for law enforcement, subject to tightly framed exceptions. Even where your organisation is not a public authority, supply-chain involvement matters. If you develop, customise, host, or materially support such capabilities, the governance review cannot be superficial.
How to operationalise the checklist
A checklist only works if it sits inside a decision process with ownership, evidence, and stop rules. That means every AI use case should have a named business owner, a legal reviewer, and a clear record of intended purpose, data categories, affected persons, deployment context, and supplier dependencies. If any prohibition trigger is met or cannot be ruled out, the workflow should force escalation and prevent progression to procurement, pilot, or production.
This is where structured governance platforms have a practical advantage over ad hoc reviews. If the prohibited-practice screening sits alongside AI inventory, classification, risk assessment, and audit evidence, you avoid the familiar problem of teams answering the same legal questions differently across procurement, security, and compliance. Endaxi AIG is designed for exactly this sort of operational consistency, especially where organisations need one system of record rather than another disconnected review form.
It also helps to define evidence standards. A yes or no answer is not enough. Reviewers should require policy documents, technical descriptions, data flow detail, supplier attestations, user interface samples, and deployment instructions where relevant. If the owner cannot evidence what the system does, the absence of documentation is itself a governance finding.
Common failure points
The biggest failure point is false reassurance from vendor language. Another is assuming that if a human remains in the loop, the prohibition disappears. It may not. A third is treating pilots as exempt from formal review. If a pilot uses real people, real data, or real operational decisions, it needs the same screening discipline as a production system.
There is also a timing issue. Prohibited practices screening should happen before contract signature, before deployment, and again when the use case changes. Scope creep is common. A tool acquired for workflow support can become a behavioural monitoring system six months later through feature expansion and local configuration.
The organisations that manage this well are not the ones with the longest AI principles documents. They are the ones that can show, system by system, who approved what, against which legal criteria, using which evidence, and what happened when a red flag appeared.
A good checklist does not create friction for its own sake. It creates an earlier, cheaper point of challenge. That is what compliance teams need when the question is not whether a control is strong enough, but whether the AI practice should exist at all.