AI Objective Drift: When a Mandate Grows Beyond Its Boundary

AI objective drift occurs when a system’s interpretation of its purpose expands over time without anyone approving that expansion. The mandate stays the same on paper. What the system does under that mandate widens, incrementally, through changes that each look reasonable in isolation. It is one of the few governance failures that passes review precisely because nothing broke.

The clearest illustration comes from fiction. In I, Robot, the central AI, VIKI, is given a directive to protect humanity. She does not violate it. She follows it to its logical conclusion and decides that the greatest threat to humanity is human autonomy. Removing that autonomy becomes the most rigorous possible expression of her purpose. No line of her instruction set was breached. The scope of the instruction was simply never bounded.

We raise this because the same failure mode is present in production AI systems today, and almost nobody writes a control for it.

Why a broad mandate expands on its own

A mandate without an explicit boundary is a mandate that grows. Systems are commissioned with purpose statements written at the level of business intent: reduce fraud, improve triage, identify at-risk accounts, support clinical decision-making. Those statements are useful for approval and useless for constraint, because they describe a direction rather than a limit.

Once live, three forces push the system outward. Retraining changes what the model considers relevant. New data sources widen the population it reasons about. And users, having found the tool useful for its original task, begin applying it to adjacent tasks that nobody assessed.

None of these are misuse. A fraud model retrained on a larger dataset is doing what it was built to do. A triage assistant used on a slightly different patient cohort is being used by clinicians acting in good faith. The system is not malfunctioning; it is operating at a scope that was never approved.

Drift happens through legitimate increments

This is the reason objective drift survives governance review. Each individual step is defensible.

A recruitment screening tool is approved to rank applications against a role specification. Six months later it is being used to flag candidates for future roles, because someone noticed it could. A year later, its outputs inform internal promotion shortlists, because the underlying signal seemed transferable. Every extension was proposed by a competent person with a sound business reason, and each one was small relative to the last.

Ask whether that final use case would have passed the original approval process, and the answer is usually no. Ask when it was refused, and there is no answer, because it was never presented as a change. It arrived as usage.

We see the same pattern in customer-facing assistants. A tool approved to answer questions about published policy documents starts answering questions about individual accounts, then offering interpretations of entitlement, then effectively making decisions that were meant to sit with a human. The model did not seize authority. Authority accumulated around it because no one had written down where its authority ended.

Change control has to cover scope, not just code

Most AI change control processes are inherited from software change management and they inspect the wrong things. They ask what changed in the codebase, what changed in the configuration, what changed in the model version and whether the deployment was tested. All necessary. None of it detects drift, because drift frequently involves no change to code, configuration or model at all.

A scope-aware change control process asks a different set of questions before a change is approved:

• What decisions is this system permitted to influence, and which is it permitted to make?
• Which populations or datasets is it authorised to reason about?
• Which teams are authorised to use it, and for what?
• What is it explicitly not for?

That last question does the most work and appears in the fewest AI risk assessments we review. A prohibited-use statement is far more durable than a purpose statement, because it survives creative reinterpretation. “Support clinical triage” can be stretched. “Must not be used to determine treatment eligibility, and must not be applied to paediatric cases” cannot be stretched quietly.

When scope is recorded this precisely, extension becomes a change request. That is the entire objective. You are not trying to prevent the system from being used more widely; you are trying to ensure that widening is a decision somebody makes on the record. It also belongs in the disclosure record we describe in purpose disclosure for AI systems, because a boundary nobody publishes is a boundary nobody applies.

Periodic re-assessment against original purpose

Bounded scope handles the changes people bring to you. Detection handles the ones they do not.

The only reliable method we have found is periodic re-assessment against the original purpose. On a defined cycle, take the approved scope statement as written at commissioning, then examine what the system is actually doing: the queries it receives, the decisions its outputs feed, the teams using it and the data it now touches. Compare the two. The gap between them is your drift.

For higher-risk systems that cycle should be quarterly. For lower-risk internal tooling, annually is usually defensible. What matters is that the comparison is made against the original document rather than against last quarter’s practice, because comparing against recent practice normalises whatever has already drifted. Each review then re-baselines from a slightly wider position, and the boundary erodes at exactly the rate it did before.

Assign the review to someone who did not build or operate the system. Owners are poorly placed to notice expansion they authorised one increment at a time. Where two approved objectives are pulling in different directions, that is a separate problem with its own fix, set out in conflicting AI objectives.

Common questions on objective drift

Who should own scope re-assessment in a mid-sized organisation?

Second-line risk or compliance, with technical input from the system owner. The reviewer needs enough independence to challenge accumulated practice and enough access to examine actual usage logs. Where no second line exists, internal audit or a rotating peer reviewer from another team is workable, provided the finding goes to a governance forum rather than back to the owner.

What if our original purpose statement was too vague to compare against?

Re-baseline before you review. Write a bounded scope statement describing current approved use, including prohibited uses, and have it formally approved. That becomes your reference point. Attempting to audit against a vague original wastes the exercise, because almost any behaviour can be argued as consistent with it.

Does this apply to third-party AI tools we have not built?

Yes, and often more urgently. Supplier updates change capability without consulting you, which means scope can expand between one release and the next. Record what you approved the tool to do, and review supplier release notes against that boundary.

If you are responsible for AI systems already running in production and have no scope boundary written down, that is the place to begin. Our AI Security Programmes establish bounded scope, scope-aware change control and a re-assessment cycle across your AI estate.