Joint Controllership Between an AI Vendor and Its Customer

Almost every AI vendor contract says the vendor is a processor. The label is not decisive: controllership is a factual question about who determines purposes and means, and a vendor that uses your prompts for its own ends has determined a purpose whatever the contract calls it. The interesting question is whether that makes it a joint controller with you or an independent one, and the answer changes who owes what to the data subject.

The test the Court actually applies

Article 4(7) defines a controller as the body which, alone or jointly with others, determines the purposes and means of the processing. Article 26(1) makes two or more controllers joint controllers where they jointly determine those purposes and means. Article 28(1) describes a processor as one processing on behalf of the controller, and Article 28(3)(a) requires it to act only on documented instructions.

Three points from the case law shape how that test is applied, and each is counter-intuitive. First, joint controllership does not require equal responsibility: Article 26(1) itself and the Court have both said the involvement of the parties may be at different stages and to different degrees. Second, it does not require access to the data — a party can be a joint controller for processing it never sees. Third, responsibility is scoped to the stage of processing for which the party actually determines purposes and means; being a joint controller for collection does not make you a controller for everything the other party does afterwards.

Wirtschaftsakademie and Fashion ID

In Case C-210/16, Wirtschaftsakademie Schleswig-Holstein, judgment of 5 June 2018, the Court held that the administrator of a Facebook fan page was a controller jointly with Facebook for the processing of visitors’ data, even though the administrator received only anonymous statistics and had no access to the underlying personal data. What made it a controller was that it took part in determining the purposes and means by setting the parameters of the audience statistics it wanted. The docket is at curia.europa.eu for C-210/16.

In Case C-40/17, Fashion ID, judgment of 29 July 2019, the Court applied the same reasoning to a website embedding a social plugin and then drew the boundary that matters most here: the website operator was a joint controller for the collection and transmission of visitor data to the plugin provider, because it enabled and benefited from those operations — but it was not a controller for the subsequent processing carried out by the provider alone, over which it had no influence. See curia.europa.eu for C-40/17.

Read together, the two cases give a workable frame: joint controllership attaches where the parties’ decisions converge on a common operation and both pursue purposes served by it, and it stops at the edge of the operation each actually influences. The EDPB built its Guidelines 07/2020 on the concepts of controller and processor around the same distinction, describing joint participation as arising from a common decision or from converging decisions that are complementary and necessary to each other; the guidelines are published at the EDPB’s document register.

Article 28(10): the trigger for AI vendors

The provision that decides most AI vendor questions is not Article 26 at all. Article 28(10) says that if a processor infringes the Regulation by determining the purposes and means of processing, it shall be considered a controller in respect of that processing. That is a self-executing reclassification. It does not require a supervisory authority to find it, and it does not care what the DPA says.

For a model vendor, the events that pull Article 28(10) are specific and identifiable:

• Using customer prompts or outputs to train or improve its own models. This is the clearest case. The purpose — improving a product the vendor sells to everyone — is the vendor’s, not the customer’s, and no instruction from the customer creates it.
• Retaining content for abuse monitoring on its own initiative. Harder. The vendor may argue this is necessary to provide the service and is therefore within its instructions; a regulator may see a vendor pursuing its own safety and liability interest. Where the retention is imposed on the customer rather than configurable by it, the second reading gets stronger.
• Deciding, without instruction, which upstream model serves a request. Routing is arguably a means rather than a purpose, and Article 28 permits a processor to determine non-essential means. The line between essential and non-essential means is exactly where this argument lives.
• Reusing content for benchmarking, research or publication. An independent purpose on any reading.

The consequence of Article 28(10) is not merely a relabelling. A vendor that has become a controller for that slice of processing owes the data subject its own Article 13 or 14 information, needs its own Article 6 lawful basis for it, and is directly exposed under Article 82. The customer, meanwhile, has disclosed personal data to a controller — which is a disclosure that needed a basis and a notice of its own.

What is genuinely unresolved

It would be comfortable to say the answer follows mechanically. It does not, and the honest position has three open questions in it.

The first is whether a vendor that reuses customer data for training becomes a joint controller with the customer or a separate controller. Fashion ID suggests the latter for downstream processing the customer cannot influence, and the EDPB’s converging-decisions test suggests the parties are not pursuing a common operation at that stage. But the customer did enable the transmission, which is precisely the operation Fashion ID found joint. The distinction is not academic: joint controllers must have an Article 26 arrangement and a data subject can exercise rights against either of them under Article 26(3), while separate controllers each answer only for their own processing. There is no Court of Justice ruling on this configuration for AI vendors at the time of writing, and what would settle it is either a preliminary reference or a reasoned supervisory authority decision on a specific vendor.

The second is how far a vendor can determine means before it stops being a processor. The EDPB draws the line at essential versus non-essential means, with the type of data processed, the duration of retention and the recipients treated as essential. Model selection, quantisation, caching strategy and inference region are not obviously on either side of that line, and reasonable regulators could differ.

The third is whether abuse-monitoring retention imposed by the vendor as a non-negotiable term is instruction or independent purpose. Vendors argue it is inherent to lawful service provision. The counter-argument is that a term the customer cannot switch off is by definition not the customer’s instruction. This one is likely to be resolved by enforcement rather than by contract drafting.

If you are joint controllers

Article 26(1) requires joint controllers to determine their respective responsibilities for compliance in a transparent manner by means of an arrangement between them, in particular as regards the exercise of data subject rights and the Article 13 and 14 information duties. Article 26(2) requires the arrangement to reflect the parties’ respective roles and relationships with data subjects, and the essence of it must be made available to the data subject. Article 26(3) then removes the practical benefit of careful allocation: the data subject may exercise rights against each controller, irrespective of the terms of the arrangement.

That last point is why joint controllership is worth avoiding where it can honestly be avoided. The route to avoiding it is not a clause asserting processor status — Article 28(10) ignores assertions. It is contractual terms that remove the vendor’s independent purposes: an express prohibition on training use, a bounded and configurable retention window, and a named list of upstream recipients. Those are exactly the clauses set out in DPA clauses specific to AI sub-processing, and the disclosure side is in sub-processor disclosure obligations for AI vendors. Note that this GDPR role question is separate from, and does not determine, the AI Act’s provider-and-deployer split — the same company can be a GDPR processor and an AI Act provider at once, as provider versus deployer sets out.