Leading AI Transformation Without Leaving People Behind

The clearest signal that an AI programme is in trouble is usually a healthy-looking adoption dashboard. The real question is whether the work, responsibility, and decision rights have changed.

TL;DR

• AI value comes from redesigning workflows, not placing generation tools inside unchanged processes.
• Human–AI collaboration must be specified task by task; full delegation is the default drift, not a neutral outcome.
• Removing entry-level tasks can also remove the apprenticeship through which an organisation develops future experts.
• Reskilling works when it is embedded in a redesigned process and teaches domain-specific failure modes and verification.
• Psychological safety is a governance control because concealed AI use makes inventories, risk classification, and oversight unreliable.
• Human accountability is meaningful only when reviewers have evidence, time, authority, and a manageable decision volume.
• Leaders must be honest about role change while making disclosure, challenge, redeployment, and experimentation procedurally safe.

Opening observation

The clearest signal that an AI programme is in trouble is usually a healthy-looking dashboard. Licence utilisation above eighty percent, weekly active users climbing, a respectable count of prompts per seat, and a slide showing which departments are ahead of the curve. Everything on the chart is real. What the chart does not show is whether a single approval step, handover, review gate, control point, or job description has changed since the tools arrived, and in most of the programmes I have watched at close range, the answer is that nothing has. The work is done the same way, by the same people, in the same sequence, with the same people accountable for the same outputs. Something new sits inside each step, producing drafts faster.

Anyone who was in enterprise IT during the ERP wave, the offshoring wave, the robotic process automation wave, or the agile transformation wave will recognise the shape of this. Each of those arrived with a technology story and a rollout plan, and each of them delivered roughly what the surrounding operating model allowed it to deliver. Organisations that used ERP as an excuse to renegotiate who owned a process got something durable out of it. Organisations that configured the software to reproduce the process they already had got an expensive replica of their previous problems, with a longer change-request queue. The technology in each wave was capable of more than it delivered, and the gap was never mainly technical.

AI is following that pattern with unusual speed, and the reason is worth stating plainly, because it explains most of what follows. Every previous wave required a project to reach a person's desk. This one arrives on its own. People adopt it privately, often before any policy exists, and they adapt their own work around it without telling anyone. By the time the transformation programme starts, the workforce has already been transforming itself for eighteen months in the dark, and the organisation has no reliable picture of where or how. That is a governance problem before it is a technology problem, and it is a leadership problem before it is either.

What the evidence says about adding tools

The most useful number I know of on this question comes from McKinsey's survey work on generative AI adoption, which tested twenty-five organisational attributes against the ability to show EBIT impact from AI use. The redesign of workflows had the largest effect of any attribute tested—larger than budget, larger than talent, larger than technology stack. In the following year's survey, with roughly nine in ten respondents saying their organisations used AI regularly in at least one function, only thirty-nine percent could attribute any level of EBIT impact to it, and most of those put the figure below five percent. The high performers, defined as organisations claiming both significant value and more than five percent of EBIT attributable to AI, were about six percent of the sample.

Those two findings sit together uncomfortably for anyone selling tools, and they are entirely consistent with what the operational evidence shows about what happens when output gets cheaper and nothing else changes. Research from BetterUp Labs and Stanford's Social Media Lab, published in Harvard Business Review in September 2025, put a name to the mechanism: work that looks finished, arrives faster, and lacks the substance to advance the task. Roughly four in ten of the US desk workers surveyed reported receiving something of that description in the previous month, with an average of just under two hours spent resolving each instance. The costs are estimated rather than measured and the time figures are self-reported, so the precise numbers deserve the usual scepticism. The direction, however, is not really in doubt, and it is confirmed by anyone who has spent a quarter reviewing submissions from a team that recently acquired a copilot licence.

The structural point underneath the survey is the one that matters. When you add a generation tool to an unchanged workflow, you make production cheaper for the person who produces and verification more expensive for everyone downstream, and you do so without moving any budget, headcount, time allocation, or accountability to match. The gain is captured privately by the producer and the cost is socialised across the reviewers, which is a reliable way to make a system look more productive while it becomes slower. Holweg and Davenport extended this argument in Harvard Business Review in June 2026 by suggesting that the accumulated effect degrades an organisation's collective knowledge base over time; that framework synthesises existing evidence rather than testing a new hypothesis, and should be read as a proposition rather than a finding. It is nonetheless the right question to be asking, because it asks about the system rather than the task.

