Prohibited AI Practices: Practical Guide for SaaS Teams

Prohibited AI practices are AI uses that SaaS teams should block before they reach a customer, employee, vendor workflow, or internal launch. Under Article 5 of the EU AI Act, the prohibited category covers a limited set of practices that the law treats as unacceptable, including harmful manipulation, exploitation of vulnerabilities, certain social scoring, some predictive policing uses, untargeted facial-image scraping, emotion recognition in workplaces and education, sensitive biometric categorisation, and real-time remote biometric identification in publicly accessible spaces for law enforcement except within narrow exceptions.

For SaaS operators, the practical answer is simple: do not wait until a lawyer reviews a finished feature. Build a pre-launch screen that asks whether an AI use case could fall into one of the prohibited categories, routes uncertain cases to review, blocks clearly unacceptable uses, and keeps evidence of the decision. The workflow should cover product features, internal tooling, embedded vendor systems, model integrations, and customer-configurable automations.

The European Commission's guidelines are intended to support consistent application of the AI Act across the EU, while the Court of Justice of the European Union remains the authoritative interpreter. That matters for operating teams: the checklist should be strong enough to prevent obvious issues, but ambiguous cases still need legal review.

Why prohibited-practice screening matters

Prohibited-practice screening is the front door of AI governance. If a use case is prohibited, the team should not spend weeks designing ordinary controls around it. The right operational response is to stop, redesign, narrow the use case, or escalate before the work becomes embedded in a product roadmap or customer commitment.

This matters especially in SaaS because AI functionality often enters the business quietly. A product team may add behavioural nudges to improve activation. A customer success team may adopt an AI tool to score account health. An HR team may test emotion analytics in training sessions. A vendor may add biometric or profiling functionality inside a platform the SaaS company already uses. These changes can look small in a ticket queue, but they may change the legal and ethical posture of the service.

Screening also helps with commercial readiness. Enterprise buyers increasingly ask whether vendors have AI governance controls, whether AI features can manipulate users, whether biometric or emotion data is processed, and whether the company can explain the boundary between acceptable automation and unacceptable use. A documented prohibited-practice screen gives the sales, security, legal, and product teams a shared answer.

What Article 5 covers in practice

Article 5 is not a general ban on AI. It is a set of specific prohibitions. SaaS teams should translate those prohibitions into practical questions.

First, check for manipulative, deceptive, or subliminal techniques that materially distort behaviour and impair informed decision-making in a way that causes, or is reasonably likely to cause, significant harm. In product terms, ask whether the system uses hidden or purposefully manipulative techniques to push a person toward a decision they would not otherwise make.

Second, check for exploitation of vulnerabilities. The AI Act addresses systems that exploit vulnerabilities linked to age, disability, or a specific social or economic situation in a way that materially distorts behaviour and causes, or is reasonably likely to cause, significant harm. For SaaS teams, the review should ask whether the system targets or adapts to vulnerable users in a way that changes their choices to their detriment.

Third, check for social scoring. The prohibition is aimed at certain systems that evaluate or classify people or groups based on social behaviour or personal or personality characteristics where the output leads to detrimental or unfavourable treatment in unrelated contexts or treatment that is unjustified or disproportionate.

Fourth, check for criminal-risk assessment based solely on profiling or personality traits. This is less common for ordinary B2B SaaS, but teams that sell analytics, public-sector tooling, identity products, security tooling, or risk scoring should not assume it is irrelevant.

Fifth, check for untargeted scraping of facial images from the internet or CCTV footage to create or expand facial recognition databases. If any product, vendor, dataset, or model-training workflow touches facial recognition, require deeper review.

Sixth, check for emotion recognition in workplace or education settings, except where the system is intended for medical or safety reasons. This is relevant beyond HR software. Training tools, productivity analytics, online learning, coaching, and workforce platforms may all need a hard review if they infer emotions.

Seventh, check for biometric categorisation that uses biometric data to infer sensitive traits such as race, political opinions, trade union membership, religious or philosophical beliefs, sex life, or sexual orientation.

Eighth, check for real-time remote biometric identification in publicly accessible spaces for law-enforcement purposes. Most SaaS teams will not deploy this directly, but vendors serving public-sector, security, venue, retail, or smart-city markets should route it to specialist review.

Build a SaaS screening workflow

The workflow should be short enough that product and engineering teams will use it, but serious enough that it catches the red flags before launch.

Start with an AI intake question in product review, vendor review, security review, privacy review, and internal tool approval. The question should not be "Is this prohibited?" because most teams will not know. Ask operational questions instead: Does the system influence a person's decision? Does it use hidden, manipulative, or deceptive techniques? Does it target children, workers, applicants, economically vulnerable users, or people with disabilities? Does it evaluate people across contexts? Does it process biometric data? Does it infer emotions? Does it scrape face images? Does it support law-enforcement, public safety, education, employment, credit, migration, or essential-service workflows?

Then route the answer. Clear "no" answers can proceed to ordinary AI classification and risk review. Clear "yes" answers should stop until legal and compliance approve a redesign or confirm that the use case is outside the prohibition. Uncertain answers should go to a named reviewer instead of disappearing into a generic risk register.

