Bringing the AI Worker model to HR operations

IT was the first place we deployed an AI Worker because the requests are frequent, well-defined, and measurable. HR operations turn out to look remarkably similar once you strip away the vocabulary.

The same shape of work

A leave request is an access request with dates. An onboarding is a provisioning run across several systems. A payroll query is a lookup against a policy and a record. In every case there is a request in plain language, a policy that governs it, an approver, one or more systems to update, and a person waiting for an answer.

What Kepler does for people teams

• Onboarding and offboarding across HR, identity, payroll, and workspace systems in one coordinated run, with equipment and access tied to role.
• Policy questions answered from your own handbook and procedures, in Slack or Teams, with a citation to the source.
• Leave and benefits requests checked against entitlement and routed to the right manager for approval.
• Record changes such as role moves, reporting line updates, and address changes, applied consistently across systems.

Why the controls matter more here

People data is sensitive by definition, and in Ghana it sits squarely under the Data Protection Act. An AI Worker in HR has to be more conservative, not less: stricter approvals, tighter scopes, and a complete audit trail of every action taken. Those are the same policy controls Kepler runs on in IT, applied with a lower threshold for escalation.

One worker, one set of skills

Because Kepler learns by capturing how your team actually resolves requests, the HR skills grow the same way the IT ones did: alongside your people first, then autonomously for the routine cases. The organisations getting the most from it are the ones that treat IT and HR operations as one service desk rather than two.