How to let an AI agent update employee records in your HRIS

Grant HRIS permissions field by field, not record by record. An agent can apply approved changes to job, manager and contact fields at depth 3. Bank details, pay and leavers stay held for HR or payroll. Health, diversity and other special-category fields are outside its scope, and every edit records before, after and who asked.

Why are employee records harder than they look?

An employee record in a human resources information system holds three very different kinds of data. Some is routine: a work location, a phone extension, a cost centre. Some drives money: salary, allowances, bank details, tax codes. And some is sensitive in law: health information, ethnicity, religion, trade union membership, which data protection law treats as special category and protects more strictly.

A single "update employee record" permission covers all three, which is why it should never be granted. HR operations owns the record and the process of changing it. Payroll owns anything that feeds pay. The data protection officer owns the rules on special-category data. Line managers own the decisions behind many changes, such as a new role or reporting line.

Which fields should the agent change, and at what depth?

1. Agent, depth 1: reads the fields its job needs, not the whole record. A change-of-manager job needs the reporting line and job details; it does not need salary or health notes.
2. Agent, depth 1: verifies the request. Changes come through an approved route: a completed HR workflow, an approved change form, or the employee's own verified self-service request. An email saying "please update" is external and not enough.
3. Agent, depth 3: applies approved organisational changes: job title, grade, manager, department, cost centre and location, where an approved workflow record exists.
4. Agent, depth 3: applies the employee's own contact changes from a verified request: work phone, personal phone, emergency contact.
5. Agent, depth 2: prepares home address changes. An address can change tax or payroll region, so payroll confirms.
6. Agent, depth 2: prepares pay and allowance changes from an approved compensation decision. Payroll applies them.
7. Person, payroll: changes bank details. Diverting salary to a new account is a known fraud. Changes need verification through a channel the request did not come from.
8. Person, HR: processes leavers, contract changes and anything touching right-to-work evidence.
9. Refused for the agent: reading or writing special-category fields, and changing records of employees in HR or payroll themselves.

Why are HR and payroll staff records excluded?

The people who approve changes should not have their own records changed by a process they oversee. If the agent can update a payroll officer's bank details from a request that payroll officer approves, separation of duties is gone. Exclude these records from the agent's scope entirely and handle them by hand with a second approver.

How does this compare with customer records?

The structure is the same as updating customer records in a CRM: field-level scope, a verified source for each change, a before-and-after record. Two things differ. Employees have a continuing relationship with the firm that gives them more ways to dispute a change, and some HR fields carry legal consequences that customer contact fields do not. And as in a core banking system, any field that eventually moves money deserves the same caution as the payment itself.

What is recorded?

The request and its route: which workflow, form or self-service request, and the identity check.

The approval relied on, with the approver's name.

Every field changed, old and new values, and the effective date.

The verdict and the deciding bound for each attempted change. An attempt to touch a special-category field shows as refused by role scope.

Who read what. Read access to employee data is itself worth recording, because employees can ask what was done with their data and the firm must be able to answer.

What should you measure?

• Changes reversed after the agent applied them, by field.
• Requests the agent rejected for lack of a verified route, and how many were later found to be legitimate.
• Time from approved workflow to updated record, which often lags by days when done by hand.
• Payroll errors traced to record changes, before and after the agent.
• Attempted bank detail changes received through unverified routes.

Where does it usually go wrong?

Effective dates are ignored. A promotion approved today may be effective next month. Applying it now changes pay and reporting lines early. The agent must apply changes as future-dated where the system supports it, and hold them where it does not.

Free-text notes leak sensitive data. A manager's change form includes "reduced hours due to a medical condition". The agent copies the note into a field anyone in HR can read. Notes should be stripped of anything that looks like special-category data, or held.

Bulk changes skip the checks. A reorganisation moves 200 people to new managers. Teams want the agent to apply them all at once. Bulk changes should be certified as a separate capability, with a sample reviewed before release.

The service account sees everything. HRIS integrations are often given full read access for convenience. Narrow the account to the fields in scope; the agent's bounds should not be the only control.

Testing uses invented employees. Certification should replay real past changes, with their real awkwardness, as set out in train, shadow, certify, widen.

Where Pryme fits

In Pryme, each field group is a separate capability with its own depth, and special-category fields sit outside the agent's role scope, so attempts are refused at the moment of action. A change request from email is external and cannot by itself authorise an edit. Every change is filed with the approval it relied on.