Change control after an AI go-live: keeping a live Claude system reliable

Change control after an AI go-live means treating every edit to a live Claude system as a production release. That covers its prompts, its routing rules, the model it runs on and the Zoho data it reads. Each change is versioned, tested, approved, released and reversible. Go-live does not end the project. It starts a stream of small changes, and each one can break something that worked yesterday.

Change control, in this guide, is the routine that decides which changes reach the live system, in what order, after which checks, and how you undo them. It is not the same as change management. Workast describes change management as "the structured approach utilized by an organization to transition from a current state to a desired future state". That is about preparing people. Change control is about keeping the system itself stable while it changes.

The two meet at one point. Staff will ask for adjustments once they use the assistant every day. A routine for those requests protects the people who now rely on it.

A live Claude system changes in four places. Each one needs its own version history. If you only track one, the other three will drift without anyone noticing.

• Prompts. These are the written instructions that tell Claude what to do, what to refuse and how to format its answer.
• Routing rules. These are the conditions that send a request or ticket to a team, a queue or a person.
• Zoho data and connections. This covers the fields, departments, picklists and permissions in Zoho CRM or Zoho Desk that Claude reads and writes, and the connection that links them.
• Model and platform. This is the Claude model the system calls, and the plan and organisation settings around it.

The data matters as much as the prompt. Glen Stansfield, writing on LinkedIn about AI controls, puts it plainly: "A lot of the operational risk starts earlier, with the knowledge the model is allowed to trust." Suppose someone renames a Zoho Desk department or retires a picklist value. A routing rule that was correct last month now points at something that no longer exists.

Stansfield makes a related point. An AI control "can correctly enforce a permission that was valid when it was defined, even though the operating conditions behind that permission have changed." A live system can follow its rules perfectly and still be wrong.

Some changes to a live Claude system come from Anthropic, not from your team. Your change control has to watch for them. You cannot schedule them, but you can plan for them.

Anthropic released three new models in under three weeks in autumn 2026. Claude Opus 5.5 arrived on 22 September, Claude Sonnet 5.5 on 28 September and Claude Haiku 5.5 on 7 October, according to the Anthropic newsroom. A 2026 Usage Policy update followed on 8 October. Each new model is a reason to re-test, even if you choose not to move.

Every current model has a published earliest retirement date on the Claude models overview:

• Claude Fable 5.1: not sooner than 1 September 2027.
• Claude Opus 5.5: not sooner than 22 September 2027.
• Claude Sonnet 5.5: not sooner than 28 September 2027.
• Claude Haiku 5.5: not sooner than 7 October 2027.

Put the date for your model in your change calendar now.

Platform settings change too. From 6 October 2026, new Cowork tasks on Pro and Max plans run in the cloud. The Help Center states that "you can't switch back". A change with no undo needs more care before it lands, not less.

Versioning means you can name exactly what is live and return to the previous state in minutes. For each Claude system, keep one record per release. The record holds:

• the prompt text, with a version number and date
• the routing rules, written out in full
• the model name the system calls
• the Zoho fields, departments and permissions the system depends on
• who approved the release, and why

The model record should include what the model can actually do. The Models API returns "max_input_tokens, max_tokens, and a capabilities object for every available model". Save that response with each release, so you can compare it when you change models. Capabilities differ between models. For Claude Haiku 4.5, for example, the API reports server-side code execution as supported but programmatic tool calling as not supported.

At Svennis we keep the previous version of every prompt and routing rule stored beside the live one. Rolling back then means copying a known file back, not rewriting instructions from memory under pressure.

Organisation settings belong in the record as well. The models overview warns that "an administrator can disable web search". A request that uses that tool then fails, even though the model supports it.

Every change to a live Claude system should pass the same test set before it reaches users. A test set is a fixed collection of real past requests whose correct outcome you already know. You run it before and after the change and compare the results line by line.

Build the test set from your own history. Use tickets, emails or enquiries where a person has already confirmed the right answer. Include the awkward ones: mixed languages, missing details, two issues in one message. All current Claude models support multilingual input, so test in every language your customers actually write in.

Three checks matter for most systems:

• Outcome. Did the request land in the right place, with the right fields filled?
• Format. Does the output still match what Zoho expects to receive?
• Refusals. Does the system still decline what it should decline?

Keep the test set stable between releases so the results are comparable. Add new cases when a live mistake teaches you something, but do not remove old ones. Our guide to testing a Claude workflow before go-live covers how to build the first set. The same set then becomes your regression test for every change after launch.

A controlled release changes one thing at a time and keeps the previous version ready to switch back. If you change the prompt and the model on the same day and results get worse, you will not know which change caused it.

Plan each release in four steps:

1. Write down the change, the reason and the expected effect.
2. Run the test set and record the result against the current version.
3. Release at a quiet time, with the owner watching the first live cases.
4. Switch back to the saved version if live results fall short of the test.

Some changes have no rollback. These need a decision before release, not a fix afterwards. Anthropic states that migrating an organisation from Team to Enterprise through the self-serve path "is not reversible".

