The Drift Ledger: Contracting for AI Maintenance That Ages in Service

UK utilities, transport operators and manufacturers are no longer treating AI-assisted inspection and maintenance as a laboratory curiosity. Models now rank defects on overhead lines, flag anomalies in rotating equipment and prioritise repairs across distributed estates. The procurement exercise, however, often ends at the point where the real contractual risk begins. A model that performs well on commissioning day is not a fixed asset. It is a changing instrument, shaped by new sensor data, altered operating conditions and shifting failure signatures.

For asset managers, the question is not whether to buy AI maintenance tools. It is how to contract for them once the vendor’s model starts to age in service. That requires a drift ledger: a formal record of what the model was expected to do, how its performance will be observed, who holds the data needed to retrain it and how the organisation can reverse a decision when the evidence changes.

Drift is a condition, not a defect

Contracts often treat poor model performance as a warranty issue. In maintenance work, that framing is too narrow. Data drift occurs when the operating environment moves away from the training set: a new substation design, a changed camera angle, a replacement sensor fleet or a seasonal pattern the model has not seen. Concept drift is subtler. The relationship between the signal and the failure itself changes, so the model’s confident output no longer maps cleanly to the physical risk.

A UK distribution network operator answering to Ofgem cannot wait for a model to fail visibly before acting. Nor can a rail asset manager treat every false negative as a vendor defect when the underlying sensor estate has been modified. The contract needs to distinguish between defect, drift and scope change. Each carries a different remedy, cost allocation and evidence requirement.

Define material drift before it happens

The first clause to write is the definition. A useful drift clause should name the reference dataset, the performance metrics and the observation window. It should specify thresholds for false negatives and false positives, not merely aggregate accuracy. In maintenance, the cost of missing a defect is rarely symmetrical with the cost of an unnecessary inspection.

The clause should also define material model drift as a contractual event. That event might trigger a joint review, a retraining obligation, a price adjustment or a right to suspend automated decisions. Without a defined trigger, drift becomes a matter of opinion after a failure. With a defined trigger, both parties have a shared evidence base.

Asset managers should require a model performance schedule at signature. This schedule should record the baseline evaluation set, the accepted tolerance bands and the test conditions. It should also state how often the baseline will be refreshed and who signs off changes. A drift ledger is only credible if it can be audited against something stable.

Data rights after signature

AI maintenance contracts frequently grant the vendor access to operational data but leave the asset manager without the rights needed to verify or replace the model. That imbalance becomes acute when drift appears. The buyer needs access to training data, labels, feature definitions, model versions and evaluation sets. It also needs the right to use operational data for retraining, either directly or through a third party.

UK GDPR obligations must be addressed explicitly, particularly where inspection imagery or sensor data could identify individuals or reveal operational vulnerabilities. The contract should separate personal data from asset data, set retention periods and define lawful bases for processing. It should also restrict the vendor from reusing the asset manager’s data to improve models for competitors without clear permission and compensation.

Model escrow is not a complete answer, but it can support continuity. The agreement should specify what is deposited, how often it is updated and the circumstances in which the asset manager can access it. A static copy of model weights is of limited use without the associated feature pipeline, configuration and evaluation harness.

Retraining, rollback and human override

Retraining obligations should be trigger-based rather than calendar-based alone. A model that is retrained annually may still be wrong for six months after a sensor replacement. The contract should allocate responsibility for retraining, set validation standards and define who bears the cost when drift arises from buyer-side changes to the estate.

Reversibility matters as much as improvement. The asset manager should have a contractual right to roll back to a previous model version, to require human review of automated decisions and to operate a deterministic fallback where the model’s confidence falls below an agreed level. These are not signs of distrust. They are the operational controls that make AI-assisted maintenance insurable.

Insurers will increasingly ask for evidence of model governance, change control and human oversight. A contract that provides those records is more than a legal document. It is part of the asset management system.

A contract architecture for 2026

The practical answer is a set of schedules attached to the main agreement: a model performance schedule, a data rights schedule and a change control schedule. Together they should define drift triggers, evidence packs, review cadence, retraining duties, rollback rights and exit assistance. The main contract should give the buyer audit rights and a clear route to replace the model provider without losing access to the data needed to keep the asset safe.

None of this removes the need for engineering judgement. It simply places that judgement inside a contractual framework that expects the model to change. For UK asset managers, the vendor’s exit is not the only integration risk. The model’s ageing is the quieter one. The drift ledger is how it becomes visible, negotiable and reversible.