When Google restricted Meta’s access to Gemini in March 2026, the question moved from theoretical to operational — AI infrastructure denial was now a boardroom reality, not a white-paper scenario. If a company with Meta’s engineering resources can be cut off, what stops it happening to your business?
Most organisations accumulate AI dependencies faster than they recognise them. Models, orchestration platforms, agentic workflows. No single function measures the aggregate exposure. By the end of this article you’ll have a framework for auditing every external AI dependency and a method for determining which concentrations are acceptable and which demand action.
The framework starts with a diagnostic question: which of your dependencies actually threaten the business?
How do you know if your AI dependencies are a competitive vulnerability?
A dependency becomes a competitive vulnerability when four conditions converge: the provider competes with you (or could realistically enter your space), switching costs are high, the provider has contractual rights to restrict or reprioritise access, and the dependency sits in a revenue-generating or competitively sensitive workflow.
Anthropic, Google, and OpenAI all explicitly forbid using their services to build competing products, and all three enforce these terms. Anthropic cut off Windsurf when it was being acquired by OpenAI, cut off OpenAI’s access to Claude models when they were used to test GPT-5, and blocked xAI’s access within a twelve-month period.
The Google-Meta case scored high on every dimension. The structural conflict between AI model providers and their own customers is no longer hypothetical.
Score each dependency on a simple matrix. High competitive posture plus high switching cost is your priority remediation target. High posture with low switching cost warrants monitoring. Low posture with high switching cost means negotiate. Low on both is acceptable. But not all lock-in works the same way, and the matrix flattens a distinction that changes your mitigation strategy.
What is the difference between model-layer and platform-layer lock-in?
Model-layer lock-in means your application depends on a specific model API. Switching requires rewriting integration code. It’s significant but bounded, and responds to abstraction layers.
Platform-layer lock-in is a different order of problem. The AI capability is inseparable from the platform your business runs on. Salesforce Agentforce agents aren’t portable outside Salesforce. ServiceNow AI layered into ITSM configurations represents tens of thousands of engineering hours. These migrations run eighteen to thirty-six months.
Model-layer lock-in responds to abstraction layers. Platform-layer lock-in requires architectural decisions about where your AI capability boundary sits. Agentic AI pushes the problem further. When agent memory and tool access accumulate in provider-proprietary infrastructure, model-layer dependency becomes platform-layer dependency. The countermeasure is context portability: storing agent memory, interaction history, and behavioural calibration in your own infrastructure, in formats you control.
How do you quantify the real cost of switching AI providers once workflows are embedded?
Switching costs accumulate across five dimensions. To get a practical read on the aggregate, score each dimension low, medium, or high. A dependency scoring high on three or more dimensions warrants an exit timeline.
Data gravity: what enterprise data and interaction history live in the provider’s infrastructure? Proprietary memory systems without export APIs are one of the largest exit barriers. Integration depth: how many internal services call the provider’s API directly?
Fine-tuning investment: custom-tuned models and prompt libraries represent sunk effort that can’t be transferred. Team expertise: how many engineers know the current provider’s SDK and failure modes? Contractual commitments: minimum spend, egress fees, termination penalties. Often the smallest component but usually the only ones tracked.
The aggregate is always larger than anticipated, and for agentic workflows it’s beyond an API-key swap. Meta’s experience shows these costs are real.
What does an AI supply chain dependency audit look like in practice?
The audit follows four phases and produces a named output: the Model Provider Diversification Roadmap.
Phase one: map every external AI dependency, including unsanctioned shadow AI usage by employees. Dependencies you don’t know about carry the same risks with zero mitigation.
Phase two: score each dependency on the four vulnerability dimensions. Overlay CADA’s sovereignty framework for EU workloads; providers who can’t meet Tier 3 or 4 carry regulatory exposure that compounds the risk.
Phase three: prioritise the highest-risk concentrations. The EU Data Act’s switching-fee elimination target of September 2027 is a regulatory forcing function for your timelines.
Phase four: produce a roadmap with specific actions, owners, and deadlines. Embed it in procurement and architecture review. The regulatory dimension of this competitive dynamic means accounting for forces beyond any single vendor.
The audit will identify dependencies whose risk profile demands contract renegotiation. Here are the questions that surface those risks before you sign.
What questions should you ask AI model providers before signing an enterprise contract?
Most AI API contracts lack portability, continuity, and competitive-exclusion provisions. The questions you ask during procurement determine your leverage later.
Access continuity: does the provider reserve the right to deprioritise or terminate access based on internal capacity decisions? Do enterprise customers get guarantees that distinguish them from API-tier customers?
Competitive exclusion: does the provider compete in the application layer? Does it supply your competitors? What firewalls separate the model-provision business from the application business? Has the provider ever restricted a customer’s access for competitive reasons?
Portability: are model outputs, fine-tuning artefacts, and agent configurations exportable? What’s the demonstrated migration path, not the theoretical one?
Indemnity: does the contract include indemnity for access denial that causes business disruption? These provisions are absent from most current AI API agreements. As the structural conflict analysis established, the competitive posture of your provider is the organising concern. These questions would have surfaced the Google-Meta risk before the restriction letter arrived.
When should you build on proprietary model APIs versus adopt open-weight alternatives?
Most organisations will run a hybrid portfolio, and the audit framework determines the mix. Evaluate each workload against six criteria:
- Capability: does an open-weight model meet the performance threshold? For most standard agent tasks, Llama 5 is production-ready; closed frontier models still lead on complex reasoning.
- Operational cost: open-weight inference is ten to fifteen times cheaper per token, but self-hosting adds engineering headcount.
- Switching cost: open-weight models are inherently more portable.
- Regulatory exposure: Mistral‘s EU jurisdiction matters for CADA Tier 3 and 4 workloads. Zhipu GLM-5, a Chinese open-weight model with capabilities similar to US models, carries different jurisdictional considerations.
- Competitive posture: as established in the vulnerability test above, Anthropic and OpenAI increasingly compete in the application layer. Meta releases Llama but doesn’t sell enterprise AI services.
- Ecosystem maturity: Llama has the strongest community and tooling. Mistral and GLM-5 have narrower ecosystems.
Martin Casado’s infrastructure-commoditisation argument provides useful context here: AI infrastructure appears to be following the cloud pattern of heavy capex and thin margins, with value migrating to the application layer. If that holds, proprietary APIs face the same margin compression that reshaped cloud infrastructure.
The framework points toward a hybrid approach: providers with high competitive posture get abstracted or replaced, low-risk proprietary APIs remain where justified, and open-weight models serve workloads where portability and sovereignty matter more than frontier performance.
Regulation adds a dimension the six criteria don’t fully capture: jurisdiction and sovereignty. That brings us to CADA.
How does the EU’s Cloud and AI Development Act change your dependency risk calculus?
CADA establishes a four-tier sovereignty framework for cloud and AI services. Tier 1 is standard commercial cloud. Tier 2 requires EU-based operations with data protections. Tier 3 demands EU-headquartered providers with no non-EU government access. Tier 4 requires fully EU-controlled infrastructure and supply chain.
US hyperscalers are barred from Tiers 3 and 4 because ownership and personnel requirements can’t be satisfied through contractual workarounds. The audit must treat EU workloads as a separate dependency dimension with a narrower provider pool.
Even if your company isn’t in scope today, CADA is the leading edge of a regulatory trend. Australia and other jurisdictions are watching the EU model closely. There’s a strategic upside: a provider who meets Tier 3 or 4 requirements is structurally less likely to be a competitor. Sovereign providers like GAIA-X-aligned European clouds are infrastructure providers, not application-layer competitors. The regulatory landscape is reshaping the competitive playing field in ways that directly affect your supply chain decisions.
The audit framework converts an overwhelming problem into a prioritised roadmap. AI dependency risk spans model-layer and platform-layer lock-in, hidden switching costs across five dimensions, provider competitive posture, and evolving sovereignty regulation. The framework addresses all of them.
The Google-Meta cutoff was the first visible instance of a structural dynamic that will repeat. Organisations that complete this audit before receiving their own restriction letter have options — and that’s the difference the AI infrastructure denial landscape demands.
The audit lives inside procurement, architecture review, and quarterly risk assessment cadences. The framework is what makes the complexity tractable.
Frequently Asked Questions
Who should own the AI supply chain dependency audit?
The CTO or VP of Engineering should sponsor it, but the audit itself needs cross-functional ownership spanning procurement, architecture, and security. A single function cannot see the full picture: procurement sees contracts but not integration depth, architecture sees the stack but not the commercial terms, and security sees risk but not competitive posture. The most effective model is a working group chaired by the CTO’s office with representation from all three functions, producing the Model Provider Diversification Roadmap as a shared artifact that feeds into architecture review and procurement governance.
How long does a full dependency audit take?
A first-pass audit mapping all sanctioned dependencies, scoring them against the four-dimension vulnerability test, and producing an initial prioritised roadmap typically takes four to six weeks for a midsize organisation. The larger variable is shadow AI discovery: surfacing unsanctioned dependencies that procurement never approved can extend the mapping phase by two to three weeks. The audit is not a project with a finish line, but the initial cycle that produces a board-ready artifact should be measured in weeks, not months.
What do you do if you discover a critical vulnerability mid-contract with a provider?
Do not wait for the contract to expire. Begin parallel-track remediation immediately: one track renegotiates the existing contract for portability rights, data-egress commitments, and notice-period extensions; the other track begins architectural abstraction of the dependency, starting with the highest-risk workloads. The worst-case scenario is discovering a critical vulnerability and doing nothing because the contract has eighteen months remaining. A provider who knows you are actively building portability has a different negotiating posture than one who believes you are locked in.
Can small organisations with limited resources still run a meaningful audit?
Yes. A scaled-down version focusing on the two highest-impact dimensions (provider competitive posture and switching cost) across the top five dependencies will surface the most urgent risks without requiring the full four-phase process. The key discipline is prioritisation: identify which dependencies sit in revenue-generating or competitively sensitive workflows and score those first. A spreadsheet and an afternoon with the engineering lead and procurement contact will produce more actionable insight than pretending the problem requires a consultancy engagement.
Is it realistic to migrate all workloads to open-weight models?
No, and the article’s recommendation is explicitly a hybrid portfolio, not a wholesale migration. Open-weight models reduce dependency risk but increase operational burden: self-hosting inference infrastructure, managing model updates, and maintaining evaluation pipelines all require engineering investment that proprietary APIs absorb. The audit framework determines the optimal mix: high-competitive-posture providers get abstracted or replaced, low-risk proprietary APIs remain where capability requirements justify them, and open-weight models serve workloads where portability and sovereignty matter more than frontier performance.
How does shadow AI complicate the dependency audit?
Shadow AI (unsanctioned model usage by individual employees or teams outside procurement and IT governance) creates dependencies the organisation does not know it has. These dependencies carry all the same risks as sanctioned ones (competitive exposure, switching cost, contractual vulnerability) but with zero mitigation. Discovery requires both technical methods (API gateway logs, expense-report analysis, browser-extension audits) and organisational methods (team surveys, engineering-manager interviews). The audit is incomplete until shadow dependencies are surfaced, because the dependency graph you cannot see is the one most likely to cause a crisis.
How often should the audit be updated?
Quarterly, with a lighter monthly review cycle for the highest-risk dependencies. The provider landscape shifts continuously: new models launch, competitive postures evolve, regulatory frameworks like CADA tighten, and your own dependency graph changes with every new feature and integration. Treating the audit as a one-off exercise means the roadmap decays within weeks. Embedding it in quarterly risk-assessment cadences alongside existing security and compliance reviews keeps it current without creating a separate governance burden.
What is the first step if you receive a provider restriction letter?
Activate your pre-built migration playbook. The organisations best positioned to respond are those that completed the audit before the letter arrived and already know which workloads are affected, what the switching cost is, and which alternative providers are viable. If you do not have a playbook, the first step is triage: identify every integration touchpoint with the provider, assess which workflows are revenue-generating or customer-facing, and begin parallel-track migration on the highest-priority workloads while legal engages the provider on notice-period and data-egress terms.
How do you make the business case for investing in dependency risk mitigation?
Frame it in terms the board already understands: operational resilience and negotiating leverage, not abstract risk. The business case has three components. First, the cost of an unplanned migration (the Google-Meta case provides a reference point). Second, the bargaining power that architectural portability creates in contract renewals (providers price differently when they know switching is feasible). Third, the regulatory exposure if CADA or equivalent legislation constrains your current providers. The audit converts each of these from a vague concern into a specific, quantified line item with a remediation cost and timeline.
How does an AI dependency audit fit alongside existing risk management frameworks like NIST AI RMF?
It complements them by adding a competitive and architectural dimension that standard risk frameworks do not address. NIST AI RMF focuses on trustworthiness characteristics (validity, safety, security, fairness) but does not evaluate whether your model provider competes with you in the application layer or whether your dependency is platform-layer rather than model-layer. The audit framework sits alongside NIST AI RMF and similar frameworks as a separate lens: use the RMF for model-level trustworthiness assessment, and use the audit for supply-chain concentration and competitive-exposure assessment. Both are necessary; neither is sufficient alone.
What about AI features embedded in SaaS platforms you cannot directly control?
This is platform-layer lock-in in its purest form, and the mitigation strategy is architectural rather than contractual. When Salesforce embeds Agentforce agents in your CRM or Microsoft weaves Copilot into M365, you cannot abstract the AI capability away from the platform because the dependency includes your business processes, custom configurations, and team workflows. The audit should flag these as the highest-weight dependencies (exit costs measured in business-process migration timelines of eighteen to thirty-six months), and the remediation is a strategic architecture decision: where does your organisation’s AI capability boundary sit relative to platform-specific implementations, and what would it cost to redraw that boundary.
