Most AI in most organizations was never bought as AI. It arrived inside a product purchased for another reason, under terms agreed before the feature existed, and was switched on by an update.
That is the central fact of AI vendor risk, and it means supplier review built around new purchases will miss the majority of your exposure. This page covers what to ask, what to look for in the agreement, and how to review an estate you already own.
Start with the suppliers you already have
Before assessing anything new, work through the products already in use and establish which have added AI capability and whether it is enabled.
Check admin consoles and release notes rather than relying on recollection. Ask each major supplier directly, in writing, which AI features are available in your tier, which are on by default, and what changed in the last twelve months. The answers are frequently surprising to the people who own the contract.
This is the same work as the second step of building an AI inventory, approached from the vendor side rather than the user side, and doing both is how the two lists reconcile.
The questions worth asking
Fifteen, grouped. Ask for the answers in writing and read the linked policies rather than the summary, because the substantive answer is usually in a document referenced by the agreement rather than in the agreement itself.
On data. What happens to the information we put in. Is it used to train or improve any model, ours or anyone else's, and can that be switched off in writing rather than by a setting. How long is it retained, and can we set that. Can we require deletion, and what does deletion actually cover, including logs, caches and backups. Where is it processed, geographically. Which subprocessors are involved, and how are we told when that list changes.
On security. How is data encrypted in transit and at rest. How do we authenticate, and does it integrate with our identity provider. How is access controlled within the product, and does the AI feature respect the permissions our users already have. What independent assurance exists, and may we see the report rather than the badge.
On the model and the service. Which model underlies the feature, and are we told when it changes. What service level applies, and does it cover the AI capability specifically or only the product it sits inside. What happens to our data and our configuration if we leave.
On incidents and change. What is the notification commitment when something goes wrong, and to whom. What is the notice period for a material change to terms, model or default settings.
A supplier who will not answer the training and retention questions in writing has answered them.
What to look for in the agreement
Five things, and the absence of any of them is a finding rather than a formality.
A written statement on training use. The most consequential single term, and the one most often addressed in a policy page the agreement links to rather than in the agreement. A policy page can be changed without notice; a contractual commitment cannot.
Retention and deletion you can act on. Including whether you can require deletion on request and on termination, and what is excluded.
Notice of material change. Model changes, capability changes and default-setting changes all affect an assessment you have already done. Without a notice term, your reassessment triggers depend on noticing.
Incident notification with a timeframe. An undertaking to notify without a period attached is not one.
Exit and portability. What you can take with you, in what format, and for how long it remains available.
Where an AI capability arrives inside an existing contract, the practical question is whether your current terms already cover it or whether the supplier is relying on an acceptable-use policy that postdates your signature. That is worth establishing before the capability is in use rather than afterwards.
Categories of AI supplier, and how the questions shift
The list above applies to all of them, but the emphasis changes and it is worth knowing which conversation you are having.
General-purpose assistants sold at enterprise tier. The training and retention questions dominate, and enterprise tiers frequently differ materially from the consumer product on exactly those points. Establish which tier you actually hold.
AI features inside software you already own. The contract question dominates, because the terms predate the feature. This is where most organizations have the least visibility and the most exposure.
AI capability reached through an API. Security and integration questions dominate, particularly what the calling system can reach and what is logged. Your own configuration is doing more of the work than the vendor's.
Sector-specific systems. Where the product makes or informs decisions about people, the human oversight and explainability questions dominate and the supplier's answers should be specific to your regulatory context rather than generic.
We name categories rather than products deliberately. Vendor terms change faster than any page can be reviewed, and a supplier's current position should be read from their current documentation rather than from ours.
Assurance reports, and what a certificate does not tell you
A supplier holding a recognized certification has demonstrated something real about how it runs its business. It has not demonstrated anything about how your use of its AI feature will behave.
Ask for the report rather than the badge, and read the scope statement first: certifications cover a defined boundary, and an AI capability added recently may sit outside the scope of the last audit. Ask which of the supplier's services the certificate covers and as of when.
ISO/IEC 42001:2023 specifies requirements for an AI management system and organizations may seek independent certification against it. Certification is voluntary, and it says something about the supplier's management system rather than about the safety of a particular use case. LABUSA is not a certification body.
What good looks like in a procurement process
The durable improvement is not a longer questionnaire. It is a trigger, early, that catches AI before the purchase is made.
Add one question to whatever approval already exists for buying software: does this product include AI capability, and if so, is it on by default. A yes routes the request to the assessment described in AI risk assessment. That single question does more than any amount of downstream review, because it moves the conversation to a point where declining is still cheap.
GAO reported in April 2026 that federal agencies were not consistently collecting and applying lessons learned from earlier AI acquisitions. That finding concerns federal agencies, and the pattern it describes, buying without capturing what the last purchase taught you, is not unique to government. Keeping a short record of what each assessment concluded, and consulting it before the next one, is cheap and unusual.
Federal agencies operate under specific AI acquisition guidance from OMB. Those requirements apply to federal agencies. Other organizations may adopt the same shape by choice.
Where the data actually goes, and why the answer is layered
One question causes more confusion than the rest combined: does the supplier use our data to train models. The answer is usually layered rather than yes or no, and the layers are where organizations get caught out.
A supplier may not train a general model on your content while still retaining it for abuse monitoring, still logging prompts for a period, still passing content to a model provider it does not itself operate, and still applying a different position to a free tier that some of your staff are using alongside the enterprise one.
Four separate answers, and a summary sentence in marketing material collapses all four into one. Ask them separately: training, retention, subprocessing, and whether the position differs by tier. Then ask which of the four are contractual and which are described in a policy the supplier can revise.
The joint CISA, NSA and FBI guidance on AI data security is a useful reference for the lifecycle view of this, covering data risks from development and testing through to deployment and operation.
Reviewing what you approved
A vendor assessment describes a supplier on a date. Set a review date, and set triggers: a model change, a terms change, a new default-on capability, a subprocessor change, an incident, or an acquisition of the supplier.
The acquisition trigger is the one most often missing and the one most likely to change the answers to the data questions entirely.
Where to go next
Vendor review is one domain of the governance framework and step eight of the ten-step sequence. The security questions above are expanded in the AI cybersecurity risks to assess before deployment.
LABUSA reviews AI suppliers and contracts as part of an AI governance advisory work, including the awkward case of capability already live inside an existing agreement. We are vendor-neutral and hold no reseller relationship that would shape the answer. If you have a specific supplier in front of you, talk it through with us.