A worked AI risk classification example under the EU AI Act: intended purpose, affected individuals, category rationale, controls and the evidence to retain.
Topics: EU AI Act, AI Governance, Risk Classification, DPIA
A credible AI risk classification example does more than attach a label to a model. It creates a defensible record of what the system does, who can be affected, why a particular EU AI Act category applies, and which operational controls must follow. For organisations introducing AI across multiple business functions, that record is the difference between an AI register that looks complete and one that supports accountable governance.
The EU AI Act uses a risk-based structure, but classification is not a one-time legal exercise. An AI system can change category or require a revised assessment when its intended purpose, users, model version, data sources, deployment context or level of human influence changes. The practical objective is to make those changes visible, assign ownership and retain evidence.
AI risk classification example: recruitment screening
Consider a multinational organisation deploying an AI-enabled recruitment screening system. The tool receives CVs and application information, extracts skills and employment history, assigns each candidate a suitability score against a job description, and ranks candidates for a recruiter to review.
The system is supplied by a third party, but the organisation configures the scoring criteria, determines which roles use it and decides whether recruiters can progress lower-ranked candidates. It is used for vacancies in the UK and EU, with applicant data retained in the organisation's recruitment environment.
This is not simply a supplier procurement decision. It is an AI system deployment that affects access to employment, processes personal data and can materially influence individuals. The organisation should register it, classify its EU AI Act risk, assess privacy impacts and establish ongoing oversight before use.
Step 1: Define the intended purpose precisely
A useful classification starts with operational facts, not a vendor's marketing description. In this case, the intended purpose might be recorded as: “To analyse candidate application data and rank applicants against defined job criteria to support recruiter shortlisting for employment roles.”
That wording matters. “Supporting recruiters” does not remove the system from higher-risk use merely because a person remains in the process. If the score or ranking shapes who receives attention, interview opportunities or rejection, it has a meaningful role in an employment decision.
The AI system registry should also identify the business owner, technical owner, supplier, deployment countries, user groups, model and product versions, input data categories, outputs, integrations and intended users. These fields give a classification decision enough context to be reviewed later.
Step 2: Test for prohibited practices first
The first classification question is whether the use could fall within a prohibited AI practice. The assessment should consider the system's actual functionality, not only its primary workflow.
For the recruitment tool, the organisation should confirm that it does not use prohibited functionality such as emotion recognition in the workplace or infer sensitive personal characteristics from biometric data. It should also establish whether any functionality creates manipulative or exploitative effects that would require escalation.
Where the answer is no, retain the supporting evidence. This may include supplier documentation, product configuration records, contract terms, test outputs and a written statement from the product owner. A simple “not prohibited” field without rationale is unlikely to be sufficient for internal accountability.
Step 3: Assess high-risk classification
AI systems intended for use in employment, worker management and access to self-employment are identified in Annex III of the EU AI Act as high-risk use cases. Recruitment screening and candidate evaluation are therefore a clear area for scrutiny.
In this example, the classification should be high risk because the system ranks and supports the selection of job applicants. The fact that a recruiter can override an outcome is relevant to control design, but it does not by itself change the risk category.
The EU AI Act includes a limited exception where an Annex III system does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons. Organisations should apply this exception cautiously. A system that filters, scores or ranks candidates is likely to materially influence access to employment. Treating it as outside the high-risk category would require strong, documented reasoning and should be subject to legal and governance review.
The registry entry should record the applicable category, the assessment date, the person approving the decision, the legal rationale and the evidence reviewed. It should also show whether the organisation is acting solely as a deployer or has provider obligations because it developed, materially modified or placed the system on the market under its own name.
What controls follow a high-risk decision?
Classification is useful only when it drives work. Once the recruitment system is identified as high risk, the governance workflow should create linked actions for the relevant owners.
The supplier must be assessed for the documentation and assurances relevant to its role. The organisation, as deployer, needs clear operating controls: use the system according to instructions, assign meaningful human oversight, monitor its operation, retain relevant logs, and establish routes for users to report issues or suspend use. Responsibilities can differ where the organisation has developed or substantially modified the system, so the role analysis must be explicit.
Human oversight must be designed rather than assumed. Recruiters need instructions on how to interpret scores, when they must review underlying information, how to override a recommendation and when to escalate suspected bias or data-quality failures. A reviewer who is expected to accept the top-ranked candidates without challenge is not delivering meaningful oversight.
Data quality needs equivalent discipline. The organisation should identify the data used for screening, assess whether job criteria are relevant and current, restrict access to sensitive information that is not necessary for the purpose, and test whether outcomes appear disproportionately adverse for particular groups. Statistical testing can inform this work, but it does not replace a review of the business rules and recruitment process behind the model.
The deployment should also be connected to a Data Protection Impact Assessment. Candidate profiling, potentially significant effects on employment opportunities and the use of new technology are indicators that a DPIA is likely to be required under UK GDPR and GDPR. The DPIA and the AI classification assessment serve different purposes, but they should share core facts rather than duplicate them inconsistently.
A well-run programme links the AI registry entry to the DPIA, Records of Processing Activities, vendor or third-party risk assessment, contract review, and incident management process. This gives legal, privacy, security, HR and risk teams a common operating record.
Build the assessment record for review
The classification record should read like a decision file, not a questionnaire completed at implementation. It needs enough detail for a new owner, internal audit team or regulator-facing reviewer to understand why the organisation reached its conclusion.
For this example, the evidence set would normally include the supplier's technical documentation and instructions for use; configuration details for scoring and ranking; a description of recruiter oversight; testing and monitoring results; data protection assessment records; training materials; and contractual obligations covering notification of model or service changes.
Ownership should be equally visible. HR may own the business use case, procurement may manage the supplier relationship, privacy may lead the DPIA, and information security may assess access and integration risks. A central governance owner should ensure these dependencies are complete before the system moves into production.
Privacy360 supports this operating model by bringing the AI system registry and EU AI Act risk classification into the same environment as DPIAs, ROPA, vendor assessments, contract review and evidence collection. The aim is not to create another repository. It is to ensure a classification decision triggers accountable work across the teams that must deliver it.
Reclassify when the system changes
The original classification should not be treated as permanent. Suppose the supplier releases a feature that automatically rejects applicants below a threshold, or HR expands the tool from CV ranking into predicting candidate “culture fit”. Either change alters the intended purpose, level of automation and potential impact on individuals.
The system should then return to assessment before the revised functionality is enabled. Other triggers include a new country deployment, new input data, a new vendor model, material performance concerns, an incident, a complaint, or changes to the legal framework.
Set review intervals, but do not rely on annual review alone. High-risk systems need event-driven reassessment because significant changes often occur through routine configuration, procurement renewals and software releases rather than formal transformation projects.
The practical test is straightforward: can the organisation show what the system was designed to do, why its risk category was chosen, who approved the decision and what controls are operating now? If the answer is clear from one connected record, AI governance is becoming operational rather than aspirational.