# Cloud AI Contracts, Subprocessors and Transfer Evidence

Canonical URL: https://xpertdpo.com/cloud-ai-contracts-subprocessors-and-transfer-evidence/

Content type: Article

Published: 2026-06-26T12:02:38+01:00

Updated: 2026-06-26T12:02:38+01:00

Author: Philipa Jane Farley, Head of Legal and Operations

Summary: Cloud AI contract review should connect the data processing terms, AI product terms, subprocessor chain, remote support, training use, logs, audit rights and transfer evidence into one decision record.

## Article

*This article accompanies Hour 6: Privacy, AI and Cloud Services in our full-day CPD programme on [XpertAcademy](https://xpertacademy.com/cpd-event-b-ai-technical/). 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](https://xpertacademy.com/cpd-event-b-ai-technical/).*

 A vendor offers an AI analytics service for customer operations. The product is cloud hosted. It can analyse support tickets, call transcripts and account notes. The vendor offers a European hosting option, but its documentation also refers to several regional processing locations, remote support, product telemetry, an external model provider and a changing list of subprocessors.

 The business asks whether the contract is acceptable. The answer cannot come from the data processing agreement alone. The privacy team needs to connect the contract terms, AI product terms, subprocessor chain, transfer evidence, logging position, training use, audit rights and operational support model before anyone can say what risk is being accepted.

 This article is general guidance, not legal advice on any specific vendor, contract or transfer assessment. Cloud AI contracts are fact-sensitive, and the right answer will depend on the service, data, countries, roles, safeguards, sector and negotiating position.

> In cloud AI review, the question is not only "what does the contract say?" It is "does the contract match the way the service actually processes, accesses, logs and transfers data?"

### Why cloud AI contract review is different

 Cloud AI services often sit across several documents. There may be a master services agreement, data processing agreement, AI addendum, product-specific terms, acceptable-use policy, security schedule, subprocessor page, data residency note, model provider documentation, support policy, service description and online trust centre.

 The risk often appears between those documents. A DPA may say customer data is processed only on instructions, while product terms allow broad service improvement. A data residency page may promise regional storage, while support documentation allows remote access from other countries. A subprocessor page may list hosting providers, but not explain which subprocessors receive prompts, outputs, logs or telemetry. A security certificate may cover the platform, but not a newly released AI feature.

 This is why cloud AI contract review is not a redline exercise by itself. It is an evidence exercise.

 The DPC's cloud guidance emphasises control, security, transparency, location and written contract terms when organisations engage cloud providers. Those themes are directly relevant to AI-enabled cloud tools. The organisation should be able to show how the contract keeps the controller in control, how subprocessors are authorised, how transfers are identified, how security assurances are evidenced and how breach or incident obligations work in practice.

### Start with the service boundary

 Before reviewing clauses, define the service boundary. What exactly is the organisation buying and using?

 For an AI analytics tool, the service boundary may include the customer-facing application, model provider, cloud infrastructure, data warehouse connector, transcription module, vector database, telemetry system, support environment, content filtering service and analytics dashboard. Some of those components may be operated by the vendor. Others may be subprocessors. Some may process raw customer data; others may process metadata, logs or derived data.

 The contract should be tested against that boundary. If the vendor says data is stored in one region, ask which categories of data are covered: source records, prompts, outputs, embeddings, logs, telemetry, backups, support tickets and admin metadata. If the vendor says no training occurs, ask whether that covers foundation model training, fine-tuning, product improvement, evaluation, quality review and third-party model provider use. If the vendor says subprocessors are listed online, ask whether the list identifies the relevant services, processing locations and change-notice route.

 A contract that is acceptable for a static SaaS dashboard may be too thin for an AI service that ingests free text, produces recommendations and routes data through several infrastructure and model layers.

### Roles need to be mapped by purpose

 The EDPB controller and processor guidelines matter because cloud AI contracts can blur roles. A vendor may act as processor for the customer's configured AI analytics workspace, but controller for account administration, billing, fraud prevention, security monitoring or certain product analytics. It may also use a subprocessor model provider that itself has specific terms.

 The role map should not rely on a single label in the contract. It should identify each processing purpose and the party deciding its purposes and means. For example:

 | Processing purpose | Likely role question |
| --- | --- |
| Analysing support tickets inside the customer's workspace | Is the vendor processing on the customer's documented instructions? |
| Account administration and billing | Is the vendor acting as a controller for its own business purposes? |
| Security monitoring and abuse detection | Is this processor activity, controller activity, or split by purpose? |
| Model improvement or evaluation | Is customer data involved, and who decides the purpose? |
| Support access to troubleshoot customer incidents | Is access covered by processor instructions and confidentiality controls? |

 This matters because Article 28-style processor terms do not solve every purpose if the vendor is acting independently for some processing. It also matters for transparency, records of processing, DPIA screening and transfer records.

 XpertDPO's guidance on [vendor oversight and legal characterisation](https://xpertdpo.com/vendor-oversight-and-legal-characterisation/) can support this kind of role analysis where the service description and the contract do not line up cleanly.

### Subprocessors: ask what they do, not only who they are

 Subprocessor review is often reduced to checking whether a vendor has a list. For cloud AI, the list is only the starting point.

 The privacy team should ask which subprocessors process which data categories, for which parts of the service, in which locations, under what transfer mechanism, and with what onward-transfer restrictions. A hosting provider, model provider, support platform, logging provider and analytics tool do not create the same risk.

 The DPC guidance notes that processors need controller authorisation for subprocessors and that controllers should receive information enabling review and objection where needed. In practice, a cloud AI evidence pack should show the current subprocessor list, date checked, update process, objection route, service function, location, transfer mechanism and any customer configuration choices.

 If a vendor's subprocessor list changes frequently, the organisation needs a practical monitoring route. That could be a subscription to change notices, a procurement owner, a quarterly review for high-risk services or a contractual trigger requiring prior notice for subprocessors involved in AI processing, model provision, support access or non-EEA transfers.

### Transfers: hosting is not the whole answer

 Many cloud AI reviews get stuck on one question: where is the data hosted? Hosting location is important, but it is not the whole transfer position.

 The review should separate:

- where source data is stored;
- where prompts and outputs are processed;
- where embeddings, logs, telemetry and backups are stored;
- where vendor support and engineering teams can access data;
- where subprocessors operate;
- whether third-country remote access is possible;
- what transfer mechanism and supplementary measures apply.

 A vendor can offer EEA hosting while still involving remote support, security monitoring, incident response or subprocessor access from elsewhere. The EDPB supplementary measures recommendations are relevant because they focus attention on the practical transfer context and the measures needed to maintain the level of protection required.

 The evidence pack should therefore include more than standard contractual clauses or a generic transfer statement. It should include a dated note explaining the transfer scenario, the categories of data involved, the parties, locations, transfer tool, supplementary measures, onward transfers and residual risk. For more material use cases, link this to the organisation's transfer impact assessment process. XpertDPO's [Transfer Impact Assessments in Practice](https://xpertdpo.com/transfer-impact-assessments-in-practice/) is a useful companion route.

### Worked example: building the evidence request

 The business wants to use the AI analytics vendor for customer operations. The tool will summarise interactions, identify trends, flag complaint themes and recommend follow-up actions. It will process customer names, account notes, support tickets, transcripts and free-text comments. Some data may include vulnerability indicators, financial difficulty, disability information or other sensitive context disclosed by customers.

 The facts are enough to start, but not enough to approve. The vendor says the service is "EU hosted". It offers a DPA and a subprocessor page. It says customer data is not used to train its general AI models. It has a SOC 2 report. It provides standard breach notification language.

 The unknowns are the real review. The privacy team does not know whether logs and telemetry leave the EU hosting region. It does not know whether the external model provider receives raw prompts or only transformed data. It does not know whether transcripts are retained for quality review. It does not know whether support engineers outside the EEA can access customer content. It does not know whether the audit rights are limited to generic certifications. It does not know what notice is given when subprocessors change.

 The decision question becomes:

 Can this cloud AI analytics service be approved for customer operations data with defensible contract terms, subprocessor governance, transfer evidence, AI data-use limits, logging controls and audit rights?

 The evidence request is then built around six areas.

 First, data use. The vendor must identify whether source records, prompts, outputs, transcripts, embeddings, logs, telemetry, feedback and support content are used for service provision, support, security, abuse monitoring, product improvement, model training, fine-tuning or evaluation.

 Second, subprocessors. The vendor must provide a dated subprocessor list with service functions, countries, data categories, transfer mechanisms and change-notice terms.

 Third, transfers. The vendor must explain hosting, access, support, backups, logs, model processing and onward transfer locations. If non-EEA access occurs, the transfer evidence must explain the transfer tool and supplementary measures.

 Fourth, training use. The contract and product settings must confirm whether customer data is excluded from model training and whether any opt-out applies to prompts, outputs, files, feedback, logs and third-party model providers.

 Fifth, logs. The vendor must describe log categories, retention, access controls, personal data content, export availability, deletion route and incident investigation support.

 Sixth, audit rights. The vendor must identify what evidence the customer can receive, whether independent reports cover the AI feature, how exceptions are handled and whether the customer can obtain additional evidence after an incident or material change.

 The evidence created afterwards is a contract review note, subprocessor and transfer table, AI data-use summary, log and retention note, security assurance review, DPIA screening record, action log, sign-off decision and review trigger list. If the vendor refuses to identify model providers or transfer locations, the issue is escalated before go-live.

### Contract clauses that need operational evidence

 Some clauses deserve particular attention because they sound useful but can be weak unless tied to evidence.

 Instructions clauses should cover the actual AI processing, including prompts, outputs, files, embeddings, logs and support access. If the vendor reserves separate rights for improvement or analytics, those purposes should be clearly identified.

 Confidentiality and access clauses should explain who can access customer content, when, from where, under what approval, and how access is logged. Remote support should not be hidden inside a generic personnel clause.

 Security clauses should be linked to current assurance evidence. Ask whether the report or certification covers the AI service, the model integration and the relevant cloud environment.

 Subprocessor clauses should provide authorisation, notice, objection, flow-down obligations and enough information to assess risk. A list without functions and locations is rarely enough for a higher-risk AI deployment.

 Transfer clauses should align with the real data path. If the service involves support access, model calls or log processing outside the selected hosting region, the transfer record should say so.

 Deletion clauses should cover source data, prompts, outputs, logs, telemetry, embeddings, backups, support tickets and derived records where relevant. If some records are retained for security or legal reasons, the retention basis and period should be clear.

 Audit clauses should explain what evidence the customer can rely on before approval and after a material event. Generic rights that are impossible to use may not support a meaningful review.

### What the DPO or privacy team should check

 The privacy team does not need to become the contract owner for every clause, but it should make sure the privacy decision is based on the right facts.

 Check the purpose and affected individuals. The risk is different where the AI analyses public product feedback, employee conduct records, customer vulnerability data or children's information.

 Check the data categories and sensitivity. Free-text inputs often contain more personal data than the business expects.

 Check role mapping by purpose. Do not let one processor label cover independent vendor analytics, security purposes or model improvement without scrutiny.

 Check lawful basis, fairness and transparency. If AI outputs affect customers or employees, the review should cover how the organisation explains the processing and how human review works.

 Check minimisation and retention. A tool should not ingest whole repositories, unrestricted transcripts or long-lived logs where narrower configuration would work.

 Check vendor and transfer evidence. The contract should be backed by subprocessor, location, support, transfer and security evidence.

 Check escalation and review triggers. A change in model provider, subprocessor, hosting, support location, training terms, logging, retention, integration scope or use case should bring the review back to privacy and security.

### Evidence that should exist afterwards

 After the contract review, the organisation should be able to explain what it accepted. That record should be concise enough to use but specific enough to defend.

 Useful evidence includes the final contract and DPA, AI addendum, product terms, subprocessor table, transfer evidence note, security assurance review, data-use summary, log and retention note, DPIA or screening record, configuration evidence, decision record, unresolved action log and next review date.

 For higher-risk uses, include a short risk acceptance note where any important issue remains. For example, if remote support outside the EEA is allowed under controlled conditions, the record should identify the conditions, safeguards, data categories, approval owner and re-review trigger.

 This evidence is not just a filing exercise. It supports incident response, renewal, vendor change review, audit, board reporting, DPIA updates and user training. It also gives the business a clearer answer than "legal approved the DPA".

### What this means for CPD

 For Hour 6, the practical skill is learning to read cloud AI contracts as part of a working evidence set. The DPO or privacy lead should be able to connect legal terms to actual data flows, operational support, subprocessor chains, transfer positions and AI-specific data use.

 XpertDPO supports teams building that evidence through [Vendor / Third-Party Privacy Governance](https://xpertdpo.com/vendor-third-party-privacy-governance/), [AI Governance and DPIA Lifecycle Support](https://xpertdpo.com/ai-governance-dpia-lifecycle-support/) and practical transfer review support where cloud AI data paths are hard to pin down.

 The aim is not to slow every cloud AI procurement. It is to avoid approving a contract that looks acceptable until the first subprocessor change, support incident, transfer question or log disclosure reveals that the real service was never properly understood.

 *This article is intended to support the learning covered in Hour 6 of our [XpertAcademy](https://xpertacademy.com/cpd-event-b-ai-technical/) 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](https://xpertacademy.com/cpd-event-b-ai-technical/).*

#

## General Information Only

This article is provided for general information and does not constitute legal, regulatory, or professional advice. Data protection obligations depend on the specific facts, context, and jurisdiction involved. You should not rely on this content as a substitute for advice tailored to your organisation.

If you would like support with a specific issue, please contact us: https://xpertdpo.com/contact/