Sub-Processor (AI Vendors) — GDPR Article 28(2) Obligations

Key Takeaway: When your AI vendor uses OpenAI, Anthropic, Google, or any other third-party model provider to process your personal data, that provider becomes a sub-processor. Under GDPR Article 28(2), you — the controller — must authorize every sub-processor in the chain. Most enterprise AI contracts get this wrong.

What Is a Sub-Processor?

A sub-processor is any third party that a data processor engages to carry out specific processing activities on behalf of the data controller. The term originates in GDPR Article 28(2): "Where a processor engages another processor for carrying out specific processing activities on behalf of the controller, the same data protection obligations as set out in the contract or other legal act between the controller and the processor... shall be imposed on that other processor by way of a contract."

In plain language: the processor's obligations under the Data Processing Agreement (DPA) must flow down to every sub-processor in the chain. If the sub-processor fails, the processor remains fully liable to the controller.

The sub-processor concept has become strategically important for enterprise AI procurement because virtually every AI SaaS vendor relies on third-party foundation model providers, cloud infrastructure, and data pipeline services to deliver its product. Each of these can be a sub-processor — and each must be contractually controlled.

Why It Matters

The sub-processor chain is one of the most commonly underestimated GDPR compliance risks in enterprise AI procurement. Three scenarios create exposure:

Unauthorized sub-processors. If an AI vendor routes personal data through a foundation model API (OpenAI, Anthropic, Cohere) without prior written authorization from the controller, that is an unauthorized processing act. The controller is in breach of its own GDPR obligations for using a non-compliant processor; the processor is in breach of Article 28(2); and both parties may face supervisory authority action.

Inadequate sub-processor DPAs. The GDPR requires that sub-processors be bound by the same data protection obligations as the main processor. If the AI vendor's agreement with its model provider does not mirror the Article 28 requirements, the controller's legal basis for the processing is compromised.

Undisclosed sub-processor changes. Article 28(2) requires that the processor give the controller prior notice of any intended changes to sub-processors, and that the controller has the right to object. AI vendors that silently switch or add model providers without notification breach this requirement — and the controller who does not enforce notification rights bears downstream risk.

The AI Model Provider Problem

The sub-processor designation is most acute where the AI vendor's core product is built on a third-party foundation model. Consider a sales intelligence platform that uses OpenAI's GPT API to process and score prospect data. The flow is: controller (enterprise) → processor (sales intelligence SaaS) → sub-processor (OpenAI). GDPR requires:

  1. The controller must be aware that OpenAI processes the data.
  2. The controller must have authorized this arrangement — either specifically or via a general authorization permitting sub-processors subject to notification rights.
  3. The processor (SaaS vendor) must have a DPA with OpenAI that imposes Article 28 obligations on OpenAI's processing.
  4. OpenAI's processing must be limited to what is authorized under that DPA — specifically, it must not use the data for model training without explicit controller authorization.

In practice, many AI vendors' standard contracts omit a complete sub-processor list, use general authorization language that obscures which providers process personal data, and include no notification mechanism for sub-processor changes. Enterprise procurement teams should verify all four requirements before signing.

Regulatory Anchor: Article 28(2) and the Article 28(4) Chain

GDPR Article 28(2) establishes the authorization requirement. Article 28(4) extends it: "Where that other processor fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller for the performance of that other processor's obligations."

This makes sub-processor vetting a direct financial and regulatory risk for the controller. If an AI vendor's model provider suffers a data breach, the vendor remains liable to you — but only if your DPA with the vendor included compliant sub-processor controls. Without those controls, your ability to seek redress is weakened.

ISO 42001 Section 6.1 (risk identification) explicitly contemplates supply chain data governance — organizations implementing ISO 42001 should include sub-processor mapping as part of their AI risk register. The EU AI Act adds a further layer: Article 25 requires AI providers to disclose sub-contracting arrangements to high-risk AI deployers, creating a parallel supply chain transparency obligation.

What Compliant Sub-Processor Management Looks Like

A compliant sub-processor framework from an AI vendor includes:

  • A published sub-processor list specifying the name, location, and processing role of each third party.
  • A mechanism to notify the controller of sub-processor changes with adequate advance notice (typically 30 days).
  • A contractual right for the controller to object to new sub-processors.
  • Evidence that each sub-processor is bound by a DPA meeting Article 28 requirements.
  • Data transfer documentation where sub-processors are outside the EEA (Standard Contractual Clauses or adequacy mechanism).
  • A process for removing personal data from sub-processor systems on contract termination.

Knowlee's Sub-Processor Framework

Knowlee maintains a current sub-processor list, published as part of the commercial DPA. The list specifies each sub-processor's name, country of establishment, and the processing activity they perform. Advance notification of sub-processor changes is provided with 30 days' notice, and customers retain contractual objection rights.

All Knowlee sub-processors are bound by DPAs that satisfy GDPR Article 28(4) obligations — including explicit restriction on using Knowlee customer data for model training or product improvement. Knowlee's per-tenant Supabase isolation architecture ensures customer data does not comingle across processor or sub-processor boundaries. Data transfers outside the EEA are covered by Standard Contractual Clauses (2021/914/EU Module 2 and Module 3 as applicable). This sub-processor framework is auditable and forms part of Knowlee's ISO 42001-aligned AI supply chain risk management documentation.

Related Terms