Policy Significance Statement

This commentary proposes a framework that identifies decision-making layers leading to an organisational archetype for governance in federated learning. What type of entity controls the server in such systems and orchestrates clients is a pending question that hinders adoption. The proposed framework allows for the ex-ante selection of the appropriate organisation for each setting. We apply the framework on the basis of real-world applications.

2. Background

In FL, the peculiarity is that while training takes place at the edges, a central orchestrating entity is still present. The presence of that entity has technical and organisational implications.

In technical terms, the orchestrator is responsible for the central server, or rather the training process, which aggregates updates from decentralised clients that locally process data, and then distributes the combined model back to these clients. Thus, the orchestrator will receive the model trained by the clients (or the delta) from the previous iteration and aggregate it before transmitting it back to the clients (McMahan et al., Reference McMahan, Moore, Ramage, Hampson and y Arcas2017).Footnote ² Consequently, the orchestrator plays a crucial role, as it ensures the integration of diverse, local insights into a global model without directly sharing or aggregating data. Doing so requires data curation, standardisation of reference labels, and the formalisation of workflows, among othersFootnote ³. Furthermore, the orchestrator is also responsible for the aggregation mechanism, is in control of the update schedule, and handles security and privacy aspects (Yin et al., Reference Yin, Zhu and Hu2021). Thereby, it holds the capability to affect the accuracy, bias, and overall integrity of the system. The organisation governing the central server wields significant power (Pati et al., Reference Pati, Baid, Edwards, Sheller, Wang, Reina, Foley, Gruzdev, Karkada, Davatzikos, Sako, Ghodasara, Bilello, Mohan, Vollmuth, Brugnara, Preetha, Sahm and Maier-Hein2022; Bujotzek et al., Reference Bujotzek, Akünal, Denner, Neher, Zenk, Frodl, Jaiswal, Kim, Krekiehn, Nickel, Ruppel, Both, Döllinger, Opitz, Persigehl, Kleesiek, Penzkofer, Maier-Hein, Bucher and Braren2024).

From an organisational perspective, in the case that FL is collaborative and outside of the boundaries of a single organisation (as is the case in, e.g., applications in healthcare under a consortium; Pati et al., Reference Pati, Baid, Edwards, Sheller, Wang, Reina, Foley, Gruzdev, Karkada, Davatzikos, Sako, Ghodasara, Bilello, Mohan, Vollmuth, Brugnara, Preetha, Sahm and Maier-Hein2022), the “structure” acting as the orchestrator must be trustworthy. This organisation—beyond technical tasks described previously—is also tasked with aligning participating clients to a set of agreed-upon rules and contracts, settling disputes, and ensuring the financial sustainability of the collaboration. These points each consider the “locus of accountability”—that is, here, some type of organisation, the one “who makes the decision” (Khatri & Brown, Reference Khatri and Brown2010). All participants must trust this accountable organisation before any collaboration and sharing of assets occur (Berente et al., Reference Berente, Gu, Recker and Santhanam2021; Pati et al., Reference Pati, Baid, Edwards, Sheller, Wang, Reina, Foley, Gruzdev, Karkada, Davatzikos, Sako, Ghodasara, Bilello, Mohan, Vollmuth, Brugnara, Preetha, Sahm and Maier-Hein2022; Bujotzek et al., Reference Bujotzek, Akünal, Denner, Neher, Zenk, Frodl, Jaiswal, Kim, Krekiehn, Nickel, Ruppel, Both, Döllinger, Opitz, Persigehl, Kleesiek, Penzkofer, Maier-Hein, Bucher and Braren2024). This is essential in order to create an environment where all parties are willing to collaborate in the short term, and benefit from shared insights or financial gains in the long term. An alternative case is when FL is deployed inside the boundaries of an accountable organisation, in which case governance is done in-house (see, e.g., Hard et al., Reference Hard, Rao, Mathews, Ramaswamy, Beaufays, Augenstein, Eichner, Kiddon and Ramage2018).

