AI Resume Screening and the EU AI Act: High-Risk Classification for US Staffing Vendors

Step 1: Does the Act reach a US staffing vendor?

Establishment in the US does not settle the question. The Act's recitals explain that, because of their digital nature, certain AI systems should fall within the Regulation even when they are not placed on the market, put into service or used in the Union. The recital's own example is an operator established in the Union that contracts services to an operator established in a third country for an activity performed by an AI system that would qualify as high-risk. A US staffing vendor screening candidates for a European client's open roles is close to that pattern.

For each EU-role engagement, document three facts: where the vendor is established, where the candidates are located, and where the system's output is used. The output location matters most in practice, because a ranked shortlist delivered to an EU client is used in the EU even if the model runs in the US.

A second scope consequence applies to the vendor as a provider. A provider established in a third country must appoint an authorised representative established in the Union, by written mandate, before making a high-risk AI system available on the Union market. Decide early whether that applies to your offering. The territorial analysis is a legal conclusion, so have counsel confirm it rather than relying on this summary.

Step 2: Why resume screening is high-risk, and what the derogation requires

The Act's recitals state that AI systems used in employment, workers management and access to self-employment, in particular for the recruitment and selection of persons, should be classified as high-risk. The stated reason is their appreciable impact on career prospects, livelihoods and workers' rights. Parsing resumes, scoring fit, ranking applicants and filtering out candidates are all recruitment and selection activities, so they sit within that category.

An Annex III system can leave high-risk status only through the Article 6 derogation. It applies where the system does not pose a significant risk of harm to health, safety or fundamental rights, including by not materially influencing the outcome of decision making. Two points follow for a screening vendor.

First, a system that filters or ranks candidates before a human looks at them will often influence the outcome, so a derogation claim needs a careful, written basis. Second, the derogation is unavailable whenever the system performs profiling of natural persons. Evaluating candidates against attributes inferred from their data is the kind of function to test against that override. Record the assessment, the reasoning and who approved it, and have counsel confirm the conclusion.

On timing, as of November 2026, Commission pages state that rules for high-risk areas including employment apply from 2 December 2027. The Commission has also published guidelines for providers and deployers on classifying high-risk systems, with practical examples. Plan against the stated date, and track further Commission guidance, since dates have shifted relative to earlier material.

Step 3: Allocating provider and deployer roles

A vendor that builds or supplies the screening system and offers it to clients will usually be the provider. The EU client that uses it to evaluate its own candidates will usually be the deployer. Provider obligations fall under Article 16. Under Article 26(1), deployers must take appropriate technical and organisational measures to use the system in accordance with the instructions for use. The recitals describe deployers as playing a critical role in protecting fundamental rights, complementing the provider's obligations.

Roles are not fixed by label. Under the value-chain provision, a distributor, importer, deployer or other third party is considered a provider of a high-risk system, and takes on Article 16 obligations, in certain listed circumstances. A client that materially reshapes the system, or a vendor that resells another party's model under its own name, may land in a different role than the contract assumes. Read those circumstances in the primary text against your actual delivery model.

Put the allocation in writing. The client contract should state which party acts as provider and which as deployer, what the instructions for use require of the client, and who owns each obligation. Instructions for use matter twice: they define what the vendor must communicate, and they define the standard against which the deployer's conduct is measured.

Step 4: Which obligations operate at runtime, and which do not

The Commission's summary of high-risk requirements includes adequate risk assessment and mitigation, high-quality datasets to minimise discriminatory outcomes, and a high level of robustness, cybersecurity and accuracy. Most of this work happens before and around deployment, not inside a live interaction.

• Organizational and documentation duties: Risk management, data governance and bias work, technical documentation and conformity assessment. These need named owners, methods and written records. No runtime control substitutes for them.
• Obligations at the point of AI interaction: Human oversight and escalation, record-keeping, and enforcement of defined policy on what goes into and comes out of the system on each screening interaction.

What an auditor will want to see for live interactions

For the interaction-level obligations, evidence has to be specific to individual screening events, not a description of intended behaviour. A reviewer will typically want to see which policy applied to a given interaction, what action was taken, and when. Where a decision was escalated to a person, they will want the escalation itself, the reviewer's identity and the outcome. They will also want to see that the records are durable, complete across interactions and retrievable by role, requisition or time period.

This matters for role allocation as well. The provider needs records showing the system behaved within its defined limits. The deployer needs records showing human review actually took place for the cases that required it. Agree up front which party holds which records and for how long, and make sure retention settings in your environment match that agreement.

The obligation texts, including logging and retention periods, should be read directly with counsel before you fix evidence schemas.

Where runtime enforcement fits

Trussed enforces policy in the execution path, so controls on individual screening interactions are enforced at runtime, not reviewed after the fact. Policy can allow, redact, block, rate limit or escalate for human approval across models, agents, tools and MCP servers. For a screening workflow, a regulated enterprise could define policy that redacts specified candidate fields before they reach a model, or that sends an automated rejection to a human reviewer for approval before it takes effect. Each enforcement action produces audit-ready evidence, which is mapped to the EU AI Act among other frameworks. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

The boundary is important. Runtime enforcement supports human oversight, record-keeping and policy enforcement at the point of interaction. It does not replace conformity assessment, technical documentation, or bias and data-governance work, and it does not determine whether your system is high-risk or which role you hold. Those remain legal and organizational responsibilities. Trussed has run for 18+ months in continuous production in a regulated enterprise, but classification and role decisions still need counsel.