The AI vendor holds the pen.

Why vendor paper is where the risk gets signed

Most mid-market AI does not arrive as a decision your team made. It arrives as a document a vendor wrote. MIT's NANDA project found external partnerships behind roughly two-thirds of deployments — meaning for most operators your size, the AI initiative is defined, scoped, measured, and priced on the seller's paper before your own people have framed the problem in their own words. (primary PDF)

That matters because the exposure isn't created at go-live. It's created at signature. By the time a pilot is quietly failing, the terms that decide who eats that failure were fixed months earlier, in a paragraph nobody on your side was equipped to interrogate. The vendor who wrote the scope also defined what "delivered" means, also proposed how it would be measured, and — in the common structure — gets paid on their own sign-off regardless of whether the thing worked. RAND put the failure rate of AI projects above 80%, with the number-one cause a misunderstanding of the project's intent and purpose. (rand.org, RRA2680-1) A vendor's scope is a description of intent and purpose written by the party that profits from a particular reading of it.

This is not an accusation that vendors are dishonest. Most aren't. It's a structural point: the person who holds the pen sets the defaults, and defaults favor the drafter. A good vendor will sign fair terms without complaint. The purpose of the interrogation below is not to catch a villain — it's to make the defaults visible while you still have the leverage to change them, which is the fifteen minutes before you sign and not the fifteen months after.

This page is the buyer's side of that table. It costs nothing and it recommends nothing you have to buy, because Tektari sells no implementation and takes no vendor commissions — the whole point of publishing it is that we have no vendor to protect. (See the Verification Charter.)

The seven questions that expose it

Seven questions, in this order. The order is the point. A vendor who has already answered questions one and two in their favor — they wrote the scope, they defined "delivered" — has won the deal before you ever get to price. Ask them out loud, in one room, and write down each answer next to the risk it flags.

The single most consequential question, and the one most often skipped because the answer feels obvious: the vendor did. That's the problem. If the scope of work is written in the vendor's language — "improve forecasting," "enhance quality visibility," "AI-driven insights" — then success is whatever the vendor later says it is. The fix is not to reject their scope; it's to rewrite one sentence in yours: the business problem, as a metric with a current value and a target value, owned by the person on your side who owns the P&L it touches. If your version and their version don't line up, you've found the gap now instead of at invoice time. A vendor who resists you writing your own one-line problem statement is telling you something.

"Delivered" is a word doing enormous quiet work in most AI contracts. Does it mean the software was installed? That a model was trained? That a dashboard exists? Or that the metric in your problem statement actually moved? These are wildly different bars, and vendor paper almost always means the first three, not the last. Ask directly: "What specific, measurable condition marks this as delivered — and is that condition in the contract?" If "delivered" is defined as activity (a thing was built) rather than as outcome (a number changed), you are paying for motion, not results — and you will pay in full whether or not the operation is any better off.

Even with a good definition of "delivered," it collapses if the vendor is the one who measures whether it happened. A demo run on the vendor's curated data, scored by the vendor, is a sales asset — not evidence. The buyer-side standard is an acceptance test your own team can run on your own data, with a threshold you set and a pass/fail rule applied mechanically to the numbers. Ask: "Who runs the test that decides this passed, on whose data, with what threshold, agreed when?" If the only party who can tell you whether it worked is the party who gets paid when it works, you have no measurement — you have a marketing claim with an invoice attached. (This is the discipline behind Tektari's Problem-Definition Audit: it hands your team a vendor acceptance test they can run without us, and without the vendor.)

Now the money question. If the pilot doesn't move the metric, what happens? In the default vendor structure, the answer is: nothing happens to the vendor. They were paid on delivery of activity (question two), which they measured themselves (question three), so failure is entirely your cost — the fee, the internal hours, the opportunity cost, the political capital. Ask: "If the acceptance test fails, what does it cost you?" The honest answer on most paper is "nothing." That's not automatically disqualifying — but it tells you exactly how much skin the vendor has in your outcome, which is the number you should price the risk against. A vendor willing to put even part of the fee behind the acceptance test is a categorically different counterparty than one who isn't, and you learn which you're dealing with by asking.

Assume it goes badly and you leave in month four. What do you have that still has value? The trained model? The cleaned and labeled data? The integration work? The documentation? Or a login that stops working the day you stop paying? Ask what survives your departure, and get it in writing. Gartner projected at least 30% of generative-AI projects would be abandoned after proof-of-concept, and S&P Global found the average organization scraps 46% of its POCs (via CIO Dive) — so a walk is not the edge case, it's the base rate. If the answer to "what do we keep if we walk?" is "nothing you can use without us," you're not buying a tool, you're renting a dependency, and you should price it as one.

