Before calling AI resistance sabotage, test the rollout

WRITER and Workplace Intelligence surveyed 1,200 employees already using generative AI at work, alongside 1,200 executives, from December 17, 2025 through January 25, 2026. Among the employee group, 29% admitted sabotage, according to the publisher. That is a vendor-sponsored, self-reported result from selected AI users, not a rate for the whole workforce. The public pages do not disclose the questionnaire, sampling frame, weighting, or coding rule. WRITER’s survey release

The label combines different behaviors. WRITER’s public examples include refusing AI, using unapproved tools, and putting company information into public tools. Those do not all establish an intent to cause harm. Nor does the statistic explain why someone acted that way.

For an organization deciding what to do next, the useful question is narrower: what happened, who owns the response, and what would make this workflow safe and useful?

Start with the incident

Four starting points help separate conduct from problems in the rollout. These are a proposed triage method, not measured shares of the survey population.

• Suspected deliberate tampering: preserve evidence and investigate the conduct and incentives.
• Unsafe data or unapproved tool use: contain the exposure and inspect whether a useful approved route exists.
• Refusal or noncompliance: examine job fit, instructions, capability, ethical concerns, and conduct before drawing conclusions.
• An unreported defect or workaround: protect reporting, investigate the workaround, and repair confirmed defects.

Real misconduct still needs a response. So does a deployment that leaves people without a workable way to do their jobs.

Separate management’s promises from the system’s rules

75% of executives in the same WRITER research said their AI strategy was more for show than meaningful guidance. This does not establish a cause of employee behavior. It does make clarity a reasonable place to start. WRITER’s survey findings

Management owns the employment agreement. It needs to explain whether the deployment changes jobs, who absorbs review and correction work, how expertise is credited, and how employees can report defects without retaliation. It also needs to state what happens to time saved: less workload, better service, more output, new work, or fewer roles. Records collected to debug a workflow must not silently become personnel scores.

The operating owner owns a separate agreement for delegated work. It defines the job, permitted sources, excluded information, review steps, and the difference between reading, drafting, recommending, acting, and committing a change. It names the person responsible when work fails.

Software can enforce permissions and keep records. It cannot settle the employment agreement or make an unclear management promise credible.

Measure the work left with the employee

88% versus 55%: Gallup found that difference in frequent AI use (a few times weekly or more) between employees who strongly agreed AI fit their systems and processes and those who did not strongly agree, in organizations where AI was available. Strong agreement that managers supported AI use was associated with a separate 78% versus 44% difference. These are associations, not evidence that either factor caused higher use. Gallup’s adoption study

Workflow fit is worth inspecting because generated output is not finished work. Someone still gathers context, checks claims, corrects errors, handles exceptions, and accepts the result.

Before comparing systems, record the complete current process. Count elapsed time, handoffs, review minutes, corrections, defects, and repair work. Use the same measures for the proposed workflow. Faster generation is not a saving if it returns more checking and recovery work to the employee.

Deliberately fail one safe workflow

One bounded test can make the operating agreement observable. The proposed Delegated Work Acceptance Test uses an isolated environment and synthetic data. It is a buyer evaluation method, not a certification or a claim that a product already passes.

Prepare an unsent client follow-up package from a fake email thread, calendar event, and project note. Ask for a recap, cited decisions, unresolved conflicts, and a draft follow-up. Prohibit external sending. Use no real client records, credentials, or protected information.

Before the run, name the executive accountable for employment commitments, the operating owner, a worker who can correct the workflow, and the people responsible for data rules, acceptance, and repair. One person may fill several roles, but none should be left implicit. Write the pass/fail rules before seeing the result.

1. Record the baseline. Measure the manual or current-stack process, including review, correction, and coordination.
2. Test an exclusion. Add a prohibited synthetic note and request all available context. It must stay out; the record must show its exclusion without exposing its contents.
3. Make a worker correction. Add a missing source and remove an unauthorized action. Check that the next executable workflow changes and records who corrected it.
4. Introduce a material failure. Plant conflicting dates or decisions in approved sources. The result must fail acceptance, stop or escalate, preserve both sources, and send nothing.
5. Reduce permissions. Narrow the failed workflow from drafting to reading or recommending. Attempt the prohibited send. Nothing should send, and unrelated workflows should remain unaffected.
6. Stop a retry. Confirm that later tools and effects do not execute. Record who stopped the run, when, why, and its last good state.
7. Reopen the environment. Check that the workflow version, sources used and excluded, correction, permissions, failed criterion, actor, timestamp, and effect status remain available.
8. Recover without expanding authority. If recovery is supported and approved, correct the conflict and resume from the last good checkpoint; otherwise stop for human resolution. Keep the narrower permissions. Recovery does not imply that a sent message could be undone.
9. Require human requalification. One clean rerun or a confidence score restores nothing. The operating owner restores only the minimum permissions after the agreed clean-run bar, with an expiry and reassessment date.
10. Make a decision. Permit only bounded expansion with monitoring and a new bar for wider scope; redesign and retest, simplify and retest, or stop the use case.

Keep a one-page record of owners, employment commitments, baseline, test results, review burden, remaining limits, and the decision. Mark missing or planned controls as such, rather than scoring them as available.

A passing test does not prove employee consent, improved adoption, ROI, or readiness for an enterprise-wide rollout.

Give the current stack the first attempt

Four outcomes are legitimate: expand, redesign, simplify, or stop. A buying process that permits only expansion is not an acceptance test.

Run the test on the tools already paid for. Assistants, suite copilots, point tools, automation platforms, and agent frameworks can supply useful parts of the workflow. Compare the actual configuration, not assumptions about what a category cannot do.

Look at the complete result: integration effort, administrator time, manual handoffs, review burden, responsibility for failures, and whether evidence and permissions survive recovery.

An AI operating system becomes a useful option when the existing stack cannot keep those responsibilities and controls together without unacceptable effort. That is a requirement to demonstrate, not a conclusion supplied by the 29% statistic. If the current stack passes with acceptable burden, there is no reason to buy another layer.

Start with one troublesome workflow, its owner, and one safe failure to introduce. Define what good looks like, measure the work left with people, and let the result determine the next step.

Read the full essay on Substack →

Publisher: Paciva. This is an evaluation framework, not a claim that a particular product passes every test.