Collaboration is a design decision, not a default

There is a persistent assumption in transformation programmes that human–AI collaboration will emerge on its own once people have access, and the observable evidence runs the other way. Anthropic's Economic Index, which analyses patterns across its own consumer and API traffic, has tracked the share of interactions in which a user hands over a complete task with minimal iteration. That share rose from around twenty-seven percent to around thirty-nine percent over eight months, and enterprise API traffic, where the systems are wired into processes rather than used conversationally, skews overwhelmingly toward full automation rather than collaborative iteration. This is one vendor's telemetry and should be read as such, but the drift it describes matches what teams report: as the systems get better, people stop looking at the intermediate steps.

That drift is not a failure of character. It is what capable tools do to attention, and it has been documented in aviation, clinical decision support, and process control for three decades. What it means for a transformation programme is that the collaborative model has to be specified, staffed, and enforced, because the delegated model is what you get by default. Specifying it involves decisions that most programmes never make explicitly: which steps in a process are delegated outright, which are drafted by a system and materially reworked by a person, which remain entirely human because the judgement involved is the point, and where in the sequence verification sits. Those four categories look obvious written down, and are almost never documented anywhere in the organisations that claim to have adopted AI at scale.

The unit of that decision is the task, not the job, and the distinction carries more weight than it appears to. A role is a bundle of tasks that has accumulated for reasons that are partly deliberate and partly historical, and the tasks within it differ enormously in how well they tolerate delegation. Treating the role as the unit produces the two failure modes that dominate the current discourse—the assumption that a whole occupation disappears, and the assumption that nothing about it changes—while treating the task as the unit produces something an operating model can actually be built from. It also produces an uncomfortable finding, in most organisations, about which tasks were holding the role together.

Role redesign and the apprenticeship problem

The evidence on where the workforce effects are actually landing is the most consequential input to any people agenda in this area, and it deserves to be handled carefully rather than dramatically. Brynjolfsson, Chandar, and Chen's work using ADP payroll microdata, circulated under the title Canaries in the Coal Mine?, found relative employment declines in the region of thirteen to sixteen percent, depending on specification, for workers aged twenty-two to twenty-five in the most AI-exposed occupations, while employment for older workers in the same occupations held steady or grew. The mechanism appears to be a reduction in hiring rather than a wave of dismissals, which is precisely why it is easy to miss: nobody is fired, no announcement is made, and the aggregate headcount looks unremarkable while the entry cohort quietly thins.

The authors have themselves revisited the causal question more than once, publishing a note in February 2026 addressing whether interest-rate movements explain the pattern better than AI exposure does, and concluding that they do not, while acknowledging that the timing only becomes statistically clean from 2024 under the broadest set of controls. Stanford's own policy commentary has been careful to note the confounders—pandemic over-hiring, rate rises, remote-work patterns—and the honest summary is that the correlation is well documented, the causal attribution is contested, and the direction is consistent enough that planning against it is prudent.

What makes this a design problem rather than a labour-market curiosity is what junior work was actually doing inside the organisation. In most professional environments, the tasks now most exposed to automation were also the apprenticeship: the reconciliation nobody enjoyed, the first-pass document review, the test cases, the data cleanup, the draft memo that came back covered in corrections. That work was inefficient as production and extremely efficient as instruction, because it was how people acquired the pattern recognition that later makes someone worth consulting. Removing it removes the mechanism by which the organisation manufactures its own seniors, and the bill for that arrives four to seven years later, at which point nobody connects it to a decision made in 2026.

Anyone who lived through the large-scale offshoring of testing and maintenance work in the 2000s has seen a version of this. The immediate economics were sound and the immediate quality impact was manageable. What a number of organisations discovered some years later was that they had exported the environment in which their future architects had previously been formed, and that rebuilding it cost considerably more than the original saving. I would not push the analogy further than it can bear, because the situations differ in important ways. The transferable lesson is narrower and harder to argue with: when you remove a category of work, you should establish what else that work was doing before you remove it.

