AI copilots: why the tool doesn't transform the organisation

The licences are rolled out. Developers code faster, product managers write their specs in record time, support handles tickets with the help of generative AI. And yet, a few months later, the organisation looks almost exactly like it did before: same meetings, same approval chains, same queues, same dependencies between teams, same responsibilities.

There's nothing mysterious about this paradox. A tool can improve how well a task is performed without touching the work system that task sits inside. Transformation starts somewhere else: when AI changes the handoff points between roles, decision rights, accountability for the outcome, and how performance is steered.

This is precisely the boundary between equipping an organisation and transforming it.

In brief

• •Copilots produce real individual gains without automatically triggering organisational change.
• •A large-scale experiment involving several thousand employees reveals a clear asymmetry: behaviours an individual can change on their own shift faster than ones that require collective coordination.
• •Observing a broad panel of companies confirms this split: some integrate AI without touching their structure, others explicitly redefine responsibilities, interfaces between roles, and decision rights.
• •The relevant unit for judging a transformation is neither the AI licence nor even the role: it's the workflow. To know whether an organisation is genuinely changing, you have to look at what happens between the start and the end of a work stream.

The adoption-rate trap

The scenario has become a classic. A company equips its employees, launches training, builds a community of champions, and tracks the number of active users. Six months later, it can report a usage rate of 60, 80 or 100%.

That's useful information about adoption. It is not a measure of transformation.

Tools often move faster than methods: their adoption can run months ahead of any real change in working standards. Productivity gains observed on certain tasks — research, synthesis, writing — don't let you conclude that the organisation as a whole mechanically becomes more effective.

The nuance matters. A product manager now writes their spec in two hours instead of four. But if they still have to wait three days for a committee to approve it before handing it to engineering, the overall cycle has barely moved. A developer produces a first version twice as fast; if code review, security testing or the go-live decision remain the bottlenecks, the company mainly ends up with more work sitting in a queue. A salesperson drafts a proposal in thirty minutes; if their director still has to read over every document, the extra capacity simply shifts into the approval queue.

The local gain is real. The system stays exactly the same.

What a large-scale experiment shows

Research conducted between September 2023 and October 2024 lets us move past individual impressions. In a six-month randomised trial, Microsoft tracked 66 large companies and 7,137 employees across different sectors, around the use of Microsoft 365 Copilot.

The result: access to the tool mainly changes behaviours an employee can shift on their own — less time spent on email, some documents produced faster. However, no statistically significant change was found in time spent in meetings.

The explanation is useful for any leader: behaviours that require coordination are harder to shift than ones an individual can act on alone. Giving one person a copilot can change how they work. Shortening a recurring meeting, removing an approval, redistributing a decision, or merging two steps of a process requires something else: several people agreeing to work differently.

This is exactly where the organisational question begins.

Transformation and value creation are not the same thing

The opposite conclusion would be just as wrong: that if the organisation doesn't change, AI is pointless. The data doesn't say that either.

In a study covering 5,179 support agents, researchers Erik Brynjolfsson, Danielle Li and Lindsey Raymond measured an average 14% rise in the number of issues resolved per hour thanks to a generative-AI assistant. The benefit varies widely and is markedly stronger among less experienced agents. In this setup, agents remain accountable for the conversation and can ignore the AI's suggestions.

That's a significant gain achieved without having to immediately upend accountability.

The relevant contrast, then, isn't "useless tool" versus "successful transformation". It's optimising existing work versus changing the work system. Both create value. They simply don't answer the same ambition.

What the company cases reveal

Observing a panel of thirty companies selected for their organisational signals — a useful body of cases, but one that makes no claim to represent the market — leads to a similar conclusion: AI doesn't always trigger an overhaul. At Lucca, Pennylane, Joko, Photoroom or Alma, AI integration takes varied forms, with no documented structural transformation. Elsewhere, other companies change the division of labour, responsibilities, or the interfaces between functions.

Comparing these cases is more instructive than any adoption rate.

Lucca: not reorganising can be a perfectly rational choice

The Lucca case has the merit of stopping "AI reorganisation" from becoming a new orthodoxy. Its product teams, made up of 6 to 8 people, stay structured around their applications. AI is built into the products and into HR practice, but the doctrine remains explicit: AI proposes, the human decides. No public data establishes a productivity gain or a headcount reduction attributable to these features.

This case proves that a company can choose to augment its existing model rather than rebuild it — not that this strategy is better or worse than the alternative. For a sensitive function, an already-effective process, or an organisation where human accountability has to stay very legible, preserving the existing interfaces can be the most reasonable choice.

Doctolib: the change becomes organisational once the decision moves

At Doctolib, the story isn't limited to developers using agents. An explicit framework, internally dubbed "who makes the call?", distinguishes irreversible decisions — certain priorities, legal elements, structural choices — which stay with the product manager, from reversible decisions, which product builders can now make directly, without waiting for their approval.

