LLM DPA Subprocessors: GDPR, LATAM, and US Compliance

To comply with GDPR, LATAM, and US state privacy laws, contractually bind every LLM subprocessor to your main DPA and maintain a transparent, up-to-date subprocessor schedule. This prevents cloud providers, inference hosts, and data annotators from training on your data or bypassing your security controls.

When you send prompts through an API, that data can pass through multiple downstream providers before a response returns via chat completions, and each hop creates compliance exposure. A typical LLM inference chain looks like: customer application → SaaS integrator → LLM API gateway → underlying inference provider → GPU host. Every layer is a separate legal entity that processes controller data, and each must be disclosed in the subprocessor schedule with its function, location, and retention defaults documented in writing.

GDPR Article 28 Subprocessor Requirements

GDPR Article 28↗ mandates controller approval for subprocessors. Vendors must notify you of new providers and allow a meaningful objection window. Under general authorization, vendors must provide 30 days’ notice before adding a subprocessor.

Flow down identical data protection obligations to every subprocessor in writing. Lock down processing scope, duration, data types, and controller rights. The processor must act solely on documented controller instructions, including for third-country transfers. OpenAI’s published DPA↗ is a useful market reference: it limits subprocessor work to what is strictly necessary and binds each downstream entity to equivalent terms.

For an LLM vendor, explicitly state they act only as an inference processor. Determining purposes or means of processing shifts them to controller status. EDPB Opinion 28/2024 on AI models reinforces this analysis: when a provider exercises substantive discretion over training data or model behavior, regulators may treat them as a joint controller rather than a pure processor.

Demand an explicit no-training guarantee. Controller data, including prompts, outputs, embeddings, logs, and derivatives, must not be used to train, fine-tune, or improve models without separate written authorization. Require model improvement features disabled by default.

Set a default of zero retention or stateless processing for prompts and outputs. Retain only narrowly defined technical logs for security or billing. Specify exact categories, purpose, retention periods, and deletion methods.

Article 28 also requires processors to submit to audits. Grant the controller a right to review independent security documentation, pen-test summaries, and ISO 27001 or SOC 2 reports. Breach notification must reach the controller without undue delay to preserve the 72-hour regulator deadline under Article 33↗. Require notice within 24 hours of awareness.

LATAM Subprocessor and Transfer Controls

LATAM privacy laws add jurisdiction-specific requirements on top of GDPR Article 28 baselines. Compliance teams typically add clauses addressing statutory roles, authority interaction, and localization mechanics.

Brazil’s LGPD Art. 39↗ treats the vendor as an operator bound to controller instructions and detailed processing records for the ANPD. DPA clauses cover instructions-only processing, security measures, breach cooperation, audit records, and subprocessor control.

Mexico’s LFPDPPP Article 53 bars service providers from independent data use and requires documented instructions. Mexico-focused clauses add no-training restrictions, deletion obligations, cross-border transfer language, and incident support.

Colombia’s Law 1581↗ distinguishes data transfer from transmission, requiring clear legal bases for each movement. Additions include authorization language, purpose limitation, subprocessor approval, and local compliance support.

Argentina requires vendors to fit local lawful processing and cross-border transfer constraints, often including filing references and transfer safeguards. Chile is moving toward a GDPR-style accountability model, so DPAs include explicit processing limits, transfer restrictions, and reform-readiness language.

Across the region, non-GDPR clauses cover local authority notification workflows, country-specific transfer mechanics, local contact points, registry support, language-of-contract requirements, AI use restrictions, and breach timelines aligned to local law.

US State Privacy Laws and LLM Vendor Chains

Treat the LLM API inference chain as disclosed subprocessors, hard-limited to documented purposes with explicit no-training and no-combining restrictions for California data.

Cal. Civ. Code § 1798.140(ag)↗ mandates a written service provider contract restricting processing to the specific business purpose. It prohibits selling, sharing, or combining customer data with other sources except in narrow statutory exceptions. A compliant DPA clause tracks this directly: the vendor processes data only on documented instructions, will not sell or share it, and will not retain or use it for any other purpose.

For multi-layer chains, disclose each layer as a subprocessor with its role, data categories, transfer limits, and training permissions. A schedule listing entity name, function, location, retention, and training default is the cleanest format. Require downstream providers to be bound by written terms at least as protective as the main DPA.

