AI Is Tearing Companies Apart Along the Org Chart
Updated: 2 days ago
Rewritten, 4 October 2026. An earlier version of this post led with a figure we could not trace to a reliable source. This version keeps what the evidence supports.
The customer-support summarisation tool had been live for six weeks when the arguments started. The support director wanted it rolled out to every team. The IT security lead wanted it paused until someone had reviewed what customer data it sent to the model provider. Data science pointed out that it was only ever a pilot. Finance asked whose budget the API bill came from. The meeting set to resolve it ended with an action to "set up an AI working group".
(Composite scenario, drawn from patterns common in enterprise AI rollouts. Not a single named company.)
Every person in that room was being reasonable. Each was protecting something they were accountable for. The tool itself worked fine. What it exposed was that nobody had decided who gets to decide.
What executives are actually reporting
The clearest recent evidence comes from a survey by WRITER with Workplace Intelligence. It ran from 17 December 2025 to 25 January 2026 and covered 2,400 knowledge workers (1,200 C-suite executives and 1,200 employees) in the US, UK, Ireland, Benelux, France and Germany, at companies with 100 to more than 10,000 employees (WRITER, April 2026).
Several findings describe the same fracture from different angles:
54% of the C-suite said adopting AI is tearing their company apart.
56% said it had created power struggles and disruption.
78% of executives said AI had created tension between IT and other lines of business.
55% described AI use at their company as a chaotic free-for-all.
29% of employees, including 44% of Gen Z respondents, admitted to sabotaging their company's AI strategy.
79% of executives acknowledged struggling with issues such as lagging ROI, strategy gaps and internal power struggles.
Only 29% said they had seen significant ROI from generative AI.
Two cautions on reading these. First, they're self-reported perceptions from people inside these companies, not measured outcomes. Second, WRITER sells an enterprise AI platform, so it has an interest in the problem being real. The method is published, and the findings point in a consistent direction, which is why they're worth taking seriously. Still, treat them as a strong signal about how adoption feels from the inside, not as a census.
The interpretation, which is ours: most of these findings aren't about the technology. Power struggles, IT-versus-business tension, a free-for-all and active sabotage are all symptoms of the same missing thing.
Why "it's a change-management problem" doesn't go far enough
The usual response is to call this change management: more training, more communication, an executive sponsor. Those help, and they're the wrong first move. Training people to use a tool doesn't settle who can approve a new one. Communication doesn't settle whose budget pays for it. A sponsor who can't say who has authority to pause a system just adds another voice to the argument.
The mechanism is structural:
AI changes work that crosses team boundaries, such as support, data and IT security in the example above.
Budgets, incentives and decision rights stay inside those boundaries.
So every cross-boundary decision becomes a negotiation. Who approves the tool? Who can change the prompt? Who can switch it off?
Each team optimises for what it's measured on. Support is measured on handle time, security on incidents, data science on shipped models, finance on spend.
Where no rule exists, the loudest stakeholder or the most cautious one wins. Others route around the process, which is how you get a free-for-all and, at the extreme, sabotage.
That's why the fractures run along the org chart. They appear where teams meet and nobody has written down who decides.
Run this: list the last three disputes about an AI tool in your organisation. For each one, write the decision that was actually contested, such as "approve", "pause" or "pay for". If the same decision type appears twice, you've found an undefined decision right.
The discovery move: map decisions before tools
Most AI programmes start with a tool inventory. The organisations that avoid the fracture start one step earlier, with the recurring decisions an AI workflow needs, and who makes each one.
The intake question is: for this workflow, who can approve it, change it, pause it and answer for its outcome? If any of those four answers is "it depends" or "a committee", the workflow will produce the meeting in the opening story.
A decision-rights map makes this concrete. It's one page, and it's the most useful artefact an AI programme can produce in its first month.
Recurring decision | Decides | Must be consulted | Informed |
Approve a new AI tool or vendor | Business unit owner, within platform standards | Platform team, security, procurement | Finance |
Change a prompt, model or tool in production | Workflow owner | Platform team (for shared components) | Users of the workflow |
Pause or switch off an AI system | Workflow owner, or security (unilaterally, for a suspected incident) | — | Everyone affected |
Sign off a high-risk use (customer decisions, regulated data) | Legal and compliance | Workflow owner, security | Executive sponsor |
Fund ongoing running costs | Business unit that owns the outcome | Finance | Platform team |
(Illustrative default. Your rows and names will differ; the point is that every cell has one named answer.)
Note the pause row. Security can stop a system unilaterally during a suspected incident, without a meeting. Defining that one right in advance removes the most common standoff, where a cautious team blocks a rollout indefinitely because it has no other lever.
Run this: draft this table for one live AI workflow. Show it to the five people named in it and ask each whether they agree with their row. Every disagreement you surface now is a meeting you won't have during an incident.
A worked example: the support tool, mapped
Back to the summarisation tool. Here's how the map would have resolved it, decision by decision.
Roll out to every team? That's a change to a production workflow, so it's the support director's call as owner. They're required to consult the platform team, because the rollout uses the shared model gateway.
Pause for a data review? Security's concern was data handling, not an active incident. So security has a consulted role and a deadline, not a veto. If the review finds customer data reaching the provider without an agreement in place, it becomes an incident, and security's unilateral pause right applies.
Is it still a pilot? The map has no "pilot" status that suspends ownership. Once real customers' data flows through it, the workflow owner owns it.
Whose budget? Support's, because support owns the outcome. Seeing the running cost in its own budget also gives support a reason to measure value.
None of those answers required new technology or a working group. They required someone to decide, ahead of time, who decides.
Options for structuring ownership
Model | Gains | Costs | Fits when | Warning signs |
IT owns AI | Consistency, security, one vendor list | Slow, conservative, far from the work being changed | Highly regulated, low appetite for change | Business units buying tools on expense cards |
Business units own AI | Speed, close to the work | Duplicate vendors, uneven controls, repeated reviews | Small number of independent units | Five tools for one job; security learns about tools after launch |
Central AI team owns AI | Concentrated expertise | Builds things no business unit adopts | Very early, while building capability | Impressive demos, little production use |
Federated (units own workflows; platform owns shared infrastructure; legal and compliance own the gates) | Speed with standards | Needs explicit decision rights, or it degrades into all three problems | Most mid-size and large organisations | No written decision-rights map |
Federated ownership is our default recommendation. Its failure mode is specific, though: without the decision-rights map, it degrades into all three of the other models' problems at once.
Tradeoffs and exceptions
Writing decision rights down creates friction at first. People who used to decide informally now have to consult, and some will feel slowed down. That's the trade for removing the much larger friction of contested decisions.
Small organisations can skip the formality. If one person genuinely owns technology, data and the business outcome, the map is that person's name in every row. Write it anyway: it takes ten minutes, and it's what lets the organisation grow without inheriting the fracture.
A unilateral pause right can be abused. If security pauses systems for reasons that aren't incidents, the right needs a definition of "suspected incident" and a time limit before it goes to the executive sponsor.
Implementation reality
The map has to live somewhere decisions actually get made. Attach it to the intake for every new AI workflow, review it when an owner changes jobs, and link it from the incident runbook so the pause row is findable at 2 a.m. Assign it an owner of its own, usually whoever runs the AI programme, or it will be out of date within a quarter.
What to do next
Choose the AI workflow that has caused the most argument in the last quarter. Draft its decision-rights map this week, using the table above as the template, and walk it past the people named in it. If one table settles one recurring argument, the case for doing the rest makes itself.
Final takeaway
AI isn't tearing companies apart because the technology fails. It's exposing decisions that cross team boundaries and that nobody has assigned. Map who approves, changes, pauses and pays for each AI workflow before you argue about which tool to buy, and the org chart stops being where your AI programme breaks.
Sources
WRITER with Workplace Intelligence, Enterprise AI adoption survey 2026, press release, 7 April 2026. Fieldwork 17 December 2025–25 January 2026; 2,400 knowledge workers (1,200 C-suite, 1,200 employees) in the US, UK, Ireland, Benelux, France and Germany. https://writer.com/blog/enterprise-ai-adoption-survey-results-press-release/