This is a real organisational change — not because an agent writes more code, but because a long-standing interface between two roles is being redefined. Worth noting: moving 600 engineers to agentic-first demonstrates large-scale adoption, not a matching measured productivity gain.

PayFit: someone becomes accountable for AI once the prototype is done

At PayFit, everything starts with individual use cases and a Copilot prototype. A Senior AI Ops role, an AI PM, 29 champions, and prompt owners responsible for the prompts tied to different personas and their versions gradually appear afterwards.

The figure of 29 champions matters less than what it reveals: work that used to be diffuse now has an owner. Someone drives adoption. Someone owns a prompt. Someone guarantees the business content. The business teams gradually take back ownership of the use cases. The tool becomes work infrastructure — so someone has to decide who runs it, who maintains it, and who answers for its results.

The real test: what has changed in the workflow?

Three levels let you objectively place an organisation.

Level 1 — Equip. The employee does the same work, in the same process, with a new tool. Before: research → writing → manager approval → handoff. After: AI-assisted research → AI-assisted writing → manager approval → handoff. The task speeds up; the workflow stays the same.

Level 2 — Adapt. AI takes on part of the work and the organisation starts adjusting how it operates: standards appear, champions are named, some tasks get automated, control rules evolve, a platform team or an AI Ops role may emerge. How the work gets done changes, but the overall architecture stays recognisable.

Level 3 — Transform. The interfaces between people or teams are redrawn: an approval step disappears, a role can now decide what it used to have to escalate, an agent handles the standard cases and passes on only the exceptions, two teams that used to be separate move closer together because their work becomes interdependent, accountability shifts to the quality of a whole flow rather than the output of one isolated task, and the metrics themselves change because the unit of performance is no longer the volume processed by hand.

This third level is an organisational transformation, even if no org chart moves. Reorganising doesn't necessarily mean moving boxes around on a slide.

Four levers have to move for transformation to actually take hold

Handoffs

A handoff is work moving from one person or team to another: product manager to designer, designer to engineering, tier-1 to tier-2 support, sales to presales, analyst to manager. Organisations accumulate these handoff points because every specialisation has created its own interface.

When a person equipped with AI can now do part of the work that used to be passed on to another function, two paths open up. In the first, the handoff is kept: the person simply prepares what they hand off faster. In the second, its necessity is questioned: the workflow changes. Transformation begins in this second path.

Decision rights

A large share of organisational time isn't spent producing — it's spent waiting for a decision: who can approve, ship to production, settle an edge case, answer the customer directly, check with legal, change a process? When AI sharply raises production capacity but every decision still funnels through the same place, the bottleneck simply moves.

This is a signal observed in several organisations with a strong engineering culture: as production speeds up, the constraint shifts toward the quality of specs, evaluations, review and decision-making — a finding that shouldn't be generalised to every function or every company.

Accountability

A copilot can draft a reply, an agent can propose a price, a system can generate code. But someone still has to answer four questions: who checks it? who can accept a mistake? who handles the exception? who owns the outcome?

The more AI moves from assistant to active participant in the workflow, the more these questions become structuring. That's why the most complete transformations don't stop at "giving AI to the teams": they give rise to new roles — prompt owner, agent supervisor, engineering buddy, AI Ops, orchestrator.

Metrics

An organisation can automate 40% of a process and gain nothing at the overall level. If the remaining cases are more complex, if the rework rate rises, or if human approvals soak up all the time saved, the automation rate on its own says almost nothing. For a model where the human focuses on exceptions, it's better to track volume, the automated share, the exception rate, errors, rework, lead times, quality and, where possible, cost. The same discipline applies to copilots.

The right indicator is no longer "how many employees use AI", but "what has actually improved between the start and the end of the workflow".

Why AI can also reinforce an organisation's flaws

The 2025 DORA report on AI-assisted software development offers one of the most useful conclusions for a leader: AI behaves above all as an amplifier. It tends to reinforce the strengths and the weaknesses already present in the organisational system. The best returns come less from the isolated tool than from the attention paid to the underlying work system.

This consequence goes well beyond software engineering. A team that produces fast but decides slowly creates more work sitting in queues. A process with redundant controls produces faster between each control point, without shortening the total lead time. An organisation with blurry accountability generates more content without any better clarity on who has to approve it. A sales team unable to prioritise its opportunities properly produces twice as many mediocre proposals.

AI doesn't mechanically eliminate a system's flaws: it can raise the throughput that reaches them. This isn't a universal law, but a useful inference — one that leads to a far more interesting question than the adoption rate: what bottleneck are we going to create if this task suddenly becomes five times faster?

Five received ideas the data doesn't support

"If you're not reorganising, your AI strategy has failed." False. Lucca is a useful counter-example: it can be perfectly rational to keep an organisation that works and use AI to improve certain tasks or strengthen the product. The goal isn't to reorganise just so you can say you're transforming.

