A buyer stopped mid-signature on an AI receptionist deal to ask who owns the AI chatbot configuration if the model underneath it gets replaced, and whether any of it leaves with the business when the relationship ends. The pen did not move again for three weeks.
That pause was correct. Most AI communication contracts are written as though the software is the asset. It is not. The asset is everything the buyer's own business poured into the system, and almost no order form names it.
The Pen Stops Mid-Signature
The operations lead read the intellectual property clause twice, then asked whether the clause covered the code or the configuration. The clause covered the code. It said nothing about the prompt set, the retrieval index, or the test cases someone on their team had spent a fortnight arguing over.
They were not worried about theft. They were worried about the day they wanted to switch and discovered that switching meant starting again from a blank text box.
This is a pattern, not an outlier. Operators in this market have stopped asking whether the automation works and started asking what happens to it afterwards. The underlying fear has been measured: a 2026 Zapier survey of 542 US leaders holding active paid AI vendor contracts found that 74 percent either expected operational disruption or described their organisation as fully reliant if a key AI vendor ended service, as reported from that survey. Three quarters of buyers know they are exposed. Very few have a clause that does anything about it.
The Assumption the Vendor Didn't Expect
The buyer's assumption was that the configuration was theirs by default, in the way a logo designed for them is theirs. It is a reasonable assumption and it is usually wrong.
Under a standard order form, the vendor owns the platform, and the configuration sits inside the platform. There is no separate object called "your setup" with its own title. If the contract does not carve it out, it does not exist as a transferable thing, and the question of who owns the AI chatbot configuration has no answer at all, which in practice means the answer is the vendor.
The fix is a single sentence naming the artefacts. Ownership has to name the derived artefacts rather than only the code: the prompts, any fine-tuned weights, the embeddings built from the buyer's own documents, and the evaluation set. Contract guidance on this point makes the reason explicit, which is that those pieces are made from your material and are the parts a successor cannot cheaply rebuild.
What Was Actually Sitting Inside the Agent
It is worth being specific about what a working AI receptionist for a clinic or an agency actually contains after six months. There are five things, and only one of them is software.
- The prompt library. Not one prompt. The main system prompt plus the branching instructions for pricing questions, complaints, out-of-hours bookings, and the three enquiry types that only exist in this business.
- The retrieval index. Embeddings built from the price list, the treatment descriptions, the cancellation policy, the objection answers the sales lead wrote by hand.
- The evaluation set. The fifty to two hundred real conversations someone labelled as good or bad answers. This is the most expensive artefact in the stack and the one buyers forget to ask for.
- The routing and escalation logic. Which enquiries go to a human, at what confidence, during which hours.
- The conversation history. Every thread across WhatsApp, Instagram, Messenger and email, which is both a customer record and the raw material for the next evaluation set.
A successor vendor given all five can be live in days. A successor vendor given none of them is doing the original build again at the original price. That gap is the entire commercial value of an export clause.
Reading the Fine Print at the Tier They Actually Bought
The second thing the buyer got right was refusing to read the vendor's public privacy page and calling it done. Training and data-use language has to be read at the tier being purchased, because business and API terms routinely differ from the consumer product carrying the same brand name. A screenshot of a consumer help centre article proves nothing about an API contract.
There is a structural reason this keeps catching people. Every AI agreement a mid-market operator signs is really a stack of three documents. There is the vendor's own master agreement or order form, the one in front of the buyer. Underneath it sit the model provider's terms, which govern the component doing the actual work and which the vendor accepted on the buyer's behalf before the buyer was in the room. The buyer negotiates the top document and inherits the rest.
Ask for the middle document by name. Which model provider, which tier, and what does that tier say about training on inputs. A vendor who cannot answer that in one email does not know either.
The Warranty That Wasn't There
The clause the buyer nearly relied on was indemnity, because it was the only one that mentioned risk. Indemnity as vendors write it answers third-party intellectual property claims about the output, which is the rarer exposure. It does not answer the output being wrong, which is the common one, and that gap belongs in the warranty and liability sections instead.
For a business selling appointments, wrong output is the whole risk surface. An agent that quotes a discontinued price, books into a closed slot, or tells a patient a treatment is suitable when it is not, does not trigger an IP claim. It triggers a refund, a complaint, or in regulated categories something worse.
The related gap is the service level. Service levels written for software measure availability, while an AI system usually fails by degrading rather than by stopping. So the agreement needs a quality threshold tied to the acceptance criteria and a remedy when the system falls under it. A perfect availability record is compatible with an agent that has quietly become useless, because nothing in an uptime figure measures whether the answers are still right.
Write the threshold in the buyer's own terms. Percentage of conversations resolved without a human, percentage escalated correctly, measured monthly against the same evaluation set the system was accepted on. If the evaluation set is not owned by the buyer, the threshold is unenforceable, which is the second reason that artefact matters.
A Contract Can Outlive Its Own Model
Here is the timing problem nobody prices. A one-year or three-year agreement can outlive the component it was accepted on, and almost no contract says who pays to re-qualify the system when that day arrives.
The published retirement commitments differ enough to matter, and they are commitments about notice, not about longevity. Each provider publishes its own deprecation policy, and the summary below reflects one contracts analysis of what those policies currently say; read the provider's own page before you rely on a number in a negotiation, because these policies change without touching your contract.
| Provider | Reported commitment on model retirement | What that means for a 36-month contract |
|---|---|---|
| OpenAI | At least six months' notice on generally available models | Roughly one full quarter of planning time, twice over, inside the term |
| Anthropic | At least sixty days' notice | Two months from notice to re-qualification, if notice lands mid-term |
| Microsoft Foundry | Retirement set eighteen months from a model's launch, with retirement dates described as not extendable | A 36-month term spans at least one forced migration, scheduled from day one |
Run the arithmetic on the third row with your own dates. Sign a 36-month agreement on a Foundry-hosted model that launched six months before your start date, and the model reaches its retirement date twelve months into your term. You then have twenty-four months of contract left on a component that no longer exists. Who rebuilds and re-tests the agent, and at whose cost, is a question the order form almost certainly does not answer.
The clause is short. Model substitution requires notice and written approval, re-qualification against the existing evaluation set is at the vendor's cost, and failure to meet the quality threshold after substitution is a termination event without penalty.
One warning on technical comfort here. A model gateway cannot prevent an upstream model from changing if the agreement allows unannounced substitution, and a multi-model router does not create export rights for fine-tuning artefacts, managed embeddings, prompt libraries or evaluation history. Architecture does not substitute for a clause.
Termination Day: Proving the Data Really Left
The buyer's last question was the hardest to answer honestly. They wanted evidence, not assurance, that their customer conversations were gone from the vendor's systems after termination.
A deletion workflow on the buyer's side cannot prove that copies held by subprocessors or in vendor backups were removed. That is a real limit, and pretending otherwise is how vendors lose clients on renewal. What a contract can do is name the subprocessors, set a deletion deadline in days, require written certification of deletion including backups, and give the buyer the right to ask for it at any point.
The certification is not decorative. The US Federal Trade Commission has stated that model-as-a-service companies failing to abide by their privacy commitments to users and customers may be liable under the laws the FTC enforces. A written promise in a contract is a commitment of exactly that kind. It converts a vendor's goodwill into an enforceable statement.
Exit Terms That Still Get Signed
The objection to all of this is that a small service business has no leverage to rewrite a vendor's paper. Mostly true, and mostly irrelevant, because the moves that work are not rewrites.
Ask for an export, not an amendment. Request a full configuration export as a one-off deliverable during onboarding, delivered as files: prompts as text, evaluation cases as a spreadsheet, retrieval documents in their original form. Most vendors will do this without touching the contract, and once you hold the files the ownership question is far less urgent.
Keep the source material outside the vendor. The price list, policy documents, objection answers and labelled conversations should live in your own drive, versioned, with the vendor working from copies. Embeddings can be rebuilt from source documents. They cannot be rebuilt from nothing.
Build the evaluation set yourself, from your own inbox. Fifty real enquiries with the answer you would want, written by the person who actually handles them. It takes an afternoon, it is yours by any reading of any contract, and it is the instrument that makes a quality threshold enforceable.
Negotiate the renewal, not the signature. Exit terms are cheap to a vendor who wants a second year and expensive to one you are already leaving. Raise configuration ownership at month ten, not month one.
Two moves are borderline and worth naming plainly. Some operators run a parallel build on a second tool for one enquiry type, which gives a genuine fallback and a price benchmark, and carries commercial cost in duplicated effort rather than any platform or legal risk. Others export their own message histories from the platforms directly rather than through the vendor, which is faster but sits against the messaging platforms' developer terms on data handling and, where the messages contain health or identity data, against data protection law as well. Those are different categories of risk. The first suits an operator with slack in the team; the second suits nobody in a regulated category, and anyone else should read their platform's terms before doing it, not after. The safer version of the same instinct is to insist on a monthly conversation export from the vendor as a standing deliverable, which is a contract term rather than a workaround.
What This Changed on Our Side
Configuration ownership is now a standard term in what Learnmind signs, not a concession. Prompts, embeddings, evaluation set and conversation history belong to the client, exportable on request in open formats, with a deletion certificate on termination.
The honest trade-off is that this makes us easier to leave. That is the point. A vendor whose retention depends on the client being unable to move has already stopped competing on the work. Twelve enforceable outcomes are worth defining before an agent touches sensitive data or executes transactions, covering data use, training, retention, intellectual property, model changes, pricing, portability, evidence, supply chains, incidents, regulatory support and termination continuity. Portability and termination continuity are the two that decide whether the business can keep operating after the relationship ends.
If you are sizing an automation build, the same discipline applies to the money: our guide to automation spending covers what is worth paying for and what is not. And if you are still choosing the channel itself, the comparison of a business versus personal WhatsApp number is the decision that comes before any of this, because the number is an asset with its own portability problem.
Contract questions buyers raise before an AI agent goes live
Can I really ask for the prompts if the vendor built them?
Yes, and the argument is stronger than most buyers realise. The prompts encode your pricing, your policies, your objection handling and your tone. The vendor supplied the structure; you supplied the substance. Ask for the prompt set as a plain text export and treat a refusal as information about the relationship rather than a technical limitation.
What is the minimum clause to add if the vendor will only accept one change?
Make it the export right. One sentence: on request or on termination, the vendor provides the prompt library, evaluation set, retrieval source documents and full conversation history in machine-readable formats within a named number of days. Ownership disputes become academic once you hold the files, and this single clause does more for continuity than a page of warranty language.
How do I know if the model under my agent has changed?
You usually cannot tell from the outside, which is why it belongs in the contract rather than in monitoring. Ask which model and version is in use today, get it in writing, and require notice and approval before substitution. Then re-run your own evaluation set monthly, because a change you were not told about shows up as drift in results before it shows up anywhere else.
Does any of this apply to a small salon or clinic, or only to enterprise buyers?
It applies at any size, but the artefacts are smaller and the export is therefore easier. A single-location clinic might have one system prompt, forty retrieval documents and sixty evaluation cases. That is a folder, not a data migration, and there is no good reason for a vendor to refuse to hand it over.
If you are reviewing an AI communication contract this month and want a second opinion on the ownership and exit clauses specifically, we are happy to read it with you and say plainly what is missing. No obligation to change anything you already have in place.
If you want a second look at how this works on your own numbers, talk to us and we will walk you through it.
