Every HR tool has an AI badge now. Very few can tell you which specific minutes it saves.
AI earns its place in HR software in exactly one shape: drafting text from data you already have, for a human to edit. Summarising a month of logged work, turning a scope discussion into a structured quote, rewriting a policy paragraph. It does not belong anywhere a decision is made about a person, and for most numerical problems in workforce management — predicting how long a task takes, spotting attendance patterns — plain statistics are cheaper, faster and explainable.
Three patterns are worth having:
The common thread: the AI produces a draft, a person edits it, and the person remains accountable for the result. Nothing reaches an employee that a human did not approve.
A lot of what gets marketed as AI in workforce tools is a prediction problem over numeric data, where a language model is the wrong instrument entirely.
Time estimation. "How long will this task take?" is answered better by finding similar past tasks and looking at how long they took — similarity on the description, the project and the client — than by asking a model to guess. The statistical approach is faster, costs nothing per query, works offline, and, crucially, is explainable: you can show which past tasks produced the estimate. It also improves automatically as your history grows. The estimation problem in full is here.
Attendance and leave patterns. Counting and thresholds. A model is not required to notice that someone's Friday absences are elevated.
Payroll. Deterministic arithmetic with statutory rules. There is no role for a probabilistic system in computing what someone is owed, and a "roughly right" salary is simply a wrong salary.
If a vendor uses an LLM where a lookup would do, ask why. Often the answer is that "AI-powered" sells better than "median of similar past tasks" — even though the second is more useful.
Some decisions require a human who is accountable, can explain the reasoning, and can be challenged:
A practical test: if an employee asked "why?", could you give a specific, honest answer that does not reduce to "the system said so"? If not, a human has not actually made the decision.
When an AI feature runs, employee data usually leaves your workspace and goes to a model provider. That is a processing decision, and under frameworks like India's DPDP the accountability sits with you, not with your vendor.
Ask specifically:
A vendor that cannot answer these has not thought carefully about the feature they are charging for. The wider security checklist is here.
Five questions that cut through the presentation:
Assembled from the above, a responsible implementation has five properties:
| Genuinely useful | Summarising your own records · structuring unstructured input · drafting text |
|---|---|
| Better done statistically | Time estimation, attendance patterns, payroll arithmetic |
| Never AI-decided | Ratings, increments, promotion, termination, CV shortlisting, disciplinary outcomes |
| Required pattern | Draft → human edits → human is accountable |
| Privacy questions | Which provider · what is sent · used for training? · can it be disabled · is there a cap |
| Red flag | AI that cannot be switched off, or a product that stops working without it |
| Demo test | Ask "show me it being wrong" — a good vendor can |
In specific, narrow ways: summarising records you already hold into a first draft, turning unstructured input such as a scope conversation into structured fields, and ordinary writing assistance for policies and job descriptions. In each case the output is a draft that a human edits and remains accountable for. Broader claims usually describe problems that plain statistics solve better.
No. A draft summary assembled from logged work is a reasonable time-saver, but the judgement about a person's rating, increment, promotion or continued employment must be made by an accountable human who can explain the reasoning and be challenged on it. A useful test is whether you could answer 'why?' without saying 'the system decided'.
Usually not. Finding similar past tasks — by description, project and client — and looking at how long they actually took is faster, costs nothing per query, works without a network call, improves automatically as history grows, and is explainable because you can show which past tasks produced the estimate. A language model adds cost and opacity without adding accuracy.
Running an AI feature usually sends employee data to a model provider, which is a processing decision you remain accountable for under frameworks such as India's DPDP. Ask which provider receives the data, in which country it is processed, exactly what fields are sent, whether it is used for training, whether the feature can be disabled per company, and whether there is a usage cap.
It should be approached with great caution. Models trained on historical hiring data reproduce the patterns in that data, including ones you would not defend, and employment discrimination law applies to the outcome regardless of what produced it. Any shortlisting decision needs a human who made it and can explain it.
Off by default and fully functional when off; gated in layers with a global switch, per-feature flags, per-company grants and usage caps that all fail closed; draft-only for anything concerning a person; statistical methods used where they suffice; and transparency about which provider is used, with credentials stored encrypted and never displayed in full.
Merik's AI layer is deliberately narrow. Exactly one server-side function talks to a language model, and it does two things: draft a performance summary from an employee's own task log and attendance, and draft a quote from a scope description. Both are drafts a human edits — for performance summaries, the edit distance between the draft and what the manager submits is captured, so it is visible whether drafts are actually being reviewed.
Four gates control it, all failing closed: a master switch, a per-feature flag, a per-company grant, and a monthly call cap. Provider keys — Anthropic, OpenAI, Google, xAI or an OpenAI-compatible endpoint — are stored only as encrypted ciphertext, and the dashboard shows only the last four characters. Everything else in the product works with AI switched off entirely, and the time estimator is deliberately not a language model: it scores tasks by similarity to your own history and backtests its own weights, so its suggestions are explainable. See the feature list, the modules, or how it works.
The questions to ask any HR tool holding your salaries and IDs.
Reviews grounded in the work already logged, not in memory.
What each category does, the integration tax of buying three, and a guide by team size.