This article accompanies Hour 6: Privacy, AI and Cloud Services in our full-day CPD programme on XpertAcademy. Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.

Procurement sends privacy a completed AI vendor questionnaire. Every answer is positive. The vendor encrypts data, supports deletion, uses appropriate access controls, has policies, has incident procedures, has subprocessors under contract and says customer data is not used to train public models.

On paper, it looks clean. In practice, the privacy team still does not know what data the tool will receive, whether prompts and outputs are retained, whether support teams can view customer content, what "service improvement" includes, which entities process the data, where remote access happens, whether logs contain personal data, or who inside the business will own the decision after go-live.

That is the practical problem with many AI vendor questionnaires. They create the appearance of diligence before the organisation has enough evidence to make a controlled decision.

This article is general guidance, not legal advice on a specific vendor, product or deployment. The right review will depend on the data, the AI functionality, affected individuals, sector risk, geography, contractual leverage and operational reliance involved.

A good AI vendor questionnaire does not ask the vendor to sound safe. It asks for evidence that lets the organisation decide whether the use case is controlled enough to approve.

Why ordinary questionnaires struggle with AI vendors

Traditional vendor questionnaires are often built around stable outsourced services. They ask whether the supplier has policies, security controls, subprocessors, breach procedures, access controls, deletion arrangements and transfer mechanisms. Those questions still matter, but cloud AI tools add facts that ordinary templates often miss.

An AI service may process prompts, uploaded files, outputs, embeddings, feedback, telemetry, safety events, product analytics and support logs. Some of that material may contain personal data even when the business thinks it is only testing a tool. The vendor may use different model providers, hosting providers, analytics tools, content filters and support systems. The product may change quickly through new AI features, new model versions, new retention settings or new integrations.

The DPC's cloud guidance is a useful reminder that a controller remains responsible for control, security, transparency, data location and written contractual arrangements when engaging cloud providers. The same governance point applies with extra force to AI-enabled cloud vendors: the organisation needs enough evidence to remain in control of the personal data and the decision to use the tool.

For DPOs and privacy teams, this means the questionnaire should not be the whole review. It should be the route into an evidence pack.

Move from assurance to evidence

Assurance is a statement. Evidence is something the organisation can test.

"We delete data on request" is assurance. The relevant contract clause, retention schedule, deletion workflow, backup deletion period and customer-facing deletion confirmation route are evidence.

"We do not train on your data" is assurance. The AI product terms, data processing agreement, model provider terms, admin setting screenshot, support article, account configuration record and change-notice commitment are evidence.

"We use approved subprocessors" is assurance. A dated subprocessor list, the basis for authorisation, update process, objection route, processing locations and onward transfer controls are evidence.

The aim is not to bury suppliers under paperwork. It is to make the review proportionate and usable. Low-risk AI use cases may need a lighter evidence set. A tool connected to customer records, employee files, complaint histories, legal documents, health information, financial data, children's data or large repositories should not be approved from a tick-box return alone.

The legal and governance issue in plain language

The GDPR due diligence position is not "ask a supplier some questions and keep the spreadsheet". Controllers must use processors that provide sufficient guarantees for the processing, and controller/processor roles need to be understood before contract terms can do their job. The EDPB controller and processor guidelines remain important because AI services often blur language around "customer", "workspace", "model provider", "platform" and "service improvement".

Cloud AI also raises transfer and subprocessor questions. A service can have a regional hosting setting while still involving remote support, telemetry, security monitoring, abuse detection or subprocessors outside the selected region. EDPB transfer recommendations point towards an assessment of the transfer context and supplementary measures where needed, not a generic assumption that standard terms solve every operational risk.

The ICO AI and data protection risk toolkit is useful because it frames AI governance around risks to individuals' rights and freedoms. That matters in vendor review. Privacy teams should ask how the vendor's system affects people in this specific deployment, not only whether the vendor has a general AI policy.

Worked example: rebuilding the questionnaire around evidence

Imagine a business wants to buy an AI assistant for customer success teams. It will summarise support tickets, suggest draft responses and search the knowledge base. Procurement has a completed vendor questionnaire. Security has a SOC 2 report under NDA. The business wants approval within two weeks.

The facts the privacy team starts with are limited but useful. The tool is cloud hosted. It will connect to the ticketing platform and the knowledge base. Users will be support agents and team leads. It may process customer names, contact details, complaint content, order history, account notes and attachments. The vendor says data is not used to train public models.

What is still unknown is more important than what is known. The privacy team does not yet know whether prompts, outputs, retrieved knowledge snippets and feedback are retained separately from the ticketing system. It does not know whether the vendor uses a third-party model provider. It does not know where support access takes place, whether logs include ticket text, whether sensitive attachments are indexed, whether the AI can retrieve restricted knowledge base pages, or whether account settings are needed to disable training or product improvement use.

The decision question is not "has the vendor answered yes to the questionnaire?" It is:

Can the organisation approve this AI assistant for customer support data with clear limits on data use, access, retention, transfers, evidence, sign-off and review?

The privacy team rewrites the review around documents, controls, examples and owners. It asks for the AI product terms, data processing agreement, subprocessor list, data-flow description, model provider position, retention schedule, log description, regional hosting documentation, support access controls, transfer mechanism, security assurance report, incident procedure, deletion process and change-notice mechanism. It asks the business owner to confirm the intended use cases, prohibited uses, user group, data categories and go-live conditions.

