This article accompanies Hour 6: Privacy & AI in the Cloud 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.

Cloud AI tools rarely arrive as a single neat product. They arrive as enterprise copilots, AI features inside existing SaaS platforms, customer support tools, analytics services, developer assistants, document review systems, meeting tools, HR platforms and retrieval-augmented knowledge assistants. Some are bought through procurement. Some are switched on through an existing licence. Some appear during an M&A review as part of a target company's operating stack.

That makes cloud AI due diligence a privacy and security governance issue, not only a vendor questionnaire issue. The organisation needs to understand what the tool does, what data it receives, what the vendor can do with that data, where the data is hosted and accessed, who can see it, what is logged, what is retained, what is used for model improvement, what is transferred, what changes over time and who owns the decision to keep using it.

This article is general guidance, not legal advice on any specific vendor, transaction or deployment. The right level of review will depend on the data, sector, affected individuals, countries, contract position, AI functionality and operational reliance involved.

Cloud AI due diligence should answer a simple governance question: can the organisation explain the tool, the data flows, the controls and the decision to use it?

Why cloud AI due diligence is harder than ordinary SaaS review

Traditional SaaS due diligence already involves controller and processor mapping, security evidence, contract terms, subprocessors, hosting locations, access controls, deletion, audit rights, incident notice and transfer mechanisms. AI adds several more layers.

The first is data-use ambiguity. A vendor may say that customer data is not used to train "foundation models", but the terms may still allow prompts, outputs, telemetry, feedback, support content or product analytics to be used for service improvement, abuse monitoring, evaluation, fine-tuning, benchmarking or troubleshooting. Those are not automatically inappropriate, but they need to be understood and governed.

The second is system complexity. A cloud AI tool may include a model provider, application provider, hosting provider, vector database, monitoring provider, content safety provider, support vendor and other subprocessors. It may also connect to the customer's own document repositories, CRM, HR system, ticketing system, email, chat, codebase or data warehouse.

The third is change. AI-enabled services can change through model updates, new features, revised retention settings, new subprocessors, altered telemetry, changed prompts, wider integrations or new terms. A vendor review that was reasonable at procurement may become stale if change control is weak.

For that reason, cloud AI should sit within a defensible vendor privacy lifecycle, not a one-off approval email.

Start with the use case and role map

The first due diligence question should not be "is the vendor reputable?" It should be "what are we using the tool for?"

A drafting assistant used on public marketing copy is not the same risk as a support chatbot connected to complaint files, an HR assistant summarising employee relations records, a clinical workflow tool, a legal disclosure assistant or an AI search layer across a document repository. The same vendor may be low risk in one deployment and high risk in another.

The review should identify the approved use case, prohibited uses, user groups, affected individuals, data categories, connected systems, outputs, human review, business owner and review date. It should also map roles carefully. A vendor may be a processor for hosted AI functionality, an independent controller for some product analytics, a separate controller for its own account management or security operations, and a provider or deployer in AI Act language depending on the system and context.

The distinction matters because GDPR controller/processor mapping and AI Act provider/deployer mapping answer different questions. XpertDPO's guidance on vendor oversight and legal characterisation and the article on EU AI Act provider and deployer obligations are useful companion reads where the role position is unclear.

Vendor terms: the clauses that need daylight

Privacy teams should read the AI-specific terms, product terms, data processing agreement, security schedule, subprocessor page, acceptable-use policy, support terms, service documentation and any AI addendum together. The risk often sits in the gap between documents.

The contract should explain the vendor's processing instructions, confidentiality commitments, security obligations, subprocessor authorisation, assistance with rights requests and DPIAs, breach support, end-of-contract deletion or return, and audit or assurance rights. For cloud AI, the review should go further and test the terms against the actual product behaviour.

