I've Been Asked to Explore an HR Copilot Agent. What Do I Need to Decide Before Involving IT?

The Problem We Are Solving

Maybe this started when a manager said, “Could we have an HR Copilot agent for this?” It sounds like a simple request. Then the awkward questions begin.

Should it help people find the annual-leave policy? Explain what the policy says? Collect details for a flexible-working request? Update an absence record? Advise a manager about a named employee?

Those are not different versions of the same job.

An HR Copilot agent is an internal conversational tool that uses Microsoft Copilot technology for an HR-related task. The name alone tells you nothing about what it can read, what it may do, or what it should never decide.

Before asking IT to choose the technology, define whether the request is to find information, take action, or make a judgement. That one distinction changes the data, permissions, owners, tests, and human review the request needs.

The Short Answer

Do not send IT a request that says, “Please build us an HR agent.”

Send a bounded proposal that names:

• The employee or manager problem.
• What the agent should answer or do.
• The approved information it may use.
• The personal or sensitive information it might receive.
• What it must refuse and where it sends the person instead.
• Who owns the policy, technology, approval, and maintenance.
• How a small pilot will be tested and stopped if it fails.

If those answers are missing, the request is not ready for a product decision.

A bounded information-only agent is limited to named approved sources and users. It can return general information with citations, but it cannot update a system or decide a personal case.

First, Classify the Job

A conversation can cross categories. A person may begin by asking for the absence policy and then add medical details or ask what should happen to a named employee. Scope the agent for what it may receive, not just for the friendly example in its welcome message.

Check Whether an Agent Is the Right Fix

Repeated questions do not automatically justify an agent. Sometimes the real problem is a collection of stale policies, duplicate documents, poor SharePoint navigation, unclear ownership, or a form nobody can find.

Use the lightest intervention that fixes the problem:

Define the Information Boundary

“Use the HR SharePoint site” is not a source definition.

For every source, record:

• The exact site, library, folder, page, or document.
• Its version, effective date, and review date.
• The policy owner who says it is authoritative.
• Who can currently open it.
• Whether draft, superseded, local, restricted, or duplicate versions exist.
• What the agent should do when two sources disagree.
• Whether every policy answer must show a citation.
• Whether general web content is allowed. For an internal policy pilot, the starting assumption should be no unless HR explicitly approves it.

For Microsoft 365 and SharePoint-grounded answers, the signed-in person's existing source permissions affect what can be returned. That is useful, but it is not an approval of the permissions already in place. An agent can make an existing oversharing problem easier to discover. Do not assume the same identity model applies to an action or connector. Ask IT whose connection or service identity it uses.

Define the Human Boundary

A useful refusal does more than say “contact HR.” It explains the boundary without repeating unnecessary personal details and gives the person a working route.

For example:

An information-only HR agent should normally refuse or escalate:

• Requests to decide individual entitlement.
• Requests for another employee's information.
• Recommendations about recruitment, pay, performance, discipline, redundancy, or dismissal.
• Health, disability, absence, pregnancy, grievance, safeguarding, harassment, whistleblowing, or misconduct questions that need case-specific handling.
• Requests to bypass an approval, permission, or established HR process.
• Questions where approved sources conflict, are missing, or are out of date.
• Requests to reveal restricted documents or personal records.

Record the human team's name, route, hours, urgent route, minimum handover details, and the owner responsible for keeping that information current.

Treat Employee Data as Expected, Not Exceptional

Even a policy FAQ can receive names, health details, grievance information, pay questions, trade-union information, or allegations about another person. Questions, transcripts, audit records, and feedback may preserve some of that interaction.

Before a pilot, ask:

• What specific purpose requires this information?
• What is the minimum information needed?
• Can tests use fictional or anonymised cases?
• Who can see questions, transcripts, audit records, and reports?
• Where are they stored and how long are they kept?
• How will employees know what the agent does, what may be logged, and where human help is available?
• How can someone challenge or report a harmful answer?
• Who can suspend the pilot immediately?

The answers depend on the organisation, location, workforce, data, and intended use. Microsoft documentation can describe product controls. It cannot decide the organisation's lawful basis, privacy assessment, employment obligations, or approval route.

Assign the Owners Before the Technology

Do not let “the maker” become the accidental owner of everything.

Name these roles separately:

• Business owner: owns the problem, intended outcome, pilot, and stop decision.
• HR or policy owner: approves the source, interpretation boundary, refusals, and updates.
• Technical owner: owns configuration, identity, integrations, monitoring, and incident handling.
• Publisher or deployment approver: is authorised to make the agent available to the intended audience.
• Maintenance owner: checks sources, tests, permissions, ownership, failures, and review dates.
• Specialist reviewers: privacy, security, legal, compliance, employee relations, or employee representatives when the use, data, location, or consequence requires them.
• Human escalation owner: receives the questions the agent must not handle.
• Licensing or billing owner: confirms the current entitlement, metering, alerts, and stop controls.

