AI Control Library / CF-03: AI Supply Chain & Third-Party Risk
Designation: Core | Control types represented: Operational and Technical
Control requirement
Maintain an inventory of AI supply chain dependencies and relationships, with owners, versions or service identifiers, purpose, data exposure, criticality and links to approved deployments. Reconcile it against actual use and changes.
Why this matters
A vendor list may omit the underlying model host, embedding provider or third-party tool receiving the information. Effective risk management needs visibility into the dependency paths that determine exposure and continuity.
How the control types work together
Operational controls define acceptance, responsibility and response. Technical controls verify artifacts, observe actual use or enforce data and action boundaries. The process must cover the same deployment that the technical mechanisms protect.
When it applies
Models, data sources, hosted APIs, libraries, plugins, evaluation services, subprocessors and supporting platforms used in AI workflows.
Tailor review depth to information sensitivity, granted authority and business dependence. Record what the organization can test directly, what relies on provider evidence and how material visibility gaps affect the acceptance decision.
Ownership
The system owner is accountable for deployment coverage; supplier-risk and asset-management teams maintain linked dependency records.
Implementation guidance
- Record each dependency’s identity, supplier, source, version or endpoint, intended role, internal owner and assessment status.
- Map relationships to deployed services and identify data categories, access permissions, criticality and material upstream dependencies.
- Use manifests, procurement records and authorized technical discovery to reconcile the inventory; record provider visibility limits explicitly.
- Update records after onboarding, configuration changes, provider changes and retirement, removing obsolete access while retaining required history.
How to verify it
Use representative deployment records and authorized controlled tests. Establish the assessed service, artifact version and acceptance conditions before interpreting results; do not extend evidence beyond the boundary it covers.
| Test | Expected result |
|---|---|
| Trace a live AI request or deployment manifest | Material model, data and tool dependencies appear in the inventory. |
| Inspect a changed endpoint or library | The inventory and relevant risk review are updated. |
| Review a retired integration | Access is removed and records retain the historical relationship. |
Record a finding when a required result cannot be demonstrated or actual practice differs materially from the accepted conditions. Assign corrective action and verify the affected boundary before closing the issue.
Evidence to retain
- Dependency inventory and relationship map
- Deployment and service references
- Reconciliation results
- Change and retirement records
Protect supplier-confidential information, credentials and personal data in these records. Preserve enough version and scope information to establish which service or artifact the evidence supports.
If the control fails
Escalate unknown material dependencies to system and supplier-risk owners. Restrict undisclosed data transfers or consequential tool access until ownership and assessment are established.
Example in practice
Hypothetical example: A chatbot uses separate providers for text generation and embeddings. Reconciliation discovers that sensitive text reaches both, prompting assessment of the second provider rather than relying on the first vendor’s approval.
Related controls
- CF03-001: AI Supply Chain Risk Management Policy
- CF03-006: AI Supply Chain Risk Assessment
- CF03-013: AI Service Bill of Materials (AI-BOM)
Framework mappings
- CSA AICM (STA-08)
- NIST AI RMF (MAP 1.6)
- EU AI Act (Art. 9(2)(b))
- ISO 42001 (Cl. 8.3, A9.1)
Review and maintenance
Review at the interval approved by the control owner and after relevant supplier, component, contract, access or deployment changes. Reassess material incidents and new evidence, updating acceptance conditions and verifying corrective actions where required.
Back to AI Supply Chain & Third-Party Risk
Version 1.0