Common Prohibited AI Practices Mistakes SaaS Teams Still Make

The most common prohibited AI practices mistake is treating Article 5 of the EU AI Act as a legal definition to remember instead of an operating control to run. SaaS teams may know that certain practices are prohibited, but still miss them in product planning, vendor review, internal tool approval, or customer-facing AI documentation.

The practical answer is to screen AI use before it reaches production. The screen should identify whether a system may involve harmful manipulation, exploitation of vulnerability, certain forms of social scoring, prohibited biometric uses, emotion recognition in workplace or education settings, untargeted facial-image scraping, or other Article 5 red flags. It should also assign an owner, record the decision, and define what would trigger re-review.

The European Commission's prohibited-practices guidelines help teams understand the Commission's interpretation, while the Court of Justice of the European Union remains the authoritative interpreter. For operators, that means the goal is not to improvise a final legal answer in every product meeting. The goal is to catch obvious issues, escalate ambiguous ones, and keep evidence that the company acted deliberately.

Mistake 1: Waiting until the feature is nearly ready

Many teams ask about prohibited practices at the end of the launch process. By then, the feature has a name, a customer promise, a roadmap dependency, a vendor contract, and engineering work behind it.

That timing makes compliance feel like a blocker. It also increases the chance that people defend the work because it already exists. A prohibited-practice screen belongs near product discovery, vendor intake, and internal tool approval, before the team is committed to a design.

The practical fix is simple: add a short AI red-flag screen before deeper development. Ask whether the system influences people, targets vulnerable groups, evaluates people across contexts, processes biometric data, infers emotion, or supports law-enforcement, education, employment, credit, public-sector, or essential-service workflows.

Mistake 2: Screening only customer-facing AI

Internal AI tools can create prohibited-practice risk too. A SaaS company may use AI to support hiring, worker monitoring, training, productivity analytics, fraud review, account prioritization, security investigation, or customer support escalation.

The fact that the system is internal does not make the affected people irrelevant. Workers, applicants, customers, users, and support contacts can all be affected by AI-assisted decisions. Emotion recognition in workplace settings is a particularly important example because it may appear in HR, training, meeting analytics, coaching, or productivity tools under ordinary procurement language.

The better control is to screen all AI systems by effect, not by audience. If the system changes how a person is evaluated, prioritized, monitored, persuaded, or treated, it deserves review.

Mistake 3: Trusting vendor labels too much

Vendors rarely describe risky features with risky language. A system may be sold as engagement intelligence, sentiment analytics, trust scoring, identity assurance, behavioural insight, safety automation, or productivity measurement.

Those labels are not the compliance analysis. The question is what the system actually does: what data it processes, what traits it infers, who is affected, whether biometric data is involved, whether the output changes treatment, and whether customers can configure the system into a higher-risk pattern.

Vendor documentation should be evidence, not a substitute for review. Keep the vendor's AI documentation, security answers, data-processing terms, model or feature description, and any statement about biometric data, emotion recognition, profiling, scraping, or manipulation. Then record your own conclusion for your own use case.

Mistake 4: Treating human review as a cure-all

Human oversight matters, but it does not automatically fix a prohibited design. A human approver may reduce error or add accountability, but the system may still be built around unacceptable manipulation, exploitation of vulnerable people, sensitive biometric inference, or another prohibited pattern.

This mistake appears when teams say "a person makes the final decision" and stop the analysis. A stronger review asks whether the AI system itself uses a prohibited technique or purpose, whether the human can realistically understand the output, and whether the person is likely to rubber-stamp the recommendation.

If the underlying use case is unacceptable, the answer is not more sign-off. The answer is to stop, redesign, narrow the feature, or obtain specialist legal review before any pilot.

Mistake 5: Confusing prohibited practices with high-risk classification

Prohibited practices and high-risk AI classification are related governance topics, but they are not the same operational decision.

A prohibited practice is a stop-or-redesign issue. A high-risk AI system may be permitted but subject to stricter obligations. If the team treats both questions as one generic "AI risk" review, it may design controls around something that should not proceed at all.

The workflow should ask prohibited-practice questions first. If there is no Article 5 red flag, the team can then continue into AI system classification, provider or deployer role analysis, privacy review, security review, and customer trust documentation. The broader process can connect to AI governance expectations for SaaS vendors, but the prohibited-practice screen needs its own decision point.

Mistake 6: Ignoring customer configuration

