AI Vendor Due Diligence: A Checklist

Most vendor checklists are lists of topics, and a list of topics produces a folder of answers that nobody can act on. What makes a checklist useful is a pass condition per row: the answer that clears it, and the answer that should stop the purchase.

Two different diligences

Keep these apart, because they have different owners and different timelines. Diligence on the integration asks whether this data may flow to this endpoint under these controls, and it is the security and legal review. Diligence on the vendor asks whether this is a company you want to depend on for three years, and it is mostly commercial.

The second is the one that gets skipped, because the first is mandatory and the second is not. It is also the one that produces the expensive surprises: a price change, a deprecated model, an acquisition, a term that quietly permits the vendor to change terms. None of those are security issues and all of them are your problem.

Timing matters as much as content. Vendor diligence should run in parallel with the evaluation rather than after it, for a reason that is purely about leverage: the moment you can still walk away is the moment you can ask for things, and that moment ends as soon as an integration exists. It is also a queue — contracts and terms take calendar time you do not control — so starting it in week one is worth more elapsed time than any engineering decision you will make. Run it on two candidates rather than one wherever you can, not to create a bidding war but because the comparison is what tells you which of a vendor’s terms are industry-normal and which are unusually bad.

Data terms

The rows here overlap with the security review deliberately — these are the ones you should have settled before the review starts, because a failure here ends the evaluation rather than adding a condition to it.

Commercial terms that move

These are specific to metered AI products and they are where a spreadsheet built during evaluation stops matching the invoice a year later.

• Price change mechanics. Can prices rise inside the term, and with what notice? Per-token prices for a given capability level have generally moved downward over time, which makes people complacent — but the price of your model can rise when the one you use is deprecated and the replacement is dearer. Ask for the notice period on both price and deprecation, in days.
• What an alias resolves to. If you call a name rather than a pinned version, the vendor decides what runs. Ask whether pinned versions exist, how long they live, and how a change is announced — this is the contractual half of detecting a behaviour change you were not told about.
• Overage and minimums. What happens above the plan, and does unused commitment roll over? A commitment is only worth signing against a forecast you trust, and the break-even on committed spend is a calculation rather than a discount you accept.
• Rate limits as a commercial term. Limits are frequently tied to tier or to spend history. Find out the number you will actually get on day one, because a limit that is fine for a pilot and wrong for the rollout is a launch-week outage.
• Support and incident notification. A response-time commitment, and a defined clock for being told about an incident that affected your data. “We will notify you promptly” is not a clock.

Continuity and exit

The rows nobody fills in during a successful evaluation, and the only ones that matter on the day something goes wrong.

• Can you leave? Export format for anything the vendor accumulated — conversation history, evaluations, fine-tuned adapters, indexed content. If a fine-tune lives only inside the vendor, it is not portable even if the training data is.
• How long would a swap take? This is an engineering answer, and the honest version depends on whether you drew an abstraction boundary a provider can be swapped behind. Estimate it before you need it; the estimate is also your negotiating position.
• Is there a second source? For open-weight models, the same weights are typically served by several hosts, so a fallback is a configuration change. For a proprietary model there is exactly one supplier, and that is a structural dependency to name in the risk register rather than to worry about vaguely.
• What happens on acquisition or shutdown? Notice period, data return, and whether your terms survive a change of control.

Turning it into a decision

Score each row as pass, conditional or fail, and pre-commit to what each verdict means, so the evaluation ends in an outcome rather than a discussion.

FAIL on any data-terms row      -> vendor is out, regardless of
                                   product quality
FAIL on a continuity row        -> allowed only for a use case you
                                   could switch off tomorrow
CONDITIONAL                     -> named owner, named date, and it
                                   goes on the risk register now
PASS everywhere                 -> proceed, and re-run the
                                   commercial rows at renewal

The first line is the one to hold. A data-terms failure does not become acceptable because the demo was impressive, and the moment in which you have leverage is before the purchase order, not after the integration. Everything else is negotiable and most of it is worth negotiating: the notice periods, the export commitment and the rate limit are frequently granted simply because somebody asked at the right time.

Record the answers with dates and keep them. Terms change, plans get restructured, and the version of a page you read in March is not evidence of anything in November unless you saved it. A dated file per vendor — the terms as they stood, the sub-processor list as it stood, the answers you were given and by whom — costs nothing to maintain and turns the renewal conversation from a fresh evaluation into a diff. It is also, in practice, what you will be asked for the first time a customer’s security team asks how you chose.