AI procurement for HR: an evidence-led guide

Compare AI suppliers using workflow demonstrations, data questions, evaluation evidence and exit requirements. This practical guide to AI procurement for HR brings together a step-by-step approach, illustrative examples, a reusable worksheet and answers to common questions. Start with the section closest to your current challenge, then use the working session to turn the guidance into a clear next action.

Buy against a defined use case

Begin with the task, intended users, approved information and consequence of an error. A supplier cannot demonstrate suitability for a use case the buyer has not defined. Separate required capabilities from attractive but unnecessary features.

Include HR, security, privacy, procurement and the people who will use the system. Assign a decision owner and a route for unresolved risks. Do not let a commercial deadline silently become acceptance of an unanswered material question.

Ask for current, scoped evidence

Request information about data flows, hosting, subprocessors, model providers, retention, deletion and whether inputs or outputs are used for training. Review the actual contract and service configuration, not only a generic FAQ.

Ask how access is enforced, what audit records exist and how incidents and model changes are communicated. If certifications or assurance reports are offered, check scope, dates and exceptions with the appropriate specialist. A badge does not establish coverage of every feature or deployment arrangement.

Test performance on your scenarios

Use fictional or approved test material and include ordinary tasks, missing information and conflicting sources. Agree what constitutes a material error and how human review works. Ask the supplier to demonstrate failures and the recovery route as well as successful examples.

Record unsupported claims separately from verified capabilities. A roadmap item, bespoke development proposal and available feature have different costs and delivery risks. Include the time needed for review, administration and correction in the value assessment.

Worked example: review-summary software

Illustrative scenario: a supplier summarises performance notes. The buyer tests a changed goal, limited history and contradictory project feedback. The evaluation checks whether the summary preserves context and links statements to accessible sources.

One output turns a future goal into a completed achievement. The buyer records the failure, asks how it is detected and tests the proposed mitigation. The decision is based on repeatable evidence and the consequences of residual errors, not one polished demonstration.

Supplier comparison worksheet

• Requirement: What must the service do for the approved use case?
• Evidence: Which demonstration, document or contractual term supports the answer?
• Data arrangement: What is processed, where, by whom and for how long?
• Control: How are access, review, correction and incidents handled?
• Change: What happens when the model or a subprocessor changes?
• Cost and ownership: What setup, review and operating effort is required?
• Exit: How can data be exported, access ended and deletion verified?

Keep unanswered items visible with an owner and due date. Do not convert “supplier will confirm” into a positive score.

Contract and launch with acceptance criteria

Translate important commitments into the reviewed agreement and implementation plan. Define acceptance tests, responsibilities, support and a fallback if the service fails. Confirm that the approved configuration matches what was evaluated.

Use the software RFP template for a wider procurement structure. The NIST AI Risk Management Framework is useful background for risk questions; it is not a certification of a supplier or a substitute for reviewing your deployment.

Put the guide into practice

Set aside a working session with the people who own this process and one or two people who experience it. Use a fictional or appropriately authorised case, so the discussion can be specific without sharing unnecessary personal information. The purpose is to leave with a usable decision or document, not just agreement that the topic matters.

Prepare the case

Prepare a use-case brief with approved inputs, expected output, users and consequences of an error. Identify the required reviewers and decision owner. Ask each supplier to respond to the same scenario. Without a common brief, comparisons can become a contest between unrelated demonstrations and marketing claims.

Write the starting assumptions down before discussing solutions. If the group disagrees on what happened, identify the information needed to resolve that difference rather than building a plan on an untested story.

Work through the decision

Request current evidence for important claims and record its scope. Test output quality, access and correction using sample cases. Distinguish a contractual commitment from a presentation statement, and an available feature from custom development. Include review effort and internal administration in the comparison rather than focusing only on the subscription price.

Ask each participant to explain the proposed decision in their own words. Differences in interpretation often reveal an unclear criterion, a missing responsibility or an instruction that will be difficult to follow.

Test an exception

Introduce a model change, an incident or a request to end the service. Ask who is notified, what evidence is available and how data is exported or deleted. Check the responsibilities of the application vendor, model provider and your organisation. Do not assume the supplier relationship removes your own operating obligations.

Record what changes in this situation and what remains the same. An exception should lead to a clear next step, with an owner, rather than an informal workaround that nobody can explain later.

Agree the handoff

Give the approver a decision record with verified capabilities, unresolved gaps, conditions and acceptance tests. Assign an owner to each open item. The contract and implementation plan should reflect material commitments, and the launch configuration should match the arrangement that the reviewers actually assessed.

Finish by confirming the owner, the next action and the date when the result will be reviewed. Give the person receiving the work enough context to continue without repeating the whole discussion.

Frequently asked questions

Which AI supplier question should we ask first?

Start by asking the supplier to demonstrate the specific task you need using representative approved data. Then examine the information flow, output review and consequences of errors. A generic description of the model is less useful than understanding the complete service you will operate. The first question should connect directly to your use case and the evidence needed for a decision.

Does a security certification settle AI procurement risk?

No single assurance item answers every question. Check the certification or report’s scope, validity and exceptions with the relevant specialist. You still need to evaluate the actual feature, data arrangement, output behaviour, human review and contractual responsibilities. Treat assurance evidence as part of the decision rather than a substitute for assessing the proposed deployment.

What should an AI contract address?

The exact terms need professional review, but procurement should raise service scope, data processing, retention, deletion, model changes, support, incident communication, responsibilities and exit. Translate important promises into the reviewed agreement where appropriate. Keep acceptance tests and operational ownership clear so the organisation knows what must be true before launch and what happens if the service changes.

Review the first cycle

Compare the implemented configuration with the evaluated proposal and resolve material differences. Review whether the supplier delivered evidence and support as agreed. Keep outstanding conditions visible after purchase; procurement work is not complete when the contract is signed if critical launch requirements remain unresolved.

Keep a brief record of what was tried, what participants found useful and what needs to change. Compare the result with the original problem rather than judging success only by completion. If the process created extra work without improving clarity, quality or support, simplify it and test again. Share the agreed change with the people who will use it, and name the person responsible for keeping the guidance current.

About New Dynamics

New Dynamics connects goals, feedback, recognition and reviews around the way organisations work. This guide is published by the New Dynamics Editorial Team as part of our practical library for HR leaders, managers and People teams.

Use the examples and worksheets to structure your own discussions and adapt them to your organisation. Illustrative scenarios are not customer case studies. Policy and employment guidance needs appropriate local review before adoption.

For questions about this guide, corrections or a conversation about your performance management process, email contact@new-dynamics.com. Explore the complete guide library for related resources.