At last, it is noteworthy that the organisational structure for governance must be designed according to the context in which FL is trained. Technology governance is never a one-size-fits-all and depends on the asset plus organisational structure at hand (Brown & Grant, Reference Brown and Grant2005; Weber et al., Reference Weber, Otto and Österle2009; Khatri & Brown, Reference Khatri and Brown2010). In the case of training FL across devices by a single organisation, governance typically happens in-house (see McMahan et al., Reference McMahan, Moore, Ramage, Hampson and y Arcas2017; Hard et al., Reference Hard, Rao, Mathews, Ramaswamy, Beaufays, Augenstein, Eichner, Kiddon and Ramage2018). When between organisations, in a non-competitive and research-centric market for data, a consortium might be the right fit (see Mateus et al., Reference Mateus, Moonen, Beran, Jaarsma, van der Landen, Heuvelink, Birhanu, Harms, Bron, Wolters, Cats, Mei, Oomens, Jansen, Schram, Dekker and Bermejo2024). Alternatively, a single party—such as a university or non-profit—could be trusted to act altruistically as a third party and reap shared rewards (see Pati et al., Reference Pati, Baid, Edwards, Sheller, Wang, Reina, Foley, Gruzdev, Karkada, Davatzikos, Sako, Ghodasara, Bilello, Mohan, Vollmuth, Brugnara, Preetha, Sahm and Maier-Hein2022).

Taking past understandings on designing data governance and decision domains (Khatri & Brown, Reference Khatri and Brown2010), we formulate a set of non-exhaustive questions related to and informing model governance (see Table 1).Footnote ⁴ They are categorised in terms of decision domains appropriated from governance literature. Formally, Weill and Ross (Reference Weill and Ross2004) propose that IT governance design includes five major decision domains—principles, architecture, infrastructure, application needs, and investment and prioritisation. Khatri and Brown (Reference Khatri and Brown2010) adapt these to data governance to consider principles, quality, metadata, access, and the life cycle. We adhere to and adapt the latter as we consider data to be the core asset.

Table 1.

Decision domains and questions tailored to FL governance, based on Khatri and Brown (Reference Khatri and Brown2010)

^a The questions formulated by domain are non-exhaustive.

^b Privacy enhancing techniques (see Yin et al., Reference Yin, Zhu and Hu2021).

The practical orientation of this article compels us to consider the framing of governance by Pati et al. (Reference Pati, Baid, Edwards, Sheller, Wang, Reina, Foley, Gruzdev, Karkada, Davatzikos, Sako, Ghodasara, Bilello, Mohan, Vollmuth, Brugnara, Preetha, Sahm and Maier-Hein2022). Their study presents results from training an FL model for tumour detection involving data from 71 sites across 6 continents. Here, governance is referred to as (1) the definition of the problem statement and (2) the coordination with the collaborating sites. In consideration of this framing, the scope of this commentary is on the latter: the coordination (i.e., model governance) with collaborators. The goal of this commentary is to advance understanding of the common layers leading to an organisational archetype for the governance of FL. After delineating assumptions, describing our inductive approach, we propose the framework and its layers. At last, we apply the model to real-world cases.

3. Towards a framework of common layers

3.3. Layered framework

The result of this process of information gathering and iteration is the formulation of a conceptual framework of common layers to derive organisational archetypes for the governance of FL (Figure 1). The three common layers at play when deciding upon the locus of accountability and corresponding organisational archetype are (1) the nature of the data market (spectrum of collaborative–competitive), (2) the FL model’s architecture (spectrum of centralised–decentralised), and (3) the model’s ownership (spectrum of proprietary–shared). The result is archetypes.

Figure 1.

A layered framework to derive organisational archetypes for the governance of FL. The line represents the virtual decision-making process throughout each of the layers, resulting in a selected archetype.

While in no order of priority, there is a temporal element to these layers such that the initial consideration is done with regard to the market, followed by architectural design choices, and, at last, the definition of the ownership structure. We subsequently discuss each of the three common layers individually. Thereafter, we put forward a set of non-exhaustive questions to help decide on the archetype.

3.3.1. Data market

First, stakeholders must evaluate the data market in which they are operating. There are four types of data markets: many-to-many, one-to-many, many-to-one, and one-to-one (Driessen et al., Reference Driessen, Monsieur and Van Den2022). However, in stylised economic terms, we can simplify markets for data and place them on a spectrum between competitive and collaborative markets (Fernández, Reference Fernández2023). Competitive markets are characterised by organisations that guard their data closely to maintain a competitive edge. Legal restrictions and other market pressures also play a role in the limits of data sharing. Organisations will avoid sharing data that could potentially benefit their rivals, as their competitive advantage hinges on exclusive access to valuable data resources (Kearns & Lederer, Reference Kearns and Lederer2004).

However, organisations have begun to shift towards collaborative business models and technologies to maximise returns. At once, data markets can be “inherently” collaborative such that organisations actively work together to share data, research on projects, and reap mutual benefits (Spiekermann, Reference Spiekermann2019). Examples include hospitals and research centres collaborating to create comprehensive datasets for better patient care.Footnote ⁵ Other organisations, such as banks and insurance companies, will traditionally compete, although they will look to collaborate to address a shared problem and reap joint rewards (Lee et al., Reference Lee, Fernández, Potenciano Menci, Rieger and Fridgen2023).

