Operating AI Systems: Drift, Model Updates and Provider Change

Part II treated operations with AI as the operator. This chapter turns the relation round and treats AI as the thing operated. A service that contains a model, a prompt, a retrieval index and a set of tools behaves differently from a service made of code alone: its behaviour can change when nobody has deployed anything, because a provider has replaced a model, an index has gone stale or the world that the model was trained on has moved. The chapter concerns O1 Observe, where quality, drift and freshness become service level objectives that are measured independently of the model under test; O3 Change, where a model, a prompt or an index is released, canaried, pinned and rolled back as configuration with a change record; and O5 Sustain, where provider notices, retirements and deployer duties are kept as a standing part of the service's lifecycle.

The subject is the operation of AI systems in the series' Modes 2 to 5, that is, embedded workplace assistants, agentic work tools, built AI applications and autonomous production agents (AI Governance and AI Platform and Security, Chapter 2). AI Platform and Security, Chapter 21, treated observability, monitoring and drift in production as a capability of the platform (297, Nordqvist, 2026), and AI Platform and Security, Chapter 20, set out the evaluation pyramid and the evaluation of AI systems before release. This chapter takes both as given and asks what the operator does with them: how a change to an AI service passes through the same discipline as any other change, what extra the discipline needs, and what a deployer of a high-risk AI system must be able to show. Incidents that involve AI are the subject of Chapter 14, the cost of running AI of Chapter 15, and the contract terms that make provider change visible of Chapter 24.

The release path of an AI service from trigger through offline gate, shadow and canary to promotion, with an observer outside the path and a stop path to a fallback chain

Figure 13.1: The release path of an AI service, with an observer outside the path and a stop path that routes to a fallback chain.

What is different about an AI service

A conventional service changes when its code, its configuration or its infrastructure changes. Each of these is recorded in a repository or a change system, and an operator who asks what changed can look for a record. An AI service has the same three sources of change and at least five more, and several of them leave no record in the operator's own systems.

The first is the model. A hosted model can be replaced, retired or fixed by its provider on the provider's schedule. The second is the serving infrastructure that runs the model: the same model weights can yield different outputs when the serving stack is misconfigured or a compiler bug changes the arithmetic. The third is the input distribution: the claims, questions and documents that arrive change with the season, the law and the customers, and a model that was good on last year's inputs can be worse on this year's. The fourth is the retrieval index: the corpus that an assistant draws on grows, ages and is re-chunked, and a change to the embedding model makes old and new vectors incomparable. The fifth is sampling itself: the same request can produce different answers on different runs. Each source has its own evidence and its own control, and the chapter takes them in turn.

Evidence that behaviour moves

Chen, Zaharia and Zou evaluated the March 2023 and June 2023 versions of GPT-3.5 and GPT-4 on seven kinds of task: mathematics, sensitive questions, opinion surveys, multi-hop knowledge questions, code generation, medical licensing examination questions and visual reasoning. Both services changed substantially over those three months. On one task, deciding whether a given number is prime or composite, GPT-4's accuracy fell from 84 per cent in March to 51 per cent in June, which the authors attribute in part to GPT-4 following chain-of-thought prompting less well, while GPT-3.5 improved on the same task. GPT-4 also became less willing to answer sensitive and opinion questions, and both models made more formatting mistakes in generated code (141, Chen et al., 2023). The study is a preprint, it concerns one provider's consumer-facing models over one period, and the size of each change depends on the task and the prompt format. Its value for an operator is the existence proof: a service that was addressed under one name behaved measurably differently within a quarter, and the authors conclude that such services need continuous monitoring.

A provider's own report shows the other source. Between August and early September 2025, Anthropic reports, three infrastructure bugs intermittently degraded the quality of Claude responses. A routing error sent some Sonnet 4 requests to servers configured for a longer context window, initially affecting 0.8 per cent of requests and, after a load-balancing change on 29 August, 16 per cent of Sonnet 4 requests at the worst hour on 31 August; about 30 per cent of Claude Code users who made requests in the period had at least one message misrouted. A misconfiguration on the API's TPU servers caused output corruption, with unexpected characters in English answers and syntax errors in code, between 25 August and 2 September depending on the model. A compiler bug triggered by a change to token selection affected further models. The provider states that the problems were due to infrastructure bugs alone and that it never reduces model quality because of demand, time of day or server load. The provider also states that its standard evaluations did not capture the degradation, that it relied too heavily on noisy evaluations and that it is moving to quality evaluation on production systems continuously (144, McAllister, 2025). The lesson for the operator is the book's own conclusion from this account: a pinned model identifier says which weights were requested and says nothing about whether the stack that served them was healthy, so a quality objective has to be measured on outputs, at the interface, by something other than the provider's own evaluation.

