The Feature That May Not Stay: Preparing UK Workflows for an AI Sunset

AI features rarely arrive with a retirement date. They appear inside established platforms as an included assistant, a summarisation button or a recommended next step. For many UK SMEs, that is precisely what makes them attractive: the capability feels like an extension of software the business already trusts, rather than a separate product with its own lifecycle. The difficulty is that familiarity can obscure dependency. A feature that sits inside a finance system, a customer relationship platform or a productivity suite may still be withdrawn, altered or repriced at relatively short notice.

The practical question is not whether a vendor will ever retire an AI feature. It is whether the business has enough visibility, contractual protection and operational fallback to absorb that change without disrupting the work that has grown around it.

Begin with an AI dependency register

Most SMEs do not need a complex configuration management database to manage this risk. A simple register is sufficient, provided it is honest and maintained. For each AI feature in use, record the platform, the workflow it supports, the staff group that relies on it, the data it touches, the named business owner and the current commercial terms. Add a column for the fallback route, even if the entry initially reads as unresolved.

The register should distinguish between features that are merely convenient and those that have become embedded. A drafting assistant that saves a few minutes is different from an AI notetaker that has become the only record of client conversations, or a summarisation tool that feeds a weekly management report. Dependency grows quietly through habit. The register makes that habit visible.

It is also worth recording the vendor's terminology. Features labelled as preview, beta, early access or experimental often sit outside normal service commitments. That does not make them unsuitable, but it does mean the business should not assume the same notice, support or continuity terms apply. A short review each quarter is usually enough to keep the register current and to flag features that have moved from occasional use into critical use.

Read the roadmap backwards

Vendors publish forward-looking roadmaps, but procurement and operations teams should read them backwards. The useful questions concern withdrawal, not arrival. What notice period applies if a feature is discontinued? Can the vendor change the price or usage allowance during the term? Are AI features covered by the service level agreement, or are they explicitly excluded? What happens to data generated by the feature if it is switched off?

These questions matter because AI features are often priced in ways that can change quickly. An included allowance may become a metered charge. A flat fee may become a per-seat or per-use model. A feature that was bundled to encourage adoption may be repositioned as a premium tier once adoption is established. None of this is necessarily unreasonable, but the business should know which terms allow it and what notice is required.

Where the contract is silent, the risk sits with the customer. A request for written clarification is not adversarial. It is a routine part of understanding the service being bought. If the vendor cannot commit to a notice period, the business should treat the feature as changeable and plan accordingly.

A fallback is a workflow, not a toggle

Many continuity plans assume that a fallback is simply another tool. In practice, a fallback is a workflow that staff can perform under pressure. If an AI summarisation feature were removed next month, who would produce the summary? What template would they use? Where would the source material be found? How long would the process take? These questions are more useful than a list of alternative vendors.

The fallback should be tested while the primary feature is still available. A quarterly exercise can be modest: one team completes a routine task without the AI feature and records the friction. The aim is not to prove that the old way is better. It is to confirm that the business can still operate if the feature changes or disappears. For some workflows, the acceptable fallback may be a manual process for a limited period. For others, it may require a replacement supplier or a revised service level with an existing platform.

Data exit deserves particular attention. If the feature generates transcripts, summaries, recommendations or classifications, the business should know how to export that material in a usable format. A fallback that preserves the workflow but loses the record is only a partial answer.

Budget for the reprice, not just the removal

A feature sunset is not always a withdrawal. Often it is a commercial reset. The assistant remains available, but at a higher price or under a narrower allowance. Finance and operations teams should model a few scenarios rather than a single forecast. What would a 20 per cent increase mean for the cost per user? What usage threshold would make the feature uneconomic? At what point would a manual process or a specialist alternative become preferable?

These scenarios do not need to be elaborate. A short table showing current cost, usage, renewal date and trigger point is enough to move the conversation from surprise to preparation. The register and the budget should be reviewed together, because a feature that is cheap today may be critical tomorrow and expensive next year.

Keep people in the plan

Staff adapt quickly to tools that reduce effort, and they notice when those tools change. A sunset plan that focuses only on contracts and systems will miss the practical disruption caused by altered habits. Managers should explain what is changing, why the fallback exists and where to raise concerns. This is also the moment to check for shadow use. If the official feature is withdrawn, staff may adopt unapproved alternatives unless there is a clear, supported route.

Questions to ask before renewal

Before the next renewal, ask for written answers on notice periods for feature withdrawal, price variation, data export, model changes, service credits and support boundaries. Confirm whether AI features are covered by the same terms as the core platform. Ask what happens to prompts, outputs and metadata if the feature is disabled. These are ordinary due diligence questions, not signs of distrust.

The central lesson is straightforward. AI features should be managed as dependencies with a lifecycle, not as permanent fixtures. A register, a few contract clarifications, a tested fallback and a modest budget scenario will not prevent a vendor from changing course. They will, however, give the business a reasonable chance of absorbing the change without discovering, too late, that a convenient feature had become a load-bearing part of the operation.