When Prohibited AI Practices Applies and What to Do Next

Prohibited AI practices apply when a SaaS team builds, buys, embeds, configures, sells, or internally uses an AI system in a way that may fall inside Article 5 of the EU AI Act. The practical answer is not to debate the whole AI Act every time. It is to run an early screen for the prohibited categories, stop clearly unacceptable uses, redesign risky workflows, and escalate uncertain cases before the product, vendor contract, or internal process becomes hard to change.

Article 5 is a narrow but serious gate. It covers AI practices the law treats as unacceptable, including harmful manipulation, exploitation of vulnerabilities, certain social scoring, some criminal-risk assessment based only on profiling or personality traits, untargeted scraping of facial images to build facial-recognition databases, emotion recognition in workplaces and education except for medical or safety reasons, sensitive biometric categorisation, and real-time remote biometric identification in publicly accessible spaces for law-enforcement purposes except within narrow exceptions. The first AI Act rules on prohibited practices started applying on 2 February 2025, so this is already an operating question for teams serving EU markets.

For SaaS operators, the right next step is a repeatable workflow: identify the AI use case, map the affected people and data, ask the Article 5 screening questions, assign an owner, record the conclusion, and connect the decision to launch, vendor, privacy, security, and customer trust processes.

When the rule is likely to matter

The rule matters whenever AI affects people, not only when the feature is marketed as an AI product. A customer-facing assistant, an onboarding flow, a pricing nudge, a support-routing tool, an HR analytics system, a fraud workflow, an identity vendor, or a customer-configurable automation can all create Article 5 questions if the facts line up with a prohibited category.

Start with use and context. Does the system influence a person's decision or behaviour? Does it use hidden, manipulative, deceptive, or subliminal techniques? Does it exploit vulnerability linked to age, disability, or a specific social or economic situation? Does it evaluate people across unrelated contexts? Does it infer emotions in work or education? Does it use biometric data to infer sensitive traits? Does it scrape facial images from the internet or CCTV footage? Does it support public-sector, law-enforcement, education, employment, credit, essential-service, migration, safety, or identity workflows?

A low-level model integration can still matter if it changes how people are ranked, persuaded, monitored, classified, or denied access. The model name is less important than the purpose, data, affected people, output, and consequence.

When it may not apply

Not every AI feature triggers Article 5. A document summarisation tool, product analytics assistant, code helper, customer support draft generator, or internal knowledge search tool may be outside the prohibited categories if it does not manipulate people, exploit vulnerabilities, infer protected characteristics, perform banned biometric or emotion recognition, or support one of the restricted law-enforcement uses.

That does not make the feature compliance-free. It may still need AI system classification, privacy review, security review, vendor assessment, customer disclosure, or high-risk analysis. The point is sequencing. If there is no prohibited-practice red flag, the team can move into the ordinary AI governance path instead of treating every AI use as a stop decision.

Record that reasoning. A short decision saying "no Article 5 red flag identified based on current purpose, data, users, and configuration" is more useful than silence. It shows the team asked the right question at the right time.

What to do first

Begin with an intake screen that appears wherever AI enters the business: product discovery, model selection, vendor onboarding, privacy review, security review, customer-specific configuration, and internal tool approval. The intake should be short enough for product and engineering teams to complete without legal translation.

Capture the system name, owner, intended purpose, affected people, AI Act role, vendor or model, data categories, geography, user groups, customer configuration options, and whether outputs influence decisions or behaviour. Then ask direct screening questions for each prohibited category. The goal is not for the first-line owner to make a final legal interpretation. The goal is to decide whether the case can proceed, must stop, or needs review.

Use three routes. Clear no-red-flag cases proceed to ordinary AI classification and risk review. Clear red-flag cases stop until the team redesigns the use case or obtains specialist approval that the facts are outside the prohibition. Uncertain cases go to a named reviewer with a deadline and enough evidence to decide.

Evidence to keep

