AI compute is no longer merely an infrastructure purchase. For companies scaling training, inference or AI-enabled products, it is becoming a long-duration capital allocation and operational resilience decision.

Volta’s emergence from stealth illustrates the shift. The London AI cloud startup was reported at a €2.07 billion valuation, alongside a reported €8.6 billion compute agreement. The candidate source attributes the customer to Anthropic, but that attribution is reported rather than confirmed in the supplied summary. Even with that caveat, the scale is instructive: access to compute can now involve commitments whose financial and strategic consequences extend well beyond an engineering team’s cloud budget.

Developments elsewhere reinforce the broader pattern. ICEYE’s €1 billion Series F financing and Neuraspace’s €15.6 million funding for AI-enabled satellite protection show how advanced software services can depend on expensive physical assets, specialist infrastructure and sustained financing. Neither company should be understood as a general-purpose cloud provider. The comparison is about dependency: sophisticated AI operations often sit on top of capital-heavy, strategically sensitive supply chains.

Start by defining what capacity you are buying

A headline quantity of accelerators, tokens or compute hours does not establish usable capacity. Buyers should distinguish reserved capacity from consumed capacity. Reserved capacity gives a contractual right to resources; consumed capacity is what workloads actually use and what may ultimately create value.

Ask whether capacity is dedicated, prioritised or merely targeted. Confirm the hardware generation, interconnect, storage throughput, geographic location and availability date. A nominally large allocation can underperform if networking, power, storage or orchestration becomes the bottleneck.

Demand a ramp schedule linked to measurable acceptance tests. If capacity arrives late or fails benchmark requirements, minimum-spend obligations should reduce accordingly. Avoid paying full rates for reservations that cannot support the agreed workload profile.

Model the contract’s real unit economics

Long-term commitments can secure availability and improve pricing, but they can also convert uncertain demand into fixed cost. Build scenarios for expected, low and high utilisation rather than relying on a single forecast.

The useful metric is not simply price per accelerator-hour. Calculate cost per completed training run, per million inferences or per customer transaction. Include storage, networking, data movement, support, orchestration, idle reservations and engineering time. Model failed jobs and performance variation too.

Minimum-spend clauses deserve particular scrutiny. Determine whether spend can move across regions, hardware types, subsidiaries or workloads. Check whether unused commitments roll forward and whether service credits count against minimum spend. A discount can become expensive when demand changes or newer hardware materially improves performance per euro.

What most people miss

Hardware-refresh assumptions can dominate long-term economics. A contract priced attractively against today’s chips may become uncompetitive if the supplier does not upgrade equipment or pass through efficiency gains. Specify how refreshes affect rates, migration work, performance guarantees and remaining commitments.

Financing risk matters as well. A provider promising major future capacity may depend on debt, equity, customer prepayments, energy contracts and hardware delivery. Procurement teams should assess whether capacity is already operational, fully financed or contingent on future fundraising and construction. Contract size is not proof of delivery capability.

Treat continuity and concentration as board-level risks

A compute provider can become a single point of failure across product delivery, model development and customer commitments. Map concentration by supplier, region, data centre, hardware architecture, network provider and orchestration layer. Two vendor names do not create resilience if both depend on the same facility, energy source or component supply chain.

Set exposure limits based on business impact. A provider might handle a large share of interruptible experimentation but a smaller share of latency-sensitive production inference. For critical workloads, establish tested alternatives rather than a theoretical multi-cloud strategy.

Service-level agreements should cover more than uptime. Define remedies for capacity shortfalls, degraded performance, missed delivery dates and prolonged incidents. Credits alone may be inadequate when an outage causes lost revenue or regulatory breach. Seek termination or step-down rights after repeated failures and require incident reporting, recovery objectives and continuity testing.

Control data location, security and portability

Data residency must be expressed contractually, not left to a dashboard setting. Identify where prompts, training data, model weights, logs, backups and support records are stored and processed. Clarify whether administrators or subcontractors can access them from other jurisdictions.

Security review should cover encryption, key control, tenant isolation, privileged access, vulnerability management, audit evidence and breach notification. Buyers should also understand what operational telemetry the provider retains and whether customer data can be used to improve its services.

Portability requires practical preparation. Document model formats, container images, dependencies, data pipelines, networking and identity controls. Estimate the time, bandwidth and cost required to move datasets and checkpoints. Test a representative workload with an alternative provider before signing a commitment that would make switching prohibitively difficult.

Negotiate the exit before committing

Exit terms determine whether supplier risk remains manageable. Define termination rights for persistent underperformance, security incidents, insolvency, ownership changes, sanctions or material changes in data location. Specify assistance, export formats, deletion evidence and continued access during transition.

Review assignment and change-of-control clauses because strategic infrastructure providers may consolidate. Understand whether prepaid amounts are protected and whether deposits are held separately. If the supplier is financing future infrastructure against customer commitments, seek visibility into milestones and rights if financing or deployment fails.

Finally, establish governance. Finance, security, legal, data protection, engineering and product leaders should jointly review material commitments. Reassess utilisation, concentration and supplier condition throughout the term rather than treating diligence as a one-time purchasing event.

AI compute contract checklist

• Separate reserved capacity, deliverable capacity and expected consumption.
• Define hardware, networking, storage, region, delivery milestones and acceptance benchmarks.
• Model unit economics at low, expected and high utilisation, including indirect costs.
• Review pricing escalators, minimum spend, rollover rights and workload flexibility.
• Specify hardware-refresh assumptions and access to newer generations.
• Set remedies for downtime, degraded performance and delayed capacity.
• Confirm residency for data, weights, logs, backups and administrative access.
• Assess security controls, subcontractors, audit rights and breach notification.
• Test workload, data and model portability before making a long commitment.
• Negotiate termination, transition support, deletion and change-of-control protections.
• Examine whether promised capacity is operational, financed and deliverable.
• Map concentration across suppliers, facilities, regions, energy and hardware.
• Maintain a tested continuity plan for business-critical workloads.