How to Operationalize Prohibited AI Practices Without Slowing Product Delivery

Operationalizing prohibited AI practices means turning Article 5 screening into a normal product, vendor, and internal-tool workflow. The goal is not to make every product manager become an AI lawyer. The goal is to catch unacceptable uses early, route uncertainty to the right reviewer, keep evidence of the decision, and let low-risk work continue without unnecessary delay.

For SaaS teams, the fastest workable model is a short intake, a decision route, a launch gate, and an evidence standard. If the AI use case clearly avoids prohibited categories, it can move into ordinary AI classification and risk review. If it clearly touches a prohibited category, the work stops until the team redesigns or receives specialist confirmation. If it is unclear, the case goes to a named reviewer with enough facts to decide.

That structure matters because the first AI Act rules, including AI literacy and prohibited-practice rules, started applying in February 2025. The European Commission has also published guidance to help organizations understand the practical application of the prohibitions, while the Court of Justice of the European Union remains the authoritative interpreter of EU law. SaaS teams should therefore build an operating model that is usable now and flexible enough to update as interpretation matures.

Start with a narrow operating question

The wrong first question is "Are we AI Act compliant?" That is too broad for a product team trying to ship. A better question is: "Could this specific AI use case fall into a prohibited-practice category?"

That question should appear anywhere AI enters the business:

• product discovery and feature review
• security design review
• privacy and data protection review
• vendor onboarding
• internal tool approval
• customer-specific configuration review
• major workflow changes after launch

Keep the first screen short. Ask whether the system influences a person's decision, uses hidden or purposefully manipulative techniques, targets vulnerable users, evaluates people across contexts, uses biometric data, infers emotions, scrapes facial images, supports law-enforcement or public-sector workflows, or affects work, education, credit, essential services, migration, safety, or access to important opportunities.

The screen does not need to produce a legal conclusion. It needs to decide the next route.

Use three routes, not one giant review

Teams slow down when every AI question goes through the same heavy process. Prohibited-practice operations work better with three routes.

The first route is proceed. If the facts show no Article 5 red flags, the team records the answer and moves to ordinary AI classification, security, privacy, and product review. This does not mean the feature has no compliance work. It means the prohibited-practice gate did not block it.

The second route is stop and redesign. If the use case involves a clear prohibited category, the product should not continue as planned. Examples include an HR feature that infers worker emotions for engagement scoring, a service that builds a facial-recognition database from untargeted scraped images, or a workflow that uses hidden manipulation in a way likely to cause significant harm. The owner should document the concern, stop release work, and define the redesign path.

The third route is escalate. Most hard cases live here. The facts may be incomplete, the vendor may use unclear labels, or the use case may depend on customer configuration. Escalation should go to a named legal, compliance, or AI governance reviewer with a target response time. Otherwise "needs review" becomes a quiet parking lot.

Define ownership before the first case arrives

Ownership is where many AI governance programs become slow. Everyone agrees prohibited practices are important, but nobody owns the operational decision.

A practical model splits responsibility by facts, review, and release.

Product owns the intended purpose, user journey, affected people, customer configuration, and release timeline. Engineering owns data flows, model integration, logs, architecture, and technical constraints. Security owns vendor risk, access, deployment, and third-party assurance. Privacy or legal owns the interpretation of Article 5 risk and the evidence standard. Compliance or the AI governance owner maintains the process, tracks decisions, and confirms that launch gates are working.

This split prevents two bad outcomes. Product does not have to guess legal meaning from a regulation. Legal does not have to reconstruct technical facts from screenshots and meeting notes after the feature is finished.

For audit readiness, record the accountable owner for each decision. A decision without an owner is hard to defend later, even when the conclusion was reasonable.

Build the minimum evidence package

The evidence package should be small enough to create during normal work and specific enough to survive customer, auditor, or regulator questions.

For each reviewed use case, keep:

• system or feature name
• owner and reviewing function
• intended purpose
• affected people or user groups
• AI role, such as provider, deployer, reseller, or internal user
• model, vendor, or service involved
• data categories, including biometric, behavioural, worker, child, or sensitive data flags
• prohibited-practice screen answers
• conclusion and rationale
• required redesign, restriction, or approval condition
• date and next review trigger

Attach proof where the work already happens. A product ticket can hold the decision. A vendor record can hold the supplier answers. A release checklist can confirm that the decision exists before launch. A separate spreadsheet may be useful early, but it should not become the only source of truth if the real work happens somewhere else.

This evidence model also aligns with broader evidence collection practices. Teams move faster when proof is captured inside existing workflows rather than rebuilt during audits or enterprise security reviews.

Connect the screen to product delivery

A prohibited-practice workflow only works if it is tied to delivery. If the screen is optional, teams will use it only when they already know there is a concern.

Add the screen to ordinary operating points:

• new AI feature intake
• material model or vendor change
• launch readiness checklist
• data protection impact assessment trigger review
• security architecture review
• enterprise customer configuration review
• internal tooling approval

