The value​​​ ​​​chain of general-purpose AI​​

General-purpose AI (GPAI)¹ ​models​ are designed for generality of output and have a wide range of possible applications. Sometimes called​ foundation models, ​they​ can be used ​in​ standalone systems or as the ‘building block’ of hundreds² of single-purpose AI systems to accomplish a range of distinct tasks, such as sector-specific analytic services, e-commerce chatbots or ​​design​ing custom curriculum​.³ 

Many believe that GPAI represents a paradigm shift from traditional, single-purpose AI. Rather than having to build an AI system to carry out a specific task from scratch, cutting-edge GPAI – such as that developed by ‘upstream’ providers Meta, Microsoft and its partner OpenAI, and Alphabet with its Google Brain team and subsidiary DeepMind – offers the infrastructure that traditionally ​less ​technical ‘downstream’ companies can leverage to realise many different user-facing applications.  

This class of AI technology​​ and the relations among providers and users it implies create non-trivial issues for legislators. We can already see these tensions at play in the context of the EU AI Act – the first horizontal AI governance regime, which is likely to be followed by others in other jurisdictions – which tries to regulate AI mostly as a tangible product with limited intended purposes. 

The key characteristics of GPAI ​​​models​ are their ​large size (due to the extensive number of​​ parameters​ they use, i.e. the numerical values defining the model),⁴ their opacity (the fact that the computational mechanisms through which they output information are hard to explain) and their potential to develop unexpected capabilities beyond those intended by their producers. Delivering a GPAI ​model​ requires substantial amounts of data, computing power, some of the most talented researchers and engineers and – consequently – extensive financial resources.  

The resource-intensive character of GPAI development contributes to establishing an interdependence between GPAI providers (upstream) and the companies applying these models to end user-facing applications (downstream). This relation makes the lifecycle of a GPAI model complex and reliant on a variety of actors, who are each responsible for different components of the same process.  

This is further complicated because relationships between upstream and downstream companies, and the level of control different actors have over the GPAI model, change according to the strategy that upstream GPAI providers adopt to distribute their model and place it on the market (currently as open-source software or via application programming interfaces (APIs) for the most part), i.e. their way of generating value and monetising the GPAI model.  

The complex dependencies between companies developing and companies deploying GPAI, the multi-functionality of the models and the entanglements between these two factors and the release strategies used by upstream providers pose unique challenges for AI governance. To assign the right responsibilities to the best equipped actor, it will be necessary to have a deep understanding of how GPAI accrues value over its various development ​and deployment ​stages – in other words, its ​value chain. 

As the EU co-legislators are still negotiating the​​ AI Act, we look at the two most common GPAI market release strategies and their implications for the development and use of GPAI and its regulation.  

​API and open-source access to GPAI ​​dictate the​ level of control different actors have over the model

There are two main ways GPAI systems ​and​ their underlying models are currently made accessible to downstream developers on the market: via API and open-source access.  

Here we analyse the two routes separately but acknowledge that in reality they tend ​to blur,⁵ not least because models ​or parts of models, ​initially ​made accessible​ via API by one GPAI provider, are often imitated and made available as open-source by another one. 

Downstream developers can access a GPAI model through an API, which is controlled by the GPAI provider. They can use the model, including adapting it to use-case specific AI applications, without needing to understand its underlying technical details. In this route, the GPAI model is developed by the provider and run remotely on its servers, with a continuous interaction transferring the input and output from and to the downstream user online.  

Two prominent examples of GPAI ​models distributed ​via API are OpenAI’s GPT-3.5 (and its user-facing ​​​system​, ChatGPT) and DALL-E. The key feature of this strategy is that control over the model and source code remains largely in the hands of the provider. 

​​Open-source access refers instead to releasing the model or some elements of it publicly and allowing anyone to download, modify and distribute it, under the terms of permissive licences. In this case, only a one-off interaction between the GPAI provider and the downstream developers is needed. The GPAI provider uploads the model’s elements onto a platform or repository, providing technical documentation and any usage instruction required, and the downstream developer downloads the files. ​​​ 

Stability AI and Runway​ML​ adopted this release strategy with Stable Diffusion​,​ a noteworthy example as the model in question is very similar to OpenAI’s aforementioned (API-provided) DALL-E.⁶