Give the reviewer a decision template. It should capture the system name, owner, vendor, model or service, intended purpose, affected people, data categories, geography, AI Act role, prohibited-practice questions, conclusion, rationale, required changes, approver, and next review trigger.

Finally, connect the decision to release management. A prohibited-practice screen that lives in a spreadsheet will fail if launch approval does not check it. Add the decision record to the product launch checklist, vendor onboarding record, customer-facing AI documentation, and audit evidence folder.

Evidence to keep

The evidence does not need to be theatrical. It needs to be retrievable and specific.

Keep the intake form, the product or vendor description, the data-flow note, the affected-user analysis, screenshots or configuration notes, the prohibited-practice decision, the rationale, the legal or compliance reviewer, the date, and any redesign action. If a vendor is involved, keep the vendor's AI documentation, contractual commitments, security questionnaire answers, and any statement about biometric data, emotion recognition, profiling, model training, or user manipulation.

Evidence should also show when the team will revisit the decision. Reassessment should happen when the feature changes purpose, reaches a new user group, enters a new market, adds new data sources, changes human review, enables customer configuration, or receives new regulatory guidance.

This evidence helps the team answer three practical questions: what did we review, why did we decide it was acceptable, and what would cause us to reopen the decision?

Common mistakes

The first mistake is treating prohibited-practice review as a late legal sign-off. By the time a feature is ready for release, the product design, customer messaging, vendor contract, and engineering work may already assume that the use case is acceptable. Screening belongs near the start of the workflow.

The second mistake is checking only customer-facing features. Internal tools can create risk too, especially when they affect workers, applicants, training, productivity scoring, account prioritisation, fraud review, support escalation, or security investigations.

The third mistake is relying on vendor labels. A vendor may call a feature "insight," "engagement," "sentiment," "safety," "identity," or "personalisation." The compliance question is what the system actually does, whose data it uses, and how the output affects people.

The fourth mistake is assuming "human in the loop" solves everything. Human review may be important, but it does not automatically cure a use case that is built on prohibited manipulation, sensitive biometric inference, or an unacceptable purpose.

The fifth mistake is failing to record negative decisions. If the team rejects or redesigns a feature because of prohibited-practice concerns, keep that evidence. It shows the control worked.

Example scenarios

Consider a SaaS onboarding flow that uses AI to personalise prompts. Personalisation is not automatically prohibited. But if the system uses hidden manipulative techniques to materially impair decision-making and push vulnerable users into harmful choices, the team has a serious red flag. The safer path is to redesign the flow around transparent assistance, user control, and ordinary product analytics.

Now consider an HR platform that wants to infer worker emotions during video meetings to measure engagement. Because Article 5 addresses emotion recognition in workplace and education settings, this should not be treated as a routine analytics feature. The team should stop the launch and obtain specialist review before any pilot.

Or consider a security vendor that offers face matching by expanding a database from scraped public images. That touches one of the clearest Article 5 concerns. A SaaS company embedding or reselling that capability should not rely on generic vendor assurances; it needs a direct review of the source data, purpose, customer controls, and legal basis.

These examples show why prohibited-practice screening must look at use, context, affected people, and data, not just the model name.

How to operationalize ownership

Product should own the facts about the use case. Engineering should own the architecture, data flow, model integration, logging, and configuration details. Security should own vendor and access review. Legal and compliance should own the prohibited-practice analysis and evidence standard. Leadership should own risk acceptance when a feature is sensitive, ambiguous, or commercially important.

The owner model should be explicit. If everyone can flag a concern but nobody owns the decision, the process will slow down and evidence will fragment. A practical model is to assign one AI governance owner who maintains the intake, routes reviews, tracks decisions, and confirms that launch checklists include the result.

Tie the workflow to existing governance rather than creating another isolated channel. Add prohibited-practice questions to privacy impact reviews, security design reviews, vendor risk assessments, AI system classification, customer trust documentation, and incident response. That way, the same facts support multiple compliance needs.

FAQ

What is the practical purpose of prohibited ai practices?

The practical purpose is to identify AI uses that should be blocked, redesigned, or escalated before they become part of a product, vendor workflow, or internal process.

When does prohibited ai practices apply to SaaS teams?

It applies when a SaaS team builds, buys, embeds, sells, configures, or uses AI in a way that may touch Article 5 categories such as harmful manipulation, exploitation of vulnerabilities, social scoring, certain biometric uses, emotion recognition in workplace or education, or facial-image scraping.

What should teams document or change first?

Start with an intake screen, a decision record, a named reviewer, and a launch gate. Then connect the result to product review, vendor review, privacy review, security review, and customer trust evidence.

Is this the same as high-risk AI classification?

No. Prohibited practices are a stop-or-redesign category. High-risk classification is a separate route for AI systems that may be permitted but subject to stricter obligations.

Can a vendor's assurance replace our own review?

No. Vendor documentation is useful evidence, but the SaaS team still needs to understand how the system is used in its own product or operations, what data it processes, and how outputs affect people.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidelines on prohibited artificial intelligence practices.
• European Commission studies on Article 5 of the AI Act.