AI Compliance · 2026-07-30 · 10 min read
AI Vendor Risk Assessment Questions: The 2026 List That Matters
Most AI vendor questionnaires quote the right facts about the wrong pricing tier. Here are the eight question areas that actually matter — training defaults, retention, subprocessors, ISO 42001, DPA terms, and the EU AI Act role you inherit — plus a copy-paste question list.
An AI vendor risk assessment should answer eight questions: whether the vendor trains on your data by default — and on which tier — how long prompts are retained, where data is processed, which subprocessors touch it, which certifications the vendor holds (SOC 2, ISO 27001, ISO 42001), what the DPA guarantees, what regulatory role the tool puts you in, and how the vendor cooperates during incidents.
Standard vendor questionnaires were written for ordinary SaaS. AI vendors break them: the risk isn't just "can they keep our data secure" but "does our data become their product" and "what legal duties do we inherit." Here are the questions that matter, and the most common mistake teams make.
Why AI vendor risk assessment is different from normal vendor review
Three things change:
- Your data can become training data — absorbed into a model that serves other customers, with a default that differs by pricing tier.
- You inherit regulatory roles. Using an AI tool can make you a deployer under the EU AI Act; building your product on a vendor's model API typically makes you the provider of your downstream feature.
- Many duties stay with you regardless of the vendor. Under NYC Local Law 144 (in force since 1 January 2023, enforcement since 5 July 2023), the employer owns the annual bias-audit duty even when the hiring tool is a vendor's ATS product.
Does the AI vendor train on your data by default?
This is the first question, and the one most teams get wrong — not because the answer is hard to find, but because it is different on every pricing tier. Ask four things, in writing:
- Is customer content used to train or improve models by default on the exact tier and product we will use?
- If yes, is there an opt-out, and does it apply retroactively to data already submitted?
- Do humans ever review our prompts or outputs (abuse monitoring, quality, anything else)?
- Is the no-training commitment in the contract or DPA, or only on a policy page the vendor can change tomorrow?
There is also a downstream trap: if the tool fine-tunes a model on your data and you release the result publicly, California AB 2013 (Civ. Code §§3110–3111, in force since 1 January 2026, no size threshold) treats fine-tuning as a "substantial modification" (§3110(d)) — making you a developer who must publish a 12-element training-data summary before the system is publicly available to Californians. The law is operative (the xAI v. Bonta injunction was denied 4 March 2026), enforced via UCL §17200 at up to $2,500 per violation, no cure period.
The consumer-tier trap: right facts, wrong tier
The most common assessment error is quoting facts about one tier while the organization uses another. It happens in both directions:
- Optimistic: the security review cites the vendor's enterprise documentation ("no training, SOC 2, SSO, DPA") — while half the company is on free consumer accounts, where training-by-default and no DPA is the norm. Run a shadow AI discovery pass before trusting any tier assumption.
- Pessimistic: procurement blocks a tool because "it trains on your data" — true of the free consumer tier, not of the business tier the company would actually buy.
Typical tier differences (patterns, not guarantees — verify each vendor):
| Question | Consumer/free tier (typical) | Business/API tier (typical) |
|---|---|---|
| Trains on your data by default | Often yes, with opt-out | Usually no |
| DPA available | Rarely | Yes |
| Retention controls | Limited | Configurable, sometimes zero-retention |
| Admin controls, SSO, audit logs | No | Yes |
| Security commitments | Terms of service only | Negotiated MSA/DPA |
The rule: assess the tier you will actually use, and verify people are actually on it.
How long does the vendor retain your prompts and outputs?
"We don't train on your data" is not the same as "we don't keep your data." Ask:
- What is the retention window for inputs and outputs on our tier?
- Is a zero-retention or short-retention option available?
- Is there a separate abuse-monitoring buffer where prompts are held, and for how long?
- How long does deleted data persist in backups?
- On termination, what is deleted, by when, and will the vendor certify it?
Retention determines what a breach exposes and what you can honestly tell your own customers.
Where is your data processed, and who are the subprocessors?
Two questions hide inside "residency":
- Where are inference and storage performed, and can we pin a region (for example, EU-only processing)?
- Who else touches the data? Most AI features inside SaaS products are wrappers on a third-party model API — your contract is with the SaaS vendor, but your prompts may flow to a model provider you never evaluated. Ask for the full subprocessor list, which entities receive prompt content specifically, and advance notice of changes: if the model provider behind the feature changes, your risk profile changes.
Which certifications should an AI vendor have? SOC 2 vs ISO 27001 vs ISO 42001
| Certification | What it covers | AI-specific? | What it proves |
|---|---|---|---|
| SOC 2 Type II | Security, availability, confidentiality controls over time | No | Independent audit of security controls in operation |
| ISO/IEC 27001 | Information security management system | No | Certified, audited security governance |
| ISO/IEC 42001:2023 | AI management system (clauses 4–10 plus Annex A controls) | Yes | Certified governance of how the vendor builds and runs AI |
Two clarifications:
- SOC 2 and ISO 27001 say nothing about training practices, model risk, or AI governance. Necessary, not sufficient. ISO/IEC 42001:2023 is the certifiable AI-specific standard — see ISO 42001 vs NIST AI RMF for which to ask about.
- "NIST AI RMF aligned" is a self-claim, not a certification. NIST AI RMF 1.0 (January 2023) is voluntary — 4 functions, 72 subcategories, plus the Generative AI Profile (NIST AI 600-1, July 2024). Nobody audits "alignment," and it is not a legal shield: under Texas TRAIGA (in force since 1 January 2026), substantial NIST AI RMF compliance is only a discovery-channel qualifier for a defense (§552.105(e)(2)), not standalone immunity.
What should the DPA and contract actually say?
Get commitments into signed documents, not marketing pages:
- A no-training clause covering your content, on your tier, in the DPA itself.
- Retention terms: named windows for inputs, outputs, and abuse buffers; certified deletion on termination.
- Subprocessor flow-down: the commitments bind the model provider behind the feature, not just the vendor you signed with.
- A residency commitment as a contract term, not a dashboard setting.
- Incident notification with a defined clock and a named contact.
- Audit and evidence rights: certification reports on request, plus cooperation with audits you are legally required to run.
- Regulatory cooperation: the vendor supplies what you need for your own obligations — transparency disclosures, bias audits, impact assessments.
What EU AI Act role does this vendor put you in?
The EU AI Act assigns duties by role — provider, deployer, importer, distributor — so the assessment must answer: what are we, once we deploy this? Two patterns cover most buyers:
- You use the vendor's AI tool internally → typically a deployer of that system.
- You build your product feature on the vendor's model API → typically the provider of your downstream feature. The model vendor holds the GPAI duties; the product-level duties are yours.
Timing makes this urgent. Article 50 transparency obligations — disclosing AI interaction, marking AI-generated content, deep-fake disclosure — apply from 2 August 2026, backed by the general penalty regime — live since 2 August 2025 — of up to €15M or 3% of worldwide turnover applying from the same date. The Digital Omnibus (adopted June 2026) deferred the high-risk regime (Annex III systems apply from 2 December 2027) but did not defer Article 50, the GPAI rules, or penalties. So if you are the provider of the customer-facing feature, the Article 50 duties are yours — "the vendor handles compliance" is usually wrong.
Not sure which role you land in? See does the EU AI Act apply to my company, or run the free EU AI Act checker — risk tier and role-scoped obligations, with citations, in about three minutes.
How will the vendor cooperate during an incident?
Ask about the worst day, not the best one:
- Does the breach notification window cover AI-specific incidents — prompt-injection exploitation, training-data leakage through outputs, a model rollback that changes behavior your users rely on?
- Can we get logs of our own traffic for forensics?
- Will the vendor supply technical documentation if a regulator or plaintiff asks?
That last one is not hypothetical. Under NYC Local Law 144, the annual independent bias audit (no more than one year old at time of use) is the employer's duty even for a vendor-supplied hiring tool — penalties run $500 first violation, $500–$1,500 subsequent, and audit and posting failures accrue per day. A vendor that won't support your audit generates your fines; the NYC Local Law 144 bias audit guide covers the mechanics.
The AI vendor risk assessment question list
The copy-paste version:
- Do you train on our content by default on our exact tier? Is opt-out retroactive?
- Is the no-training commitment in the DPA?
- Do humans review our prompts or outputs, and when?
- What are the retention windows for inputs, outputs, and abuse buffers?
- Is zero-retention available? What happens to backups after deletion?
- Where are inference and storage performed? Can we pin a region?
- Which subprocessors receive prompt content? Which model provider is behind the feature, and will we be notified before it changes?
- Which certifications do you hold — SOC 2 Type II, ISO 27001, ISO/IEC 42001 — and can we see the reports?
- What is your incident notification window, and does it cover AI-specific incidents?
- Will you supply the documentation we need for our own duties — Article 50 disclosures, bias audits, training-data summaries?
- Does using this product make us a provider or a deployer under the EU AI Act?
Start from pre-verified vendor profiles instead of a blank questionnaire
Multiplied across every AI tool in the company, this is weeks of work — and the answers go stale as vendors change policies. Shieldra ships 40 pre-verified AI vendor profiles, with trains-on-your-data defaults sourced from the vendors' own pages, so most questionnaires start pre-answered. Paired with shadow-AI discovery matching usage against 284 known AI tools, you assess the vendors actually in use — including the ones nobody told procurement about. See features for how the vendor catalog, discovery, and AI acceptable use policy templates connect.
FAQ
What is the single most important AI vendor risk assessment question?
Whether the vendor trains on your data by default on the exact tier you will use, and whether the no-training commitment appears in the DPA rather than only on a policy page. Consumer and business tiers of the same product routinely have opposite defaults.
Do SOC 2 or ISO 27001 cover AI-specific risks?
No. They audit security controls and security management — still worth requiring — but say nothing about training practices or model governance. ISO/IEC 42001:2023, the certifiable AI management system standard (clauses 4–10 plus Annex A controls), is the AI-specific credential to ask about.
Does using an AI vendor make my company a provider or a deployer under the EU AI Act?
Using a vendor's tool internally typically makes you a deployer; building your product feature on a vendor's model API typically makes you the provider of the downstream feature, while the model vendor holds the GPAI duties. Article 50 transparency duties — penalties up to €15M or 3% of worldwide turnover — apply from 2 August 2026 to whoever holds the relevant role.
Is "we don't train on your data" enough to approve an AI vendor?
No. Training is one of eight areas — you still need retention, residency, subprocessors, certifications, DPA terms, incident cooperation, and your resulting regulatory role. A vendor can honestly never train on your data and still retain prompts indefinitely, in a region you can't accept, via subprocessors you've never heard of.
Who is liable if a vendor's AI hiring tool turns out to be biased?
Generally the employer, not just the vendor. NYC Local Law 144 (in force since 1 January 2023) puts the bias-audit, publication, and candidate-notice duties on the employer even for vendor-supplied tools, and Illinois HB 3773 (775 ILCS 5/2-102(L), in force since 1 January 2026) makes discriminatory AI use in employment decisions civil-rights exposure for the employer. The duty stays with you.