Start with intended use, not technical complexity. If the system is used for hiring, credit, performance evaluation, or another Annex III activity, it may be high risk even if it looks routine. Classification should be tied to the actual business function, the people affected, and whether the organisation is acting as provider or deployer.
Why This Matters for Security Teams
EU AI Act classification is not a model inventory exercise. Security, privacy, legal, and product teams need to classify systems by intended use, affected people, and organisational role because the compliance burden changes sharply when a system touches hiring, credit, education, or similar Annex III use cases. The same model can be low impact in one workflow and high risk in another, which is why technical sophistication alone is a poor proxy for regulatory scope. The EU AI Act makes this distinction explicit, while NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives reinforces that governance must follow real operational risk, not vendor labels or internal assumptions. The practical problem is that classification decisions often land across multiple teams, each seeing only part of the workflow. In practice, many security teams encounter misclassification only after a procurement, HR, or customer decision has already been made.
How It Works in Practice
Classification usually starts with a use-case map, not a model sheet. Teams should document what the system does, who is affected, whether a human makes or overrides the decision, and whether the organisation is acting as a provider, deployer, importer, or distributor. That record becomes the basis for deciding whether the system falls into prohibited, high-risk, limited-risk, or minimal-risk treatment. The EU AI Act regulatory framework is the primary reference, but current guidance suggests that organisations should also preserve evidence of their reasoning, because regulators will look at the actual business function and not just the stated intent. For teams aligning internal controls, NHIMG’s Top 10 NHI Issues is useful where AI services rely on non-human credentials, because classification often overlaps with access control, logging, and third-party integration risk.
- Identify the concrete workflow first, then map it to the relevant Annex III category if applicable.
- Record whether the AI system informs a decision, automates it, or merely supports a human reviewer.
- Separate provider obligations from deployer obligations, because the control set and documentation duties differ.
- Track data inputs, outputs, and affected populations so risk is assessed by impact, not by model size.
Security teams should then align classification with evidence collection: logs, model cards, approval records, testing notes, and post-market monitoring. Best practice is evolving, but one constant is that a system used in a regulated decision path needs a stronger control baseline than a generic productivity assistant. These controls tend to break down when the AI is embedded in a workflow as a “feature,” because ownership, user impact, and decision authority become difficult to prove after deployment.
Common Variations and Edge Cases
Tighter classification discipline often increases legal and operational overhead, requiring organisations to balance faster AI adoption against stronger evidence and review. The hardest cases are borderline systems that influence decisions without making them directly, such as ranking, screening, summarisation, or recommendation engines. Those tools may still trigger high-risk treatment if they materially affect access to employment, finance, or essential services. There is no universal standard for this yet across all sectors, so teams should treat borderline cases conservatively and document why they were classified as they were. The NIST Cybersecurity Framework 2.0 is useful for structuring governance around identify, protect, detect, respond, and recover activities, even though it is not an EU classification rule. For operational depth, NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs helps when the system depends on API keys, service accounts, or automated agents that can change risk exposure over time.
Edge cases also appear when an organisation fine-tunes a foundation model, wraps a third-party model in a narrow workflow, or uses the same engine across several products. In those situations, each deployment may need a separate classification because the business effect changes. Another common mistake is assuming an internal tool is outside scope, when the affected population is actually employees and the use case is performance evaluation or access decisions. Classification should be revisited when the workflow changes, the user population expands, or the model starts driving decisions rather than merely supporting them.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| EU AI Act | Classification depends on intended use, risk tier, and role under the Act. | |
| NIST CSF 2.0 | GV.OV-01 | Governance requires evidence of risk decisions and oversight across AI workflows. |
| OWASP Non-Human Identity Top 10 | NHI-01 | AI systems often rely on non-human credentials that affect deployment risk. |
Map each AI workflow to its role, use case, and risk category before deciding obligations.
Related resources from NHI Mgmt Group
- How should organisations prove EU AI Act compliance across the AI lifecycle?
- How should security teams structure EU AI Act compliance for AI systems?
- How do organisations prepare for the EU AI Act without slowing AI adoption?
- What should organisations do before an AI assistant can act on real systems?