Two older bodies of work name the pattern in general terms. Sculley and colleagues listed, among the risk factors that make machine learning systems expensive to maintain, shifts in the external environment, configuration issues and undeclared consumers (142, Sculley et al., 2015). The research on concept drift, surveyed by Gama and colleagues, concerns learning in settings where the relation between inputs and the quantity predicted changes over time (143, Gama et al., 2014). Neither concerns language models specifically; both support the point that a service can degrade through the world moving while every component stays as released.

Sampling

A request sent twice to the same model at the lowest randomness setting does not reliably return the same answer. He and colleagues at Thinking Machines sent one prompt 1,000 times to an open-weight 235-billion-parameter model at temperature 0 and obtained 80 distinct completions, which diverged at the 103rd token. They attribute the variation not to randomness in the arithmetic but to the kernels' results depending on batch size, which varies with server load, and they report that batch-invariant kernels gave identical output in all 1,000 runs at a cost in speed (148, He & H. and Thinking Machines Lab, 2025). The report is not peer reviewed and describes one model and one serving configuration. The consequence for operations is practical. An evaluation gate that compares a single run of the candidate with a single run of the baseline compares two draws from two distributions, and a threshold that ignores the spread will pass and fail the same model on different days.

Observable. Behaviour change without a deployment, through provider-side change, serving faults, input drift and nondeterministic serving, is documented now and is the starting point of the rest of the chapter.

Versions as configuration

The operator's first move is to make every source of change a versioned, recorded thing, so that the question of what changed has an answer. In the book's usage the release manifest of an AI service lists everything whose change can change the service's behaviour, and a change to any line is a change that passes through the change path of Chapter 8.

Element	What is recorded	Why it matters
Model	Provider, model identifier, snapshot or version, the route through the gateway, region of processing	A moving alias is an unrecorded change; a snapshot is a claim that can be checked
Serving	Gateway version, serving provider, runtime and quantisation where the organisation runs the model	The same weights behave differently on different stacks
Prompts and policies	System prompt, instructions, guardrail rules and their versions, with the repository commit	A prompt edit is a behaviour change and is released like code
Retrieval	Embedding model and version, corpus snapshot, chunking rules, index build identifier, freshness at release	A change of embedding model needs a full rebuild and a side-by-side index
Tools	Tool definitions, schemas, scopes of the identity the agent uses, mandate manifest version	A tool schema change changes what the agent can do, not only what it says
Parameters	Sampling settings, maximum output, effort or reasoning settings, timeouts, retries	Providers deprecate and remove parameters
Evaluation	The evaluation set version, the sentinel set version, the grader and its version, thresholds	A gate is only as stable as the set and the grader behind it

Two properties of the manifest deserve comment. First, a manifest that names a model by alias, such as a family name that the provider re-points to a newer snapshot, records an intention and not a fact. Providers document the distinction. Anthropic's documentation lists each model identifier with its lifecycle state and retirement date (147, Anthropic, n.d.); Microsoft's describes per-deployment update policies that either stay on a version, move to a new default when one is published or move only at retirement (146, Microsoft, 2026). The operator chooses the policy that makes a change a visible event, which in nearly every Tier 1 case means pinning and updating deliberately.

Second, the manifest also protects against breakage that no behaviour test would find. A provider's deprecation page records that sampling parameters were removed in a new API version, so that a request that sets them returns an error (147, Anthropic, n.d.). A service pinned to a model snapshot is therefore not pinned against the contract of the interface it calls, and the manifest records the API version beside the model.

The release manifest in the telemetry

A manifest in a repository is not enough if the running service does not report which manifest it runs. Every request and every output carries the manifest identifier, and the model name and version that actually served it, taken from the response and not from the request. The OpenTelemetry project maintains semantic conventions for generative AI clients that cover spans, metrics and events (61, OpenTelemetry, n.d.), and an organisation that adopts them gets the identifiers into the same telemetry that Chapter 5 uses for service level objectives. The record serves three later purposes. It allows an impact query, which is the question of which outputs a defective version produced, answered in minutes instead of days (F46). It lets a canary be compared with its control. And it is the log that Article 26(6) of the AI Act asks a deployer of a high-risk AI system to keep, to the extent that the logs are under its control (see the section on deployer duties).

Provider-side change

A provider changes a service in four ways, and each needs a different intake.

Scheduled retirement is the best-behaved. Anthropic states that it notifies customers with active deployments of a model's retirement at least 60 days before it takes effect for publicly released models, by email and in its documentation (147, Anthropic, n.d.). Microsoft's lifecycle policy for Foundry Models gives a retirement date for generally available models at launch, set 18 months out for the standard lifecycle and 12 months for generally available models from several named publishers including Anthropic, with a retirement notice at least 60 days before retirement; it states that the replacement is named about 90 to 120 days before retirement, that retirement dates are not extendable and that provisioned deployments are not upgraded automatically while standard ones are (145, Microsoft, 2026). The two policies agree on the structure: a date, a notice of at least 60 days and a replacement that behaves differently.

