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.
