# AI Supply Chain Map and Risk Assessment Template Tracing what your production AI actually depends on: foundation models, training and fine-tuning data, inference infrastructure, and the AI tools in your build pipeline. A supply chain map, a risk assessment for the critical links, and an incident runbook for supply-chain events. **Who this is for:** The AI security or governance owner who needs to know what breaks the production model if an upstream provider is compromised. Source playbook: https://aigovernance.com/playbook/ai-supply-chain-governance --- ## AI supply chain map _For each production system, its upstream dependencies, each tiered by how directly a failure hits production._ ### Template | System | Dependency | Dependency type | Risk tier | Controls in place | |---|---|---|---|---| | | | foundation model / training data / fine-tune data / inference infra / dev-pipeline tool | Critical / Significant / Limited | | ### Worked example | System | Dependency | Dependency type | Risk tier | Controls in place | |---|---|---|---|---| | Fraud Scoring | VendorLM-4 | foundation model | Critical | pinned version; vendor change-notice; fallback rules engine | | Fraud Scoring | KYC transaction history | fine-tune data | Critical | access-controlled; lineage documented; PII minimized | | Fraud Scoring | GPU inference cluster | inference infra | Significant | multi-AZ; capacity alerts; 30-day exit runbook | | Fraud Scoring | Coding assistant (build) | dev-pipeline tool | Limited | outputs code-reviewed; no secrets in prompts | ### Acceptance criteria - Every production AI system has its upstream dependencies traced, including dev-time AI tools. - Each dependency is tiered Critical, Significant, or Limited using a stated definition. - Critical and Significant dependencies name the controls that currently apply. --- ## Critical dependency risk assessment _For each Critical and Significant link, the four questions that decide whether it is safe to depend on._ ### Template | Dependency | Concentration (single provider?) | Integrity (can tampering be detected?) | Change management (how are updates communicated?) | Security posture (vuln disclosure process?) | Gap / action | |---|---|---|---|---|---| | | | | | | | ### Worked example | Dependency | Concentration | Integrity | Change management | Security posture | Gap / action | |---|---|---|---|---|---| | VendorLM-4 | Sole provider for scoring | Version pinned; response hashes spot-checked | Contractual 30-day notice for model changes | Public advisory feed; bug bounty | Concentration: evaluate a second provider for failover (owner: MLOps, Q4) | | KYC fine-tune data | Internal single source | Row-level lineage; checksums on the export | Change-controlled; quarterly refresh | Internal pen-test coverage | None | | GPU inference cluster | One cloud region | N/A | Provider status page + our alerts | Provider ISO 27001; disclosure process documented | Add a warm standby region (owner: Platform, Q1) | ### Acceptance criteria - Every Critical and Significant dependency has all four questions answered. - Single-provider concentration on a Critical dependency has a documented failover or acceptance decision. - Each gap has an owner and a date. --- ## Supply chain incident runbook _Pre-written response for the supply-chain events that a normal incident plan does not cover._ ### Template > Attach to the AI incident response plan. One section per scenario. **Foundation model provider compromised or breached:** - Assess exposure: what data did we send, what outputs did we rely on, over what window - Switch affected systems to the fallback (rules engine, cached model, or safe-mode) - Preserve logs; notify Legal and, if personal data is implicated, the privacy team - Hold on the provider until a clean version and a root-cause statement are available **Training or fine-tuning dataset found to contain sensitive or unlawful data:** - Freeze retraining; identify every model trained on the affected data - Assess whether deployed models must be rolled back to a clean version - Document the provenance failure and the remediation for the data governance record **AI tool in the development pipeline is backdoored or malicious:** - Identify code, configs, or artifacts produced with the tool in the exposure window - Trigger a targeted code review and dependency audit of that output - Rotate any secrets that could have been exposed to the tool ### Worked example **Tabletop run, 2026-09-12, scenario: foundation model provider breach.** - Exposure assessed: fraud-scoring sent transaction features (no raw PII) over a 6-month window; outputs gated by analyst review. - Fallback tested: rules engine handled 100% of traffic at 92% of model precision for 48h in a drill. - Gap found: no pre-drafted customer/regulator holding statement. Action: Legal to draft template (2026-09-30). - Gap found: log retention for the API request/response pairs was 30 days, shorter than the assessment window needed. Action: extend to 13 months (Platform, 2026-10-15). ### Acceptance criteria - Each scenario has concrete first steps, not "assess and escalate". - The fallback for every Critical dependency has been tested, not just documented. - The runbook is referenced from the main AI incident response plan. --- ## Governance controls this kit produces evidence for - **AGT-019**: The supply chain map and dependency assessment are the AI tool and plugin supply-chain risk assessment. - **PRC-009**: The concentration column of the critical-dependency assessment is the vendor concentration-risk analysis for upstream providers. - **DGC-006**: The dev-pipeline-tool rows and the backdoor scenario cover AI-generated code and tool supply-chain risk. - **IRC-002**: The supply chain runbook extends the incident response playbook to upstream events. - **PRC-003**: Assessing integrity and change management of upstream models is third-party model evaluation applied to the chain.