Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / How Cloud Contracts Now Include AI Model Portability Clauses
Transcript
- Lucas: Luna, I was reviewing a cloud contract last week — a Fortune 500 retailer negotiating with AWS — and buried in the AI infrastructure addendum was a clause I hadn't seen six months ago. It was about AI model portability. Not data portability, not code portability, but the specific right to move a trained model — weights, inference graph, everything — to another cloud. Luna: That's interesting. So the hyperscalers are starting to write rules around something they used to treat as a grey area? Lucas: Exactly. Historically, if you trained a large language model on AWS using SageMaker, your model artifacts lived in S3. You could download them, technically. But there was no contractual guarantee that the cloud wouldn't charge you an arm and a leg for egress, or that you could move the inference pipeline without rebuilding it. Now, at least three of the big four — AWS, Azure, GCP — have started offering explicit model portability clauses in their enterprise agreements. Luna: And this is happening because companies want to train on one cloud and deploy on another, or run in a multi-cloud inference mesh? Lucas: Both. The retailer I mentioned trained a recommendation model on GCP — they have a long-standing contract there — but their production inference runs on Azure because that's where their e-commerce stack lives. They needed a contractual right to export the model weights and the inference graph from GCP and import them into Azure within a specified time window. The clause they negotiated caps the export window at 10 hours and limits any egress fees to 0.5 percent of the monthly compute spend on the training side. Luna: That 0.5 percent cap is key. Egress fees have been the hidden tax on cloud portability forever. Lucas: Right. And the clause is very specific about what it covers. Typically, it includes the model weights — the trained parameters — the inference graph, which is the optimized execution plan, and any fine-tuning checkpoints. It explicitly excludes raw training data, logs, and metadata. So if you want to move the model but leave the data behind, fine. If you want to move the data, that's a different clause — data portability — which usually has higher fees. Luna: So the cloud providers are drawing a bright line between the model artifact and the data. That makes sense from a security and compliance standpoint. But is this really about flexibility, or is it a new kind of lock-in? You can move the model, but the inference stack is still tied to their services. Lucas: That's the tension. The clause gives you the right to export the model, but it doesn't guarantee that the model will run efficiently on another cloud. If you've used custom GPU kernels or specific hardware optimizations — say, AWS Trainium or Azure Maia — the inference graph might not be portable. Some contracts include a 'reasonable effort' clause to provide the model in an open format like ONNX, but that's not universal. Luna: So the model portability clause is more like a safety valve than a full portability guarantee. It ensures you're not held hostage by the model weights, but you're still tied to the ecosystem. Lucas: Exactly. And the interesting thing is that these clauses are becoming a competitive differentiator. GCP started offering a model portability add-on last year partly in response to customer concerns about lock-in after they introduced their own TPU v5. AWS followed with a similar clause in March 2026, and Azure has a pilot program with about twenty enterprise customers. The terms vary. AWS's clause, for example, requires the customer to request model export within 30 days of contract termination, and they guarantee export within 72 hours. Azure's clause has a sliding scale: if you're spending over $10 million annually, they cover egress fees up to 5 TB per month for model artifacts. Luna: I've heard from a few infrastructure leads that these clauses are often buried in the fine print. They're not standard in the base agreement — you have to ask for them. Lucas: That's the catch. The model portability clause is usually in an addendum that requires a minimum commitment. The retailer I worked with had a three-year, $15 million annual commitment on GCP before they could even negotiate the portability terms. So it's not for everyone. But for enterprises with significant AI workloads, it's becoming a table-stakes discussion. If your cloud provider doesn't offer it, you might want to ask why. Luna: And that's exactly why these clauses matter. It's not just about moving a model today — it's about the signal it sends about the provider's long-term strategy. Lucas: Which brings us to something I wanted to mention. This show is possible because a small group of listeners chips in monthly through buy me a coffee dot com slash fexingo. It keeps us ad-free, focused purely on topics like this — the fine print that actually shapes how enterprises build and run infrastructure. If you find these contract deep dives useful, that's the same place to support the show. No pressure, but it's how we keep doing them. Luna: Yeah, and it's a small community, but it's the reason we can spend time on a single clause in a cloud contract. We don't have to chase clicks or sponsor angles. Lucas: Exactly. So — back to the model portability clause. One detail I found fascinating is that some contracts are now including a 'model format specification' appendix. It lists the file formats the provider will export in: typically SafeTensors for weights, Protobuf for the inference graph, and JSON for metadata. If you're using a custom format — say, Hugging Face's safetensors variant — you need to check if it's covered. One enterprise I know had to convert their model from a proprietary format to ONNX before export, which took three weeks. Luna: So the clause might guarantee portability in theory, but the practical cost of conversion can be significant. That's another hidden switching cost. Lucas: Right. And that's where negotiation comes in. Some enterprises are asking for the provider to cover the cost of format conversion, or at least provide tooling. AWS has a Model Export Toolkit that runs within SageMaker and can convert to ONNX or SafeTensors automatically. But it's not always included in the base contract. You have to know to ask for it. Luna: So for our listeners who are negotiating cloud contracts today, what's the one thing they should look for in a model portability clause? Lucas: First, make sure the clause explicitly covers the inference graph, not just the weights. Many contracts only cover model weights, but the graph is where the provider's optimization magic lives. Second, check the egress fee cap. If it's not capped, you could be paying a lot to move a large model. Third, ensure the format appendix includes the formats you actually use. And fourth, verify the time window for export. If it's 30 days, that's fine. If it's 7 days, you need to plan accordingly. Luna: And what about multi-cloud deployment? Some companies want to run the same model on two clouds simultaneously for redundancy. Lucas: That's a tougher ask. Most portability clauses are for migration — moving the model from one cloud to another — not for simultaneous deployment. But I've seen a few contracts that include a 'parallel deployment right' that allows you to run the model on two clouds for up to 90 days during a migration. That's rare, though. Typically, you're expected to decommission the model on the original cloud after export. Luna: So the clause is really about exit, not about ongoing multi-cloud flexibility. Lucas: Exactly. And that's an important distinction. If you want true multi-cloud AI, you need a different architecture — like using a model registry that abstracts the underlying infrastructure, or running your inference on a neutral platform. But that's a separate conversation. For now, the model portability clause is a step forward, even if it's a small one. Luna: I'm curious — have any of the hyperscalers started including model portability as a standard term in their small to medium business agreements, or is it still enterprise-only? Lucas: Right now, it's enterprise-only. For SMBs, the model sizes are smaller, so the switching cost is lower. But I think we'll see it trickle down within the next year or two. As more companies train models, the demand for portability will grow. And the providers who make it easy will have a competitive advantage. Luna: It reminds me of the early days of data portability clauses. They started as custom addendums for large customers and became standard within a few years. Lucas: Exactly. And I think model portability will follow the same path. In fact, I'd bet that by 2028, it'll be as standard as data portability is today. The question is whether the providers will compete on the terms — lower egress fees, faster export windows, better format support — or whether they'll converge on a common baseline. Luna: Given the competitive pressure, I'd bet on differentiation, at least for the next couple of years. Lucas: I think you're right. And that's good news for enterprises. It means you have leverage. If you're negotiating a cloud contract today, especially for AI workloads, model portability should be on your list. It's not just about leaving — it's about having the option. And in cloud, options are power.