Several features that are on by default on Team are off by default on Enterprise, according to the Help Center. These include Skills and code execution. A system that relied on a Skill can stop working the morning after an upgrade. Its underlying data is retained, but the feature is off.

Spend limits need the same attention. Once the organisation-level spend limit is reached, "all users lose access immediately". Raising the limit before you release a heavier workload is part of the change.

This example follows one change from start to finish. It shows how change control works on a real decision. A service team uses a Claude assistant to classify incoming tickets and route them to departments in Zoho Desk. The assistant runs on Claude Sonnet 5.5. The team wants to move the classification step to Claude Haiku 5.5.

The reason is in Anthropic's documentation. The models overview positions Haiku 5.5 "for high-volume, latency-sensitive tasks such as classification, extraction, and routing". It is priced from $0.10 per million input tokens and from $0.50 per million output tokens. Sonnet 5.5 costs $2 and $10.

The team works through the change like this:

1. Record the current state. They save the Sonnet 5.5 prompt, the routing rules, the Zoho Desk department list and the Models API response.
2. Compare capabilities. They call the Models API for Haiku 5.5 and check the capabilities object against everything the step uses.
3. Run the test set. They run past tickets with known correct departments through both models and compare the results line by line.
4. Adjust only the prompt. Haiku 5.5 misreads one category, so they fix the prompt, version it and re-test.
5. Release and watch. The owner reviews the first live day of routing in Zoho Desk.
6. Keep the rollback. The Sonnet 5.5 configuration stays saved, and switching back means changing one model name.

Nothing else changes in the same release. The department list stays frozen until the model change has settled.

Each type of change to a live Claude system carries a different risk. The table below sets out what to test and how to undo each one. Use it as the checklist your owner signs off against.

Change	What can break	Test before release	Rollback
Prompt wording	Classifications, output format, refusals	Full test set, side by side with the current prompt	Restore the saved prompt version
Routing rule	Tickets reach the wrong team or no team	Test set, plus cases for every affected department	Restore the saved rule set
Zoho field, department or picklist	Rules point at values that no longer exist	Check every prompt and rule that names the value	Restore the old value, then update rules in a separate release
Claude model	Quality, cost, supported tools	Models API capabilities check, then the full test set	Switch back to the saved model name
Plan or organisation settings	Features off by default, tools disabled, users without seats	Review the vendor's list of default changes in advance	Often none, so decide before release

The last row is the one most often missed. During a Team to Enterprise migration, Anthropic notes that some users may appear as "No seat assigned" until an admin corrects it. That is a live outage for those users, caused by an administrative change.

Approving a change does not prove the system stays safe once it runs. Someone has to own the live system and be able to stop or change it. Stansfield states the principle directly: "approval is a point-in-time decision. It is not permanent evidence that execution remains safe."

He offers a useful test for any approval path. When something is escalated or challenged, "does somebody gain or exercise authority to change the outcome?" If the answer is no, the approval step is decoration. Name one owner per Claude system, with the authority to pause it, roll it back or refuse a change.

The Centre for the Study of Existential Risk gives a working definition of control. It anchors control "to the setting and getting of goals". Its paper lists what being in control needs, including the ability to set goals and "a functional control loop".

For a business system, that loop is concrete. You set the goal, measure live results against the test set, and correct when they diverge. The paper also notes that control can be lost through AI behaviour "far below the level of superintelligence". An unmonitored routing assistant is a small, ordinary example of that.

For a UK company, change control mostly means fitting AI changes into the release habits you already use for finance and CRM systems. Most UK businesses running Zoho already freeze changes around month end or busy trading periods. Apply the same freeze to prompts, routing rules and model changes.

Many UK firms sign staff in through Microsoft 365. If you manage Claude users through Microsoft Entra ID with SCIM, the Help Center notes that Entra "pushes changes approximately every 40 minutes". A joiner or leaver change is therefore not instant. Build that delay into release plans that depend on user access.

Domain verification for an Enterprise organisation can take time as well. Anthropic advises allowing 24 to 48 hours for DNS changes to propagate. Many changes take effect within 10 minutes. Do not schedule a go-live for the same afternoon as a domain change.

Your legal obligations depend on what the system does and whose data it handles. Our summary of AI law in the UK for businesses sets out what applies. A versioned record of every release also gives you a clear account of what the system did at any date, if a customer or regulator asks.

You can put basic change control in place in a few working sessions. You do not need new software. Start with the system that touches customers first.

1. Name one owner for each live Claude system, with authority to pause and roll back.
2. Write down the current prompt, routing rules, model name and Zoho dependencies as version one.
3. Save the Models API response for the model you use.
4. Build a test set from past cases with confirmed correct outcomes.
5. Add your model's earliest retirement date to the change calendar.
6. Check your organisation spend limit and default settings before any plan change.

If your system is not live yet, start with our guide to testing a Claude workflow before go-live. The test set you build there becomes the backbone of change control afterwards.

If you are still choosing where Claude should sit in your processes, see how we approach AI automation for growing businesses. You can also browse AI by business task to find the process closest to yours.