Policy drift is what happens when the rules your legal and compliance teams are working from diverge from the rules your AI assistant is actually applying. The divergence usually starts small: a policy update that applies to human-authored communications gets applied to AI outputs in a revision meeting, but the engineering team is not in the room. Or the assistant's system prompt is updated for a product reason, and the compliance constraints in the old version get partially carried forward. Or a regulatory interpretation shifts and the legal team issues updated guidance that never makes it into the assistant's evaluation logic.
The outcome in each case is the same: the assistant is operating according to an older version of the policy, and no one has a precise record of which version that is. The compliance team, working from the current policy, will find violations. The engineering team, confident they implemented the policy they were given, will be confused. Both are right. The problem is structural.
Why This Happens More Than It Should
Part of the reason policy drift is endemic to AI assistant deployments is that compliance policy and AI behavior are managed by entirely different disciplines using entirely different tooling. Compliance policy lives in document management systems, legal review workflows, and versioned policy repositories. AI assistant behavior is specified in system prompts, RAG configurations, eval suites, and fine-tune datasets. There is no natural mechanism that causes a change in one to propagate to the other.
When a human employee's behavior needs to change because of a policy update, there is an established process: the policy update is communicated, training is provided if needed, and the employee is expected to apply the updated guidance going forward. When an AI assistant's behavior needs to change because of a policy update, there is no equivalent process unless the team explicitly builds one. Most teams do not build one, at least not initially. They rely on the same ad hoc communication channels they use for everything else, which means updates sometimes propagate quickly and sometimes sit in a review meeting until someone remembers to file the ticket.
The compounding factor is that AI assistant behavior is not fully deterministic. You cannot read the system prompt and know exactly how the assistant will respond to every query. You have to test it, and testing takes time. So even if a policy update is communicated promptly, the engineering team may not be able to validate that the assistant actually reflects the update without a non-trivial evaluation effort. Under deadline pressure, that validation gets deferred.
The Three Gaps Policy Drift Lives In
The first gap is the update propagation gap: the time between a policy document being updated and the change reaching the systems that enforce it. For AI assistants, this typically means the time between a policy revision and the assistant's evaluation logic reflecting the revision. In organizations with quarterly release cycles and annual compliance reviews, this gap can be six months or more. During that window, the assistant is operating on stale policy, and every violation it generates reflects the delta between what was approved and what is current.
The second gap is the interpretation gap: the difference between what the policy document says in natural language and what the enforcement logic actually checks. Policies are written to be read by humans with contextual judgment. Enforcement logic checks specific conditions. The translation between them is imperfect. A policy that says "do not provide specific financial projections" might be translated into a rule that flags certain numerical formats, but a response that implies a financial projection through qualitative language might pass the check while still violating the intent of the policy. The interpretation gap means even well-maintained enforcement logic may not be capturing what the policy document means.
The third gap is the coverage gap: the categories of policy violation that the enforcement logic does not check at all. When a new policy category is added, enforcement logic for that category has to be written. If the policy update does not include an explicit request to update the enforcement logic, the new category simply goes unchecked. These invisible gaps are the most dangerous because they cannot be caught by any audit that focuses only on existing enforcement.
What Governance Looks Like When It Works
The organizations that manage policy drift effectively have, in common, two things: a clear ownership model for policy-to-enforcement propagation, and a mechanism for detecting drift before audits do.
On ownership: someone has explicit accountability for the pipeline from policy document to active enforcement rule. This is not a job that naturally falls to either the compliance team or the engineering team as currently structured in most organizations. The compliance team understands the policy requirements but does not own the enforcement system. The engineering team owns the enforcement system but does not track policy updates. Closing the drift gap requires either a bridge role or an explicit handoff protocol with defined SLAs.
On detection: passive drift detection relies on audits, which means violations accumulate between audit cycles. Active drift detection checks enforcement coverage against the current policy document on a scheduled basis and flags gaps. This can be as simple as a quarterly review where the compliance team reviews the active enforcement ruleset against the current policy document and marks uncovered categories. It can also be more automated, particularly when policy documentation is structured enough to extract checkable requirements. Neither approach is foolproof, but both are substantially better than waiting for an audit to surface the drift.
The role of a runtime enforcement layer like ZeroDrift in this picture is not to solve the governance problem. Governance is an organizational problem. But a well-designed enforcement layer does change the economics of drift: when policy rules are active configuration rather than embedded in model behavior, propagating an update means pushing a rule change rather than retraining and re-evaluating a model. That changes a week-long process into an hours-long one, which reduces the window during which drift is a liability. It does not eliminate the need for ownership and detection, but it makes the correction cycle fast enough to be practical.
A Note on What This Problem Is Not
Policy drift is worth distinguishing from model hallucination and from intentional model limitations. A model that fabricates information is exhibiting a different failure mode than a model that provides accurate information that violates current policy. And a model that correctly follows the policy it was trained or prompted on is not drifting, even if that policy is outdated.
The practical reason this distinction matters is that the fixes are different. Hallucination is primarily a model quality and grounding problem. Policy drift is an operational and governance problem. Conflating them leads to solutions targeting the wrong root cause. A model that gets better at avoiding fabrication does not become more current on policy updates. An organization that improves its policy propagation process does not automatically improve grounding quality. Both problems deserve their own attention, and neither is a substitute for the other.
Drift is also not the same as intentional scope limitation. If a team decides the assistant should not address certain categories of question, and enforces that through blocking rules, that is a design decision. If the blocking rules no longer reflect what the current policy intends to restrict, that is drift. The policy is the reference. When the enforcement diverges from the reference, you have drift. Maintaining fidelity to that reference over time, as both the policy and the product evolve, is the operational challenge that compliance-oriented teams need to treat as a first-class concern.