If I buy an AI tool, I still carry the risk. A U.S. vendor, a cloud host, a model API, support staff, and extra subprocessors can all touch my data - and each step can trigger GDPR, HIPAA, GLBA, or contract duties.
Here’s the short version: before I sign, I need clear answers on 7 points - where data goes, which laws apply, what the contract says, how data is protected, who else handles it, what proof the vendor can show, and how deletion and incident notice work across borders.
I’d treat these as pass-fail checks:
- Map every transfer point, not just the hosting region
- Get the DPA and SCCs in writing where needed
- Review the subprocessor list and change-notice terms
- Check logs, memories, backups, and support access - not just prompts
- Ask for proof like SOC 2 Type II, deletion terms, and residency details
- Pause the deal if the vendor cannot show a signed DPA, a subprocessor list, and a named region
A few points stand out. Hosting in the U.S. does not mean all processing stays in the U.S. A “no training” claim does not mean zero data retention. And deleting a chat does not always delete logs or memory stores.
If I were summarizing the article in one line, it would be this: vendor claims do not protect me - contract terms, transfer paths, and proof do.
Quick comparison
| Check | What I want to see | Red flag |
|---|---|---|
| Data location | Named storage and processing regions | “Global” or vague wording |
| Legal basis | DPA, SCCs, and transfer basis by data path | No written transfer method |
| Subprocessors | Current list with locations and roles | No list or website-only notice |
| Security | Clear terms on encryption, retention, and access | Broad promises only |
| Training and retention | Written “no training” plus retention limits | Marketing claim only |
| Deletion | Timelines for chats, logs, backups, memories | Silent on backups or logs |
| Incidents | Notice clock starts at first awareness | Notice only after confirmation |
That is the baseline I’d use to review any AI vendor before procurement moves forward.
AI Vendor Compliance Checklist: 7 Pass-Fail Questions Before You Sign
AI Compliance: How to Audit Vendors & Verify AI Outputs
sbb-itb-bec6a7e
7 compliance questions to ask every AI vendor
Use these 7 questions in RFPs, security reviews, and legal negotiations. Each one checks a specific weak spot in how AI vendors store, process, and move data.
The key point: check every transfer point, not just the vendor's main server location.
1. Where is our data stored, processed, and transferred?
Ask for a data-flow map. It should show what stays local, what leaves your environment, and where saved memories are kept.
Then map each transfer to its legal basis and the contract term that covers it.
2. Which laws and contract terms apply to these transfers?
This depends on the data type and the transfer path. For EU personal data, confirm there is a signed DPA, the right SCCs, and any transfer impact assessment that may be required. Ask the vendor to name the legal basis for each transfer path and the clause that applies to it.
3. What do the security and transfer clauses actually require?
Ask for terms that are specific and testable - not broad promises. The contract should cover security controls, transfer mechanism, subprocessor notice, deletion, and breach notice.
If subprocessors can change, require advance notice and a written right to object. If the vendor offers ZDR, ask exactly what it covers. Also ask whether any logs or saved memories are still kept.
4. How is data protected in transit, at rest, and during processing?
Ask whether the vendor supports on-device processing, ZDR setups, or temporary sessions or no-retention modes for sensitive work. If the vendor uses saved memories, ask whether users can view, edit, or delete them separately from chat history.
That split matters. A deleted chat does not always mean every related data store is also deleted.
5. Which subprocessors and third-party AI services handle our data?
Request a current subprocessor register. It should list each provider's name, role, processing location, and transfer mechanism, such as SCCs or an adequacy decision.
Also confirm:
- How the vendor tells you when subprocessors change
- Whether you have a right to object
- Whether an external AI API used for document or media inference touches personal data
If that outside AI service touches personal data, it may count as a subprocessor.
Then check that the vendor can document those third-party relationships in the proof file.
6. What proof should the vendor provide?
Ask for a current SOC 2 Type II report, signed DPA and SCCs where relevant, a current subprocessor register, and evidence for encryption, ZDR, or on-device processing claims.
You should also ask for records that show how the vendor deletes saved memories, including any logging lag or separate retention layer that still applies after deletion.
Use that same proof set to check retention and deletion commitments across regions.
7. How are retention, deletion, and incidents handled across borders?
Retention schedules should state the retention period for each data type the vendor handles - prompts, outputs, logs, and saved memories. Vague wording is not enough if you need to support a deletion request or meet a regulator's deadline.
Deletion duties should cover separate memory stores and logs, not just the main chat record. Ask for breach notice timing, escalation contacts, and country-specific notification duties.
How to evaluate vendor answers without slowing down procurement
Use a vendor comparison table. Put vendors across the top and clauses down the side. Then treat any blank cell as a no. That turns the seven questions into a simple pass/fail check for procurement.
Red flags that should pause procurement
Pause procurement if the vendor can't provide all 3 of these items:
- A signed DPA
- A current subprocessor list
- A named hosting region
There’s another hard stop too. If the vendor trains on customer data by default and does not offer an opt-out in the signed DPA, stop there.
Also, don’t lump "no training" and ZDR together. They are not the same promise. You need both, and both should appear in the signed DPA.
If a vendor gets through those basics, move to the evidence file.
What good evidence looks like in a vendor file
A good approval package does not need to be huge. It needs to be complete.
For cross-border transfers, keep these items in the file: the signed DPA, the right SCC module, the current subprocessor list, SOC 2 Type II, the transfer mechanism, the transfer impact assessment, and the data-residency map. If the vendor relies on the Data Privacy Framework, include DPF certification too. Use the same file again for renewals and periodic reviews.
The table below shows the difference between a passing vendor file and a failing one on the clauses that matter most:
| Clause | Acceptable Evidence | Red Flag |
|---|---|---|
| Data Residency | Named region and facility (e.g., AWS Frankfurt) | "Globally distributed" with no written commitment |
| Subprocessor Notice | 30-day advance notice with right to object [1][4] | Posted on website; no direct notice or objection window [1] |
| Data Deletion | Defined timeline (e.g., 30 days), covering backups and logs [1][2] | Silent on backups or "for legitimate business purposes" |
| Breach Notification | 24–72 hours from the vendor's first awareness [2][3] | "Without undue delay" or triggered only after confirmation [2][3] |
| AI Training | Explicit "No Training" clause in the signed DPA | Marketing claims only; ToS allows "service improvement" [2] |
| Audit Rights | SOC 2 Type II plus targeted follow-up questions | "SOC 2 available on request" with no additional rights [4] |
Pay close attention to the breach notification trigger. The clock should start when the vendor first becomes aware of the incident - not when the vendor confirms it. That one wording change can stop a vendor from using its internal review process to delay notice [4].
Using the 7 questions in AI tool selection and ongoing oversight
Add the questions to RFPs, security reviews, and contract checklists
AI for Businesses can help SMEs and scale-ups shortlist tools fast. But a directory listing helps you find options - it does not replace due diligence. The only terms that bind are the ones in the signed contract. Ask for the executable DPA during the shortlist stage, and treat refusal or delay as a red flag.
Put the seven questions straight into your RFP as pass/fail criteria. Ask for yes-or-no answers on hosting region, processing region, and transfer mechanism. And don't accept marketing language instead of a signed DPA. Use the same rubric across marketing and operations so AI adoption stays tied to risk control and measurable value.
SOC 2 Type II does not cover prompt logging or model-training boundaries [1][2]. Your security review should spell out those answers in writing, and the contract should match them.
That same checklist should stay in use after signature.
Review transfer and security evidence on a schedule
After launch, run the same checklist again whenever subprocessors, hosting regions, or transfer terms change. A vendor can pass the first review and still add risk later through subprocessor changes, hosting-region changes, or revised SCCs.
Track the events below and review the file each time one happens:
| Trigger Event | Review Action | Review Timing |
|---|---|---|
| New subprocessor | Verify location, jurisdiction, and ZDR/training terms. | 14-30 days prior notice |
| Hosting-region change | Confirm residency and sovereignty requirements are still met. | Immediate upon notice |
| Security incident | Exercise on-cause audit rights and request forensic detail. | 24-72 hours notification |
| Contract or DPA update | Check whether the transfer mechanism changed. | Immediate review of redlines |
| Annual milestone | Review the updated SOC 2 Type II report and run a written-questions audit. | Every 12 months |
Require SOC 2 Type II reports automatically when released, not only when you ask for them. Also ask whether data processing locations are fixed by account configuration or whether they can shift on their own due to load balancing. Silent re-platforming can add risk that certifications may not catch.
Conclusion: A practical baseline for AI vendor data-transfer compliance
Use these seven answers as the minimum bar before you sign with an AI vendor. Track where data is stored, processed, accessed, and logged. Make sure the contract names the correct transfer mechanism, and check the encryption language to see who controls the keys. Map each subprocessor and confirm those same duties flow down to them. Then put the file together: a signed DPA, a current SOC 2 Type II report, and a dated subprocessor list.
Skipping this work has a real cost. That's what makes the review defensible.
Document-backed diligence is not a delay. Contracts, transfer scope, and proof matter more than vendor assurances - and that's what makes AI adoption defensible and sustainable for U.S. businesses.
FAQs
What is a DPA, and why do I need one?
A Data Processing Agreement (DPA) is a binding contract between you, the data controller, and your AI vendor, the data processor. It says the vendor can handle personal data only under your instructions and must meet rules such as GDPR Article 28.
You need a DPA because it sets the rules that matter in practice. It puts security obligations in writing, controls subprocessor use, preserves audit rights, and turns compliance protections into contract terms - not just privacy policy language or marketing claims.
Does "no training" also mean no data retention?
No. No training and no data retention are 2 separate commitments. You need to check each one on its own.
A vendor might say it does not use your data to improve models and still keep that same data in logs, caches, or temporary buffers for abuse monitoring, security, or legal compliance. If you want your data deleted after processing, ask for Zero Data Retention in writing. Then confirm that it applies to both the vendor and any third-party model providers.
What should I do if a vendor won’t share its subprocessor list?
Treat it as a red flag.
A subprocessor list is a standard disclosure in a Data Processing Agreement. It is not a trade secret.
If a vendor won't share that list before you sign, that can point to weak oversight of its own data supply chain. In practice, that should be a disqualifier. Move on to another provider instead of taking on the risk.
