Define the system
Start by naming the AI feature, users, decision impact, data categories, vendors, and the team member responsible for maintaining the review record.
Risk screening
Prohibited AI Practices Under the EU AI Act
Some AI use cases should be stopped before a normal product launch checklist begins. This page gives product teams a plain-English way to spot practices that may fall into the EU AI Act prohibited category.
Disclaimer: This guide is for general operational planning. It is not legal advice, and it does not replace review by qualified counsel for a specific product, market, or customer deployment.
Fast stop signals
| Practice to screen | Why it needs immediate review |
|---|---|
| Manipulative or deceptive AI patterns | The system may materially distort a person's behavior or decision-making in a way that can cause significant harm. |
| Exploiting vulnerable people | The feature targets or takes advantage of age, disability, social situation, or economic vulnerability. |
| Social scoring | The system ranks people or groups in a way that affects treatment across contexts or creates unjustified disadvantage. |
| Predictive policing based only on profiling | The system estimates criminal risk mainly from profiling, personality traits, or characteristics instead of objective, verifiable facts. |
| Untargeted facial image scraping | The product builds or expands facial recognition databases from broad web or CCTV scraping. |
| Workplace or education emotion inference | The system infers emotions in work or education settings, except for limited medical or safety reasons. |
| Sensitive biometric categorization | The system uses biometrics to infer sensitive traits such as political opinions, religion, sex life, race, or trade-union membership. |
| Real-time remote biometric identification in public spaces | Law-enforcement use in public spaces is tightly restricted and should not be treated as a normal SaaS feature. |
Product triage questions
- Could the AI pressure, trick, or steer a user without the user understanding what is happening?
- Does the system make or influence decisions about people outside the original context where data was collected?
- Does the feature involve biometric identification, biometric categorization, emotion recognition, or facial image collection?
- Does the system affect vulnerable users, children, workers, students, applicants, tenants, borrowers, or people seeking public services?
- Would a reasonable reviewer describe the feature as surveillance, scoring, profiling, or behavioral control?
What to do when a signal appears
- Pause the launch path for that use case.
- Write the intended purpose, user group, data categories, and real-world decision impact.
- Separate marketing claims from actual system behavior.
- Ask whether a safer, non-biometric, non-scoring, or human-led workflow can meet the product goal.
- Get specialist review before collecting production data or enabling the feature for EU users.
Official sources
Last reviewed: July 3, 2026.
- EU AI Act Article 5: prohibited AI practices
- EU AI Act Article 2: scope
- European Commission: AI Act regulatory framework
practical AI compliance self-assessment
Practical notes for Prohibited AI Practices Under the EU AI Act
Prohibited AI Practices Under the EU AI Act | Screening Guide is maintained for founders, product managers, compliance owners, agencies, and small teams building AI workflows who need AI governance workflow. The goal is to help visitors complete a real task and leave with an AI inventory, risk note, disclosure draft, vendor question set, policy outline, or review workflow report, not only read a generic summary.
Separate triage from advice
Use the generated output as first-pass operational triage. Legal, medical, hiring, credit, education, biometric, and public-sector uses still need specialist review.
Keep evidence
Save the output, assumptions, date, source links, and reviewer notes so the team can explain why a risk level, disclosure, or vendor question set was chosen.
Before relying on this page
- Review high-impact use cases manually.
- Keep policies and disclosures aligned with the real product behavior.
- Re-run the workflow when vendors, data, or user impact changes.
Review record
How to use Prohibited AI Practices Under the EU AI Act in an AI compliance file
A compliance tool is useful when it leaves a traceable record. The output should name the AI system, explain the assumptions, and show what the team still needs to verify with product, legal, security, or vendor owners.
Describe the real system
Record the feature name, user group, decision impact, data sources, vendor dependencies, and the human owner. A generic "chatbot" label is rarely enough. A hiring assistant, support summarizer, medical triage bot, and product recommender can have very different risk profiles even if they all use language models.
Separate signal from conclusion
Treat this page as first-pass triage. It can flag high-risk areas, transparency duties, missing evidence, and questions to ask a vendor. It should not be treated as legal approval, clinical advice, hiring approval, credit approval, or permission to launch without human review.
Save evidence and changes
Save the generated result with the date, reviewer, source links, and unresolved questions. Update the record when the model, data, users, product flow, vendor, or region changes. This keeps the site useful for actual operators rather than only being a static explanation page.
Evidence checklist
- Document what the AI system does and what it does not do.
- Record whether the system influences employment, education, credit, public benefits, healthcare, biometric identification, safety, or other high-impact outcomes.
- Keep vendor documentation, model notes, data descriptions, user notices, human oversight notes, and monitoring plans together.
- Re-run the review when the product behavior changes, not only when the law changes.
- Use specialist review for high-impact or regulated workflows before relying on any generated text.