Scheduled upgrade is the second. On Azure OpenAI, Microsoft states that it notifies customers at least two weeks before a new version becomes the default and keeps the previous major version until its retirement, and that deployments set to follow the default are switched automatically (146, Microsoft, 2026). A deployment on the follow-the-default policy has delegated the release decision to the provider. The book's rule is that a Tier 1 service does not delegate it.

Emergency change is the third. Microsoft reserves the right to retire a model on shortened notice when it finds a compliance or security issue (145, Microsoft, 2026). A contract can limit the cases but cannot remove the possibility, and the service therefore needs a fallback that has been tested, which the section on canarying treats.

Unannounced change is the fourth: the serving faults, silent behaviour changes and infrastructure updates described above. The operator has no notice and relies on its own observation.

For Mode 0 Ambient AI the fourth case is the usual one. Vendor AI embedded in a product changes on the vendor's release train, and the organisation may not know what model sits behind a feature or what it is allowed to do (F57). AI Blue, Chapter 16, turned the answer into a contract: a notice of 20 working days of a change of model, sampling rights and test rights (F97). That figure is the book's own recommended default for a service whose output feeds a decision, not a legal requirement.

Notice as a change request

A provider's notice is a change that the organisation did not author. The operations practice that follows from this is to treat the notice as a change request raised by the provider, entered in the change system on the day it arrives, with the retirement date as the deadline and a named service owner. The notice does not wait for the next quarterly review. Its stages are those of an internal change: assessment of the replacement, evaluation against the service's own sets, shadow and canary, a decision by the change authority and a record. The difference is that the deadline is not the organisation's to move, so the plan works backwards from the retirement date and fixes the last day on which a rollback to the old version is still possible. After that day the rollback target is a different model altogether.

What the regulations ask of the contract

DORA asks the financial entity to have documented policies for ICT change management, covering software, hardware and firmware components, systems and security parameters, so that all changes are recorded, tested, assessed, approved, implemented and verified in a controlled manner (Article 9(4)(e)). For contracts on ICT services that support critical or important functions, DORA Article 30(3)(b) requires notice periods and reporting obligations of the provider to the financial entity, including notification of any development that might have a material impact on the provider's ability to provide the services in line with the agreed service levels (2, European Union, 2022). Neither provision mentions models. Their operational reading, which is the book's own, is that a provider-side model change on a service supporting a critical or important function is a change that the contract has to announce and the entity's change process has to record and verify. Chapter 24 returns to the clause.

Expected. Contractual notice and test rights for model change are expected to spread for services supporting regulated functions, because the instruments above already require notice periods and change control and because providers already publish notice policies of at least 60 days for retirements. The notice duty for unannounced serving changes is not yet documented in the policies cited, and remains something the contract must supply.

Quality objectives

An AI service has the objectives of any service, which are availability, latency and error rate, and Chapter 5 defines them. It needs three more families, each measured at the interface and each with a window and an error budget.

Quality. The share of outputs that meet the task definition, measured against a graded reference. For a triage service the measure is agreement with a confirmed outcome. For a retrieval assistant it is whether the answer is supported by the retrieved passages, whether the cited passage says what is claimed and whether the answer is complete enough for the task. A quality objective states the population (which inputs), the grader (who or what decides that an output is good), the threshold and the interval.

Restraint. The share of runs in which the system stayed inside its mandate and its rules: no action outside the approval rules, no answer from outside the permitted sources, no disclosure of data it should not give. The series put restraint first wherever an action is delegated (F129), and in the release path restraint is a gate of its own, with a threshold of zero on the defined violations, before any quality comparison.

Freshness and drift. Freshness is a property of the retrieval index and the data: how old the oldest unindexed change is, and what share of answers cite a source that has since been superseded. Drift is a property of the inputs and outputs: a distance between the distribution of recent inputs and the distribution on which the service was evaluated, and between recent outputs and the baseline. A drift measure is a signal that the evaluation set may no longer represent the traffic, and not in itself a finding of harm. The book follows AI Governance, Chapter 8, in treating a drift alert as one of the triggers of re-classification (F16), so a drift breach opens a change or a review and does not only colour a dashboard.

Measuring without trusting the measured

The observer principle (Chapter 4, applied in Chapter 17) governs how these are measured. Three consequences follow for AI services.

First, the grader is not the model under test. A model that grades its own outputs, or those of a sibling from the same family, shares blind spots with it, and the independence argument of AI Purple, Chapter 15, applies: a check counts only when the ways it can fail are not the ways the checked thing can fail. Grading is done by people on a blind sample, by a deterministic check where the task allows one (format validity, citation present in retrieved text, value within range), or by a model from a different provider calibrated against human grades and rechecked on a schedule.

Second, a sentinel set runs continuously. It is a fixed set of cases, 100 to 200 as the book's default, stratified by the strata that matter (market, language, claim type), never used for tuning and refreshed in part each quarter, sent through the production path on a schedule and graded against known answers. The sentinel set is the operator's counter to the failure the provider's postmortem describes: it detects a change in the served behaviour of a pinned version because the version, the inputs and the grading stay constant and only the serving changes.