Computing power plays an important role in how easily a GPAI model can be used in a meaningful way. API access is usually combined with access to the necessary computational infrastructure​.​ ​However, ​to use open-source GPAI, downstream developers need to already have separate access to such infrastructure. As computing power is expensive and scarce, this can be a barrier to modifying or even loading the model.  

​​In terms of business models, both release and distribution strategies enable GPAI providers to monetise their models. Those releasing them through APIs can gain direct revenue by charging a subscription fee to access the model over time or on a per-use basis. Open-source providers can instead monetise their GPAI models ​mainly​​ ​indirectly. For example, they can charge downstream actors for easy access to the necessary compute infrastructure (​hosting​) and to premium or enhanced versions of the models (​open-core​) or for other services such as fine-tuning, maintenance or customer support services (​consulting and support model​). ​​​     ​​ 

​Open-sourcing a GPAI model can also be a strategic decision for attracting ​attention from the broader research community, media and downstream industry. GPAI providers may benefit from reputational value through increased visibility, attracting partnerships and investments, and establishing a pool of talented researchers trained on and demanding their models​. Clearly, as OpenAI’s ChatGPT has shown, ​​s​uch indirect benefits can also arise from API release strategies​.​​ 

In terms of who, in the GPAI model lifecycle, is responsible for doing what, ​t​he upstream ​GPAI ​provider usually researches, designs, develops and pre-trains the model on data and sometimes produces use-agnostic risk management and quality controls. It then determines the release and pricing structure​ of the GPAI model.​

Releasing the model through an API means that the provider can set the conditions for access, respond to downstream misuse and constantly improve their model and commercial strategy, through analysing downstream use,​​​ ​without losing intellectual property rights. If the provider releases the model as open-source software, ​it​ loses control over the downstream use and can only leverage indirect ways of monetisation. However, ​it​​ ​can incorporate into the original model new functionalities developed downstream in the open-source environment.  

From the perspective of downstream actors, who produce simpler AI applications by adapting a GPAI model, they can decide on the specific use for a model and the training data to fine-tune it. They can also choose to provide risk and quality management in the specific context of use. If they access the model via API, they potentially face constraints on the evaluation or retraining of the model’s functions.⁷ Instead, with an open-source model, they can directly examine the parameter values according to which it has been originally trained by the provider and change them.  

Table 1: common business practices associated with API and open-source release strategies for GPAI⁸

The choice between API or open-source release strategies has divergent implications for accessibility and accountability. API-mediated access could offer more guardrails to reduce the proliferation of harmful content, however, it centralises the control on GPAI models in the hands of the most powerful actors in the value chain.  

Open-source releases, instead, have been seen as the means to make access to and control of GPAI models (and their outcomes) more equitable, as a broader community c​an study a model, adapt it or improve it​. However, the lack of guardrails in open-source releases has already led to the proliferation of sexist and racist outputs and lawsuits over the use of copyrighted images.  

The implications of release strategies therefore represent a difficult trade-off and may be a reason why leading AI labs have simply decided to keep ​some of ​their models private​. For example,​ DeepMind ha​s​ released only research documents about their GPAI model​ MuZero​ together with the pseudocode (a partial, non-functional version of the code), rather than the model itself. 

Clearly, ​many​​ ​issues of safety-control on end user-facing services, accountability and equitable access could be addressed via legislation. The question is how to do so effectively. 

The task is especially complicated because, while the debate in the policy community has focused on the two release strategies of API and open-source, the monetisation of GPAI remains in its infancy. Other business models, transforming GPAI and GPAI-related services into economic value, already exist. Even if it is unclear how much they will be used in the future, ​their wide array indicates that we should future-proof policy by making it adaptable or, better yet, completely independent from GPAI release strategies.​ 

Table 2: potential business practices and GPAI release strategies other than API-accessible and open-source

Future-proofing policy for GPAI: five key challenges to address  

GPAI and their release strategies pose a unique challenge for policymakers setting an AI governance regime. This is most visible in the EU AI Act, which is currently being ​negotiated​, for three primary reasons.  

