The demo takes twenty minutes. The contract decides what happens over the next three years — on the day the outputs are wrong, the invoice doubles, or your team decides to leave. Most buyers spend six weeks evaluating options and one afternoon on the paperwork. Reverse that ratio.
Here are ten questions worth putting in writing before anyone signs, grouped the way they tend to come up in a room. None of them require a law degree to raise. Several of the answers do, so keep counsel close when the language starts to matter.
Who Owns the Data, the Outputs, and the Space Between
Three separate questions, because vendors answer them very differently. What licence do they take over the data you upload or connect? Who owns the outputs — the drafts, classifications, summaries, code — and can the vendor reuse them? And what happens to the layer in the middle: embeddings, indexes, or adjusted model weights derived from your material?
Marketing pages say "your data is yours." Master agreements often grant a broad licence "to provide, maintain, and improve the services." That last phrase is the one that lets them train on your content. Ask them to strike it, or narrow it to operating the service on your behalf.
Then ask what survives termination. If the list of permitted uses is longer after you cancel than during the term, you have your answer.
Can the Model Change Under Your Feet?
Updates ship constantly, and most of them are genuine improvements. But a change that lifts a general benchmark can degrade your specific workflow: a classifier that gets sharper on common cases may drift on your edge cases, and nobody will tell you unless the contract makes them.
Ask how you get notified, how much notice you receive, and whether you can pin a version for a defined period. "We'll let you know" is not a commitment; a notice period measured in months is. Then ask about deprecation: how long the old version stays available, what migration support looks like, and whether you can re-run your own tests before switching.
Build the test set before you need it
A few hundred labelled examples from your own work will tell you more about a version change than any vendor benchmark. Put it together during the pilot, while the examples are fresh and easy to collect.
Compliance Is a Set of Questions, Not a Badge
Certifications matter, but they are a starting point. Frameworks such as SOC 2 or ISO 27001 describe how a company handles data generally. They do not tell you where your data sits or who can read it. Add these to the due diligence list:
- Which regions store and process the data, and can you keep it in one?
- Which subprocessors are involved, and how much notice do you get when that list changes?
- How long is data retained, and how is deletion verified?
- Do humans review your inputs or outputs, and can you opt out?
- What are the incident notification timelines, and who notifies whom?
- Can you audit directly, or at least receive an independent report each year?
If your organisation falls under sector rules or privacy law, the answers have to match what your compliance team has already promised regulators. Bring them in early. Retrofitting a vendor's terms into a filing after the fact is expensive and unpleasant.
Service Levels That Match the Work
Uptime is the easiest number to publish and often the least relevant. If your workflow depends on response time, throughput, or accuracy on your own data, ask for commitments on those things instead. Then ask what a miss actually triggers. Service credits are standard and rarely cover the cost of a broken process.
Pin down support too: who answers, how fast, at which tier, and whether you reach an engineer or a ticket queue. Confirm whether the commitment covers the API, the interface, or both — those frequently have different reliability, and only one of them is in the slide.
The Exit Clause Deserves More Attention Than the Discount
Ask what you can take, in what format, how quickly, and at what cost. "Reasonable efforts to assist" is not an exit plan. Look for a defined export format you can actually load somewhere else, a wind-down period long enough to run a migration, and transition assistance with a named owner.
Test the export before you sign
If there is a sandbox, move a representative dataset out of it and time how long it takes. Note what breaks, what fields disappear, and what needs manual repair. A migration you have rehearsed is a migration; one you have only read about is a hope.
Confirm deletion timelines as well, and check whether backups are carved out. They almost always are. Knowing that in advance beats discovering it during an audit.
Pricing: Follow the Usage Meter
Find the unit that gets billed — seats, tokens, calls, documents, compute — and model your realistic growth against it. Ask what triggers an overage, whether unused commitment rolls over, and how much notice you get before a price increase. Price protection for the first renewal is a reasonable thing to request; whether you get it depends on your leverage.
Watch for definitions that quietly expand. If a "document" includes every enrichment pass, or a "seat" includes read-only viewers, your cost curve is not the one in the spreadsheet. Put the definitions in an appendix and make them hard to change without your consent.
A Two-Hour Exercise Before You Sign
Gather three people: the business owner who will live with the system, someone from security or compliance, and whoever holds the budget. Walk the ten questions in order and write down every answer. Where you get a verbal assurance, ask for it in the agreement. Where you get a "we don't do that," ask what it would cost to add.
Then keep your evaluation set and your export test results somewhere the team can find them. Six months later, when someone proposes an upgrade or a renewal, you will have evidence instead of memory. And when the terms touch data protection, employment, or sector regulation, have a qualified lawyer review the language before you commit.
Photo: advogadoaguilar / Pixabay