Ownership is where AI deals differ most from ordinary software, because there are three things to own, not one: your input data, the outputs the model generates from it, and any derived artifacts — fine-tuned weights, embeddings, labeled training sets — you paid to create. Vendor defaults quietly claim more of these than buyers realize. Watch three clauses specifically: (a) a license letting the vendor train its models on your data — your operational data improving a product your competitors also buy; (b) ambiguous ownership of fine-tuned models or embeddings built on your data, which are often the real value and are easy to leave undefined; and (c) outputs you cannot export in a usable format when you leave. Say plainly what you expect to own — your inputs, your outputs, your paid-for derived artifacts — and make the contract say it in words, not leave it to a default that was written by the other side.

Read the exit before you sign the entry — it's the truest statement of the real relationship. Ask for the notice period, the data-return format and deadline, whether there's a deletion certificate, what happens to fine-tuned models and embeddings on the way out, and what migration actually costs in money and months. Lock-in isn't always a clause; more often it's an accumulation — proprietary data formats, undocumented integrations, workflows rebuilt around the vendor's tool — that quietly raises your switching cost every quarter until the renewal price is whatever they want it to be, because leaving costs more. The whole seven-question interrogation converges here: whatever you cannot take with you when you walk is the vendor's leverage over you, and that leverage is priced into every renewal, forever.

The method: how to run the interrogation before signing

The questions only work if you ask them at the right time, of the right people, in the right order. The method is short:

1. Run it before signature, not after. Every question above is answerable in an afternoon before you sign and unanswerable — or answerable only in your disfavor — after. The leverage is entirely front-loaded. Put the interrogation in the buying process as a gate, not the onboarding process as a formality.
2. Write your one-line problem statement first, in your own words, before you read theirs. Metric, current value, target value, owner. This is your anchor for question one, and doing it first means the vendor's scope gets compared to your intent instead of replacing it. (This is the whole of the field guide's first spoke, and worth doing even for a small pilot.)
3. Ask all seven in one sitting, in order, and write down each answer. Order matters because early answers set up later ones — a vendor who defined "delivered" as activity (Q2) is the same vendor for whom failure costs nothing (Q4). Use the checklist below so nothing gets skipped and every answer is recorded next to the risk it flags.
4. Insist the answers land in the contract, not the sales call. A reassuring verbal answer that isn't in the signed document is worth exactly nothing on the day it matters. For every question, the follow-up is the same four words: "Is that in writing?" If it's important enough to ask, it's important enough to be a clause.
5. Treat a refused answer as an answer. A vendor who won't let you write your own problem statement, won't define "delivered" as an outcome, won't let your team run the acceptance test, or won't commit exit terms to paper has told you where the deal's risk lives. You don't need them to admit it; you need them to decline, on the record, before you sign.

None of this requires a lawyer to start — it requires an operator asking plain questions and writing down the answers. Counsel should review the contract; but the seven questions surface the exposure counsel would otherwise have to reverse-engineer from a signed document, which is far harder and far later.

A worked example

Synthetic and clean-room — a composite mid-market operator, not a real company or a real vendor. Names, numbers, and terms are invented to show the interrogation working end to end.

The situation. "Northwind Components" (invented) is a $140M contract manufacturer. A vendor, "ClearSight AI" (invented), proposes an AI visual-inspection system for a finishing line, on a 12-month contract at $18,000/month plus a $60,000 setup fee. The deck promises to "dramatically reduce escapes and rework through AI-powered defect detection." The COO likes the demo — on ClearSight's sample images, the system catches defects a tired inspector might miss. She runs the seven questions before signing.

The outcome. Northwind didn't reject the vendor — the technology might be fine. It changed the deal from "pay $276,000 for an installed system the vendor grades" to "pay for a measured drop in customer returns your own QA team verifies, with your data and models staying yours, and a clean exit if it fails." ClearSight agreed to five of the seven changes and balked at tying fee to the acceptance test (Q4). That balk was the most valuable answer of the afternoon: it told Northwind exactly how confident the vendor really was in its own outcome. They signed a shorter pilot with the acceptance test as the gate to the full contract — the risk moved back across the table, in writing, before a dollar was spent.

The template: the vendor-scoping interrogation checklist

Copy this into your buying process and fill it in during the vendor conversation — before signature, not after. Record each answer verbatim and note the risk it flags. A blank or a refusal is an answer; write it down too. This is the buyer's side of the table on one page.

VENDOR-SCOPING INTERROGATION — AI PROCUREMENT CHECKLIST
Run before signature. One sitting, in order. Record every answer.