3.3.2. Infrastructure

Second, stakeholders must decide upon the system architecture. FL presents two main architectures (Figure 2): centralised and decentralised (Yin et al., Reference Yin, Zhu and Hu2021). The former involves a set of clients and an orchestration agent (central server) for collaborative training of an ML model. The process consists of three phases as follows: preparation, training and learning, and use. Clients prepare their data, agree on the ML model to train, and select initialisation parameters. The orchestrator then selects a subset of clients to download, train, and share their model parameters. This process iterates until the model reaches the agreed objective, usually a certain performance level or learning threshold, although it could be a limit in rounds or training expenses. This architecture has trade-offs, including privacy concerns, a single point of failure (the server), communication overhead, scalability issues, security risks, and fairness challenges.

Figure 2.

Conceptual architectures for FL.

Decentralised FL operates differently and overcomes some of these trade-offs. It requires a protocol for peer-to-peer information sharing and a logic architecture for learning orchestration. The same three phases persist: prepare, train and learn, and use. By removing the dependency on a central coordination agent and distributing responsibility among clients, decentralised FL fosters a more resilient and efficient collaboration (Martínez Beltrán et al., Reference Martínez Beltrán, Pérez, Sánchez, Bernal, Bovet, Pérez, Pérez and Celdrán2023). It also removes the sharing of potentially compromising data with a coordination agent, avoids a single point of failure, and aims to improve fairness by shifting importance from the client’s data to every client, preventing clients with large datasets from dominating the learning process (Witt et al., Reference Witt, Heyer, Toyoda, Samek and Li2023).

In certain scenarios (involving highly sensitive or private data), an alternative take on the centralised architecture emerges, such that the physical location of the training process changes. Under specific conditions, the federation may choose to aggregate the model at a trusted third party (such as a European body like eu-LISA or a market authority) that has no economic interest in the outcome but is responsible for ensuring the correct functioning of the system. For instance, in a fraud detection federation across banks (Yang et al., Reference Yang, Zhang, Ye, Li and Xu2019), a financial market regulator could oversee the training process to ensure it is conducted properly, without having any interest in the model or its outputs.

Besides physical solutions to trust and ownership, researchers have implemented technological solutions. To uphold privacy, mechanisms like differential privacy add noise to obscure individual data contributions and mitigate reconstruction risks (Fu et al., Reference Fu, Hong, Ling, Wang, Ran, Sun, Wang, Chen and Cao2024). Homomorphic encryption enables computations directly on encrypted data, preserving confidentiality during aggregation without sacrificing model utility (Jin et al., Reference Jin, Yao, Han, Joe-Wong, Ravi, Avestimehr and He2023). Similarly, secure multi-party computation protocols allow for collaborative model training while ensuring no individual party’s data are exposed (Kaminaga et al., Reference Kaminaga, Awaysheh, Alawadi and Kamm2023).

To protect against adversarial behaviour, especially model poisoning, anomaly detection techniques have been developed to identify irregular or malicious updates (Vucovich et al., Reference Vucovich, Tarcar, Rebelo, Gade, Porwal, Rahman, Redino, Choi, Nandakumar and Schiller2022). Trust and reputation-based systems can further reinforce robustness by weighting client updates according to their historical reliability and contribution quality (Rashid et al., Reference Rashid, Xiang, Uddin, Tang, Sood and Gao2025). Furthermore, research has proposed to integrate blockchain-based solutions, such as smart contracts (Cassano et al., Reference Cassano, D’Abramo, Munir and Ferretti2024), and non-technical approaches utilising legal instruments like contracts and independent audits to ensure ethical, legal, and technical robustness in systems, thereby holding providers accountable (OECD, 2016).

Other emerging methods seek to enhance fairness and operational efficiency. Fairness-aware aggregation frameworks attempt to balance the influence of clients with heterogeneous data volumes, ensuring equitable model contributions (Ezzeldin et al., Reference Ezzeldin, Yan, He, Ferrara and Avestimehr2023), while model compression techniques reduce the communication burden associated with transmitting large updates, thereby broadening participation to include clients with limited resources (Yang et al., Reference Yang, Xiao, Motta, Beaufays, Mathews and Chen2022). Collectively, these techniques enable the development of federated systems that are not only decentralised but also more secure, private, and equitable.

3.3.3. Ownership