Ask whether customer data, prompts, files, outputs, embeddings, feedback, telemetry, logs, evaluations or support content may be used for model training, model improvement, fine-tuning, product improvement, safety monitoring or abuse detection. Ask whether opt-outs are available, whether they are default-on or default-off, whether they apply across all products, and whether they cover both vendor models and third-party model providers.

Check whether logs and telemetry can include personal data, sensitive data, credentials, confidential material or repository content. Check who can access them and for how long. If the vendor says logs are "de-identified" or "aggregated", ask what that means in practice and whether the data may still relate to identifiable users or customers when combined with account, device, time, workspace or document metadata.

These points are especially important for LLM services because privacy risk can sit in prompts, memory, logs, model outputs and retained context. XpertDPO's article on LLM privacy risks for DPOs and privacy teams covers that wider risk picture.

Hosting, access locations and transfers

Cloud AI due diligence should separate hosting location from access location. Data may be stored in the EEA, UK or another selected region, while vendor support, security operations, subprocessor processing or model calls involve remote access from elsewhere. A transfer assessment may be needed even where the marketing page says "EU data residency".

The review should map where customer data is stored, where prompts and outputs are processed, where logs and telemetry are retained, where backups are held, where support teams may access data, where subprocessors operate, and whether third-country access can occur for troubleshooting, security, abuse monitoring or incident response.

For EU and UK organisations, this means checking the relevant transfer mechanism, transfer risk assessment or data protection test, supplementary measures, onward transfers and practical enforceability of the vendor's commitments. The EDPB's transfer recommendations and the ICO's transfer risk assessment guidance both point towards documented, context-specific analysis rather than a generic reliance on standard terms.

Where transfers are material, link the cloud AI review to the organisation's existing transfer governance. The XpertDPO article on transfer impact assessments in practice is a natural support point for teams turning vendor answers into a defensible record.

RAG, repositories and permissions

Retrieval-augmented generation can be useful because the AI system answers from approved internal sources rather than relying only on a general model. It can also expose weak information governance very quickly.

If an AI assistant indexes SharePoint, Teams, email, Google Drive, CRM records, HR folders, ticketing systems, code repositories or knowledge bases, the privacy review needs to cover the source permissions and the retrieval layer. Does the tool respect existing permissions? Does it index documents that users could not otherwise see? Does it expose snippets, summaries or metadata from restricted files? Does it retain embeddings or cached content after source deletion? Can repository owners remove content from the index? How quickly are permission changes reflected?

This is not only a technical question. It is a governance question about records management, access design and data minimisation. A cloud AI tool connected to a messy repository will inherit the mess, then make it easier to query.

For sensitive repositories, the review should consider whether the AI tool should be limited to curated sources, specific workspaces, approved document classes or non-production data. In many cases, the best control is not a clever prompt rule. It is a narrower connection.

Security evidence, support access and incident routes

Security evidence should be specific enough to support the actual use case. A SOC 2 report, ISO certificate or cloud security whitepaper may help, but it should not be treated as a substitute for understanding the service.

Ask how the vendor protects data in transit and at rest, separates tenants, manages identity and access, restricts privileged access, monitors abuse, tests controls, handles vulnerabilities, manages secure development, protects backups, deletes data, logs administrator actions and responds to incidents. Where the AI tool connects to internal systems, ask how OAuth scopes, API tokens, plugins, connectors and service accounts are controlled.

Support access deserves its own attention. Can vendor staff view prompts, files, outputs, logs, screenshots or workspace content? Is access just-in-time, approved, logged and time-limited? Can the customer restrict or disable support access? Are support staff and subprocessors in approved locations? What happens during an urgent incident?

Incident terms should address more than classic personal data breaches. Cloud AI incidents may involve unauthorised repository exposure, prompt or output leakage, excessive logging, insecure plugin access, model behaviour that reveals personal data, misdirected support access, or a configuration change that broadens access. The review should identify who investigates, who notifies, who preserves evidence, who communicates with affected individuals or regulators where required, and what logs will be available.

