Blog Details

Six months after launch, the AI is not performing like it did on day one. The finger-pointing begins. You think the vendor sold you something that quietly fell apart. The vendor thinks you changed everything around the system and never told them. So whose fault is AI drift? The honest answer is that drift is nobody's fault and everybody's responsibility, and treating AI performance and optimisation as a shared duty is the only version of this that ends well.

Drift is not a defect. It is a property of how AI works. Models make decisions based on patterns in data, and when the data or the world changes, performance moves. Blaming someone for drift is like blaming the mechanic because your car needs servicing after ten thousand kilometres. The real question is not who caused it. It is who is accountable for catching and correcting it, and whether that was ever agreed in writing.

Why drift feels like betrayal

The emotional charge comes from a mismatch in expectations. The buyer heard a launch pitch and reasonably assumed the performance shown was the performance they would keep. The vendor knew that performance was a snapshot, not a guarantee, but did not always say so clearly. When the numbers slip, the buyer feels misled and the vendor feels blamed for physics. Both reactions are understandable. Neither is useful.

This is why the accountability conversation has to happen before launch, not after the first slip. If nobody owns post-launch performance, then by default nobody is watching it, and the system rots until someone notices at the worst possible time.

What the vendor should own

A responsible builder carries real obligations that do not end at handover.

• Honesty at the point of sale. Making clear that performance will drift and that maintenance is required, not optional.
• Building for observability. Shipping a system you can actually monitor, with the metrics and logging needed to spot decay early.
• A maintenance path. Offering a clear, priced way to keep the system healthy, rather than disappearing after the invoice clears.
• Fixing genuine defects. Drift is not a defect, but a model that was badly built or poorly fitted from the start is, and that sits with the vendor.

A vendor who sells a system as a one-time purchase with no mention of upkeep has not done their job, even if the code was fine on day one. Setting the wrong expectation is itself a failure.

What the client should own

Accountability runs both ways. The client controls the environment the system lives in, and that environment is usually what shifts.

• Telling the vendor when things change. New products, new processes, new data sources, new policies. The system cannot adapt to changes nobody communicates.
• Funding maintenance. Treating optimisation as a line item, not an unwelcome surprise. A system nobody pays to maintain will not be maintained.
• Giving feedback. Front-line staff see errors first. If that signal never reaches anyone, the drift stays invisible until it is expensive.
• Owning the decision to act. When a review says the system needs attention, someone on the business side has to authorise the work.

Clients who buy AI and then change everything around it in silence, while assuming the system will keep up on its own, are setting themselves up to be disappointed.

The contract is where this gets decided

Most drift disputes are really contract failures in disguise. If the agreement never defined who monitors performance, what the target is, how often it is reviewed, and who pays for corrections, then both sides are arguing about an expectation that was never written down. The fix is unglamorous but decisive: put post-launch performance in the scope from the beginning.

A healthy arrangement names the metrics that matter, sets a review cadence, defines what triggers action, and prices the maintenance. Structured AI performance and optimisation is simply this agreement made real: a standing loop where someone is clearly responsible for watching the numbers and someone is clearly responsible for acting on them.

A more useful question than blame

When performance drops, the productive question is not who is at fault. It is a sequence: what changed, when did it change, who noticed, and what do we do now. Teams that ask these questions fix the problem in days. Teams that ask whose fault it is spend those same days arguing while the system keeps drifting.

Blame is backward-looking and adversarial. It assumes a culprit exists. Drift has no culprit. It has a cause, and causes can be found and corrected by people working together rather than pointing at each other.

The partnership model that actually works

The best outcomes come from treating post-launch AI as a shared operating relationship, not a transaction that ended at delivery. The vendor brings the technical ability to diagnose and correct. The client brings knowledge of what changed in the business and the authority to act. Neither can keep the system healthy alone. This is the model we hold ourselves to at Freemansland, and across more than 500 clients since 2022 the pattern is clear: the engagements that stay healthy are the ones where accountability was shared and explicit from the start.

Early warning signs that drift is setting in

Because drift is quiet, the responsible move is to know its early signals and watch for them deliberately rather than waiting for a complaint. A few recurring tells:

• Staff quietly stop relying on the system. When the people closest to it start double-checking or working around it, they are telling you something the dashboard has not yet caught.
• The same category of error keeps recurring. One-off mistakes are noise. A pattern clustered around a particular topic or case type is drift with a return address.
• Performance is fine on old cases and poor on new ones. This split is the classic fingerprint of a system running on a world that has moved.
• Nobody can say how the system performed last month. If the answer is a shrug, you are not monitoring, and drift is free to accumulate unseen.

For a Singapore business, there is an extra reason to catch these early. A drifting system that quietly starts producing biased or incorrect outputs is not only a commercial problem, it can become a compliance and reputational one. Keeping performance under active review, with evidence, is part of using AI responsibly under frameworks like the PDPA and the national guidance on AI governance. Shared accountability is not only about protecting the return. It is about being able to show, at any moment, that someone is genuinely in charge of how the system behaves.

The businesses that handle drift gracefully are simply the ones that decided, in advance, who would look for it. That single decision converts an ugly surprise into a scheduled, unremarkable piece of maintenance. It also changes the tone of the relationship. When both sides have agreed who watches, who fixes, and who pays, a performance slip becomes a task to work through together rather than a grievance to litigate. The drift still happens. The argument does not.

The bottom line

Drift is not a scandal and it is not a bug. It is the normal behaviour of a system that lives in a changing world. Asking whose fault it is misses the point. Ask instead who is accountable for catching it, who is accountable for fixing it, and whether that was agreed before anyone signed. Get that right and drift becomes a routine maintenance event. Get it wrong and it becomes a relationship-ending argument nobody needed to have.

Talk to us before your AI starts to slip

If you are not sure whether your AI is still performing the way it did at launch, that uncertainty is itself the signal to check. Freemansland offers a free AI opportunity assessment where we give you an honest read on where AI helps, where it does not, and what it would take to keep a system sharp over time. No jargon, no obligation. Get in touch for your free assessment and we will come back within one working day.

Frequently Asked Questions

Is AI drift covered under a normal support warranty?

Usually not. A standard warranty covers defects, meaning things that were broken at delivery. Drift is the gradual decline that comes from a changing environment, which is expected behaviour rather than a fault. Ongoing performance is normally handled through a separate maintenance or optimisation arrangement, so it is worth clarifying this before you sign.

Can you prevent AI drift entirely?

No, and any vendor who promises otherwise is overselling. You cannot stop the world from changing, so you cannot stop performance from moving. What you can do is detect drift early through monitoring and correct it quickly through tuning or retraining, which keeps the impact small and manageable rather than sudden and costly.

Who should pay to fix AI drift?

It depends on what the contract says and what caused the slip. Genuine build defects sit with the vendor. Drift from a changing business environment is normal upkeep and is usually the client's responsibility to fund, ideally through a maintenance plan agreed in advance so it is never a surprise. Clear terms at the outset prevent most disputes.