SaaS products often give customers configuration power. A feature may be harmless in the vendor's default setup but risky when a customer changes prompts, inputs, thresholds, labels, target groups, automations, or downstream actions.

This matters for prohibited practices because the actual deployment context can change the analysis. A general recommendation tool may become more sensitive if a customer uses it to influence vulnerable people. A scoring workflow may become more serious if it follows natural persons across unrelated contexts. A monitoring tool may become problematic if configured for workplace emotion inference.

Product and compliance teams should document intended use, prohibited customer uses, configuration limits, customer-facing guidance, and escalation rules. If customers can create risky configurations, the team may need product restrictions rather than policy language alone.

Mistake 7: Forgetting evidence of rejected ideas

Teams often document approvals but lose the history of rejected or redesigned AI use cases. That is a missed opportunity.

Rejected ideas show that the control works. If a team blocks a vendor because of facial-image scraping concerns, redesigns a feature to avoid manipulative personalization, or refuses workplace emotion analytics, that evidence can support board reporting, customer trust, audits, and future training.

Keep a short record with the proposed use case, the red flag, the decision, the owner, the reviewer, and the date. The record does not need to name every brainstorm, but it should preserve meaningful decisions.

Mistake 8: Leaving review triggers undefined

A prohibited-practice conclusion can become stale. The product may enter a new market, serve a different user group, add biometric data, change model behaviour, automate a decision, or rely on a new vendor.

Without re-review triggers, teams may keep using an old conclusion after the facts have changed. Define triggers inside product change management, vendor management, and launch readiness.

Good triggers include new data categories, new affected groups, new customer segments, new automation, new vendor functionality, new public-sector or regulated use cases, and new EU guidance. The decision record should say what event reopens the analysis.

Mistake 9: Not connecting the issue to customer trust

Enterprise buyers increasingly ask how SaaS vendors govern AI. They may not ask about Article 5 by name, but they ask whether AI features manipulate users, infer sensitive traits, process biometric data, monitor workers, or rely on weak vendor controls.

If prohibited-practice review sits in a private legal note, sales and security teams may answer from memory. That creates inconsistency. A better approach is to maintain customer-ready evidence: the AI inventory, prohibited-practice screen, vendor documentation, reviewer decision, and summary explanation.

This evidence also supports adjacent questions about what compliance teams should ask before adopting internal AI tools and controls buyers increasingly ask about for AI-enabled SaaS products.

What to do next

Start with a short prohibited-practice intake that every AI feature, AI vendor, and AI-enabled internal workflow must answer. Keep the questions operational: who is affected, what data is used, what the system infers, what treatment changes, whether biometric or emotion data is involved, and what happens if the output is wrong.

Then name the reviewer. Product and engineering should supply the facts. Legal, compliance, privacy, or the AI governance owner should decide whether the use case can proceed, needs redesign, or must be blocked.

Finally, connect the decision to EU AI Act readiness. Prohibited-practice screening should be one control inside the wider AI governance system, not a one-off legal question that disappears after launch.

For the first version, avoid making the workflow too heavy. A useful minimum is one intake form, one decision template, one owner field, one reviewer field, and one place where evidence is stored. The team can add deeper legal analysis for sensitive cases, but every routine AI review should still leave a basic record. That record should make clear whether the review found no prohibited-practice concern, required product changes, or blocked the use case pending specialist advice.

Review the first month of decisions with product, security, privacy, and customer-facing teams. Look for questions people misunderstood, vendor evidence that was hard to obtain, and cases where the screen happened too late. Then tighten the checklist. The control becomes stronger when it reflects how the company actually ships software, buys tools, and answers enterprise customers, instead of living as a detached policy exercise.

FAQ

What should teams understand about Prohibited AI Practices?

Teams should understand that prohibited-practice review is a launch and vendor control. It should catch unacceptable AI use before the company invests in a design, signs a vendor, or makes a customer commitment.

Why does Prohibited AI Practices matter in practice?

It matters because the wrong AI use case may need to be blocked or redesigned rather than controlled through ordinary monitoring. Early screening avoids late product surprises and gives teams evidence for customer, audit, and leadership questions.

What is the biggest mistake teams make with Prohibited AI Practices?

The biggest mistake is treating prohibited practices as a legal label instead of a workflow with intake questions, owner, reviewer, decision record, launch gate, and re-review triggers.

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.