DPIAs, AI assessments and change control

Not every cloud AI deployment will require a full DPIA, but every material deployment should go through structured screening. A DPIA or wider AI/privacy assessment becomes more likely where the tool handles sensitive data, employee data, children, patients, students, vulnerable customers, complaint records, financial data, special category data, profiling, monitoring, automated recommendations or decisions that may significantly affect people.

The DPIA record should not sit apart from vendor due diligence. It should use the same facts: use case, personal data categories, data flows, vendor roles, subprocessors, hosting, transfers, security evidence, retention, deletion, human review, transparency, individual rights support, incident handling and review triggers.

Change control is where many cloud AI reviews fail. The approval should say what changes require privacy, security or legal re-review. Typical triggers include a new model, new model provider, new AI feature, changed model improvement terms, new subprocessor, changed hosting or support location, wider user group, new connected repository, new data category, changed retention, reduced human oversight, new output use, incident, complaint, audit finding or regulator guidance.

XpertDPO's AI Governance and DPIA Lifecycle Support is designed for this joined-up lifecycle, where DPIAs, vendor review, AI governance and change control need to remain connected after the initial approval.

The M&A and vendor diligence angle

Cloud AI matters in corporate due diligence because AI-enabled vendor use may reveal privacy debt that is not visible from a list of contracts. A target company may rely on AI tools for customer support, HR, analytics, sales scoring, product development, software engineering or document review without a complete record of data flows, model improvement terms, transfer positions or repository access.

In an M&A context, due diligence should test whether the target has an AI inventory, vendor register, DPIA screening process, transfer record, security assurance process, acceptable-use rules, training evidence and a route for approving new AI features inside existing cloud platforms. The review should also identify whether important customer or regulated-sector commitments restrict AI use, cross-border processing, subprocessors or model training.

Where issues are found, the answer is not always "do not proceed". It may be price risk, warranty wording, pre-completion remediation, post-completion integration work, a vendor exit plan, a DPIA uplift, a transfer remediation plan, or a pause on a particular AI use case. XpertDPO's Data Protection Due Diligence for Corporate M&A can support that evidence-led view.

A practical cloud AI diligence table

Diligence area Evidence to request
Use case and ownership Approved purpose, users, affected groups, prohibited uses, business owner and review trigger.
Data use Prompt, file, output, embedding, telemetry, feedback, log and model improvement terms.
Architecture Model provider, hosting region, support access, subprocessors, backups and connected systems.
RAG and permissions Source repositories, indexing scope, permission enforcement, cache/embedding deletion and access testing.
Security and incidents Assurance reports, access controls, privileged access logs, vulnerability process, incident notice and investigation support.
Transfers Hosting and access locations, transfer mechanisms, onward transfers, supplementary measures and review date.
Exit and deletion Export, deletion, backup deletion cycle, end-of-contract return, residual logs and evidence of disposal.
Change control Notice of AI feature, model, term, subprocessor, location, retention, support or integration changes.

How XpertDPO supports cloud AI governance

XpertDPO supports organisations that need cloud AI reviews to be practical, defensible and proportionate. That may mean reviewing a single AI-enabled vendor, building a vendor evidence pack, connecting procurement and security evidence to a DPIA, reviewing transfer assumptions, supporting M&A diligence, or helping an in-house DPO challenge unclear AI terms without blocking useful adoption by default.

For ongoing supplier governance, Vendor / Third-Party Privacy Governance can help turn cloud AI due diligence into a repeatable lifecycle. For multinational teams, the Global DPO Operating Model can help align local transfer, DPIA, vendor and AI governance expectations without creating inconsistent records in each country.

The aim is not to make every AI tool slow to approve. It is to know which tools can move through a light route, which need deeper review, and which should wait until the vendor, security, transfer or DPIA evidence is strong enough to support the decision.

This article is intended to support the learning covered in Hour 6: Privacy & AI in the Cloud in 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.

Sources