Foundation model dependency is the condition where critical business or public-interest workflows rely on externally controlled models for inference, updates or content generation. It creates concentration risk because the consuming organisation may not control behaviour changes, data handling or recovery options.
What Foundation Model Dependency Means
Foundation model dependency is not just “using an AI model.” It is a structural reliance on an external provider for core inference, model updates, or generation behaviour, which means the consuming organisation inherits upstream decisions it does not fully control.
This matters because the dependency sits in the operational path of important workflows. If the provider changes the model, alters policy, throttles access, or removes a capability, the consumer may see immediate impact even when its own systems have not changed.
Why This Creates Concentration Risk
The central risk is concentration: many organisations can end up dependent on the same model family, API, or hosting chain for similar business functions. That creates correlated failure, correlated policy shifts, and a shared exposure to outages, content-filter changes, and service terms that are outside the consumer’s control.
Concentration risk is especially important when the model shapes customer-facing decisions, internal knowledge work, or public-interest outputs. In those settings, a single upstream change can affect quality, availability, legal posture, and trust at the same time.
What Actually Becomes Dependent
Dependency can extend beyond the model weights themselves. Organisations may rely on the provider’s moderation layer, safety tuning, retrieval settings, logging behaviour, billing controls, or update cadence, all of which can alter the effective system without a local code change.
That is why foundation model dependency is partly a governance problem, not only a technical integration problem. The real question is what the business can still guarantee if the provider changes behaviour, access conditions, or retention rules.
Operational Consequences and Control Expectations
When a workflow depends on an external foundation model, resilience planning should assume provider-side change as a normal condition rather than an edge case. Organisations need clear fallbacks for degraded service, model substitution, human review, or restricted mode operation when the upstream dependency becomes unstable.
Documentation should also distinguish between what the organisation controls and what it merely consumes. For example, it should be clear whether the provider handles updates, whether outputs are stored or reused, and which business processes would be disrupted if the model changed behaviour overnight. For vendor scoping and contract questions around this kind of dependency, the Third-Party AI Risk Guide is the most relevant internal reference.
Risk and Threat Considerations
Foundation model dependency creates exposure to provider concentration, sudden model drift, service interruption, and policy changes that can break downstream workflows without warning. It also increases the blast radius of a single supplier compromise, since many customers may consume the same model or update channel.
Failure mechanism: The consumer’s business process inherits upstream changes in inference behaviour, data handling, or availability, while local controls may not detect the shift until outputs, logs, or service quality deteriorate.
Impact: Decisions can become inconsistent, regulated workflows can fail, recovery can slow, and the organisation may lose the ability to reproduce or explain model-driven outcomes. In supply-chain cases, dependency also broadens the trust boundary, as shown by incidents such as the LiteLLM PyPI package breach and by the broader open-source dependency posture described by OpenSSF.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI 600-1, NIST AI RMF, CSA Cloud Controls Matrix and NIST CSF 2.0 set the technical controls, while ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI 600-1 | Generative AI Profile | Addresses GenAI governance, provenance, and model risk for externally supplied models. |
| Recommendation — Apply the profile to govern model changes, provenance, and incident handling for dependent workflows. | ||
| NIST AI RMF | AI Risk Management Framework | Covers AI governance, mapping, measuring, and managing dependency-related AI risks. |
| Recommendation — Use the framework to identify, measure, and manage upstream model dependency risk. | ||
| ISO/IEC 42001:2023 | 8.1 — Operational planning and control | Requires controlled operation of AI systems whose behaviour depends on external providers. |
| Recommendation — Define operational controls for provider changes, fallback modes, and ongoing oversight. | ||
| CSA Cloud Controls Matrix | GRC — Governance, Risk and Compliance | Supports vendor risk governance for externally controlled AI services and dependencies. |
| Recommendation — Assess provider concentration and assign formal ownership for model dependency risk. | ||
| NIST CSF 2.0 | GV.SC-03 — Cyber Supply Chain Risk Management | Covers supplier and third-party dependencies that can alter service availability or behaviour. |
| Recommendation — Track model providers as supply-chain dependencies and review their resilience and change controls. | ||
Practitioner Guidance
Governance implication: Treat the model provider as a material dependency, not just a feature supplier. Ownership should extend to vendor risk review, service continuity assumptions, data-handling terms, and the conditions under which the organisation can switch models or revert to a safer operating mode.
What to watch for: A dependency becomes more material as more workflows, teams, or customers rely on a single model API, especially when the same provider also controls updates, moderation, or retention settings. That is the point at which resilience planning and contractual scope should be reviewed together.