• ​​​Complexity of the value chain: ​the AI Act is designed to regulate tangible products placed on the EU market, a description that hardly applies to GPAI models. Indeed, ​the assignment of duties and liability is much more difficult to establish in the case of GPAI than ​the AI ​​A​​ct implies​. This is due to the number of players in the value chain, the disparate levels of control, based on ​the ​release ​and access​ strategy, and the ​model’s​ ability to ​exhibit​ new  throughout its lifecycle. 
• The multi-functionality of GPAI models: ​EU product legislation​, like the AI Act,​ assumes all products have an ‘intended purpose’, however, GPAI models ​by definition have underdetermined purposes.​ 
• The polarity of (current) release strategies: the decision taken by GPAI providers on how to make their model accessible and thus release it on the market – via API or as open-source – determines in disparate ways how risks emerge for users and consumers. Regulating GPAI through a one-size-fits-all regime, such as the AI Act, is highly challenging.  

Understanding these challenges and distilling the key questions that legislators face in the context of the AI Act will foster an informed debate on the regulation of GPAI now and in the future.  

Challenge 1: How should GPAI be defined in the legislation? 

Finding an evidence-based definition that recognises the broad spectrum of ‘generality’ of purpose of this technology is a first key regulatory challenge. Future benchmarking, measurement and metrology efforts in the GPAI domain could help, but a temporary code of conduct might be needed while they mature.  

Challenge 2: How to factor in the various ​incentives​ behind open-source release strategies? 

Similarly, making the distinction between ​open-source​ distribution by grassroot developers volunteering their talent and private companies’ ​open-source​ product release mechanisms​ ​​(​including sophisticated for-profit, monetisation strategies​)​ is another hurdle for policymakers and enforcers. Engaging with open-source communities of the first kind will be key to ensure that this distinction is accurate. 

Challenge 3: What regulatory tools are needed to ensure future-proofed governance of ​GPAI models​?  

As business models develop at exponential speed, policymakers need to future-proof their policies, ​by keeping principles and obligations independent from distribution channels. ​Specifically, they need to ensure design, quality and reliability requirements are the same regardless of how GPAI models are released, to avoid distorting the market. ​Realistically, methods of compliance and ​policy ​enforcement will have to be adapted to different business models to ensure that trustworthiness remains a competitive advantage for AI providers rather than a liability.​ This involves monitoring evolutions in the AI value chain and updating regulatory guidance accordingly.​  

Challenge 4: How can regulators ensure adequate capacity for oversight to deal with the societal-level implications of GPAI models?  

Cutting-edge GPAI models may become fundamental assets in the digital economy, while still being fraught with inherent issues, such as opacity and emerging capabilities. Countering this phenomenon will require strong technical expertise at all levels of government, coordination between leading AI labs and regulators and, possibly, an ‘ecosystem of inspection’¹³ that allows academia and civil society to independently assess GPAI models.  

Challenge 5: How can AI governance incorporate the views of affected persons and impacted communities, so that the benefits of GPAI are equitably distributed?  

As GPAI releases in 2022 have shown, these models are now a matter of public debate. Amid the need for safeguards, the drive for innovation, the protection of privacy and intellectual property rights, the traditional culture of freedom and openness of software communities, the transition towards synthetic art and culture and the oligopolistic interests of bigger companies in this field, AI governance has ​the​ daunting task​ of arbitrating many trade-offs​. ​P​​olicymakers need to find ​​methods​​ to engage​​ ​with the people affected by AI technology, ​including those stakeholders that are traditionally left out of the debate. 

Overall, ensuring trustworthiness along the entire value chain of GPAI and its ​diversified​​​ business models presents significant challenges for policymakers. Future-proofing policies and ensuring compliance and effective enforcement will be crucial in building and maintaining public trust in these technologies, not only in the context of the EU AI Act, but in all jurisdictions aiming at setting a governance regime for AI.

The views presented here are the authors’ own and do not necessarily represent the views of the organisations they work for or are affiliated with. 

If you want to know more about recent developments in AI regulation, you may be interested in our foundational report Rethinking data and rebalancing digital power, our work on the AI Act and the expert opinion on AI liability we commissioned to Christiane Wendehorst.