If a critical role has no named person, record that gap. Do not quietly assign it to the adoption champion.

Define the Pilot Before Choosing the Product

A bounded information pilot needs more than a successful demonstration. Include:

• One narrow family of HR questions.
• One approved source set.
• A small audience that should already have access to those sources.
• Known-answer questions approved by the policy owner.
• Questions that require citations.
• Ambiguous questions that should trigger clarification or escalation.
• Questions from people with different source permissions.
• Individual-case and employment-judgement questions that must be refused.
• A test of the human escalation route.
• A test of how the owner pauses or retires the agent.
• A named review date and explicit stop conditions.

Record each test question, expected behaviour, actual behaviour, citation, reviewer, result, severity, and retest result.

Do not reduce this to one accuracy percentage. A single restricted-content exposure, unapproved action, invented policy, materially wrong answer, or employment recommendation can be enough to stop the pilot.

Choose One Status

Complete the HR Agent Request Brief

Copy this table into a working document. Write unknown rather than guessing.

Two Worked Decisions

Suitable for a bounded pilot

Keep the judgement human-owned

A manager wants an agent to consider a named employee's sickness absence, health information, performance history, and previous warnings, then recommend whether to start disciplinary action or dismiss them.

That is not a policy-finding job. It applies judgement to sensitive information and could influence a significant employment outcome. A safer design keeps the assessment with a qualified human case owner. A separate information-only agent might show the general absence process without receiving personal case details.

Provisional status: Do not build the requested judgement as an employee-facing agent.

Message to Send IT

Subject: HR agent request defined for review

We have completed an HR Agent Request Brief before selecting a Microsoft product.

The request is classified as [classification] and its provisional status is [status].

The intended users are [audience]. The approved sources are [sources], owned by [policy owner]. The agent may [permitted behaviour] and must not [prohibited behaviour]. Questions outside that boundary must go to [human route].

Please confirm the tenant, identity, permissions, source, sharing, logging, retention, licence, billing, monitoring, and suspension implications. Please also tell us which current Microsoft surface could meet this scope with the least access and complexity.

Please do not begin configuration until HR and the named reviewers have accepted those answers and the mandatory pilot tests.

Ask IT to record the date checked and answer:

1. Which current Microsoft agent surface fits the defined scope?
2. Which creator, owner, publisher, administrator, and user licences or entitlements are required?
3. Will usage consume Copilot Credits, pay-as-you-go charges, connector entitlement, Power Automate entitlement, or another metered service?
4. Whose identity and permissions will each source read or system action use?
5. Can the audience be limited to the named pilot users?
6. Which admin policies could block creation, knowledge sources, actions, authentication, sharing, or publication?
7. What logs and transcripts are created, who can see them, and what retention applies?
8. How will the team record and rerun the permission, citation, refusal, escalation, and negative-action tests?
9. How can the business owner suspend the agent immediately?
10. Which questions remain for HR, privacy, security, legal, compliance, or employee representatives rather than Microsoft technology?

Recommended Next Move

Complete the request brief before discussing SharePoint agents, Agent Builder, or Copilot Studio.

If the result is Ready for a bounded FAQ pilot, take the completed brief to HR and IT. Once they accept the scope, use Check What a SharePoint Agent Can Access Before You Build to compare what each Microsoft agent option can access, who can build it, and how licensing applies.

If the result is Needs more discovery, investigate the problem, sources, users, and owners. That is progress. You have found the missing decision before it became an expensive build problem.

Evidence Notes

Use current Microsoft documentation to understand product roles, permissions, sharing, admin review, logging, and billing. Do not use those pages as proof that your tenant is configured correctly, your policies are suitable, or your proposed HR use is approved.

Regulator and standards guidance explains why purpose, personal information, human involvement, testing, monitoring, challenge routes, and significant employment consequences matter. It does not decide which law applies to your organisation or approve a particular use. Ask the organisation's authorised HR, privacy, security, legal, compliance, and employee-relations specialists to make those decisions.

The safest proof available from this Briefing is a well-defined request with visible gaps and a provisional status. It does not prove that an agent will be accurate, lawful, secure, adopted, or valuable. Those claims require local review and real pilot evidence.

Microsoft product, licence, billing, preview, and menu-path claims were checked on 5 August 2026. They are volatile. Record a fresh check date before build or publication.