Prohibited AI Practices Checklist for Founders and Compliance Leads

Prohibited AI practices are AI uses that should be blocked, redesigned, or escalated before they reach production. For founders and compliance leads, the useful question is not only "does Article 5 of the EU AI Act apply?" The useful question is whether the company has a repeatable way to spot unacceptable AI use early, stop obvious cases, and document the decision before a product launch, vendor rollout, or customer review.

The checklist below turns the prohibition into an operating workflow. Use it when your team builds AI features, embeds third-party AI, buys internal tools, supports regulated customers, or changes how an AI output affects people. The European Commission's prohibited-practices guidelines explain the Commission's interpretation and examples, but they are non-binding; final interpretation belongs to the Court of Justice of the European Union. That means the checklist should catch red flags and create evidence, while uncertain cases still go to legal review.

1. Confirm the AI use case is in scope

Start with a plain description of the system. Record the product, workflow, owner, vendor, model or service, intended purpose, users, affected people, data categories, geography, and whether the AI output influences a decision.

Ask:

• Is the system built, bought, embedded, configured, or used by the company?
• Is it customer-facing, internal, or part of a vendor workflow?
• Does it influence people, rank people, evaluate people, infer traits, process biometric data, or change access to a service?
• Could the system affect EU users, workers, applicants, learners, customers, or other natural persons?

If the answer is clearly no, keep the record and proceed to ordinary AI governance. If the answer is yes or unclear, continue the prohibited-practice screen.

2. Screen for harmful manipulation or deception

Article 5 addresses certain AI systems that use subliminal, purposefully manipulative, or deceptive techniques in a way that materially distorts behaviour, impairs informed decision-making, and causes or is reasonably likely to cause significant harm.

For a SaaS team, this is a product-design question as much as a legal question. Check whether the system hides material information, adapts pressure tactics to a person, steers users toward harmful decisions, or uses AI-generated interaction patterns that people would not reasonably understand.

Evidence to keep:

• the user journey or workflow screenshot
• the personalization or recommendation logic
• the user groups affected
• the harm analysis
• the mitigation or redesign decision

If the system relies on hidden pressure or deceptive influence, stop the launch until the design is reviewed.

3. Check whether the system exploits vulnerability

The AI Act separately addresses exploitation of vulnerabilities linked to age, disability, or a specific social or economic situation when the system materially distorts behaviour and causes, or is likely to cause, significant harm.

Ask whether the AI feature targets, profiles, adapts to, or pressures vulnerable people. This may matter for products used by children, patients, students, workers, consumers in financial distress, people seeking essential services, or people with disabilities.

The operational control is simple: require a vulnerable-user review before launch when the system personalizes persuasion, prioritization, eligibility, pricing, support, or enforcement. Record whether vulnerable groups are excluded, protected with additional safeguards, or exposed to the system.

4. Rule out social scoring and unrelated penalties

Social scoring risk appears when an AI system evaluates or classifies people over time based on social behaviour or personal characteristics and leads to unfavourable treatment in unrelated contexts, or treatment that is unjustified or disproportionate.

Most B2B SaaS products are not designed as public social scoring systems, but the pattern can appear in account health, trust, fraud, safety, employee, education, community, or marketplace tools. Look for scoring that follows a person across contexts and changes access, priority, price, moderation, support, or opportunity.

Your decision record should explain what the score is used for, whether it affects natural persons, whether the context is related to the original data, and whether the treatment is proportionate.

5. Review criminal-risk, biometric, and emotion-recognition features

Some red flags require immediate specialist review.

Escalate if the system:

• assesses the risk of a person committing a criminal offence based solely on profiling or personality traits
• creates or expands facial-recognition databases through untargeted scraping of facial images from the internet or CCTV footage
• infers emotions in workplace or education settings, except for medical or safety reasons
• uses biometric data to infer sensitive traits such as race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation
• supports real-time remote biometric identification in publicly accessible spaces for law-enforcement purposes

These topics are easy to miss because vendors often describe them with softer words such as sentiment, engagement, safety, identity, insight, or trust. Review what the system actually does, not just the label.

6. Assign a decision owner and reviewer

Every prohibited-practice screen needs two roles. The business owner supplies the facts. The reviewer decides whether the use case can proceed, needs redesign, or must be blocked.