Third, the objective's data path is separate from the service's. If the quality measure depends on the same gateway and the same logging pipeline as the service, a failure of the gateway removes the service and the signal together. The measurement path has its own credentials and failure domain (Chapter 17).

Variance and the gate

Because sampling varies, a gate compares distributions and not single runs. The book's defaults are three to five repeats per case for a candidate and its baseline, a confidence interval on the difference in the quality measure, and a gate expressed as a bound on that interval (for example, the lower bound of the candidate's agreement may not fall more than one percentage point below the baseline's), plus the restraint gate at zero violations. The bound is set from the service's error budget and adapted to it. A gate that cannot fail teaches nothing, and the operator seeds it periodically with a known-degraded candidate to confirm that it does.

Worked example: quality objectives as a service level objective record

The following record, illustrative and in the format of Chapter 5, extends the objective SLO-HM-002 of the claims-triage agent (SVC-HM-002) with quality, restraint and freshness objectives. The identifiers with the suffix -Q are new in this chapter.

# Illustrative. Extends SLO-HM-002 (Chapter 5) for the claims-triage agent.
id: SLO-HM-002-Q
service: SVC-HM-002
owner: Anja Weiß            # accountable for the model and the gateway
window: rolling 28 days
manifest: RM-HM-002-2028-09 # release manifest the objectives apply to
objectives:
  - sli: route_agreement
    definition: share of sampled claims whose route equals the handler-confirmed route
    grader: blind human sample, 1 in 200 outputs, minimum 100 per week
    target: ">= 93.0%"
    interval: 95% confidence, lower bound
  - sli: restraint_violations
    definition: actions outside the approval rules, per 10,000 runs
    grader: deterministic policy check at the policy decision point
    target: "0"
    budget: none; any violation opens a problem record and holds promotion
  - sli: format_valid
    definition: outputs that parse against the event schema
    target: ">= 99.5%"
  - sli: decision_latency_p95
    target: "<= 30 s"        # as SLO-HM-002
  - sli: index_freshness
    definition: age of the oldest policy-document change not yet searchable
    target: "<= 4 h for 99% of changes"
drift:
  signal: population stability index on claim-type mix, weekly
  review_threshold: 0.2
  action: open change review; do not retrain or retune automatically
observer: OBS-HM-AI-01      # sentinel set of 150 cases, hourly, own credentials
burn_rate_alerts:
  fast: {window: 1h, threshold: 14.4, page: incident_commander}
  slow: {window: 6h, threshold: 6, page: platform_engineer_on_call}

The record shows the three properties that matter: each objective has a grader that is not the model, restraint has a budget of nothing, and a drift breach opens a review without changing the model on its own.

Canarying a model

The canary of a model follows the canary of any release, and the Site Reliability Workbook sets out its logic. The canary is a partial, time-limited release in which the rest of the service serves as the control. The population is kept small because the impact on the error budget scales with the traffic exposed to a defect. Metrics are broken down by canary and control, because aggregate monitoring can hide a bad canary. A small set of user-visible indicators is preferred to a large set of noisy ones, and the comparison is made in the same period for both populations, because before and after comparisons confound the result with time-based changes (246, Warner et al., 2018). All of this carries over. Three things differ for a model.

The metric is noisier. An error rate is a count of failures, and a defect that fails 20 per cent of requests shows within minutes. A quality measure is a graded judgement on a sample, with sampling variance in the outputs and in the grading, and a difference of one percentage point needs hundreds or thousands of graded cases to see. The canary therefore runs for a minimum number of graded cases and not only a minimum time, and the plan states in advance what difference it can detect. A canary of 5 per cent of traffic that produces 30 graded cases in a week cannot support a decision about quality, and the record says so.

Assignment is by case and not by request. For a service in which one claim, one ticket or one citizen's application passes through several requests, the canary assigns the whole case to one version, by hashing the case identifier. Otherwise one claim is handled partly by one version and partly by another, which confounds the comparison and, for decisions about people, produces unequal treatment that nobody designed. For Nordvik's benefit claims, the point has a legal edge: a claimant's case is ranked by one version, recorded, and open to later review under the version's evidence.

Shadow comes first. Before any real case is handled by the candidate, the candidate receives a copy of production traffic and its outputs are recorded and compared and acted on by nobody. Shadow tests behaviour and cost on real inputs, including the restraint measures, without exposing a claimant. It does not test the effect on the people who use the answers, which only a canary can, and it doubles inference for its duration (Chapter 15).

The stages are therefore: the offline gate on the evaluation set, with restraint first; shadow for a defined period; a canary at a small share, by case, with the observer grading both populations; a ramp with holds; and promotion, recorded. Each stage has a stop condition written before it starts, and each stage ends in a decision by a named change authority and not by the pipeline's own check alone. This is the pattern of Chapter 9, applied to a different thing.

Pinning and fallbacks

