AI approval needs to survive the next change

AI lifecycle assurance asks whether an approval still fits the system in use. An approval records a judgement about something that existed at a particular moment. With AI, the thing that was assessed can change without the surrounding organisation being redesigned: an underlying model is updated, a new population starts using the service or the evidence available after deployment qualifies the original confidence. The signature remains while the object of the decision moves.

On 6 October 2026, the UK government accepted all 44 recommendations from the National Commission into the Regulation of AI in Healthcare. The response describes a direction for reform, including stronger post-market assurance and ways to manage iteration. Acceptance of the recommendations is not equivalent to immediate implementation of a new regulatory regime.

The wider idea is nevertheless clear. Assurance has to remain connected to the conditions under which a system works. For marketing and compliance teams adopting AI, that is a useful challenge to an approval culture organised around completed documents and fixed launch dates.

The conditions are part of the decision

The response proposes a lifecycle-based framework with evidence and oversight across a product’s life. It also sets out work on reporting dependencies on underlying general-purpose models. For Predetermined Change Control Plans, the MHRA intends to issue draft guidance by December 2026, exploring boundaries for allowable change while maintaining intended use. These are planned steps, with further development and consultation still to come.

The conceptual shift is from assessing a frozen product to governing a product that may evolve. If a device’s performance depends partly on a model supplied by another organisation, the assessment needs a meaningful account of that dependency. If changes are expected, it needs a way to distinguish acceptable iteration from a change that requires fresh scrutiny. The point is not to assume that every update makes a system unsafe; it is to know which changes matter.

An illustrative marketing equivalent would be an assistant approved to produce factual descriptions from a controlled product catalogue. Its outputs depend on the catalogue, the instructions it receives and the model performing the task. If it later gains access to customer profiles or starts recommending products, its operating conditions have changed even if the interface still looks familiar. The earlier approval cannot answer the new question merely because the software retains its name.

This analogy has limits. Healthcare devices face safety and regulatory obligations that cannot be transferred wholesale to marketing software. The government response does not introduce a marketing approval requirement. What travels is the discipline of preserving the assumptions behind an approval and identifying when those assumptions no longer describe the work.

Change needs a boundary before it needs a queue

Teams often discover that every variation has become a new approval request. The alternative is sometimes an overly broad permission: the system was approved, so subsequent changes are treated as ordinary operations. Both approaches can arise from the same omission, because neither defines what the original decision actually covers.

A more useful approval might state that an assistant may rewrite specified descriptions, for a defined audience and channel, while preserving verified product facts and required qualifications. Changes to tone within that range could follow an established route. Changes to eligibility language, evidence or the balance between benefit and risk could require a different review. This is an operating proposal, not a claim that a particular policy formulation guarantees compliance.

The reasoning behind the boundary matters. If a qualification must remain prominent because customers might otherwise misunderstand a benefit, a system needs to recognise prominence as part of the control. Preserving the words while moving them to a less visible position can change the communication’s effect. A boundary based only on text substitutions would miss the condition the reviewer cared about.

That is why reusable judgement needs its contextual limits. Recording the accepted answer can accelerate repetition. Recording why it was accepted helps the organisation recognise when repetition is no longer appropriate. The latter is more demanding, but it is what turns an archive into a usable basis for future decisions.

Evidence after launch can reopen the question

An approval is also a judgement made with incomplete knowledge. Before launch, teams may test a communication with a sample of customers, assess expected risks or examine a system’s behaviour under representative conditions. Real use can reveal something different: a customer segment misunderstands an explanation, a previously rare failure becomes frequent or a workflow exposes information the test environment did not contain.

Continuous assurance should make those signals consequential. A dashboard that records problems without a route to investigate or change the system is not much of an assurance mechanism. The business needs to know who interprets the evidence, what would prompt intervention and whether the response addressed the issue. In financial services, the relationship between monitoring and action is already a central question in assessing customer outcomes.

For AI-assisted marketing, the evidence may concern both content and process. A sample of outputs can help reveal unexpected claims; reviewer interventions can show recurring weaknesses in a generation instruction; complaints can identify a mismatch between the promised experience and the delivered product. None of those signals has a single automatic meaning. Together, they can support a better judgement about whether the current approval still fits the work.

There is an economic case for being selective. Constantly repeating the entire original assessment would consume specialist attention without necessarily improving control. Teams need to focus on material changes and the evidence capable of showing that the system has moved beyond its accepted conditions. Version records and dependency information help direct that attention instead of simply adding another administrative burden.

The healthcare response makes the problem particularly visible because an evolving system can affect safety. The same underlying question belongs wherever an organisation relies on an AI-assisted decision: what, exactly, remains approved after the next change? A dependable answer requires more than preserving the signature. It requires preserving the conditions that made the signature meaningful.