The questions to ask your AI hiring vendor (EU AI Act)

A checklist for HR and legal teams. About 6 minutes.

Start here

Most teams evaluate an AI recruiting tool the way they evaluate any software: features, price, integrations, a security questionnaire. Then they assume that if the vendor is compliant, they are covered. Under the EU AI Act, that assumption is the gap. The vendor is the provider. The moment you switch the tool on to screen, rank or assess real candidates, you become the deployer, and the AI Act gives the deployer its own set of obligations that the vendor cannot discharge for you.

That matters because AI used in recruitment and employment is named directly in Annex III, point 4 of the AI Act, which means it starts from a position of being treated as high-risk (Article 6(2)). High-risk deployer duties are not abstract. They are specific: assign competent human oversight, monitor the tool and report risks, keep the logs, inform the workers involved, and, in some cases, run a fundamental rights impact assessment. You can only meet most of them if the vendor hands you the right information and the right controls. So the practical way to cover your side is to ask, in writing, before you sign or at your next review.

This page gives you ten questions, each tied to a specific obligation in the live text of the AI Act, with the article cited so you can check it yourself. It is built for the mid-market team that has to get this right without an enterprise compliance department. Use it as a first pass: it tells you what to ask and why it matters, and it shows you where the answer is yours to give, not the vendor's.

First, one thing the vendor cannot answer for you

Before the ten questions, fix the frame, because it changes how you read every vendor answer. The AI Act splits duties between the provider (who builds and supplies the system) and the deployer (who uses it under their own authority). A vendor can build a compliant system and still leave you, the deployer, exposed, because a whole set of obligations attach to use, not to the build. Human oversight in your process, telling your workers, keeping your logs, monitoring how the tool behaves on your candidates: those are yours. The vendor's job is to give you what you need to do them. The questions below are designed to surface exactly that, the line between what the vendor owes you and what you still owe yourself.

The ten questions

1. Who operates the tool on our side, and are they competent and authorised to overrule it?

Why it matters. Article 26(2) puts the duty on you, the deployer, to "assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support" (AI Act, Article 26). The vendor cannot assign your people. What the vendor can do is tell you what oversight the system is designed for and what a reviewer needs to understand to use it safely. Ask the vendor what oversight the tool assumes; then ask yourself whether the named person on your side actually has the training and the authority to act on it.

2. How do we monitor the tool in use, and how do we report a problem to you and to the regulator?

Why it matters. Article 26(5) requires the deployer to "monitor the operation of the high-risk AI system on the basis of the instructions for use" and, where there is reason to think use of the tool may present a risk, to "without undue delay, inform the provider or distributor and the relevant market surveillance authority" (AI Act, Article 26). Ask the vendor what signals you should watch, what their channel is for reporting a fault or a serious incident, and how fast they respond. You still own the duty to escalate to the authority; you want a vendor who makes that possible, not one who goes quiet.

3. Does the tool generate logs, can we export them, and will they cover at least six months?

Why it matters. Article 26(6) requires the deployer to "keep the logs automatically generated by that high-risk AI system to the extent such logs are under their control, for a period appropriate to the intended purpose ... of at least six months, unless provided otherwise in applicable Union or national law" (AI Act, Article 26). This is the question vendors most often fail. Ask: does the system log automatically, what exactly is captured, are those logs under our control, and can we hold them for at least six months. If the logs live only on the vendor's side and you cannot export or retain them, you cannot meet a duty the law puts on you.

4. What do we have to tell our workers and their representatives before we switch this on?

Why it matters. Article 26(7) is explicit: "Before putting into service or using a high-risk AI system at the workplace, deployers who are employers shall inform workers' representatives and the affected workers that they will be subject to the use of the high-risk AI system" (AI Act, Article 26). This duty is entirely yours, and it happens before first use. The vendor cannot inform your workforce. What you want from the vendor is a plain description of what the tool does, in language you can pass to employees and their representatives. Ask for it, and build the notice into your rollout, not after it.

5. If we are a public body or provide a public service, do we need a fundamental rights impact assessment, and will you give us what it needs?

Why it matters. Article 27 requires certain deployers to carry out a fundamental rights impact assessment (a FRIA) before first use. It applies to deployers that are bodies governed by public law, private entities providing public services, and deployers in the Annex III credit-scoring and life-and-health-insurance cases (points 5(b) and (c)) (AI Act, Article 27). The assessment must describe your processes, the people and groups likely to be affected, the specific risks of harm, your human oversight measures, and what you will do if those risks materialise. Separately, Article 26(9) says you use the Article 13 information from the vendor to meet your data protection impact assessment duty under GDPR Article 35 (AI Act, Article 26). Ask the vendor whether they supply a FRIA or DPIA support pack, and what inputs they can give you. The assessment is yours to perform; the vendor's information is an input, not a substitute.

6. Will you give us the instructions for use, and do they actually tell us the tool's limits?

