AI vendor due diligence: 7 checks before customer data moves

The AI demo took 18 minutes. The vendor now wants permission to import your customer records.

The assistant will read the CRM, draft replies and update deal stages. It looks useful. The salesperson points to a security badge, says the platform is GDPR compliant and opens the connection screen.

This is where procurement actually starts.

AI vendor due diligence is the evidence check you complete before a tool receives customer data, system credentials or authority to act. For an owner-operated business, it does not need a committee or a 90-page questionnaire. It needs a risk tier, seven checks and a written decision: approve, restrict, pause or reject.

The import button is a trust decision wearing the clothes of a product setting.

Why the usual vendor check is too shallow

A normal software review asks whether the supplier is financially credible, secure and contractually accountable. AI adds questions that a generic security page may not answer:

• Can prompts, files or outputs be used to train or evaluate a model?
• Does the tool create embeddings, traces or support copies that live somewhere else?
• Can the model or its behaviour change without notice?
• Can it only suggest an action, or can it send, edit, delete or pay?
• What happens when the output is confidently wrong?

In one current procurement discussion, the inherited process was described as “fill out security questionnaire, get SOC 2, done.” The people in the thread were already finding the gap: controls at company level do not prove that a particular model is suitable, stable or correctly bounded for your use. (Reddit)

A certification can be useful evidence. Check its scope three ways: does it cover the vendor organisation, the exact service you will use and the configuration you intend to run? A badge alone cannot answer all three.

The urgency is real, but the numbers need context. Cisco's 2026 privacy benchmark surveyed 5,200 privacy-responsible technology and security professionals across 12 markets. Ninety per cent said AI had driven an expansion of their privacy programme, while only 12% described their AI governance body as mature. This is vendor-sponsored global research, not a measure of European small businesses, but the direction is worth noticing: spending can move faster than operating discipline. (Cisco)

Tier the use before you review the vendor

Do not send every supplier the same questionnaire. First decide what the tool will touch and what a mistake could do.

The EU AI Act also takes a use-based, risk-based approach. As of August 2026, it is generally applicable and certain transparency duties apply, while many obligations for high-risk systems have later application dates in 2027 or 2028. Employment, credit and access to essential services are among the use cases that can fall into the high-risk category. Classify the intended use before assuming the vendor's general statement covers it. (European Commission)

This is an operational checklist, not legal advice. Personal data, employee records, health, credit or other high-impact uses deserve advice from a privacy, security or legal specialist who understands the jurisdiction and facts.

The seven AI vendor due diligence checks

Each check has three parts: the question, acceptable evidence and a red flag. A confident answer is not the same thing as proof.

1. Map every place the data goes

Start with your data, not the vendor's architecture diagram.

List the fields and files the tool receives. Then trace prompts, outputs, logs, embeddings, evaluation traces, backups, support exports and connected-system data. Note who can see each copy and where it is stored or processed.

The UK National Cyber Security Centre recommends recording supplier information flows, subcontractors, assessment dates and assurance evidence so supply-chain risk can be understood and revisited. It also recommends contract terms for incident notification, audit rights, necessary data transfer, segregation and supplier access. (NCSC)

Acceptable evidence: a product-specific data-flow diagram or written schedule that includes every storage and processing layer you will use.

Red flag: “Your data stays in Europe” with no distinction between storage, model processing, support access and backups.

If the path cannot be mapped, test with synthetic data. Do not solve uncertainty by uploading real records to see what happens.

2. Separate storage, training and purpose

Ask three different questions:

1. Is our data stored, and for how long?
2. Is any input, output or trace used to train, fine-tune, evaluate or improve a model or product?
3. For which purposes may the vendor or its model provider process it?

A “no training” setting may not cover human review, abuse monitoring, evaluation or a third-party model provider. It may also differ between consumer and business accounts.

Acceptable evidence: product terms, a data-processing schedule and administrator settings that agree on training, evaluation and secondary use.

Red flag: the salesperson says no, the privacy policy says “improve our services” and the contract never resolves the difference.

Under GDPR Article 28, a controller should use “only processors providing sufficient guarantees” and put the processing duties into a binding contract. That does not make a generic “GDPR compliant” statement a substitute for understanding your own purpose, data and configuration. (EUR-Lex)

3. Prove retention and deletion

“We delete your data” is incomplete. Ask when, from which systems and what happens to logs, backups, embeddings and support copies.

Set a retention period that fits the use. Confirm whether an administrator can delete an individual record, an account or the full workspace. At contract end, decide whether data is returned, deleted or retained under a stated legal requirement.

