Enterprise AI infrastructure · 26 September 2026

You found the GPUs.
Now comes the hard part.

The capacity is available. The business case looks compelling. Your researchers are ready. The risk is discovering too late that your organisation cannot actually put the GPUs to work.

You've found the capacity your AI team has been asking for. Perhaps Nebius has the cluster, the regional footprint or the commercial terms your workload needs. Perhaps CoreWeave has the right capacity and managed services. Perhaps Crusoe has hardware your existing provider cannot supply when you need it.

For the first time in months, the compute problem looks solvable.

Then your platform engineering lead asks: "How does this work with everything we already have?"

That question is where the real project starts, and most organisations underestimate it. The gap between signing a GPU contract and running a useful workload in production is wider, messier and less well documented than any provider's sales process will show you.

I'm currently involved in this kind of integration work. I've written this as a narrative because that's how it actually unfolds: each problem reveals the next, and the decisions you make early constrain what's possible later.

The GPU deal isn't the business outcome. A productive workload is.

Specialist GPU providers can offer better pricing, more capacity, newer hardware and geographic options. The economics look good on paper. But the number on the rate card is not the number your business ends up paying.

Imagine committing to a cluster because it promises substantial savings. The contract starts. The GPUs are ready. Then the work begins.

Security needs to approve the network path. Engineers need to federate your identity provider. Training data needs a secure route into the new environment. Monitoring is incomplete. Nobody has agreed who takes the call when a job fails at 2am.

Meanwhile, you're paying for capacity your researchers cannot fully use.

The provider has delivered what it sold. Your business hasn't yet realised what it bought.

The real calculation isn't cost per GPU-hour. It's cost per useful, completed workload, and that includes data movement, integration engineering, utilisation losses and ongoing operations. Before you commit, work out the real numbers: what the workload costs today, what the integration will take, how long it will realistically be before researchers are productive, and what you'll spend on idle capacity in the meantime.

The reason the gap is so large is that the integration surface between a specialist GPU provider and your existing enterprise touches almost everything:

Where the provider's responsibility ends depends on the service and contract you buy. In general, the provider manages infrastructure up to an API boundary. Everything above that, who can access the GPUs, how data gets there, how costs are tracked, how failures are handled, falls to you. The shared-responsibility band in the middle varies by provider, service and contract. Some offer substantial managed identity, networking, scheduling and recovery. Others leave more to the customer. Your job is to work out what your chosen provider actually supplies, what has to connect to your existing estate and who owns each failure mode.

The first wall: your identity system stops at the new cloud.

Your researchers already sign in through Microsoft Entra, Okta or another established identity provider. Their groups determine what they can access. Security can disable accounts and review activity.

A separate GPU-cloud account might get the first experiment running quickly. But what happens when twenty researchers need access, someone leaves the company, or auditors ask you to reconstruct six months of access history?

Each specialist provider has built identity and access features for enterprise customers, though the depth of public documentation varies and your experience will depend on the specific service and contract you buy.

Nebius supports SAML-based SSO, service accounts and group-based authorisation through its IAM. Managed Kubernetes provides standard Kubernetes RBAC. Nebius runs GPU clusters with InfiniBand across multiple European locations, which matters when identity and access controls need to align with regional requirements.

CoreWeave has published the most detailed enterprise identity material among the specialist providers. Their IAM federates over SAML and OIDC with named support for Okta and Microsoft Entra. Users and groups sync from your IdP via SCIM. Their SUNK User Provisioning automatically creates POSIX users on Slurm clusters when a federated user arrives. Remote Key Encryption, announced in September 2026, will let encryption keys stay in the customer's own key store.

Crusoe holds ISO 27001 and SOC 2 Type II certifications with GDPR alignment and customer-managed encryption keys. Their published identity documentation is thinner than the other two. Ask for a technical demonstration against your specific requirements.

Sources: Nebius documentation (docs.nebius.com). CoreWeave blog, "Bringing Enterprise Identity and Key Control to AI on CoreWeave", September 2026. Crusoe security documentation.

