AI vendor due diligence for agencies: 12 questions before upload

Most AI vendor reviews begin with a feature list: model quality, integrations, output formats, and price. For an agency, the more important question comes before any of those: what happens to a client’s information after someone presses Upload?

You do not need a 40-page procurement exercise for every experiment. You do need a repeatable set of questions before client data enters a new system. The answers become part of your risk decision, your client conversation, and your offboarding plan.

Start with the data, not the model

Classify what you plan to send. A public brief, an internal working note, a customer list, a contract, and a health-related record do not belong in the same risk bucket.

Write down the minimum data the workflow needs. If the model only needs a redacted paragraph, do not upload the whole folder. If it needs a spreadsheet, remove columns that have nothing to do with the task. Data minimisation is often the cheapest control available.

The ICO’s guidance on AI and data protection frames AI review as a risk-based exercise: assess the effect on people’s rights and apply proportionate technical and organisational measures. That is useful agency language even when the client is outside the UK.

The 12-question vendor checklist

1. What data is collected?

Ask what the service logs beyond the prompt and output: files, metadata, account identifiers, usage events, support transcripts, and diagnostic data.

2. Is customer content used to train a model?

Find the exact contractual answer for your plan. “We do not train on your data” is not the same as “we do not retain your data,” and neither answer covers every provider or feature.

3. How long is content retained?

Look for separate retention periods for prompts, files, outputs, backups, abuse monitoring, and deleted accounts. If the answer depends on a plan, record the plan.

4. Who can access it?

Ask about the provider’s staff, support contractors, subprocessors, workspace members, and your own administrators. Check whether access is logged and reviewed.

5. Where is it processed?

Record the regions and transfer mechanism that apply to your account. Do not infer a location from the vendor’s headquarters.

6. How does deletion work?

Test the actual path: delete a file, delete a workspace, close an account, and request support deletion. Note what remains in backups and how long it can persist.

7. How are subprocessors disclosed?

Find the current subprocessor list, notification process, and your right to object or terminate if a material processor changes.

8. What security controls are in place?

Look for encryption, access controls, key management, tenant isolation, vulnerability response, audit reports, and a clear incident process. A security badge is not a substitute for understanding the architecture.

9. What happens after an incident?

Ask when the provider will notify you, what information it will share, and whether it supports investigation. Your client may need a faster answer than the vendor’s public status page provides.

10. Can you export your work?

Check whether prompts, source files, generated outputs, comments, audit logs, and configuration can leave the system in usable formats. An exit path is part of due diligence.

11. Can you limit the tool’s permissions?

For connected or agentic features, ask what the system can read, write, send, or delete. Prefer narrow scopes, separate workspaces, and approvals for external actions. The OWASP GenAI Security Project’s 2026 guidance treats excessive agency and unbounded access as operational security problems, not just prompt problems.

12. What does the contract actually promise?

Read the data processing terms, acceptable use policy, privacy notice, security addendum, service levels, and plan-specific terms together. Save the version you reviewed. Product pages can change while a contract remains the thing your team relies on.

Turn answers into a go / no-go decision

Use three labels: approved, approved with limits, and not approved. An approved workflow may use ordinary client briefs. An approved-with-limits workflow may require redaction, a named reviewer, no personal data, or a dedicated workspace. A not-approved workflow is one where the vendor cannot answer basic questions or the residual risk is greater than the value.

Put the decision where the team can see it. A policy hidden in a shared drive will not help someone who is choosing a tool five minutes before a deadline.

Make client communication plain

Clients usually want four answers: what data was used, why AI was involved, who reviewed the result, and what was not automated. Explain those without claiming the system verified facts or replaced professional judgment.

This is not a one-time checklist. Review it when the vendor adds an agent, changes retention, introduces a new model provider, or moves the workflow from internal draft to client-facing output.