AI governance for HR agents — a practical operating model

Most HRIS teams trying to run agents in 2026 are stuck on the same problem. They have three or four agent ideas on the list. Legal is nervous. IT has open questions. Privacy wants documentation nobody has written. The CHRO is asking when something will ship. Every party has a legitimate concern. The team has no structured way to address them all in the same room.

The fix is unglamorous. A small board with the right people, a checklist that covers the right questions, a RACI that takes the role argument off the table, and a clean sequence from idea to go-live. None of this requires hiring an AI ethics officer or buying a governance platform. It requires a few weeks of discipline and a willingness to say no to scope creep.

Who should be on the board

The minimum useful composition. HRIS, who owns the platform and brings the use cases. IT or enterprise architecture, who owns the integration and security context. Legal or privacy, who owns the regulatory read. A senior HR voice, who owns the operating-side risk. That is four people. For high-risk use cases, you add InfoSec and, where applicable, a works council or employee representative.

The mistake we see most often is a board that is too senior to meet often, or too junior to make decisions. The right level is decision-makers with practical responsibility. A CHRO does not need to be in every review. A Legal Counsel with employment law and data protection experience does. The board meets monthly, with a fast lane for use cases that need quicker turnaround.

What the board does in three sentences. It reviews each new AI use case against the standard checklist. It decides enable, pilot, or wait, with conditions where relevant. It maintains a register of live AI use cases and revisits them at least annually.

The checklist that does most of the work

Eleven categories. We have refined this list over a year of running it with clients. It is not exhaustive but it covers the questions a deployer of HR AI needs to answer, and it is short enough to actually fit on one page.

• Purpose and risk level. What does the AI do, and does it influence hiring, pay, promotion, or termination?
• Roles. Who is provider, deployer, and downstream provider for this AI?
• Data sources and quality. Which data fields does it rely on, and is the data accurate enough?
• Lawful basis and privacy. Does the existing legal basis cover this use of personal data?
• Fairness and bias. Could the output create unfair outcomes for protected groups?
• Human oversight. Where can humans review, override, or stop the AI?
• User transparency. Are affected employees informed that AI is being used, and how do they raise concerns?
• Security and access. Who can configure, run, and see outputs of this AI?
• Vendor assurance. For native or partner AI, have we reviewed the vendor's documentation?
• Monitoring and logging. How will we monitor performance, errors, and misuse over time?
• Regulatory alignment. EU AI Act category and any other applicable regimes.

Each line on the checklist needs a one or two sentence answer for each use case. Not a memo. A sentence. The discipline of being short forces the actual question, which is "do we know enough to ship this, and if not, what do we still need to find out?"

A RACI that prevents the role argument

A second discipline that saves time. Write down once who is responsible, accountable, consulted, and informed for the activities that happen across every agent. Do not negotiate it again for each use case. The activities that benefit most from a clean RACI: identifying and prioritising use cases, approving the business case, performing the risk assessment, building the agent, integrating with Workday, deciding go-live, monitoring after go-live, and handling incidents.

A working pattern we use. The HRIS Lead is accountable for prioritising use cases and monitoring agents in production. The Agent Product Owner is accountable for the design and ongoing improvement of each specific agent. The Workday Architect or IT lead is accountable for the technical design and integration. The DPO or Legal is accountable for privacy and risk assessment. The CHRO or CIO is accountable for go-live decisions on high-impact agents. Vendors and partners are responsible for delivery alongside your team, not accountable for outcomes.

That set of accountabilities reflects how decisions actually flow. It also makes the difficult conversations less personal. "DPO is accountable for the privacy read" is a published rule, not a complaint about whose desk a task lives on.

The sequence from idea to go-live

Idea on the list. HRIS captures it with a one-paragraph description, the request type (transaction, knowledge, status, advice, complex case), and a rough business case sketch.

First-pass classification. HRIS marks it low, medium, or high risk based on the EU AI Act lens plus a check on which other jurisdictions are in scope. Low-risk use cases go to a lighter-touch path. Medium and high go to the full sequence.

Pre-board briefing. Before the board meets, HRIS talks one-to-one with each member who will be in the room. Not for approval, for feedback. Each person gets to surface their concerns early. Most of the difficult work happens in these conversations, not in the meeting.

Board review. The use case is presented in a tight template (purpose, risk view, data used, human oversight, controls). The board decides enable, pilot, or wait, with conditions if needed. A named owner and a review date are assigned. The decision is logged.

Pilot. For anything new or above low-risk, the answer is almost always "pilot first, scale later". A defined user group, a clear KPI set, a stop-or-scale review date. The pilot is the safety net that lets the board be permissive at the front of the funnel.

Live operation. Once an agent is in production, it goes onto the register. Quarterly review of usage and incidents. Annual review against the checklist to confirm nothing has drifted (a Workday release added a feature, a regulation changed, a data source moved).

Retirement. The most underused part of any agent operating model. Some agents earn their place. Others do not. A clear retirement path keeps the portfolio honest and the register short.

The board briefing template that gets decisions

One page per use case. The feature or agent name. The process and personas it touches. The value summary in two sentences. A link to the business case. The solution type (native, partner, custom). The type of AI (machine learning, GenAI, agent). A risk-and-controls summary in five bullets matching the checklist categories that matter most for this case. A link to the vendor's AI Fact Sheet if applicable. The ask to the board: enable, pilot, or wait, with proposed conditions.

The discipline of writing this page surfaces the gaps. Most use cases that struggle to fit on a single page are not yet ready. That is useful information, not a failure of the template.

Change management belongs in the operating model

A piece teams skip. The board decides to ship an agent. The pilot launches. Nobody uses it. The agent quietly dies. Or worse, the agent is used but only because adoption was pushed, and the users do not trust it.

A working change approach for HR agents follows the standard adoption model: awareness, desire, knowledge, ability, reinforcement. The version that fits HR agents specifically. Awareness: a simple story about why agents and how Workday stays the source of truth. Desire: real benefits in the user's language (fewer clicks, faster answers), with early-adopter stories from real teams. Knowledge: quick guides that show what the agent can and cannot do, in three bullets. Ability: pilots and small groups with active support channels. Reinforcement: usage numbers shared, teams who use the agent well recognised, KPIs added to the HRIS scorecard.

Change work is unglamorous and difficult to invoice for. It is also why some agents live for two years and others end up as tenant artefacts within six months. The board can approve every agent on the list and still none of them will be used if the change work was skipped.

Upskilling, briefly

The team running the operating model needs to understand the technology well enough to ask the right questions. Not deep ML knowledge. Practical literacy. The difference between deterministic and probabilistic systems. What retrieval-augmented generation is and where it fits. How human-in-the-loop actually looks in a workflow. Why evaluations matter for AI systems. A few hours a week of structured learning, against a defined curriculum, builds this faster than people expect.

Pair functional team members with technical team members on real use cases. The functional owner asks "what could this do for our process". The technical owner sketches "how would we build it with the tools we know". The pair becomes the operating pattern for the next ten use cases. This is much more useful than sending people on AI training courses one at a time.

What a healthy operating model looks like after a year

The signs are visible across the organisation, not just inside the governance board. The board meets monthly and decides things, instead of deferring everything. A register of live AI use cases exists and anyone on the team can read it. The checklist has been applied to every active use case, not just the headline ones. Each agent has a named owner who can be reached. Some agents have been turned off, which is healthy because it means the retirement track is real. And the upskilling rhythm sits in calendars rather than in slide decks. None of these on their own is decisive. Together they are what an operating model that ships looks like.