Keep evidence that explains what was reviewed, why the conclusion was reached, and what would cause the decision to be reopened. At minimum, retain the intake answers, product or vendor description, data-flow note, screenshots or configuration notes, affected-person analysis, prohibited-practice conclusion, rationale, reviewer, date, required restrictions, and next review trigger.

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, facial-image sources, model training, behavioural influence, or customer configuration. Vendor labels such as "engagement", "insight", "safety", "sentiment", or "personalisation" are not enough by themselves. The evidence should show what the system actually does.

Store the decision where work already happens. A product ticket, vendor record, privacy review, launch checklist, or customer trust evidence folder is often better than a standalone spreadsheet that nobody checks before release.

Common SaaS scenarios

A product team adds AI-driven prompts to improve trial conversion. Personalisation is not automatically prohibited, but the review should ask whether the prompts rely on hidden manipulation, materially distort user behaviour, exploit vulnerable users, or are reasonably likely to cause significant harm. If the answer is uncertain, redesign toward transparent assistance, user control, and ordinary analytics.

An HR or enablement tool claims to measure worker engagement from voice, face, or meeting behaviour. Because Article 5 addresses emotion recognition in workplaces and education, this should not be treated as routine productivity analytics. Stop the launch and obtain specialist review before a pilot.

A security or identity vendor offers face matching and says its database is expanded from public images. That is a direct red flag for untargeted facial-image scraping and facial-recognition databases. The SaaS team should require source-data evidence, legal review, contractual restrictions, and a decision before embedding or reselling the capability.

A customer asks to configure an AI workflow for employee ranking, student assessment, fraud investigation, or public-sector decisions. Even if the default product looks low risk, customer configuration can change the context. Sensitive configurations need guardrails, disabled options, contractual limits, review workflows, or escalation.

Common mistakes

The first mistake is waiting until launch. By then the customer promise, vendor contract, product design, and engineering work may already assume the use case is acceptable. Screening belongs near the start.

The second mistake is checking only customer-facing features. Internal tools can affect workers, applicants, support users, account teams, security investigations, and customer outcomes. They deserve the same first screen when AI influences people.

The third mistake is treating human review as a cure-all. Human oversight can matter, but it does not automatically fix a system built on prohibited manipulation, sensitive biometric inference, or an unacceptable purpose.

The fourth mistake is recording only approvals. Rejections, redesigns, and blocked vendor features are strong evidence that the control works. Keep them.

Connect it to the operating model

Ownership should be explicit. Product owns the purpose, user journey, configuration, and release facts. Engineering owns the data flow, model integration, logs, and technical controls. Security owns vendor and access review. Legal or compliance owns the Article 5 analysis and evidence standard. An AI governance owner should maintain the intake, track decisions, and confirm the launch gate works.

This connects naturally to existing ComplySafe workflows. Use the prohibited-practice screen alongside AI governance expectations for SaaS vendors, the compliance owner model, internal AI-tool review, and the broader EU AI Act SaaS provider analysis.

The practical goal is simple: make Article 5 visible early enough that teams can move faster with fewer surprises.

FAQ

What is the practical purpose of prohibited AI practices?

The purpose is to identify AI uses that should be blocked, redesigned, or escalated before they become part of a product, vendor workflow, customer configuration, 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 that may touch Article 5 categories such as harmful manipulation, exploitation of vulnerabilities, certain social scoring, some biometric uses, emotion recognition in work or education, or untargeted facial-image scraping.

What should teams document or change first?

Start with an intake screen, a decision route, a named reviewer, release-blocking rules, and a minimum evidence package connected to product, vendor, privacy, security, and customer trust workflows.

Is this only a legal issue?

No. Legal interpretation matters, but the operating work sits across product, engineering, security, privacy, vendor management, and customer trust. Those teams hold the facts needed for a defensible decision.

What happens if the team is unsure?

Do not let uncertainty disappear into a backlog. Route the case to a named reviewer, set a response target, keep the evidence, and block launch only for the specific use case or configuration that needs review.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidelines on prohibited artificial intelligence practices.
• European Commission note on the first AI Act rules becoming applicable.