AI for HR Reporting: Asking People Data Questions in Plain Language

By Kevin Kim · Updated Oct 11, 2026

AI for HR reporting means letting people ask questions of HR data in everyday language, such as "What was voluntary turnover in support last quarter?", and having software translate the question into a query, run it against governed data and return a table, chart or short explanation. The technique behind it is usually text-to-SQL: a language model writes the database query so the asker doesn't have to. Done well, it removes the report-request queue. Done badly, it hands confident wrong numbers, or someone's salary, to the wrong person.

This guide is for HR leaders, people analytics owners and HR business partners who are being shown a "chat with your HR data" demo. It covers how natural-language querying works, what changes for dashboards and recurring reports, how to control who can see what, and how to check that the answers are right. It sits inside the AI in HR section and builds on people analytics and AI.

Key Facts

• On the BIRD text-to-SQL benchmark (12,751 question-SQL pairs over 95 large databases, 33.4 GB), human data engineers and database students score 92.96% execution accuracy. The top model on the overall leaderboard scored 82.95% on the test set as of 7 September 2026, roughly 10 points behind (BIRD leaderboard).
• When BIRD was introduced, the best model tested, ChatGPT, reached 40.08% execution accuracy against 92.96% for humans (arXiv). Benchmark gains have been steep, and a gap to humans remains.
• A 2022 paper in Transactions on Data Privacy argues that ten is a popular minimum cell size in disclosure control but has no statistical justification above three, and that there is no monotonic relation between a threshold and risk (Ritchie, Transactions on Data Privacy).
• NIST's AI Risk Management Framework, released on 26 January 2023, organizes AI risk work into four functions: Govern, Map, Measure and Manage (NIST).
• The UK ICO's motivated intruder test asks whether a reasonably competent person with access to resources such as the internet and public records could identify someone from supposedly anonymous information (ICO).

What Changes When HR Reporting Goes Conversational

Traditional HR reporting has three layers. Analysts build dashboards for the questions they can predict. Everything else becomes a ticket: a director wants attrition by tenure band and manager, an analyst spends two days pulling it, and by the time it lands the meeting is over.

In ACE Framework terms, conversational reporting ingests structured HR data, analyzes it with a query, and generates a readable answer. Three pieces make it work:

1. A language interface. A model reads the question using natural language processing and works out what's being asked: which metric, which population, which time window.
2. A translation layer. The model writes a query, usually SQL, against your HR tables. This is the text-to-SQL step.
3. A governed data layer. The query runs against a defined set of tables, metrics and permissions, not against raw payroll and case files.

The third piece is the one that decides whether the project works. A model asked to guess what "headcount" means from column names will guess differently on Tuesday than on Monday. A semantic layer fixes that. It's a maintained dictionary that says "headcount means active employees with an employment record on the last day of the period, excluding contingent workers", "voluntary turnover excludes retirements" and "tenure is measured from original hire date". The model picks from governed definitions instead of improvising them.

Dashboards change too. Instead of forty fixed charts, you keep a smaller set of trusted ones for the board and monthly rhythm, and let people ask follow-ups on top: "Break that down by location", "Exclude interns", "Compare with last year". Scheduled reports can add an explanation, a sentence on what moved and an alert when a number leaves its normal range. That's the pattern a reporting agent follows: pull on a schedule, build the report, flag anomalies, send it to the right people.

How Accurate Is Text-to-SQL Really?

Better than it was, and still not good enough to trust blindly. The numbers help calibrate.

BIRD is a widely used benchmark built from real-looking, messy databases, with questions that need business knowledge to answer. At launch in 2023, the best model tested got about 40% of questions right on execution accuracy, while humans got 92.96% (arXiv). The current leaderboard shows the top overall model at 82.95% on the test set as of 7 September 2026, still about ten points below humans (BIRD leaderboard). That's a large jump and a real gap.

Read that carefully. Benchmark accuracy measures whether the query returns the same result as a reference query. Your HR data adds problems a benchmark doesn't have:

• Ambiguous words. "Employees" might include contractors. "Last quarter" might mean fiscal or calendar. "Manager" might be the direct manager or the org-chart head.
• Messy history. Reorganizations, rehires, name changes and backdated corrections make simple counts tricky.
• Terminology that differs by company. "Regretted attrition" or "high performer" exists only in your policy documents.
• Silent errors. A wrong query that runs doesn't throw an error. It returns a plausible number. This is the same family of failure as AI hallucination, except the invented answer arrives formatted as a chart.

So the practical conclusion isn't "don't use it". It's "make the easy questions reliable, and make the answer inspectable". Show the user the query, the definitions used and the filters applied, so a person can see that "turnover" meant voluntary exits only.

Real Examples by Function

HR business partner. Before a quarterly review, an HRBP asks, "Which teams in operations had more than 15% annualized turnover, and how long had the leavers been here?" The tool returns a table. The HRBP notices two small teams dominate it and asks for the numbers by tenure band. The follow-up takes a minute, not a ticket.

Recruiting lead. "How many days did it take to fill engineering roles opened in the first half of the year, and where did candidates drop out?" The answer joins the applicant tracking and HRIS data. The lead sees the drop-off sits between hiring manager screen and onsite and takes it to the manager for fixing.

Compensation analyst. "Show me the pay range position by job level for the sales organization." This question touches sensitive data, so it's a good test of access control. The analyst with compensation rights gets it. A line manager asking the same question gets their own team's figures, or a refusal.

Finance partner. "What's our headcount by cost center at month end, compared with budget?" The value here is consistency: HR and finance see the same number because both are using the same definition in the semantic layer.

