Where we are in the leader track
a1 mapped what AI actually changes about the people function. a2 laid out the legal map. a3 built the governance around vendors, audits, notice and records. a4 got specific about fairness - proxies, the four-fifths ratio, and what "explainable" means to a candidate who was rejected. All four were about the hiring decision: a person who does not yet work here, being assessed. Tonight is the mirror image. It is about everything HR holds on the people who already work here, and about the quiet moment when someone says "we have all this data, why not point AI at it". The answer is not "no". It is "not like that, and here is the version that survives contact with your own staff". a6 then turns all of it into a pilot you can actually run.
The data boundary, sorted by how badly it goes wrong 7 min live
HR sits on the richest personal-data estate in the company, and unlike marketing's, none of it was volunteered for analysis. People handed it over because they wanted a job, needed an adjustment, or were required to. So the useful sort order is not "what is interesting" - it is what happens to a real person when this leaks, or gets used for something they never agreed to. Five tiers, worst-case ascending.
LiveThe five tiers, and why the order matters3 min▶
Most organisations run a two-tier model in their heads: "confidential" and "very confidential". That is not enough resolution to make a decision with, because it does not tell you what changes when the data moves into a new tool. Five tiers does.
- Tier 1 - ordinary employment records. Titles, teams, reporting lines, start dates, completed training. Still personal data, still needs a basis and a retention limit, but the failure mode is embarrassment rather than harm. This is the tier that makes AI genuinely useful for org design questions.
- Tier 2 - pay. Aggregate is a management tool. Named is a career and a relationship. A pay band chart may enter a workspace; a spreadsheet with 400 names and 400 numbers may not, and the fact that it is the easiest export in your HRIS is not an argument.
- Tier 3 - performance, grievance, disciplinary. Written by humans, about humans, often in the middle of a conflict, and frequently contested. Anything drafted from this material inherits its contestedness. If the underlying rating was unfair, an AI summary of it is unfair and now also fluent.
- Tier 4 - health and accommodations. Special category under GDPR and treated with heightened care under the PDPA regime too. Nothing here belongs in a prompt, and there is no clever de-identification that makes "adjusted hours for a chronic condition" safe when the team has nine people in it.
- Tier 5 - monitoring output and anything collected about protected characteristics. Both were collected for a stated, narrow purpose. Reusing them is a new purpose, and a new purpose needs its own basis, its own assessment, and usually its own conversation with people. This is Part 2.
The helpful export. An HR analyst was asked for a view on why one department kept losing people. The fastest route was the full employee extract - every field the HRIS offered, because filtering columns takes longer than not filtering them. That single file carried named pay, two open grievances and four accommodation flags into a tool nobody had cleared for tier 3. Nothing leaked, nobody was harmed, and the review still took six weeks. The failure was not malice or even carelessness. It was that "export everything" is one click and "export what I need" is twenty.
LiveWhat lawful basis actually asks you2 min▶
GDPR and the Singapore PDPA both govern candidate and employee data through the same practical spine: you need a lawful basis for processing, you may only use the data for the purpose you collected it for, you take the minimum you need, you keep it for a limited time, and there are constraints on decisions taken about a person without meaningful human involvement. Four of those five are silently broken the moment somebody pastes an HRIS export into a chat window.
- Consent is the weakest basis in an employment relationship, because the power imbalance makes "freely given" hard to argue. Leaders reach for it because it feels safe; it usually is not the right instrument here, and your DPO will tell you which one is.
- Purpose limitation is the one AI projects trip over, every time. The data exists. It is right there. But "we already have it" answers a storage question, not a use question.
- Minimisation is a design constraint, not a virtue. Ask what the smallest field set is that could answer the question, then build to that. It is also the cheapest risk reduction available to you.
- Retention limits bite hardest on the material nobody owns - old interview notes, shared drives of engagement free text, the folder from the reorganisation two years ago. This is where an AI project usually discovers what you actually still hold.
Self-studyThe de-identification habit, and when it stops working2 min read▶
The HR track teaches this as a reflex in b1: before anything real touches a tool, strip the name, contact details, employer, dates of birth, protected characteristics and any free text about health or family. It works well for tier 1 and tier 2, and it is the reason most useful HR AI work is possible at all.
It stops working at small numbers. In a team of nine, "the person on adjusted hours" is a name. In one office, "the grievance from last March" is a name. Re-identification is not a technical attack in an HR context - it is just colleagues knowing each other. So the honest rule is: de-identification protects tier 1 and tier 2 data at scale, and it does not rescue tier 3, 4 or 5 at any scale.
And the diagnostic from b1 still holds. If stripping the identifiers makes the task impossible, the task needed a person rather than a prompt.
The monitoring line, and the question that actually decides it 7 min live
Productivity scoring. Sentiment analysis on internal messages. Always-on activity tracking. Attrition-risk prediction attached to named individuals. Every one of these arrives with a business case that sounds reasonable in a room of four people and reads very differently in a room of four hundred. Three things are engaged at once, and leaders usually only check the first.
LiveThree things monitoring engages at once3 min▶
Leaders check the first of these, occasionally the second, and are ambushed by the third.
- It can be high-risk under the EU AI Act. Annex III point 4 is wider than hiring. It covers performance evaluation, task allocation, monitoring of workers, promotion and termination. So people analytics and monitoring tooling can land in the same high-risk category as a screening tool - with the risk management, data governance, documentation, record-keeping, transparency and human-oversight obligations that come with it. Annex III obligations were postponed to 2 December 2027 under the Digital Omnibus agreement; that is the position as of mid-2026, it has moved once already, so check before you act on it.
- It can engage consultation duties. In parts of Europe, introducing employee monitoring is not a decision the employer simply takes - works councils and employee representative bodies have a say, and the process matters as much as the outcome. Discovering this after procurement is an expensive way to learn it.
- It always engages trust, and no legal basis answers that. You can be entirely lawful and still have destroyed something. This is the axis with no compliance workaround, and it is the one that should be discussed first because it is the one that is irreversible.
The pilot that was never announced. A people-analytics team ran a six-week trial scoring internal message tone as an "engagement early-warning signal". It was scoped narrowly, the output was aggregate, and legal had signed it. Nobody told staff, on the reasoning that announcing a trial would distort the results - which was true, and which was also the tell. When it surfaced in a town hall question, the discussion was not about the score. It was about six weeks of reading, and about what else people had not been told. The tool was switched off that week; the question "what else are they running" outlasted it by a year.
LiveThe leader question, and how to ask it in the room2 min▶
When a monitoring proposal reaches you, the temptation is to send it to legal and wait. Do that, but do not start there, because a "yes, lawfully possible" tends to end the conversation before the important part of it happens.
| Ask this | What it surfaces |
|---|---|
| What decision changes because of this data? | Most monitoring proposals cannot name one. That is the finding. |
| Would we put this in the employee handbook, in plain words? | If the honest sentence is unwriteable, the practice is unrunnable. |
| What happens the day staff find out - because they will? | Turns an abstract risk into a specific meeting you can picture. |
| Does it attach to a named individual, or to a pattern? | The single most useful design fork in the whole conversation. |
| Who consults whom before this starts? | Works councils, employee reps, the DPO. Order matters and is often statutory. |
| What would make us switch it off? | A project with no stop condition is not a pilot, it is a rollout. |
Self-studyWhy "we anonymised it" is not the end of the argument2 min read▶
Aggregation genuinely reduces risk, and Part 3 is built on it. But two things still travel with monitoring data even after the names come off.
- Small groups re-identify themselves. An "aggregate" view of a seven-person team is a view of seven people, and everyone on that team knows it. Set a minimum group size before you build anything, publish the number, and hold it even when a director asks nicely.
- The collection is the intrusion, not just the output. Staff do not object to a chart. They object to being read. An aggregate dashboard built on always-on capture is still built on always-on capture, and the honest employee-facing sentence has to describe the capture.
Which is why the strongest position is usually the boring one: collect less, keep it shorter, aggregate higher, and spend the credibility you save on the projects that actually change something.
Attrition analytics you would defend in the open 5 min live
Kestrel is losing engineers faster than it is replacing them, in the middle of a 120-role hiring wave. That is a real problem and it deserves real analysis. The failure mode is not analysing it - it is analysing it in the shape of a watchlist. There is a version of this that is genuinely useful and entirely defensible, and the difference is three design choices made at the start.
LiveAggregate not named, drivers not scores, system not person3 min▶
- Aggregate, not named. The unit of analysis is a team, a level, a tenure band, a manager span - never an individual with a risk percentage next to their name. A named score is a decision-support tool about one person's future, which is exactly the territory Annex III point 4 describes and exactly the thing that turns a manager into a surveillance operator. Set your minimum group size before you look at anything.
- Drivers, not scores. The output you want is "engineers at level 3 with no internal move in 24 months leave at roughly twice the rate of their peers", not "Priya: 71% flight risk". The first sentence tells you to build an internal mobility path. The second tells a manager to behave strangely towards Priya.
- Used to change the system, not to watch a person. Write down, in advance, what you will do with the finding. If the answer is "have a conversation with the at-risk individuals", stop - you have designed a watchlist with an analytics wrapper. If the answer is "fix the level 3 progression gap", you have designed people analytics.
The retention bonus that taught the wrong lesson. One company built named flight-risk scores and used them to target retention offers. It worked, briefly. Then people noticed the pattern - the offers went to the ones who had been visibly unhappy - and the lesson the whole engineering group learned was that the route to a raise ran through looking like you were leaving. Attrition went up. The model was accurate; the intervention taught a behaviour, and the behaviour was the actual output.
LiveWhat Kestrel should actually build2 min▶
Tier 1 and de-identified tier 2 data, no monitoring feed, minimum group size of eight, and a written purpose that names the change you intend to make.
| Question | Cut it by | Then what |
|---|---|---|
| Who is leaving? | Level, tenure band, team size | Names the population, not the people |
| When do they go? | Months since last internal move or level change | Usually the sharpest signal Kestrel has |
| What do exits say? | Themes across a quarter, minimum eight responses | Themes are safe; verbatims are identifiable |
| Where is pay drifting? | Band position by cohort, never named | A comp fix is a system fix |
| Which managers? | Span, tenure, promotion rate - not sentiment | Coach the role, and be careful here |
The manager row is the one to argue about in the room. It is legitimate, it is where a lot of attrition actually lives, and it is also one small step from a named performance judgment built out of other people's data. Set the group-size floor and the "no individual output" rule before you run it, not after somebody sees an interesting name.
Tier your own data estate, then mark the tool contact ★ 12 min · everyone builds
Do this for your own organisation, not for Kestrel. It takes twelve minutes and it is the only artifact from tonight that your DPO will ask you for. The output is not the tier list - it is the marked list underneath it.
List the data stores HR actually owns or touches. Not the ones on the architecture diagram - the ones people use. Include the shared drives, the exports, the trackers, the survey platform and the two spreadsheets everyone pretends are temporary.
Put each one in a tier: 1 ordinary records, 2 pay, 3 performance and grievance, 4 health and accommodations, 5 monitoring output and protected-characteristic data. Anything that spans tiers takes the highest tier it contains, which is the whole reason the full HRIS export is a tier 4 object.
Now the real step. Against each store, write every AI or automation tool that currently touches it - including the ones nobody calls AI: the survey platform's summariser, the ATS ranking feature, the note-taker in your one-to-ones, the browser extension somebody installed.
Highlight every line where a tool touches tier 3 or worse. That list is the output of this session. Do not fix it in the room.
For each highlighted line, name one owner and one date. Not a remediation plan - a name and a date. The plan is a3's territory and the pilot is a6's.
Write the employee-facing paragraph ★ 10 min · build your own
Same discipline as the candidate notice in b1, pointed inward. Four things, in plain words: what AI is used for on employee data here, what it is never used for, that a person decides, and who to ask. Under 150 words. If a sentence is hard to write honestly, you have not found a wording problem - you have found a practice problem.
Write the "what we use it for" sentences first, and make them specific enough to be checkable. "To improve HR processes" is not a sentence, it is a shrug.
Write the "what we never use it for" sentences. These are the ones people actually read, and they are the ones that buy you credibility for the first set.
Write the human sentence: which decisions are made by a named person, and that a model does not decide pay, rating, promotion or exit.
Write the route: who to ask, how to object, how to request a human review. A named team or role, not a mailbox nobody answers.
Now audit it line by line against what actually happens today. Every sentence you cannot honestly write is this session's finding, and it goes on the list from Demo 1.
The sentence that could not be written. A people team drafting this paragraph got stuck on "we do not read your messages". They did not, deliberately - but the collaboration suite had shipped an analytics feature eighteen months earlier and it had been on by default the whole time. Nobody had chosen it, nobody was using the output, and the honest paragraph was still unwriteable until it was switched off. That is the entire value of this exercise: it audits reality rather than intent, and it does it for the price of one hard afternoon.
Try it yourself - this week ◐ 45-60 min total
- Finish the tier map for your real estate, including the informal stores. Send it to your DPO with one question: "is anything on here being used for a purpose it was not collected for?"
- Take the tier 3-or-worse contact list from Demo 1 and get a name and a date against every line. That is your whole obligation this week.
- Find out what monitoring capability you already own and have not switched on - in the collaboration suite, the endpoint tooling, the survey platform. Most organisations own more than they have decided to use, and the decision was never actually taken.
- Ask whether any employee monitoring in your organisation triggers a consultation duty, and with whom. If nobody knows, that is the finding.
- Write your employee-facing paragraph and read it out loud to one person outside HR. Watch their face on the "we do not" sentences.
- Before a6: pick the one team and the one artifact you would pilot with. You will need both next session.
Official sources covered
Taught from public regulation and vendor documentation. Certification content and any actual legal position stay with their owners. This course is education for HR leaders, not legal advice, obligations vary by jurisdiction, and the dates below have already moved once. Verify the current position before you act on anything here. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Your analytics lead proposes reusing badge and login data - collected for building security - to study attrition. What is the first objection?
Purpose limitation. "We already hold it" answers a storage question, not a use question. Anonymising helps but does not create a purpose, and at team size the anonymity is thinner than it looks.
2 · Legal confirms a productivity-scoring tool would be lawful in your main jurisdiction. What have you learned?
Worker monitoring sits inside Annex III point 4, so high-risk obligations can attach; consultation duties apply in some jurisdictions; and the all-hands question is untouched by any of it. Lawful and defensible are different tests, and the second one is the one that ends projects.
3 · Which attrition-analytics design is the defensible one?
Aggregate, drivers, system. A named score is decision support about one person's future, it hands managers something they cannot use well, and consent buried in an employment contract is the weakest ground you could stand on given the power imbalance.