The checks are practical. Privacy compares the contract with the product documentation. Security checks whether the SOC 2 scope covers the AI service, not only the vendor's wider platform. The business tests whether restricted knowledge base articles are retrievable by users without source permission. Legal checks whether the vendor's service improvement wording covers prompts, outputs, telemetry, support content or feedback. Procurement records whether any unresolved point is a contractual issue, a configuration issue or a risk acceptance issue.

The evidence created afterwards includes an AI vendor review note, a short decision record, the approved evidence pack, a DPIA screening note or DPIA update, a transfer assessment note if needed, the agreed configuration screenshots, an action log and a review date. The approval is conditional: customer support use is allowed, but HR, legal, health, payment card and free-text bulk uploads are excluded unless separately reviewed.

Escalation would be triggered if the vendor cannot evidence model training restrictions, refuses to identify relevant subprocessors, cannot explain log retention, allows unrestricted support access, introduces a new model provider, expands processing locations, changes product terms, connects to additional repositories or proposes use on a more sensitive data set.

What the questionnaire should ask

A useful AI vendor questionnaire should still cover standard vendor points, but it should ask them in a way that produces usable evidence.

For the use case, ask the business owner what the tool will do, who will use it, whose data it will process, what outputs will influence, what human review exists and what uses are prohibited. This is not a supplier question. It is an internal governance question.

For data categories, ask the vendor and the business to identify prompts, uploaded files, source records, outputs, feedback, metadata, telemetry, logs, embeddings and support content. Ask whether each category may contain personal data, special category data, confidential data or credentials. Ask what is retained and for how long.

For role mapping, ask whether the vendor acts as processor, controller or joint controller for each processing purpose. A vendor may be a processor for the hosted AI service but a controller for account administration, security analytics or some product improvement activity. The evidence pack should not flatten those roles into one label.

For AI data use, ask whether customer data, prompts, outputs, files, feedback, embeddings or logs are used for model training, fine-tuning, model evaluation, product improvement, abuse monitoring, benchmarking or support. If there is an opt-out, record whether it is default, configurable, product-wide and applicable to third-party model providers.

For security and access, ask for evidence of tenant separation, encryption, identity controls, privileged access management, support access approval, audit logging, vulnerability management, secure development and incident response. Certifications can help, but the scope and date matter.

For transfers, ask where data is stored, where it is accessed, where logs and backups sit, where support teams operate and where subprocessors process data. Record the transfer tool, supplementary measures and onward-transfer position where relevant.

For rights, retention and deletion, ask how the vendor supports access, correction, deletion, restriction, objection and export requests in practice. Ask what happens to logs, backups, derived data, embeddings, cached content and support tickets.

For change control, ask how customers are notified of new AI features, new model providers, new subprocessors, changed retention, changed training terms, changed support locations, changed security measures or new integrations.

Evidence that should exist afterwards

After the review, the organisation should be able to show what was approved and why. The evidence does not need to be elaborate, but it should be complete enough for another reviewer to understand the decision.

At minimum, a higher-risk AI vendor evidence pack should usually contain:

• the approved use case, business owner, user group and prohibited uses;
• the vendor questionnaire with supporting documents, not just answers;
• the AI terms, DPA, security schedule, subprocessor list and relevant product documentation;
• a data-flow note covering prompts, files, outputs, logs, telemetry, feedback and support content;
• role mapping for controller, processor and any separate vendor purposes;
• transfer evidence, including hosting, access, subprocessors and transfer mechanisms;
• DPIA screening, DPIA update or assessment note;
• security assurance evidence and any scope limitations;
• configuration evidence, including training opt-outs, retention settings and access restrictions;
• a decision record, action log, risk acceptance if needed and review date.

This evidence pack becomes useful beyond procurement. It helps audit, incident response, contract renewal, DPIA review, training, board reporting and exit planning. It also stops the organisation having to reconstruct the original decision months later after an incident, vendor change or regulator question.

Red flags that should slow approval

Some issues do not automatically mean "no", but they should slow the route to approval.

A vendor answer should be challenged where it uses broad phrases such as "may use data to improve services" without explaining the data categories and purposes. It should also be challenged where the vendor cannot identify model providers or subprocessors, cannot separate hosting from support access, refuses meaningful audit or assurance evidence, cannot explain log content, or treats all AI outputs as outside the privacy review.

The same applies where the business cannot explain the use case. If nobody owns the deployment, nobody can own the limits, training, user behaviour, incident route or review date.

The strongest approval records usually make the limits obvious. They say what is approved, what is not approved, what depends on configuration, what the vendor still owes, what risk has been accepted, and what change would require re-review.

What this means for CPD

For Hour 6, the practical skill is not memorising a longer AI vendor questionnaire. It is learning to turn supplier claims into an evidence-led governance decision.

After reading this article and completing the course hour, a DPO or privacy lead should be better able to spot when a questionnaire is too shallow, ask for evidence that matches the use case, separate internal decisions from vendor assurances, and leave behind a review record that procurement, legal, security and audit can actually use.

XpertDPO supports organisations that need this kind of evidence-led vendor governance, whether through Vendor / Third-Party Privacy Governance, AI Governance and DPIA Lifecycle Support or targeted support on role mapping, transfer evidence and defensible vendor review records.

This article is intended to support the learning covered in Hour 6 of our XpertAcademy CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.