Allocating controllership across the generative AI supply chain

Respondents

In August 2024, we published the fifth chapter of our consultation series. This set out a policy position on allocating controllership across the generative AI supply chain.

We received 16 responses from organisations, with one respondent identifying as a member of the public. Seven responses came via our survey, with a further nine received directly via email. In contrast to previous calls, the technology sector (five) was the most represented. There was just one creative industry response. Industry groups (four) and law firms (two) were the next most represented.  

Of the survey respondents, five (71%) agreed with our initial analysis.

Original call for evidence

In our original call for evidence,⁵⁷ we set out our positions on controllership and generative AI. To recap those positions were as follows:

Firstly, we said that a contract does not necessarily determine whether an organisation is a controller, joint controller or processor. Instead, this is determined by the practical realities of the processing. In generative AI, the roles of ‘developers’ and ‘deployers’ don’t always neatly map onto the concepts of controllers and processors. Roles and responsibilities under data protection law are also not determined by other legal regimes, such as intellectual property or competition law.

Secondly, the allocation of controller, joint controller or processor roles must reflect the actual levels of control and influence over the purposes and means of each different processing activity taking place. We emphasised the importance of this in complex supply chains such as generative AI.

Thirdly, we set out that the relationship between developers and third-party deployers towards the “closed-source” end of the generative AI model release spectrum will mean that there are often shared objectives and influence from both parties for the processing. Joint controllership, instead of a processor-controller arrangement, may be more likely. 

Finally, we set out that, based on a lot of current practices in “closed access” scenarios, it is unlikely that such developers can claim to be processors at the deployment stage. This is because the generative AI developer is likely to influence overarching decisions (such as the training data, model architecture, risk mitigations and model distribution) that predetermine how data will be processed during deployment. This means that joint controllership remains likely.

Key points from the responses

On determining means and purposes for models closer to the “closed-access” end of the model access spectrum:

• There was clear recognition from all respondents that the varying degrees of control and influence at each stage of processing activity are key factors. These make allocating controllership a challenging task. 
• Generative AI developers accept they are controllers for the development stage of models, but do not want to accept controllership responsibility for downstream deployment of their models. One generative AI developer stated that, in some cases, they may consider themselves a processor if they are acting on instructions from a third party. 
• The prevailing argument from the technology sector and trade membership bodies is that generative AI developers do not exert a sufficient degree of control or influence over the purposes or means at the deployment phase to be considered controllers or joint controllers for this phase. Instead, they stated that they are processors. 

On joint controllership for “closed-access” models:

• Both an industry body and the respondents from the technology sector (including two generative AI developers) agreed that, in some scenarios, they may be joint controllers. However, they argued that in most cases, deployers determine entirely separate purposes for processing personal data (eg when fine-tuning a model). Therefore, they consider themselves a separate controller. 
• One industry and trade membership body raised that, in joint controllership scenarios, there is potential for one party to hold a dominant negotiating position. They may unfairly push obligations onto the other party. They also raised that, as a complex arrangement, it may cause delays in responding to subject access requests. 
• One technology company argued that joint controllership does not improve legal certainty or accountability. Instead, they argued it created confusion. They advocated for clear contracts setting out defined roles and liabilities as a preferred solution. 

Our response

We understand that allocating accountability in complex supply chains such as generative AI may be more challenging than in simpler contexts. This is why, in the call for evidence, we welcomed real-life evidence on the complex decisions deployers and developers make when allocating accountability. Based on the evidence we received, we maintain our consultation position and continue to engage with the sector where they have queries. 

Generative AI developers’ overarching decisions may influence how a model operates at the deployment stage. As a result, there is a risk that deployers of “closed-access” models do not have meaningful control and influence over all the processing at deployment. In such circumstances, when considering the role of the parties in the processing, it will be important to consider what information the deployer has and the level of control that the developer provides. Joint controllership is more likely where both parties retain shared objectives or influence during the deployment stage.

There was also some stakeholder confusion around what joint controllership entails. It does not mean that both parties have joint and equal responsibility. A joint controllership agreement sets out what each party is responsible for. This means that they do not have to have joint responsibility for everything involved in the processing. This is a fact-based assessment. Any other contracts that are set up between developers and deployers will not override the fact-based assessment that determines controllership.

Many respondents asked us to provide further practical examples of processing activities that clearly demonstrate examples of controllership, to help organisations understand their roles. We welcome further engagement with stakeholders on this issue, given the different contexts and variety of processing activities.

Some respondents suggested that developers could be processors when they use a deployer's data to improve their own models, because the deployers would benefit from the improvement. We do not accept this argument. It contradicts our established position that if a developer is processing data for their own purposes, they are a controller for that processing. The fact that clients may also benefit is not enough to make them the sole controller for all processing.

---

57 Generative AI fifth call for evidence: allocating controllership across the generative AI supply chain