For SaaS teams, the business owner is often product, engineering, security, HR, customer operations, or vendor management. The reviewer should be legal, compliance, privacy, or a named AI governance owner with a route to legal support.

Do not let the decision sit in a chat thread. Use a short record with:

• system name and owner
• intended purpose
• affected people
• vendor or model provider
• prohibited-practice questions answered
• conclusion
• rationale
• required changes
• approver
• next review trigger

7. Tie the screen to launch and vendor gates

A checklist only works if it changes the release path. Add prohibited-practice questions to product intake, security design review, privacy impact review, vendor onboarding, internal tool approval, and customer-facing AI documentation.

Set a clear rule: no AI feature, AI vendor, or AI-enabled internal workflow launches until the prohibited-practice screen is complete or a reviewer confirms it is not required. For lower-risk cases, the record can be short. For sensitive cases, attach product notes, data-flow notes, vendor evidence, screenshots, and legal review.

This also helps sales and trust teams. When a customer asks whether the company uses prohibited AI practices, the answer should come from a decision log, not from memory.

The gate should also say what happens when the answer is uncertain. A practical escalation path has three outcomes. The reviewer can approve the use case as outside the prohibited categories, approve it only after specific design changes, or block it until legal review is complete. Avoid vague statuses such as "monitor" or "to be discussed" when a launch is moving. If the team needs more facts, assign a named owner and due date so the release decision does not drift into informal approval.

8. Define triggers for re-review

A decision can become stale. Reopen the checklist when:

• the intended purpose changes
• the system reaches a new user group or market
• the vendor changes model behaviour or data processing
• new data categories are added
• outputs move from advisory to automated action
• customers can configure the system in a materially different way
• new EU guidance or enforcement changes the risk analysis

Record the trigger in the original decision. A good checklist does not only say what the team decided today; it says what would make the team look again.

Example checklist decisions

Consider a customer-support tool that uses AI to summarize tickets and suggest replies. That is not automatically a prohibited practice. The checklist should still record the intended purpose, the affected people, the vendor, the data used, and whether the output influences access, pricing, escalation, or enforcement. If the tool only assists support agents and does not manipulate or classify customers in a harmful way, the record may be short.

Now consider an employee-productivity tool that claims to infer stress, attention, or emotion from video meetings. Because Article 5 addresses emotion recognition in workplace settings, this should not move through an ordinary procurement flow. The right checklist outcome is escalation, with no pilot until the team has legal and compliance review.

Or consider a growth feature that uses AI to identify financially vulnerable users and serve more aggressive upgrade prompts. The commercial goal may look ordinary, but the combination of vulnerability, personalization, behavioural influence, and potential harm should trigger redesign or rejection. The checklist is doing its job when it changes the product path before engineering time is spent.

Common mistakes

The first mistake is screening only customer-facing features. Internal tools can still affect workers, applicants, support queues, fraud decisions, security investigations, or customer outcomes.

The second mistake is accepting vendor marketing language. A vendor may say "engagement analytics" or "identity intelligence" while the underlying feature processes biometric data, infers emotion, or profiles people.

The third mistake is treating human review as a universal fix. Human oversight may reduce risk, but it does not automatically make a prohibited use acceptable.

The fourth mistake is recording only approved decisions. Rejected and redesigned use cases are important evidence because they show the control is working.

The fifth mistake is separating this checklist from the broader AI inventory. Prohibited-practice review should feed the same source of truth used for AI system classification, vendor risk, privacy review, security review, and customer trust answers. Otherwise the company may have one team saying a use case is low risk while another team has already identified a serious Article 5 concern.

FAQ

What is the practical purpose of prohibited ai practices?

The purpose is to stop unacceptable AI use before it becomes part of a product, vendor relationship, internal workflow, or customer commitment.

When does prohibited ai practices apply to SaaS teams?

It may apply when a SaaS team builds, buys, embeds, sells, configures, or uses AI that manipulates people, exploits vulnerability, scores people across contexts, processes biometric data, infers emotion in work or education, scrapes facial images, or supports certain law-enforcement biometric uses.

What should teams document or change first?

Start with an intake screen, a decision owner, a reviewer, a short conclusion template, and a launch gate. Then connect the record to vendor review, privacy review, security review, and customer trust evidence.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidelines on prohibited artificial intelligence practices established by Regulation (EU) 2024/1689.