Thin documentation does not mean a provider lacks the capability. What matters is whether it supports the federation, provisioning and deprovisioning flows your security team actually needs. Ask every provider the same questions: which SAML or OIDC flows are supported? How are groups provisioned and deprovisioned? What are the RBAC boundaries? Which conditional-access controls survive federation? How are admin actions logged?

But getting federation to work is not the same thing as reproducing your access model. Even after federation is live, several problems are still yours:

• Group and role mapping. Your IdP groups must map to meaningful RBAC roles in the new Kubernetes clusters. AWS IAM roles, GCP service accounts and Azure managed identities don't transfer. You need a mapping layer.
• Workload identity. A training job on any specialist provider that reads from your S3 bucket needs credentials. Distributing long-lived cloud access keys into another provider's cluster is a security incident waiting to happen. The right pattern is workload identity federation, where a Kubernetes service account in one cloud assumes a role in another without static credentials. It requires configuration on both sides.
• Secrets distribution. If you use Vault or a cloud secrets manager, workloads on the specialist cloud need to reach it. The External Secrets Operator for Kubernetes can bridge the gap, but it has to be deployed and configured in every cluster.
• Audit trail unification. Your security team needs a single view of who accessed what, across both environments. Each provider can forward logs to a customer SIEM. The schema mapping and correlation work is yours.
• Break-glass access. When something goes wrong at 3am, your on-call engineer needs access that works, that's auditable, and that doesn't depend on a separate set of credentials nobody remembers.

Acceptance test: onboard a researcher, run a workload under the correct permissions, change their group membership, verify it propagates, revoke access, check the logs and prove that no forgotten credentials retain access. Do this before you treat identity integration as complete.

The second wall: the GPUs are ready, but your data is somewhere else.

Identity gets researchers through the door. Then the first real workload needs its training data. Several terabytes, probably, sitting in your existing cloud.

Shopify's published SkyPilot architecture is a well-documented production example of solving this at scale, and it uses Nebius alongside Google Cloud. Training datasets are replicated near the compute. When a run targets Nebius, data comes from Nebius storage. When it targets GCP, from GCS. They designed for data locality rather than cross-cloud reads.

Source: Shopify Engineering, "SkyPilot at Shopify: Multi-cloud GPUs without the pain", January 2026.

This works when datasets don't change often and aren't subject to residency restrictions that prevent replication. The operational cost is synchronisation, versioning and paying for storage in multiple locations.

CoreWeave's LOTA Cross-Cloud claims near-local throughput of up to 7 GB/s per GPU for data stored in another cloud. That removes the need for replication but creates a dependency on CoreWeave's caching infrastructure. It was in limited availability for Google Cloud workloads as of September 2026. CoreWeave's Interconnect provides private fibre to Google Cloud via Partner Cross-Cloud Interconnect with MACsec encryption and zero egress fees.

Nebius provides high-performance GPU clusters with InfiniBand interconnect and its own object and file storage. When compute and data are both within Nebius, data locality is simple and fast. The Shopify implementation shows this pattern working in production at scale.

For other cloud pairings (CoreWeave to AWS, Nebius to Azure, Crusoe to any hyperscaler), the options today are typically site-to-site VPN or colocation cross-connects, with the latency and management overhead those involve. A VPN may get the first workload running. But can it sustain several teams moving large datasets? Do you need private connectivity? Can workloads resolve internal DNS? What happens when a transfer fails halfway through?

For EU-sensitive workloads, the location of the GPU cluster is only the beginning. Check where checkpoints, model artefacts, logs and backups end up. Find out where support staff can access the environment. Read the provider's subprocessor list. Residency is an end-to-end property of the workload, not a regional checkbox.

Acceptance test: run the actual data-loading pattern at expected scale, document the complete data flow and calculate the resulting cost per completed job before extrapolating from a benchmark.

