Legal Support for Neoclouds: Contracts, GPUs, Power and Data

Legal support for a neocloud means managing a chain of contracts in which obligations to the customer, the GPU supplier, the data centre, the power provider and lenders fall due on different dates and come with different remedies. A neocloud is a provider that rents out GPU capacity for AI workloads: dedicated servers, clusters or inference endpoints. There is no separate branch of law for this. The work draws on commercial contracting, finance, export controls and data protection, and what makes it specific is how those contracts depend on each other. Buzko Legal's overview covers how the neocloud market took shape. We look at it from the operator's side: we follow one event through the whole chain and show which risk stays with the operator and what to do about it.

A hypothetical: the servers are being paid for, the power isn't on

This example is invented for illustration. A GPU cloud operator has signed a three-year reserved-cluster agreement with an AI company. The customer has paid an advance. The operator has ordered servers, and the supplier invoices as each batch ships. The racks in the data centre are ready, but energisation slips by two months. The cluster sits assembled and cannot pass acceptance, so monthly service billing never starts.

Meanwhile the hardware supplier still has to be paid on schedule. IREN's disclosure of its Microsoft and Dell arrangements shows how far apart the dates can sit: Microsoft prepays IREN 20% of each tranche's value before the delivery date, while IREN pays Dell for the equipment in instalments within 30 days of each tranche shipping. Those figures belong to one deal and are not a market benchmark.

The customer, for its part, has rights under its own contract: delay credits and, after a set period, termination with a refund of the advance. The data centre answers to the operator under a separate agreement with its own liability caps and force majeure wording. The power utility may not be a party to any of these contracts at all. The lender is watching a revenue schedule that has slipped along with acceptance.

One delay therefore costs the operator credits to the customer, hardware payments and interest on its debt, while any upstream compensation, if there is any, arrives at a different time and in a different amount.

Where the customer promise and upstream cover part ways

It pays to fill in a table like this before signing the customer contract: every blank in the third column marks a risk the operator is carrying.

What the operator is actually selling

The subject matter of the contract drives the SLA, the split of security responsibilities and the operator's role under GDPR and the AI Act. That is why a GPU-as-a-Service agreement, as Pillsbury's analysis also recommends, starts by defining the product. Common options:

• Bare metal. The customer gets dedicated servers and runs its own software environment.
• Reserved cluster. The operator commits to a configuration for a term: GPU count, network topology, storage.
• Interruptible virtual machines. Cheaper, and the operator can reclaim capacity under the service rules.
• Managed inference endpoint. The customer calls a model through an API, and the operator runs the infrastructure underneath.

These formats do not line up on a scale from less responsibility to more. Each has its own layers (hardware, network, storage, operating system, orchestration, model), and each layer belongs to whichever party the contract assigns it to. So in the service description we recommend listing the layers and naming who is responsible for each, including security and incident response.

Acceptance and the start of billing

Installed servers are not yet the cluster the customer was promised, so a reserved-capacity contract should tie money to distinct events. An advance may be invoiced before delivery, while monthly service billing starts at acceptance. Each payment has its own schedule and its own consequences if things slip, and folding them into one clause is risky.

What we check in the acceptance section:

• Criteria. Working GPU count, topology, network and storage throughput, and the test results the supplier hands over. Engineers and lawyers write these together.
• Procedure. When the operator may declare readiness, how many days the customer has to test, how long the operator has to cure defects.
• Customer silence. Whether no rejection within the window counts as acceptance. Without that, acceptance can be dragged out.
• Partial acceptance. Whether the cluster can be accepted once an agreed share of GPUs is working, which SLA applies to an incomplete cluster, and when billing for the accepted part begins.

GPU uptime versus useful workload

A GPU can be available and still useless to the customer. In distributed training, one slow node or a network fault can stall the whole job: CoreWeave's engineers walk through how this happens at scale in their write-up on training failures. The contractual conclusion is ours: the availability of a single machine says little about what a training customer is paying for.

A specific standard SLA makes the point. Nebius's Compute SLA measures the availability of an individual virtual machine by external connectivity and boot disk, and under its general SLA terms the remedy is credit against future payments as the exclusive remedy. That design makes sense for a general-purpose service, but it tells you nothing about whether a training run on a cluster will complete.

So when negotiating a reserved cluster, a typical task is choosing metrics that fit the workload:

