Drift

What Drift means

Drift is the slow slide in an AI tool’s output quality, access and rules once nobody is looking after it. The word describes a direction and not an event. Nothing breaks. A tool that was accurate at launch becomes a little less so, a permission granted for a pilot stays in place, a rule written in the first week no longer matches how the tool is used, and no single day is the day it went wrong.

That is why the site’s definition says unowned AI rarely fails loudly. A loud failure gets noticed and fixed. A slow one is noticed late, often by a customer, an auditor or an insurer, and by then the cause is months old.

The site’s short version is that an AI tool does not stay as it was installed. A review done at launch describes a tool that no longer exists in quite that form, so the checking has to keep moving because the tool does.

Why an AI Tool does not stay as it was installed

The ownership article draws a contrast that explains the whole term. A conventional piece of software does what it did on the day it was set up until somebody changes it. An AI tool keeps moving, for four reasons the article names:

• the vendor updates the model behind it, sometimes without an announcement that reaches the people using it;
• the documents it draws on change;
• new features switch on;
• staff discover uses that nobody planned.

Any one of these can change what the tool does. A review carried out at launch then describes a tool that no longer exists in quite that form. The running cost article makes the same point from the workflow side: providers can change a model’s behaviour with an update, source data can degrade, and users find new edge cases after launch.

None of this means the tool was badly chosen or badly set up. It means the set-up was a photograph and the tool is a moving thing. Drift is the distance between the two.

Why it happens when nobody owns the Tool

Drift is not caused by owners being careless. It is caused by there being no owner, and the article explains how that comes about. A rollout is a project, with a start, a budget, a champion and a date on which it is declared finished. Owning the result is operational work with no end date, and projects do not turn into it on their own.

Three things happen when a rollout closes. The project team disbands, so the person who understood how the tool was configured returns to their day job. The enthusiasm that carried the launch fades. And responsibility spreads out, because an AI tool touches several functions at once. IT holds the account, the department holds the use, the managing director or legal holds the risk, and HR holds the training. Each has a genuine claim to a slice. Nobody holds the whole, and each assumes that someone else is watching the rest.

The production article reports the same pattern at project level: projects without a named owner are far more likely to drift once the initial enthusiasm fades. The pilot article says it more simply, that a task nobody owns is the one that quietly drifts, and advises checking again at thirty days because AI routines drift when nobody is watching them.

There is a third effect. When nobody sets the rules, the users set their own. That is how a sanctioned assistant ends up alongside personal accounts and browser extensions the business never chose, which is shadow AI.

The five slow failures

The ownership article lists five costs of an unowned tool. They are slow and spread out, which is why they go unnoticed.

Quality drifts. Nobody is sampling the outputs, so a summary tool that was accurate at launch becomes slightly less so, or starts to be used on a kind of document it was never tested on. Staff learn to trust it because it usually works, which is the moment a hallucination does the most damage, because nobody is expecting one.

Access widens. Permissions granted for a pilot stay in place. A tool connected to one folder gets connected to three. When a member of staff leaves, their account and its connections outlive them.

Policy goes stale. A rule written at launch does not mention the new features, the new tools or the new team. It sits on the intranet and nobody reads it against reality.

Incidents have no route. If an assistant sends wrong information to a client, or surfaces something it should not, who is told first, and who decides whether it is reportable? In an unowned system that conversation starts from nothing, under pressure.

The business cannot show its work. Customers, auditors and insurers increasingly ask which AI is in use, on what data and under whose supervision. “We think it is fine” is not an answer.

An illustration from the Ownership article

The article gives a scenario and labels it an illustration and not a real client. A 40-person professional services business rolls out an AI assistant after a successful pilot run by an enthusiastic operations manager. Six months on, that manager has moved to another project. The assistant has since been connected to the shared drive, which includes a folder of HR documents that was never meant to be searchable. An employee asks it a routine question about the team and it returns text drawn from that folder. Nobody notices for weeks, because nobody’s job is to look.

