Short answer
Implement AI in HR around one defined work decision, not a broad promise to transform HR. Name the owner, affected population, permitted data, prohibited uses and human review before the pilot. Test the complete workflow under realistic conditions, record failures, and scale only when the operating controls work.
This guide starts after the software demonstration
A polished demonstration can establish what happened in a controlled session. It cannot establish how the system will behave with your configuration, employees, data, reviewers and exceptions. Use the AI HR demo checklist to test a product before a pilot. Use this guide to design the implementation after a candidate workflow has survived that review.
The implementation job has five stages:
- define the work decision and boundaries;
- map people, data and responsibilities;
- configure and test with fictional cases;
- run a bounded pilot with human review;
- decide whether to stop, adjust, repeat or scale.
Treat each stage as a decision gate. A scheduled launch date is not evidence that the next gate is ready.
Write a one-page implementation charter
The charter should be short enough for HR, operations, privacy, security and employee representatives to challenge together.
| Field | Question to answer |
|---|---|
| Work decision | What will a named person decide or prepare differently? |
| Current process | What happens today, including delays and existing safeguards? |
| Intended users | Who participates, reviews, acts and administers? |
| AI task | Does the system collect, summarise, classify, retrieve or draft? |
| Human authority | Who checks the output and owns the final decision? |
| Permitted data | Which minimum fields and sources are needed for this purpose? |
| Prohibited use | What must never be inferred, scored or decided from the output? |
| Success evidence | Which delivery, quality and work measures will be reviewed? |
| Stop conditions | Which error, harm, access failure or operating gap pauses the pilot? |
For example, “use AI to improve retention” is too broad. “Help HR prepare a group-level review of onboarding friction for new store employees, without rating individuals or making employment decisions” is testable.
The NIST AI Risk Management Framework asks organisations to document business context, intended use, knowledge limits, human oversight, roles, testing and monitoring. Its functions are voluntary and not a certification. They provide a useful structure for assigning implementation work rather than treating governance as one approval meeting.
Map the workflow before mapping the technology
Draw the path from invitation to action. Include the points where someone can decline, correct an interpretation, report a concern or use another process.
Use four lanes:
- Participant: what the person is asked, what they are told and what choices they have.
- System: what is collected, transformed, retained, displayed or transferred.
- Reviewer: what source context is available and what must be checked.
- Decision owner: what action can be approved, declined, escalated or returned for more evidence.
Do not use an AI workflow as the only route for a grievance, safety concern, accommodation request or other matter that requires an appropriate specialist process. The implementation charter should say how such material is handled and which promises cannot be made.
Minimise data before connecting systems
Start with the decision, then justify each field. A useful implementation rarely needs every HRIS column, every historical comment or a persistent individual risk label.
The UK Information Commissioner's Office says data protection by design should be considered at design time and throughout the lifecycle. Its current guidance also connects protection by default to limiting personal information to what is necessary for each specific purpose. UK organisations should apply that guidance to their circumstances. US organisations still benefit from the same practical questions about purpose, access and retention, alongside applicable state and federal requirements.
For each input, record:
- source and field owner;
- reason it is needed;
- eligible population and period;
- transformation or grouping;
- people and services with access;
- retention and correction process;
- what breaks if the field is missing or wrong.
If the implementation needs an HRIS exchange, use the separate HRIS and AI integration guide to design the data contract and reconciliation test. Do not assume that a named connector, API, import or write-back exists because a workflow diagram needs it.
Assign operating roles
“Human in the loop” is not an operating model. Name the human, their evidence and their authority.
| Role | Accountable for | Must not be assumed |
|---|---|---|
| Executive sponsor | Purpose, risk tolerance and resources | Daily review or technical approval |
| Process owner | End-to-end workflow and follow-up | Privacy or security expertise |
| HR reviewer | Source check, context and appropriate route | Authority over every operational change |
| Manager | Local action within their remit | Access to raw employee conversations |
| Privacy or legal owner | Applicable requirements and documented controls | Ownership of product quality |
| Security or integration owner | Access, credentials, logging and failure response | Correct interpretation of employee context |
| Employee representative or participant group | Practical feedback on invitation, choices and impact | Final accountability for the system |
Use a decision log when roles disagree. Record the question, evidence, owner, decision, conditions and review date.
Run a staged pilot
The sequence below defines evidence to gather at each stage. Choose the duration to cover the actual workflow and its exceptions.
Stage 1: configuration and fictional tests
Before live data, test ambiguity, refusal, correction, conflicting accounts, missing fields, inappropriate requests and each access role. Capture expected and observed behaviour. Resolve any critical access or routing failure before inviting employees.
Stage 2: limited live workflow
Choose one population whose work context is understood and whose owner can respond. Explain the purpose, voluntary or required elements, access, record use and other available routes. Monitor invitations, participation, failures, review workload and follow-up.
Stage 3: decision review
Compare the pilot with the original process. Check delivery separately from outcome:
- Did the intended population receive and understand the invitation?
- Could participants decline, pause or correct the relevant material as designed?
- Could reviewers trace important output to its source context?
- Did access views match the approved roles?
- How much review and follow-up work did the process require?
- Did the named decision happen, and was it better supported?
- Which groups, languages or edge cases were not adequately tested?
An increase in participation does not prove better decisions. A completed action does not prove a retention, performance or wellbeing effect.
Worked example: onboarding handovers
This fictional US example demonstrates the implementation method, not a product result.
A retail operations team wants to understand where new supervisors lose context during shift handovers. It initially proposes analysing every new supervisor's HR record and rating onboarding risk.
The charter narrows the task. New supervisors in one region can describe one recent handover and what information was missing. HR reviews group patterns; operations owns any process change. No individual readiness, performance or departure score is produced.
The team tests fictional accounts first, including an unclear answer, a refusal and a safety concern that must use another route. It then pilots the workflow with the agreed population. Reviewers find that some summaries merge a missing stock update with a separate scheduling complaint. The team pauses reporting, corrects the prompt and repeats the fictional cases before continuing.
At review, the useful outcome is not “AI improved onboarding”. The evidence is narrower: the revised workflow preserved the two issues separately, the regional owner changed the handover checklist, and the next cohort can assess whether that change reaches the relevant shift. Wider rollout remains a new decision.
Use a scale gate, not momentum
Score each requirement as demonstrated, partly demonstrated, not demonstrated or not applicable.
| Scale requirement | Evidence to require |
|---|---|
| Defined purpose | Current charter and prohibited uses |
| Participant understanding | Tested invitation and feedback from the intended population |
| Output fidelity | Source-to-output review across ordinary and difficult cases |
| Human review | Named reviewers, workload and correction path |
| Access and security | Tested roles, logs, credential owner and incident route |
| Operational follow-up | Actions, owners, dependencies and review dates |
| Coverage | Known gaps by role, location, language or work pattern |
| Monitoring | Measures, thresholds and authority to pause or change the workflow |
Scale the parts that worked. A pilot may justify another site while leaving a language, integration or use case unresolved. Maintain version, configuration and change records so later results can be tied to the system that produced them.
Where Lontra fits
Lontra's product approach supports focused employee conversations and manager briefs for human follow-up. Managers receive a brief rather than raw conversations. The platform does not decide who should be hired, promoted or retained, and it does not predict an individual's departure.
Treat integrations, identity configuration, exports and other technical requirements as items to verify for the proposed deployment. The implementation charter remains useful whether the pilot uses a manual roster, an approved file exchange or a verified system connection.
Frequently asked questions
How should an organisation start an AI HR implementation?
Start with one work decision, one eligible population and one accountable owner. Define the data, prohibited uses, human review, success measures and stop conditions before configuring or inviting employees.
How long should an AI HR pilot run?
There is no universal duration. Choose a period that includes enough instances of the real workflow to test participation, review effort, access, errors and follow-up. Calendar length alone does not make a pilot representative.
What should an AI HR implementation measure?
Measure whether the workflow was delivered, whether outputs remained faithful to their sources, how much human review was required, whether the intended decision improved, and which harms, errors or exclusions appeared.
When is an AI HR system ready to scale?
Scale only when the intended use, access roles, employee explanation, review process, error handling and operating owner have worked under conditions close to deployment. Record remaining limits and keep a pause route.