The Sick-Leave Bot and Article 9 GDPR: A Case Analysis

I recently heard a use case on an AI podcast that was sold as a cool vision of the future. An AI agent listens in on Slack and email, spots a sick note, automatically sends a get-well message, reshuffles the shift plan and informs the team. Sounds efficient. The catch was in the detail: the group email to the team named the person and the duration. Roughly: colleague X is now in their third week off sick. Let me say plainly what this is. This is not a clever bit of automation, this is a data protection incident waiting to happen. That is my analysis as an auditor, not legal advice. But the analysis is unambiguous.

Illness data is not an edge case, it is the highest level of protection

Anyone who is off sick is disclosing information about their health. And health data is a special category of personal data under Article 9 GDPR. This category is not subject to ordinary handling but to a general prohibition on processing. You may only process it if one of the narrowly defined exceptions applies, such as explicit consent or a provision under employment and social security law.

This is the decisive shift that got lost in the podcast. The agent is not handling a harmless absence note. It is handling the most sensitive category of data the GDPR recognises, on a par with data about religious beliefs or a person's sex life. And it does so in a largely automated way, listening in, without anyone having decided beforehand whether and how this is permissible at all.

An agent that reads sick notes and redistributes them by name opens a barn door. Not out of bad intent, but because nobody recognised the most sensitive category of data for what it is.

Where there is no legal basis, good intentions do not help

An employer may certainly know that someone is unfit for work. It needs that information to organise the workplace. That is not the problem. The problem is the path the agent takes with it.

Each of these steps would require a sound legal basis, and one that withstands the strict exceptions of Article 9. In the case described, none was evident. There was an agent doing something practical, and nobody who had asked the question: on what basis, exactly?

• Automatically monitoring Slack and email for sick notes is already a processing of health data.
• The automatic get-well email to the affected person treats the illness as a fact and documents it.
• Reshuffling the shift plan links the health information with further personnel data.
• The group email to the team discloses the sensitive information to colleagues who do not need it at all.

On top of that: if the chain really runs fully automatically and sets personal outcomes along the way, the principle in Article 22 GDPR must also be kept in view, which protects people from purely automated decisions with significant effects. You do not need to stretch the case to see it: here software decides on personnel matters, and nobody is looking any more.

The team needs the cover, not the diagnosis

The core of the mistake sits in a single sentence from the group email. Colleague X is in their third week off sick. How much of that does the team really need in order to function? The answer is soberingly short: almost none of it.

Article 5 GDPR requires data minimisation. Personal data must be limited to what is necessary for the purpose. The purpose here is: the work has to keep running. For that, it is enough to know that a task needs covering and who is taking it on. The name of the person who is off sick, plus the illness duration, are simply not necessary for this purpose. They are the needless extra that turns an organisational note into a disclosure of sensitive data.

• Necessary: this task needs cover until further notice, person Y is stepping in.
• Not necessary: the name of the person who is off sick in a group email to everyone.
• Least of all necessary: the illness duration, the third week, the hint about severity.
• Rule of thumb: the more sensitive the information, the narrower the circle allowed to see it at all.

Making the illness duration public is especially delicate. It allows conclusions to be drawn about the severity of the illness. Three weeks quickly turns, in colleagues' minds, into speculation about the diagnosis. That is exactly what Article 9 is meant to protect against.

Why agents in particular produce this mistake so often

I build AI agents for operational use myself. So I am not saying this from the outside, but from the workshop. An agent is good at spotting patterns and triggering chains of actions. That is exactly what makes it dangerous here. It recognises the pattern of a sick note and fires off the whole chain, email, shift plan, group email, without asking the one question a thoughtful person would ask: am I allowed to do this, and who really needs to know?

The agent does not minimise on its own. It maximises. It would rather share too much than too little, because in its logic that seems helpful. And it does so in seconds and to everyone at once. A person passing on a sick note might hesitate, phrase things vaguely, leave out the name. The agent does not hesitate. It scales the mistake.

Automation makes good processes faster and bad processes more dangerous. A data protection mistake made by hand affects one person. The same mistake in an agent affects everyone, every time, instantly.

That is the point I find missing in these podcast demos. The enthusiasm for what is technically possible obscures the question of what is legally and humanly responsible. Cool is not what works. Cool is what works and exposes no one.

How I would build the same use case

The mistake is not in the idea of letting an agent help with absences. The mistake is in the implementation without data protection built in. You can have the same benefit and still stay clean. A few guardrails that turn the barn door into a sound process:

• Clarify the legal basis first, not last. Before the agent touches a single line of health data, the basis under Article 9 has to be in place, documented and agreed with the data protection officer.
• Separate what belongs together and what does not. The fact of the absence and the health information are two different things. The team only gets the absence and the cover, without names and without duration, if the circle does not require them.
• Draw the circle tightly. Whoever really needs to know that a specific person is out for longer, such as the direct line manager, gets that information deliberately, not the whole department by group email.
• Keep a human in the loop. No agent sets sensitive outcomes on its own. A human signs off before anything goes out that concerns a specific person.
• Log what the agent does. Whoever can prove, if in doubt, which data went where and on what basis is on the safe side. Whoever cannot has already lost.

That costs a bit of thinking before building. But it is the difference between a tool that serves the organisation and one that lands it in front of the supervisory authority at the next complaint. And honestly: the clean path is not even slower. It just has to be thought through properly once.

The analysis in one sentence

An agent that reads sick notes and distributes names along with illness duration by group email processes the most sensitive category of data under the GDPR in a largely automated way, with no clear legal basis, no data minimisation and needless disclosure to colleagues. That is not an efficiency gain, that is an incident waiting to happen. Remember the one sentence that resolves the whole topic: the team needs the cover, not the diagnosis. That is my analysis as an auditor, not legal advice. But it is clear, and deliberately so.