Over 100 neocloud providers entered the market during the 2023 to 2024 GPU build-out. By mid-2026, according to a market analysis by the GPU marketplace ClusterBid, fewer than 40 were still operating at meaningful scale.
The survivors are carrying debt. CoreWeave's total debt reached $35 billion as of June 30, 2026, with quarterly net interest expense of $640 million, more than double the $267 million recorded a year earlier. Analysts have described loan-to-value ratios of 60 to 70 percent on GPU-backed facilities, and that debt matures inside a tightening window between now and 2028.
At the same time, the identity surface underneath these workloads has changed shape. Palo Alto Networks' 2026 Identity Security Landscape Report, published in May, found that organizations now manage an average of 109 machine identities for every human identity, up from 82 to 1 a year earlier. More than half of the participants said they cannot consistently enforce least-privilege access for service accounts across cloud, SaaS and on-premises systems.
Three separate pressures, one desk. They converge on whoever signs the next AI infrastructure purchase order.
This is not a trend recap. It is a decision playbook for AI storage infrastructure, organized around the three pillars that separate durable AI stacks from stranded ones.
Access covers securing premium-tier storage characteristics without accepting reserved-contract lock-in or a single provider's default object store. Auditability covers producing evidence, per action, per identity, per artifact, that survives an agent compromise, an auditor request or a customer questionnaire. Longevity covers preserving a working extraction path, so that a single neocloud failure, acquisition or price move does not strand the pipeline.
What bring-your-own storage means for AI workloads?
Bring-your-own storage for AI workloads means contracting the storage layer independently of the compute layer, so that training data, checkpoints, embeddings and evaluation artifacts live in an S3-compatible object store the buyer controls rather than in whichever store their GPU provider happens to default to. It separates two risks that vendor bundling merges into one: the risk that compute becomes more expensive, and the risk that data becomes unreachable.
The six decisions below follow the order a procurement cycle actually hits them.
Decision #1: Separate the storage contract from the compute contract
This is the catalyst decision. Everything downstream depends on it.
Teams that signed bundled GPU and storage agreements in 2024 and 2025 did so for reasonable operational reasons. One vendor, one invoice, one support path, and often a meaningful discount for taking the provider's object store alongside the cluster. The discount was real. The coupling was the price.
The coupling matters now because the failure mode has changed. In 2024, the question was whether a provider could deliver capacity. In 2026, with a refinancing wall between here and 2028, the question is whether a provider's balance sheet sits inside your recovery path. If the storage contract is bundled into the compute contract, then a provider's credit event, acquisition or repricing is also a data event. The training pipeline inherits the counterparty risk of the lender who wrote the GPU facility.
Unbundling does not require leaving the neocloud. It requires that the storage layer be portable, S3-compatible and contractually independent from whichever compute vendor is cheapest that quarter. The GPU contract becomes what it should have been all along: a lease on capacity, terminable without a data migration project attached.
The practical test is a single question for any bundled agreement already in place. If this provider gave 90 days' notice tomorrow, what is the cost and elapsed time to move the data, and who pays it? If nobody on the team can answer in numbers, the contract is more coupled than the org chart suggests.
Access: getting the AI storage infrastructure you thought you bought
Decision #2: How do I get premium AI storage performance without a reserved-capacity contract?
Premium performance tiers at most large neoclouds sit behind reserved-capacity contracts.
Saturn Cloud's June 2026 comparison of GPU cloud providers documents the pattern directly: "Many providers announce VAST Data or WEKA partnerships, but at most of them those are reserved or bespoke configurations, not something exposed in the on-demand product." The same report notes that at several neoclouds, the high-speed fabric is only exposed in a reserved or supercloud tier rather than in the public on-demand product. CoreWeave, where VAST is selectable at provision, and Crusoe, which offers VAST-backed shared disks on-demand, are called out as exceptions.
The practical result is a gap between the marketing page and the bucket. A team running checkpoint-heavy training on on-demand capacity assumes it inherited the storage tier the provider's website describes. It did not. It landed on the provider's default object store, and it finds out at the first multi-terabyte checkpoint write, usually during a run it cannot restart cheaply.
The requirement this creates is specific. A self-service buyer needs high-throughput object semantics, S3 compatibility and predictable performance, available without a reserved-tier gate. Those are properties of a storage layer, not concessions to be won in a compute negotiation. Saturn Cloud's own guidance to buyers is the right instinct: plan storage around what you can actually provision.
Tier is one axis. The other is which workloads justify bringing your own storage in the first place.
Decision #3: Which of my AI workloads actually need bring-your-own storage?
Workload profile decides the answer, and procurement teams that treated AI storage infrastructure as one line item are now splitting the requirement by workload class.
Inference is the honest exception. When latency is the binding constraint and the data is a served model artifact rather than a record of anything, keeping it close to the compute is the right engineering call. The case for independence is weakest here, and a playbook that pretends otherwise is selling rather than advising.
Evaluation is the inverse, and it is the category most organizations have not yet separated out. Evaluation artifacts are the record of how a system behaved: which model version, on which inputs, producing which outputs, reviewed by whom. Their value is entirely in being trustworthy later, which means their storage requirement is closer to a compliance archive than to a training scratch volume. Storing them in the same bucket as last month's checkpoints, under the same retention policy, on the same provider whose survival is the open question, is a decision most teams have made by default rather than on purpose.
Once storage crosses tenant and workload boundaries, the audit trail behind it becomes the next constraint.
The Auditability pillar
Decision #4: Can I prove which data my agents acted on?
This is the question the identity numbers are really asking.
At 109 machine identities per human, the population of actors touching enterprise data is no longer something a human review process can enumerate. A Cloud Security Alliance analysis published in May 2026 puts the governance gap in plainer terms: 51 percent of organizations report no clear ownership of AI identities, and roughly 47 percent of non-human identities remain static and unmonitored for a year or more.
An agent with a long-lived credential, no owner and no monitoring is not primarily a threat-detection problem. It is an evidence problem. When something goes wrong, the questions are forensic and specific. Which agent read this dataset? Was the file it read the file we think it read, or a version modified after the fact? Can we demonstrate that, to an auditor, using records the compromised system did not control?
That last clause is the hard one, and it is where most logging architectures quietly fail. If the agent, the application logs and the object store all sit inside the same trust boundary and the same provider account, then an attacker who reaches that boundary reaches the evidence too. Logs written by the system under investigation are the weakest possible answer to a question about that system.
The requirement is evidence that is independent of the actor generating it. Practically, that means integrity attestations at the storage layer rather than the application layer, immutability guarantees that survive administrative credentials, and a record of what a given artifact was at a given time that can be checked without trusting the party who stored it.
Decision #5: What logs do I have to keep, and for how long?
Here the regulatory picture shifted in 2026, and it shifted in a way that is easy to misread as a reprieve.
The EU AI Act's Article 12 requires that high-risk AI systems "technically allow for the automatic recording of events (logs) over the lifetime of the system." Article 19 requires providers to retain those logs for a period appropriate to the intended purpose, and in any case for a minimum of six months, unless other EU or national law requires longer.
The timing moved. The AI Omnibus was published in the Official Journal on 24 July 2026 and entered into force on 27 July. It moved the compliance deadline for stand-alone Annex III high-risk systems from 2 August 2026 to 2 December 2027, and for Annex I systems embedded in regulated products to 2 August 2028. One qualifier matters for planning: the deferral covers the high-risk obligations only. The Article 50 transparency obligations for AI-generated content were not deferred, and 2 August 2026 remained an active compliance date for those.
Read as a deadline, the deferral buys eighteen months. Read as an architecture requirement, it changes nothing, because the retention clock and the system lifetime are the constraint, not the enforcement date. A six-month minimum on logs generated over the lifetime of a system, held in a form an auditor will accept, is a storage design decision. Organizations that treat 2 December 2027 as the date to start building will be assembling an evidence chain for systems that have already been running for two years, from logs that were rotated out on a 30-day default.
The decision to make now is where those records live and under whose control, not when to start keeping them.
The Longevity pillar
Decision #6: What does it cost me to leave?
Every pillar above resolves into this one, and for the first time the answer has a legal floor under it in Europe.
Under the EU Data Act, switching charges between cloud providers, including data egress fees, become prohibited from 12 January 2027. During the transition period running until then, providers may still charge for switching, but only where the costs are directly incurred in facilitating the switch, and only on terms agreed transparently in advance. Continuous, bidirectional multi-cloud usage falls outside the switching provisions, so the change is narrower than "egress is free now," and organizations reading it that way will be surprised.
What the Data Act does is turn exit cost from a commercial fact into a compliance question with a date attached. That makes the CIO's version of the question concrete, and it is worth asking of every provider in the stack right now.
Three parts, and the third is the one that gets skipped. What does extraction cost in money. What does it cost in elapsed time at the provider's actual sustained throughput, not its advertised peak. And what is lost in the move: lifecycle policies, object versions, retention locks, access logs and integrity records that do not travel with a bulk copy.
An extraction path that moves the bytes but leaves the provenance behind is not a working extraction path for anything audit-bound. It is the reason the Longevity pillar and the Auditability pillar are the same problem viewed from different ends. Data that cannot be moved without losing its history was never really portable, and evidence that only exists inside one provider's control plane was never really evidence.
How we think about this at Akave?
We built Akave Cloud on a premise this playbook keeps arriving at from different directions. The storage layer should outlive whichever compute vendor is cheapest this quarter, and it should be able to prove what it held.
That translates into three design decisions. Akave Cloud is S3-compatible, so unbundling storage from compute does not mean rewriting the data path. Akave charges zero egress fees, so extraction is never a pricing decision made under pressure, and Decision #6 has the same answer in January 2027 that it has today. And Akave Cloud produces cryptographic data provenance: on-chain attestations and Proof of Data Possession, so that a question about what a given artifact was at a given time has an answer that does not depend on the storage provider's own logs or its continued existence.
That last property is the one we think is underrated in the current market, and it is why we describe Akave as a sovereign data fabric rather than as object storage. When an agent makes a decision, the useful question is not whether the data was fast. It is whether you can audit what the agent acted on, six months later, to a third party who has no reason to take your word for it. Akave is built to make that answerable at the storage layer, where the evidence is least dependent on the systems under review.
We are not competing on scale, and we are explicit about that internally. Hyperscalers win on scale. Akave wins on control: geofenced data sovereignty for organizations that need to know where data physically lives, GDPR and EU AI Act alignment built into the layer rather than bolted on above it, and verifiability as a property of the storage rather than a report generated about it.
None of this makes the six decisions above easier. It does mean that for the organizations running on Akave Cloud, Decisions #1, #4 and #6 resolve to the same architectural choice rather than to three separate projects. The name is the argument, for what it is worth: Aka, root or origin, and Ve, verification. Akave is meant to be the root of verifiable truth for the data an AI system acted on.
The pattern underneath the six decisions
Read together, the six decisions are one decision asked six ways: which parts of the AI stack are you willing to let a single counterparty hold.
Compute has always been a lease. Nobody expects to own a GPU cluster in perpetuity, and the whole neocloud model depends on that expectation being comfortable. Storage got treated the same way because it arrived in the same contract, and the market is now discovering that the two have different half-lives. A GPU contract that ends is an inconvenience. A dataset, a checkpoint lineage or an evaluation record that ends with it is something else.
The consolidation and the refinancing wall will resolve one way or another, and the surviving providers will be stronger for it. The organizations that come through the other side with their pipelines intact will mostly be the ones that made these decisions before they were forced to, when the question was an architecture review rather than a 90-day notice.
The next infrastructure PO is a good place to start asking.