Let’s talk about the clause in your AI contract that decides whether your business quietly becomes somebody else’s training data.
Picture the procurement meeting. Six people around a table, maybe eight. The finance lead has one question and it’s about price per seat. IT wants to know about SSO. Legal has a redline on liability and indemnity, and they’ve done this a hundred times, so they know where the real fight is. Someone asks whether the pilot can start Monday.
Nobody asks what happens to the forty thousand support tickets you’re about to point at the thing.
The invoice says software. That’s the first lie, and it’s not even a lie anybody tells. It’s just the shape the paperwork takes. What you actually bought is a licence for a model to learn from your operation, priced as if it were a licence for a tool.
Now, the machine itself is not the interesting part. The definitions are.
Open the data processing addendum — the schedule nobody reads, the one that gets attached at the end and signed with the same pen as everything else. Look for four phrases. Usage Data. Feedback. Derived Data. Service improvement. Then look for the escape hatch they always put next to them: aggregated and de-identified.
Every one of those is a door. The question is which side of it your business ends up on.
Is prompt content usage data? Is the output? Is the correction your team makes when the model gets it wrong — the moment a person with fifteen years of experience types “no, that’s not how we do it, here’s why” — is that feedback the vendor can use? And once they’ve used it, who owns the model that came out the other side?
Because that’s the part with the real value in it. Not your seats. Your corrections. The gap between what the model knows and what your business knows is the only thing you’re bringing to the table that they can’t get elsewhere, and it’s the exact thing the contract is quietly asking you to donate.
Here’s why this stays invisible for years.
Nothing breaks. There’s no outage, no invoice line, no angry email. The tool works better than the thing it replaced, people are happy, the pilot becomes a rollout, and the renewal comes around and nobody has any reason to look at it again.
The loss leaks instead. It leaks in the second-order effects. The vendor sells the same system to your competitor, and now it’s better at your category than you are, because you taught it your category. Their next productised offering looks suspiciously like the workflow your operations team spent two years refining. Or the relationship ends badly, or the vendor gets acquired, or the data sits on a disk with a retention policy you can’t see and a breach notice you’ll read in a news article.
None of that shows up as a cost. That’s what makes it a good deal for them.
Now, the honest version, because I’m not going to pretend this is always wrong.
Sometimes the trade is right. You’re a twelve-person business with no ML team, the vendor’s model is better than anything you could build in five years, and the data you’re handing over has no strategic value whatsoever — it’s invoices and delivery notes and nobody’s competitive advantage lives there. Take the deal. Take it fast.
The failure isn’t making the trade. It’s making it by default, while telling yourself you bought software. Those are different decisions with different prices, and only one of them is on the quote.
So here’s what actually matters at the table.
Rewrite the definitions, not the clause. A clause that says “we won’t train on your data” is worth nothing if the definition of your data excludes the only part that counts. Name it explicitly: prompt content, outputs, ticket text, customer records, and any model artefact derived from them. No training, no fine-tuning, no evaluation, no reinforcement from your usage. Put “service improvement” in the list of things that don’t get an exception.
And treat “de-identified” as a promise, not a property. It describes an intention, not a guarantee, and it gets weaker every year as re-identification gets cheaper.
Then the boring operational stuff, which is where the leverage actually lives. Deletion on exit, with a certificate and a date, not a “reasonable efforts” clause. A named subprocessor list and notice when it changes. Audit logs you can actually pull, so that in eighteen months you can prove what the system did inside your workflow. And the one most people miss: own your evaluation set. The twenty or thirty cases that define what good output looks like for your business. Write them yourself, keep them in your own repo, and run them against any replacement. If you can’t tell whether a new vendor is worse, you don’t have a contract, you have a dependency with paperwork.
The test is simple. If you switched providers tomorrow, what still works? The answer should be your process, your data, and your standards. If the answer is nothing, you didn’t buy a tool. You rented a capability and left the recipe with the landlord.
And then there’s the part that doesn’t fit in a contract review.
Those support tickets are people’s worst days. Somebody’s bond application that got declined, somebody’s mother’s medical aid claim, somebody’s business that’s three weeks from closing. Your internal documents are somebody’s decade — the engineer who wrote the runbook at eleven at night, the rep who built the objection-handling guide out of two hundred lost deals.
That work has authors. When a company signs it into a training set as an unpriced side effect of a software purchase, nobody asks them. Not because anyone’s being cruel. Because the paperwork never had a field for it.
So the question at the end of the deal isn’t whether the AI is good. It usually is. The question is what your company agreed to become in order to use it, and whether anyone who understood the answer was in the room when it was decided.
If you don’t know which clause governs training, you don’t know what you bought. Go and read the schedule. It’s dull, it’s badly written, and it’s the most financially important page in the stack.