States like Colorado, Virginia, Connecticut, Texas, Oregon, and New Jersey use analogous frameworks requiring instructions, confidentiality, and subprocessor controls. Connecticut specifically mandates explicit disclosure when personal data is used to train large language models, making explicit training restrictions critical for any vendor handling Connecticut data. Texas TDPSA and Oregon OCPA add their own breach-notification timelines that need to be reflected in vendor incident-response clauses.

Address caching and temporary storage explicitly, since rate limits and security controls dictate data buffering during high-volume inference.

Drafting the Subprocessor Schedule for LLM Inference

Build your subprocessor schedule to map every entity in your inference chain. Use a table with columns for entity name, function, data categories, location, subprocessor status, international transfer, retention, and training default. Set retention to zero or stateless processing for every prompt and output. Mark the training default as prohibited, with separate written authorization required for any model improvements.

Pass GDPR Article 28 obligations down to each subprocessor. Datadog’s DPA↗ mandates written agreements with downstream providers and 30 days’ notice before adding new entities. Verify that every row in your schedule matches the actual data flow across your infrastructure, including regional routing decisions for audio, speech, or reranking endpoints that may use different data centers.

Pay close attention to how third-party tool calling or function execution routes data. If your application uses external APIs to enrich prompts, those external endpoints are subprocessors by definition and must appear in your schedule with verified data handling policies, especially when using tools and function calling.

Audit, Transfer, and Termination Clauses

Add a clause stating the vendor processes data only on documented instructions. Limit international transfers to jurisdictions with adequacy decisions or valid Standard Contractual Clauses, and require an annex listing every transfer mechanism in use. Require deletion of all derived artifacts and embeddings at contract end, including vector stores, cached prompts, and any fine-tuning checkpoints derived from controller data.

If the vendor cannot offer true zero retention, the DPA should distinguish between ephemeral inference memory and persistent logs, and require deletion after a short, defined period tied to the operational need. Three to thirty days is typical for security or abuse-monitoring logs; longer windows should be explicitly justified.

For multi-layer chains, add a subprocessor authorization paragraph such as: “Customer authorizes Service Provider to engage the subprocessors identified in Schedule A, including model and API providers and underlying infrastructure providers, solely to the extent necessary to provide the Services. Each subprocessor must be bound by written terms imposing data use, confidentiality, security, retention, and training restrictions no less protective than this Addendum.” This pattern fits the service provider or processor model described in state law summaries and reflects current enforcement focus on actual contract language.

Tessera serves open-source models including Qwen3.6-35B-A3B on EU and LATAM dedicated GPUs through an OpenAI-compatible API. The flat-rate model means no metered data-flow that complicates retention accounting, and the subprocessor chain stays inside the contracted jurisdictions for teams in the US, EU, and LATAM that need region-locked inference.

FAQ

Do I need to sign a separate DPA with every LLM subprocessor?

No. Your main vendor contract is the only legal link you need. The vendor passes equivalent obligations down to each subprocessor through their own written agreements.

How do I handle LLM subprocessors under Brazil’s LGPD?

Brazil’s LGPD↗ requires the operator to follow controller instructions and maintain detailed processing records. Your DPA needs incident cooperation and ANPD notification workflows, plus subprocessor control and local contact-point support.

What is the standard notice period for adding an LLM subprocessor?

Expect at least 30 days’ written notice before a new subprocessor starts processing. That window gives you time to object under GDPR Article 28. The safest wording requires prior notice, a defined objection window, and a right to terminate if the objection cannot be resolved.

How do US state laws affect LLM vendor contracting?

California requires a written service provider contract that strictly limits data use, prohibits selling or sharing, and bars combining customer data. Colorado, Virginia, and Connecticut follow similar frameworks; Connecticut additionally requires disclosure when personal data is used to train large language models.

Can an LLM vendor use my prompts to improve their models, and what if a subprocessor breaches the DPA?

Only with separate, specific written authorization; the current market default is hard no-training. If a subprocessor violates the DPA, the primary vendor remains fully liable, must remediate immediately, notify you in writing, and provide a corrective plan, and you retain a right to terminate if the violation cannot be resolved within the cure period.