When an AI vendor hands you a trust page, you're looking at a statement of intent with no remedy attached. The questionnaire answers on their website and the data processing addendum you can negotiate are entirely different instruments. Knowing the difference is where due diligence actually begins.
This is a working framework for software teams and the business operators who rely on them — not a theoretical checklist, but the specific questions that expose the gap between a vendor's marketing copy and what their contracts will actually commit to.
Start by Separating Documents from Claims
Before asking any questions, request three specific documents: a SOC 2 Type II report (read the scope section and any listed exceptions, not just the badge), a data processing addendum, and their current subprocessor list. These documents tell you what's been tested and what remedies are contractually available. Trust badges without scope context mean very little.
Once you have them, sort every vendor claim into one of three buckets: marketing (no remedy), questionnaire answer (recorded but not contracted), or contract language (enforceable). The goal of this process is to move the claims that matter into the third bucket before you sign.
Follow Your Data Through the Entire Stack
The architecture diagram a vendor shows in a sales call typically traces the happy path. The real question is where a realistic record — say, a customer support ticket that includes personal data — actually ends up across logs, caches, analytics pipelines, vector indexes, support tools, and backups.
Ask vendors to name their model providers and inference locations explicitly. Many SaaS products route requests to a mix of foundation model providers and self-hosted fine-tunes. Each of those hops is a data location that belongs on their subprocessor list. If a vendor can't name all storage locations for prompts, outputs, uploaded files, and derived data like embeddings, that's a gap worth pressing on before any contract gets signed.
For teams with regional compliance obligations, confirm not just where data is stored but where it's processed — and whether support staff in other regions can access production data to handle tickets.
Break Data Retention Into Three Separate Questions
Retention, deletion, and training are often bundled into a single policy clause that vendors present as straightforward. They're not.
Training and fine-tuning: Confirm whether your inputs and outputs are used to train or fine-tune any model. Many vendors offer opt-outs or make this a contract term — but the default may be permissive unless you ask.
Retention periods: Get specific numbers. "We retain data for the minimum necessary period" is not a retention period. Ask separately for live systems, abuse-monitoring windows, and backup schedules — "deleted within N days" almost always refers to live systems only.
Derived data: Embeddings, indexes, and cached representations of your data often survive primary record deletion. A deletion commitment is only complete if it explicitly includes derived representations and requires written confirmation upon completion.
Tenancy, Access Control, and Incident Terms
For multi-tenant SaaS products, the isolation model matters as much as the encryption story. Shared database tables with logical separation carry different risk profiles than separate schemas or dedicated instances. Ask whether tenant isolation has been explicitly scoped in recent penetration tests.
Retrieval-augmented systems introduce a specific risk: if a user's query can surface records from another tenant's data because of a permissions bug, that's a cross-tenant exposure event. Confirm that source-system permissions are enforced per user at query time, not only at ingestion.
For incident notification, replace vague language with specific windows in writing. "Without undue delay" is not a commitment. Define what counts as an incident broadly — cross-tenant data access and unauthorized agent actions should qualify alongside system intrusions.
Finally, before committing, confirm what you can actually take with you: data export formats, ownership of any prompts or fine-tuned models, and how you'll be notified if subprocessors change.
A Practical Closing Test
Pick the three data-handling terms your organization cares most about — training use, regional processing, retention limits, whatever they are — and verify each one is covered by contract language, not questionnaire answers. Anything a vendor will not commit to in writing is a preference, not a control.
This guide originally appeared on agentpalisade.com. Agent Palisade helps small and mid-sized businesses put AI to work inside the tools they already use — practical automation, internal assistants, and AI security reviews. Book a free 30-minute call.