Finally, the stakeholders need to address questions about ownership. In the context of AI, these questions are manifold. Post-GenAI, the body of works considering the ownership of outputs of an AI has grown (see Tzimas, Reference Tzimas2021). Conceptually, we pragmatically consider ownership as who owns the IP rights to the trained model and how the benefits derived are distributed (Berente et al., Reference Berente, Gu, Recker and Santhanam2021). The benefits can be both financial in the commercialisation of the model or practical in its application.

The IP can be shared or in whole; correspondingly, ownership can be shared equally among parties, be distributed among parties, or be owned by one single party. In the former, parties can—for example, in the European Union—draw up a so-called Research and Development Agreement before development (European Commission, 2023). The agreement covers (1) IP ownership and access rights, (2) registration protocols, (3) exploitation strategy (in the form of licences), and (4) IP management in case of termination of the agreement. An alternative form of shared ownership can be formalised by the creation of a joint venture or consortium, where two or more independent organisations undertake a specific project together and share the IP accordingly. Here too, for both types of organisations, agreements typically cover the same four points (see also WIPO, 2005). By and large, IP rights define the ownership settings and access to the model. For example, whereas in-house governance will allow to fully leverage the IP rights, sharing IP as part of a consortium may put limits on commercialisation.

3.3.4. Archetype

Due to the limited number of scaled applications, the knowledge on resulting archetypes is scarce. However, we expect one to use our framework and for one archetype to emerge as a result of decisions taken along each layer of the framework. To assist practitioners in identifying the matching archetype, we propose a set of guiding questions along the layers (see Table 2). Effectively, the way one answers these questions will determine internal development choices, ultimately leading to a specific archetype. In the future, the patterns for which archetypes are more popular in which context may become clearer. We anticipate that context, application domains, verticals, country-specific regulations, and other variables to play a significant role in shaping them.

Table 2.

Guiding questions by layer of our proposed framework

^a The questions formulated by layer are non-exhaustive. We see these as starting point for discussion.

4. Organisational archetypes

4.1. Application of the framework

In Table 3, we consider a limited set of real-world applications through the lens of our framework. It is noteworthy that we only selected applications that are mature and have progressed beyond initial proofs of concept, prototypes, or small-scale pilots and are actively utilised in real-world environments, of which, according to the UK’s Department for Science, Innovation, and Technology (2024), there are relatively few of them. We expected this to be the case given the general, risk-averse sentiment towards FL adoption (Müller et al., Reference Müller, Zahn and Matthes2024).

Table 3.

Real-world applications of FL through the lens of the layered framework

^a We estimate the application’s technology readiness levels (see NASA, 2023) on the basis of available documentation.

^b Coll, collaboration; Comp, competition.

^c Dec, decentralised; Cen, centralised.

We note that the majority of applications are in the healthcare sector. This was to be expected (Rieke et al., Reference Rieke, Hancox, Li, Milletarì, Roth, Albarqouni, Bakas, Galtier, Landman, Maier-Hein, Ourselin, Sheller, Summers, Trask, Xu, Baust and Cardoso2020). In terms of archetypes, we observe that in collaborative data markets with decentralised infrastructure and shared IP ownership, the consortium appears as an evident organisational archetype. Popularised in the information technology industry at the turn of the century, consortia are a form of alliance between multiple organisations that collaborate on a shared objective while maintaining their independence (see Hawkins, Reference Hawkins1999). Literature has shown that such collaborative structure mitigates the risks of monopolisation, enhances collective innovation, and promotes fair competition by aligning incentives toward mutual benefit rather than market dominance (Doz et al., Reference Doz, Olk and Ring2000). In the context of FL, the archetype helps to balance power dynamics by ensuring that decision-making, resource allocation, and IP rights are distributed more equitably among stakeholders (Bujotzek et al., Reference Bujotzek, Akünal, Denner, Neher, Zenk, Frodl, Jaiswal, Kim, Krekiehn, Nickel, Ruppel, Both, Döllinger, Opitz, Persigehl, Kleesiek, Penzkofer, Maier-Hein, Bucher and Braren2024; Mateus et al., Reference Mateus, Moonen, Beran, Jaarsma, van der Landen, Heuvelink, Birhanu, Harms, Bron, Wolters, Cats, Mei, Oomens, Jansen, Schram, Dekker and Bermejo2024).

The second archetype we see emerging is labelled as “in-house.” Here, the application is Gboard, Google’s virtual keyboard, which utilises FL to improve predictive text and typing suggestions while maintaining user privacy. Instead of sending raw typing data to centralised servers, Gboard trains directly on users’ devices, aggregating only the necessary updates to improve the overall model (Hard et al., Reference Hard, Rao, Mathews, Ramaswamy, Beaufays, Augenstein, Eichner, Kiddon and Ramage2018). In terms of governance, the model principles and access (refer to Table 1) largely define and point towards a centralised, proprietary setting.