The first security review is where the demo meets the enterprise.

A researcher can train a model on a new cluster with a small dataset and temporary credentials. That proves it works technically. It does not prove it's ready for sensitive workloads.

Picture a financial firm evaluating EU-hosted compute. The hardware fits. The research team is happy. Then security asks where the checkpoints go. Legal asks whether support staff outside the region can access the environment. Platform engineering asks how workloads authenticate to existing data. Operations asks where the audit logs will live.

"The GPUs are in the EU" doesn't answer those questions. Nor does a provider's compliance certificate replace your own architecture review.

Providers are getting better at this. Nebius runs data centres across European locations with a growing set of enterprise features. CoreWeave has published enterprise identity and key-control capabilities. Crusoe holds ISO 27001 and SOC 2 Type II. But each provider's features differ by service, and each still needs integration with your groups, workload permissions, network policies and audit requirements.

Compare what your workload actually requires against what each provider supports for the service you're buying. A compliance certificate or an approved region is evidence for a particular scope, not blanket approval of your end-to-end architecture.

Don't create a permanent security exception for AI. Bring new compute under the controls your business already trusts.

Your researchers didn't ask for another cloud. They asked to get more work done.

The first job runs. Then twenty more researchers want access. One team needs a different GPU type. Another wants reserved capacity. A third wants to compare the same experiment across providers.

Giving everyone direct access pushes provider-specific authentication, storage, quotas and deployment work onto the people you were trying to speed up.

Shopify's published implementation is worth studying because it uses Nebius alongside Google Cloud. Their SkyPilot-based platform routes suitable GPU jobs to Nebius while enforcing Shopify's own scheduling, cost-ownership and configuration rules. A custom routing plugin intercepts every job request before it reaches a cluster. H200 requests go to Nebius. L4 or CPU-only work goes to GCP. Explicit overrides are available when needed.

They also enforce a showback_cost_owner_ref label on every job. If a workload doesn't carry an owner tag, it doesn't run. Their blog describes this as "annoying but it means we actually know where our GPU spend goes." A GPU reaper terminates jobs running below 20% utilisation.

The researcher writes accelerators: H200:8 and the platform handles the rest. Provider-specific configuration (InfiniBand setup, storage paths, CUDA versions) gets injected automatically.

The point is not that every organisation needs Shopify's exact stack. It's that these building blocks solve different problems and are not interchangeable:

• SkyPilot routes jobs to the right cluster. It operates above the cluster.
• Kueue admits jobs within a cluster based on quota and priority. It operates inside the cluster. MultiKueue extends dispatch across clusters.
• Ray is a distributed compute framework. It runs inside a job.
• KubeRay deploys and manages Ray clusters on Kubernetes.

A complete stack might use SkyPilot to route a job to Nebius, Kueue to admit it based on team quota, KubeRay to deploy a Ray cluster and Ray Train for distributed training within it. Each handles a different concern. Collapsing them into "we use SkyPilot" misrepresents how much integration work is involved.

Don't introduce every abstraction on day one. A single provider and a small team may only need well-designed job templates. Quotas become important when teams compete for reserved GPUs. Cross-provider routing is useful when you actually have a placement decision to automate.

Then finance asks a question your monitoring dashboard can't answer.

You built the business case on better economics. Now you need to prove it. Researchers are running jobs. Utilisation is climbing. Finance asks which team consumed the capacity and whether the new provider is delivering the savings that justified the investment.

The provider has billing data. Kubernetes shows resource usage. Your experiment tracker knows which jobs ran. Those three systems probably don't agree on what a completed experiment actually cost.

A job can occupy eight GPUs for ten hours while spending much of that time waiting on data. Reserved capacity may already be paid for whether you use it or not. Restarts and failed experiments consume resources too. Across providers, billing records, cluster telemetry and experiment logs rarely line up without deliberate work to join them.

What you need to build:

