Who approves what when an AI writes to your candidates

No, you should not approve every message. An agent whose every action goes through you is not a colleague, it is a draft with extra steps: the time you save by not writing, you lose again re-reading.

But the reverse: letting it write freely to your candidates and clients, is not an option either. You need a line, and it has to hold without being renegotiated case by case.

The line that holds: does it leave?

The temptation is to sort by importance. It does not work: importance is arguable, and a rule that can be argued is a rule that gets bypassed on a Friday at 7pm.

The criterion that holds is mechanical, and it fits in two sentences. An action that leaves the company waits for approval, and an action that stays inside does not.

Updating a candidate record, transcribing an interview, preparing a skills file, ranking a shortlist, flagging a roll-off: none of that reaches anybody outside. A mistake gets fixed before it is seen, which is exactly why those are the tasks you delegate first.

Emailing a candidate, replying to a client, posting an advert, offering a slot: that is gone, and it carries your name.

This line has an advantage “important / not important” does not: nobody has to think to know which side an action falls on. A criterion applied without thinking is a criterion that gets applied.

Decisions are a third case

One category neither leaves the company nor should happen without a person: the decisions that close a door.

Rejecting an application, choosing between two consultants for a mission, deciding not to put someone forward. These go nowhere, but they have an effect on a real person who will never know they happened.

This is not merely good practice. GDPR governs fully automated decisions producing a legal or similarly significant effect, and an application rejected without human involvement qualifies. The AI Act, separately, classes recruitment among the high-risk uses in its Annex III. That part only applies on 2 December 2027: Regulation (EU) 2026/1744, in force since 27 July 2026, moved it back from 2 August 2026.

The transparency obligation, on the other hand, has applied since 2 August 2026: it was not deferred. It is the one requiring that a person be told they are interacting with an AI system, and it is exactly the subject of the next section.

In practice the constraint is lighter than it sounds. An agent that ranks five hundred CVs by relevance and shows you the top twenty takes no decision: it prepares yours. The difference is not cosmetic: it rests on the other 480 remaining consultable, and on your being able to say why you did not look at them.

Telling the candidate they are talking to a machine

Yes, and as early as possible.

The regulatory argument exists: the AI Act requires transparency about interacting with an AI system, but the practical one is stronger. A candidate who discovers after three exchanges that they were writing to an agent feels deceived, whatever the quality of what was written. And in a market where good people talk to each other, they say so.

Saying it up front costs nothing. A signature that states what it is will do: nobody has ever blamed a firm for using an assistant, they blame it for not mentioning one.

Keeping the record of who approved what

Log what the agent did, what was approved, by whom, and when.

The obvious use is compliance. The everyday one is less obvious and comes up more often: when a candidate writes six months later saying they were promised an answer, you want to check rather than take somebody’s word.

And when something has gone wrong: a clumsy message, a duplicate follow-up, you want to be able to say what happened. Without a log the incident ends in “the AI did something odd”, which teaches nobody anything and costs the whole team its confidence over a mistake that may well have been yours.

An agent without a log is not only a regulatory risk, it is a colleague whose work nobody can review.

Who approves, in a team of ten

The rule says what needs approval. It does not say by whom, and that is what stalls in practice.

The reflex is to send it up to the manager. That is a mistake: the manager becomes the bottleneck, starts approving without reading within a week, and the approval loses all its meaning while keeping all its cost.

The principle that holds is simpler. Whoever would have written the message approves it. It is the same logic as choosing the first task to delegate: the right person is the one who can judge the result at a glance. The business manager approves what goes to their client, the recruiter what goes to their candidate.

The manager approves nothing day to day. They read the log once a week, which is a different job: not hunting for errors but for patterns: a kind of message always corrected the same way, a channel that never works, a brief being misread.

How the rule shows up in the tooling

A rule living in a shared document is not a rule, it is an intention. The tool has to carry it, or it lasts three weeks.

Concretely that means three things. The agent must tell an internal action from an outbound one, action by action, not by a global setting. It must show what it is about to send before sending it, where you already work rather than in an admin screen nobody opens. And it must refuse to settle a decision, even when asked to.

That last point is the counter-intuitive one: a good agent says no. Told to “reject the profiles that do not fit”, it should hand back the list and its reasoning rather than closing the door for you. You can see what those prepared-but-not-decided outputs look like in the use cases in detail.

What the approval actually costs

Which leaves the objection: does approving not destroy the gain?

No, because the volume is not where you picture it. Over a normal day, most of what an agent produces stays inside, records, write-ups, files, rankings, alerts. Outbound messages are a minority, and each takes seconds to read when you did not write it.

Compare that to the alternative. A clumsy message to a senior candidate in a market where everyone knows everyone costs more than a year of re-reading. And a message never sent because nobody thought of it costs a placement.

Approval is not a brake bolted onto delegation. It is what makes delegation possible: you only keep delegating what you are allowed to check.

What to do when it goes wrong anyway

It will, and the plan matters more than the prevention.

The first move is to read the log rather than the incident. What was sent, who approved it, and against which brief. Nine times out of ten the answer is not “the model hallucinated” but “the instruction said something we did not mean”, and those two conclusions lead to completely different fixes.

The second is to narrow rather than to stop. A category of message that keeps coming back wrong goes back under approval; everything else stays as it is. Suspending the agent entirely after one incident is the reaction that ends projects, and it is out of proportion to a mistake a new colleague would have been allowed to make once.

The third is to tell the team what happened. An unexplained incident becomes a rumour, and a rumour about an agent writing nonsense to candidates will outlive any correction you make quietly.

What it comes to

Three rules, one line each. What stays inside goes without you, what leaves waits for your approval, and what closes a door is decided by a person.

The rest, which channel, what moment, what wording, which of the twenty overdue follow-ups to handle first, is precisely what you are delegating. And that is where the time you were looking for turns out to be.