A team builds a workflow around an AI product. Prompts get refined over months. Instructions get saved. Staff learn which phrasing produces usable output. Then the product changes. A feature is renamed, a plan is restructured, a model is swapped underneath the same interface, or the product is folded into a larger suite. The workflow still exists, and the results shift in ways nobody can explain.
AI products change on a schedule the buyer does not set. Names change, tiers change, capabilities move between plans, and entire products are retired. Organizations adopt these tools at the pace of a purchase decision and absorb the changes at the pace of a quarterly review. The gap between those two speeds is where the exposure sits. The piece on AI readiness covers what an organization needs in place before AI multiplies what it finds. This piece covers one specific thing AI finds in an organization that has adopted it, which is work that lives on someone else's platform.
The Pace Nobody Planned For
Procurement habits come from an era of slower software. A purchase meant a product that stayed recognizable for years. Training materials stayed accurate. A workflow built on the product kept working until the organization chose to change it.
AI products follow a different rhythm. Vendors release changes continuously. Behavior shifts between versions. Features move from one tier to another, or from one product to another inside the same vendor's lineup. A product that anchored a team's workflow in one year can carry a different name, a different price, or a different set of capabilities in the next, and sometimes it is gone.
Planning for this rarely happens, because the purchase felt small. A subscription on a team card triggers no review of dependencies. The decision to adopt took a week. The decision about what happens when the product changes was never made, because nobody framed it as a decision.
What Gets Stranded
When a product changes, the visible loss is the interface. Staff relearn where things are. That cost is real and short.
The larger loss sits in what the organization put inside the product. Three things tend to accumulate there.
Prompts come first. Months of refinement produce phrasing that works. The phrasing lives in a saved chat, a personal notes file, or the memory of one enthusiastic staff member. When the product changes, the phrasing may stop producing the same output, and nobody holds a record of why it worked.
Context comes second. Teams load documents, style guidance, client background, and standing instructions into a tool so it can produce work in the organization's voice. That context sits in the vendor's system, in a format the organization may be unable to export. When the product goes away, the context goes with it.
Judgment encoded in configuration comes third, and it is the subtle one. A team makes a series of choices: which outputs to accept, which settings to use, which checks to run, how to route results. Those choices reflect hard-won knowledge of what good looks like for that team. The choices live in the configuration, and the reasoning behind them lives nowhere. The configuration becomes the only record of how the team decides.
Together these amount to operating knowledge. The organization built it over months and stored it in a place it does not control.
Platform-Dependent Versus Portable
Work built on an AI product falls into two groups.
Platform-dependent work exists only inside the product. The prompts sit in the product's saved history. The workflow runs through the product's own automation features. Instructions to the tool serve as the only documentation of the process. Remove the product and the process disappears with it.
Portable work exists outside the product. The process is described in plain language where the organization holds it, and the product performs a step within that description. Another product, or a person, could perform the same step with the same description in hand. The organization owns the process and rents the tool.
The two groups produce identical output on a good day. The difference appears on the day the product changes. A portable process absorbs the change as an inconvenience. A platform-dependent process absorbs it as an outage, and the organization learns what it had been relying on at the moment that reliance fails.
A process that lives only inside the tool belongs to the vendor.
Most organizations hold a mixture of both groups, and few have sorted one from the other. The sorting itself reveals something. The processes that feel most mature, the ones staff describe as running smoothly, are often the ones with the least written down, because smooth operation made documentation feel unnecessary.
The Question Before the Next Tool
One question belongs ahead of every adoption, and it applies to tools already in use as well. If this product disappears in eighteen months, what survives?
The answers sort quickly. Prompts either exist somewhere the organization controls or they sit in a vendor's history. The process is either described in plain language or it exists as behavior. A person either understands the work well enough to do it by another route or the understanding lives in the tool's settings.
The answers differ by tool and by team, and they differ in what they cost to learn. Learned in advance, the exposure is a list. Learned at the moment of a retirement notice, it becomes a scramble on a deadline the vendor set.
AI governance addresses who owns the decisions that surround these tools. Ownership of the work inside them belongs on the same agenda. The pattern has a clear shape: the tools change faster than organizations absorb the changes, work accumulates inside the tools, and the organization's own record of that work stays thin.
The order in which an organization documents its processes, builds portable versions, and moves off a platform is its own discipline. Any product in use today can change shape on a date its vendor chooses. The organization that holds its own record of the work will meet that date as a calendar entry.