The article’s summary is worth keeping. There was no attack and no fault in the tool. There was only a gap where an owner should have been. That is drift in one paragraph: access widened, nobody checked, and the cause was a missing job and not a missing control.

A Different Drift: a step moving up the Ladder

Drift is not only about tools. The task and decision article describes a second kind that happens inside a workflow. Sorting a process onto the delegation ladder before anything is built means a step is scoped as Recommend, with a named reviewer, a human in the loop by design. The risk is that it then drifts towards Execute later, because nobody revisited the original design once the tool proved itself on the easy cases.

The article reports that projects stalling after a promising pilot were disproportionately ones where a Recommend-level step had quietly been treated as Execute-level once the demo looked good. A shortlisting step is the example it gives. Catching that at the scoping stage costs an afternoon. Catching it after launch costs a rebuild, and sometimes an apology to whoever the wrong call affected.

The article’s remedy is a record. A written governance policy is, among other things, a record of which rung each automated process sits on and who signed off on putting it there. Without that record, a business finds out its process crossed a line only after something goes wrong. The high-risk AI system page repeats the warning for the step that quietly moves up.

Drift and Hallucination

The two are often confused. A hallucination is a confident, fluent statement that is not true, and it can happen on the first day. Drift is a change over time in how the tool behaves, what it can reach and what rules apply to it.

They connect through trust. The ownership article says staff learn to trust a tool because it usually works, and that this is the moment a hallucination does the most damage. A tool that drifts towards less accurate output, in a setting where nobody is sampling it, produces exactly that situation. The answer to both is checking that continues after launch, which is why a person checking output is a standing job and not a launch task.

What the EU AI Act presumes

The Act does not use the word drift, but the duties it places on a deployer presume someone is watching for it. The ownership article reports that an organisation deploying a high-risk AI system must monitor it for anomalies, dysfunctions and unexpected performance, keep its logs for at least six months, assign competent people to oversee it, and inform the provider and the authorities of a serious incident.

The article adds two cautions. The compliance deadline for stand-alone high-risk systems has moved to 2 December 2027, so this is not an urgent duty for everyone. And most everyday tools are not high-risk, so the Act does not ask every business to appoint someone for every chat assistant. But look at what each duty presumes. Monitoring needs someone monitoring. Oversight needs someone assigned. A business that has not decided who that is will find the deadline arriving without an answer. The deployer page covers the role.

How to prevent Drift

The fix the article proposes is small, and it starts with a list. It is a short sequence a small business can finish in a month:

1. List what is in use. Ask people, not accounts, and make clear the aim is to understand use and not to punish it. The result is the AI tool inventory.
2. Name one owner per tool. A person, not a team, who feels the consequences when the tool goes wrong and has the authority to pause it.
3. Write a one-page record. Purpose, users, the data the tool can reach and the date of the next review.
4. Set the rhythm and the route. A quarterly review for each tool, a second trigger whenever the vendor announces a change, and an agreed order of who is told if something goes wrong.

The article’s table of who holds which question is worth copying. The head of the function holds whether the tool is doing what it was bought to do. Whoever administers accounts holds who can use it and what it can reach. Whoever holds data protection holds whether the data is allowed. Line managers hold whether staff use it within the rules. The named owner holds what happens when it goes wrong, escalating to the managing director.

For a workflow, the running cost article adds the weekly look: someone checks the output, notices when it drifts, and fixes the connection when another system changes its format. It treats a named owner as part of the price of running a workflow safely and not an optional extra.

What to do first

Pick one tool that is already in use and ask the four questions the article says an owner must be able to answer: what is it for, who uses it, what can it reach, and when was it last checked. If nobody can answer all four, that is the finding, and it is a better thing to learn this month than after an incident.

Then put one name against the tool and one review date in the calendar. The AI ownership page covers the role and the AI governance page covers the rules around it. An audit ends with a named internal owner for each workflow that goes live, which the ownership article gives as the difference between a tool that keeps working and one that drifts.