The Sourcing-Versus-Screening Line for AI Hiring Features

Every AI touchpoint in a candidate search pipeline needs its own answer to one question: is this lawful sourcing, or is it high-risk screening under the EU AI Act? This guide is for recruiting operations, revenue operations, and anyone answerable for how candidate data was gathered. It gives you a repeatable, feature-by-feature test that turns the Article 6(3) conditions, the profiling trap, and the Annex III employment category into scored dimensions, so you can classify one feature in front of you and defend the call instead of presuming the whole stack is high-risk.

The mistake most vendor checklists make is to tell you high-risk hiring rules exist and stop there. That leaves you assuming every model in the pipeline is high-risk, which is expensive and wrong. The Act draws a line, and the line is drawable. What follows is the test I use, built so that two graders looking at the same feature arrive at the same tier.

Why classify feature by feature instead of the whole stack

Classify each AI feature on its own, because the Act attaches risk to a system's intended purpose, and a search pipeline contains several purposes that sit on different sides of the line. A single tool that "helps you hire" may contain an index, a translator, a deduplicator, a matcher, and a message drafter, and those do not all land in the same tier.

Recital 53 of the AI Act names a specific set of tasks as preparatory: smart solutions for file handling, including indexing, searching, text and speech processing, linking data to other data sources, and translation of initial documents. Those can qualify for the Article 6(3) exemption. Matching and ranking do not appear on that list, and the draft Commission guidance names them as material influence. If you assess the tool as one lump, you inherit the highest-risk component's obligations across the whole thing. If you assess each feature, you can carve the exempt parts out cleanly and concentrate your controls where they belong.

There is one caution that pulls the other way. Where components are orchestrated so that their combined outputs jointly materially influence a decision, they are treated as a single AI system. So the feature inventory is the unit of analysis, but the final classification must also check whether separately-innocent pieces add up to something that steers the outcome.

The four tiers and what puts a feature in each

There are four tiers a candidate-touching feature can land in: out-of-scope, limited-risk sourcing, high-risk screening, and prohibited. The tier is decided by a fixed order of gates, and the order matters because a prohibited feature cannot be rescued by any later step.

• Prohibited. The feature infers emotions in a workplace context under Article 5(1)(f), or performs biometric categorisation of sensitive traits under Article 5(1)(g). No exemption, no controls, do not deploy.
• High-risk screening. The feature's purpose falls in Annex III point 4(a) and it either performs profiling or materially influences the recruitment or selection outcome. Full deployer obligations apply.
• Limited-risk sourcing. The feature falls in Annex III point 4(a) but does not profile and meets one of the four Article 6(3) conditions without materially influencing the outcome. Exempt, but only with a documented assessment and registration.
• Out-of-scope. The feature's intended purpose does not fall in point 4(a) at all - for example a general employer branding tool that does not relate to a specific recruitment process.

The boundary between the last two is where most of the real work happens. The Annex III category is broad: it covers AI systems intended for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates. The draft guidance places sourcing squarely inside, treating systems used to source, score, rank, shortlist, assess, match, or advertise opportunities to candidates as high-risk where they materially influence outcomes.

The profiling gate does more work than the four conditions

Profiling is the gate that closes the most exemption claims, because a feature that performs profiling of natural persons is always high-risk regardless of which condition it fits. Article 6(3) says so in terms, and Recital 53 anchors it to the meaning of profiling in Article 4(4) of the GDPR.

That is a stronger rule than it looks. Most candidate-scoring builds a personal picture to predict fit, and any automated processing that evaluates personal aspects to make predictions about a person is profiling under Article 4(4). So a feature can satisfy one of the four conditions perfectly and still be high-risk because it profiles. Run the profiling gate before you spend time on the conditions.

The practical test is to name the personal aspects the feature infers. Deduplication that collapses two records for the same person infers nothing about that person's work or behaviour. Enrichment that scores reliability, seniority, or likely performance evaluates personal aspects and is profiling. If you cannot articulate what personal aspect is being inferred, the feature probably is not profiling. If you can name one, the exemption is closed and you move to deployer controls.

The clean line, then, runs between preparing documents and ordering people. Deduplication and translation prepare documents. Matching, ranking, and scoring order people, and ordering people by predicted fit is both material influence and, almost always, profiling.

What "materially influences the outcome" means

Article 6(3) exempts an Annex III feature only where it does not pose a significant risk of harm, including by not materially influencing the outcome of decision making. The draft Commission guidance sharpens this into a usable question: does the system merely support the recruitment process, or does it materially influence decisions relating to hiring, promotion, termination, pay, task allocation, or performance evaluation?

For a sourcing pipeline the test collapses to one operational check: does the feature's output change who the recruiter sees, or the order in which they see them? A translator does not. An index does not. A ranker that orders candidates by fit does, because it decides who appears first, and first is where attention lands. That is material influence whether or not a human later scrolls the list.

