Your standard vendor review was built for software that stores and processes data in predictable ways. An AI model or AI feature adds questions that review does not ask. What happens to the prompts? Can the vendor train on them? What changes when the vendor swaps the model underneath?
The answers often decide whether you can use the tool with customer data at all. They also end up in your own customers' questionnaires, so you will be repeating them.
This article lists the questions to add, grouped by what they protect, with notes on what a useful answer looks like. It assumes you already run general due diligence, as in a vendor due diligence checklist, and adds the AI layer on top.
Start with what the tool will touch
Not every AI tool needs every question. A grammar assistant used on public marketing copy is a different review from a model that will process support tickets containing customer data.
Tier the vendor by the data it will receive and the decisions its output will inform. The method in vendor tiering by data access applies unchanged. Then ask the questions below in proportion. For the lowest tier, the data questions alone may be enough.
Questions about your data
These matter most, and vague answers are common.
Do you use our inputs or outputs to train or improve any model? Ask separately about the default setting and what the contract guarantees. A settings toggle is not a contractual commitment.
How long do you retain prompts, files, and outputs, and why? Some services keep inputs for a period for abuse monitoring even when they do not train on them. Ask for the period, the purpose, and whether it can be shortened.
Who at your company can access our data, and under what conditions? Look for named roles, logged access, and a stated reason for access, such as a support request or an abuse investigation.
Do you store derived data? Embeddings, vector indexes, conversation histories, and cached outputs are all data. Ask where they live and whether deletion covers them.
If we fine-tune or customize a model, who owns it, and is it isolated from other customers?
How do we delete our data, and how do you confirm deletion?
Questions about where it runs
Which regions process and store our data? Include where inference runs, not only where data is stored at rest.
Who are your subprocessors for this service? Many AI products call a model provider underneath. That provider is a subprocessor, and its terms shape what your vendor can promise you.
Will you notify us before adding or changing a subprocessor? Get the notice period in writing.
If personal data crosses borders, what transfer mechanism applies? Under GDPR this is a legal question. Confirm the answer with counsel and your privacy lead.
Questions about the model itself
A traditional SaaS vendor changes features. An AI vendor can change the behavior of the same feature by changing the model underneath.
Which model or models does the product use, and who provides them?
How do you communicate model changes? Ask whether you get notice, release notes, or the ability to stay on a version for a period.
How do you test a model before releasing it to customers? Look for a description of evaluations relevant to your use, not a general statement about quality.
What are the documented limitations? A vendor that publishes known limitations and intended uses is easier to govern against than one that does not.
Can we turn the AI feature off? For AI features inside an existing product, an admin-level control matters. Without one, your acceptable use policy is the only control, and it depends on every user.
Questions about security and incidents
Do your security attestations cover this feature? A SOC 2 report or ISO/IEC 27001 certificate has a scope. Check that the AI service is inside it, not a newer product that has not been audited yet.
How do you handle prompt injection and similar attacks? You are not looking for a guarantee. Nobody can give one. You are looking for evidence they have thought about it: input handling, output filtering, and limits on what the model can reach.
What would you notify us about, and how fast? Ask whether AI-specific incidents, such as one customer's data appearing in another's output, are covered by the incident notification commitment.
What logs can we get? If you need to investigate how the tool was used, find out now whether admin logs or usage exports exist.
Questions about governance
Who owns AI risk at your company? A named role is better than "the security team."
Do you follow a framework? An ISO/IEC 42001 certificate is third-party evidence of a governed process. Read its scope carefully. A claim of following the NIST AI RMF is a self-assessment, so ask what it covers.
How do customers report a concern about model behavior, and what happens next?
Asking these supports your own supplier controls if you are working toward ISO/IEC 42001, mainly A.10 on third-party relationships. The ISO 42001 framework page summarizes the rest.
What belongs in the contract
Answers in a questionnaire are representations. Terms in a contract are commitments. Move the ones that matter into the agreement or the data processing agreement:
- Not done:
No training on your inputs or outputs, stated as a contractual term
- Not done:
Retention periods for prompts, outputs, and derived data
- Not done:
Deletion on request and at termination, including derived data
- Not done:
Subprocessor list, with advance notice of changes
- Not done:
Processing locations
- Not done:
Incident notification scope and timeline
- Not done:
Notice of material model changes, where your use depends on behavior
Reading the answers
A few patterns signal that a follow-up is needed:
The answer describes the company's general security, not this product.
The answer refers to a model provider's policy without saying how your vendor's own terms align with it.
"We do not train on customer data," with no mention of retention, logging, or human review.
Attestation reports with a scope that predates the AI feature.
None of these is automatically disqualifying. Each is worth one more question before you sign. Record your conclusion, the residual risk, and who accepted it.
When to ask again
An AI vendor review goes stale faster than most. The product can change materially between annual reviews without a new contract being signed.
Set reassessment triggers in addition to the calendar:
The vendor announces a new underlying model or model provider.
The vendor changes its terms of service, privacy policy, or data processing agreement.
Your team wants to use the tool with a higher classification of data than it was approved for.
The vendor adds features that act on your systems rather than only generating text, such as connecting to your email or code repositories.
A security incident at the vendor, or at its model provider, becomes public.
Each trigger should route to the person who owns the vendor relationship, with a short list of which questions above to ask again. Most reassessments need only a handful of them.
How TrustLynce helps
TrustLynce's third-party risk tools keep the vendor inventory, assign risk tiers, run reviews with your AI questions included, and schedule reassessment, so a vendor's answers are revisited when their product changes.