AIPOM Platform Dependency Audit
What Is It
Map and test the external and internal dependencies that shape value, reliability, control, and exit: models, vendors, data, infrastructure, integrations, talent, contracts, pricing, evaluation, and operational knowledge.
Why Use It
A technically successful pilot can become economically or operationally fragile when one provider changes price, behavior, access, terms, region, or service. Dependency is not automatically bad; unmanaged dependency is the problem.
When to Use It
Use before material procurement, scale, renewal, architecture lock-in, sensitive-data transfer, or increased autonomy. Scope the audit to the decision rather than producing a generic vendor inventory.
What It Produces
- Dependency, ownership, and concentration map
- Change, outage, degradation, and exit scenarios
- Portability evidence and switching cost
- Accept, mitigate, diversify, constrain, renegotiate, or exit recommendation
Who Should Participate
Include the investment owner, architecture and engineering, product, procurement, finance, security, data, operations, and governance partners.
Evidence to Bring
Bring architecture, data flows, contracts, service terms, pricing, usage, evaluations, incidents, operational runbooks, portability tests, skills, and migration estimates. Contract language without tested operations is partial evidence.
How to Do It
- Name the investment decision and critical capabilities.
- Map upstream, runtime, downstream, organizational, and contractual dependencies.
- Record owner, substitutability, concentration, data movement, and failure consequence.
- Test price, model change, outage, quality regression, access loss, policy change, and provider-exit scenarios.
- Examine portability of prompts, context, data, evaluations, integrations, logs, and operating knowledge.
- Estimate switching time, cost, downtime, retraining, revalidation, and control changes.
- Identify dependencies that constrain scale, autonomy, geography, or data use.
- Recommend accept, mitigate, diversify, constrain, renegotiate, or exit actions.
- Assign owners, evidence tests, monitoring, and decision triggers.
Key Concepts
- Portability is demonstrated through tests, not architecture diagrams.
- Multi-vendor designs can add complexity without reducing critical concentration.
- Organizational expertise is a dependency.
- Dependency exposure belongs in economics and stage gates.
Organizational Applications
Use for foundation-model providers, cloud and vector infrastructure, data vendors, orchestration platforms, evaluation services, and internal shared platforms.
Common Pitfalls
- Treating vendor availability as portability
- Mapping technology but not contracts or skills
- Ignoring model behavior changes
- Assuming multi-cloud eliminates concentration
- Omitting re-evaluation and migration cost
- Creating mitigations with no trigger or owner
Combine With
Use aipom-economic-case-builder to price exposure, aipom-investment-stage-gates to constrain funding, and aipom-initiative-readiness-review to integrate critical gaps.
Assets and Templates
- Dependency audit template
- Synthetic worked example
- Weak example
Sources
- NIST AI Resource Center, AI RMF Core. Manage 3 addresses monitoring third-party AI resources and applying documented controls. Accessed July 17, 2026. NIST notes that AI RMF 1.0 is under revision.
1---2name: aipom-platform-dependency-audit3description: Assess model, vendor, data, infrastructure, integration, talent, switching, and portability dependencies that can change an AI investment decision.4---56# AIPOM Platform Dependency Audit78## What Is It910Map and test the external and internal dependencies that shape value, reliability, control, and exit: models, vendors, data, infrastructure, integrations, talent, contracts, pricing, evaluation, and operational knowledge.1112## Why Use It1314A technically successful pilot can become economically or operationally fragile when one provider changes price, behavior, access, terms, region, or service. Dependency is not automatically bad; unmanaged dependency is the problem.1516## When to Use It1718Use before material procurement, scale, renewal, architecture lock-in, sensitive-data transfer, or increased autonomy. Scope the audit to the decision rather than producing a generic vendor inventory.1920## What It Produces2122- Dependency, ownership, and concentration map23- Change, outage, degradation, and exit scenarios24- Portability evidence and switching cost25- Accept, mitigate, diversify, constrain, renegotiate, or exit recommendation2627## Who Should Participate2829Include the investment owner, architecture and engineering, product, procurement, finance, security, data, operations, and governance partners.3031## Evidence to Bring3233Bring architecture, data flows, contracts, service terms, pricing, usage, evaluations, incidents, operational runbooks, portability tests, skills, and migration estimates. Contract language without tested operations is partial evidence.3435## How to Do It36371. Name the investment decision and critical capabilities.382. Map upstream, runtime, downstream, organizational, and contractual dependencies.393. Record owner, substitutability, concentration, data movement, and failure consequence.404. Test price, model change, outage, quality regression, access loss, policy change, and provider-exit scenarios.415. Examine portability of prompts, context, data, evaluations, integrations, logs, and operating knowledge.426. Estimate switching time, cost, downtime, retraining, revalidation, and control changes.437. Identify dependencies that constrain scale, autonomy, geography, or data use.448. Recommend accept, mitigate, diversify, constrain, renegotiate, or exit actions.459. Assign owners, evidence tests, monitoring, and decision triggers.4647## Key Concepts4849- Portability is demonstrated through tests, not architecture diagrams.50- Multi-vendor designs can add complexity without reducing critical concentration.51- Organizational expertise is a dependency.52- Dependency exposure belongs in economics and stage gates.5354## Organizational Applications5556Use for foundation-model providers, cloud and vector infrastructure, data vendors, orchestration platforms, evaluation services, and internal shared platforms.5758## Common Pitfalls5960- Treating vendor availability as portability61- Mapping technology but not contracts or skills62- Ignoring model behavior changes63- Assuming multi-cloud eliminates concentration64- Omitting re-evaluation and migration cost65- Creating mitigations with no trigger or owner6667## Combine With6869Use `aipom-economic-case-builder` to price exposure, `aipom-investment-stage-gates` to constrain funding, and `aipom-initiative-readiness-review` to integrate critical gaps.7071## Assets and Templates7273- [Dependency audit template](template.md)74- [Synthetic worked example](examples/worked-example.md)75- [Weak example](examples/weak-example.md)7677## Sources7879- NIST AI Resource Center, [AI RMF Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/). Manage 3 addresses monitoring third-party AI resources and applying documented controls. Accessed July 17, 2026. NIST notes that AI RMF 1.0 is under revision.
Dean Peters