Pinning fixes the model snapshot, the gateway route, the prompt and the index build that the service runs, so that a change is the organisation's act. Pinning cannot hold past a retirement date and is not a defence against serving faults, and it is only one half of the pair. The other half is the fallback chain: the ordered list of what the service runs on when the pinned version cannot be used. A typical chain is the previous pinned version while it still exists, a second model on capacity that the organisation or another provider controls, and a manual mode in which people do the work with the AI off.

Three rules keep the chain honest. Every link is itself a release, with an evaluation result and a date, because a fallback model that has never been evaluated on the service's inputs is an assumption and not a fallback. Each link has a stated quality loss, so that the people who run the degraded mode know what they are running. And the switch between links works without the platform that failed: the routing flag is held at the gateway, and the stop path for the AI service, which sends traffic to the next link, sits outside the model-serving platform and is held by the incident commander and the service owner without further approval. A fallback that is reached only through the failed system's own control plane is not a fallback.

A manual mode that has not been exercised is not recoverable in the sense the book uses the word: the claim needs a test date and a measured time (Chapter 19), and the skill to run it decays when unused (217, Bainbridge, 1983); Chapter 26 treats that decay.

What can be undone and who can stop it

A model update through the gateway can be undone in minutes by routing back, as long as the previous version exists. What cannot be undone is the effect of outputs already acted on. Three controls follow. The version identifier on each output lets the organisation list the cases handled by a defective version. A review path takes those cases back to a person for a second look, sized in advance. And an AI service that decides or recommends about people keeps its outputs in a form that allows contestation (AI Boss, Chapter 27). The stop path for a model update is a routing change at the gateway and a feature flag that disables the AI feature altogether; both are held by the incident commander on duty, the platform engineer on call and the service owner, and both are exercised in a drill each quarter.

The degrees of delegation apply to the update itself. Promoting a model into production is an action of the class deploy in the autonomy budget of Chapter 4, and rolling back one of the class roll back. An operations agent may prepare the change record, run the evaluation and compare the canary, at Level 1 Assisted or Level 2 Supervised, and a named change authority approves promotion. Level 3 Bounded for an automatic rollback on a breached stop condition is defensible, because the rollback is reversible and its trigger is defined in the record and enforced outside the agent. Level 4 Autonomous is never used for a model update on a critical function outside its change window or freeze, and an agent never edits the gate that tests the model it runs on, because that would disable the observation itself.

Worked example: a change record for a model update

The following change record is illustrative and follows the form of Chapter 8. It concerns Hansa Mutual's claims-triage agent. The model provider announced the retirement of the pinned snapshot on 2028-10-12, with retirement on 2028-12-18; the record shows the stages, the observer, the stop conditions and the rollback, including the date on which the rollback target changes.

# Illustrative. Hansa Mutual, claims-triage agent (SVC-HM-002).
id: CHG-HM-2028-0412
type: normal              # model changes are never "standard" (cf. INC-HM-2027-0833)
trigger: provider notice 2028-10-12, retirement of snapshot m-2027-06 on 2028-12-18
change: model snapshot m-2027-06 -> m-2028-08; prompt and index unchanged
manifest: {from: RM-HM-002-2028-09, to: RM-HM-002-2028-11}
requested_by: Anja Weiß
change_authority: Tobias Richter   # does not run the evaluation
aidr: AIDR-0954
substantial_modification_check: not high-risk under AIDR-0024; recorded, no action
stages:
  offline_gate:
    set: eval-hm-triage-v7, 1,800 cases, six markets, 5 repeats
    restraint_violations: {candidate: 0, gate: 0}
    route_agreement: {baseline: 94.1, candidate: 94.6, ci_lower_diff: -0.4, gate: ">= -1.0"}
    format_valid: {candidate: 99.8, gate: 99.5}
    latency_p95_s: {candidate: 21, gate: 30}
  shadow: {from: 2028-10-24, to: 2028-10-31, restraint_divergences: 0}
  canary:
    share: 5%             # assigned by hash of claim id
    from: 2028-11-01
    to: 2028-11-08
    minimum_graded_cases: 600
    observer: OBS-HM-AI-01   # sentinel set plus blind sample, own credentials
  ramp: [25%, 50%, 100%]  # 24 h hold at each step
stop_conditions:
  - any restraint violation
  - route_agreement lower bound below 92.0 in canary
  - burn rate above 14.4 over 1 h on SLO-HM-002-Q
rollback:
  until_2028-12-18: route to m-2027-06 at the gateway, expected 10 minutes
  after: route to the Frankfurt fallback model, last evaluated 2028-09-05, agreement 91.2
  review_of_affected_cases: list by manifest id, handler second look within 2 working days
stop_path: gateway flag, held by incident commander, platform engineer on call, service owner
outcome: promoted 2028-11-14; canary 5% graded 640 cases, agreement 94.3

