Cloud repatriation had an exit. AI repatriation may not.
Cloud repatriation is now an established pattern. Organizations that migrated workloads out of their own data centres started bringing some of them back — not all, not as a reversal of strategy, but selectively and for reasons that turned out to be predictable.
The question worth asking now is whether the same correction is coming for AI, and what it would look like.
My answer is that a correction is coming, and that it will be considerably harder than the cloud one — for reasons that have nothing to do with the technology.
What they have in common
Both were adopted faster than they were understood.
Cloud adoption ran ahead of anyone’s picture of what it would actually cost. Cisco’s own customer research in 2015 put the true cost of public cloud at four to eight times the provider’s price once integration, security authorization, network work, vendor management and service catalogue work were counted. That gap is what produced repatriation. Not a failure of cloud — a failure to price it.
AI adoption is running ahead of any picture of what it will actually do to the operating environment. Same shape.
Both were sold as a substitution when they were actually a reconfiguration.
Cloud was sold as moving a workload. What it actually did was redistribute responsibility, change who held operational knowledge, and alter the cost structure in ways that showed up two budget cycles later.
AI is being sold as automating a task. What it actually does is relocate a decision — and decisions have relationships attached that no task inventory contains.
And in both cases, the people who chose it were not the people who would live with it.
That was the point of the 2023 piece. The migration decision sat with finance and IT. The consequences landed on operations, procurement and the people doing the work.
How they are different, and this is the part that matters
Cloud repatriation was possible because three things were true. None of them is reliably true for AI.
Cloud repatriation
AI repatriation
Trigger
A visible operating signal that arrives on its own — cost, latency, sovereignty, performance
Margin erosion and degraded relationships, attributable to something else
Object
Entangled and expensive to move, but nameable
A decision process with no portable form
Destination
A prior state that frequently still existed
Judgment that was never written down, held by people who have moved on
Each row deserves its own explanation.
1. Cloud repatriation had a bill — or another visible operating signal
The trigger was frequently an invoice. Somebody had to explain a monthly number that kept growing, and that number was undeniable, itemized and arrived on schedule.
It was not always the invoice. Latency, data sovereignty, regulatory obligation, security posture and performance predictability all drove repatriation decisions too. But every one of those is the same kind of thing: a visible operating signal that forces the question, arriving on its own without anyone having to go looking for it.
An agent making a mediocre decision produces no invoice.
The cost shows up as margin erosion, a supplier relationship that quietly degraded, an opportunity nobody knew was available, a customer who did not come back. All of it real. All of it attributable to something else. There is no line item that says this decision was worse than the one a person would have made.
⚠ Without a bill, there is no trigger. And without a trigger, the correction does not start when the problem starts. It starts when something breaks visibly, which is much later and much more expensive.
But I want to be precise here, because the absence of a trigger is a design choice rather than a property of automation.
There is no bill because nothing in these deployments is measuring the outcome against the world. That is not inevitable. A system that records what actually happened after each decision — delivered or not, correct item or wrong one, relationship intact or not — produces the signal without anyone having to attribute it. Degradation enters the record as an outcome and the ranking moves, whether or not a human noticed or understood why.
That is not speculative. It is what the 1998 architecture I have written about did. Every transaction was tracked from purchase through delivery, so a supplier whose performance slipped did not require anyone to file a complaint. The historic attribute updated itself and the next ranking a buyer saw was different.
And it caught something stronger. After the system moved into production it took on an attribute nobody had specified at design — capturing defective and wrong-part shipments — because operating it revealed that on-time delivery of the wrong item had been counting as success. The measure itself turned out to be short a dimension, and the architecture absorbed the new one rather than being rebuilt around it.
So the honest version of this section is narrower and more useful than AI repatriation will have no trigger.
Organizations that automate a decision without building an outcome loop will have no trigger. Organizations that build one will see the correction coming while it is still cheap.
The difference is not the technology. It is whether anyone specified what a good outcome looks like and arranged for the world to report back on it.
2. Cloud repatriation had an identifiable object
I want to be careful here, because cloud repatriation was frequently not easy. Workloads become entangled with managed services, proprietary APIs, identity architectures and serverless functions, and moving one back can require substantial re-engineering.
But the organization could always say what had moved and what would have to move back. The object requiring reversal remained nameable, however expensive it was to shift.
A decision process that has been automated is different.
If an agent has been selecting suppliers for eighteen months, there is no artifact to bring back. There is a history of outcomes and a model nobody can inspect. The thing you would be repatriating does not exist in a portable form.
3. Cloud repatriation had somewhere to return to
This is the decisive difference.
When organizations repatriated workloads, the prior state was frequently still available — the data centre had not been demolished, the team had not entirely dispersed, the runbooks existed, and the institutional knowledge of how the thing ran was recoverable at a cost.
You cannot repatriate to a process you never documented.
When AI replaces a decision that lived in someone’s head — the buyer who knew which supplier to call when the schedule slipped, the technician who knew what the four o’clock order actually meant, the planner who knew which customer would tolerate a delay and which would not — reverting means reverting to what, exactly?
The people have been reassigned or have left. The knowledge was never written down, because it was never on the process map to begin with. The undocumented layer is precisely the layer that automation is most likely to displace, because it is the layer nobody could see well enough to protect.
The offshoring precedent, with the exit closed
Organizations offshored functions to reduce headcount cost, then discovered the coordination overhead, the quality variance, and the knowledge loss. A great deal of it came back, at a premium, and the reshoring was frequently more expensive than the original saving.
But it was possible, because the work was still work. You could hire people, train them, and rebuild the capability — slowly and expensively, but it could be done.
The difference is that offshoring moved the work to different people. Automation can remove the practical ability to restore human judgment — when the knowledge was tacit, undocumented, and allowed to leave with the people who exercised it.
Those three conditions matter. An organization that retained its logs, its exception records, its people and its written rules has a path back. The warning is not about automation as such. It is about automating a decision whose reasoning was never written down, and then losing the people who held it.
That is not an argument against automation. It is an argument for knowing what you are automating before you automate it — which is the same argument as everything else in previous technology eras, arriving through a different door.
What AI repatriation will probably look like
Not a reversal. Selective, quiet, and described as something else.
I would expect it to appear first as:
Roles being recreated under new titles, eighteen to thirty months after they were eliminated, to do work that turns out to require judgment nobody could specify.
Human review layers being added back into workflows that were fully automated, described as quality assurance rather than as reversal.
Pilots quietly not scaling, with the decision framed as prioritization rather than as failure. This is already happening in volume.
Vendors repositioning from autonomy toward augmentation, and describing it as what they meant all along.
⚠ None of that will be called repatriation, which is why the pattern will take longer to become visible than the cloud one did. Cloud repatriation had a name because it had an invoice. This will not.
The falsifiable version
I would rather state this so it can be wrong.
My claim: organizations that automated decisions without first establishing how those decisions were actually being made — and without building a loop that reports the outcome back — will incur a correction cost materially higher than cloud repatriation, and the correction will be harder to identify because nothing in the architecture is arranged to notice it.
What would show me wrong: if agentic deployments prove straightforwardly reversible at scale — if organizations that fully automate a decision function can restore human judgment without significant relearning cost, and can do it without first having to reconstruct a process nobody documented — then the concern is misplaced and I will say so here.
What would confirm it: roles reappearing under new names, review layers being added to workflows sold as autonomous, and organizations discovering that reverting requires reconstructing knowledge that left the building.
I do not know whether the evidence will ultimately support the claim. But it is checkable, and I would rather have the prediction on the record with a date on it than write about it afterward as though I had known.
The one thing that prevents it
Not a guardrail. A record.
If you know how the decision was actually being made — not the documented version, the operating version — then automating it is a choice you can reverse, because you retained the thing that would have to come back.
Which is where this meets the post before it. That one ended on a census: before deciding how to govern an agent estate, establish what is actually running. The same trace does both jobs. Working backward from how a decision is really made produces the record that keeps the door two-way — and it is the only version of documentation that is worth anything, because it describes the operating process rather than the one on the wall.
If you do not, then the automation is not a deployment decision. It is a one-way door, and the reason it looks like a two-way door is that nobody has tried to walk back through it yet.
Related: the post preceding this one, on AI agent governance and the estate nobody mapped.
What Does Cloud Repatriation and AI Repatriation Have in Common, and How Are They Different?
Posted on August 16, 2026
0
Cloud repatriation had an exit. AI repatriation may not.
Cloud repatriation is now an established pattern. Organizations that migrated workloads out of their own data centres started bringing some of them back — not all, not as a reversal of strategy, but selectively and for reasons that turned out to be predictable.
In August 2023 I asked who besides the CFO should be involved in procurement’s migration to the cloud. The short version of the answer was that the decision was being made by people who could see the sticker price and not by people who could see the operating consequences.
The question worth asking now is whether the same correction is coming for AI, and what it would look like.
My answer is that a correction is coming, and that it will be considerably harder than the cloud one — for reasons that have nothing to do with the technology.
What they have in common
Both were adopted faster than they were understood.
Cloud adoption ran ahead of anyone’s picture of what it would actually cost. Cisco’s own customer research in 2015 put the true cost of public cloud at four to eight times the provider’s price once integration, security authorization, network work, vendor management and service catalogue work were counted. That gap is what produced repatriation. Not a failure of cloud — a failure to price it.
AI adoption is running ahead of any picture of what it will actually do to the operating environment. Same shape.
Both were sold as a substitution when they were actually a reconfiguration.
Cloud was sold as moving a workload. What it actually did was redistribute responsibility, change who held operational knowledge, and alter the cost structure in ways that showed up two budget cycles later.
AI is being sold as automating a task. What it actually does is relocate a decision — and decisions have relationships attached that no task inventory contains.
And in both cases, the people who chose it were not the people who would live with it.
That was the point of the 2023 piece. The migration decision sat with finance and IT. The consequences landed on operations, procurement and the people doing the work.
How they are different, and this is the part that matters
Cloud repatriation was possible because three things were true. None of them is reliably true for AI.
Each row deserves its own explanation.
1. Cloud repatriation had a bill — or another visible operating signal
The trigger was frequently an invoice. Somebody had to explain a monthly number that kept growing, and that number was undeniable, itemized and arrived on schedule.
It was not always the invoice. Latency, data sovereignty, regulatory obligation, security posture and performance predictability all drove repatriation decisions too. But every one of those is the same kind of thing: a visible operating signal that forces the question, arriving on its own without anyone having to go looking for it.
An agent making a mediocre decision produces no invoice.
The cost shows up as margin erosion, a supplier relationship that quietly degraded, an opportunity nobody knew was available, a customer who did not come back. All of it real. All of it attributable to something else. There is no line item that says this decision was worse than the one a person would have made.
⚠ Without a bill, there is no trigger. And without a trigger, the correction does not start when the problem starts. It starts when something breaks visibly, which is much later and much more expensive.
But I want to be precise here, because the absence of a trigger is a design choice rather than a property of automation.
There is no bill because nothing in these deployments is measuring the outcome against the world. That is not inevitable. A system that records what actually happened after each decision — delivered or not, correct item or wrong one, relationship intact or not — produces the signal without anyone having to attribute it. Degradation enters the record as an outcome and the ranking moves, whether or not a human noticed or understood why.
That is not speculative. It is what the 1998 architecture I have written about did. Every transaction was tracked from purchase through delivery, so a supplier whose performance slipped did not require anyone to file a complaint. The historic attribute updated itself and the next ranking a buyer saw was different.
And it caught something stronger. After the system moved into production it took on an attribute nobody had specified at design — capturing defective and wrong-part shipments — because operating it revealed that on-time delivery of the wrong item had been counting as success. The measure itself turned out to be short a dimension, and the architecture absorbed the new one rather than being rebuilt around it.
So the honest version of this section is narrower and more useful than AI repatriation will have no trigger.
Organizations that automate a decision without building an outcome loop will have no trigger. Organizations that build one will see the correction coming while it is still cheap.
The difference is not the technology. It is whether anyone specified what a good outcome looks like and arranged for the world to report back on it.
2. Cloud repatriation had an identifiable object
I want to be careful here, because cloud repatriation was frequently not easy. Workloads become entangled with managed services, proprietary APIs, identity architectures and serverless functions, and moving one back can require substantial re-engineering.
But the organization could always say what had moved and what would have to move back. The object requiring reversal remained nameable, however expensive it was to shift.
A decision process that has been automated is different.
If an agent has been selecting suppliers for eighteen months, there is no artifact to bring back. There is a history of outcomes and a model nobody can inspect. The thing you would be repatriating does not exist in a portable form.
3. Cloud repatriation had somewhere to return to
This is the decisive difference.
When organizations repatriated workloads, the prior state was frequently still available — the data centre had not been demolished, the team had not entirely dispersed, the runbooks existed, and the institutional knowledge of how the thing ran was recoverable at a cost.
You cannot repatriate to a process you never documented.
When AI replaces a decision that lived in someone’s head — the buyer who knew which supplier to call when the schedule slipped, the technician who knew what the four o’clock order actually meant, the planner who knew which customer would tolerate a delay and which would not — reverting means reverting to what, exactly?
The people have been reassigned or have left. The knowledge was never written down, because it was never on the process map to begin with. The undocumented layer is precisely the layer that automation is most likely to displace, because it is the layer nobody could see well enough to protect.
The offshoring precedent, with the exit closed
Organizations offshored functions to reduce headcount cost, then discovered the coordination overhead, the quality variance, and the knowledge loss. A great deal of it came back, at a premium, and the reshoring was frequently more expensive than the original saving.
But it was possible, because the work was still work. You could hire people, train them, and rebuild the capability — slowly and expensively, but it could be done.
The difference is that offshoring moved the work to different people. Automation can remove the practical ability to restore human judgment — when the knowledge was tacit, undocumented, and allowed to leave with the people who exercised it.
Those three conditions matter. An organization that retained its logs, its exception records, its people and its written rules has a path back. The warning is not about automation as such. It is about automating a decision whose reasoning was never written down, and then losing the people who held it.
That is not an argument against automation. It is an argument for knowing what you are automating before you automate it — which is the same argument as everything else in previous technology eras, arriving through a different door.
What AI repatriation will probably look like
Not a reversal. Selective, quiet, and described as something else.
I would expect it to appear first as:
⚠ None of that will be called repatriation, which is why the pattern will take longer to become visible than the cloud one did. Cloud repatriation had a name because it had an invoice. This will not.
The falsifiable version
I would rather state this so it can be wrong.
My claim: organizations that automated decisions without first establishing how those decisions were actually being made — and without building a loop that reports the outcome back — will incur a correction cost materially higher than cloud repatriation, and the correction will be harder to identify because nothing in the architecture is arranged to notice it.
What would show me wrong: if agentic deployments prove straightforwardly reversible at scale — if organizations that fully automate a decision function can restore human judgment without significant relearning cost, and can do it without first having to reconstruct a process nobody documented — then the concern is misplaced and I will say so here.
What would confirm it: roles reappearing under new names, review layers being added to workflows sold as autonomous, and organizations discovering that reverting requires reconstructing knowledge that left the building.
I do not know whether the evidence will ultimately support the claim. But it is checkable, and I would rather have the prediction on the record with a date on it than write about it afterward as though I had known.
The one thing that prevents it
Not a guardrail. A record.
If you know how the decision was actually being made — not the documented version, the operating version — then automating it is a choice you can reverse, because you retained the thing that would have to come back.
Which is where this meets the post before it. That one ended on a census: before deciding how to govern an agent estate, establish what is actually running. The same trace does both jobs. Working backward from how a decision is really made produces the record that keeps the door two-way — and it is the only version of documentation that is worth anything, because it describes the operating process rather than the one on the wall.
If you do not, then the automation is not a deployment decision. It is a one-way door, and the reason it looks like a two-way door is that nobody has tried to walk back through it yet.
Related: the post preceding this one, on AI agent governance and the estate nobody mapped.
Jon Hansen, FCIPS — Procurement Insights | Hansen Models™ | Independent. Unsponsored. Archive-based.
-30-
Share this:
Like this:
Related