• Training. Availability of the whole cluster on the agreed network, a threshold for straggling nodes, recovery time after a node failure.
• Inference. Time to first token (TTFT), latency percentiles, error rate, throughput. Nebius's description of dedicated endpoints treats these as observability metrics; they become a contractual SLA only if the parties write them in.

Every metric needs a carve-out for what the operator controls. Inference latency depends on the customer's model and code, and the operator should not answer for what it does not run.

Minimum commitments, advances and credits

If a reserved-capacity contract obliges the customer to pay for accepted capacity for the full term regardless of actual usage, that is the backbone of the operator's financial model and its strongest argument with lenders. How much that commitment is worth depends on the qualifications around it, and we take them one at a time:

1. Start date. When the obligation to pay for the service begins, and which payments, such as an advance, fall due earlier.
2. Credits. A credit is a contractual reduction of the fee or an offset against future payments under an agreed formula. You need to know the availability level that triggers it, how it is calculated and whether there is an overall cap.
3. Exclusivity. Whether credits are the customer's only remedy, or whether termination and damages remain available.
4. Refund of the advance. On which termination grounds the advance is returned, how much of it and by when.

Credits for a long outage eat into the same revenue the operator uses to service its hardware debt. Clifford Chance notes that lenders look at cash flow after credits and at the customer's own credit risk, so the credit cap is negotiated with the financing terms in mind.

Aligning supply, data centre, power, connectivity and financing

Upstream contracts do not mirror the customer contract on their own: each counterparty has its own liability caps, force majeure and timelines. The lawyer's job is to line them up against the customer contract:

• The ready-for-service date promised to the customer sits after the guaranteed dates for delivery, energisation and connectivity, with room for acceptance.
• Force majeure in the customer contract and in the data centre agreement is handled as a single allocation of risk. If the data centre's clause is wider, the data centre is excused towards the operator while the operator stays bound to the customer.
• Supplier remedies are matched to customer credits in amount and timing.

Financing is its own layer. The Nebius SOW with Microsoft makes the core obligations conditional on Nebius either obtaining financing or confirming it will self-fund the capital expenditure. Signing the contract and satisfying that condition are separate events, so a signed contract does not yet prove the capacity is funded or will generate revenue.

Large customers raise continuity of service separately. Section 2.2 of the IREN SOW with Microsoft is headed "Step-in right", but in substance the service supplier, an IREN group company, undertakes to use good faith efforts to get its lenders and colocation provider to sign a separate agreement for continuing Microsoft's service if that supplier becomes insolvent. The clause does not by itself create a ready-made right to step in. A direct agreement or step-in right exists only once the lender, the data centre and any other necessary parties have signed it. Whether an assignment needs consent depends on the wording of each contract and the governing law. These questions are easier to settle alongside financing and fundraising advisory.

Hardware refresh, customer exit and change of control

A new GPU generation may arrive during a multi-year term, while the contract fixes the technical specification for the whole of it. We recommend setting out in advance which replacements count as equivalent, which need the customer's consent and who pays for moving to a new generation. Hard-coding a specific card model can block a fleet refresh even when the customer would benefit from it.

Customer exit also needs to be written up front. If a customer leaves early, the operator needs to know what it may do with the dedicated servers: reconfigure them for another customer, sell them or return them to the lender. That depends on confidentiality duties and the deletion of the customer's data and configurations, on the lender's security interest, and on how proceeds from reusing the servers are credited in the settlement with the customer. These constraints are best gathered into one section of the contract.

Change of control is checked contract by contract. When a buyer acquires an operator, Mayer Brown advises reviewing the whole package: the MSA, orders, side letters, and the assignment, change-of-control and capacity-allocation terms. A share deal does not by itself guarantee that a contract survives, nor does it always need the customer's consent. On the operator's side, it makes sense to negotiate a narrow change-of-control definition and to know in advance whose consent a sale or a new funding round will require.

Customer data, model weights and telemetry

Data and model weights are the customer's most valuable assets in the cluster. The contract has to answer three questions: who owns them, who gets access, and what the operator does with telemetry. A capacity contract does not by implication let the operator train its own models on customer data. Even express customer permission does not replace rights in the data and IP themselves, nor, for personal data, an independent legal basis for the processing.