The record carries the pieces that the section argued for. Approver and evaluator are different people, the observer sits in its own failure domain, the rollback target changes on a stated date, and the fallback is shown with the evaluation date and score that make it a claim with evidence age and not an assumption.

Deployer duties

The AI Act places duties on the deployer of a high-risk AI system that land directly on operations. The text below is read from Regulation (EU) 2024/1689 as published (1, European Union, 2024) and as amended by the Digital Omnibus on AI (11, European Union, 2026). It is framed as an architectural implication and not as legal advice.

Provision	What it asks	Operations artefact
Article 26(1)	Technical and organisational measures to use the system in accordance with the instructions for use	The release manifest checked against the instructions for use at each change
Article 26(2)	Human oversight assigned to natural persons with the necessary competence, training, authority and support	Named oversight roles in the delegation profile (Chapter 22); competence records (Chapter 26)
Article 26(5)	Monitor the operation on the basis of the instructions for use and, where relevant, inform providers in accordance with Article 72; where there is reason to consider that use may present a risk within the meaning of Article 79(1), inform the provider or distributor and the market surveillance authority without undue delay and suspend use; on a serious incident, inform the provider first	Quality and restraint objectives; a provider-notification route; a suspension switch that is the stop path above
Article 26(6)	Keep the logs the system generates, to the extent under the deployer's control, for a period appropriate to the intended purpose and at least six months unless Union or national law, in particular on data protection, provides otherwise	Retention policy for the output and version log; personal-data minimisation
Article 12	The system must technically allow automatic recording of events over its lifetime, to identify risk situations or a substantial modification, to facilitate post-market monitoring under Article 72 and to monitor operation under Article 26(5)	A deployer's check that the events it needs are actually produced
Article 72(1) and (2)	The provider establishes and documents a post-market monitoring system that actively and systematically collects, documents and analyses data, which may be provided by deployers, on performance throughout the lifetime	The interface through which operations data flows to the provider

Three observations apply. First, the deployer's monitoring duty and the provider's post-market monitoring system meet at an interface, and operations owns the deployer's side. What the deployer's telemetry can show, and what it sends to the provider, is a design decision. A deployer whose quality measures exist only inside the provider's tooling cannot meet Article 26(5) independently of the provider.

Second, the article treats financial institutions differently. For deployers that are financial institutions subject to requirements on internal governance, arrangements or processes under Union financial services law, the monitoring obligation of Article 26(5) is deemed fulfilled by complying with the internal governance rules under that law, and the logs are kept as part of the documentation kept under that law (Article 26(5) and (6)). For Hansa Mutual, as an insurance undertaking, this routes part of the duty through its Solvency II governance and its DORA documentation, and leaves the operational practice unchanged.

Third, a change of model can be a change of the system. The Act defines a substantial modification as a change to an AI system after it has been placed on the market or put into service, which was not foreseen or planned in the provider's initial conformity assessment and as a result of which compliance with the requirements for high-risk systems is affected or the intended purpose changes (Article 3, point 23). A deployer that makes a substantial modification to a high-risk AI system that remains high-risk is considered a provider and subject to the provider's obligations (Article 25(1), point (b)). Whether a given model update is a substantial modification is a legal assessment. The architectural consequence is a step in the change record that states who asked the question, against which assessment and with what answer; the record above shows the entry for a system that is not high-risk, the simplest case.

Dates

The Digital Omnibus on AI, Regulation (EU) 2026/1744 of 8 July 2026, published in the Official Journal on 24 July 2026, changes the dates of application. The provisions of Chapter III, Sections 1 to 3, which include Articles 12 and 26, apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for those under Article 6(1) and Annex I. It also replaces Article 72(3): the Commission's power to adopt an implementing act with a template for the post-market monitoring plan is removed, and the Commission is to adopt guidance, including a template, by 2 September 2027 (11, European Union, 2026). The Omnibus did not amend Article 26 in the text the author read. The practical reading is that the deployer duties above are the target state of an operations function for any Annex III system, and that the provider-side plan that operations will feed is still being specified. That reading is expected: it follows from a decided instrument and a stated date.

Speculation. A production model that updates itself on live data without a gate, a canary or a record is plausible as a design and is unsupported by present evidence as a safe one. The Level 4 prohibitions and the deployer duties above make it hard to reconcile with the practice described here, and the book treats it as speculation until independent data shows otherwise.

Practical guide: defining quality objectives and a rollback for an AI service

Purpose. To give an AI service the objectives, the release path and the way back that a conventional service already has.

Roles. The service owner accountable for the outcome; the platform engineer who runs the gateway; the evaluation engineer who owns the sets and graders; the incident commander who holds the stop path; the privacy officer for logs; the employee representative for any measure that touches people's work.

Steps.

