Vendor AI drift

What Vendor AI Drift Means in Practice

Vendor AI drift happens when a supplier’s model behaviour, hosted features, or underlying data handling changes after approval, so the service in production no longer matches the service that was risk-assessed. It is less about a single defect than about ongoing divergence between assurance and reality.

That divergence can be subtle. A vendor may retrain a model, swap a dependency, alter retention settings, change prompt handling, add a new subprocessor, or expand the product’s AI features without a corresponding customer review. The result is a live service that can carry new exposure even though the contract, questionnaire, or security sign-off looks unchanged.

Why Drift Creates Governance Blind Spots

The central problem is that AI services are not static artifacts. Their outputs, data flows, trust boundaries, and control assumptions can change faster than procurement reviews, security attestations, and legal approvals are refreshed. That makes drift a governance issue as much as a technical one.

For customers, the risk is not only that a model becomes less accurate. The more consequential change is often in what data the vendor now processes, where that data travels, which safeguards still apply, and whether the original use case has quietly expanded. That is why vendor AI drift belongs in third-party risk, not just model evaluation.

This is also where supplier transparency matters. If the approval record cannot describe the current service accurately, then control ownership becomes blurry, and security teams may be operating against an outdated picture of the vendor environment.

Signals That a Supplier Has Drifted

Drift usually shows up first as inconsistency between documentation and observed behaviour. Customers may notice new model responses, altered integration paths, changed permissions, unexpected retention language, missing release notes, or shifted governance terms that were not part of the original review.

It can also appear when a vendor adds new AI-enabled features around an otherwise familiar product. The core business service may look the same, but the data path, access model, or subprocessor chain may no longer be equivalent to the version that was approved. A practical example is a SaaS integration that keeps the same user experience while changing how tokens, prompts, or customer content are routed behind the scenes, a pattern often discussed alongside Salesloft OAuth token breach style drift and token-abuse scenarios.

Because these shifts can be invisible to end users, drift is often discovered only through reassessment, vendor notification, or an incident. The absence of visible breakage is not evidence that the service is still within the approved risk envelope.

Vendor AI Drift and Third-Party Risk Review

Vendor AI drift is most serious when the buyer treats an initial questionnaire as a one-time event. AI features evolve quickly, and vendor assurance needs to keep pace with the actual service rather than the product name on the contract. This is where periodic review of CSA Cloud Controls Matrix and SOC 2 Trust Services Criteria (AICPA) style assurances can be useful, provided they are tied to the live service and not just annual paperwork.

For AI-specific governance, drift can also mean the supplier has moved into a new risk posture that warrants fresh evaluation against AI governance and control expectations. A broader control lens, such as NIST AI Risk Management Framework, helps teams ask whether the supplier still meets the assumptions behind the original approval.

When the supplier’s changes affect data protection, security of processing, or deployment transparency, the issue may also intersect with regulatory obligations. In those cases, the customer should treat drift as a material change event, not a cosmetic product update.

Risk and Threat Considerations

Vendor AI drift can create a gap between assumed and actual controls, which is especially dangerous in outsourced systems that handle sensitive content, tokens, or customer data. The main exposure is that a supplier may introduce new AI behaviour, data processing paths, or privileges without the customer revalidating the change.

Failure mechanism: A vendor updates its AI service, model, or connected workflow in ways that alter data handling, access paths, retention, or output behaviour, while customers continue relying on an outdated approval or assurance record.

Impact: The customer may inherit unreviewed confidentiality, integrity, compliance, or supply-chain risk, and a later incident may be harder to contain because the true service state was never re-baselined.

Practitioner Guidance

What to watch for: Treat drift as a continuous vendor-management signal, not a periodic paperwork issue. If the supplier cannot clearly explain what changed, what data moved, and what controls changed with it, the service should be considered out of date from a risk perspective.

Governance implication: Assign explicit ownership for re-review triggers such as model updates, new AI features, new subprocessors, prompt-routing changes, token handling changes, and retention changes. The practical goal is to keep the approved risk view aligned to the live service, not to rely on the vendor’s original security description.

Practitioner takeaway: The safest assumption is that an AI supplier is a moving target, so approval should expire when the service meaningfully changes, even if the contract title does not.

Related resources from NHI Mgmt Group

• Why does agentic AI create mission drift risk in enterprise environments?
• Who is accountable when AI flags a vendor as high risk?
• Who is accountable when an AI vendor changes an agent's capabilities without notice?
• Why is intent drift a governance risk for AI agents?