AI vendor due diligence for HR: the questions to ask

HR teams buy most of their AI rather than build it, but the legal exposure does not transfer with the invoice. When a screening tool discriminates or a monitoring tool over-collects, the employer is the respondent and the controller. Due diligence is how you shift some of that risk back — and, more usefully, how you avoid buying a tool that cannot be operated lawfully.

Use this as a procurement checklist. Get the answers in writing and attach them to the contract schedule.

1. What does the system actually do?

• What is the model's output, in plain terms — a score, a ranking, a classification, a draft?
• What decision does the buyer typically make from that output?
• What is out of scope, and what uses does the vendor consider misuse?
• Is there documented instructions for use? Under the EU AI Act, a deployer that departs from these can inherit provider obligations.

Vague product marketing here is a real signal. A vendor that cannot state the output variable usually cannot evidence its validity either.

2. Regulatory classification

• Does the vendor consider the system high risk under Annex III of the EU AI Act? If not, why not?
• Can they produce a declaration of conformity and CE marking where applicable?
• Is the system registered in the EU database where required?
• For the UK: what is their position on UK GDPR Article 22, and does the tool support a human-review workflow?
• Does the tool include emotion recognition or biometric categorisation in any feature, including optional ones? These are prohibited in workplace contexts under the EU AI Act.

3. Bias and validity evidence

• What adverse-impact testing has been performed, on what population, and how recently?
• Can they share the results, not just a summary claim of fairness?
• Has any independent third party audited the system?
• What evidence links the output to actual job performance?
• Which input features are used, and are any plausible proxies for protected characteristics?
• How does the tool behave for disabled users and users of assistive technology?
• What happens when the model is retrained? Are buyers notified, and can testing be repeated?

4. Data protection

• Who is controller and who is processor for each processing activity? Get this right in writing; "joint controller" arrangements need an Article 26 agreement.
• Is customer data used to train the vendor's models, by default or at all? Is opt-out contractual?
• Where is data hosted and processed, which sub-processors are used, and what transfer mechanism covers non-UK/EU transfers?
• Retention and deletion: what happens at the end of the contract, and how quickly?
• Can the vendor support subject access, rectification and erasure requests within statutory timescales?
• Will they provide inputs to your DPIA, including the information you need on necessity and proportionality?

5. Explainability and records

• What explanation can be given to a candidate or employee about a specific outcome?
• Are decision logs retained, and can the buyer export them? Under the EU AI Act, deployers must keep logs under their control for at least six months.
• Can the buyer export its own decision data to run an independent audit?
• Is model versioning visible, so a decision can be tied to the version that made it?

6. Security

• Certifications held: ISO/IEC 27001, SOC 2 Type II, Cyber Essentials Plus.
• Penetration testing frequency and whether summary reports are shared.
• Access controls, encryption at rest and in transit, and admin-access logging.
• Incident response: notification timescales that let you meet the 72-hour breach deadline.
• For generative features: prompt and output retention, and whether staff at the vendor can read them.

7. Commercial and contractual terms

• Liability and indemnity for discriminatory output, data-protection breach and IP infringement. Uncapped liability is rare, but a carve-out above the general cap for data and discrimination claims is negotiable.
• Audit rights for you or your appointed auditor.
• Change control requiring notice before material model changes.
• Exit: data export in a usable format, deletion certification, and transition assistance.
• Regulatory change clause requiring the vendor to keep the product compliant as the EU AI Act phases in.

8. Operational readiness on your side

Due diligence is not only about the vendor:

• Who owns the tool internally, and who can switch it off?
• Which humans provide oversight, and do they have the authority and training to override?
• Has the DPIA been completed, and consultation with representatives done?
• Is there a candidate or employee notice explaining the tool?
• What is the fallback if the tool is unavailable or has to be withdrawn?

Scoring the answers

A simple rule works well: any high-risk use case where the vendor cannot evidence adverse-impact testing, cannot support human review, or will not accept liability for discriminatory output should not proceed to contract. Everything else is a negotiation.

The practical takeaway

The questions above take a couple of hours to send and can save a group discrimination claim. The single most valuable artefact from the process is the written vendor response: it shows a regulator or tribunal that the employer asked, assessed and decided — which is the difference between a defensible deployment and an indefensible one.