CHRO. A scheduled weekly summary lands in the inbox: headcount movement, open requisitions, absence trends and a note that overtime in one site has run above its normal range for three weeks. The CHRO can click through and ask why.

Employee self-service. An employee asks the HR assistant how many vacation days they have left. This is a single-person lookup, not analytics, and it belongs in the employee self-service pattern with its own, much narrower permissions.

Access Controls: Who Can Ask What

HR data is among the most sensitive a company holds. A conversational interface makes access easier, which is the point, and also makes mistakes easier. The controls below aren't optional.

Role-based access, enforced in the data layer. Don't rely on a prompt that says "don't show salaries to managers". Prompts can be talked around. Permissions should be enforced in the database or semantic layer, so the query physically can't return rows or columns the user isn't entitled to. A manager sees their reporting line. An HRBP sees their business unit. Payroll sees pay. The model inherits the asker's rights; it never runs with a super-user account.

Column-level and row-level rules. Some fields (health data, disciplinary records, immigration status, union membership) should be unreachable through the conversational tool entirely. Others (salary) should be visible only in aggregate except to defined roles.

Small-cell suppression. A chart showing "average rating by gender in a team of four" identifies individuals. The usual fix is to suppress or merge any group below a minimum size. Choose the threshold on purpose. Many organizations use ten, but research on disclosure control argues that ten is popular by convention, that the only threshold with a solid statistical basis is three, and that a higher threshold doesn't reliably lower risk, so how you check outputs matters as much as the number (Ritchie, Transactions on Data Privacy). Set a minimum, apply it consistently, and review it with your privacy team.

Watch for differencing. If a user can ask for "headcount of the whole department" and then "headcount excluding one person's team", subtracting the two reveals a small group. Suppressing one cell isn't enough when the missing value can be recovered from totals, so complementary suppression, rounding or merged categories may be needed. Rate-limit and log repeated narrow queries.

Anonymity thresholds for survey and sentiment data. Engagement comments are especially risky because free text names people. Report themes only above a minimum respondent count, and never show verbatim text from a group small enough to be identified.

Test for re-identification. The ICO frames it as a motivated intruder test: could a reasonably competent person with access to public information identify someone from what you're about to release (ICO)? If a manager can combine a "team of five" chart with what they already know, the output isn't anonymous.

Log everything. Record who asked, what was asked, which query ran and what was returned. Audit logs are how you answer a works council, a regulator or an employee who asks who looked at their data.

Mind data protection law. In the EU and UK, personal data should be limited to what the purpose requires and protection built in by default, as GDPR's recitals on data minimisation and data protection by design describe (EUR-Lex). Where a model vendor processes the data, check where it's stored, whether prompts are retained and whether they're used for training. Take legal advice for each country you operate in.

Accuracy Checks Before You Trust an Answer

Treat the first six months like onboarding a new analyst: check their work often, then less often as they earn it.

The NIST AI Risk Management Framework gives a vocabulary for this (NIST). Govern means someone owns the tool and its policies. Map means you've listed the questions it will and won't answer. Measure means you track accuracy against your golden set. Manage means you act when it drifts.

How to Implement It Step by Step

1. Start with the top twenty questions. Look at the last year of report requests. Most organizations find a handful of questions make up the majority of the load: headcount, turnover, hiring pace, absence, tenure. Build for those first.
2. Fix the definitions. Agree, in writing, on headcount, active employee, voluntary exit, tenure and time to fill. If HR and finance disagree, resolve it before any tool does it for you. The groundwork is in HR data foundations for AI.
3. Build the governed data layer. Expose curated views, not raw tables. Put definitions in the semantic layer. Exclude the fields that must never be reachable.
4. Wire permissions to your identity system. Role-based access should come from the same source of truth as your HR system roles, so a transfer or termination changes access the same day.
5. Set suppression and anonymity rules. Pick minimum group sizes, decide how to handle totals and differencing, and write the rules down.
6. Pilot with analysts, not the whole company. Let the people analytics team use it first. They'll find the ambiguous questions and wrong answers fastest.
7. Build the golden set and monitor it. Run it on every change. Track the share of answers that users flag.
8. Widen access in stages. HR business partners, then HR leadership, then managers with team-level scope. Keep each stage until the error rate and the access tests look right.
9. Decide who owns it. Someone has to own definitions, permissions and the review queue. AI and the HR operating model covers how to assign that.
10. Keep people in the loop for decisions about people. A reporting tool describes. Anything that affects an individual, such as a pay change or a performance outcome, needs a human decision outside the tool.

For an example of a model that should stay at team level, see predicting employee attrition with AI.

Common Pitfalls

• Skipping the semantic layer. If the model guesses what "turnover" means, you'll get a different answer each week and lose trust fast.
• Giving the tool a super-user account. The model should only ever see what the asker may see.
• Trusting a prompt for security. "Never reveal salaries" is a request, not a control. Enforce it in the data layer.
• Ignoring small groups. The most common privacy failure in HR reporting is a neat chart of a team of three.
• Measuring only the demo. A vendor demo uses clean data and friendly questions. Test on your messy history and your ambiguous wording.
• Hiding the query. If people can't see how a number was produced, they can't catch a wrong one.
• Replacing analysts instead of freeing them. The goal is to clear the routine queue so analysts can do the work that needs judgment: root causes, modelling and advice.
• Letting dashboards sprawl. Conversational access doesn't remove the need for a small set of governed, official numbers.

Once your reporting is reliable, the same governed data can support summaries, drafts and briefings that cite the numbers behind them.