The AI Hiring Tool Register: Inventory, Risk Tier, and Evidence

You own the answer to a question an auditor, a works council, or a plaintiff's lawyer will eventually ask: which AI tools touched this candidate, and how do you know each one was allowed to. This guide is for the recruiting operations, revenue operations, and compliance leads answerable for that answer. It delivers a running deployer register - an inventory of every sourcing and screening tool, a defensible risk tier for each, and the evidence file behind it - plus the cadence that keeps it true as vendors and models change.

Most published material on this ranks tools against a shifting deadline and hands you a one-time checklist. That decays. A register is a durable object. It survives a deadline moving, a vendor swap, and a model update, because it stores the reasoning and the proof, not the date.

What makes a sourcing or screening tool high-risk

A sourcing or screening tool is high-risk when it is intended for recruitment or candidate selection, unless it clears the Article 6(3) filter and does no profiling. Employment sits in Annex III point 4 of the EU AI Act, which covers recruitment and candidate-selection systems and systems affecting the terms of a work relationship, promotion, termination, task allocation, or performance monitoring.

Annex III lists eight categories that are classified as high-risk under Article 6(2) when built for the regulated purposes: biometrics, critical infrastructure, education and vocational training, employment and worker management, essential private and public services, law enforcement, migration and border control, and administration of justice. Hiring tools land in point 4 the moment they screen, rank, or select people.

There is one escape route and one override. The escape route is Article 6(3): a system inside an Annex III use case may self-assess as not high-risk if it meets one of four conditions - it performs a narrow procedural task, improves a completed human activity, detects decision patterns without replacing human assessment, or performs a preparatory task. The override is decisive: a system that performs profiling of natural persons is always high-risk, regardless of whether it otherwise satisfies one of those four conditions.

That override is where most register mistakes hide. A tool marketed as a "preparatory" ranking helper that infers traits about candidates is profiling, and profiling forces high-risk. Your register needs a dedicated profiling flag that overrides the 6(3) column, not a footnote.

The Commission published draft high-risk classification guidelines on 19 May 2026 and opened a five-week consultation running to 23 June 2026. Guidance will keep moving; the classification logic in Article 6 will not. Anchor your register to the article, and re-read the guidance when it finalizes.

What the deployer owes, and what proves it

As a deployer you carry Article 26, which imposes 12 distinct obligations. The proof is a set of artifacts you can hand over on request. The core duties are: use the system according to the provider's instructions, with competent human oversight, and monitor its operation; manage input data, keep logs for at least six months, and inform the provider and authorities of any risk or incident; and notify workers' representatives and affected workers when the system is used in the workplace.

Each duty maps to a document. That mapping is the spine of the evidence file.

Note two moving parts. First, the AI-literacy duty under Article 4 was softened in the Omnibus, so treat literacy as good practice rather than a hard artifact until the position settles. Second, the FRIA under Article 27 is not universal, covered later. Store what you have, and record plainly where a duty does not apply to you and why.

What the provider owes, and how to verify it

The provider owns the conformity documentation; your job is to collect it and check it is real. The provider must produce the technical documentation set out in Annex IV, the instructions for use under Article 13, the EU declaration of conformity, and the CE marking.

Verify each of these concretely rather than accepting a marketing PDF. The EU declaration of conformity must be drawn up as a machine-readable, physical or electronically signed document for each AI system, kept for 10 years, and made available to authorities on request; it confirms the system meets requirements and carries the information in Annex V. The CE marking must be affixed visibly, legibly, and indelibly for high-risk systems.

The tell for third-party assessment is a number. Where the conformity assessment under Article 43 involved a notified body, the CE marking is followed by that body's identification number. A CE mark with no notified-body number on a high-risk system either means self-assessment was used or that the marking is incomplete - both are things to record and question.

One reason to build the file now rather than later: the deferral bought time precisely because harmonized standards were not ready. Under the original timetable, organizations would have had to demonstrate compliance without finalized benchmarks. The deadline moved; the work did not shrink. A register assembled today is the hedge against the standards landing late.

The register schema that makes classification reproducible

No official standardized deployer-register schema is published, so treat any "canonical template" claim with suspicion. The defensible field set is derived from Articles 6, 11, 12, 26, and 27 and Annex VIII. The point of a schema is reproducibility: two people classifying the same tool a year apart should reach the same tier from the same fields.

System name
Provider
Deployer owner (internal)
Intended purpose (one sentence)
Annex III category (e.g. point 4, employment)
Article 6(3) determination + written justification
Profiling flag (Y/N - Y forces high-risk)
Assigned risk tier
DoC reference + CE / notified-body ID
Instructions-for-use reference
FRIA reference (or "N/A - regime recorded")
Human-oversight design (owner + intervention points)
Log-retention location
Last bias-test date + impact ratios (per req)
Monitoring cadence
Incident log link

The two columns people skip are the two that matter most in a dispute: the written Article 6(3) justification and the profiling flag. A tier with no written reasoning is not defensible; it is an assertion. Write the sentence that says why this tool is or is not high-risk, and let the profiling flag override it when profiling is present.

Build the register: the procedure

