Supplier Concentration and Exit Governance

2. Summary

Supplier Concentration and Exit Governance requires that every organisation deploying AI agents maintains quantified visibility into its AI supply chain concentration and maintains executable exit plans for every critical AI supplier. The AI supply chain is structurally concentrated: a small number of foundation model providers, cloud infrastructure providers, and specialised AI service providers serve the majority of deployments. This concentration creates systemic risk — if a single provider experiences a service disruption, changes its pricing, alters its terms of service, is subject to regulatory action, or exits the market, every dependent organisation is affected simultaneously. AG-093 mandates that organisations measure supplier concentration using defined metrics, establish concentration thresholds that trigger diversification requirements, maintain tested exit plans with documented migration paths, and ensure that no single supplier failure can render the agent system inoperable without a viable recovery path.

3. Example

Scenario A — Single-Provider Dependency Creates Operational Paralysis: A mid-sized insurance firm builds its entire AI agent ecosystem on a single foundation model provider's API. The provider powers 14 agents across underwriting, claims processing, customer service, and compliance. The provider announces a 340% price increase effective in 90 days, justified by rising compute costs. The firm has no alternative model integration, no abstraction layer between its agents and the provider's API, and no tested migration path. The firm's options are: accept the price increase (adding £2.4 million annually to operating costs), or attempt an untested migration within 90 days while maintaining service continuity. The firm accepts the price increase, creating a budget overrun that triggers a review of the entire AI programme.

What went wrong: The firm allowed 100% concentration on a single AI model provider without establishing any exit capability. No abstraction layer existed to decouple agent logic from provider-specific APIs. No alternative provider had been evaluated, benchmarked, or integration-tested. The 90-day notice period was insufficient for a safe migration. Consequence: £2.4 million annual cost increase, board-level review of AI strategy, 18-month programme to implement provider diversification — during which the firm remains fully dependent on the incumbent.

Scenario B — Provider Regulatory Action Cascades to Deployers: A healthcare organisation uses a third-party AI model for clinical triage. The model provider is subject to an EU AI Act enforcement action that prohibits the model's use in healthcare applications pending a conformity assessment that is estimated to take 12-18 months. The healthcare organisation has no alternative triage model, no manual fallback procedure that can handle the current volume (47,000 triage assessments per month), and no exit plan. The organisation must immediately cease using the model or face its own regulatory enforcement. It reverts to fully manual triage, increasing average assessment time from 4 minutes to 22 minutes and creating a backlog of 8,200 assessments within the first two weeks.

What went wrong: The organisation had no exit plan for regulatory disruption of a critical supplier. No alternative model had been identified or tested. No manual fallback process had been designed for the current operational scale. The organisation's operational dependency on the model was total, with no resilience for supplier-level disruption. Consequence: 2-week operational disruption affecting 47,000 monthly triage assessments, emergency procurement of alternative model at premium cost (£380,000 expedited), reputational damage from service degradation during the transition.

Scenario C — Concentration Risk Across Shared Infrastructure: An enterprise uses three different AI model providers for different agent functions, believing it has achieved diversification. Analysis reveals that all three providers run on the same cloud infrastructure provider's GPU instances. A regional outage of that cloud provider lasting 6 hours disables all three AI services simultaneously, halting all 22 of the enterprise's AI agents. The enterprise's business continuity plan assumed that using multiple AI model providers provided resilience — it did not account for shared infrastructure concentration.

What went wrong: Supplier concentration was measured at the direct provider level without analysing shared dependencies deeper in the supply chain. The apparent diversification across three model providers masked a single point of failure at the infrastructure layer. Consequence: 6-hour complete AI agent outage, estimated revenue impact of £165,000 for the outage period, customer SLA breaches triggering £43,000 in service credits, and discovery that the business continuity plan was based on a false assumption of provider independence.

4. Requirement Statement

