Image: Unsplash, used under the Unsplash License.
TL;DR: Thirty questions in five sections, each with a pass criterion and a note on how vendors tend to answer. Run Sections 2 and 3 for every AI tool, add Sections 1 and 4 for business data, and all five for high-risk use. Three answers block a tool outright: your data trains the model with no opt-out, no DPA, and no BAA for health data.
Before signing any AI tool contract, run it through this checklist. Questions are grouped by risk area. Each has a pass criterion and a note on how vendors tend to respond. For a medium-risk tool, budget 45-90 minutes per vendor. The pass criteria are our defaults, not legal requirements, except where a law is cited.
How to use this checklist:
- Low-risk tools (no personal data, every output reviewed before use): Sections 2 and 3. These cover whether your content trains the model and what the contract says.
- Medium-risk tools (business data, workflow integration): Sections 1 to 4.
- High-risk tools (personal data at scale, consequential decisions, regulated industries): all five sections, plus legal review of Sections 3 and 4.
Image: aipolicydesk.com chart; source: this checklist's tiers and blockers.
For a faster first pass, use the 30-minute version, which runs five gate questions against a vendor's public terms.
To fill it in offline, download the checklist as an Excel workbook (.xlsx), which counts your fails and applies the scoring bands for you, or as a Word document (.docx).
Section 1 of 5: Security Posture
| # | Question | Pass Criterion | Vendor Deflection Risk |
|---|---|---|---|
| 1 | Does the vendor have a SOC 2 Type II report? | Yes, covering a period that ended within the last 12 months | High, "in progress" can last a long time |
| 2 | Is the SOC 2 report available for customer review (under NDA)? | Yes, the full report, not only a summary or bridge letter | Medium, some share only summaries |
| 3 | What was the last penetration test date? | Within 12 months, by a named third party | High, many vendors share a summary at most |
| 4 | Is there a vulnerability disclosure policy? | Yes, at a public URL | Low |
| 5 | How is customer data encrypted at rest and in transit? | AES-256 at rest, TLS 1.2 or later in transit | Low |
| 6 | What is the contractual deadline for telling you about a breach that affects your data? | A fixed outer limit in the DPA, short enough to leave room inside your own 72 hours | Medium, many DPAs say only "without undue delay" |
Why Q6 is worded this way: under GDPR, the 72 hours belong to you. The controller must notify the supervisory authority "not later than 72 hours after having become aware of it," while "the processor shall notify the controller without undue delay after becoming aware of a personal data breach." A vendor that commits only to "without undue delay" is meeting the law, but you cannot plan around it. Anthropic's DPA, for comparison, says "without undue delay, but in any event within 48 hours." OpenAI's says "without undue delay."
On Q1: a SOC 2 Type I report covers whether controls are designed properly; a Type II report covers whether they operated effectively over a period. If a vendor cannot produce a Type II report within 2 weeks of request, treat it as a finding. Do not accept Type I alone for a medium or high-risk tool.
Section 2 of 5: Data Handling and AI Training
The AI-specific questions sit here: whether your content trains the vendor's models, how long prompts are kept, and what happens to them when you leave.
| # | Question | Pass Criterion | Vendor Deflection Risk |
|---|---|---|---|
| 7 | Is customer data used to train or fine-tune the vendor's models on the plan you will buy? | No, in the published terms or DPA | Depends on tier: business and API terms often say no, consumer plans often differ |
| 8 | If training is on by default, is there an opt-out? | Yes, confirmed in the contract or DPA | High, opt-out may need a higher tier or a request |
| 9 | What is the retention period for inputs and outputs? | Stated in writing, 30 days or less for prompts | Medium, and it can differ by model |
| 10 | Who inside the vendor can access customer data? | Named roles and a controlled access process | Medium |
| 11 | Is your data separated from other customers' data? | Yes, logical or physical separation described | Low for cloud services |
| 12 | What happens to your data at termination? | Deleted within 30 days, with written confirmation | Medium, some DPAs delete only on your instruction |
| 13 | Does the vendor share customer data with third parties for anything other than service delivery? | No, confirmed in the DPA | Low if a DPA exists |
The training question depends on the tier, not the brand. OpenAI says that "as of March 1, 2023, data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)." Anthropic says that "by default, we will not use your inputs or outputs from our commercial products" for training. Anthropic's consumer plans work differently: in 2025 it began "giving users the choice to allow their data to be used to improve Claude," a change that did not cover "services under our Commercial Terms, including Claude for Work." So the question to ask is not "do you train on our data?" but "on the plan our staff will actually use, is our data used for training, and where is that written?"
On Q12, two large vendors answer differently. Anthropic's DPA says that "within thirty (30) days of the date of termination or expiration of the Agreement" it will return data on request and delete it, with stated exceptions. OpenAI's DPA says it will "at Customer's instruction, return or delete Customer Data." With the second kind of term, send the deletion instruction in writing when the contract ends.
Screenshot: Data Processing Addendum, sections G and H, Anthropic.
Red flags for this section:
- "We anonymize your data before using it for training." Anonymization varies in quality and does not answer whether your content trains the model.
- "Our models are trained on public data only." That describes the base model, not what happens to your inputs.
- "You can delete your data any time." A delete button is not a contractual retention limit.
Image: Unsplash, used under the Unsplash License.
Section 3 of 5: Legal and Contract Terms
| # | Question | Pass Criterion | Vendor Deflection Risk |
|---|---|---|---|
| 14 | Is a Data Processing Agreement (DPA) available? | Yes, published or available to sign | Low for established vendors, higher for startups |
| 15 | Does the DPA name the vendor as a processor (not a controller)? | Yes, stated explicitly | Medium |
| 16 | What is the liability position for AI-generated errors? | Stated, with a cap you understand, rather than silence | High, output liability is usually limited or excluded |
| 17 | Is there a subprocessor list and a change notice? | Yes, with notice of changes and a right to object | Medium |
| 18 | Who owns outputs, and can you use them commercially? | Customer ownership or a clear license stated | Low for most AI tools |
| 19 | Are there restrictions on industries or use cases? | Restrictions documented in the usage policy | Low, but unread policies catch teams out |
| 20 | What does the exit clause cover? | Data export and deletion within 30-60 days | Medium |
On Q15: GDPR Article 28(3) requires that "processing by a processor shall be governed by a contract." OpenAI's DPA states that "OpenAI acts as a Data Processor on the Customer's behalf." That is the sentence you are looking for.
On Q17: under Article 28(2), a processor using a general authorization must tell you about changes, "giving the controller the opportunity to object to such changes." The objection window is a contract term. OpenAI's DPA gives 30 days after notice; Anthropic's gives "fifteen (15) days."
On Q16: expect liability for model outputs to be limited or excluded. That is the baseline, not a red flag. What matters is that you have recorded the exclusion internally and have human review for AI outputs that affect customers, employees or compliance decisions. Without vendor liability, the responsibility sits with your team.
Section 4 of 5: Compliance Documentation
| # | Question | Pass Criterion | Vendor Deflection Risk |
|---|---|---|---|
| 21 | If EU personal data is processed, does the DPA meet GDPR Article 28 and cover transfers? | Yes, Article 28 terms plus SCCs or an adequacy basis where needed | Low for established vendors |
| 22 | If California residents' data is processed, does the contract meet the CCPA service provider rules? | Yes, a written contract with the terms in the CCPA regulations | Medium |
| 23 | If PHI is processed, is a HIPAA Business Associate Agreement (BAA) available for the features you will use? | Yes, signed before any PHI is entered | Medium, coverage often excludes some features |
| 24 | Will the vendor give you what you need for your own Data Protection Impact Assessment (DPIA)? | Yes, documentation on request | Medium |
| 25 | Has the vendor assessed whether its system falls under the EU AI Act, and in which risk category? | Classification documented, with instructions for use for high-risk systems | High |
On Q22: a HIPAA BAA is not the CCPA document. The CCPA regulations list what "the contract required by the CCPA for service providers and contractors shall" contain, starting with a ban on "selling or sharing personal information" and a stated business purpose.
On Q24: under GDPR the DPIA is your job as controller, but the processor must assist "the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36," which include the DPIA.
On Q25: if you deploy a high-risk system (for example in hiring, credit or education), Article 26(1) of the AI Act requires you to use it "in accordance with the instructions for use," so you need those instructions from the vendor. After the Digital Omnibus, the Annex III high-risk obligations apply from 2 December 2027.
HIPAA note for Q23: check the BAA's scope, not only its existence. OpenAI says that "to use the OpenAI API with protected health information (PHI), your organization must first enter into a Business Associate Agreement (BAA) with OpenAI," that "an enterprise agreement is not required to sign a BAA for API services," and that "we do not offer a BAA for ChatGPT Business." Anthropic's BAA covers "our first-party API, Claude in Microsoft Foundry, or Enterprise plans," excludes "Claude Console, Cowork in the cloud, or features currently in beta," and notes that "not all API features are covered." A team on the wrong plan, or using an excluded feature, has no BAA for that use.
Section 5 of 5: Operational Reliability
| # | Question | Pass Criterion | Vendor Deflection Risk |
|---|---|---|---|
| 26 | What is the vendor's uptime SLA? | 99.9% or better, with a remedy for misses | Low |
| 27 | Can you pin a model version, and are changes announced? | Pinned model IDs available and a public changelog | Medium |
| 28 | What is the rate limit, and what happens when you hit it? | Documented limit with predictable behavior | Low |
| 29 | What is the minimum notice before a model is retired? | A published notice period that covers your migration time | Medium, periods differ widely |
| 30 | Does the vendor have a disaster recovery plan? | Yes, RTO and RPO documented | Medium |
Model versioning is the risk teams notice last. If your integration calls an alias rather than a fixed model ID, the model behind it can change. Anthropic's documentation says "each Claude model ID identifies a pinned version of the model," while older aliases "point to the most recent dated snapshot for that minor version." For production workflows, pin a specific model ID and log which one produced each output.
On Q29, published notice periods differ. OpenAI gives "at least 6 months" for generally available models, shorter for specialized variants and much shorter for preview models. On October 1, 2026 it announced that GPT-5.1 and two other models "will be removed from the API on April 1, 2027, with six months' notice." Anthropic gives "at least 60 days' notice before model retirement for publicly released models." If your migration takes a quarter, 60 days is a planning problem worth writing down.
Screenshot: Deprecations, OpenAI API documentation.
A checklist tells you what a vendor will and won't do with your data. It doesn't tell you whether, a year later, you can reconstruct which document a number came from, which model version produced it, and who approved it before it reached a committee or a regulator. For buyers in regulated workflows that reconstruction is most of the control environment. Domain platforms built around that requirement, Hypha in commercial real estate lending is one example, cite every extracted value to its source and log every approval to a named person, so the file reads as a record rather than a reconstruction. If a vendor's answers to Sections 2 and 3 don't support that, the gap moves onto the buyer's balance sheet.
Scoring and Decision Framework
After completing the sections for the tool's risk tier, count the fails:
| Score | Recommendation |
|---|---|
| 0 fail answers | Proceed, sign the DPA and add the tool to the approved list |
| 1-2 fail answers | Negotiate, most fails can be fixed in contract language |
| 3-4 fail answers | Escalate, legal review before proceeding |
| 5 or more fail answers | Reject, or require major remediation before any use |
Three questions are automatic blockers, whatever the total:
- Q7: your data is used for training and there is no opt-out. Reject for any sensitive data.
- Q14: no DPA, and the vendor will not provide one. Reject for any personal data.
- Q23: no BAA covering the features you will use. Reject for any PHI.
Vendor Assessment Record
For each vendor assessment, record:
| Field | Entry |
|---|---|
| Vendor name | |
| Tool / product and plan assessed | |
| Date of assessment | |
| Assessor | |
| Risk tier (Low / Medium / High) | |
| Sections completed | |
| Fail count | |
| DPA signed (Y/N/Pending) | |
| Training exclusion confirmed, with URL (Y/N/N/A) | |
| Breach notice limit and deletion window from the DPA | |
| Model IDs in use and deprecation notice period | |
| Decision | Approved / Rejected / Conditional |
| Conditions / remediation required | |
| Next review date |
Keep one record per vendor per assessment cycle. Reassess high-risk vendors quarterly, and medium-risk vendors annually or when the vendor changes its terms or data practices. Then add the vendor to your AI tool register with the DPA status and next review date filled in.
Our take
When I checked the old version of this checklist against vendor documents, the errors all pointed the same way: they assumed vendors were vaguer than they are. Large vendors now publish the training default, the breach notice wording, the subprocessor objection window, the BAA scope and the deprecation notice period. The answers differ in ways that matter, such as 48 hours against "without undue delay", or 60 days against 6 months before a model is retired. My advice is to spend your review time reading those documents for the plan you will actually buy, and to record the URL and date next to every answer.
How we checked this: we read GDPR Articles 28 and 33 and AI Act Article 26 on EUR-Lex, the Digital Omnibus dates, the CCPA service provider contract rules (11 CCR 7051), OpenAI's DPA, data controls guide, BAA help article and deprecations page, and Anthropic's DPA, privacy center articles, BAA article, model ID documentation and deprecation policy. We took the two screenshots and built the tier chart. Pass criteria, tiers and score bands are our defaults. Last reviewed: October 13, 2026.
Related Reading
- AI vendor due diligence in 30 minutes, the five-question gate run on public vendor terms
- AI governance for small teams, complete guide, where vendor review fits in a full program
- Privacy-first AI APIs that don't train on your data, for Q7 and Q8
- AI vendor contract redline template, clauses to add for the gaps this checklist finds
- AI vendor DPA tracker, DPA status for common AI vendors
- Enterprise AI privacy pages: direct links to OpenAI, Anthropic, Google, Microsoft documentation
- AI vendor evaluation prompts
- Agentic AI vendor contract clauses
- How to add AI tools to your SOC 2 program
- SOC 2 AI controls audit
- AI governance for healthcare startups under HIPAA
- AI vendor security incident response playbook
- LiteLLM supply chain breach: vendor audit checklist
- Anthropic's Fable backlash and vendor transparency
- Anthropic export ban: what the Fable shutdown means for your vendor policy
- White House frontier AI model access gating
- Meta skipped the EU AI Code: what Llama deployers must do
- DeepSeek and Chinese AI models: GDPR data transfer risk
- Flock Safety: when vendor defaults share your data
- MAS AI risk guidelines for vendors selling to Singapore financial institutions
- OpenAI agent incident tracker
- AI insurance exclusion checklist
- Character.AI Bankruptcy: What Happens to Chats and User Data
References
- General Data Protection Regulation, Articles 28 and 33
- EU AI Act, Article 26, and the Digital Omnibus on AI
- California Code of Regulations, 11 CCR 7051, contract requirements for service providers and contractors
- Anthropic, Data Processing Addendum, Business Associate Agreements for commercial customers, Model deprecations and Model IDs and versions
- OpenAI, Data Processing Addendum, Data controls, BAA for the API and Deprecations
- Imperva, SOC 2 compliance
