Direct answer

The EU AI Act prohibited-practices checklist should determine whether an AI system, AI agent, vendor tool, or model-enabled workflow falls within Article 5 categories such as harmful manipulation, exploitation of vulnerabilities, social scoring, certain criminal-risk assessments, prohibited facial-recognition database creation, workplace or education emotion inference, sensitive biometric categorisation, or restricted real-time remote biometric identification for law-enforcement purposes. Article 5 obligations apply from 2 February 2025. Enterprises should screen use cases before deployment, collect evidence on purpose, data, inferences, affected people, decision consequences, and runtime permissions, and escalate plausible matches to legal, compliance, privacy, security, and business owners.

Article 5 screening focus

The screening process should help enterprise teams decide whether a planned or deployed AI use case falls within a prohibited-practice category. The same review should apply to AI systems, AI agents, vendor tools, and model-enabled workflows, because Article 5 risk can arise from the intended purpose, the data used, the inferences produced, or the authority granted at runtime.

For enterprise governance, this means the checklist should be used before deployment, with a record of the system owner, deployment geography, affected population, data categories, biometric or emotion features, decision consequences, runtime permissions, and next review date.

EU AI Act prohibited-practices screening checklist

Use these questions as an initial screen. A plausible match should not be treated as a final legal conclusion, it should be escalated to legal, compliance, privacy, security, and business owners for review.

  • Does the AI system, AI agent, vendor tool, or model-enabled workflow involve harmful manipulation?
  • Does it exploit vulnerabilities of affected people?
  • Does it perform or support social scoring?
  • Does it perform certain criminal-risk assessments?
  • Does it create or support prohibited facial-recognition database creation?
  • Does it infer emotions in workplace or education contexts?
  • Does it perform sensitive biometric categorisation?
  • Does it involve restricted real-time remote biometric identification for law-enforcement purposes?
  • Does an AI agent have tools, permissions, data access, memory, or autonomous action rights that could allow behavior beyond the approved use case?
  • Is there evidence for purpose, data, inferences, affected people, decision consequences, and runtime permissions?

What the checklist is designed to decide

The checklist is designed to determine whether the system, agent, vendor tool, or workflow should proceed through normal governance, require deeper Article 5 review, or be blocked from deployment until the issue is resolved. It should focus on the concrete use case rather than only the model name or vendor description.

Scope of review

Enterprise review should cover internally built AI systems, AI agents, third-party vendor tools, and model-enabled workflows. For agents, review should include the runtime context, not just the prompt or model. Excessive functionality, broad permissions, or high autonomy can allow harmful actions even when the underlying model was approved for a narrower purpose.

Timing

Article 5 obligations apply from 2 February 2025. Enterprises should screen use cases before deployment and preserve the evidence needed to explain the determination later.

Evidence to collect before making an Article 5 determination

A useful determination depends on evidence that is specific enough for reviewers to understand how the system works, who it affects, and what consequences can follow from its outputs or actions.

Evidence area What to document
Purpose and use case What the AI system is intended to do, where it operates, and whether it is used before deployment in a controlled review process.
Data and inferences The data categories used and whether the system infers emotions, vulnerabilities, sensitive biometric traits, criminal risk, or social behavior scores.
Affected people The affected population, including whether the system is used in workplace, education, law-enforcement, or other sensitive operating contexts.
Decision consequences How outputs are used, whether they influence decisions, and whether the system recommends actions or takes actions directly.
Runtime authority The tools, permissions, data sources, memory, and autonomous actions an AI agent can use.
Governance record The system owner, deployment geography, Article 5 screening status, policy approvals, and next review date.

Where to embed prohibited-practice screening

Prohibited-practice screening should be embedded into the ordinary AI governance path, not handled as an informal review after a system is already live. The screening result should become part of the system record and should inform deployment gates, approvals, and runtime controls.

  1. Screen before deployment

    Review the intended purpose, affected people, data, inferences, decision consequences, and runtime permissions before the system is approved for use.

  2. Record the screening status

    Maintain a centralized AI inventory that records Article 5 screening status, deployment geography, system owner, affected population, data categories, biometric or emotion features, decision consequences, and next review date.

  3. Escalate plausible matches

    Escalate plausible matches to legal, compliance, privacy, security, and business owners so that the determination is reviewed by the right stakeholders.

  4. Apply policy gates

    Policy gates should prevent deployment of known restricted functions unless legal and governance review has approved a documented exception or determined that the function is outside the prohibited category.

  5. Preserve runtime evidence

    Logs should capture prompts, responses, retrieval sources, tool calls, approvals, overrides, and policy blocks so reviewers can reconstruct what happened without relying on informal memory.

Runtime controls for AI agents and model-enabled workflows

Prohibited-practice compliance is not only a policy document problem. Enterprise systems need technical controls that make prohibited or unapproved behavior harder to deploy and easier to detect. This is especially important for AI agents because excessive functionality, broad permissions, or high autonomy can allow harmful actions even when the underlying model was approved for a narrower purpose.

A practical architecture starts with a centralized AI inventory that records Article 5 screening status, deployment geography, system owner, affected population, data categories, biometric or emotion features, decision consequences, and next review date. Policy gates should prevent deployment of known restricted functions unless legal and governance review has approved a documented exception or determined that the function is outside the prohibited category.

Least privilege should apply to agents in the same disciplined way it applies to other enterprise systems. Agents should have only the tools, data access, and execution rights needed for the approved use case. Recommendation functions should be separated from action-taking functions where appropriate, and sensitive actions should require human approval. Logs should capture prompts, responses, retrieval sources, tool calls, approvals, overrides, and policy blocks so reviewers can reconstruct what happened without relying on informal memory.

Determination, escalation, and remediation

The output of the checklist should be a clear determination path. If the use case does not appear to match a prohibited category, the screening record should still be preserved with the evidence reviewed. If there is a plausible match, the system should be escalated to legal, compliance, privacy, security, and business owners before deployment.

Where a function is known to be restricted, policy gates should prevent deployment unless legal and governance review has approved a documented exception or determined that the function is outside the prohibited category. For AI agents, remediation may also require reducing permissions, separating recommendation functions from action-taking functions, adding human approval for sensitive actions, or improving logs so reviewers can reconstruct what happened.