Run these steps in order. The first pass takes a few weeks; after that the register lives on a quarterly rhythm. Roles and durations are drawn from a working deployment cadence, not from the Act, which sets no timetable for the build itself.

Discovery is where teams underestimate. A tool that "just ranks" candidates or "just writes outreach" from candidate data is in scope for the inventory even if it clears 6(3) later. The register lists everything that touches candidate data; the tier column decides how much evidence each row needs.

Finding the person to own this is its own problem. When you need an independent auditor or a governance lead to sanity-check a tier, Refolk turns a plain-English description of that person into a shortlist across the public GitHub graph, public LinkedIn records, and the open web, rather than a keyword hunt that misses people who never used your exact title.

Human oversight that survives scrutiny

Human oversight is a design, not a signature. Article 26(2) requires a competent person with the authority and the training to intervene, and the artifact that proves it is a record of interventions, not a name on a form. An overseer who cannot override the tool, or who has never once overridden it, is oversight in name only.

Design the intervention points explicitly. Where in the workflow can the overseer see the tool's output before it acts on a candidate? Where can they reverse it? Who trained them, and on what? A register row that answers those three questions is defensible. A row that names a person and stops is a false positive waiting to be exposed.

Governance staffing makes this harder in Europe. In Refolk's index, 19,607 US professionals list Responsible AI or AI Governance skills against 1,585 in Germany - a 12.4x gap. EU deployers will more often hand register ownership to a generalist, which is exactly why the schema must be self-documenting: the written justifications and intervention records carry the knowledge that a specialist would otherwise hold in their head.

That scarcity is sharper at the top: across the queried US and German set, only 24 people hold an explicit AI Governance, Compliance, or Responsible AI manager-level title. Do not design a register that assumes a dedicated manager will maintain it. Design one a competent generalist can run from the written record.

Oversight is a logged intervention, not a signature; a name with no override history is a gap, not a control.

Monitoring and adverse-impact testing

The Act sets no numeric cadence. Deployers must monitor the operation of the high-risk system on the basis of the instructions for use and inform the provider of any risk identified under Article 26(5), plus keep logs for at least six months. That is the floor. The useful practice comes from a more concrete regime.

Borrow the four-fifths method from NYC Local Law 144. The impact ratio is the selection rate of a group divided by the rate of the most-selected group, and a ratio below 0.80 generally indicates potential adverse impact under the EEOC's four-fifths rule. Use historical data from actual use; if that is insufficient, test data may be used, but the limitation must be disclosed. Audit at least annually, and re-audit whenever the tool is materially changed.

The worked example above is deliberately simple. The trap is that it looks fine when pooled. A 2026 Stanford study followed 3.4 million people submitting 4 million applications across 1,700 positions, and disparity surfaced only at the role level, because pooling averages out role-specific screens. A tool can pass an aggregate bias audit while systematically screening out candidates for specific roles. Run your impact ratios per requisition, and store the data source on every test so synthetic data never masquerades as live monitoring.

How this register goes wrong

The failure modes below are where a register that looks complete falls apart under scrutiny. Each one has a false positive - something that looks like compliance and is not - and a concrete check.

Two of these deserve extra weight. The deferral is not relief. The Digital Omnibus moved Annex III standalone high-risk compliance to 2 December 2027, but Article 50 transparency has been enforceable since 2 August 2026, with only a legacy grace period to 2 December 2026. A register that stops until 2027 already carries a live transparency gap.

The FRIA trap runs the other way - people over-build. Article 27 requires FRIAs from public-law bodies, private entities providing public services, and specific private deployers using high-risk AI for credit scoring or insurance pricing. Many private recruiters carry Article 26 duties but not a strict FRIA obligation. Record which regime applies in the register so you neither skip a required FRIA nor waste weeks producing one you do not owe. And never reuse a completed DPIA as a FRIA; the rights scope is different.

Enforcement is thin but visibly tightening, which is the argument for a standing file over a one-time push. In a 2025 review, a state comptroller found at least 17 potential non-compliances where the enforcing agency had flagged just one among 32 firms. That gap invites proactive enforcement, and a standing evidence file is cheap insurance against it.

Before you call the register done

Run this checklist before you sign off the first full pass, and re-run the top half each quarter.

Keeping the register current

A register is only as good as its last review, so put the maintenance cadence in a calendar, not in someone's memory. The two triggers that force a re-classification are a vendor change and a model update; either can move a tool across the 6(3) line or turn a non-profiling tool into a profiling one. Between triggers, run a quarterly pass over the whole register and refresh the evidence that expires: logs age past six months, bias tests go stale after a year, and instructions for use get reissued.

The timeline table below is the one thing most likely to change under you, so track the mechanism rather than memorizing dates. Re-check the Official Journal and the Commission guidance when a deadline nears; the classification logic and the deployer duties are stable, but the dates and the finalized standards are not.

When the Commission's high-risk classification guidelines finalize after their consultation, re-read your Article 6(3) justifications against the final text and update any that no longer hold. When a vendor ships a new model, treat it as a new tool for classification purposes until you have confirmed the tier is unchanged. And when you swap a vendor entirely, the old row does not get deleted - it gets closed with a date, because the candidates it touched are still on record. A register that keeps its history is the one that answers the auditor's question years later, which is the only test that matters.