AI Vendor Due Diligence: Questions to Ask Before Connecting Business Data

Once an AI tool is connected to your business data, you're no longer just buying software. You're deciding who else gets to hold your data, and what happens to it. So before you approve it, find out what the vendor receives, what it does with it, who can see it, and how you get out.

Start With the Proposed Data Flow

Ask the project owner to describe which data will go into the service and where it comes from. Find out whether it includes personal, customer, employee, financial, contractual, or confidential information. Then ask what output comes back to your systems, which users and integrations will have access, and which business decision depends on the result.

Don't rely on the product category. A writing assistant pointed at your document repository is a different exposure than the same tool used on public marketing copy.

Ask How the Vendor Uses Your Data

Get clear answers to these:

• Is customer data used to train or improve shared models?
• Can that be turned off, and where is the setting enforced?
• Are prompts, files, outputs, and metadata treated differently?
• How long is each kind of data kept?
• Can your administrators delete data, and what stays in backups or logs?
• Does the vendor claim any rights to uploaded content or generated output?

Then check that the product settings, the contract, and the vendor's technical description all say the same thing. When they don't, trust the contract and ask questions.

Understand Storage and Access

Ask where data is processed and stored, and whether it's encrypted in transit and at rest. Ask which vendor staff can reach customer data and why, and how privileged access is approved and logged. Find out whether you can control user roles, single sign-on, and MFA, and whether audit or activity logs are available to your administrators.

Your own identity and offboarding process should reach the AI service too.

Look at Subcontractors and Model Providers

The company selling the app may depend on other hosting, model, analytics, or support providers. Ask for a current list of the relevant subprocessors, and learn what each does, what data it receives, how you'll be told about changes, and whether your agreement covers the whole chain.

What a vendor says about its own platform may not tell you how the underlying model provider handles your data.

Check Security and Incident Response

Ask for evidence that fits the risk and the size of the purchase. Then confirm how vulnerabilities are managed, how customer environments are kept apart, how integrations and API credentials are protected, how security events are detected, when and how you'd be told about an incident, and what support you'd get during an investigation.

Define your own side as well: who disables the integration, who preserves logs, who contacts the vendor, and who figures out which data was affected.

Test Controls and Output Boundaries

Before a broad rollout, run a controlled pilot with approved data. Verify that permissions keep data to the intended scope, connectors don't index more than you expected, and users can't retrieve content they shouldn't see. Check that outputs are reviewed before anyone acts on them, logs give you enough to investigate, and there's a workable manual fallback.

Plan the Exit Before You Go In

Ask how you'd export configurations, records, and the output you need. Confirm how accounts, connectors, credentials, and retained data are removed when the contract ends. Give someone inside the company ownership of the renewal review so the service doesn't roll on year after year with no current purpose.

You won't find a vendor with zero risk. What you can do is understand the data flow, match the controls to the business impact, and decide with a workable exit in hand.

Related Reading

This builds on our AI workplace security policy guide. The policy sets the expectations, and vendor due diligence checks whether a platform can meet them.