Scope: What This Guide Covers
This guide addresses the governance gap created by the financialization of AI compute resources. You'll learn about the specific challenges this market introduces, how existing regulatory frameworks apply (or don't), and steps to build oversight mechanisms before your organization trades or relies on compute derivatives.
We focus on three regulated derivatives venues that announced competing AI compute products in May 2024, including CME Group’s partnership with Silicon. This guide does not cover cloud service agreements, spot compute purchasing, or traditional infrastructure procurement.
Key Concepts and Definitions
AI Compute Derivative: A financial contract whose value derives from the availability, performance, or pricing of AI-specific computational resources, typically GPU clusters optimized for model training or inference.
Financialization: The transformation of AI compute from a technical input purchased through service agreements into a tradable commodity with standardized contracts, price discovery mechanisms, and secondary markets.
Systemic Risk in Compute Markets: The potential for compute market disruptions to cascade across AI systems, creating correlated failures in unrelated applications that share infrastructure dependencies.
Counterparty Compute Risk: The exposure your organization faces when a compute derivative counterparty cannot deliver the underlying computational resource, creating model development or deployment failures.
Settlement vs. Delivery: Whether a compute derivative settles in cash (based on a price index) or requires physical delivery of actual compute resources. This distinction fundamentally changes your risk profile.
Requirements Breakdown
Existing Financial Regulations That Apply
The Commodity Exchange Act (CEA) governs derivatives trading in the U.S. When your organization enters compute derivative contracts on regulated exchanges, you're subject to position limits, reporting requirements, and margin rules designed for traditional commodities.
MiFID II in the EU requires transaction reporting and best execution for derivatives. If you're trading compute derivatives through European venues, you'll need systems to capture trade details, timestamps, and execution quality metrics.
GDPR Article 35 may require a Data Protection Impact Assessment if your compute derivative strategy involves sharing information about model training datasets or inference workloads that contain personal data.
SR 11-7 (for U.S. financial institutions) doesn't explicitly address compute procurement, but if compute scarcity affects your ability to validate or redevelop models on schedule, you've created a model risk management gap that supervisors will notice.
Gaps in Current Frameworks
No existing regulation addresses:
- What happens when a compute derivative fails to deliver during a critical model validation window
- How to assess counterparty risk when the "counterparty" is a data center operator with no credit rating
- Whether compute derivatives used for model development create vendor dependencies that require Vendor Due Diligence under your AI Management System
- How to document compute procurement decisions in Technical Documentation (Annex IV) when the EU AI Act requires you to explain your infrastructure choices
Implementation Guidance
Step 1: Classify Your Compute Exposure
Map every model development project and production AI system to its compute dependency. You need three data points:
- Compute type required (training-optimized GPUs, inference-optimized accelerators, specific architectures)
- Timing criticality (can this project tolerate a 30-day delay if compute isn't available?)
- Substitutability (can you switch to a different compute provider or architecture without revalidation?)
Mark any system where compute unavailability would trigger regulatory reporting, breach service-level agreements, or delay mandatory model updates.
Step 2: Build a Compute Procurement Policy
Your policy must answer:
- Who approves compute derivative contracts (not just cloud service agreements)?
- What documentation do you require before entering a contract (proof of data center capacity, performance benchmarks, fallback options)?
- How do you assess whether a compute provider meets your Vendor Due Diligence standards when they're not providing software or data, just infrastructure?
Include a decision tree: when does your team purchase compute through traditional cloud agreements vs. derivatives? The answer should depend on cost predictability, delivery certainty, and whether you need the optionality that derivatives provide.
Step 3: Adapt Your Risk Tiering Process
Add compute dependency as a risk factor in your AI RMF Profile. A high-risk AI system that relies on a single compute derivative for retraining becomes higher-risk. Your AI System Impact Assessment under ISO/IEC 42005 should explicitly evaluate infrastructure concentration risk.
Consider a scenario where you've locked in compute pricing through a derivative, but the underlying data center suffers a cooling system failure. Your derivative contract still exists, but you can't access the compute. How does this affect your Post-Market Monitoring obligations? Document the answer in your Annex A Controls.
Step 4: Update Model Documentation
Your Model Cards and System Cards must now include:
- Compute architecture used for training and validation
- Whether compute was procured through derivatives or direct agreements
- Any Model Limitations and Use Restrictions created by compute dependencies (e.g., "This model cannot be retrained on alternative hardware without full revalidation")
If you're subject to SR 11-7, your model validation evidence should address whether validators had access to equivalent compute resources. A validator who can't reproduce your training run because they lack the same GPU architecture hasn't truly validated your model.
Step 5: Establish Compute Contingency Plans
For every model where compute derivatives play a role, document:
- Alternative compute sources you can access within 48 hours
- Which models you'd prioritize if you face compute rationing
- How you'll meet your Instructions for Use commitments if you can't deliver model updates on schedule
This isn't theoretical. If three competing derivatives venues are launching products simultaneously, they're pricing in scarcity. Plan accordingly.
Common Pitfalls
Treating compute derivatives like cloud contracts: A cloud service agreement gives you access to infrastructure. A derivative gives you a financial position that may or may not result in infrastructure access. Read the settlement terms.
Ignoring concentration risk: If you and your top three competitors all hold compute derivatives from the same data center operator, you've created correlated risk. Your AI System Impact Assessment should flag this.
Assuming financial regulators understand AI risk: The Commodity Futures Trading Commission regulates derivatives markets, not AI systems. Don't expect them to catch governance gaps that your AI Management System should address.
Failing to update vendor risk assessments: When you enter a compute derivative, you've added a new AI Actor to your supply chain. Treat them accordingly in your Stakeholder Engagement and Vendor Due Diligence processes.
Overlooking Reproducibility requirements: ISO/IEC 42001 and SR 11-7 both emphasize the need to reproduce model results. If your compute derivative expires and you can't access equivalent hardware, you've broken reproducibility.
Quick Reference Table
| Governance Requirement | Applies When | Key Action | Documentation Location |
|---|---|---|---|
| Vendor Due Diligence | You enter any compute derivative contract | Assess data center operator's reliability, capacity proof, and track record | Vendor risk register; AI Management System records |
| Data Protection Impact Assessment | Compute derivative involves sharing workload details containing personal data | Complete GDPR Article 35 assessment before contract signature | DPIA register |
| Model Limitations disclosure | Compute dependency constrains model updates or retraining | Document in Model Cards and Instructions for Use | Technical Documentation (Annex IV) |
| AI System Impact Assessment update | High-risk system relies on compute derivative for Post-Market Monitoring | Add infrastructure risk to ISO/IEC Impact Assessment (ISO/IEC 42005) | Impact assessment documentation |
| Validation Evidence gap analysis | Validators lack access to equivalent compute | Document limitation and mitigation in validation report | SR 11-7 Validation Evidence |
| Counterparty risk assessment | Derivative requires physical delivery of compute resources | Evaluate provider's ability to deliver during market stress | Risk management documentation |
| Contingency planning | Any production system depends on derivative-sourced compute | Identify alternative compute sources and prioritization logic | Business continuity plan; AI Management System |
| Position reporting | Trading on regulated U.S. exchange | File required reports under Commodity Exchange Act | Compliance department records |
Your governance framework should answer one question before you sign any compute derivative: if this contract fails to deliver, which AI systems stop working, and what regulatory obligations do you breach? If you can't answer that question with specifics, you're not ready to financialize your infrastructure.