Beyond the two archetypes observed “in the wild,” we foresee other archetypes to emerge. One of these is the joint venture whereby independent organisations form a new organisation under which model training occurs or is coordinated, by which ownership is equitably shared and typically commercialised. This archetype is opposed to consortia, where it is typically not commercialised.Footnote ⁶ The conditions for such a form of alliance are relationship and firm-specific (see Pateli & Lioukas, Reference Pateli and Lioukas2011). Another archetype we foresee to be of interest is to delegate orchestration to a third party. This could be, for example, a financial market authority or central bank (Lee et al., Reference Lee, Fernández, Potenciano Menci, Rieger and Fridgen2023). A more speculative, experimental archetype is to delegate orchestration to a decentralised autonomous organisation (Majeed et al., Reference Majeed, Hassan, Han and Hong2023).

6. Outlook

As with any emerging technology, FL faces the dynamics of typical technology adoption life cycles—be it Gartner’s hype cycle or others. While deterministic by nature (Pollock & Williams, Reference Pollock and Williams2010), these frameworks can provide a useful lens to estimate the stage of development for FL.

The academic corpus surrounding FL appears to be entering a stage of consolidation, marked by an increasing number of early adopters seeking to understand, explore, and advance the technology. These efforts are projected into the first real-world implementations in the healthcare sector (Pati et al., Reference Pati, Baid, Edwards, Sheller, Wang, Reina, Foley, Gruzdev, Karkada, Davatzikos, Sako, Ghodasara, Bilello, Mohan, Vollmuth, Brugnara, Preetha, Sahm and Maier-Hein2022; Bujotzek et al., Reference Bujotzek, Akünal, Denner, Neher, Zenk, Frodl, Jaiswal, Kim, Krekiehn, Nickel, Ruppel, Both, Döllinger, Opitz, Persigehl, Kleesiek, Penzkofer, Maier-Hein, Bucher and Braren2024; Mateus et al., Reference Mateus, Moonen, Beran, Jaarsma, van der Landen, Heuvelink, Birhanu, Harms, Bron, Wolters, Cats, Mei, Oomens, Jansen, Schram, Dekker and Bermejo2024). These examples illustrate how real-world applications are progressing beyond purely technical aspects, in finding answers to organisational questions. Their success relies on interdisciplinary and cross-domain collaboration (van Drumpt et al., Reference van Drumpt, Timan, Talie, Veugen and van de Burgwal2024).

By contrast, applications outside of the healthcare sector remain underdeveloped, often lagging in the depth and breadth of available research. This disparity suggests that while research in other sectors may be maturing, real-world adoption is still in its infancy, requiring more innovators and organisations to bridge the gap. Consequently, as also seen in the healthcare sector, we recommend to decision-makers and policy-makers that interdisciplinary and cross-sectional collaboration is key for FL’s adoption. The uptake of use cases requires more than technical expertise.

Research opportunities will continue to emerge as both industry and academia explore the implementation of FL across sectors. As collaboration markets emerge and evolve, it is essential to examine the technical advancements in FL and the governance concepts that will accompany them. For instance, we envision that organisational frameworks must be developed to address long-term and short-term adoption strategies. Short-term strategies are particularly relevant in the context of FL, as the emergence of short-term federations may necessitate agile organisational structures that enhance governance’s dynamism and account for such contingencies (see Sambamurthy & Zmud, Reference Sambamurthy and Zmud1999). In line with these developments, a clear research opportunity building from our theoretical framework could lead to the creation of a decision tree to guide organisations in the selection process of an organisational archetype from a practical perspective. We foresee managers and C-level executives within organisations to be the main counterparties. Moreover, we also foresee the necessity of understanding the trade-offs; in other words, the benefits and drawbacks of certain decisions when in the context of an FL organisation.

Additional research opportunities in governance arise as the global “building boom” of high-performance computers and data centres is kept alive (Weise, Reference Weise2025). Specifically, beyond those owned and operated by Big Tech, we see these facilities as providing on-demand computational resources and being non-competitive, trustworthy orchestrators for the training of FL. Still, they also require governance frameworks to establish the rules based on the type of archetype they will interact with. However, given the preliminary nature of our approach and the lack of post-data analysis, a significant question remains uncertain: will there be a multitude of different archetypes, or will they converge?