AI Supply Chain Risk: Governance and Response in Model Dependencies

1. Structural Issues Behind the Incident

According to public reports, a customer purchasing AI services raised objections to the terms of use set by a provider. After negotiations broke down, the customer initiated a supply chain risk determination against the provider, while the relevant systems continued to run for a period of time. Some details in the reports have not been independently verified. This article does not judge the rights and wrongs of the specific incident; it discusses only the general technical problem it exposes: usage restrictions are written into contracts but not necessarily into systems, and dependency has formed without necessarily having an exit.

These problems are also common inside enterprises. A customer support system connects to an external model, and the contract states that certain scenarios must not be used, yet there is no constraint at the code level. An analytics platform depends on a single provider, and only after the provider changes its terms does the team discover that migration costs far exceed expectations.

2. Technical Breakdown of Three Types of Conflict

1. Usage Boundary Conflicts

Providers typically define acceptable uses through terms of service, while customers establish internal rules based on their own business and legal frameworks. When the two are inconsistent, an enforcement gap appears. Contract terms are legal constraints; they cannot by themselves prevent an API call. To make boundaries effective, terms need to be translated into checkable policies, such as validating business scenario tags before a call and recording the approval basis for each call.

2. Control Ownership Conflicts

When a capability is relied on by multiple parties, who has the right to decide how it is used must be agreed in advance. A common approach is layered decision-making: the business side proposes the use case, legal and security teams assess risk, and the technical team implements and keeps records. High-risk uses should include manual approval steps and must not be fully delegated to automated processes.

3. Dependency Inertia

Once a system integrates a model, call sites become scattered across multiple services. When replacing the model, prompts, output formats, and evaluation criteria all need to be adjusted again. The deeper the dependency, the slower the switch and the weaker the bargaining power. The core of supply chain risk is the inability to switch, not just a single service outage.

3. Governance Principles for High-Sensitivity Scenarios

For scenarios involving lethal autonomous decision-making, mass surveillance, and similar high-sensitivity uses, technical teams should prioritize the following principles:

• Human-in-the-loop: Critical decisions must have traceable human confirmation; the system only provides recommendations.
• Purpose limitation: Data may be used only for registered purposes; calls outside the registered scope require new approval.
• Data minimization: Pass only the fields required to complete the task, and avoid bringing sensitive data such as identity information into prompts.
• Auditability: Record the model version, purpose tag, approver, and timestamp for each call.

These principles are independent of any specific vendor and should serve as an internal governance baseline regardless of the model used.

4. Supply Chain Risk Assessment Framework

When assessing AI dependencies, teams can review six dimensions one by one.

Dimension	Core Question	High-Risk Signal
Substitutability	Can the organization switch to an alternative within two weeks?	No alternative; dozens or more call sites
Terms stability	How often do terms change, and is advance notice given?	Unilateral changes allowed; no notice period
Data boundary	Are storage, training, and cross-border scopes for input and output data clearly defined?	Contract does not specify data use
Availability	Can the business operate in degraded mode during an outage?	No degradation path
Auditability	Can call logs and version information be obtained?	Logs cannot be exported
Compliance alignment	Have use cases been legally reviewed and do they meet regulatory requirements?	Use cases have not been assessed

Scores can be quantified to make cross-team comparison and periodic review easier:

from dataclasses import dataclass
@dataclass
class ModelDependency:
    name: str
    call_sites: int           # Number of locations in code that call this model
    has_fallback: bool        # Whether a usable alternative implementation exists
    policy_change_risk: int   # Risk of terms changes or service termination, 1 to 5
    data_sensitivity: int     # Sensitivity level of processed data, 1 to 5
def risk_score(dep: ModelDependency) -> float:
    score = dep.policy_change_risk * 2 + dep.data_sensitivity * 2
    score += min(dep.call_sites / 10, 3)   # More call sites mean higher switching cost, capped at 3 points
    if not dep.has_fallback:
        score *= 1.5
    return round(score, 1)