Why it matters. Article 13(2) requires that high-risk systems "be accompanied by instructions for use ... that include concise, complete, correct and clear information that is relevant, accessible and comprehensible to deployers" (AI Act, Article 13). The instructions are not marketing. Article 13 expects them to cover the provider's identity, the system's intended purpose, its accuracy and known limitations, the human oversight measures it is built for, and how to interpret its output. This is the vendor's duty, and it is the document that lets you meet half of your own. Ask for the instructions for use by name, read them, and treat a vague or missing one as a finding, not a formality.

7. Is your tool in scope of Annex III, point 4, in the first place?

Why it matters. Annex III, point 4 names the employment use cases that start as high-risk: AI "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", and AI used to "make decisions affecting terms of work-related relationships, the promotion or termination of work-related contractual relationships, to allocate tasks based on individual behaviour or personal traits or characteristics or to monitor and evaluate the performance and behaviour of persons in such relationships" (AI Act, Annex III). Ask the vendor plainly whether they consider the tool in scope of Annex III, point 4, and on what basis. Their answer tells you how seriously they have read the law, and a vendor who says "we are not in scope" without a clear reason is a vendor to slow down with.

8. You say a human is in the loop. Does that actually take the tool out of high-risk?

Why it matters. Vendors lean on "there is always a human in the loop" as if it settles the question. Article 6(3) is where the off-ramp lives, and it is narrow. An Annex III system is not high-risk only if it "does not pose a significant risk of harm" and meets one of four conditions: it performs a narrow procedural task; it improves the result of a previously completed human activity; it detects patterns and "is not meant to replace or influence the previously completed human assessment, without proper human review"; or it performs a preparatory task (AI Act, Article 6). "A human reviews the output" is not, by itself, on that list. And there is a hard stop: the same Article 6(3) states a system "shall always be considered to be high-risk where the AI system performs profiling of natural persons", with profiling carrying its GDPR meaning under Article 3(52) (AI Act, Article 3). A tool that scores, ranks or analyses candidates is doing the assessment, and if it profiles, the off-ramp is closed. Ask the vendor which of the four conditions they rely on, in writing, and whether the tool profiles. (We covered this off-ramp in depth in Edition 19.)

9. Can you identify the system and hand us what we need to register and document it?

Why it matters. Article 26(6) ties the deployer's logging duty to logs "under their control", and Article 13 ties your documentation to the provider's instructions for use (AI Act, Article 26; AI Act, Article 13). To keep an honest internal record, you need to be able to identify the system: its name and version, the provider's identity and contact, what it does, and the documentation behind it. Ask the vendor for the system identification details and the version you are actually running, so that your inventory names a specific system, not "the screening tool". A record that cannot name the system it describes will not hold up when someone asks to see it.

10. A bridge for US hiring: if you sell into New York City, where is your annual bias audit and the candidate notice?

Why it matters. This one is a separate law, not the EU AI Act, and worth asking if you hire in New York City. New York City's Local Law 144 governs automated employment decision tools (AEDTs) and has been enforced since 5 July 2023. It requires a bias audit by an independent auditor "conducted no more than one year prior to use" of the tool (§ 5-301 of the adopted rule), a summary of those results published on the website (§ 5-303), and notice to candidates at least ten business days before the tool is used on them (§ 5-304) (NYC adopted rule; IAPP). Two cautions. First, this is a New York City obligation, distinct from the AI Act, with its own scope and its own definitions; do not treat an AI Act answer as covering it, or the reverse. Second, the bias audit must come from an independent auditor, so a vendor's own internal testing does not satisfy it. Ask for the most recent independent bias audit, its date, and the candidate notice language.

What to do with this

You do not need a lawyer to run the first pass. You need the questions asked and the answers on the record.

1. List every place AI touches a hiring decision, and name the vendor behind each. Sourcing and targeted ads, screening and filtering, ranking, interview tools, anything feeding promotion or performance. You cannot send a questionnaire for a tool you have not listed.
2. Send the ten questions to each vendor in writing, and keep the replies. The point is not only the answer; it is having the answer in writing, dated, so that when your board, your customer or an auditor asks, you reach for a file instead of a scramble. Written answers are the evidence that you did the diligence.
3. Mark the duties that stay yours no matter what the vendor says. Human oversight (Article 26(2)), informing workers (Article 26(7)), keeping the logs (Article 26(6)), and any FRIA (Article 27) are deployer duties. The vendor's answers are inputs; the obligations are yours. Write down who owns each one on your side.
4. Flag the gaps and decide before you sign. A vendor who cannot export logs, will not name a basis for being out of scope, or has no current independent bias audit for New York City is not a deal-breaker by itself, but it is a gap you should price in, document, and raise with counsel if it is material.

This is educational material and a starting point, not legal advice. The EU AI Act is still being implemented and its timetable is still moving: the general application date for high-risk obligations is the subject of a provisional change (the Digital Omnibus) that is not yet final in the Official Journal, so we have deliberately built this page on the classification and obligation text (Articles 6, 13, 26, 27 and Annex III), which is enacted, rather than on a specific application date. Whether a particular tool is high-risk, and which of these obligations apply to your organisation, depend on the facts of that tool and on national implementing rules. New York City's Local Law 144 is a separate US law with its own scope. For your situation, and before you rely on a vendor's answers, consult a qualified lawyer. Signato is not a law firm and does not certify compliance.