Enterprise AI review combines familiar SaaS questions with AI-specific questions about model providers, training use, retention, retrieval, tool permissions, output handling, change control and incident response. The practical problem for a vendor is not merely answering a questionnaire. It is being able to connect each material answer to a defensible scope and supporting evidence.
1. “Never” claims without a defined scope
Absolute claims such as “we never train on customer data” are attractive because they are easy to understand. They are also fragile if the product has multiple providers, optional telemetry, separate free and enterprise tiers, fine-tuning features or support workflows. The procurement-ready version of the claim makes the boundary explicit and can point to the document or control that enforces it.
2. Retention described as one number
“30-day retention” may refer only to primary application data while logs, backups, embeddings, abuse-monitoring traces or model-provider records follow different schedules. Buyers increasingly ask for retention by data class and processing path rather than a single headline number.
3. Subprocessor lists that omit AI dependency context
A conventional subprocessor list says who receives data. AI procurement often needs the next layer: what each provider does, what data reaches it, whether a model provider retains inputs, which region is used and what happens if the provider/model changes.
4. Model-provider names without version/change control
Knowing the provider is not the same thing as knowing what changes when the underlying model changes. A defensible answer identifies the affected product path, how changes are evaluated, who approves them and what customers are told when the behavior or risk profile materially changes.
5. “Red team” used as a vague marketing noun
Buyers may ask whether testing included the AI interaction layer rather than only conventional application security. Evidence should state scope, date, methodology, environment and whether issues such as prompt injection, information disclosure, tool misuse or retrieval isolation were actually covered.
6. Security documentation that stops at SOC 2
SOC 2 can be highly relevant to the underlying control environment, but it does not automatically answer every AI-specific product question. Keep the control assurance and the AI behavior evidence distinct.
7. Retrieval permissions described but not demonstrated
For RAG and enterprise search products, a common buyer question is whether retrieval respects source-system permissions and tenant/user boundaries at query time. A written architecture description is useful; a reproducible test or control evidence is stronger.
8. Tool/agent autonomy without a clear approval boundary
Agentic products need an explicit answer to a simple buyer question: what can the system do without a human approval, and how is that limit enforced? Documentation should distinguish model suggestion from permitted action.
9. Incident processes that do not name AI-specific events
A general security incident process may not explain whether model behavior, prompt injection, cross-tenant retrieval or harmful autonomous action is treated as an incident, who triages it and what customers are told.
10. Privacy, security and sales pages that make different promises
Procurement review is cross-document by nature. A sales page may say “zero retention,” a privacy policy may reserve broad processing rights, and support documentation may describe logs. Even when each statement was written in good faith, the buyer sees the inconsistency.
11. No owner for the answer
Evidence decays when no person owns the representation. A procurement-ready evidence pack identifies who can update the answer when a model, provider, policy or architecture changes.
12. “Not found” treated as “does not exist”
Good assessment language preserves epistemic boundaries. If a public source does not contain evidence, the correct conclusion is that it was not located in the reviewed material—not that the control definitively does not exist.
What good readiness looks like
A mature system is not a 200-row spreadsheet of yes/no answers. It is a maintainable evidence map: material claim, scope, source, evidence owner, relevant control/test, last review date, known limitation and buyer-facing answer.