Role redesign, done seriously, means answering that question deliberately. If first-pass review is now machine work, then the junior year has to be rebuilt around verification, adversarial testing, edge-case discovery, and supervised judgement, all of which are teachable and none of which happen by accident. The organisations I have seen handle this well did something unglamorous: they wrote down what a person in each affected role should be able to do unaided after twelve months, compared it to what the redesigned workflow would actually expose them to, and closed the gap on purpose.

Reskilling that survives contact with the work

The World Economic Forum's Future of Jobs Report 2025 put the expected change in core skills at thirty-nine percent by 2030, with fifty-nine of every hundred workers requiring training and eleven of those unlikely to receive it, and with skills gaps named by sixty-three percent of employers as the primary barrier to transformation, ranking above culture, regulation, and capital. Numbers of that shape have a way of producing a training budget, a platform procurement, and a completion-rate metric, and then producing very little else, because generic capability programmes have a poor record of changing what happens in a workflow the following Tuesday.

The reskilling that has worked, in what I have observed, has been narrow, embedded, and tied to a specific redesigned process with a named decision at the end of it. It teaches people what the system is bad at in their particular domain, rather than what it is good at in general. AI literacy, in a regulated environment, is much closer to the ability to articulate a failure mode than to the ability to write a clever prompt—a person who can say why this system produces confident nonsense on precisely this class of input is a control, and a person who can produce a slick output in half the time is a risk until proven otherwise. That distinction should drive the curriculum, and it rarely does.

Editorial update, 27 July 2026. The regulatory backdrop has now moved. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force three days later. It replaced the EU AI Act's Article 4 duty to ensure, to the best extent, a sufficient level of AI literacy with a duty for providers and deployers to take measures that support its development; the amended text expressly says that no specific level must be guaranteed for any individual. The regulation also moved the application of high-risk obligations to 2 December 2027 for standalone systems and 2 August 2028 for systems embedded in regulated products. Most Article 50 transparency obligations were not deferred.

The correct reading is not that the workforce question has been downgraded. It is that the regulatory floor has shifted while the operational requirement stayed exactly where it was. For Swiss institutions the position was always closer to this anyway. Switzerland signed the Council of Europe Framework Convention in March 2025 and opted for a sector-specific approach rather than a horizontal act, with a consultation draft expected by the end of 2026, while FINMA's Guidance 08/2024 has since December 2024 expected supervised institutions to inventory their AI applications, classify the associated risks, define responsibilities, ensure they can explain outputs, and subject the whole arrangement to independent review. FINMA also observed something that most workforce discussions omit: as processes decentralise and systems act with more autonomy, assigning responsibility becomes materially harder. That is a people problem written in supervisory language.

Psychological safety as a control, not a comfort

The single most useful workforce statistic on AI that I have encountered comes from the study led by Nicole Gillespie and Steve Lockey with KPMG, covering 48,340 people across 47 countries. Fifty-seven percent of employees said they hide their use of AI and present AI-generated work as their own. Around two thirds reported relying on AI output without evaluating its accuracy, and a majority reported having made mistakes at work as a result. Fewer than half of respondents globally said they were willing to trust AI systems, while a clear majority were using them anyway.

The instinct in most organisations is to read the concealment as a discipline problem. The experimental evidence suggests it is a rational response to an accurate perception. Reif, Larrick, and Soll, in four preregistered experiments with 4,439 participants published in PNAS in May 2025, found that people who use AI at work both anticipate and actually receive worse evaluations of their competence and motivation, with the effect extending to assessments of job candidates. Employees who conceal their AI use are not being deviant. They are correctly reading a social environment in which disclosure carries a cost, and they are protecting themselves from it.

For a regulated institution, this converts a cultural observation into a control gap of a familiar kind. An organisation cannot maintain the AI inventory FINMA expects, or the deployer obligations the AI Act imposes, or any meaningful model-risk position, when the majority of actual usage is undeclared. The entire supervisory architecture assumes the institution knows where AI is being used, and the evidence says most institutions do not, because they have built an environment in which telling them is individually irrational. There is no policy document that closes that gap. It closes when disclosure is safe, and disclosure becomes safe when the first few people who disclose are visibly not punished for it.

