Executive Briefing: Why Employees Sabotage AI When the Deal Is Broken

If employees are asked to feed their knowledge into systems while management talks about leaner teams, this is not an adoption problem. It is a prisoner's dilemma.

The striking number is 29 percent.

A WRITER and Workplace Intelligence survey referenced by State of Brand, covering 2,400 employees, found that 29 percent of respondents say they are actively sabotaging their company's AI strategy. Among Gen Z workers, the figure is 44 percent.

Sabotage here does not mean quiet resignation or silent eye-rolling. It means using unauthorized tools, putting company data into public AI systems, deliberately producing low-quality output, refusing mandated tools, and bypassing internal rules.

That is serious. But the real point is not the number.

The real point is the incentive structure.

When companies ask employees to make their knowledge, routines, decisions, and exceptions machine-readable while also talking about efficiency, leaner teams, and a new AI elite, a very simple game emerges: those who cooperate may help weaken their own bargaining position. Those who block protect their role in the short term.

That is bad for the AI strategy. But it is not irrational.

This is not a training problem

Many companies still read AI resistance as an enablement problem.

The answer then becomes: better training, better communication, more prompt education, more champions, more demos, more use cases.

That can help when the problem is lack of knowledge.

But lack of knowledge is not the core issue here. Employees understand the stakes quite well. They see that AI systems do not just generate text. They learn workflows. They see process knowledge, quality judgement, exceptions, and decision routines moving into tools. And at the same time, they hear that non-adoption will hurt careers while adoption is supposed to make the organisation more efficient.

The official message often says: we want to empower you.

The perceived message says: teach the machine what you know, and trust us not to use it against you later.

That is not a very attractive deal.

Knowledge extraction needs a contract

AI transformation is not just tool adoption. It is knowledge extraction.

A useful agent does not only need data access. It needs context. It needs examples. It needs feedback. It needs corrections from people who know when something is formally right but practically wrong. It needs exactly the knowledge that many organisations have built over years in heads, routines, and informal paths.

That knowledge is not neutral.

For the company, it is productivity potential. For employees, it is often part of their role, status, and job security. Whoever hands over that knowledge is not merely providing input. They are handing over part of their bargaining position.

That is why it is not enough to demand usage. Companies have to clarify what may happen to the knowledge being transferred.

Can it be used to assess individual performance? Can it feed into restructuring decisions? Can it justify shrinking roles? Who sees the data? Who can inspect models, prompts, logs, and evaluation data? What happens when a pilot actually becomes more productive?

Without answers, adoption is an act of trust. And many organisations have already overdrawn that account.

The DACH angle: co-determination as architecture

For German companies, this creates an uncomfortable advantage.

Co-determination slows AI transformation down. It forces documentation, purpose limitation, participation, and negotiation. That is annoying, especially when the speed of American AI narratives is ringing in your ears.

But precisely that slowness can be useful.

The problem is not that employees are insufficiently excited. The problem is that the deal is often not credible. In Germany, that deal can be negotiated institutionally: through works agreements, data protection, qualification, role definitions, control rights, and clear boundaries between assistance, performance monitoring, and replacement logic.

This is not a romantic defence of works councils. Bad co-determination can also block transformation or turn it into formal theatre.

But good co-determination asks the right question: which work really changes, which knowledge is being transferred, who controls its use, and what commitments apply to the people whose knowledge makes the system better?

Those are not side questions. They are the architecture of adoption.

Guarantees have to cost something

A social contract that costs nothing is not a contract.

If management says AI is only meant to relieve pressure, it has to say how employees can verify that. If it says process knowledge will not be used against individuals, it needs technical and organisational boundaries. If it says roles will be redesigned rather than cut, it needs training, time frames, and criteria that can be checked.

Possible commitments could include:

• no individual performance monitoring through AI usage data without a separate agreement
• clear purpose limitation for process knowledge, prompts, logs, and feedback data
• qualification before sanctions when new AI requirements are introduced
• role redesign before job cuts in defined pilot areas
• shared control rights for the business function, data protection, and works council
• documented boundaries between assistance, decision support, and automation

That costs management flexibility. Of course it does.

But without that price, the deal remains psychologically implausible. Employees are then asked to cooperate while they cannot control the expected benefit and carry the personal risk.

That is not how you build adoption. That is how you build counter-strategies.

The security question does not disappear

Explaining sabotage does not mean excusing it.

If employees put company data into public AI tools, that is a real security problem. If they deliberately produce bad outputs, that is a quality problem. If they bypass internal rules, that is a governance problem.

But these problems are not solved by ignoring the motivation behind them.

Shadow AI does not emerge only because people do not know the rules. It also emerges because official tools are worse, slow work down, or the organisation communicates in a way that lacks credibility. In that situation, the system that works in everyday life wins. Not the system written into the policy.

Security therefore needs more than bans. It needs usable tools, clear boundaries, and a deal that employees do not read as self-harm.

The leadership test

The question for leadership is not: how do we make people use AI?

The better question is: under which conditions would it be rational for them to cooperate honestly and actively?

If the answer consists only of training, tool licences, and change communication, the most important layer is missing.

Technology has been introduced, but no credible contract has been built.

Three questions are enough to start:

1. What kind of knowledge are we asking employees to transfer into AI systems?
2. What explicit limits exist for the later use of that knowledge?
3. What happens to people whose knowledge actually makes a process more efficient?

If these questions are not answered, resistance is not a cultural defect. It is a market signal from inside the organisation.

AI adoption does not start with enthusiasm. It starts with a credible deal.