Acceptable evidence: a retention schedule, deletion procedure, administrator controls and a contractual deletion or return commitment.

Red flag: deletion applies to the visible chat history but not to derived data, logs or connected stores.

The UK ICO's current AI audit framework calls for detailed processor contracts and clauses requiring personal information to be deleted or returned at the end of the contract unless the law requires storage. The page is UK guidance and is marked as under review, but its evidence discipline is practical beyond a checkbox. (ICO)

4. Expose subprocessors, locations and transfers

The vendor on the invoice may not be the only company touching the data. Model providers, cloud hosts, observability tools, transcription services and support platforms can sit underneath it.

Request the current subprocessor list. Ask what each one does, where it processes data, how changes are announced and whether you can object. If personal data leaves the EEA or another protected jurisdiction, ask which transfer mechanism applies and have the answer reviewed where necessary.

Acceptable evidence: a dated subprocessor register linked to the service, change-notification terms and a clear transfer schedule.

Red flag: the vendor names its cloud host but will not identify the model or logging providers behind the feature.

5. Test access, security and incident controls

Encryption is a starting point. The practical questions are who can get in, what they can do and whether you can reconstruct an incident.

Check multi-factor authentication, role-based permissions, tenant separation, support access, API-key handling and audit logs. For an AI agent, list every tool it can call. Mark calls as read-only or changing data. Ask for a replay of one allowed action, one blocked action and one action that required human approval.

OWASP identifies sensitive-information disclosure as a material LLM application risk and recommends sanitisation, least-privilege access, restricted data sources and transparent retention, use and deletion policies. It also warns that prompt-only restrictions can be bypassed. (OWASP)

Acceptable evidence: access-control documentation, audit-log samples, recent relevant testing, incident contacts and a notification commitment.

Red flag: the agent can send emails, change records or trigger payments using a broad shared credential, with no approval trail or kill switch.

6. Make the contract match the product

The DPA, order form, security schedule and product settings should describe the same service.

Record the processing purpose, data categories, instructions, confidentiality, security measures, subprocessor rules, assistance with individual rights, incident duties, audit evidence, retention and end-of-contract handling. Add notification or review rights for material changes to models, terms or data handling where the risk justifies it.

Acceptable evidence: signed terms that name the service and resolve gaps found in the review.

Red flag: an enterprise security page makes a promise that the order form excludes or the administrator cannot configure.

A DPA allocates obligations. It does not prove the product behaves as described. Test important controls before approval and keep screenshots or exports with the decision record.

7. Bound the use, the human decision and the exit

Vendor due diligence cannot make a poor use case safe. Decide what the tool is allowed to do, who checks its output and which event stops it.

For customer-facing or consequential work, define the acceptable error, the human review point and the record you keep. Decide what happens when the model changes, quality falls, an integration fails or the vendor changes a subprocessor. Then test the exit: export the data, revoke credentials, delete the workspace and run the process manually if needed.

Acceptable evidence: a named business owner, an approved-use statement, permission limits, review samples, stop conditions and an exit test.

Red flag: “human in the loop” means somebody could notice a bad action after it has already reached the customer.

Turn the review into a one-page decision

Do not end with a folder of documents and no answer. Record:

• the tool, use case and owner;
• the data and system access requested;
• the risk tier;
• evidence received for each of the seven checks;
• unresolved gaps and compensating restrictions;
• the decision: approve, approve with restrictions, pause for evidence or reject;
• the next review date and events that reopen the decision.

Restricted approval is useful. A tool may be acceptable for public-copy drafting but not CRM access. It may work with redacted tickets but not full call recordings. It may suggest replies but not send them.

That is not indecision. It is giving the useful part permission without giving the unknown part customer data.

A shared operating record in SharpOS can keep the evidence, access decision, owner and next review together. The point is not more administration. It is being able to answer one calm question later: why did we trust this tool with this data?

Five reasons to stop before connecting

Pause the purchase or pilot when:

1. the vendor cannot map where your data goes;
2. training, evaluation or secondary use remains ambiguous;
3. deletion excludes important stores or cannot be tested;
4. tool permissions exceed the approved job; or
5. the contract and product settings contradict each other.

No supplier will remove every risk. The decision is whether the remaining risk is visible, owned and proportionate to the value of the use.

Small companies do not need enterprise theatre. They need to connect fewer things by accident.

Before adding another AI tool to your business systems, decide what it may see, what it may change and what proof earns that access. If the workflow cannot be explained on one page, it is not ready for production data.

If you want AI automation that removes work while keeping the data path, permissions and human decisions visible, talk to SharpHaw. We can help you design the operating loop before the import button becomes somebody else's problem.