• A common labelling convention enforced at submission time, not applied after the fact.
• Billing data aggregation from each provider into your cost management system.
• Showback or chargeback that works across the combined estate.
• Waste detection. Idle GPUs on a specialist cloud burn budget silently. Shopify's reaper approach (terminate jobs below a utilisation threshold) is worth adopting early.

When teams can see what they're spending, behaviour changes. Researchers right-size their jobs. Platform engineers spot idle capacity. Leadership compares the economics of completed workloads instead of arguing over rate cards.

The first serious failure reveals whether you have a platform.

Your CTO approved the investment. Your researchers are productive. Then a long training job fails overnight. The business case assumed reliable compute. Now you find out whether you've built a production platform or an impressive demonstration.

Is it a GPU fault, an interrupted data path, exhausted storage or a provider incident? Can the job resume from a checkpoint? Is that checkpoint accessible in the recovery environment? Can the on-call engineer tell who owns the next action?

Providers are getting better at resilience. Managed recovery features, node replacement and checkpoint storage vary by provider and service level. Don't compare goodput benchmarks across providers without controlling for workload, cluster size and failure type. Ask each provider how the specific service you're buying handles node failures, checkpoint storage, capacity replacement and escalation. Test recovery with your own workload.

When your workload spans your estate and a provider's infrastructure, you need to agree in advance who is responsible for what:

• Checkpointing. Your training code must checkpoint at intervals that balance recovery time against I/O overhead. Store the checkpoint somewhere accessible for recovery, not only on the provider's local storage.
• Automatic recovery. SkyPilot's managed spot jobs can recover preempted work on a different cluster. This requires idempotent jobs, accessible data and a configured recovery path.
• Capacity fallback. If the specialist provider's capacity runs out, can the job move to your existing cloud? Only if the right GPU types are available, the data is accessible and the environment is configured. Most organisations can't do this without significant preparation.
• Partial failure in distributed jobs. A multi-node training run where one node fails is different from a single-node preemption. PyTorch Distributed, DeepSpeed and Ray handle faults differently. Some can recover from partial failures; others need a full restart.

Day-two operations go well beyond failure recovery. GPU driver and CUDA version compatibility. Certificate rotation. VPN tunnel maintenance. Node pool management. Provider API changes. Abandoned storage cleanup. Monitoring integration. Each of these is a recurring task your team inherits. Provider dashboards help, but your team needs a joined-up picture of application, scheduler, GPU, storage, network and identity across both environments.

Six months later, someone needs to reproduce a result.

A research finding is challenged. A regulator asks how a model was trained. A team wants to build on earlier work. The code and model weights exist. But which dataset version, container image, CUDA and PyTorch versions, GPU type and distributed configuration produced the result? Was the job resumed from a checkpoint? Where are the audit records?

Reproducibility across environments means:

• Digest-pinned container images with exact versions of CUDA, cuDNN, PyTorch and all dependencies. Not latest tags.
• Recorded hardware configuration. A model trained on 8×H200 with InfiniBand may produce different results on 8×A100 with Ethernet, even with the same code and data.
• Versioned data. The exact training data used, not a pointer to a mutable dataset.
• Experiment tracking. Weights & Biases, MLflow or equivalent, configured to record hyperparameters, metrics, hardware and code version from every environment where experiments run.
• Unified audit trails. Who launched what, when, where, with what access. The combination of provider audit logs and your own experiment tracking creates the full record.

Experiment tracking products handle parts of this. But the full reproducibility problem (pinning every dependency, recording topology, versioning data, unifying audit trails across environments) remains largely your work. It gets harder, not easier, when you add a second compute environment.

The second provider reveals what you really built.

Suppose your first integration succeeds. Six months later, another team wants different GPUs. A new provider offers better capacity, a more suitable region or a price that changes the economics.

Do you repeat the entire exercise? Another identity configuration. Another deployment process. Another monitoring system. Another cost report. Another operational burden.

Or can you extend what you already have?

The advantage isn't access to five GPU clouds. It's being able to introduce the next one without rebuilding your engineering organisation around it.