Vendor: [vendor name]          Initiative: [what it's supposed to do]
Our sponsor (owns the P&L): [name / title]     Date: [date]
Fee proposed: [$ amount + structure]   Term: [months]

OUR ONE-LINE PROBLEM STATEMENT (write this FIRST, before reading theirs):
  Metric: [the business number this must move]
  Current value: [today's number]  →  Target value: [the goal]
  Owner: [person on our side who owns that number]

── Q1 · WHO WROTE THE SCOPE ───────────────────────────────
  Their scope language: [quote it]
  Does it match our problem statement above?  [ yes / no / partly ]
  Answer recorded: [__________]
  RISK FLAGGED: [e.g. success is undefined / vendor's language wins]

── Q2 · WHO DEFINED "DELIVERED" ───────────────────────────
  "Delivered" in their paper = [installed? trained? metric moved?]
  Is it an OUTCOME (a number changed) or ACTIVITY (a thing built)?  [__________]
  Is that definition IN THE CONTRACT?  [ yes / no ]
  RISK FLAGGED: [e.g. paying for motion, not results]

── Q3 · WHO MEASURES IT ───────────────────────────────────
  Who runs the acceptance test? [ our team / vendor / third party ]
  On whose data? [ ours / vendor's sample ]
  Threshold set by whom, agreed when? [__________]
  RISK FLAGGED: [e.g. vendor grades its own homework]

── Q4 · WHO CARRIES THE COST OF FAILURE ───────────────────
  If the acceptance test fails, what does it cost the VENDOR? [__________]
  Is any fee tied to the outcome? [ yes: $____ / no ]
  RISK FLAGGED: [e.g. failure is 100% our cost]

── Q5 · WHAT WE KEEP IF WE WALK ───────────────────────────
  On termination we retain: [ data / labels / model / integrations / nothing ]
  In a usable, exportable format?  [ yes / no ]
  RISK FLAGGED: [e.g. renting a dependency, not buying a tool]

── Q6 · WHO OWNS THE DATA & OUTPUTS ───────────────────────
  Our input data — owner: [__________]
  Outputs generated from it — owner: [__________]
  Derived artifacts (fine-tuned model, embeddings, labels) — owner: [__________]
  Can the vendor train its models on our data?  [ yes — STRIKE IT / no ]
  RISK FLAGGED: [e.g. our defect data improves a competitor's product]

── Q7 · LOCK-IN & EXIT TERMS ──────────────────────────────
  Notice period: [___]   Data-return format & deadline: [__________]
  Deletion certificate?  [ yes / no ]
  Fate of fine-tuned models / embeddings on exit: [__________]
  Migration cost (money + months): [__________]
  RISK FLAGGED: [e.g. no clean way out; renewal price = ours to take]

── FOR EVERY ANSWER ABOVE ─────────────────────────────────
  "Is that in writing?"  →  [ yes, clause # ___ / no — get it added / refused ]

DECISION: [ sign / renegotiate these clauses: ______ / walk ]
The most useful answer is often the one they REFUSE to give. Log refusals.

Related tools in the field guide: the hub links all five spokes, including the problem-statement spoke (write your one-line metric before you read the vendor's scope) and the acceptance-test spoke (how to write the pass/fail line the vendor can't grade for you). When you're ready to put a signed baseline and a runnable acceptance test on one specific decision, that's the Problem-Definition Audit.

Frequently asked questions

What are the most important AI vendor due-diligence questions?

Seven, in order: who wrote the scope; who defined "delivered"; who measures whether it was delivered; who carries the cost of failure; what you keep if you walk; who owns the data and the model outputs; and what the lock-in and exit terms are. They are ordered on purpose — a vendor who wrote the scope and defined "delivered" has already won the deal before price is discussed. Ask them in that order, in one room, before you sign.

Why does most AI risk get signed on vendor paper?

Because most mid-market AI arrives on vendor paper — MIT's NANDA project found external partnerships behind roughly two-thirds of deployments. The party that writes the scope, defines "delivered," and gets paid on their own sign-off has structured the deal so that failure is your problem and payment is theirs. The exposure isn't created at go-live; it's created at signature, in language nobody on your side was equipped to interrogate.

Should we use a proof of concept to evaluate an AI vendor?

A POC only evaluates the vendor if you defined what a pass looks like before it ran, on your data, with a threshold you set. Gartner projected at least 30% of generative-AI POCs would be abandoned after proof-of-concept, and S&P Global found the average organization scraps 46% of its POCs — largely because the POC had no pre-agreed acceptance test, so it could neither pass nor fail, only fade. A demo the vendor scored on their data is a sales asset, not due diligence.

Who should own the data and the model outputs in an AI vendor contract?

You should own your input data, the outputs generated from it, and any derived artifacts you paid to produce — and the contract should say so in words, not leave it to a default. Watch three specific clauses: a license letting the vendor train on your data, ambiguous ownership of fine-tuned weights or embeddings, and outputs you cannot export in a usable format if you leave. Whatever you cannot take with you when you walk is the vendor's leverage, priced into every renewal.

How do we evaluate an AI vendor's lock-in and exit terms?

Read the exit before you sign the entry. Ask for the notice period, the data-return format and deadline, whether there is a deletion certificate, what happens to fine-tuned models and embeddings, and what it costs to migrate. If the honest answer to "what do we keep if we walk in month four?" is "nothing you can use without us," you are not buying a tool — you are renting a dependency, and the price of that dependency is set on renewal day, not signing day.

Take the Scoreboard