Prohibited Systems

Expanded Definition

Prohibited systems are not just high-risk AI uses with extra safeguards attached. They are the narrow set of AI practices the EU AI Act places outside acceptable deployment because the harm is considered too severe to permit normal market access or post-hoc mitigation. The practical boundary matters: a system can be regulated, constrained, or require documentation without being prohibited, while prohibited systems are treated as a hard stop.

The strongest way to understand the term is by contrast. High-risk AI may be allowed if governance, oversight, and technical controls are in place. Prohibited systems are different because the legal question is whether the use case itself should exist in the first place. That makes the first practitioner task classification, not tuning. For the official regulatory framing, the EU AI Act text is the authoritative source, especially where organisations need to distinguish bans from obligations. The common misunderstanding is to treat every difficult AI use as a candidate for mitigation; for prohibited systems, mitigation is not the deciding test.

In practice, the term is used as a policy filter across procurement, product review, legal sign-off, and launch gates. It can also reach third-party and embedded AI features, which means a prohibited use cannot be accepted simply because it arrives inside a broader platform or vendor workflow.

Examples and Use Cases

Prohibited systems appear whenever an organisation evaluates AI capabilities against deployment rules before release, acquisition, or integration. The key use case is not operational tuning but pre-deployment screening.

• A product team reviews a proposed biometric feature and stops the project if the intended use falls into a banned category rather than a permitted identification workflow.
• A procurement team checks whether a vendor’s AI function changes from acceptable automation into a prohibited decisioning use once it is connected to a real business process.
• A compliance team performs a launch gate on an internal model release to confirm the use case is not one of the Act’s outright bans before pilot approval.
• A legal or risk function evaluates a third-party AI embedded in a workflow to decide whether contract approval is impossible because the underlying use is prohibited.
• A security or governance team documents a rejection decision early, reducing rework by preventing a banned use from entering architecture review, testing, or assurance pipelines.

The practical tradeoff is that faster innovation can tempt teams to frame a banned use as merely experimental or internal. That is usually the wrong lens, because classification must be based on the actual function and intended deployment path, not the label attached to the prototype.

Security Implications

Misclassifying prohibited systems creates more than a compliance issue. It can expose an organisation to enforcement action, forced withdrawal, reputational damage, and avoidable technical investment in a system that should never have passed review. The control failure is usually upstream: teams focus on safeguards, bias testing, or human review when the real requirement is to stop the use case.

Another risk is governance drift. Once a banned capability is embedded in a product roadmap, it can be hard to unwind because ownership spreads across engineering, legal, procurement, and security. The observable symptom is a project that keeps moving toward pilot status even though the underlying use is not legally viable. A practical practitioner observation is that the most expensive mistake is not deployment of the model itself, but late discovery that the business objective belongs in a prohibited category.

For organisations that operate across jurisdictions, the issue is also classification consistency. A use case that seems permissible under one internal policy may still be prohibited under the EU regime, so release gates need a jurisdiction-aware review rather than a generic AI approval checkbox.

Domain and Governance Relevance

Prohibited systems matter most in AI governance because they define the outer boundary of acceptable AI use. They are not primarily a model-risk tuning problem; they are a policy, legal, and assurance problem that determines whether the organisation is allowed to proceed at all. That makes them central to intake screening, vendor due diligence, and release governance.

The identity and NHI angle is only material when a banned AI use would also govern access, authentication, or automated decision authority in ways that change control ownership. Even then, the central question remains the AI use case itself, not the downstream identity mechanism. That distinction prevents teams from over-indexing on technical controls while missing the legal prohibition.

In mature governance programmes, prohibited systems are handled as an early exclusion category: they are identified before architecture work, before procurement commitment, and before any control design begins. That approach saves assurance effort and keeps policy, legal, security, and product teams aligned on a single question: is this use allowed to exist at all?

Related resources from NHI Mgmt Group

• What is the difference between prohibited AI practices and high-risk AI systems under the EU AI Act?
• What NHI types do Agentic AI systems typically use?
• What is the main risk when automation systems store ServiceNow credentials?
• Why is identity such a critical factor in securing AI agent systems?