This doesn't mean every workload should be portable. Large training jobs depend on particular hardware, interconnects, storage and data locality. Moving them indiscriminately can destroy the savings you hoped to achieve. What should be reusable is your organisation's ability to evaluate a new provider, get security approval, deploy a workload, observe it and operate it without starting from scratch.

What is solved, what is partially solved and what remains genuinely hard.

As of September 2026, an honest assessment of where things stand. These describe the problem category, not the maturity of any single provider. A "solved" problem still needs implementing for your environment.

Solved. Single-provider Kubernetes access. Identity federation to one provider: Nebius's SAML SSO, CoreWeave's SAML/OIDC with SCIM provisioning, Crusoe's enterprise identity, each available for their respective services. Basic VPN connectivity. Job scheduling within a cluster via Kueue. Single-provider cost tracking. SkyPilot for cross-provider job routing (Shopify runs it in production across Nebius and Google Cloud).

Partially solved. Cross-provider identity: you can federate to each provider separately, but no widely adopted product yet unifies IAM across your existing cloud and multiple specialist providers. Cross-provider networking: private interconnect options exist for some cloud pairings but not all, and coverage and performance vary by provider and region. Data movement at scale: provider-specific products and Shopify's Nebius replication pattern show the direction, but availability differs. Unified observability across providers. Multi-cluster quota-aware scheduling via Kueue's MultiKueue.

Genuinely hard. Unified secrets management across three or more environments. Stateful workload migration with TB-scale checkpoints and topology-specific performance. Unified audit trails joining multiple providers with different log schemas and retention policies. Cross-provider capacity management that goes beyond spreadsheets. Full Kubernetes multi-cluster federation, which despite years of community effort remains immature.

Don't wait until every problem is solved before starting. But don't pretend the partially solved and genuinely hard ones won't find you.

Get one real workload into production. Then make the next one easier.

The opposite mistake is to recognise this challenge and spend months designing an elaborate multi-cloud platform before anyone has run a useful workload. Start with one workload and a production acceptance test that protects the original investment case.

1. Choose the workload that justifies the move. Lower completed-job cost? Faster experiments? Available capacity? Newer hardware? An approved processing location? Set a baseline, name an owner and agree what success looks like.
2. Resolve what could stop it. Identity, security, networking, data and residency requirements, while they can still influence provider selection and contract terms.
3. Connect it to your existing operating model. Reuse your developer tools, access controls, monitoring and incident response. Build the missing integration, not another organisation.
4. Prove the result under real conditions. Run the actual workload. Measure useful throughput, total cost, time to production, reliability and the effort required to support it. Test access revocation, failure recovery and incident escalation.
5. Keep what makes the next move easier. Turn proven identity patterns, job interfaces, cost attribution and operational practices into reusable capabilities. Add wider orchestration only when demand warrants it.

The first milestone isn't "we have a multi-cloud platform." It's "our researchers can run this workload securely, economically and reliably, and our existing team can support it."

The next infrastructure advantage is the ability to absorb change.

New GPU hardware will arrive. Capacity and pricing will shift. Providers will expand their regions and enterprise features. Those developments only matter to organisations that can act on them.

If every new provider requires months of engineering, your choices are limited by your integration backlog. If you have a proven way to bring in new compute, you can choose based on the workload, the economics and the business need.

The GPUs are the purchase. The ability to put them to work inside your business is the asset.

Sources and further reading. Shopify Engineering: SkyPilot at Shopify (Jan 2026). CoreWeave blog: Enterprise Identity and Key Control, Cross-Cloud AI Capabilities, Security Architecture (Sept 2026). Nebius documentation. Crusoe documentation. SkyPilot documentation. Kueue documentation. AWS SageMaker HyperPod. Practitioner discussions on Hacker News regarding multi-cloud GPU infrastructure, data gravity and operational challenges. Verify all provider features and terms for your specific service, region and contract.