AI subprocessor risk in your vendor chain

An AI subprocessor is any third party that processes personal data on behalf of the data processor — in this case, the SaaS vendor — in the course of delivering the AI-powered feature. The most common AI subprocessors in enterprise SaaS are foundation model providers whose APIs receive inference requests containing customer data.

AI subprocessors are distinct from other subprocessors — such as cloud infrastructure providers, monitoring tools, and backup services — because of the specific nature of the data processing. An infrastructure subprocessor stores encrypted data. An AI subprocessor processes the plaintext content of customer data as part of the model's inference computation. The model receives prompts that may contain sensitive information; the model provider's infrastructure handles that information at inference time.

The subprocessor chain for an AI vendor typically has at least two links after the customer:

• Data controller: The organisation deploying the AI product.
• Data processor (the SaaS vendor): The vendor whose product the organisation uses. The vendor receives customer data as part of providing the service.
• Sub-processor (the model provider): The third-party foundation model company whose API the SaaS vendor uses to power the AI feature. The model provider receives inference requests that include customer data.

Some chains are longer. A model provider may itself use third-party infrastructure (a major cloud provider for GPU compute) that qualifies as a further subprocessor. For practical security review purposes, the relevant layer is the one that processes the semantic content of customer data — the model provider.

In some AI product architectures, the chain is more complex. The SaaS vendor may use an AI middleware layer — a framework or orchestration tool — that routes requests to multiple model providers depending on the query. In this case, there may be multiple AI subprocessors, each handling different data.

The data that flows through an AI subprocessor chain typically includes:

• Prompt content:The text of the query sent to the AI feature, which may include customer data, internal documents, and personal information depending on the feature's function.
• Context content:Retrieved documents, user data, or system context injected into the model's context window. In RAG-powered AI features, this may include large amounts of internal document content.
• Metadata: Request metadata associated with each inference call — timestamps, user identifiers, session identifiers — which may constitute personal data under applicable data protection law.

What the model provider does with this data is the central question. The key variables: whether inference data is retained (and for how long), who within the model provider organisation can access retained inference data, whether inference data is used to train or fine-tune the model, and whether the model provider transfers data to further subprocessors.

Under GDPR Article 28, a data processor may only engage a subprocessor with the prior specific or general authorisation of the data controller. General authorisation mechanisms — where the processor notifies the controller of intended subprocessor changes and the controller has a right to object — are common in SaaS agreements.

When a SaaS vendor adds an AI feature powered by a third-party model provider, that model provider becomes a subprocessor. If the vendor uses a general authorisation mechanism, the customer should receive notice of the subprocessor addition. In practice, this notice is often buried in a subprocessor list update email or a changelog that security teams do not monitor.

The data controller is ultimately responsible for ensuring that each subprocessor provides sufficient guarantees regarding technical and organisational measures for GDPR compliance. Accepting a vendor's subprocessor notification without reviewing the model provider's DPA terms is a compliance gap, not a compliance act.

The obligation on the data controller is not just to know who the subprocessors are — it is to ensure each subprocessor provides sufficient guarantees. For an AI subprocessor, those guarantees must cover the AI-specific processing risks: training data use, inference data retention, and access to customer data.

The adequacy of the model provider as a subprocessor depends on the terms of the model provider's data processing agreement — not the SaaS vendor's DPA. The SaaS vendor's DPA governs the relationship between the SaaS vendor and the organisation; the model provider's terms govern the relationship between the SaaS vendor and the model provider. The organisation needs to understand both.

The specific questions about the model provider's terms:

• Does the model provider offer a data processing agreement that meets GDPR Article 28 requirements?
• Does the model provider retain inference data? If so, for how long?
• Does the model provider use inference data for training? Can the vendor opt out? Does the opt-out apply to customer data?
• Where is inference data processed and stored? Are there international transfer mechanisms in place?
• What security certifications does the model provider hold?
• Does the model provider have a breach notification obligation to the SaaS vendor that would cascade to the organisation?

The contractual requirements for AI subprocessor management flow from GDPR Article 28(4): the same data protection obligations as set out in the contract between the controller and the processor must be imposed on the subprocessor.

In practice, this means the SaaS vendor's DPA with the model provider must impose the same protections — confidentiality, purpose limitation, data subject rights support, deletion on termination, security measures — that the organisation's DPA imposes on the SaaS vendor.

The SaaS vendor must be able to demonstrate that this contractual chain exists. Common issues: vendors who use model provider APIs under standard terms that do not constitute a DPA, vendors whose model provider DPAs do not include AI-specific protections (training data restrictions, inference data retention limits), and vendors who cannot produce the model provider agreement because it is confidential.

The AI security review for a vendor with an AI subprocessor must document:

• The identity of the model provider and any other AI subprocessors in the chain.
• The data that flows to each AI subprocessor, including the categories of personal data in inference requests.
• The model provider's data retention practices and training data use policy as applied to the SaaS vendor's customers.
• The contractual relationship between the SaaS vendor and the model provider, and whether it constitutes an adequate DPA.
• Any identified gaps in the subprocessor chain and the remediation plan.
• The re-assessment trigger for changes to the subprocessor chain — specifically, when the vendor changes its model provider or the model provider changes its data handling terms.

For broader context on the data handling review for AI vendors, see Reviewing how an AI vendor handles your data.