deps = [
    ModelDependency("support-chat", call_sites=12, has_fallback=True,
                    policy_change_risk=3, data_sensitivity=4),
    ModelDependency("risk-assessment", call_sites=4, has_fallback=False,
                    policy_change_risk=4, data_sensitivity=5),
]
for d in sorted(deps, key=risk_score, reverse=True):
    print(d.name, risk_score(d))

The score is only a sorting tool; the number itself has no absolute meaning. Its value is in helping teams address high-scoring items first and update the data regularly.

5. Technical Implementation: Decoupling and Controlled Invocation

Avoiding direct dependency of business code on a specific provider’s interface is the most effective engineering approach to reducing supply chain risk. The practice is to define a unified invocation protocol and place the specific implementation in an adapter layer.

from typing import Protocol
class TextGenerator(Protocol):
    def generate(self, prompt: str, max_tokens: int) -> str: ...
class ModelRouter:
    def __init__(self, primary: TextGenerator, fallback: TextGenerator | None = None):
        self.primary = primary
        self.fallback = fallback
    def generate(self, prompt: str, max_tokens: int = 512) -> str:
        try:
            return self.primary.generate(prompt, max_tokens)
        except Exception:
            if self.fallback is None:
                raise
            # A fallback switch must be logged because output characteristics may have changed
            return self.fallback.generate(prompt, max_tokens)

Business code depends only on the TextGenerator protocol; when changing providers, only the adapter needs to be replaced. Note that the fallback model’s output may differ from that of the primary model. In regulated scenarios, fallback switching must be logged and confirmed through evaluation as producing acceptable results; it must not happen silently.

Usage boundaries should also exist as code, not only in documentation:

ALLOWED_PURPOSES = {"customer_support", "document_summary"}
REQUIRES_APPROVAL = {"risk_assessment"}
def check_purpose(purpose: str, approved: bool = False) -> None:
    if purpose not in ALLOWED_PURPOSES | REQUIRES_APPROVAL:
        raise PermissionError(f"Unregistered purpose: {purpose}")
    if purpose in REQUIRES_APPROVAL and not approved:
        raise PermissionError(f"Purpose requires approval: {purpose}")

Run the check before each call and archive the check result together with the call record. In this way, the compliance team can trace the basis for any individual call.

6. Migration Process

When planning a switch, consider advancing through the following steps:

1. Inventory call sites: Find all code paths that directly or indirectly call the model, including scheduled jobs and third-party integrations.
2. Build an evaluation set: Use real business samples to construct test data covering common scenarios and edge cases, and define pass criteria.
3. Shadow run: The alternative model processes the same requests in parallel with the existing model, recording results only without affecting production output.
4. Canary switch: Roll out gradually by percentage or business line, monitoring quality metrics and error rates at each step.
5. Prepare rollback: Keep the old adapter and configuration switch so that recovery can happen within minutes if problems arise.
6. Decommission and archive: After confirming stability, remove the old interface and retain call logs and evaluation reports for audit.

The shadow run phase is often overlooked, but it can expose differences in output format and quality in advance, usually at a lower cost than fixing issues afterward.

7. Contract and Organizational Considerations

Technical measures need to be supported by contracts and processes. When purchasing or renewing, consider specifying the following terms:

• Allowed and prohibited uses, with examples of typical scenarios, to avoid different interpretations of boundaries.
• Notice periods and objection mechanisms for term changes.
• Rules for data processing, retention, and deletion, and whether data is used for model improvement.
• Data export and transition arrangements when service terminates.
• Audit rights, or requirements for the provider to regularly provide third-party audit reports.

At the organizational level, establish a cross-functional AI governance group including technology, legal, security, and business leaders. The group maintains the dependency register, reviews risk scores quarterly, and approves new high-risk use cases.

8. Practical Checklist

• Maintain an AI dependency register recording each model’s purpose, call sites, data types, and owner.
• Set policy checks for high-risk use cases; reject unregistered or unapproved calls directly.
• Maintain at least one usable fallback for each critical capability.