The CoreWeave agreement with OpenAI shows a strict contractual approach to telemetry: the provider may compile aggregated statistics only about its own performance (uptime, errors, capacity utilisation), and only in a form that cannot reveal customer data. That is a contractual restriction; technical access controls are described separately.

It helps to separate two data flows. The first is the customer's workload: datasets, weights, model queries. The second is data the operator processes for itself: accounts, billing, security, support. The operator usually decides the purposes of the second flow itself, and that shapes its role under GDPR.

Regulatory map as of 28 September 2026

This map is short and conditional: every point depends on the facts of the deal, the operator's role and the jurisdiction.

• US export controls. Shipping regulated hardware and providing remote compute are different situations, and a conclusion about one cannot simply be carried over to the other. A licence may be needed depending on the item, the countries, the end user and the end use: in its policy statement on chips used to train AI models, BIS described cases where a requirement can arise when chips go to IaaS providers and when US persons provide services connected with model training. BIS announced it would not enforce the AI Diffusion Rule, and GAO's materials separate non-enforcement from a completed rescission: as of May 2026 the rescission process had not finished. BIS guidance confirms that licensing of exports of the relevant controlled advanced computing items continues for entities headquartered, directly or through their ultimate parent, in Country Group D:5 or Macau, even where the recipient sits in another country; whether an exception applies is checked separately. Customers and end uses are screened on the facts of each deal.
• AI Act. Under the Commission's guidelines on general-purpose AI models, the provider of a model is whoever developed it or had it developed and places it on the market under its own name. An operator whose infrastructure runs someone else's model does not automatically become that model's provider. If the operator releases a model under its own brand, substantially modifies someone else's or builds its own AI system, its role needs a separate analysis.
• GDPR. Where GDPR applies and the operator processes personal data on the customer's behalf, Article 28 GDPR requires a processing agreement with instructions, rules for engaging sub-processors and flow-down of obligations. Not every GPU rental needs one, and under Article 28(10) a processor that determines the purposes and means of processing is treated as a controller for that processing. Hosting servers in the EU does not settle the question of remote access from third countries: the EDPB discusses a controller's obligations where processors and sub-processors handle data outside the EEA, and whether access counts as a transfer depends on the recipient and the parties' roles.
• Data Act. If a cloud service falls within Chapter VI of the Data Act, the customer gains switching rights. Until 12 January 2027 switching charges are capped at the provider's direct costs, and from 12 January 2027 they are prohibited. Ordinary service fees and proportionate early termination charges are not switching charges.

A regulatory compliance audit checks a business model against all four points at once.

What a lawyer prepares for the operator

The work comes down to five sets of documents. They are easiest to run as a single advisory and ongoing support engagement, because a change in one contract ripples into the others.

1. A service description and order form with acceptance criteria and SLAs that measure what the customer is actually buying.
2. Contracts with suppliers, the data centre, power providers and carriers, aligned with the customer contract on timelines, force majeure, liability caps and remedies.
3. A financing and consents matrix: who approves assignment, security, change of control and continuity of service on default.
4. Security and data schedules: a processing agreement where the operator acts on the customer's behalf, telemetry rules, and how model weights are handled.
5. Fact-specific export control and customer screening, plus exit and migration terms.

We prepare these documents as part of our IT business legal support, from the order form to aligning the chain with lenders and the data centre. A good starting point is a review of one customer contract and the contracts that sit above it.

FAQ

Does a neocloud need a special licence?

There is no single "neocloud licence". Requirements depend on the country, on what exactly is being sold, and on the hardware and the customers: export controls, data protection and local data centre rules are each checked on their own.

What needs separate negotiation in a reserved GPU cluster contract?

The typical negotiation covers acceptance, when service billing starts, minimum commitments, credits and their cap, and how all of these tie back to the supplier, data centre and lender contracts. A standard SLA such as Nebius's Compute SLA measures the availability of an individual virtual machine, so cluster and workload metrics are drafted separately.

Can the operator train its own models on customer data?

Express permission in the contract is needed, but it is not enough. Customer permission on its own does not replace checking the rights in the training material: the customer must itself hold rights in the data and models, including third-party rights in content and IP. If the data includes personal data and GDPR applies to the processing, the operator needs its own legal basis and acts as a controller for that processing.

What happens to the contracts if the operator is acquired?

It depends on the assignment and change-of-control terms in each contract: some carry narrow termination rights, others broad consent requirements. That is why the whole package, side letters included, is reviewed before the deal.