Then define what blocks release. A missing screen should block launch for AI-enabled features. A "clear red flag" answer should block launch until redesign or formal approval. An "uncertain" answer should block launch only until the named reviewer gives a decision or conditions. A documented "no red flag" answer should not create extra delay by itself.

The key is predictable routing. Product teams can handle governance when they know what happens next. They struggle when review criteria are invisible or change from one launch to another.

Handle vendor AI without relying on labels

Vendor AI is a common source of hidden prohibited-practice risk. A vendor may describe functionality as insight, sentiment, engagement, personalization, identity, safety, fraud prevention, or analytics. Those words do not answer the Article 5 question.

For vendors, ask what the system does, what data it processes, what outputs it creates, who is affected, whether the customer can configure the use case, and whether the vendor uses biometric data, emotion inference, facial-image databases, profiling, or behavioural manipulation. Ask whether the system is intended for employment, education, credit, public safety, law enforcement, migration, essential services, or other sensitive contexts.

If the vendor cannot answer, record that as a finding. The operational issue is not only legal uncertainty. It is that the SaaS team may not know enough to launch or embed the capability responsibly.

Vendor review should also connect to customer commitments. If enterprise buyers ask whether your AI features avoid prohibited practices, your answer should be based on documented reviews, not a general vendor assurance. This is part of the broader shift in AI governance expectations for SaaS vendors and the controls buyers increasingly ask about for AI-enabled SaaS products.

Make customer configuration visible

SaaS teams often miss prohibited-practice risk because they review the default product but not customer configuration. A feature that is acceptable for one purpose may become risky when a customer uses it in employment, education, public safety, or identity workflows.

The operating model should define which configuration changes trigger review. Examples include enabling biometric analysis, adding worker or student data, changing the affected population, adding automated decision influence, using a model output for ranking or access decisions, or connecting the system to a new data source.

If customers can configure sensitive use cases themselves, the product may need guardrails: disabled options, warning text, contractual limits, admin controls, review workflows, logging, or support escalation. The right control depends on the product, but ignoring configuration risk is not a defensible model.

Review after change, not just before launch

Prohibited-practice screening should not happen once and disappear. Re-review is needed when the facts change.

Common triggers include:

• a new intended purpose
• a new affected user group
• a new market or jurisdiction
• a new vendor, model, or model version
• new biometric, behavioural, worker, child, or sensitive data
• customer-controlled configuration changes
• reduced human review
• new regulatory guidance or enforcement expectations
• incidents, complaints, or customer questions

The point is not to re-open every AI decision every week. The point is to define clear triggers so teams know when an old decision no longer covers the current use case.

Common mistakes

The first mistake is building a legal memo instead of an operating workflow. A memo may be useful for hard cases, but routine product work needs a screen, route, owner, and evidence record.

The second mistake is making compliance review too late. If the prohibited-practice question appears after design, contracting, customer messaging, and engineering are nearly done, the team has already lost speed. Early screening protects delivery because it prevents late redesign.

The third mistake is treating a human reviewer as a universal fix. Human oversight may reduce certain risks, but it does not automatically make a prohibited manipulation, sensitive biometric inference, or impermissible purpose acceptable.

The fourth mistake is forgetting internal tools. Employee analytics, training tools, security investigations, support scoring, and account prioritization can affect people even when they are not sold as product features.

The fifth mistake is recording only approvals. Rejections and redesigns are strong evidence that the control works. Keep them.

Practical rollout plan

Start with a two-week operating rollout, not a six-month governance project.

In week one, identify existing AI use cases, vendor AI capabilities, and internal AI tools. Add a short prohibited-practice screen to product intake and vendor review. Name the reviewer. Define the release-blocking states. Decide where evidence will live.

In week two, run the screen on the highest-impact use cases: customer-facing AI features, employment-related tooling, biometric or identity functions, systems that influence users, and vendors with unclear AI outputs. Record the results, fix obvious gaps, and create a backlog for ambiguous cases.

After that, make the workflow part of normal change management. Each new feature, vendor, or material configuration change gets screened. Each decision produces the same minimum evidence. Each uncertain case has a named reviewer and a deadline.

This is how teams operationalize prohibited AI practices without slowing product delivery: they make the first screen lightweight, the escalation path explicit, and the evidence standard predictable.

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, 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.

How can teams avoid slowing product delivery?

Use a three-route model. Let clear no-red-flag cases proceed, stop clear prohibited cases, and escalate uncertain cases to a named reviewer with a response target. Avoid sending every AI change through the same heavy review.

Can vendor documentation replace internal review?

No. Vendor documentation is useful evidence, but the SaaS team still needs to understand its own use case, configuration, affected users, data flows, and customer commitments.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidelines on prohibited artificial intelligence practices.
• European Commission notice that the first AI Act rules started applying on 2 February 2025.
• European Commission AI Pact webinar page on prohibited-practice guidelines and AI system definition.