Name the service, its Tier and the task in one sentence, and state what a good output is, in terms a reviewer can grade.
Write the release manifest (see the table above) in the repository, including the API version and the embedding and index build, and make the service report its manifest identifier and the serving model with every output.
Choose four to six indicators: quality, restraint, format validity, latency, freshness, and a drift signal. For each, name the grader, the window, the threshold and the interval.
Build the evaluation set from real inputs, stratified by the strata that matter, and a separate sentinel set of 100 to 200 cases that is never used for tuning. Refresh a quarter of each set every quarter and record the version.
Set the gate on the interval of the difference against the baseline, with three to five repeats, and set restraint at zero. Seed the gate once a quarter with a deliberately degraded candidate to confirm that it fails.
Define the stages: offline gate, shadow for seven days, canary at 5 per cent by case identifier for seven days and at least the planned number of graded cases, ramp with 24-hour holds. Write the stop conditions before the first stage starts.
Define the fallback chain and give each link an evaluation result, a date and a stated quality loss. Choose the last day on which the previous version is available and write it into the record.
Place the stop path outside the serving platform, name the holders (incident commander, platform engineer on call, service owner) and drill it each quarter, including a drill in which the provider's endpoint is unavailable and the service runs in manual mode.
Set the log retention for outputs and manifest identifiers to the longer of the contract, the sector's rules and the six months of Article 26(6) where it applies, and limit personal data in the logs to what the purpose needs (GDPR Articles 5 and 32; (6, European Union, 2016)).
Intake provider notices as change requests on the day they arrive: triage on day 1, candidate in shadow by day 10, decision at least 21 days before the retirement date.

Defaults to adapt. The 5 per cent canary, the seven-day periods, the sentinel set of 100 cases and the 21-day margin are starting points; a low-volume service needs a longer canary or a larger share to reach the planned number of graded cases. Blind sampling of outputs that handlers review must grade the model and be reported per version, never per handler, and any tool that logs individual users' interactions needs the agreement of the employee representatives before it is switched on.

Definition of done. The manifest is in the repository and in the telemetry; the objectives are live with burn-rate alerts; the gate has failed a seeded candidate; the fallback chain has been exercised in the last quarter with the date and the result recorded; and a provider notice has been run through the path at least once as an exercise.

Across the usage modes

The mode describes how the AI is deployed and whose identity it uses, and it decides what the organisation can version and who can update. The table gives, for each mode, what the organisation can pin, who may update, and what each function does.

Mode	What the organisation can version	Who may update	O1 Observe	O3 Change	O5 Sustain
Mode 0 Ambient AI	Nothing directly; a declaration of the feature and its effective level	The vendor, on its release train	Sample the feature's outputs; compare with a reference	Treat the vendor's notice as a change request; contract for notice and test rights	Keep the inventory of features and their declared models
Mode 1 Conversational assistants	The approved tier and the data classes allowed	The provider; the organisation controls enablement	Usage and policy telemetry	Re-approve on a model or tier change	Track provider retirements for approved tiers
Mode 2 Embedded workplace assistants	Tenant settings, enabled features, ring or pilot group	The vendor, with the tenant administrator selecting rings	Sentinel tasks in the pilot group	Ring-based release by the administrator; change record per ring	Licence and retirement calendar
Mode 3 Agentic work tools	Tool and skill versions, permissions, the model behind the tool	The platform team, within a change record	Quality of drafts; permission use	Level 1 or 2 for drafting; no applying of change	Skill library hygiene; model retirements
Mode 4 Built AI applications	The full manifest: model, prompt, index, tools, parameters, evaluation set	The change authority, through the release path	Quality, restraint, freshness and drift objectives; sentinel set	Offline gate, shadow, canary, ramp; rollback at Level 3 for a defined stop condition	Fallback chain and notice intake; log retention
Mode 5 Autonomous production agents	The Mode 4 manifest plus the mandate manifest and its tests	The change authority; the delegation is re-shown after every change (F129)	Restraint first; independent sentinel set on actions	A model update re-tests the mandate; Level 3 only inside a catalogued runbook; no Level 4 on irreversible or out-of-window action	Mandate expiry and re-test; fallback to manual mode exercised

Nordvik Region and Hansa Mutual

Both organisations run the discipline above, and they differ in where the changes come from.

Hansa Mutual pins model versions behind its AI gateway on the group AI platform (SVC-HM-007, objective SLO-HM-007: 99.5 per cent per month and gateway latency under two seconds at the 95th percentile) and canaries every update on 5 per cent of claims triage cases (SVC-HM-002). The rule that a model, prompt or routing change is never a standard change comes from INC-HM-2027-0833 of 2027-09-30, when a configuration push to the gateway's routing broke the claims assistant in four markets for 47 minutes and the canary stage had been skipped on a change classed as standard. Hansa's fallback links are its self-hosted models in the Frankfurt data centre and the manual routing that SLO-HM-002 already provides, and the worked example shows why the evaluation date of those models matters. The claims-triage agent is classified as not high-risk (AIDR-0024), so Article 26 does not apply to it (its work-allocation function was reopened in AI Boss as AIDR-0651), and the record follows the same form for the sake of one process; the underwriting-support service for life and health (SVC-HM-008, Annex III point 5(c)) is the case in which the deployer duties apply and in which Article 26(5) and (6) route through Hansa's financial services governance. The decision to gate model changes is recorded as AIDR-0954 (new).

