HR technology

AI agents on HR data, where the data is the whole problem

The most sensitive non-medical data a company holds, in a multi-tenant product, read by managers about their own reports.

Talk about your system or email instead

What I have shipped here

2,000

concurrent users on multi-tenant HR analytics

I built a multi-tenant HR analytics platform and conversational assistant on AWS Bedrock and LangChain: text-to-SQL over workforce data with strict per-tenant isolation, predictive models for attrition and time-to-fill at roughly 75% accuracy, and reporting turnaround cut from two to three days to under 30 seconds.

Read the full case study

Who I work with here

HR tech and HCM platforms adding conversational analytics or copilots
People-analytics teams inside large employers
Founders selling HR AI into enterprises and hitting security review

Systems I see in this domain

Conversational analytics over workforce data
Attrition and time-to-fill forecasting
Policy and handbook assistants
Manager copilots for reviews and one-to-ones
Interview and screening automation

What makes agents hard in hr technology

HR data is the most sensitive category most companies hold outside actual medical records. Compensation, performance ratings, attrition risk scores, disciplinary history, leave reasons. A leak is not an embarrassment, it is a lawsuit and a works-council incident.

It is also unusually adversarial by structure. The data subjects are the employees, the users are often their managers, and the buyer is HR. A manager asking a reasonable-sounding question can be asking for something they are not entitled to see — and the agent has no idea, because org-chart entitlement is not visible in the text of the question.

Then multi-tenancy compounds it. Most HR AI ships inside a SaaS platform, so a retrieval bug is not one customer seeing the wrong row, it is one company seeing another company's salary data. That is the failure that ends the product.

The practical consequence: in HR tech, more of the engineering budget goes to the boundary than to the model. That ratio surprises teams who arrived expecting the hard part to be prompt quality.

Which HR data classes can enter a prompt

The question teams should ask before the first prototype and usually ask after the first security review. My default classification — tighten it for your jurisdiction, never loosen it without a written reason.

Data class	In a prompt?	How to handle it
Job title, department, tenure, location	Yes	Low sensitivity and usually necessary context. Still scope it to the requester's entitlement.
Aggregated metrics (headcount, average tenure)	Yes	Enforce a minimum group size — typically 5 — so aggregates cannot re-identify an individual.
Individual compensation	Only with entitlement checked in code	Never rely on the prompt to decide who may see pay. Resolve entitlement server-side from the org graph, before retrieval.
Performance ratings and review text	Rarely, and never in free text	Free-text reviews re-identify people even when names are stripped — writing style and incident detail are enough. Prefer structured ratings with entitlement checks.
Attrition or flight-risk scores	Generally no	A prediction about a named employee reaching the wrong manager causes real harm. Keep these aggregate, or gate behind an explicit policy decision with logging.
Health, leave reason, accommodations	No	Special category data under GDPR Article 9. Exclude from retrieval indexes entirely rather than filtering at query time.
Protected characteristics	No — and not as model features	Also exclude proxies: postcode, school, photo, name-derived inference. Absence from the prompt is not enough if a proxy is present.
Disciplinary and grievance records	No	Separate system, separate access path, no agent access. There is no version of this that is worth the risk.

The recurring mistake is filtering sensitive classes at query time while indexing everything. If a class must never be returned, it must never be embedded — a filter is one forgotten call site away from a leak.

What HR security reviews actually ask

If you sell HR AI into enterprises, these are the questions that decide the deal. Having a real answer to each is worth more than any feature on your roadmap.

The question	What an acceptable answer looks like
How do you guarantee tenant isolation?	Session-derived tenant identity, server-side filtering, query rewriting, per-tenant credentials — plus adversarial tests that fail. Not "the prompt instructs the model."
Is our data used to train models?	A clear no, with the provider's data-processing terms and zero-retention configuration documented. Know your provider's default, because some retain by default.
Where is data processed?	Named regions. Several providers charge a premium for pinned regional inference — budget for it rather than discovering it at contract stage.
Can an employee's data be deleted on request?	Deletion has to reach embeddings, caches, conversation history and traces — not just the primary database. Most teams have not thought about the vector index.
Who can see what, and how is it enforced?	Entitlement resolved from the org graph before retrieval, with the decision logged per request.
Show us an audit trail for a decision.	A trace with prompt version, model version, retrieved records, entitlement decision and output — reconstructable months later.
Is this a high-risk system under the EU AI Act?	Worker management sits in Annex III. Know whether you are provider or deployer, and have the logging and human-oversight story ready.

