Published: 2026-04-29 · License: CC BY 4.0
Domain: PSF-8 — Vendor Resilience
Vendor Resilience
The AI vendor landscape is moving faster than any previous technology layer organisations have had to manage. Models are deprecated with 90 days notice. Providers change pricing, terms of service, and API behaviour. New providers emerge with superior capabilities and attract migration. PSF-8 addresses one question: when your current AI vendor becomes unavailable, unacceptable, or unaffordable — how long does it take you to recover, and what does that cost?
The Vendor Dependency Spectrum
Vendor dependency in AI systems exists on a spectrum. At one end: an application that calls a single provider API with hardcoded model names, no abstraction layer, and no tested alternative. A provider outage takes this application down completely; a deprecation notice triggers an emergency re-architecture. At the other end: an application built on a provider-agnostic abstraction layer, tested against two or more providers, with automated switching and a documented migration playbook. PSF-8 does not mandate the latter — it mandates a conscious, documented position on the spectrum with controls proportionate to the dependency risk.
Abstraction Layer Design
The most valuable PSF-8 control is an abstraction layer that decouples application logic from specific model providers. This layer translates application-level requests ('classify this document', 'summarise this text') into provider-specific API calls, and translates provider-specific responses back into a standardised format. The abstraction layer has three properties that matter: it is the only place in the codebase where provider-specific code lives; switching providers requires changes only to the abstraction layer implementation, not to application logic; and it is tested against multiple providers so that the test suite validates provider-agnostic behaviour, not provider-specific behaviour.
PSF-8 Resilience Controls
A dedicated module or service that encapsulates all provider-specific API calls. Application code calls the abstraction layer; the abstraction layer calls the provider. Provider switching requires only a configuration change or a single-module swap.
Use specific model version identifiers in all API calls where the provider supports them. 'gpt-4' changes over time; 'gpt-4-turbo-2024-04-09' does not. Pinning prevents silent model changes and gives you control over when you upgrade.
When a deprecation notice arrives, you need to evaluate alternatives, run evals, update the abstraction layer, run integration tests, stage the change, and promote to production. Document how long this takes. If it takes longer than the deprecation notice period, you are operating with unacceptable vendor risk.
Have at least one alternative provider tested and configured in your abstraction layer. The fallback does not need to be equivalent in quality — it needs to be sufficient to maintain service while you address the primary provider issue.
Your evaluation suite should run against any provider you might use. If your evals are built around provider-specific output formats, you cannot meaningfully compare providers. Provider-agnostic evals are a prerequisite for informed switching decisions.
Model provider terms of service, data processing agreements, and acceptable use policies change. Assign a named owner to monitor these changes for each provider in use. A terms change that restricts your use case may require emergency migration.
The Deprecation Drill
The best way to validate PSF-8 readiness is a deprecation drill: simulate a provider deprecation notice and measure actual response time. How long does it take to identify all the places in the codebase that use the deprecated model? How long to evaluate an alternative? How long to update, test, and deploy the change? If the answer to any of these is 'we don't know', the abstraction layer and evaluation suite need work before a real deprecation notice arrives.
PSF-8 Compliance Checklist
AIDA Exam Tips for PSF-8
- PSF-8 questions often present a scenario where a model is deprecated with short notice. The PSF-8 answer describes the abstraction layer, the fallback provider, and the documented migration playbook — not 'we will investigate alternatives.'
- Model version pinning is a PSF-8 control that also helps PSF-4 (Observability) — pinned versions make log correlation possible. But in a PSF-8 context, the primary reason is preventing silent behaviour changes.
- Provider abstraction layer: the exam tests whether you know the architectural pattern. Application logic does not call provider APIs directly. A dedicated layer mediates all provider communication.
- Deprecation response time: the exam may ask you to evaluate whether a team's response plan is adequate given a deprecation notice period. If the plan takes longer than the notice, it is inadequate.
- Cost risk is a PSF-8 concern: a provider that changes pricing significantly can make an application economically non-viable. Cost model documentation per provider is a PSF-8 governance requirement.