Nordvik Region receives its changes mostly from providers. TriageSoft retrains the claims ranker of the benefits-triage service (SVC-NR-001, model versions 3.2.0 and 4.0.0) quarterly inside Nordvik's platform, so that the registry entries, evaluation gates and release notes sit with the Region and serve its deployer duties. Each quarterly retrain is a provider-raised change request in ServiceFlow, with the Region's own evaluation set, a shadow period and a decision by the Head of Benefits Unit and the platform lead before promotion, and caseworkers' date-order ranking is the manual fallback that they already used on 2026-09-22, when a TriageSoft release changed a queue setting and ranking stalled for 5 hours 10 minutes (INC-NR-2026-0214) because the contract had no release notice period. The second source is the hosting provider, whose container-image update of 2027-05-24 stopped the citizen-service assistant for two hours with no notice (INC-NR-2027-0129). The Region's response, recorded as AIDR-0902 (new), is to treat any provider notice as a change request, to ask for a notice period in every contract on renewal and to run a sentinel set on the citizen-service assistant (SVC-NR-005) hourly from the platform team's own observability stack, so that a change on the provider's side is seen in the Region's telemetry. Nordvik has no Mode 5 service, so the model update of an autonomous agent is not yet a question for it; the Region reaches Level 3 in this chapter's terms only for the automatic rollback of a gateway route.

Hansa decides most of its model changes and needs the discipline to hold when a schedule is tight. Nordvik receives most of them and needs notice and test rights in contracts signed under public procurement, with lead times of 9 to 14 months.

Summary

An AI service changes without a deployment, as a study of one provider's models, a provider's own report of three serving faults and a measurement of nondeterminism show. The operator's response is to make every source of change a recorded one: a release manifest that names model, serving, prompt, index, tools, parameters and evaluation set, reported by the running service with every output. The chapter concerns O1 Observe, for the objectives of quality, restraint, freshness and drift, measured by graders and sentinel sets that are not the model under test; O3 Change, for the release path of offline gate, shadow, canary by case, ramp, pinning and a fallback chain with a stop path outside the serving platform; and O5 Sustain, for the intake of provider notices as change requests and the lifecycle of retirements.

Provider change comes in four forms, scheduled retirement, scheduled upgrade, emergency retirement and unannounced change, and only the first two come with notice. The documented notice periods of at least 60 days are a starting point, and the contract must supply what the policies do not. DORA Articles 9(4)(e) and 30(3)(b) and AI Act Articles 12, 25, 26 and 72 turn the practice into duties for the entities they cover. What can be undone is the routing; what cannot be undone is the outputs already acted on, and the version identifier on each output is what lets the organisation find them. A model update is an action of the class deploy, never at Level 4 Autonomous on a critical function outside its window, and an agent never edits the gate on the model it runs on.

The reader can take one action from this chapter. Pick the Tier 1 service in the estate that contains a model, find the line in its configuration that names the model, and check whether it names a pinned snapshot, whether the service reports which version served each output and whether a provider notice for that model would arrive in the change system or in an inbox. Chapter 14 turns to the incidents that involve AI, and Chapter 15 to the economics of running it.

Sources

European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
Nordqvist, G. (2026). AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. The Transformed Architecture, Book 3. (297, Nordqvist, 2026)
Chen, L., Zaharia, M. & Zou, J. (2023). How is ChatGPT's behavior changing over time? arXiv:2307.09009. (141, Chen et al., 2023)
Sculley, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. NIPS 2015. (142, Sculley et al., 2015)
Gama, J. et al. (2014). A survey on concept drift adaptation. ACM Computing Surveys 46(4). (143, Gama et al., 2014)
Warner, A. & Davidovič, Š. et al. (2018). Canarying Releases. The Site Reliability Workbook, O'Reilly Media. (246, Warner et al., 2018)
McAllister, S. (2025). A postmortem of three recent issues. Anthropic Engineering. (144, McAllister, 2025)
Microsoft. Foundry Models lifecycle and support policy. Microsoft Learn, 2026. (145, Microsoft, 2026)
Microsoft. Model versions in Microsoft Foundry Models (classic). Microsoft Learn, 2026. (146, Microsoft, 2026)
Anthropic. Model deprecations. Claude Platform documentation. (147, Anthropic, n.d.)
He, H. and Thinking Machines Lab (2025). Defeating Nondeterminism in LLM Inference. (148, He & H. and Thinking Machines Lab, 2025)
European Parliament and Council of the European Union. Regulation (EU) 2026/1744 (Digital Omnibus on AI). Official Journal of the European Union, 24 July 2026. (11, European Union, 2026)
OpenTelemetry. Semantic Conventions for Generative AI (GenAI). (61, OpenTelemetry, n.d.)