Vendor Questions to Ask an HR Technology Supplier
Most HR teams do not build AI systems in-house; they buy them from technology vendors. The quality of governance, the transparency provided by vendors, and the vendors’ own risk management practices determine whether an organisation can deploy AI responsibly. HR teams must be equipped to ask the right questions and to understand whether vendor answers are credible.
Pre-Purchase Due Diligence
Before buying any HR technology that involves AI (CV screening, assessment tools, performance management systems, workforce analytics, monitoring), the organisation should conduct vendor due diligence. This means more than checking references and asking whether the system is “unbiased.” It means understanding what the system actually does, what risks it poses, and what evidence the vendor has that it is safe to use.
Essential questions include: What data does the system use to make decisions? If the system uses historical hiring data, has that data been cleaned of past discrimination? If the system uses external data, what is the source and what biases might that data contain?
How is the system trained and updated? Is the model retrained regularly or do predictions degrade over time? When was it last updated?
Does the vendor have a schedule for updates, or does the vendor update only when customers complain about problems?
Has the system been tested for bias? What demographic groups were tested? What fairness metrics were used?
What was the result? If a vendor cannot produce bias testing documentation, that is a red flag.
How does the system perform overall? What is the false positive rate (candidates the system accepts who later perform poorly) and false negative rate (candidates the system rejects who would have performed well)? No system is perfect, but a vendor should be able to discuss trade-offs honestly.
Transparency and Documentation Obligations
A compliant vendor should be able to provide clear documentation of the system’s functionality, the data it uses, its training process, and its testing results. They should also provide documentation suitable for regulators: a model card or technical documentation that explains what the system does and how it was built.
For high-risk systems (like CV screening or assessment), the vendor should provide a fairness report or bias audit report that documents pre-deployment testing and post-deployment monitoring. They should explain what bias the system is monitored for and how frequently monitoring occurs.
The vendor should be able to explain the system’s decisions in plain language. If the system rejects a candidate, the vendor should be able to say why (not just “the score was below threshold”). If the system scores an employee’s performance, the vendor should be able to explain what factors contributed to that score.
Contract Terms and Liability
Vendor contracts should clearly allocate responsibility for compliance with employment law, data protection law, and AI regulation. The contract should state that the system will not discriminate, and should define what that means. It should specify whether the vendor or the customer is responsible for bias testing, human review processes, and compliance with data subject access requests.
The contract should include an indemnity clause: if the system causes discrimination and the customer is sued, who bears the cost? A vendor that is unwilling to stand behind its system’s fairness should not be trusted.
The contract should specify what happens if bias is discovered post-deployment. Will the vendor fix it? At what cost?
Will the vendor provide alternative systems? Will the vendor refund fees if the system is found to be biased?
Ongoing Relationship
The vendor relationship does not end at purchase. The organisation should have an ongoing process for monitoring the vendor’s system, escalating problems, and ensuring that the vendor is responsive to concerns.
The organisation should audit the vendor’s system regularly (at least quarterly) to check for emerging problems. If bias is detected, the vendor should be required to investigate and remediate. If the vendor is not responsive, the organisation should consider switching to an alternative vendor.
The organisation should also stay informed about regulatory developments and communicate these to the vendor. If new requirements emerge (such as transparency obligations under new regulations), the organisation should ask the vendor how the system will be updated to meet those requirements.