A common example is an AI system used to screen job applicants, rank candidates or influence hiring decisions. Because such use can affect people’s opportunities, teams should apply tighter governance, testing, logging, human review and supplier controls, and confirm the system’s intended use matches the regulatory category before deployment.
What makes an Annex III use case high-risk in practice?
The practical test is not just whether the system uses AI, but whether it is being used in a context where decisions can materially affect rights, access, safety, or opportunity. Employment screening is a clear example because the output can shape who gets interviewed, shortlisted, or excluded, which makes governance, traceability, and human review part of the control baseline.
A useful way to think about Annex III is that the higher the stakes and the narrower the room for error, the more the deployment should be treated as a controlled use case rather than a routine software feature. That means the intended purpose, decision influence, and operating process all need to be documented before rollout, not inferred after the model is live.
For teams building approval workflows, the key question is whether the AI is only assisting a reviewer or is effectively steering the decision. If it can change outcomes in hiring, promotion, education, credit, access to services, or other consequential settings, it should be treated as a regulated use case with stronger oversight than a low-impact internal automation tool.
How job applicant screening becomes a regulated example
Candidate-ranking tools are a good example because they do more than summarise information, they can alter how people are prioritised for human attention. That creates a real governance boundary around the model’s role, the source data it uses, and whether a person can meaningfully override its recommendation.
This is why teams should verify the actual workflow, not just the marketing description. A tool described as “assistive” may still be high-risk if recruiters routinely rely on its ranking, filters, or scores to decide which applicants progress. The regulatory category follows the real effect on the decision path, not the label on the procurement record.
The same logic applies when a system is used to pre-screen applications, reject applicants automatically, or rank people before any human reviewer sees them. In those cases, the control expectation is stronger documentation, clearer accountability, tested behavior, and evidence that the system does not drift beyond its approved use.
What teams should control before deployment
High-risk use cases need disciplined setup because the main failure mode is not only technical error, but uncontrolled decision influence. Teams should confirm the intended use, define who reviews outputs, decide what evidence is retained, and test whether the system behaves consistently across different applicant profiles and operating conditions.
Supplier oversight matters as much as internal governance. When a third-party model or platform is involved, the buyer still needs clarity on training data limitations, logging access, update handling, human override options, and the evidence available for audit or incident review. EU AI Act Compliance Guide is useful background for mapping high-risk use cases, and AI Governance Guide helps with use-case approval and oversight structures.
For organisations that want a broader control frame around the deployment, a use case register, risk tiering, human oversight rules, and evidence of decommissioning criteria all help keep the system within its approved boundary. Where logging, monitoring, and alerting are part of that control set, teams often need operational visibility as well as policy approval, so SIEM Guide and Detection Engineering Guide can support the monitoring layer.
Risk and Threat Considerations
High-risk AI in hiring can create direct harm through discrimination, inappropriate exclusion, or opaque decision-making that is hard to challenge after the fact. The risk is amplified when the model is treated as an authority rather than a support tool, because bias, bad inputs, or brittle thresholds can silently affect many people at once.
Failure mechanism: The system influences consequential decisions without enough human challenge, logging, or validation, so errors or bias are repeated at scale and become hard to detect or reverse.
Impact: Organisations can create unfair outcomes, lose trust, fail audit expectations, and struggle to explain why a candidate was screened in or out.
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 Systems | Annex III defines the high-risk use case category described here. |
| Recommendation — Map the hiring workflow to the Annex III category before deployment and require the corresponding controls. | ||
| ISO/IEC 42001:2023 | AI management system requirements | High-risk AI use needs governed roles, approval, monitoring, and review. |
| Recommendation — Operate the use case under a managed AI governance system with assigned accountability and review. | ||
| NIST AI RMF | GOVERN — Govern | This example needs explicit governance for intended use, oversight, and accountability. |
| MAP — Map | Teams must map the system’s real workflow and decision impact to its risk context. | |
| MEASURE — Measure | Testing, logging, and performance checks are needed to validate behavior in a high-impact setting. | |
| Recommendation — Define ownership, intended use, and escalation paths before the AI is put into service. Document the actual decision path, affected stakeholders, and deployment context before release. Test output quality, drift, and monitoring signals that show whether the system stays within bounds. | ||
Practitioner Guidance
What to verify: Confirm the system’s real role in the hiring workflow, including whether it ranks, filters, or merely assists. If the output changes who gets seen by a human reviewer, treat that as a governed decision point, not a convenience feature.
Decision rule: If the model can materially influence access to work, education, services, or other rights-bearing outcomes, require documented approval, human review, and retained evidence before deployment. If the use case is narrow and low-impact, lighter controls may be defensible, but only if the actual workflow is genuinely assistive.
Practitioner takeaway: The most important judgement is whether the AI is shaping a consequential outcome or simply supporting a person who retains genuine decision authority. If it shapes the outcome, govern the workflow as a high-risk use case from day one.