Rolling out AI in HR: a 90-day planning guide

Move from a defined use case to a controlled pilot and an evidence-based launch decision. This practical guide to AI rollout in 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.

Use 90 days as a planning frame

A 90-day plan can create a useful sequence, but it is not a deadline that overrides unresolved risks. Some use cases need longer evaluation or should not proceed. Begin with one bounded task and an accountable sponsor.

Define the current problem, users and desired result. Include the cost of checking and correcting outputs. Agree what evidence would justify continuing, changing the scope or stopping before the team becomes committed to a particular tool.

Prepare the use case and controls

During the initial planning period, map information flows, confirm the approved tool and involve the required specialists. Establish the source material, permissions, retention and incident route. Identify the people who will review outputs and give them enough time and knowledge to do so.

Build a test set with ordinary cases and foreseeable failures. Include missing data, conflicting information and a case that should be escalated to a person. Record expected behaviour before running the test so evaluation does not shift to match the output.

Run a bounded pilot

Invite a representative group and explain the permitted task, information rules and fallback. Train participants using examples of both useful output and plausible mistakes. Keep the pilot small enough to review failures promptly.

Collect evidence on task quality, total time, corrections and user understanding. A high usage count does not establish benefit. Ask whether people can identify when the assistant is wrong and whether review is realistic under normal workload.

Worked example: manager preparation

Illustrative scenario: a team pilots an assistant that prepares questions from approved project notes. Managers verify the source context before using the questions in a conversation.

The pilot logs preparation time and cases where questions imply unsupported conclusions. If managers routinely miss those errors, the team narrows the use or changes the design before expansion. The decision is not based solely on whether participants enjoyed using the tool.

Rollout decision worksheet

• Weeks 1-2: What task, owner, baseline and information boundary are agreed?
• Weeks 3-4: What tests, permissions and review instructions must pass?
• Weeks 5-8: Who pilots the service and how are failures reviewed?
• Weeks 9-10: What changes are needed and which tests should be repeated?
• Weeks 11-12: What evidence supports expansion, a narrower scope or stopping?
• Ongoing ownership: Who monitors quality, supplier changes and user questions?
• Fallback: How does the work continue if the service is unavailable or paused?

Adapt the timetable to the task and approvals. Record unresolved issues explicitly and do not label a conditional decision as an unconditional launch approval.

Expand in stages and keep learning

Introduce the service to the next group only when the team can support it. Confirm that new users, data and work patterns remain within the evaluated scope. Update training and examples using lessons from the pilot.

Schedule review points and define changes that trigger re-evaluation. Retire the use if benefits do not justify effort or if important failures cannot be controlled. The AI governance guide provides the ownership record, while the AI literacy guide supports practical user training.

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

Write a pilot charter for one task with a baseline, owner and decision date. Identify the approved tool, information boundary and required reviewers. Include the cost of human checking. A timetable is useful for coordination, but it should not make unresolved questions disappear simply because the next phase has arrived.

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

Run agreed test cases before inviting pilot users. Include missing context, conflicting sources and a case requiring a human handoff. Record expected behaviour and actual failures. Prepare training around those examples so participants understand what they must verify and how to report a problem.

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 supplier change or a failure that users do not recognise. Apply the agreed stop conditions and fallback. Also test expansion to a team with different data or work patterns. The original pilot result may not transfer automatically, so identify what needs checking before access expands.

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

Prepare a decision brief comparing benefits, review effort, errors and user understanding with the baseline. State whether the recommendation is to expand, narrow, revise or stop. Give the ongoing owner the monitoring plan and support responsibilities; a successful pilot still needs a maintainable operating model.

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

Is 90 days enough to implement AI in HR?

It can be a useful planning horizon for a bounded use, but readiness depends on the task, data, reviews and evidence. Some uses need longer and others should not proceed. Do not treat a calendar as an acceptance criterion. Use the period to organise decisions and learning, with explicit conditions for moving forward and a willingness to stop.

How large should the pilot group be?

Choose a group small enough to support and review closely but representative enough to expose relevant differences in work. There is no universal number. Include people who will use the tool under ordinary conditions, not only enthusiastic experts. Make sure the team has capacity to investigate errors and that the pilot does not expose people to an unreviewed consequential process.

What is a good reason to stop a pilot?

Stop or restrict use when important failures cannot be controlled, reviewers cannot reliably detect errors, information boundaries are breached or the benefit does not justify operating effort. Define conditions before launch and give an owner authority to act. Stopping a poorly suited use is a useful decision, not evidence that the organisation failed to innovate.

Review the first cycle

Compare the final recommendation with the charter and evidence collected. Record what changed during the pilot and which limitations remain. If expansion is approved, introduce it in manageable stages and check that support, training and monitoring can handle the new scope. Keep a usable fallback and a named decision owner.

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.