Every one of these is an engineering question wearing a compliance costume. Answer them in the architecture and the security review becomes a formality.

What the rules imply for how you build

Not a compliance summary — the engineering consequence of each obligation.

EU AI Act — Annex III, point 4 (employment and worker management)

High-risk obligations apply from 2 August 2026

AI used for recruitment, evaluation, promotion, termination, task allocation or worker monitoring is classified high-risk. Providers carry design, documentation and bias-testing duties; deployers owe human oversight, input-data quality, logging and worker information.

What it means for the build: Logging and human oversight stop being optional features. You need per-decision traces you can produce on request, a documented human review path for adverse decisions, and evidence of data quality. A system with no tracing cannot demonstrate compliance even if it behaves perfectly.

GDPR Article 22 — automated decision-making

In force

Decisions made solely by automated means with legal or significant effects require specific safeguards, including meaningful human involvement and the ability to contest.

What it means for the build: "A human clicked approve" is not meaningful involvement if the human saw only a score. Surface the reasoning and the underlying records, and log what the reviewer actually saw.

Works council consultation (Germany, Netherlands, France and others)

In force, varies by country

Introducing systems that monitor or evaluate employees typically requires consultation, and can be blocked.

What it means for the build: Build the explanation you will need for that conversation while building the system, not afterwards. Feature flags per country are usually cheaper than a rollback.

Regulatory notes on these pages are engineering guidance, not legal advice. They describe what the rules imply for how you build and log a system. Get a qualified opinion for your jurisdiction and use case before relying on any of it.

The failure modes that dominate here

Every agent can fail in all nine ways. These are the three that cause the most damage in this domain specifically.

high · very common

The answer is wrong because retrieval returned the wrong context

The model is behaving correctly given what it was handed — and what it was handed was wrong.

critical · very common

The agent calls the right tool with invented arguments

The model picks a correct tool but fabricates its inputs — a plausible-looking customer ID, an out-of-range date, an enum value that was never defined.

high · very common

It works on our test prompts and fails on real users

The team's test inputs are clean, well-formed, and written by people who know how the system works.

How I would approach it

The engagements that apply most often in this domain. Each has the full method and effort estimates.

Multi-tenant AI isolation

A prompt is not an access-control mechanism.

Isolation that holds even when the model behaves unexpectedly.

The method

Text-to-SQL reliability

The hard part is not generating SQL. It is knowing when not to run it.

Answers users trust, because every number traces back to a query they can inspect.

The method

Agent eval suites

Stop shipping prompt changes as unmeasured bets.

A suite your team owns that fails the build when agent quality drops.

The method

Questions from this domain

Can we put employee data into an LLM prompt at all?

Yes, for the lower-sensitivity classes, with entitlement resolved in code before retrieval rather than described in the prompt. Job title, department, tenure and properly-aggregated metrics are routine.

What should not go in: health and leave data, protected characteristics and their proxies, disciplinary records, and individual attrition predictions. The table above is my default classification.

Is our HR AI high-risk under the EU AI Act?

If it is used for recruitment, evaluation, promotion, termination, task allocation or worker monitoring, it falls under Annex III point 4 and high-risk obligations apply from 2 August 2026. Penalties under Article 99 reach €15 million or 3% of global turnover.

Note one nuance: the European Commission's Digital Omnibus package proposed in November 2025 may push this timeline back, but it is a proposal rather than enacted law — planning on the delay is a bet. This is engineering guidance, not legal advice.

How do we handle a deletion request for data in a vector index?

Plan for it before launch, because retrofitting is painful. Deletion has to reach the primary store, the embedding index, prompt caches, conversation history, eval datasets and traces.

The practical approach is per-employee identifiers on every derived record so deletion is a query rather than a search, plus periodic index rebuilds as a backstop. Teams that skip this discover it during an enterprise security review.

Why is multi-tenancy harder for HR AI than for a normal SaaS app?

Because a language model sits between the request and the data, and it can be talked into things a SQL query cannot. Retrieval filters and tenant predicates are the correct defence, but they now have to hold against ambiguous natural-language input rather than a typed API call.

I shipped a multi-tenant HR analytics agent for 2,000 concurrent users, and the query gate that enforced isolation outside the model was two weeks of work and the reason the project shipped at all.

Building this in hr technology?

Tell me what your system does and what worries you. I have shipped in this domain, so I can usually name the specific constraint you are about to hit — and that answer is free.

Message me Book a 20-minute call or email instead

Other domains