AI Controls and Governance
What is AI drift, and why does it matter?
Every failure mode discussed elsewhere in AI governance has a moment attached to it: an incident, a wrong decision, a question that couldn't be answered. Drift has no moment. Nothing breaks. No alert fires. Every individual action the agent takes looks reasonable on its own terms — it is doing exactly what it was told. The problem is that what it was told has quietly stopped matching what the organisation now intends, and the distance between the two has been growing for months.
Drift is the failure mode you discover by comparison, not by incident. And comparison requires a record of where you meant to be — which is precisely what most organisations don't have. Governance systems are built around events. Drift is not an event but a direction.
One Word, Two Problems
"AI drift" is carrying two different meanings, and conflating them sends people to the wrong fix.
The first is the machine learning sense: model drift and data drift, where a model's statistical performance degrades because the world its training data described has moved on. Fraud patterns change, customer behaviour shifts, and a model trained on last year's distribution slowly gets worse at this year's. This is a real, well-studied problem with mature tooling — drift detection, retraining pipelines, performance monitoring. If that is your problem, the MLOps ecosystem has answers.
The second is organisational: the agent's operating context drifting away from the organisation's actual intent. The model may be performing perfectly. The statistics are fine. What has changed is the organisation — its goals moved, its constraints were updated in a meeting, its priorities shifted last quarter — and none of that reached the agent, because the agent's context was written once and never maintained. Retraining doesn't fix this, because nothing about the model is wrong. The brief is wrong.
This page is about the second kind. It matters because it is far less discussed, has almost no tooling, and is the one that produces decisions an organisation cannot stand behind.
The Three Axes of Drift
Organisational drift shows up along three distinguishable axes, and they fail differently.
Compliance drift. The rules the agent operates under no longer match the rules the organisation operates under. A pricing agent configured before a regulatory change keeps applying the old discounting logic — within its instructions, outside the new policy. Nobody told it, because the policy change happened in a legal review and the agent's instructions live in a config file nobody connected to that review. The agent is compliant with its brief and non-compliant with reality.
Goal drift. The agent optimises for an objective the organisation has since moved past. A lead-qualification agent built when the company chased volume keeps maximising meeting bookings, a year after the sales strategy shifted to fewer, larger accounts. Every booking it makes is locally a success and strategically a small step in the wrong direction. Goal drift is the most expensive axis because it compounds: the agent isn't failing occasionally, it's succeeding consistently at the wrong thing.
Values drift. The hardest to see, and honestly the fuzziest of the three — the least measurable, and the one sceptical readers will rightly push on. The agent's tone, judgement calls, and trade-offs slowly diverge from how the organisation would want to be represented — not breaking any rule, just accumulating small choices the organisation wouldn't have made. A support agent that has become slightly more willing to deflect, slightly less generous with goodwill gestures, because nothing in its context ever told it what the organisation believes about customer relationships. No single response is a problem. The pattern is. The fuzziness is also why this axis is discovered last: there is no audit for "this doesn't feel like us."
The axes matter because they're discovered differently: compliance drift by audit, goal drift by strategy review, values drift usually by a customer or employee saying exactly that — this doesn't feel like us.
Why Drift is Invisible until it Isn't
Drift survives because every mechanism organisations use to catch problems is tuned to detect events, and drift is not an event. Monitoring flags anomalies — but a drifted agent isn't anomalous, it's consistent. Reviews examine incidents — but there is no incident, only a slowly widening gap. The agent passes every check it was set up with, because the checks drifted with it: they were written against the same stale brief.
The only way to detect drift is to compare what the agent is working from against what the organisation currently intends. That comparison needs two things to exist: a record of the agent's operating context, and a current statement of intent to hold it against. Most organisations have neither in retrievable form. The agent's context is scattered across prompt files and configuration; the organisation's intent lives in heads, decks, and meeting notes. With nothing to compare, the gap is undetectable until it surfaces as a consequence — at which point it gets treated as an incident, investigated as an incident, and misdiagnosed, because the cause wasn't an event. It was an accumulation.
This is also why drift prevention is a maintenance discipline rather than a deployment task. An agent's context is guaranteed to be current only once: on the day it's written. Everything after that is decay unless something actively keeps the brief current as the organisation changes.
Engramic's approach
How Engramic Approaches it
There are multiple ways to keep an agent's context aligned with organisational intent over time. This is one approach.
Engramic makes both halves of the comparison exist. The agent's operating context — goals, constraints, decisions — is authored and maintained in one place, and changes to organisational intent are recorded there as they happen: when a goal shifts, the change lands in the same graph the agent draws from, with the prior version preserved. When something newly recorded conflicts with what was previously agreed, the conflict surfaces for a human to resolve, rather than sitting silently in the graph undermining an agent six months later. Drift detection stops being an annual audit and becomes a property of how the context is maintained: the gap between brief and intent can't widen unnoticed, because the brief and the intent live in the same place.
What this doesn't solve: an organisation that never records its changes of intent will drift regardless of tooling. The mechanism only works if the maintenance happens.
In short
AI drift in the organisational sense is the gradual divergence between what an agent was told and what the organisation now intends — distinct from ML model drift, which is statistical and has mature tooling. It moves along three axes: compliance, goal, and values. It produces no incidents, which is why event-tuned monitoring never catches it; it is discovered only by comparing the agent's brief against current intent, and most organisations keep neither in a comparable form. An agent's context is guaranteed to be current only once, on the day it's written. After that, alignment is maintenance, not configuration.