AI vendor lock-in, platform dependency and what John Sutter’s Gold Rush can teach us about building on somebody else’s ground
If anybody should have benefited from the California Gold Rush, John Sutter had a reasonable claim to the job.
Gold was discovered on 24 January 1848 in the tailrace of the sawmill he and James Marshall were building at Coloma. [1] Instead, the discovery actively helped wreck the enterprise around it.
Workers left to prospect for themselves, so miners and squatters poured onto the wider estate, livestock and property were taken, claims were occupied and Sutter’s fort and fields emptied. In practical terms, the place was being overrun faster than he, or the institutions around him, could control what was happening.
That is the part of the story that interests me because it is uncomfortably familiar. Once something is loose inside a system, permission and control become two very different things very quickly.
There is a temptation to tell Sutter’s story very simply: he owned the land, people took it, the courts failed him and he lost everything, but the actual history is more complicated, and that’s exactly why it’s relevant.
Sutter held an 1841 Mexican grant for eleven leagues around New Helvetia. He later claimed an additional twenty-two leagues under a second grant dated 1845. When the dispute eventually reached the US Supreme Court in United States v. Sutter in 1858, the Court did not simply declare Sutter’s land title invalid, it upheld the 1841 grant and rejected the additional 1845 claim. [2]
So while the legal question of ownership was still being argued, the practical question of control had already been answered for him. Meanwhile the Gold Rush had already happened.
But what’s that got to do with AI you may ask?
Well probably more than you think. Because legal ownership, practical control and business continuity are not the same thing. Sutter proved it in the 1800s and AI is starting to prove it now, small change by small change, so the real question is:
Do you actually control the AI system you built?
You may control parts of it, some of your information, your instructions, your workflows, files, and perhaps your operating processes. However, the important bits, the working system on the whole depends on somebody else’s model, cloud, code, API, MCP, and somebody else’s account structure, authentication system and most certainly somebody else’s decision about whether a feature still exists tomorrow morning.
“I built it” and “I control it” are not the same thing.
I discovered that rather annoyingly whilst setting up a second laptop. [3]
Anthropic changed how it operated underneath me and moved part of the environment into the cloud. Nothing dramatic flashed across the screen, there was no man in a hard hat waving a flag to inform me that the ground had moved.
It had simply changed. That small vendor decision cost me several hours because it touched files and design work sitting further down the chain, and I had documentation and a map of what connected to what.
But it still hurt, and it still cost me time to get back to normal ops.
What would the same change cost a business that didn’t know what had been built on top of it and what dependencies there were?
So, what is AI vendor lock-in, when it’s at home?
In practical terms, AI vendor lock-in happens when changing a provider, model or platform becomes difficult because too much of the working process depends on that provider’s particular technology, formats, integrations, features or infrastructure.
That is becoming a much larger question as AI moves from experimentation into business operations.
In June 2026, IBM published research based on 1,000 senior executives. Ninety-one per cent said they did not fully understand their AI dependencies across vendors, models and infrastructure. Seventy-one per cent already said switching their primary AI vendor or model would be difficult. [4]
Those are extraordinary numbers if AI is simultaneously being embedded further into ordinary business processes. We have spent several years discussing what AI can do but a much less glamorous question is now becoming unavoidable:
What happens if your AI provider changes the product?
Usually, you absorb the change, the feature disappears, the model behaves differently, an API or a price changes. An integration stops working, or access rules change. A tool that worked on desktop now operates in the cloud. A service is withdrawn, token limits change or something that worked reliably enough to become part of an operating process suddenly doesn’t behave the way it did when that process was designed.
The provider changes its product, often with zero warning, and your business pays the transition cost.
That doesn’t make vendors uniquely wicked. Although there are about another hundred articles to cover that one off!
Regulations change, products change, technology moves and providers amend their commercial models. Sometimes an old service genuinely needs to disappear, the mistake is pretending that dependency doesn’t exist because the service currently works.
Who owns your AI workflow?
Legally, that can depend on contracts, licences, intellectual property, data rights and the particular services involved.
Operationally, there is a much simpler test.
What can you move without asking permission?
- Can you take your source material somewhere else?
- Can you reconstruct the instructions?
- Can another person understand the process?
- Do you know which model-specific features it relies upon?
- Can you export the working data in a usable format?
- Are the decisions and changes recorded outside the tool that made them?
If the provider disappeared tomorrow, what exactly would you still possess on Friday?
That last question is considerably more useful than a comforting green tick next to “backup”.
A backup is important, but it is FAR FROM disaster recovery. Disaster recovery is removing the platform from the critical path, that means knowing what has to survive the platform.
For me the sequence is fairly boring:
- Backup.
- Version control.
- Repository.
- Portability.
- Disaster test.
Boring is underrated when the alternative is discovering during an actual failure that the thing you carefully backed up can only be restored into the system that has just disappeared.
How do you reduce AI vendor lock-in?
- Start by separating the business process from the tool performing it.
- Keep the source of truth somewhere you control.
- Record important instructions and configurations.
- Know where data enters and leaves.
- Document the dependencies between tools.
- Keep important outputs in portable formats where possible.
- Version the things that matter.
- Know which parts of the process are model-specific and which aren’t, and know if there are hidden codes in the files too.
- Periodically test whether you can move the work somewhere else, not theoretically, actually physically move some of it because portability that has never been tested is a belief.
The same principle applies to people.
If only one employee understands how a critical AI workflow operates, you have a human dependency. If only one platform can run it, you have a vendor dependency.
If the evidence for its decisions exists only inside the application that produced them, you have an evidence dependency.
And if changing any one of those things destroys the process, you haven’t removed the dependency by calling the process automated, you’ve hidden it.
This is where Sutter’s story becomes more interesting than the simplified version. He used the institutions available to him, his claims went through the legal process, one grant was ultimately upheld and another was rejected, but a court ruling ten years after the discovery of gold could not rewind the Gold Rush.
It could decide a question of title, but it couldn’t put the workers back in the fields, return the business environment to January 1848, make the flood of people disappear, or recreate the conditions under which the enterprise had originally been designed to operate.
That is the distinction businesses need to understand about technological dependency.
- Contracts matter.
- Terms matter.
- Regulation matters.
- Legal rights matter.
But none of them is a substitute for an operating design that assumes something will eventually change.
The first Gold Rush lesson was about shovels. [5] The second was about reinforcing the seams. [6] The third is probably the least comfortable.
- Know what ground you’re building on.
- Know who controls it.
- And know what it will take with it if it moves.
Because if removing one AI vendor removes the process, you don’t have a portable process, you have a dependency, and dependencies have an irritating habit of revealing themselves only after somebody has built something important on top of them.
Apparently the original Gold Rush was capable of ruining people twice, don’t let the AI gold rush do the same.
PS. Being a history buff I looked into the Sutter character a bit more. Turns out there was a film made about the situation and that went badly too. Sutter’s Gold became one of Universal’s notorious financial failures, [7] and the wider run of expensive productions around that period helped push the studio into financial trouble. Shortly afterwards founder Carl Laemmle and his son lost control of Universal. [8] So the Sutter story managed to leave financial wreckage behind it twice. Just goes to show you never know how the wind is going to blow.
If you want to review your route, your dependencies and what you could actually take with you if the ground moved tomorrow, drop me an email at [email protected]
References
[1] California State Parks, “Gold Discovery Site,” California Historical Landmark No. 530, Marshall Gold Discovery State Historic Park. https://ohp.parks.ca.gov/ListedResources/Detail/530
[2] United States v. Sutter, 62 U.S. 170 (1858), U.S. Supreme Court. https://supreme.justia.com/cases/federal/us/62/170/
[3] Samantha Maeer, contain.digital, 25 August 2026. https://contain.digital/blog/claude-desktop-second-machine/
[4] IBM Newsroom, “IBM Study: Limited Control and Rising Dependencies Leave Enterprises Exposed in the Age of AI,” 17 June 2026. https://newsroom.ibm.com/2026-06-17-ibm-study-limited-control-and-rising-dependencies-leave-enterprises-exposed-in-the-age-of-ai
[5] Samantha Maeer, “The Shovels Have Changed, The Digging Has Not: Prompt Engineering to AI Critical Thinking,” contain.digital, 5 September 2026. https://contain.digital/blog/the-shovels-have-changed-the-digging-has-not/
[6] Samantha Maeer, “Shadow AI: What Happens When the Shovels Are Already Everywhere?,” contain.digital, 7 September 2026. https://contain.digital/blog/shadow-ai-what-happens-when-the-shovels-are-already-everywhere/
[7] American Film Institute Catalog, “Sutter’s Gold” (1936), Universal Productions, Inc., released 13 April 1936. https://catalog.afi.com/Film/1142-SUTTERS-GOLD
[8] Bernard F. Dick, City of Dreams: The Making and Remaking of Universal Pictures, University Press of Kentucky. https://uknowledge.uky.edu/upk_film_and_media_studies/14/