For AI consultancies, a missing sub-processor list is a critical GDPR vulnerability. This guide explains how to navigate Article 28 DPAs, enforce zero data retention, and secure the legal documentation your clients require before moving inference to production.
The DPA Question: Sub-Processors in AI Inference
For AI consultancies, a missing sub-processor list is a critical GDPR vulnerability. This guide explains how to navigate Article 28 DPAs, enforce zero data retention, and secure the legal documentation your clients require before moving inference to production.
Justus Amen
August 26, 2026 · GTM at Lyceum Technology
AI This article was created with the help of AI.
The Reality of GDPR Fines for AI Pipelines
When enterprise clients commission an AI pipeline, the procurement discussion inevitably transitions from latency benchmarks and token throughput to regulatory exposure. For implementation agencies and consultancies delivering production systems across Europe, data governance is not a theoretical concern. Under Article 83(4) of the General Data Protection Regulation (GDPR), breaches of the controller and processor obligations that govern the processing chain, Article 28 among them, attract administrative fines of up to 10,000,000 EUR or 2% of an undertaking's total worldwide annual turnover of the preceding financial year, whichever is higher. Infringements of the basic processing principles, data subject rights, or the rules on third-country transfers sit in a higher fine tier again.
Regulatory enforcement across European jurisdictions is shifting rapidly from basic cookie consent audits toward structural compliance in automated data pipelines. If your client passes confidential user records, financial queries, or proprietary medical data through an unvetted inference API, every entity in the supply chain shares operational and legal exposure. Without a rigorous contractual foundation, a high-throughput LLM integration can become an uninsurable liability.
- Article 83(4) imposes fines up to 10,000,000 EUR or 2% of total worldwide annual turnover, whichever is higher, for breaches of the controller and processor obligations in Articles 25 to 39, which include Article 28.
- Article 83(5) places the basic processing principles, data subject rights, and transfers of personal data to a third country in a higher fine tier, again calculated on total worldwide annual turnover.
- Supervisory authorities weigh the technical and organisational measures implemented under Articles 25 and 32 when setting the amount of a fine.
For system integrators, securing verifiable compliance before deploying production workloads is the only way to avoid catastrophic contractual clawbacks and regulatory sanctions.
How Article 28 Defines the Processor Chain
Under GDPR Article 28, every entity handling personal data on behalf of an enterprise acts as a processor. When an AI consultancy builds a custom retrieval-augmented generation (RAG) system or agentic workflow for a corporate client, the client is the data controller, the consultancy acts as the primary processor, and the underlying cloud inference platform operates as a sub-processor.
Article 28(1) mandates that a controller shall use only processors that provide sufficient guarantees to implement appropriate technical and organisational measures. Furthermore, Article 28(2) strictly prohibits a processor from engaging another processor without prior specific or general written authorisation from the controller, and requires the processor to inform the controller of any intended addition or replacement of other processors so the controller can object.
In European Data Protection Board (EDPB) Opinion 22/2024, adopted on 7 October 2024, regulators clarified that controllers should have the identity (name, address, contact person) of all processors and sub-processors in the chain readily available at all times, regardless of the risk of the processing activity. If an inference provider silently proxies API calls to secondary vendors or shifts workloads across offshore clusters without explicit authorization, the entire chain breaches GDPR compliance.
| Supply Chain Tier | Role Under GDPR | Primary Legal Duty |
|---|---|---|
| Enterprise Customer | Data Controller | Uses only processors that provide sufficient guarantees, and authorises (or objects to) any further processor in the chain |
| AI Consultancy / Integrator | Primary Processor | Acts only on documented controller instructions and imposes the same data protection obligations by contract on any infrastructure partner it engages |
| Inference Infrastructure Provider | Sub-Processor | Executes compute workloads under Article 32 security measures without engaging further processors unless authorised |
To satisfy procurement teams, consultancies must prove that their upstream infrastructure providers execute binding Data Processing Agreements (DPAs) that reflect these flow-down obligations.
Mandatory Legal Requirements for an Inference DPA
A standard click-through terms of service document does not satisfy European regulatory requirements for AI workloads. Article 28(3) of the GDPR requires that processing be governed by a contract or other legal act that is binding on the processor, and it lists eight matters that contract must stipulate.
When evaluating an AI inference vendor, implementation teams must verify that the provider's DPA explicitly addresses each statutory requirement without ambiguous disclaimers or carve-outs.
- Documented instructions: The processor processes personal data only on documented instructions from the controller, including with regard to transfers to a third country (Article 28(3)(a)).
- Confidentiality commitments: Persons authorised to process the data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality (Article 28(3)(b)).
- Security of processing: The processor takes all measures required pursuant to Article 32, including payload encryption and access controls (Article 28(3)(c)).
- Sub-processor authorization: The vendor respects the conditions of Article 28(2) and 28(4) for engaging another processor, including change notifications (Article 28(3)(d)).
- Data subject rights assistance: The platform assists the controller by appropriate technical and organisational measures in responding to data subject requests under Chapter III (Article 28(3)(e)).
- Compliance assistance: The processor assists the controller in meeting its obligations under Articles 32 to 36, covering security, breach notification, DPIAs, and prior consultation (Article 28(3)(f)).
- Data deletion or return: At the controller's choice, all personal data is deleted or returned after the end of the service, and existing copies deleted (Article 28(3)(g)).
- Audit and inspection rights: The processor makes available all information necessary to demonstrate compliance and allows for and contributes to audits, including inspections (Article 28(3)(h)).
Failing to include any of these eight elements renders the processing relationship unlawful, exposing both the enterprise controller and the implementation partner to regulatory investigation.
The Importance of a Named Sub-Processor List
A major governance gap in modern cloud AI infrastructure is the proliferation of opaque, multi-tenant sub-processor trees. Many hyperscalers and API aggregators rely on tiered infrastructure where customer prompts pass through third-party CDNs, foreign hosting facilities, and proprietary telemetry collectors without clear documentation.
Vague contractual clauses stating that an inference vendor 'may use global affiliates and third-party contractors' are unacceptable during enterprise procurement. Legal teams require a concrete, named list of every entity that touches the compute path, including data centre colocation providers, network transit operators, and hardware hosting partners.
The stronger practice is to keep strict contractual control over the whole infrastructure stack and to place a comprehensive, named sub-processor list directly inside the Data Processing Agreement. While our standard DPA is available in our Trust Center on our website, the specific version containing the sub-processor list is shared on request. That way enterprise legal teams receive an authoritative, dated document tied to their specific production scope.
- Identifies physical data centre operators and hosting regions by name for audit validation.
- Guarantees written notification before any new sub-processor is onboarded to the compute fleet.
- Provides enterprise clients with the statutory window to review and object to infrastructure modifications.
Demanding an explicit sub-processor register prevents unapproved data transfers and ensures your AI architectures remain defensible under rigorous compliance audits.
Zero Data Retention and GPU Memory Caching
Beyond contractual clauses, procurement teams scrutinize how model serving engines manage customer data in volatile hardware. In standard inference setups, unvetted API providers frequently store input prompts, system instructions, and completion logs in persistent storage for debugging, analytics, or asynchronous billing metering.
True zero data retention requires an architectural guarantee: customer inputs and generated completions are processed in volatile memory and never persisted to non-volatile storage. At the hardware level, open serving engines like vLLM utilize PagedAttention to partition the key-value (KV) cache into non-contiguous physical memory blocks within High Bandwidth Memory (HBM).
Prompts are cached exclusively in GPU memory, per session, for a few minutes at most to accelerate multi-turn context processing, and are never written to a disk database or persistent object store. Once the inference execution finishes and the session TTL expires, the memory blocks are wiped and reclaimed for subsequent tensor operations.
| Storage Layer | Persistence Mechanism | Retention Duration Under Zero-Retention Policy |
|---|---|---|
| Inference Request Body | Volatile Host RAM (Kernel Buffer) | Purged immediately upon request dispatch to GPU |
| KV Cache Attention States | Volatile GPU HBM (Paged Memory Blocks) | Retained in volatile memory for session duration only (minutes) |
| Completion Response | Volatile Host RAM (Streaming Buffer) | Flushed immediately to client network stream |
| Database / Disk Storage | None (Logging Disabled) | Zero persistent storage; no prompts or outputs written to disk |
This memory-only lifecycle guarantees that sensitive enterprise tokens cannot be extracted through cold-disk forensics or inadvertent backup retention.
Resolving EU Data Residency and Model Routing
Contractual DPAs must align perfectly with actual network topology. A common procurement pitfall is assuming that an EU-headquartered inference vendor automatically processes all model weights within the European Union. In practice, many platforms operate opaque smart routers that offload peak inference traffic to overseas data centres subject to the US CLOUD Act.
Achieving true EU data sovereignty requires auditing infrastructure on a strict per-model basis rather than accepting broad platform-level marketing claims. While European hosting is our core architectural standard, transparent vendors explicitly disclose regional boundaries for every model in their catalogue.
Across our Serverless Inference catalogue of 35 open-weight models, 31 models run strictly in European data centres (eu-north1) with guaranteed EU data residency, while 4 specialized models utilize global multi-region hosting. This granular transparency allows AI consultancies to select compliant endpoints that keep customer data securely within European borders.
- EU-pinned models: Deployed on European hardware in France, Spain, and Nordic data centres without cross-border transit.
- Global endpoints: Clearly documented for multi-region availability where localized residency is not contractually required.
- No unannounced rerouting: Request traffic is never silently diverted across international jurisdictions during peak load.
By selecting models pinned to sovereign European infrastructure, implementation partners eliminate international data transfer risks under GDPR Chapter V.
Securing Compliance & Certifications for Your Clients
For AI consultancies and system integrators, navigating enterprise procurement requires turning infrastructure compliance from a friction point into a commercial competitive advantage. Enterprise buyers will not sign off on production rollouts without verifiable documentation covering DPAs and physical data centre security.
Through our Compliance & Certifications offering, Lyceum Technology delivers the legal and technical artifacts needed to clear enterprise vendor reviews. Our regular DPA is accessible in our Trust Center on our website, and we provide the version containing our named sub-processor list upon request for every prospective integration. Furthermore, while GDPR compliance remains an essential self-asserted legal posture, all upstream European data centre facilities across our fleet maintain audited ISO 27001 certifications, with certificates available on request under standard verification workflows.
- Execute a binding Article 28 DPA with a complete, named sub-processor list provided directly upon request.
- Verify zero-retention GPU memory architectures that process prompts without writing tokens to persistent databases.
- Review upstream ISO-certified data centre credentials and lock production workloads to European hosting zones.
Engaging with Compliance & Certifications allows your technical team to de-risk client deployments, accelerate procurement sign-offs, and deploy high-performance open-source models with complete legal confidence.