Candidate data retention: the three clocks that apply

Candidate data retention is not one period but three, and the guide the CNIL, France’s data protection authority, published on 2 April 2026 keeps them clearly apart. The file lives in the active database for as long as the process lasts. The profile can stay in a talent pool for up to two years after the last contact, if the recruiter is genuinely interested in it and the candidate has not objected. And the file of a candidate who was not hired can be kept for five years from the date the position was filled, in an archive, to answer a possible discrimination claim.

An AI agent adds a fourth copy to those three clocks, and it is the one nobody sets. What it has noted about a candidate over the course of conversations is personal data just as much as the ATS record is, with the same deadlines, and it has an awkward property: once reworded, it no longer necessarily carries the name of the person it is about. Searching for that name on the day the person asks to be erased will not find it.

What periods does the CNIL set for a candidate?

The retention guide for human resources, updated on 20 May 2026, gives a page to recruitment and separates what is mandatory from what is recommended. The distinction matters, because the two are not defended the same way in front of an inspector.

Situation	Active database	Intermediate archive	Status
Candidate hired	Until the employment contract is signed	None, the file moves to personnel management	Recommendation
Candidate not hired	For the length of the process, until the outcome	5 years from the date the position was filled	Obligation (L.1134-5)
Talent pool, profiles of genuine interest	Up to 2 years after the last contact	5 years from the date the position was filled	Recommendation

The five years come from article L.1134-5 of the French Labour Code, which gives five years to bring a claim for discrimination. The two-year talent pool period is a CNIL recommendation, and it comes with two conditions that day-to-day practice happily forgets: the recruiter has to be interested in the profile, and the person must not have objected, or must have agreed. A pool that keeps everyone by default fails the first condition, whatever its retention period.

The guide names intermediaries explicitly, recruitment agencies included, and not only employers. An agency therefore has no longer period to fall back on because its talent pool is its commercial asset.

Why does everyone say “two years”?

Because practice has merged three periods into one, and the most quoted one is the most convenient. Our own guide to the impact assessment for a recruitment agent gives two years as the usual reference, which is right for a talent pool and incomplete for everything else.

The shortcut costs in both directions. An agency that deletes everything at two years loses the documents it would need if a rejected candidate challenged the decision three years later. An agency that keeps everything for five years “as evidence” and keeps sourcing from those files is using an archive as a working database, which is exactly what the guide rules out.

There is also a trap in the talent pool’s starting point, which runs from the last contact. A message sent to a former candidate just to restart the clock is not a contact in the sense the text intends; it is a diversion of purpose, and it shows in the history. A contact that renews the period is a contact that had a reason: a role to offer, a question to ask, news to pass on.

What does “intermediate archiving” mean for a recruiter?

Data in intermediate archiving is no longer used for the purpose that justified collecting it: it is kept for an administrative reason, typically possible litigation, and consulted occasionally, for a stated reason, by specifically authorised people. The CNIL requires it to be separated from the active database, either physically in a dedicated store or logically through permissions that make it unreachable for anyone who no longer has a reason to process it.

In an ATS, that means a candidate rejected eighteen months ago for a role filled since then no longer appears in a sourcing search, even though they are still in the database. Few agencies have set it up that way, because a search that brings everything back is more pleasant to use than one that respects statuses.

An agent makes that gap far more visible. A consultant looking for a profile in the ATS scans twenty or so results; an agent with read access to the whole database scans all of it, archives included, and puts forward an active candidate and a file kept solely for a court defence with the same confidence. The separation the guide requires then becomes a question of which permissions the agent was granted, which is the only place where a limit actually holds.

Is what an agent remembers about a candidate personal data?

Yes, without ambiguity, as soon as the person can be identified. “Prefers remote work, turned down an offer at €55,000 in March, their current manager leaves in June” is personal data, and often more sensitive than the record it came from, because it holds what the candidate said out loud and nobody would ever have typed into a field.

It is subject to the same periods as the rest of the file. If the candidate leaves the talent pool at two years, what the agent knows about them has to leave with them; if the file goes to the archive, the agent’s note has no better reason to stay available for everyday work. We have argued elsewhere that a memory that grows without a filter makes an agent less accurate; here the argument comes from outside and is simpler, since a memory that keeps a person past their deadline is unlawful retention, however good the agent is.

Why is a memory harder to erase than a record?

Because an agent’s memory is almost never filed by person. It is reworded, summarised, folded into a note about a client or a type of role, and the sentence about a candidate may no longer contain their name. On the day they exercise their right to erasure, a search for their name in the memory does not bring everything back, and what is left is precisely what is no longer attributed.

The second difficulty is the order of deletions. Erase what the agent remembered while the messages it learned it from are still there, and the next run reads those messages and writes the same fact again, this time with no trace of where it came from. Honest erasure removes the raw material first and the derived material second, and when the derived material can no longer be attributed, it removes it as a block and lets the agent learn again from what remains.

The deadline leaves no room to improvise. The answer is due within a month of the request, extendable by two months for a complex request provided the person is told within the first month. An organisation that discovers at that moment it does not know where its agent keeps what it learns does not have an agent problem; it has an incomplete record of processing.

Where should what the agent knows about a candidate be kept?

In the ATS, and nowhere else. It is the rule we apply to every business fact, one fact, one owning system, every other copy read-only, and here it gains a second justification: the ATS is the only place where the retention clocks already run, with the statuses, the last-contact dates and the purges the agency has configured.

In practice, the agent reads the record when it needs it instead of remembering it, and what it learns in conversation goes back into the ATS, as a field or a note, under the responsibility of the person who learned it. Its own memory keeps what concerns the company: how this client wants to receive profiles, the criteria a partner applies, the profile template that was approved. None of that names a candidate, and none of it has a GDPR deadline.

The concession is real and worth stating. An agent that rereads the ATS every time is slower and costs more than one that remembers, and some of the nuance of a conversation has no field to go in. We prefer that cost to the other one, which is discovered during an inspection or on the day a candidate asks what you know about them, and the quality of the database improves along the way, which ties in with what to look at in your data before plugging in an agent.

What should the candidate be told?

What the GDPR requires anyway, with one addition. The candidate has to be told who the controller is, the purpose, the retention period and their rights, erasure among them; for a talent pool, the CNIL points out that they must have been told how long and be able to object. If an agent takes part in the processing, the notice should say so, along with what it actually does: read a file, draft a message, prepare a shortlist.

The addition concerns the contact itself. A follow-up drafted by an agent is still an outbound message, approved by a person before it leaves, like everything an agent writes to a candidate. That is also what protects against the clock trap: a follow-up that has to be read and owned by a named recruiter is rarely written just to extend a retention period.

What we chose at Balt

Our privacy policy states that nothing is deleted because of its age, and that is deliberate: pruning by age would give a moving limit, and the agent could no longer say how far back it can see. The consequence is that Balt does not apply your two years for you. What is erased is erased on request, by person for what they said, as a block for what Balt derived from it, and always in the order raw then derived, which the same policy makes mandatory.

That is why we advise our customers to leave facts about candidates in their ATS, where their clocks already run. The remaining question is who in the agency wrote those clocks down and has checked them since the 2026 guide: it is the first document an impact assessment of the agent will ask for, and it is prepared before the agent is plugged in rather than after.