What should organisations do when AI systems may fall under Annex III high-risk rules?

How Annex III changes the question from product selection to legal classification

Annex III is not a branding label for “advanced AI.” It is a legal trigger that forces organisations to decide whether the intended use places the system into a regulated high-risk category. That means the first control question is classification, not tuning, because obligations attach to the use case, deployment context, and role the organisation plays.

The practical test is whether the planned use sits in a listed Annex III area and whether the organisation is acting as provider, deployer, or both. If teams start with the model, they often miss scope, role, and evidence obligations until implementation is already committed.

That sequencing matters because Annex III obligations can change design decisions, documentation depth, human oversight, logging, and pre-deployment checks. A system can look ordinary from a product standpoint and still require a much stricter control set once its intended use is examined.

What organisations should confirm before deployment

Before go-live, organisations should confirm four things: the intended use, whether the activity falls within EU scope, which legal role they occupy, and what evidence they will need to demonstrate conformity. Those four decisions define the control baseline and prevent late redesign when obligations surface after build or procurement.

Intended use is especially important because the same technical system may be low-risk in one workflow and high-risk in another. Teams should document the actual business process, not just the model capabilities, because high-risk obligations follow the use case that is being placed into service.

Evidence requirements should be treated as design inputs, not audit afterthoughts. If the organisation cannot produce role assignments, intended-use records, oversight arrangements, and deployment rationale, it has probably not yet defined the operating model tightly enough for a high-risk decision.

How to structure controls around the duty set

Once classification is confirmed, controls should be built around the duty set that follows from that classification. In practice, that means aligning governance, technical controls, and operational evidence to the obligations that matter for the specific deployment, rather than applying a generic AI checklist.

For organisations working through this transition, the European Commission’s EU AI Act regulatory framework is the clearest starting point for understanding how high-risk categories and timing affect planning. It helps teams anchor compliance work to the regulatory timeline instead of guessing from product descriptions alone.

Operationally, this is where cross-functional ownership matters. Legal, product, security, procurement, and the business owner all need the same classification record, because Annex III duties usually cut across technical, contractual, and governance workstreams.

Risk and Threat Considerations

If organisations misclassify an Annex III use case, the main risk is not just regulatory error, it is control drift. Teams may deploy a system with the wrong approval path, inadequate human oversight, or missing evidence, then discover the gap after the system is already embedded in operations.

Failure mechanism: The organisation treats the AI system as a general-purpose tool instead of as a regulated use case, so required controls, documentation, and accountability are not built into the release process.

Impact: That creates redesign cost, delayed deployment, compliance exposure, and a higher chance that the system enters production without the evidence needed to defend its lawful use.

Practitioner Guidance

What to prioritise: Establish a written classification decision before procurement or pilot expansion. If the use case may fall into Annex III, treat that decision as a release gate, not a policy note.

What to verify: Confirm the deployer versus provider role, the actual intended use, and the EU applicability assumptions. If any of those are unclear, the control plan is premature.

Practitioner takeaway: The safest pattern is to make legality and evidence part of the deployment design, because once a system is live, Annex III obligations become much harder and more expensive to retrofit.

Related resources from NHI Mgmt Group

• How should organisations determine whether a credit scoring model falls under the EU AI Act high-risk rules?
• When should organisations treat an NHI as a high-priority risk?
• How should organisations implement continuous AI risk management for high-risk systems?
• When do AI systems move into high-risk territory under the EU AI Act?