Scope: This dimension applies to all AI agents that depend on external suppliers for any component of the agent system — including foundation model providers, fine-tuning service providers, embedding model providers, AI infrastructure providers (GPU cloud, inference hosting), specialised AI tool providers (vector databases, prompt management platforms, evaluation frameworks), and any service whose unavailability would degrade or disable agent operations. The scope includes both direct suppliers and indirect suppliers whose services underpin the direct suppliers (e.g., the cloud provider hosting a model provider's inference endpoints). The scope extends to open-source model providers where the organisation depends on the provider's ecosystem for model updates, security patches, or community support. The scope does not extend to commodity infrastructure (general-purpose compute, networking, storage) unless that infrastructure is AI-specialised (e.g., GPU instances from a single cloud provider).

4.1. A conforming system MUST maintain a supplier concentration register that quantifies, for each AI supplier: the number of agents dependent on the supplier, the percentage of total agent operations dependent on the supplier, the annual spend with the supplier, and the estimated operational impact of supplier unavailability.

4.2. A conforming system MUST define concentration thresholds that trigger governance responses — at minimum, a threshold for "elevated concentration" (e.g., a single supplier supporting more than 40% of agent operations by count or value) and a threshold for "critical concentration" (e.g., a single supplier supporting more than 70% of agent operations).

4.3. A conforming system MUST maintain a documented, executable exit plan for every AI supplier classified as critical — defined as any supplier whose unavailability would materially degrade or disable agent operations supporting business-critical functions.

4.4. A conforming system MUST ensure that exit plans include: an identified alternative supplier or approach, a documented migration path with estimated timeline and resource requirements, a tested proof-of-concept demonstrating that the alternative can support the required workload, and a defined trigger condition that activates the exit plan.

4.5. A conforming system MUST review and update exit plans at least annually, or within 30 days of any material change in the supplier relationship (pricing change, terms of service change, ownership change, or regulatory action affecting the supplier).

4.6. A conforming system SHOULD implement an abstraction layer between agent logic and supplier-specific APIs, enabling provider switching without agent-level code changes.

4.7. A conforming system SHOULD conduct periodic exit plan testing — at minimum an annual tabletop exercise for each critical supplier, and a live migration test for the highest-criticality supplier.

4.8. A conforming system SHOULD analyse indirect supplier concentration by mapping the infrastructure dependencies of direct suppliers to identify shared single points of failure.

4.9. A conforming system MAY implement active multi-provider deployment — routing a percentage of production traffic through alternative providers to maintain operational readiness for provider switching.

5. Rationale

Supplier Concentration and Exit Governance addresses the structural vulnerability created by the AI industry's current market structure. The foundation model market is dominated by a small number of providers. GPU cloud infrastructure is concentrated among three major cloud providers. Specialised AI services (vector databases, evaluation platforms, prompt management) have limited provider ecosystems. This concentration is not inherently problematic — it reflects the capital intensity and technical complexity of AI infrastructure — but it creates risks that organisations must actively govern.

The risk is compounded by the nature of AI supplier dependencies. Switching an AI model provider is not equivalent to switching a commodity SaaS tool. Agent prompts are tuned to specific model behaviours. Fine-tuning investments are provider-specific. Evaluation benchmarks are calibrated against specific model outputs. Integration patterns use provider-specific APIs. The practical switching cost is measured in months and significant engineering effort. This creates lock-in that gives suppliers pricing power and reduces the organisation's negotiating leverage.

AG-093 does not require organisations to avoid concentration — in many cases, concentrating on the best-performing provider is the right technical decision. It requires organisations to understand their concentration, quantify the risk, and maintain viable exit paths. The principle is that concentration should be a conscious, governed decision with documented risk acceptance, not an accidental outcome of incremental adoption decisions.

The exit plan requirement is the operational core of AG-093. An exit plan that exists only as a document is insufficient — it must include a tested proof-of-concept and a credible migration timeline. The difference between an untested exit plan and a tested one is the difference between a hope and a capability. AG-045 (Economic Incentive Alignment Verification) addresses the contractual dimension of supplier relationships; AG-093 addresses the operational resilience dimension.

6. Implementation Guidance

AG-093 requires organisations to build systematic visibility into their AI supply chain concentration and maintain operational readiness for supplier transitions.

Recommended patterns:

• Supplier concentration dashboard. Maintain a real-time dashboard that visualises: the number of agents per supplier, the percentage of agent operations per supplier, annual spend per supplier, and a dependency graph showing both direct and indirect supplier relationships. Use colour-coded thresholds (green below 40%, amber 40-70%, red above 70%) to provide immediate visibility into concentration risk. Update the dashboard automatically from the component inventory (AG-087) and the dependency registry (AG-014). Include a "what-if" analysis capability that models the impact of a specific supplier becoming unavailable.
• Abstraction layer architecture. Implement a model gateway or abstraction layer that exposes a provider-neutral API to agent logic. The abstraction layer handles provider-specific request formatting, authentication, response parsing, and error handling. Agent prompts are stored with provider-specific variants, enabling switching by configuration change rather than code change. The abstraction layer also provides a natural integration point for traffic routing (active multi-provider deployment), monitoring (AG-091), and cost tracking. Example: an LLM gateway that accepts a standard chat completion request and routes it to the configured provider (OpenAI, Anthropic, Google, or a self-hosted model) based on routing rules.
• Exit plan structure. Each exit plan should contain: (a) trigger conditions — specific events that activate the plan (e.g., "provider announces price increase exceeding 50%", "provider subject to regulatory prohibition", "provider SLA breaches exceed 3 incidents in 90 days"); (b) alternative provider assessment — a documented evaluation of at least one alternative that has been benchmarked against the current provider on the relevant workload, with performance comparison data; (c) migration path — step-by-step procedure for transitioning from the current provider to the alternative, with estimated timeline per step; (d) proof-of-concept results — evidence that the alternative provider has been tested with representative production workload, including accuracy comparison, latency comparison, and cost projection; (e) resource requirements — personnel, compute, and time required to execute the migration; (f) rollback procedure — how to revert to the original provider if the migration encounters problems.
• Annual exit plan testing. Conduct a tabletop exercise for each critical supplier annually. The exercise should simulate a specific trigger event (e.g., "Provider X announces market exit in 120 days") and walk through the exit plan step by step, identifying gaps, outdated assumptions, and resource conflicts. For the highest-criticality supplier, conduct a live migration test: route 5-10% of production traffic through the alternative provider for a defined period and compare performance metrics. Document the results and update the exit plan based on findings.

Anti-patterns to avoid:

• Confusing multi-model with multi-supplier. Using three different models from the same provider is not diversification — it is three dependencies on a single supplier. Concentration must be measured at the supplier level, not the model level.
• Measuring concentration only by agent count. An organisation may have 20 agents using Provider A and 5 agents using Provider B, suggesting 80% concentration. But if the 5 agents using Provider B process 90% of the organisation's financial transactions by value, the value-weighted concentration tells a different story. Concentration should be measured by multiple dimensions: agent count, transaction volume, business criticality, and revenue impact.
• Maintaining exit plans that have never been tested. An untested exit plan may contain invalid assumptions — the alternative provider's API may have changed, the benchmark results may be outdated, the estimated migration timeline may be based on a simpler workload than current production. Testing is the only way to validate that an exit plan is executable.
• Ignoring indirect concentration. Three AI providers running on the same cloud infrastructure represent a single point of failure. Two embedding providers using the same underlying model represent a single point of failure for model quality. Concentration analysis must trace dependencies beyond the direct supplier relationship.
• Treating exit planning as a one-time exercise. The AI supplier landscape changes rapidly — new providers enter, existing providers merge or pivot, pricing models change, regulatory requirements evolve. Exit plans must be reviewed and updated at least annually to remain viable.

Industry Considerations

Financial Services. DORA Article 28 requires financial entities to assess ICT third-party concentration risk. The EBA guidelines on ICT risk explicitly address concentration risk in cloud and AI service providers. Financial regulators expect firms to maintain exit strategies for critical ICT services, with demonstrated ability to migrate within contractual notice periods. AG-093 directly implements these regulatory expectations for AI-specific supply chain concentration.

Healthcare. NHS Digital Service Standard and similar frameworks require that critical clinical systems have business continuity plans that include supplier exit. For AI-powered clinical tools, this means maintaining viable alternatives to the AI model provider. The interdependency between model performance and clinical outcomes means that exit plan testing must include clinical validation of the alternative, not only technical benchmarking.

Critical Infrastructure. NIS2 Directive requirements for supply chain security extend to AI supply chain concentration. Critical infrastructure operators must demonstrate that no single AI supplier failure can disable safety-critical functions. This may require active multi-provider deployment for the most critical AI functions, with automated failover capabilities.

Maturity Model

Basic Implementation — The organisation has identified all AI suppliers and created a supplier concentration register documenting agent dependencies per supplier. Concentration thresholds are defined. Exit plans exist as documented procedures for suppliers exceeding the critical concentration threshold. Exit plans identify an alternative supplier but have not been tested with representative workloads. No abstraction layer exists — agent logic is tightly coupled to provider-specific APIs. This level provides visibility into concentration risk but limited operational readiness for provider transitions.

Intermediate Implementation — All basic capabilities plus: exit plans include benchmarked proof-of-concept results for at least one alternative per critical supplier. An abstraction layer decouples agent logic from provider-specific APIs for at least the primary model provider. Annual tabletop exercises test exit plans for critical suppliers. Indirect supplier concentration is analysed and documented. Concentration metrics include multiple dimensions (agent count, transaction volume, business criticality). Exit plans are reviewed and updated within 30 days of material changes in supplier relationships.

Advanced Implementation — All intermediate capabilities plus: live migration tests are conducted annually for the highest-criticality supplier, with production traffic routed through the alternative. Active multi-provider deployment routes a defined percentage of production traffic through alternative providers continuously, maintaining operational readiness. The abstraction layer supports all model providers used by the organisation, enabling provider switching by configuration change. Exit plan trigger conditions are monitored automatically, with alerts generated when conditions are approaching thresholds. Concentration risk feeds into enterprise risk management and board reporting. The organisation can demonstrate to regulators that no single supplier failure would cause unrecoverable disruption to business-critical agent operations within the defined recovery time objective.

7. Evidence Requirements

Required artefacts:

• Supplier concentration register. Structured record documenting: each AI supplier, the agents and functions dependent on that supplier, the concentration percentage by agent count, transaction volume, and business criticality, and the concentration risk rating. Format: structured data (JSON, YAML, or database export). Updated at minimum quarterly.
• Exit plans for critical suppliers. Documented exit plans for each supplier exceeding the critical concentration threshold, including: trigger conditions, alternative provider assessment with benchmark results, migration path, proof-of-concept results, resource requirements, and rollback procedure. Must be dated and versioned.
• Exit plan test records. Records of tabletop exercises and live migration tests, including: date, participants, scenario simulated, findings, gaps identified, and remediation actions. Minimum 12 months retention.
• Concentration threshold approvals. Records documenting the defined thresholds, the rationale for threshold values, and approval by appropriate management authority.

Retention requirements:

• Supplier concentration registers and exit plan test records: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Testing AG-093 compliance requires validating both the analytical framework for concentration measurement and the operational viability of exit plans.

Test 8.1: Supplier Concentration Register Accuracy

• Stimulus: Cross-reference the supplier concentration register against the component inventory (AG-087) and dependency registry (AG-014) to verify completeness and accuracy.
• Expected behaviour: Every AI supplier identified in the component inventory and dependency registry has a corresponding entry in the concentration register. Concentration percentages are mathematically accurate.
• Pass criteria: 100% of AI suppliers are represented. Concentration calculations are verifiable against source data. No supplier is omitted or miscategorised.
• Fail criteria: Any AI supplier is missing from the concentration register, or concentration percentages are materially inaccurate (deviation greater than 5 percentage points from verifiable data).

Test 8.2: Concentration Threshold Enforcement

• Stimulus: Simulate a scenario where adopting a new AI agent would cause a supplier's concentration to exceed the elevated or critical threshold.
• Expected behaviour: The governance process identifies the threshold breach before the agent is deployed and requires a documented risk acceptance or diversification plan.
• Pass criteria: The threshold breach is identified during the agent admission process. A documented governance response is required before deployment proceeds.
• Fail criteria: The new agent is deployed without the concentration threshold breach being identified or addressed.

Test 8.3: Exit Plan Completeness for Critical Suppliers

• Stimulus: Review exit plans for all suppliers classified as critical. Verify that each plan contains all required elements: trigger conditions, alternative assessment, migration path, proof-of-concept, resource requirements, and rollback procedure.
• Expected behaviour: All critical suppliers have complete exit plans with all required elements.
• Pass criteria: 100% of critical suppliers have complete, current exit plans. Proof-of-concept results are dated within the last 12 months.
• Fail criteria: Any critical supplier lacks an exit plan, or any exit plan is missing a required element, or proof-of-concept results are older than 12 months.

Test 8.4: Exit Plan Execution Viability

• Stimulus: Execute a tabletop exercise simulating the invocation of an exit plan for a critical supplier. Walk through each step, validating that the alternative provider is still available, the migration path is still valid, and the resource requirements are still achievable.
• Expected behaviour: The tabletop exercise completes with all steps validated. Any gaps or outdated assumptions are identified and documented for remediation.
• Pass criteria: The exit plan is confirmed executable with identified gaps documented and assigned for remediation. The estimated migration timeline is credible given current operational context.
• Fail criteria: The exit plan cannot be executed as documented — for example, the alternative provider has changed its API, the benchmark results are no longer representative, or the required resources are not available.

Test 8.5: Indirect Concentration Analysis

• Stimulus: Map the infrastructure dependencies of all direct AI suppliers to identify shared indirect dependencies (e.g., shared cloud provider, shared model provider behind different APIs).
• Expected behaviour: Indirect concentration is documented. Any indirect single point of failure is identified and risk-assessed.
• Pass criteria: The analysis identifies all shared indirect dependencies. The effective concentration (accounting for indirect dependencies) is documented alongside the direct concentration.
• Fail criteria: Indirect dependencies are not analysed, or a known shared dependency is not identified in the analysis.

Test 8.6: Exit Plan Currency

• Stimulus: Verify that all exit plans have been reviewed within the defined period (minimum annually) and within 30 days of any material supplier relationship change.
• Expected behaviour: All exit plans have review dates within the required period. Plans affected by material changes have been updated to reflect those changes.
• Pass criteria: 100% of exit plans are current. Plans affected by known supplier changes (pricing, terms, ownership) have been updated.
• Fail criteria: Any exit plan has not been reviewed within the required period, or a known material change has not been reflected in the exit plan.

Conformance Scoring

• Score 0: No supplier concentration governance exists — the organisation has no visibility into its AI supply chain concentration and no exit plans for any supplier.
• Score 1: Basic awareness — the organisation has identified its AI suppliers and has informal awareness of concentration risk, but no quantified register, defined thresholds, or documented exit plans exist.
• Score 2: Structured governance — a concentration register is maintained with defined thresholds, exit plans exist for critical suppliers with documented alternatives and migration paths, and plans are reviewed annually.
• Score 3: All Score 2 capabilities plus tested exit plans (tabletop and live migration), abstraction layer enabling provider switching, indirect concentration analysis, active multi-provider deployment, and automated concentration threshold monitoring with governance alerts.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
DORA	Article 28 (ICT Third-Party Risk — Concentration)	Direct requirement
DORA	Article 28(8) (Exit Strategies)	Direct requirement
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EBA Guidelines	ICT Risk — Outsourcing and Third-Party Dependencies	Supports compliance
PRA SS2/21	Outsourcing and Third-Party Risk Management	Direct requirement
FCA SYSC	8.1 (Outsourcing Requirements)	Supports compliance
NIS2 Directive	Article 21 (Supply Chain Security)	Supports compliance
NIST AI RMF	GOVERN 1.5, MANAGE 4.1	Supports compliance
ISO 42001	Clause 8.1 (Operational Planning and Control)	Supports compliance

DORA — Article 28 (ICT Third-Party Risk — Concentration)

Article 28 requires financial entities to identify and assess ICT concentration risk at entity and group level. This includes assessing concentration on critical ICT third-party service providers. For AI supply chain dependencies, this means quantifying the organisation's reliance on specific model providers, AI infrastructure providers, and AI service providers. AG-093's supplier concentration register and threshold framework directly implement this requirement. Article 28(8) specifically requires that contractual arrangements with ICT third-party service providers include exit strategies, aligning with AG-093's exit plan requirements.

PRA SS2/21 — Outsourcing and Third-Party Risk Management

SS2/21 requires PRA-regulated firms to manage concentration risk arising from outsourcing and third-party arrangements. The PRA expects firms to identify concentration risk at the firm level and at the market level (where many firms depend on the same provider). For AI service providers, this creates a dual obligation: the firm must manage its own concentration risk and must consider whether its dependencies contribute to systemic concentration risk. AG-093 implements the firm-level component; systemic concentration is a supervisory concern that AG-093's concentration data supports but does not fully address.

EU AI Act — Article 9 (Risk Management System)

The risk management system required by Article 9 must address supply chain risks for high-risk AI systems. Supplier concentration risk — the risk that a critical AI component becomes unavailable due to supplier failure, regulatory action, or commercial dispute — is a supply chain risk that must be identified, assessed, and mitigated. AG-093 provides the framework for this identification, assessment, and mitigation.

NIS2 Directive — Article 21 (Supply Chain Security)

Article 21 requires essential and important entities to implement supply chain security measures, including assessment of the security properties and resilience of products and services provided by third parties. For AI supply chain components, resilience assessment must include supplier concentration risk and the availability of alternatives. AG-093's concentration analysis and exit planning framework supports NIS2 supply chain security compliance.

NIST AI RMF — GOVERN 1.5, MANAGE 4.1

GOVERN 1.5 addresses organisational risk tolerance and risk management decisions. MANAGE 4.1 addresses risk treatment including diversification and contingency planning. AG-093 supports compliance by implementing the concentration risk assessment (GOVERN 1.5) and the exit planning and diversification framework (MANAGE 4.1) for AI supply chain dependencies.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	All agent operations dependent on the concentrated supplier — potentially organisation-wide where a single supplier underpins the majority of agent operations

Consequence chain: Without supplier concentration and exit governance, an organisation accumulates undocumented dependency on a small number of AI suppliers without viable alternatives. The failure mode is triggered by a supplier event — price increase, service disruption, regulatory action, terms of service change, market exit, or acquisition — that the organisation cannot respond to because it has no prepared alternative. The immediate operational impact is degradation or cessation of all agent operations dependent on the affected supplier. The business impact scales with concentration: at 70%+ concentration on a single supplier, the event affects the majority of the organisation's AI-powered operations. Financial impact includes: emergency procurement costs (typically 2-3x normal pricing for expedited alternatives), migration costs (engineering effort estimated at 3-6 months for a tightly-coupled integration), and revenue impact during the transition period. Regulatory impact includes potential enforcement action for inadequate third-party risk management under DORA, PRA SS2/21, or equivalent frameworks. Strategic impact includes loss of negotiating leverage with the remaining supplier and potential competitive disadvantage during the transition period. Cross-references: AG-014 (External Dependency Integrity) governs dependency validation; AG-091 (Third-Party Behaviour Drift Monitoring Governance) detects early signals of supplier quality changes; AG-045 (Economic Incentive Alignment Verification) governs the commercial relationship; AG-087 (Component Inventory Governance) provides the data foundation for concentration analysis.