AI Control Library / CF-03: AI Supply Chain & Third-Party Risk
Designation: Core | Control types represented: Operational and Technical
Control requirement
Maintain a versioned AI service bill of materials identifying the components and relationships needed to understand a deployed service’s supply chain, reproduce its approved composition where feasible and assess affected dependencies when risks emerge.
Why this matters
A package manifest alone may omit model weights, adapters, retrieval stores and external tool endpoints. A service-level component record connects those pieces to the approved deployment rather than treating the model as an isolated artifact.
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
AI deployments composed of models, libraries, runtime images, adapters, retrieval resources, hosted services and plugins; record visibility limits for externally managed components.
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; platform and build teams produce and reconcile the record with supplier input.
Implementation guidance
- Define required fields for component identity, supplier, version or revision, role, integrity reference, license and dependency relationship.
- Capture the model, adaptation layers, runtime, libraries, retrieval resources and service endpoints that materially affect the deployed composition.
- Generate or collect records through the build and deployment workflow, linking the bill to the approved system baseline.
- Update after relevant changes and query the record during vulnerability, provenance or supplier incidents; document opaque components and compensating visibility.
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 the live baseline | Material components and their relationships appear in the service bill. |
| Introduce a component update | The versioned bill changes with the deployment rather than lagging behind it. |
| Identify an affected dependency in a scenario | The organization can locate impacted deployments and accountable owners. |
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
- Versioned AI service bill
- Build and deployment references
- Supplier component information
- Reconciliation and incident queries
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 missing material components or untraceable versions to platform and service owners. Restrict unsupported upgrades or affected functions until the deployed composition can be assessed.
Example in practice
Hypothetical example: A tokenizer vulnerability is reported. The service bill identifies which assistants use the affected package revision and model wrapper, allowing targeted action instead of treating every model as equally exposed.
Related controls
- CF03-005: AI Supply Chain Inventory
- CF01-012: AI System Baseline Management
- CF03-017: AI Model Artifact Scanning
Framework mappings
- CSA AICM (STA-16)
- NIST AI RMF (MAP 1.6)
- EU AI Act (Art. 11(1))
- 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