The presentation looked familiar. Cost per unit of work. Vendor capability matrix. Time-to-value curve. Risk register. A transformation roadmap that promised efficiency gains if the organization followed the programme.
I had seen it before. Many times.
The first time, the vendor was an offshore software development centre. Then it was a business process outsourcing firm. Then a managed infrastructure provider. Now the vendor is an LLM, and the slide deck has a different logo but the same argument: externalize this work, reduce costs, free your people for higher-value tasks.
AI adoption is outsourcing. Not as a loose metaphor. You are moving work that was previously done internally to an external provider you do not fully control, cannot fully audit, and whose reliability depends on a contract you did not negotiate. The mechanics are identical. Only the provider has changed.
This is not a criticism. Outsourcing, done well, genuinely works. But “done well” requires a transformation programme that most organizations skip, and they skip it now with AI for the same reasons they skipped it then.
We Have Seen This Movie Before
The modern outsourcing era in technology began in earnest in the 1990s. Labour arbitrage was the pitch: why pay engineering rates in London or New York when equivalent work could be done in Bangalore or Warsaw at a fraction of the cost? The pitch was not wrong. The problem was that “equivalent work” concealed an enormous assumption.
What followed was a generation of transformation programmes. Most of them underdelivered. A few were spectacular disasters. A handful actually worked. The ones that worked understood early that outsourcing was not a procurement decision. It was an organizational redesign.
Then came BPO, the externalization of finance, HR, customer operations. Same pitch. Same pattern. Then cloud infrastructure, which outsourced the provisioning and management of compute to AWS, Azure, and GCP. Each wave brought genuine efficiency, and each wave punished organizations that treated it as a cost-cutting measure rather than a transformation.
Now we are in the AI wave. The pitch is familiar: externalize cognitive work to a model, reduce overhead, focus your people on judgment and creativity. The promise is real. So is the hangover.
What You Are Actually Signing Up For
Every outsourcing programme that worked had a rigorous set of transformation activities that ran in parallel with the vendor engagement. These were not optional. They were the programme. The vendor contract was the easy part.
Capability assessment, knowing what can leave and what must stay. In outsourcing, this meant mapping every function, identifying which tasks were genuinely transferable and which depended on institutional knowledge, customer relationships, or judgment that could not be documented. Organizations that skipped this step discovered the hard way that some of what they had outsourced was load-bearing.
In AI adoption, this is task decomposition. Which decisions can safely be delegated to a model, and which require human judgment, accountability, or contextual awareness the model does not have? Most teams get this wrong in both directions. They either delegate everything that feels mechanical, or they protect everything that feels creative. The real boundary is harder to find than either instinct suggests.
Process documentation, you cannot hand off what you have not defined. Outsourcing firms had a standard demand during transition: show us the process. Not the way you think the process works. The way it actually works. For most organizations, this was a revelation. Work that had been performed by experienced people who simply knew what to do turned out to be nearly impossible to document, because the knowledge lived in the people, not in the procedures.
LLMs need the same clarity. A prompt is a process specification. If you cannot describe the task precisely enough for a prompt to work reliably, the problem is not the model, it is that the process was never explicit enough to transfer. This is the same discovery outsourcing teams made in the early 2000s, and it is just as uncomfortable.
Governance and SLA design, who checks the work. No serious outsourcing programme ran without an SLA framework: quality metrics, escalation paths, dispute resolution, regular review cycles. The client organization retained a governance function specifically to manage the relationship and verify that the work met the standard.
AI adoption needs the same thing and usually does not have it. Output review loops, quality gates, and human-in-the-loop checkpoints are not optional features, they are the governance layer. Organizations that deploy AI without them are running an outsourced operation without a retained governance function. They did this with outsourcing too, and the results were predictable.
Knowledge transfer and ramp, bringing the provider up to your context. Offshore teams spent months in knowledge transfer before taking over a function. Structured sessions, shadowing periods, documented edge cases, escalation support from the retained team. The ramp was expensive. Skipping it was more expensive.
With AI, the equivalents are fine-tuning, retrieval-augmented generation, system prompt design, and domain context injection. The model does not know your business, your customers, your edge cases, or your regulatory context by default. Telling it that context is a knowledge transfer programme. Treating it as optional produces the same results as skipping knowledge transfer in outsourcing: early outputs that look fine, and later failures that are hard to diagnose.
Transition risk management, planning for when it goes wrong. Every outsourcing transition plan included contingency. What happens if the vendor underdelivers? What is the rollback path? Which critical functions have a break-glass procedure if the outsourced operation fails?
AI systems hallucinate. They refuse requests at unexpected moments. They degrade on inputs that differ from their training distribution. A well-designed AI adoption programme plans for these failure modes the same way a well-designed outsourcing transition planned for vendor risk. Fallback paths are not pessimism, they are engineering discipline.
Retained organization design, the new role of the people who remain. This was the part that outsourcing programmes got wrong most often. The retained organization, the people who stayed after the function moved offshore, was given a coordination role: managing the vendor, reviewing outputs, handling escalations. But their job descriptions were not rewritten. Their skills were not developed. And within two or three years, many of them were doing less interesting work than before, with less institutional knowledge, because the work that had given them context had left.
AI adoption is producing the same pattern in slow motion. The people whose tasks are being delegated to models need a genuinely new role, with new skills and a new mandate. Not “do the same job but review AI outputs.” A different job, designed for a world where the model handles the first pass.
The Graveyard of Good Intentions
Why did most outsourcing programmes underdeliver? The vendor was rarely the primary cause.
The governance function was understaffed because it felt like overhead. The knowledge transfer was cut short because it was running over budget. The retained organization was not redesigned because that felt like a separate HR initiative. The process documentation was incomplete because documenting tacit knowledge is slow and expensive. And the capability assessment had been optimistic, because the business case needed a certain number to work.
These are not edge cases. This is the standard pattern, playing out again in the same order.
Prompt debt accumulates because the governance function does not exist. Hallucination incidents are absorbed rather than investigated because there is no quality gate. The team that was supposed to be freed for higher-value work is instead spending time reviewing and correcting model outputs, which is coordination work, not value work. And the skill atrophy is already visible: the people who used to do the work are losing the feel for when the output is wrong.
The technology is not the problem. The transformation programme is.
What the Survivors Did Differently
The organizations that got outsourcing right were not the obvious ones. They shared a different mindset about what the programme actually was.
They understood the work before they externalized it. The organizations that succeeded treated the capability assessment and process documentation phases as valuable in their own right, not as overhead before the real work started. The discipline of documenting what you do, in enough detail to hand it off, produces insights that improve the function whether or not it is outsourced. The same is true for AI. The prompt engineering and task decomposition work is valuable independent of the model.
They treated governance as load-bearing. The SLA framework, the review cycles, the escalation paths, these were not bureaucracy. They were the mechanism by which the client organization remained in control of outcomes even after ceding execution. AI governance serves the same function. Without it, you have not delegated work. You have just stopped checking it.
They designed the retained organization forward. The best outsourcing programmes asked: if this function moves, what does the retained team do? They answered that question before the transition, not after. The new role was designed, resourced, and trained for. In AI adoption, the equivalent question is: if the model handles this task, what does my team do? The answer cannot be “they oversee the model.” That is the coordination trap. The answer needs to be a genuine new mandate.
They planned for repatriation. Every serious outsourcing contract had exit provisions. What happens if we want to bring this back? What data, processes, and capabilities do we need to retain to make that possible? AI adoption should have the same clause built into programme design. Reversibility is not defeatism, it’s risk management.
They recognized that culture preceded technology. The outsourcing programmes that failed often failed because the organization was not ready to give up control. The ones that succeeded had done cultural work first: building tolerance for the transition period, creating psychological safety for the retained team, being honest about what was changing and why. AI adoption faces the same cultural challenge. The technology is available. The organizational readiness is the variable.
The Pattern Is Available to Us
We have been here before. LLMs are genuinely new technology, this is not another labour arbitrage play, but the transformation challenge is familiar. Moving work offshore. Handing a business process to an external provider. Migrating infrastructure to the cloud. Every wave looked new from the inside.
The pattern is documented. The mistakes are known. The question is not whether AI adoption requires a transformation programme, it does. The question is whether anyone in the room has lived through one before, and whether they’re being listened to.
If you lived through an outsourcing programme, as a client, a vendor, or someone caught in the middle, I’d be curious whether this reads as familiar.