ICO consults on controllership across the GenAI supply chain
In contrast to the EU’s approach of implementing uniform, specific, AI legislation, the UK has taken a more sector-specific approach with a number of different regulators grappling with the emerging issues from their own perspective.
As part of this, the ICO has conducted an ongoing consultation on AI-related issues over the last six months. Topics covered to date have been:
the lawful basis for web scraping to train generative AI models;
the purpose limitation in the GenAI lifecycle (i.e. is the processing carried out when training a model compatible with the purpose for which the personal data was originally collected?);
the accuracy of training data and model outputs; and
engineering individual rights into generative AI models.
The fifth and final consultation (Generative AI fifth call for evidence: allocating controllership across the generative AI supply chain, open until 18 September 2024) explores allocating “controllership” across the GenAI supply chain. The consultation is both a call for evidence, a summary of its current analysis and a consultation on its proposed policy positions. Accordingly, it gives a helpful snapshot into the ICO’s current thinking on this topic.
Background
Generally, organisations can play one of two roles under the UK GDPR:
controllers, which determine how and why personal data is processed. Controllers may act individually or as with another controller as joint controllers; and
processors, which process personal data on behalf of a controller in line with the controller’s written instructions. Processors cannot make overarching decisions about processing, but may make more day-to-day operational decisions.
For the purposes of determining an organisation’s responsibilities under UK GDPR; the appropriate provisions to include in their contracts; and the approach to data protection compliance that they need to take, in respect of any processing that they are undertaking, it is crucial to understand whether they will be a controller, joint controller or processor.
ICO’s current analysis
The ICO distinguishes between:
the AI lifecycle – i.e. the pre-training, fine-tuning and deployment of a model along with the creation and maintenance of that model; and
the AI supply chain, which includes the AI lifecycle plus all the other activities involved in creating and delivering new applications and services using the models developed as part of the AI lifecycle.
The ICO notes that it is seeing increasing interdependencies between the various entities in the supply chain and emphasises that they need to consider carefully whether they are a controller, joint controller or processor (and, therefore, the responsibilities that they have) and then document their analysis appropriately (e.g. in records of processing activities and data protection impact assessments).
It considers that organisations developing base generative AI models to provide as a product or service will be controllers for the development-related processing and where they deploy their model themselves.
However, if an organisation deploys a model that a developer has made available, there may be three possibilities for its status:
the developer and deployer may be joint controllers, if they have both been involved in determining how and why the processing has been designed and executed;
the developer may just be a processor, if the deployer’s role has been so influential that it has determined both the purposes and means of the processing and has enough information to be able to assess compliance with data protection law; or
the developer plays no role in processing – it has merely produced an application, product or service that the deployer decides to use in its processing activities.
The ICO considers that the way in which many developers are offering third parties access to their models means that it is difficult for deployers to understand and have meaningful control and influence the processing. Accordingly:
substantial overarching decisions about the means of the processing at the development stage can pre-determine processing during deployment; and
deployment risks may not be effectively identified or managed by the deployer.
As a result, the ICO recommends deployers consider:
obtaining sufficient information from the developer to make informed decisions about processing and compliance; and
treating the developer as a controller or joint controller, which will have important impacts on the contractual provisions used.
In its conclusion, the ICO notes that many players in the market have sought to frame their processing relationships as one of controller and processor, where in fact joint controllership may more accurately reflect the parties’ roles. Whilst it carries out its consultation, it urges AI developers to examine joint controllership approaches when considering their relationship with this third parties.
If developers do not heed the ICO’s request, then it is likely that the question will be resolved between the ICO and the developers, as controllership generally puts a greater regulatory burden on an organisation than if it was a processor.
However, given the ICO’s comments, if developers insist on transaction documentation that continues to be on a controller-processor basis, then that potentially puts deployers in a difficult position.
As is always the case, this will be a matter of the bargaining power of the parties and an assessment of the specifics and risks of any particular deployment. It will certainly be important to follow the ICO’s developing guidance on this point.