This is where the human-in-the-loop belief fails. The Commission is explicit that human involvement alone does not prevent a system from being classified as high-risk, and that businesses cannot avoid classification simply by inserting a human review step into an otherwise high-risk workflow. A recruiter who rubber-stamps a ranked list without independent inputs or genuine override authority does not downgrade the feature. Ask whether the human sets the agenda or the score does.

The clean line runs between preparing documents and ordering people, and ordering people is where the exemption ends.

Mapping common sourcing features to a tier

Here is how the recurring features in a search pipeline map, using Recital 53 for the preparatory tasks and the draft guidance for the rest. Treat this as the starting reference, then run each feature through the full gate order to confirm.

Two rows deserve a note. A job-description generator working from human-defined inputs is treated as a narrow procedural task and not high-risk per the draft guidance, which is why message and copy drafting usually sits below the line. And a general employer branding tool may fall outside point 4(a) entirely because it does not relate to a specific recruitment process. Where the guidance runs thin - for instance whether a job-board recommender that only surfaces roles a candidate elects to explore escapes point 4(a) - there is no clean worked example in public text, so record your reasoning and flag it as an open call to re-check when the final guidelines publish.

Before you can run this table with confidence, you need to know which candidates you are even touching, because the Act applies by where the person and the work are, not by your headquarters.

Refolk turns a plain-English description of the pipeline owner into a list of the people who actually run these tools, which is faster than reconstructing an org chart by hand. Once you know whose features are in scope, the inventory in the next section has a subject.

Classify one feature end to end

Work each feature through this fixed order. The order is deliberate: screen for prohibitions first, because a prohibited feature cannot be salvaged by any later step, then narrow through scope, profiling, and the conditions.

On the sequencing dispute: some sources run the Annex III gate before the prohibition and profiling screens. I run Article 5 first because a prohibited feature is dead on arrival, and finding that out after you have written a scope memo wastes the memo. The gate order above is the safer default.

How this classification goes wrong

The most common errors are all optimistic: they push a feature down a tier it does not belong in. Each has a check that catches it.

The component-by-component error deserves extra weight because it is the subtlest. A matcher that surfaces candidates and a scorer that orders them may each look modest in isolation, but where their combined outputs jointly materially influence the decision they are treated as a single AI system. Draw the pipeline as one diagram and ask what the last human sees. If what they see is shaped by the chain of models, classify the chain.

Documentation, deadlines, and who does the work

If a feature is exempt, the exemption is not a self-declaration. A provider who considers an Annex III system not high-risk must document that assessment before the system is placed on the market or put into service, register it under Article 49(2), and produce the documentation to national competent authorities on request. The written assessment should record which Annex III area applies, which condition is met, why profiling does not apply, the risk assessment, and the date.

If a feature is high-risk, deployer obligations attach. Article 26 imposes roughly a dozen duties: use the system per instructions, assign competent human oversight to natural persons with the necessary training and authority, monitor operation, manage input data, keep logs for at least six months, inform providers and authorities of risks or incidents, and notify workers' representatives and affected workers. None of these transfers to the vendor.

The dates that govern all of this sit in three tiers.

The Digital Omnibus moved the private-sector Annex III date from 2 August 2026 to 2 December 2027, and the caveat is that until Official Journal publication the earlier date remained technically binding. The prohibited-practice date did not move. Treat the deferral as a window to write your per-feature memos while the deadline is soft, not as a reason to wait.

Who holds the pen matters. In Refolk's index there is a substantial sourcing workforce - 151 sourcing-title professionals in Germany and 363 in the UK - but almost no dedicated AI-governance titles, just one in Germany and none in France. The classification burden lands on RecOps leads and DPOs, not on specialists who mostly do not exist in-house. That is the entire reason the two-grader test above has to be usable by generalists.

There is a jurisdictional wrinkle the UK number exposes. The UK's sourcing base runs about 2.40 times Germany's, and the UK sits outside the AI Act, yet UK-run pipelines routinely screen EU candidates. The Act applies by where the person and the work are, not by where the company is headquartered, so a UK team touching EU candidates inherits deployer duties anyway. Do not let a non-EU HQ short-circuit the classification.

Keep the classification current

Before you call any feature classified, run this check. It is the difference between a memo that survives an authority request and one that does not.

Two triggers should send you back through the gates. The first is a change to the feature: any time a translator gains a scoring function, or an index gains a recommender, re-run the whole path, because the change may have moved the tier. The second is a change to the guidance. The draft classification Guidelines are in consultation, and the candidate-choice boundary - whether a role recommender the candidate elects to explore escapes point 4(a) - is not settled in public text. When the final guidelines land, revisit any feature you classified on the strength of a thin worked example.

The test does not need a specialist to run, which is the point. Name the feature, name what it infers, name what the last human sees, and the tier follows. Two graders working the same feature through the same gates in the same order will land in the same tier, and that agreement is what you are defending when the authority asks.