An illustrative scenario. An admin team automates invoice intake: the agent reads, classifies and reconciles. The pilot starts, the dashboard says it works. Marta, who has done this task for eight years, hasn’t complained about anything. And yet exceptions arrive late, badly explained, or not at all. Nobody sabotaged the project out of malice. Nobody simply told Marta what she’ll be doing next Monday.
The thesis in one line: deciding what the person whose tasks the agent absorbs does tomorrow is part of the project scope, not an HR appendix. Without that decision the pilot doesn’t fail because of the technology. It fails because the person who knows the process best has rational reasons not to help.
Redeploying employees when you automate with AI: why it belongs in the scope
An AI project is defined by a process, some systems, some data and a metric. The person who does the work today shows up as a “user” or a “stakeholder”, and their future, if it shows up at all, gets one change-management slide at the end of the document.
That’s a design mistake, not a sensitivity issue. This person knows the exceptions that are written down nowhere, validates what the agent produces, and decides every day, through what they do, whether the system lives. They are a component of the system. Treat them as a side effect and the system behaves like a component nobody specified.
What is quiet sabotage and why does it appear?
Quiet sabotage is to stop helping without ever opposing: no conflict, no complaint, just friction. It appears out of plain rationality. If your job is what’s about to disappear and nobody tells you what comes next, the prudent move is not to make yourself redundant. It isn’t malice; it’s what anyone would do.
You spot it by concrete symptoms:
- Exceptions don’t get documented. “Everyone knows that,” says the person who knows it, and the agent trips over it again and again.
- The agent is reviewed with a magnifying glass nobody ever used on human work. Every failure is shown in the meeting; every success goes unremarked.
- The work keeps being done by hand “just in case”. The agent runs and the person repeats the same thing in parallel, so the saving never materialises.
- Nobody corrects the agent. If correcting it means training your replacement, the sensible thing is to let it get things wrong.
It’s one of the most repeated reasons a pilot works in the demo and never reaches production; the full pattern is in the guide on why AI automation projects fail. Here we keep the mechanism: resistance isn’t an attitude problem, it’s the logical answer to an unanswered question.
What has to be decided before you start?
Four decisions, in writing, before you approve the pilot:
- Which tasks disappear and which stay. Look at tasks, not jobs: a job is rarely a single task. That inventory is half the work of choosing which processes to automate with AI, and it usually shows that what gets absorbed is part of the job, not the whole job.
- Where each person goes. By name and by date. The real destinations are few: supervising the agent (exceptions, quality, doubtful cases), moving to work that wasn’t done before for lack of time, or moving to another role in the company. “We’ll see” is not a destination.
- What they need to learn and who pays for it. During working hours, on the real work, with someone who answers questions. Not a generic course: that’s what the training line item nobody budgets for is about.
- What happens to the saving. If what gets freed is hours, do they become capacity, fewer hires, or fewer people? Saying it clearly stops the team from working it out on their own, and they almost always work out the worst. The gap between freed hours and real savings is in freed hours are not savings.
Supervising the agent is not a consolation prize. An agent in production needs someone to decide on exceptions, and that’s a real function, described in the guide on the human in the loop of an AI automation. The person who knows the process best is often the best fit, as long as the role really exists and isn’t just a label.
And if there’s no place for that person?
Sometimes there isn’t, and promising otherwise is worse than saying nothing. Redeploying doesn’t mean guaranteeing nobody loses their job; it means the decision is made explicitly, before the pilot and not after, and that the person hears it from you and not in the corridor.
In Spain, it’s also not only a matter of manners. The Workers’ Statute regulates substantial changes to working conditions (art. 41) and, for dismissal over failure to adapt to reasonable technical changes in the role, requires offering an adaptation course first (art. 52 b). This is not legal advice and every case differs: before you talk to the team, talk to whoever handles your employment law. Other countries have other rules; this paragraph applies to Spain only.
When is this overkill?
If what the agent absorbs is a small fraction of many people’s work, say a bit of copy-paste each week, nobody’s job is disappearing and it’s enough to say so clearly. And if the stated goal of the project is to reduce headcount, say that: calling it “redeployment” and not delivering is worse than the hard conversation. Redeployment is a commitment, not a euphemism.
The line to take away: before approving the pilot, write one sentence per affected person. “The Monday after go-live, X will do Y.” If you can’t write it, the scope isn’t closed, and the pilot has an expiry date even if the technology works.
Source consulted on October 19, 2026: Spain’s Workers’ Statute, consolidated text (BOE-A-2015-11430). On adoption as the lever of ROI, see adoption, not the model, decides your AI ROI.