Prohibited AI Practices

Expanded Definition

Prohibited AI practices are the subset of AI uses that the EU AI Act places outside lawful operation because the activity itself is judged to be unacceptable, not merely risky. That distinction matters: many AI systems can be constrained, monitored, or documented; prohibited practices are treated as fundamentally incompatible with the Act’s rights, safety, and governance objectives. In practice, the concept is narrower than broad "high-risk AI" discussions and should not be confused with ordinary compliance obligations such as transparency, recordkeeping, or human oversight.

Definitions and enforcement details continue to evolve as organisations interpret the Act alongside sector rules and local supervisory guidance. NHI Management Group treats this term as a regulatory boundary marker: it tells legal, compliance, security, and product teams where design choices may cross from controllable risk into disallowed use. For security and governance teams, the most important question is not whether a model is powerful, but whether the intended use falls into a category the law treats as unacceptable.

The most common misapplication is assuming any controversial AI use is automatically "prohibited," which occurs when teams blur banned practices with high-risk but potentially lawful deployments.

Examples and Use Cases

Implementing prohibited-AI screening rigorously often introduces legal-review friction early in the product lifecycle, requiring organisations to weigh speed to market against the cost of redesigning a use case before launch.

• Using AI for manipulative or exploitative practices that materially impair a person’s ability to make free and informed decisions.
• Deploying systems that infer sensitive traits in ways the Act treats as unacceptable, especially where the inference is used to profile or disadvantage individuals.
• Applying biometric or surveillance-style AI in contexts where the legal boundary is especially strict and narrow exceptions may not apply.
• Embedding AI into decision workflows that create unacceptable harm to access, fairness, or safety, rather than merely poor outcomes.
• Assessing whether a control framework such as NIST SP 800-53 Rev 5 Security and Privacy Controls is sufficient for a use case, when the real issue is that the use case may be disallowed altogether.

In real programs, the use case often starts as a product or data-science proposal and only later becomes a compliance question. That is why organisations need an intake process that identifies prohibited categories before architecture, dataset selection, or vendor procurement are already underway.

Why It Matters for Security Teams

Security teams are often the first to see how a prohibited AI practice would actually function, because they review access, telemetry, deployment paths, and misuse scenarios. If the term is misunderstood, teams can spend months hardening a system that should never have entered production. That creates wasted engineering effort, legal exposure, and avoidable harm to affected individuals.

This concept also intersects with identity and access governance when AI systems are used to score people, mediate access, or make inferences about users, employees, or customers. In those cases, the security team is not only protecting the model itself; it is helping determine whether the use of identity-linked data is permissible at all. Governance needs to be explicit because a technically secure system can still be a prohibited one.

Organisations typically encounter the real cost only after a regulator, auditor, customer, or internal review flags the use case, at which point prohibited AI practices become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Should companies develop centralized identity management practices for AI agents?
• How do agentic AI controls differ from traditional Zero Trust practices?
• Why do platform-data training practices increase risk when employees use consumer AI tools with company data?
• Why do AI agents increase risk when organizations reuse existing IAM and secrets practices?