The weights clause: who keeps the model when the vendor relationship ends
Most AI vendor contracts never say who owns fine-tuned model weights when the relationship ends, and unsettled terms rarely favor the side that did not draft them.
Most AI vendor contracts stay silent on who owns fine-tuned model weights when the relationship ends, leaving ownership unsettled rather than resolved in the customer's favor. The weights clause should say three things plainly: the customer keeps the model, the intelligence stays in the customer's cloud, and exit is an ownership event rather than a data-return event.
"What happens to the model if we part ways?" is a question every AI vendor hears eventually, usually late in a deal, after the pilot has already produced something worth keeping. It rarely arrives as a redline. It arrives as a pause in the room, right after someone on the buying side does the math on what unwinding a bad vendor relationship would cost.
Most vendors answer with a sentence about data: your data is yours, it never leaves your environment, delete it whenever you like. That sentence is true, and it answers a different question than the one being asked. Data was never the asset a buyer spent years building. The fine-tuned model was, the one trained on four years of a company's own outcomes. On the specific question of who owns that model once the contract ends, most AI vendor contracts say nothing at all.
Silence is not a neutral outcome here. Whoever drafted the agreement drafted the silence, and it rarely favors the side that didn't write it.
The instinct behind the question is sound
A buyer who raises this before signing is doing the job well. Vendor lock-in has a long history in enterprise software, and every procurement team has a story about a system that became too expensive to leave. Not because the system stopped working. Because leaving meant starting over. AI raises the stakes on that pattern instead of lowering them. A CRM holds records. A fine-tuned model holds something closer to judgment: four years of who performed, who ramped fast, and what a company's best people did differently on the job. Losing access to that at exit is not like losing a dashboard. It is closer to losing the memory behind every decision the system ever helped make.
Outside counsel who write about AI vendor agreements keep landing on the same gap. A contract-clauses review published by Ward and Smith notes that ownership of a model customized on a customer's own data is rarely settled by any general contracting default. It depends entirely on what the agreement says in writing, and buyers who never raised the question during procurement are the ones who find out the answer during a renewal negotiation, at the exact moment they have the least room to change it.
A related habit is worth watching for on the buyer side of the table. A vendor can agree to hand back data exports in a portable format at termination while treating the fine-tuned weights themselves as infrastructure that never leaves. Both promises can sit in the same contract without contradicting each other on paper, and a buyer who only checked the data-return clause would sign believing the exit question was settled when it never was.
The clause has three sentences
A weights clause that protects a buyer does not need to be long. It needs to say three things, in this order, because the order carries the argument.
The first sentence is ownership: the customer keeps the model. Not a license to keep using it while the vendor relationship continues, but ownership, named as property, of the version fine-tuned on that customer's own outcomes. This is the sentence most silent contracts are missing, and it should be settled before any other exit term, because everything else in the clause depends on it.
The second sentence is location: the intelligence stays in the customer's cloud. A model a customer owns on paper but cannot reach in practice is not really owned. When the fine-tune lives in a shared vendor environment, and the customer's access depends on credentials the vendor controls, ownership is a word in a contract with nothing behind it. The model has to already be running inside infrastructure the customer's own team can see, so ownership at exit confirms what was already true, rather than triggering a data-transfer project on the day the relationship ends.
The third sentence describes the nature of exit itself: it is an ownership event rather than a data-return event. Most vendor contracts, when they address termination at all, describe an exit in terms borrowed from data handling: delete customer data within some number of days, certify that no copies remain, hand back exports in a portable format. Those obligations matter, but they cover what happens to inputs. They say nothing about the model those inputs produced. An exit clause that returns data while the vendor keeps the weights has returned the smaller half of what the customer paid to build. The customer gets the raw material back. The vendor keeps what the raw material became.
Put together, the clause reads less like an escape hatch and more like a description of an architecture that was already true on day one. That distinction matters in how it gets pitched internally. Leading with "you can walk away any time" undersells the point and puts the vendor in a defensive crouch. The stronger frame, and the one that survives a real procurement review, is ownership first, with the exit right surfacing on its own once the reviewer asks. A reviewer can tell the difference between a right that was extracted under pressure and a right that was designed in from the start, and the second one is what earns trust in the room.
What a redline looks like
Picture a standard AI vendor agreement that reached the review stage with a single sentence on this subject: "Customer Data will be deleted or returned upon termination." That sentence says nothing about the model, and a buyer's team that stops at "our data is protected" has confirmed the wrong thing.
The fix is not to demand new rights from a reluctant vendor. It is to make explicit what a properly built architecture already does. The redline adds a defined term, Customer Model, meaning the version of the base model fine-tuned on that customer's data, and states plainly that Customer Model is owned by the customer, deployed within the customer's own environment during the term, and remains fully accessible and operable by the customer after termination, independent of any further step by the vendor. Nothing about that sentence describes a favor. It describes where the model already sits and who already controls the infrastructure it runs on, the same standard the exit-map inspection surface asks a non-technical buyer to check before signing anything.
A vendor whose architecture is genuinely single-tenant, with fine-tuning that happens inside the customer's own cloud, can accept that language without changing anything about how the product runs day to day. A vendor who resists it is usually telling a buyer something true about their infrastructure: the model does not live where the buyer assumed it lived, and the clause would force a rebuild the vendor would rather avoid.
The proof this survives a real review
Vague exit language is one of the more common reasons a vendor review drags on. A reviewer who cannot get a straight answer on what happens to the model keeps the file open and keeps asking, and every extra round trip adds weeks. A clause with three settled sentences removes that entire category of follow-up before it starts, because there is nothing left to negotiate on the point.
That is what happened at a Fortune 500 insurance carrier that had already rejected six AI hiring vendors over eighteen months, every one of them on architecture rather than product: cleared review took 17 days and the deployment reached production 34 days later. The ownership answer was never a concession made under deadline pressure. It was a description of how the model was already built, fine-tuned inside the customer's own environment with property rights on the customer's title from the first training run, the pipeline covered in full in how a model improves without moving data. A reviewer testing that claim can check the same five points covered in five questions that test any AI sovereignty claim, and the weights question is the one that most often separates an architecture built for ownership from a slide that borrowed the word.
Sources
The clause is the pitch
A vendor that volunteers the weights clause before a buyer asks for it has told that buyer something more useful than any benchmark. It has shown a system built to be owned rather than rented, where exit was designed in alongside everything else instead of bolted on during a contract renewal.
The buyer who asks "what happens if we part ways" is not looking for reassurance. They are looking for three sentences a contract either has or does not have. The vendor who can point to them, rather than promise them, is the one who built the architecture the question was about all along.
Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.