The industry evidence on this points in a consistent direction while being weaker than it is usually presented. A survey of more than 500 executives by MIT Technology Review Insights in partnership with Infosys, published in December 2025, found that eighty-three percent believed psychological safety measurably affects the success of AI initiatives, while only thirty-nine percent described the level in their own organisation as high, and sixty percent said greater clarity about AI's impact on jobs would improve it. That study measures executive belief rather than outcomes and was commissioned by a vendor with an interest in the conclusion, which is worth saying out loud. Its value is in the gap between the first number and the second, which is a gap between what leaders think matters and what they have built.

Human accountability that would survive a review

Almost every AI governance framework in circulation resolves its hardest question by asserting that a human remains accountable, and the human-factors literature has been explaining for thirty years why that assertion, unsupported, is close to worthless. Automation bias—the tendency of people, including expert people, to defer to automated output and reduce their own scrutiny—has been documented since at least Skitka and colleagues in 1999 and reviewed extensively by Parasuraman and Manzey in 2010. It has also been demonstrated in AI-assisted clinical decision-making, where even radiologists were measurably influenced by advice they believed came from a system. Ben Green's analysis of policies requiring human oversight of government algorithms makes the institutional version of the argument: oversight requirements often function to legitimise deployment rather than to constrain it.

Madeleine Elish's concept of the moral crumple zone is the sharpest formulation of the risk, and it is directly relevant to anyone designing accountability structures. The human placed at the end of an automated process to absorb responsibility for its failures frequently has neither the information nor the practical control to prevent them, and ends up absorbing blame for a system they could not realistically supervise. An organisation that assigns accountability that way has not created a control. It has created a designated person to hold when something goes wrong, and the people in those seats work that out quickly, with predictable effects on how carefully they look and how long they stay.

Accountability that would survive an actual supervisory review requires four things that can be tested rather than asserted. The reviewer needs the evidence behind the recommendation rather than a summary of it, because a well-written summary is precisely what defeats scrutiny. The reviewer needs enough time budgeted for the review to be possible, which means the time has to appear in the capacity model rather than in the policy. The reviewer needs genuine authority to reject the output without that rejection being treated as an obstruction, which is a cultural condition with an organisational-design component. And the volume of decisions routed for review has to be small enough that attention remains a scarce resource spent deliberately, because gating everything trains the reflex to approve everything.

The governing question is not whether a human is in the loop. It is whether this particular human, with this particular evidence, in this particular amount of time, can catch this particular class of error before it does damage. Where the honest answer is no, the correct response is to prevent the outcome architecturally rather than to gate it procedurally, and to stop describing the arrangement as human oversight in documents that a regulator will one day read.

Transparent governance runs in both directions

Organisations that ask their employees to declare AI use, and then decline to declare their own, should expect the asymmetry to be noticed. If AI now contributes to how work is allocated, how performance is assessed, how candidates are screened, how scheduling is decided, or how anomalies in employee behaviour are flagged, the workforce has a legitimate interest in knowing that, and increasingly a legal one. The Annex III high-risk category under the EU AI Act covers exactly this territory, and the deferral to December 2027 changes the compliance date rather than the underlying position.

Transparency at this level is unglamorous and mostly consists of writing things down that people currently infer. A register of where AI touches employment decisions. A statement of what the systems are permitted to determine and what they may only inform. A description of the recourse available to someone who believes a system got them wrong, with a named human at the end of it. A clear statement of what is being measured about how employees use AI, and what those measurements will and will not be used for. None of this is technically demanding, and most organisations have not done it, which is one reason the workforce assumes the worst.

The connection to governance in the narrower sense is direct. Every one of those artefacts is also an input to the AI inventory, the risk classification, and the accountability map that supervisors expect institutions to hold. Building them for the workforce and building them for the regulator are largely the same exercise, and organisations that treat them as separate programmes end up with two incomplete versions of the same document.

Fear is an operational risk, not a motivational tool