"A transformed organisation has to change its org chart." Also false. The change in decision rights at Doctolib shows the opposite: a significant transformation can happen inside an existing team. The org chart describes reporting lines; it rarely describes the real flow of work and decisions.

"A high usage rate proves ROI." False. This is precisely the limitation most often flagged in cases where adoption is measured by the number of users, agents, or logins.

"If a company is growing with a stable headcount, AI must be the cause." False. Several cases combine AI adoption, growth and stable headcount, without that letting you isolate causation.

"AI-native organisations show the target to aim for." False. Mistral AI, Anthropic, OpenAI or Dust are interesting points of comparison, but their history, culture, talent, infrastructure costs and business model make any direct comparison with a scale-up that has an existing history especially fragile.

Transformation doesn't start with the tool — it starts with the interface

The distinction between equipping and transforming ultimately comes down to one question: what can a person or a team now do without going through the interface that used to exist? That's where the real changes live.

If a product manager produces a better spec but still waits for exactly the same approvals, AI is augmenting them — it isn't transforming anything. If they can make certain reversible decisions that used to require approval, the system starts to change. If an agent drafts a support reply but every reply still follows exactly the same control chain, support is augmented. If the system resolves the standard cases and human operators focus on the exceptions, the work model changes — with new questions about quality, cognitive load and accountability. If a developer writes code faster, they are augmented. If that speed forces the company to resize its specs, evaluations, review and merge rights, the delivery model is being transformed.

Technology becomes organisational at the precise moment it changes a dependency between people.

Choosing a workflow before launching a new wave of copilots

For a CEO, CTO or CPO, the temptation is often to think in terms of population: how do we equip every developer, train every product manager, get 80% of teams to adopt AI?

A different approach is to start from a single important work stream — for example: client request → qualification → decision → execution → control → delivery — and ask five questions.

• •Where does the time actually go? Not just production time: waiting, handoffs, clarification, approval, correction.
• •Which step can AI genuinely take on? Assistance, production, control, or a reversible decision.
• •Which handoff then becomes unnecessary or different?
• •Which decision right has to change to avoid creating a new bottleneck?
• •Which end-to-end metric will let you verify the system has genuinely improved?

This approach avoids starting with a big, abstract reorganisation. It lets you test a new work model on a limited stream before drawing broader conclusions from it.

The diagnostic: have you equipped your organisation, or started to transform it?

This diagnostic makes no claim to being a scientifically validated maturity model; it's a spotting tool.

Workflow

• •A complete process has been mapped — not just a list of AI use cases.
• •The steps genuinely accelerated since AI arrived have been identified.
• •Wait times, approval times and rework are measured alongside production time.
• •At least one handoff has been removed, simplified or redefined because AI changed how the work gets done.

Decision

• •What AI can propose, produce and possibly execute has been made explicit.
• •Reversible and irreversible decisions don't necessarily follow the same path.
• •Faster production hasn't simply pushed the bottleneck onto a manager, a review, or an approval step.

Accountability

• •For every important use case, a person or a team is clearly accountable for the outcome.
• •It's established who handles exceptions and under what circumstances AI has to stop.
• •The people who check the work genuinely have the time and the skills to do it.

Organisation and skills

• •Roles have been re-examined based on which tasks are disappearing, appearing, or changing in nature.
• •The time saved has an explicit destination: more volume, more quality, a new scope, the client relationship, innovation, or a capacity reduction.
• •Managers know what they can now delegate and what they remain accountable for.
• •Adoption or the number of licences isn't used as the sole measure of success.

Performance

• •A pre-AI baseline allows a credible comparison.
• •An end-to-end indicator is tracked: overall lead time, cost, quality, satisfaction, errors, or business outcome.
• •Unwanted effects are tracked just as closely: exceptions, rework, errors, approval queues, supervision load.

If the positive answers are mostly about tool usage and individual speed, the organisation has probably been well equipped.

If handoffs, decision rights, accountability and the metrics themselves are also starting to move, it has probably entered a transformation of its work model.

The conviction

Deploying a copilot is a technology decision. Transforming the organisation is a work-design decision. One can follow the other; they aren't equivalent.

The available data already shows AI can make certain tasks significantly faster without changing the behaviours that require coordination. It also shows some companies capture real benefits while keeping their existing organisation. But the cases where AI genuinely starts to reshape the organisation share one thing in common: the work isn't just done faster, it flows differently. Decisions move to a different level. Approvals get redistributed. Accountability is made explicit. Teams take on a different scope. Humans handle the exceptions rather than the whole volume. The metrics shift from tool usage to the performance of the flow.

The strategic question probably isn't "have we rolled out enough AI?" any more. It's: which workflow works today exactly as it did before, even though AI has profoundly changed its economics?