AI vendor documentation checklist for SaaS buyers
ModelCompliance.ai editorial · 4 October 2026
Public AI documentation can help you prepare a vendor review. Use this checklist to turn broad promises into product-specific questions and a record of the evidence you can actually find.
Start with the exact product
Record the feature, plan, region and deployment option you intend to buy. A vendor's general security page may cover its core service without covering a new AI agent. Consumer and enterprise products can have different data terms. Keep the scope alongside every source so that a statement about one feature does not become a claim about the entire supplier.
Separate the vendor from the model provider
Look for the model service, hosting arrangement and subprocessor list. A named model alone does not explain where a prompt travels. Hosted models, external APIs and customer-selected models can create different processing paths. If the public documents leave the provider unclear, record that uncertainty and ask the vendor for a product-specific answer.
Read training statements carefully
Distinguish foundation-model training, vendor fine-tuning, customer-specific models and product improvement. A restriction on a third-party provider does not automatically prohibit the SaaS vendor's own training. Check whether the statement applies by default, depends on an opt-out, or allows a separately agreed programme. Save the relevant settings guide as well as the marketing statement.
Check retention and access separately
No training does not mean no retention. Look for prompt and output retention periods, diagnostic logs, feedback handling, regional exceptions and authorised access. Check whether terms vary by plan. Keep privacy explanations and processing terms together, and note any documents that are only available through a trust centre access request.
Follow the human decision path
Identify who reviews outputs, approves actions, handles escalations and can disable the feature. Drafting an email and autonomously sending one are different workflows. Look for permission boundaries, citations, audit logs and administrator controls. A statement that humans remain in control is more useful when the documentation explains how that control works.
Ask what testing actually covers
Separate ordinary application security testing from AI output evaluations. Useful public evidence may discuss prompt injection, harmful outputs, grounding quality, red teaming, release gates or continuing monitoring. A list of guardrails is useful context, but it is not the same as a published evaluation report. Record that distinction rather than assuming the missing details.
Record dates, limits and follow-up questions
Public documentation changes. Save the URL, title, review date, exact product scope and a short paraphrase. Mark a signal unclear when the reviewed material cannot establish it; do not convert uncertainty into an allegation about private controls. Use the gaps to prepare follow-up questions for procurement and security review.
Use a documentation score as a starting point
The Public AI Documentation Score measures the visibility of twelve documentation signals. It does not establish implementation quality or a legal outcome. Compare the underlying source links and product scopes before comparing scores. A lower score can reflect limited public material rather than weak private practices, and a detailed public page can still need independent validation.
See the twelve checks and scoring methodology, or browse examples in AI support, AI sales and AI productivity.
This checklist supports documentation research. It does not replace a product-specific security review or professional legal advice. Suggest a correction.