You don't control the systems you're being asked to govern. If you're running an AI Management System under ISO/IEC 42001 or validating models under SR 11-7, that sentence should stop you cold.
This checklist addresses a structural risk most governance frameworks don't name: dependency. When you can't build, inspect, audit, or adapt the AI systems your organization relies on, your governance becomes performative. The UN Independent Scientific Panel's July 2026 report made this explicit: most countries are "dependent on systems they cannot build, inspect, audit or fully adapt to local context." The same holds for enterprises. Industry produced over 90% of notable frontier models in 2025, and if you're not the one building them, you're the one inheriting the risk.
This checklist helps you identify where dependency creates governance gaps and what controls you can still enforce when the system is built elsewhere.
Prerequisites
Before you start, confirm you have:
- A current AI system inventory listing all Outsourced Models and Foundation Model Providers your organization uses
- Vendor contracts with defined Service Level Agreements (SLAs), including audit rights and data access provisions
- Authority to escalate dependency risks to leadership when controls prove insufficient
- Documentation of your risk appetite under NIST AI RMF or ISO/IEC 23894, including defined materiality thresholds
If you lack any of these, start there. You can't assess dependency risk without knowing what you depend on.
Dependency Governance Checklist
1. Vendor Due Diligence Covers Governance Capability
Done when: Your Vendor Due Diligence process includes a written assessment of each Foundation Model Provider's ability to support your audit, inspection, and adaptation requirements.
What good looks like: You have a scored rubric that evaluates whether the vendor will provide Model Cards, Technical Documentation (Annex IV), access to Validation Evidence, and the right to conduct independent Red Teaming. If they won't, you've documented that as a control gap and escalated it.
2. Contracts Include Enforceable Audit Rights
Done when: Every contract with a Foundation Model Provider or vendor supplying Outsourced Models includes a clause granting you the right to audit their controls, request Root Cause Analysis for incidents, and review their Post-Market Surveillance processes.
What good looks like: The clause specifies response timelines (e.g., 15 business days for incident reports, 30 days for audit access). You've tested it at least once by requesting documentation, and the vendor complied.
3. You Have a Fallback for Every Dependency
Done when: For each critical AI system, you've documented an alternative: a different vendor, an in-house model, or a manual process you can revert to if the primary system fails or the vendor relationship ends.
What good looks like: Your Business Continuity Plan includes Model Provisioning timelines for each fallback, and you've tested at least one transition in the past year. If no fallback exists, you've flagged the system as a single point of failure and reported it to leadership.
4. You Track What You Can't Inspect
Done when: You maintain a register of governance gaps created by vendor opacity. For each gap, you've documented the specific control you cannot enforce (e.g., "cannot validate training data provenance," "cannot audit Bias Mitigation techniques").
What good looks like: The register is reviewed quarterly. For each gap, you've either negotiated better contract terms, implemented compensating controls (such as output monitoring or Responsible Disclosure processes), or accepted the residual risk with board-level sign-off.
5. Your Risk Tiering Accounts for Dependency
Done when: Your AI RMF Profile or ISO/IEC 23894 risk assessment explicitly scores dependency as a Contextual Risk Factor. Systems you cannot inspect, audit, or adapt receive a higher risk tier.
What good looks like: A high-risk system that relies on a Foundation Model Provider with limited transparency is automatically flagged for additional Post-Market Monitoring, more frequent model performance reviews, and executive oversight, regardless of its technical performance.
6. You Know Where Concentration Creates Exposure
Done when: You've mapped your compute, model, and data dependencies to identify single points of failure. You know if a single vendor, cloud region, or Foundation Model Provider supports multiple critical systems.
What good looks like: You have a written concentration risk report that quantifies exposure (e.g., "68% of customer-facing AI systems rely on a single Foundation Model Provider"). If concentration exceeds your risk appetite, you have a diversification plan with milestones.
7. Stakeholder Engagement Includes the Right to Refuse
Done when: Your consultation processes for AI deployment include a documented mechanism for affected Stakeholder Engagement groups (employees, customers, communities) to object to a system's use. Objections trigger a review, not just a response.
What good looks like: You've paused or modified at least one AI deployment based on stakeholder feedback. If you haven't, either your systems carry no Materiality or your consultation process is theatre.
Common Mistakes
Treating vendor assurances as validation evidence. A vendor's claim that their model is "fair" or "safe" is not Validation Evidence. If you can't see the testing methodology, the benchmark results, or the Annotation Quality metrics, you haven't validated anything.
Assuming audit rights you never exercise. Contracts with audit clauses are meaningless if you don't use them. Test your audit rights within the first six months of every vendor relationship.
Confusing adoption speed with governance maturity. The fact that 88% of organizations now use AI (per the Stanford AI Index 2026) does not mean 88% have effective governance. Dependency grows faster than accountability. If your governance program launched after your first model deployment, you're already behind.
Ignoring the evidence dilemma. The UN Panel warned that the evidence policymakers need to govern well tends to arrive after the moment to act has passed. The same applies internally. If you're waiting for incident data to justify controls, you've already accepted the harm.
Next Steps
If you checked fewer than five items, your governance is built on dependency you don't control. Prioritize items 1, 2, and 4: you need to know what you can't inspect, enforce the rights you have, and track the gaps you can't close.
If you checked all seven, your next step is to quantify the cost of dependency. Calculate what it would take to reduce reliance on any single Foundation Model Provider by 20%. If the cost is prohibitive, you've confirmed dependency as a strategic risk, not just a governance one. Bring that to your board.
The concentration of AI capability in a few firms and countries is not a distant geopolitical concern. It's a risk your organization inherits every time you deploy a model you didn't build. Governance that doesn't account for dependency is governance in name only.