There is a management theory in circulation at the moment which holds that people will adopt AI faster if they are afraid of what happens if they do not, and it is worth understanding why that produces a worse outcome rather than merely an unpleasant one. Fear produces concealment, and concealment produces exactly the undeclared usage that makes the control environment unmanageable. Fear also produces compliance-shaped activity, which is where mandated adoption targets meet a workforce that has understood the assignment: prompt counts rise, licence utilisation rises, and the volume of plausible-looking output that somebody downstream has to verify rises with them.

The deeper cost is informational, and it is the one that most directly damages the transformation itself. The people who know which steps in a process are safe to automate, which exceptions the documented workflow does not cover, and which control exists because of something that went badly wrong in 2011, are the people doing the work. In an environment where identifying an automatable step is understood to be volunteering for redundancy, that knowledge stops moving upward, and the redesign gets done by people who have to guess. I have watched programmes discover the resulting gaps in production, which is the most expensive place to discover them.

None of this argues for reassurance that leadership cannot honestly give. Promising that no role will change is both false and quickly detected, and it destroys credibility faster than the original anxiety did. What can be committed to is specific and procedural: that the organisation will say what it knows when it knows it, that people affected by a redesign will hear it from their own management rather than from an all-hands slide, that reskilling will be funded and time-boxed rather than expected in evenings, and that the criteria for who is redeployed where will be written down in advance. Those commitments are keepable, and keeping them is what allows the information to keep flowing.

Developing leaders for AI-augmented teams

The management job changes more than the individual contributor job does, and organisations have been slow to notice this. A manager in an AI-augmented team is allocating work between people and systems rather than only between people, which is a new allocation problem with no established heuristics. They are reviewing evidence and reasoning rather than finished artefacts, because the artefact is no longer a reliable signal of effort or of understanding. They are responsible for a decision they did not personally compute, which is a familiar position for anyone who has managed specialists but a novel one for the many managers whose authority rested on having done the job themselves. And they are running a team whose junior layer is thinner and whose development now has to be constructed rather than absorbed.

That is a different skill profile from the one most leadership programmes develop, and it is not primarily technical. It requires enough understanding of the systems to know what questions to ask, which is a lower bar than most executives fear and a higher one than a vendor briefing provides. It requires the ability to sit with partial observability, since a manager will increasingly be accountable for outputs they cannot fully trace. And it requires the specific discipline of teaching verification, which means reviewing how a team member checked something rather than only whether the answer was right, and doing so consistently enough that it becomes the norm rather than an audit.

There is one finding in the executive research that deserves more attention than it has received. In the MIT Technology Review Insights study, around a fifth of respondents admitted to having hesitated to propose or lead an AI initiative because they feared failure or criticism. The people expected to create psychological safety for their teams do not reliably have it themselves, which means leadership development in this area has to make it survivable for a leader to run something that does not work. An organisation that punishes its first failed AI initiative will find that the second one is proposed by nobody, and that the third is procured quietly by a business unit that has stopped telling anyone.

Closing reflection

The reason the tools-first approach persists is that it is tractable. Licences can be bought within a quarter, adoption can be measured within a month, and the resulting chart can be presented to a board without anyone having to renegotiate a single reporting line. Redesigning work is slower, more contested, and requires decisions that touch people's authority and standing, which is why the evidence on what actually produces value keeps pointing at it and why organisations keep declining to do it.

What is being redesigned, ultimately, is not the workflow. It is the distribution of responsibility. Every meaningful decision in an AI transformation is a decision about who is accountable for what, on what evidence, with what recourse when it goes wrong, and with what obligation to say so afterwards. Those questions have always been the substance of governance in regulated environments; AI has made them arrive faster, in more places, and about decisions that were previously too small to formalise. An organisation that answers them explicitly ends up with something a supervisor can follow, an employee can rely on, and a leader can defend. An organisation that leaves them implicit ends up with a control environment held together by the assumption that someone was probably checking.

The test I would apply to any AI transformation, two or three years in, has nothing to do with adoption rates. It is whether the organisation can still say who decided what and on what basis, and whether it is still producing people capable of making the next decision rather than only output capable of being generated faster. Those two capabilities are what an institution actually consists of, and neither of them survives being treated as a side effect of a rollout.