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

Classify the use case first, then build controls around the legal duty set rather than around the tool category. The organisation should confirm intended use, EU scope, deployer responsibilities, and evidence requirements before deployment. That sequencing prevents late-stage redesign when a system is already in production and subject to higher obligations.

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.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF sets the technical controls, while EU AI Act and ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
EU AI Act	Annex III high-risk AI system classification	Annex III classification determines the legal duty set for the use case.
Recommendation — Classify the use case early and align controls to the high-risk duty set before deployment.
ISO/IEC 42001:2023	AI management system	The question is about organizing governance and evidence around AI deployment.
Recommendation — Use an AI management system to formalize roles, evidence, and control ownership.
NIST AI RMF	GOVERN — Govern	The answer centers on AI governance, roles, and accountable decision-making.
	MAP — Map	The question requires identifying intended use, context, and risk category first.
Recommendation — Define accountable governance for AI use-case classification and control oversight. Map the AI use case, context, and stakeholders before selecting controls.

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.