Data Privacy, Security and Compliance When Adopting AI Vendors

When you adopt an AI vendor, you are not buying software in the old sense. You are routing your data, sometimes your most sensitive data, through a system that may store it, process it in another country, use subcontractors you have never heard of, and in some configurations learn from it. The purchase decision is really a data-governance decision wearing a procurement badge. Treat it that way and most of the risk becomes manageable.

Here is the due-diligence process I take clients through, in the order that saves the most pain.

First question: what does the vendor do with your inputs?

Everything else is secondary to this. For any AI tool, you need clear, contractual answers to four sub-questions:

• Do they train their models on your inputs and outputs? For business use, the answer must be no, and it must be in the contract, not just a blog post. Most enterprise tiers in 2026 (enterprise ChatGPT, Claude for Work, Microsoft Copilot with commercial data protection, Google's enterprise Gemini tiers) contractually exclude your data from training by default. Free and consumer tiers often do not. The line between the two is exactly where a lot of accidental exposure happens.
• How long do they retain your data? Ask for the retention period and whether zero-retention or a shortened window is available. Some providers offer zero-data-retention arrangements for enterprise or API customers, meaning inputs are not stored after the request is served. For regulated data, this is worth pushing for.
• Who can see it? Understand human review. Many providers allow staff to review flagged content for safety or abuse monitoring. Know whether that applies to you and whether you can opt out.
• Where is it processed? Data residency matters for GDPR and for sector rules. Ask which regions and whether you can pin processing to a specific one.

If a vendor cannot answer these clearly in writing, that is your answer. Move on.

Get the paperwork that makes it enforceable

Verbal assurances and marketing pages are not controls. The documents that actually protect you:

• A Data Processing Agreement (DPA). If you handle personal data of EU, UK, or several US-state residents, this is not optional. The DPA defines the vendor as your processor, binds them to your instructions, and sets breach-notification duties. It should also list international transfer mechanisms (Standard Contractual Clauses or an adequacy basis) if data leaves your region.
• The subprocessor list. Your AI vendor almost certainly relies on others: a cloud host, sometimes a foundation-model provider behind their own product, monitoring services. Each is a place your data travels. Get the current list, and get contractual notice before they add new ones so you are not surprised by a fourth party you never vetted.
• A security attestation. A SOC 2 Type II report or ISO 27001 certification tells you an independent auditor checked their controls over time, not just on paper. For AI specifically, ISO/IEC 42001, the AI management-system standard, is becoming a useful signal in 2026 that a vendor has a real AI governance program rather than good intentions.

Read the SOC 2 report rather than just confirming it exists. The exceptions section, where the auditor notes where controls fell short, tells you more than the certificate on the marketing page.

Map your regulatory obligations to the specific use

Compliance is not a property of the tool; it is a property of what you do with it. The same chatbot is low-risk for drafting internal memos and high-risk for screening job applicants. Walk through the regimes that touch you:

• GDPR and equivalents: if personal data is involved, you need a lawful basis, a DPA, and for higher-risk processing, a Data Protection Impact Assessment. Automated decisions with legal or similarly significant effects on people carry extra obligations, including a right to human review.
• The EU AI Act: now in phased application. Obligations scale with risk. If your use falls into a high-risk category (certain uses in hiring, credit, education, essential services), you inherit documentation, human-oversight, and transparency duties, and you need to know what your vendor supplies toward them. Even outside high-risk, transparency rules apply to things like AI-generated content and chatbots.
• Sector rules: HIPAA for US health data (you need a Business Associate Agreement, and not every AI vendor will sign one), GLBA for financial data, PCI DSS for payment data. If your sector has a rule, the AI tool has to fit inside it, not the other way around.

The practical move is to run this per use case, not per vendor. Approve the tool for the uses that clear the bar and explicitly exclude the ones that do not.

Control the integration, not just the vendor

The vendor's security is only half the picture. The other half is how you connect them. Watch these:

• Access scope. When an AI tool plugs into your email, files, or CRM through connectors or an integration layer, it can often reach far more data than the immediate task needs. Scope permissions to the minimum, and review what each integration can actually touch.
• Authentication. Require single sign-on and enforce your own multi-factor and offboarding through it, so a departing employee loses AI access the moment they lose everything else.
• Logging. You want a record of who used what and, ideally, what data flowed. If an incident happens, the audit trail is what lets you scope it instead of guessing.
• Prompt and output handling. Where feasible, filter sensitive data before it reaches the tool and log outputs used in consequential decisions.

A due-diligence checklist you can actually use

Before signing any AI vendor, get yes-or-no clarity on:

1. Are our inputs excluded from model training, in the contract?
2. What is the data-retention period, and is zero or short retention available?
3. Is there a signed DPA with valid transfer mechanisms if data leaves our region?
4. Can we see the current subprocessor list and get notice of changes?
5. Is there a SOC 2 Type II or ISO 27001 report, and have we read the exceptions?
6. Where is data processed, and can we pin residency?
7. Will they sign the sector agreement we need (BAA, etc.) if applicable?
8. Does the integration follow least-privilege access, SSO, and logging?
9. What is their breach-notification commitment and timeline?
10. Have we run our regulatory analysis per use case, not just per tool?

None of this requires you to become a lawyer or a security engineer, though you should loop both in for anything touching regulated data. It requires treating an AI purchase as what it is: a decision to let another company handle information you are accountable for. The vendors worth buying from expect these questions and answer them cleanly. The ones that get evasive when you ask are telling you something useful, and it is better to hear it before the contract than after the breach.