Procurement due diligence was built to assess a stable thing. Is the vendor financially sound, is the software secure, does the contract protect us, where does the data sit. Answer those and you have covered the risk - for a piece of software that does roughly the same thing this year as next.
An AI vendor is not that thing. It processes your data through a model that can change, learns from what passes through it, and makes or shapes decisions in ways a security review never inspects. The standard checklist still asks its questions, and the vendor still answers them, and everyone signs, and none of the questions that actually matter for an AI tool were on the form.
Why the standard checklist misses the risk
The conventional due-diligence checklist is not wrong. It is incomplete in a specific way: every question on it treats the vendor's product as a fixed object to be inspected once. That assumption is what AI breaks.
A security questionnaire asks how data is encrypted and who can access it. It does not ask what the model does with the data once it is inside - whether it trains on it, what it infers from it, where the inference runs. A financial-stability check tells you the company will still exist next year, not that the model behind the product might be swapped for a different one next quarter.
The checklist inspects the container and never looks at what the AI actually does with the contents. For a static tool that gap did not matter. For an AI vendor it is the whole risk.
The questions worth adding
If you are bringing in an AI vendor, a handful of questions belong on the form that a standard checklist leaves off. They are not exotic - they are the things that decide your exposure, and the things a vendor is least practised at answering clearly. The ones that matter most at onboarding are the ones you lose the ability to ask once you have signed.
Ask where the inference actually happens, and who else touches the data. An AI feature often calls a model run by someone other than the vendor - a sub-processor, sometimes a foundation-model provider two steps removed. You are not assessing one company; you are assessing a chain, and each link is a place your data goes.
This is the question onboarding is uniquely placed to answer, because the chain is hardest to map once you are already inside it.
Ask what happens to the relationship if you need to leave. AI vendors can be sticky in a way ordinary software is not: the model has learned your patterns, the outputs are woven into a workflow, and there may be no equivalent to switch to. Exit is a due-diligence question you ask before you sign, not after you are locked in - and it is the one a vendor has least incentive to raise.
Ask what the model trains on, and whether your data is part of it, and get the answer in the contract, not the sales call. The commitment you want is specific: your data is not used to train shared models without explicit, revocable consent. This one you can also revisit at renewal, but it is far cheaper to settle at the gate than to claw back later.
Ask whether using the tool makes you responsible for its AI. Under the EU AI Act, deploying a vendor's AI feature can place obligations on you as the deployer, regardless of who built it. That is a question to answer at onboarding, because the answer may change whether you want the tool at all.
Ask the engineer, not only the form
Here is the part I care most about, having spent a career on the building side of this. The questions above are not really legal questions, even though they have legal consequences. They are technical questions about how a system is built and where data moves, and the person best placed to ask them is not always the one running the procurement process.
A procurement checklist is answered by two commercial teams talking to each other. The most revealing AI due-diligence questions get answered properly only when someone who understands model architecture, data flow and sub-processors is in the room to ask the follow-up.
"Where does inference run?" is a fine question on a form; the useful version is the three follow-ups a technical reviewer asks when the first answer is evasive. Bring that person to the assessment, and the vendor's answers change.
The limit worth naming
None of this makes AI-vendor due diligence a checklist you can complete and file. The vendor you assess carefully at onboarding will still change after you sign - that is the reassessment problem, and it is a live one, not a one-time gate. Good due diligence at the front door does not remove the need to keep watching; it just means you start from an honest baseline rather than a blind one.
What onboarding diligence buys you is the one thing you cannot get later: the upper hand. Before you sign, you can ask for the training commitment, the sub-processor list, the exit terms, and walk away if they are not there. After you sign, you are asking a vendor to give up something they already have. The questions cost nothing to ask at the gate and a great deal to raise once you are inside.
Frequently asked questions
What should you check before signing an AI vendor?
Montro's view is that AI-vendor due diligence has to go beyond the standard security and financial checks. Establish what the model trains on and whether your data is included; where inference runs and which sub-processors or model providers touch your data; what your exit options are if you need to leave; and whether deploying the tool places EU AI Act deployer obligations on you.
These are the questions a conventional procurement checklist omits, and the ones that decide your actual exposure.
How is AI vendor due diligence different from normal vendor due diligence?
Standard due diligence treats a vendor's product as a fixed object assessed once. An AI vendor's product changes - the model can be retrained or swapped, it learns from data passing through it, and it makes or shapes decisions a security review never inspects. So AI due diligence has to ask what the model does with your data, not only how the data is stored and secured, and it has to account for a chain of sub-processors rather than a single company.
Should data-training terms be settled before signing?
Yes. Before signing, you are in a position to require a written commitment that your data is not used to train shared models without explicit, revocable consent.
After signing, you are asking the vendor to give up something the existing agreement may already permit. The training question is far cheaper to settle at the gate than at renewal, when the processing may already have happened.
Does bringing in an AI vendor create obligations under the EU AI Act?
It can. Deploying a vendor's AI feature can make you a deployer under the EU AI Act, with obligations that attach to your use regardless of who built the system.
This is why deployer status is worth establishing at onboarding: it can affect whether the tool is worth adopting, and it is not a question the vendor's sales process will raise for you.
