Beyond Turing

Chapter 8 · Part II - The Body

The Network and the Node

Federated learning, edge computing and distributed architectures for tele-health under the EU AI Act and MDR

Chapter cover: The Network and the Node

A university hospital in Berlin, one in Milan, one in Barcelona, one in Prague share a common clinical problem - early risk stratification of heart failure in patients monitored by wearables - and cannot share the datum that would solve it. The reason is not technical: it is regulatory. EU Regulation 2016/679 (GDPR) Article 9 qualifies health data as a special category; EU Regulation 2017/745 (MDR) requires clinical evidence specific to the device's context of use; EU Regulation 2024/1689 (AI Act) - fully applicable to high-risk systems from 2 August 2026 - overlays verifiable and traceable data governance requirements. Transferring four datasets from four jurisdictions to a centralised data centre to train a model is, today, an engineering possibility whose legal viability is closing.

The engineering question that follows is precise. If the data cannot migrate, the model must migrate. If the model migrates, the network becomes the locus of computation, and the node - the hospital, the wearable device, the household gateway - becomes a sovereign computational unit with its own legal obligations. The paradigm of federated learning (McMahan et al., 2017), articulated for healthcare contexts (Rieke et al., 2020) and matured over three years of multi-institutional clinical validation (Kaissis et al., 2020), answers this question. But it does not resolve it. It relocates it.

This article traces network and node - from the FedAvg baseline to its extensions for non-identically-distributed populations, from hub-and-spoke topologies to peer-to-peer scenarios, from stratified privacy-preservation to the new geometry of responsibilities that the AI Act overlays on the chain - and shows how the maturity of a federated tele-health system is not measured in the decimal digit of aggregate accuracy, but in each node's ability to retain computational sovereignty within a network that exists to serve, not to absorb, the clinical unit.

§1. The centralisation problem and clinical-data sovereignty

The classical machine-learning paradigm presupposes a centralised dataset. Data generated in heterogeneous locations - electronic health records, wearable devices, imaging systems - are collected in a single data lake and submitted to modelling. The assumption has enabled two decades of progress in medical deep learning (Esteva et al., 2019), but rests on a premise that the European legal framework has progressively narrowed: the accessibility and poolability of health data.

GDPR Article 9 qualifies health data as a special category, admissible for processing only on strengthened legal bases (explicit consent, public-health purposes, authorised clinical research). MDR Article 62 imposes clinical investigation specific to the device's context of use, which binds evidence to the deployment setting. EU Regulation 2022/868 (Data Governance Act) and EU Regulation 2023/2854 (Data Act) introduce an infrastructure of data intermediation and sectoral data spaces - the European Health Data Space (EHDS) currently being implemented - which formalises a structured but segmented model of data sharing for primary and secondary use. AI Act Article 10, finally, requires training, validation and test datasets to be relevant, sufficiently representative, free of errors as far as possible, and complete with respect to the intended purpose - a requirement that, in clinical contexts, is unsatisfiable with mono-institutional datasets.

The convergence of these constraints produces a well-defined engineering problem. The statistical model must be trained on data that, for reasons both epistemic and legal, cannot be aggregated. The engineering literature of tele-health has explored in recent years distributed collaborative platforms addressing precisely this bounded geometry (Fabbrizio et al., 2023; Fucarino, Fabbrizio et al., 2024): the problem is not without technical solutions, but the technical solution must be conceived as an integral part of the architecture, not as an accessory compliance layer.

Clinical-data sovereignty - which GDPR founds on the notion of data controller and which the Data Governance Act extends to the notion of data holder - is not an obstacle engineering must circumvent: it is the boundary condition engineering must incorporate into system design. Federated learning arises exactly from this incorporation.

§2. Federated architecture: from gradient averaging to the topology of trust

The reference algorithm - Federated Averaging or FedAvg (McMahan et al., 2017) - articulates computation in synchronised communication rounds. In each round, an aggregation server distributes the current model state - a parameter vector θ_t - to a subset S_t of participating nodes. Each node k executes K steps of stochastic gradient descent on its local dataset D_k, producing a local update θ_t^k. The server aggregates updates via weighted average by local-dataset size: θ_{t+1} = Σ_k (|D_k| / |D|) θ_t^k. Raw data never leaves the node. Network traffic reduces, by order of magnitude, to model parameters - tens of megabytes for reasonable architectures - instead of datasets - potentially terabytes.

FedAvg's theoretical convergence is guaranteed under the hypothesis of independently and identically distributed (i.i.d.) data across nodes. In healthcare, this hypothesis is almost always violated. Patient distribution in a German university hospital does not match distribution in an Italian spoke centre; signal-acquisition protocols vary; imaging equipment changes. The phenomenon is known in the literature as client drift and produces documented performance degradation up to 30-40% relative to i.i.d. baselines (Zhao et al., 2018). The proposed extensions - FedProx with proximal regularisation term (Li et al., 2020), SCAFFOLD with variance correction (Karimireddy et al., 2020), FedBN with local batch normalisation (Li et al., 2021) - constitute, today, the engineering toolkit for operating in non-i.i.d. clinical regimes.

The topology of the federated network is the second fundamental architectural choice. In the hub-and-spoke model, a central server orchestrates communication rounds: simple architecture, low latency, but single point of failure and concentration of trust on the coordinator. In the peer-to-peer model (Roy et al., 2019), nodes communicate directly in gossip schemes without a central coordinator: resilient architecture but with slower convergence and greater consensus complexity. In the hierarchical model, intermediate aggregation layers - a regional edge server aggregating hospitals in an area, a national server aggregating regions - reproduce the administrative geography of healthcare delivery and, simultaneously, the legal geography of territorial competences.

The topological choice is not neutral with respect to governance. A hub-and-spoke architecture with server located in an extra-EU jurisdiction silently transforms processing into a cross-border transfer regulated by GDPR Articles 44-49. A peer-to-peer architecture distributed across nodes in different Member States dilutes controllership in ways European law has not yet fully mapped. The network's topology, in a federated healthcare system, is itself a regulatory artefact.

§3. The node: edge computing, TinyML, and situated computation

The node, in federated healthcare learning, is not an abstraction. It is an engineering artefact with precise physical characteristics: an ARM Cortex-M4/M7 microcontroller in a wearable wristband, an ESP32 or nRF52840 system-on-chip in a household device, a Raspberry Pi gateway in a hospital ward, a local server in an outpatient clinic. Available memory ranges from hundreds of kilobytes at the microcontroller to gigabytes at the local server; energy budget ranges from milliwatts of the wearable to tens of watts of the gateway. The discipline studying the trade-off among these constraints is, today, TinyML (Banbury et al., 2020; Warden & Situnayake, 2019).

Post-training quantisation - converting model weights from 32-bit floating-point to 8-bit integer (INT8) or lower - reduces model memory by a factor of 4 and inference latency by a factor of 2-3, with accuracy losses often below 1% (Jacob et al., 2018). Structured pruning techniques eliminate up to 90% of non-informative parameters (Han et al., 2016) preserving performance within clinically acceptable margins. Knowledge distillation (Hinton et al., 2015) transfers information from a complex teacher model to a compact student model suitable for on-device inference.

The operational concept unifying these techniques is the edge-cloud continuum. Not all computational stages must occur in the same place. A wearable can perform local pre-processing and feature extraction, delegating heavy inference to the household gateway; the gateway can perform real-time inference, delegating incremental training to the hospital server; the hospital server can perform local update, participating in federated rounds with regional servers. Computational partitioning along the continuum is no longer an optimisation choice - it is an architectural specification that intersects data sovereignty, available energy, tolerable latency, and human-oversight requirements under AI Act Article 14.

The operational experience matured on distributed tele-exercise platforms (Fucarino, Zimatore, Fabbrizio et al., 2024) has shown that the clinical effectiveness of a remote-monitoring system grows not with the central server's computational power but with the peripheral node's reliability. A wearable device that loses connectivity for eight hours in a rural region and continues to operate autonomously, recording locally and synchronising at the first available network window, is a more useful - and more compliant - device than a centralised system that silently degrades as network quality varies.

§4. Privacy as technical stratification and the mathematics of trust

Federated learning keeps raw data on the node, but is not, in itself, privacy-preserving. Model updates exchanged with the aggregation server carry information about local data, reconstructable in partial forms through documented attacks - gradient leakage (Zhu et al., 2019), membership inference (Shokri et al., 2017), model inversion (Fredrikson et al., 2015). Privacy protection in a federated system is, consequently, a specific technical stratification, each layer with distinct computational cost and formal guarantee.

Differential Privacy (Dwork et al., 2006; Abadi et al., 2016) provides a quantitative mathematical guarantee. A training mechanism is (ε, δ)-differentially private if the probability of obtaining a particular outcome varies by at most a factor of e^ε with probability 1-δ, when a single record is added to or removed from the dataset. In practice, gaussian noise calibrated to gradients is injected before transmission: typical values in medical contexts - ε between 1 and 10, δ equal to 10^-5 - produce accuracy degradation of 3-15% in exchange for formal guarantees against reconstruction attacks (Kaissis et al., 2020).

Secure Aggregation (Bonawitz et al., 2017) employs multi-party computation protocols so that the server observes only the sum of updates, never a single node's update. The cryptographic construction relies on secret sharing and pseudo-random masks; communication cost grows as O(N) with number of participants. Homomorphic Encryption - CKKS schemes (Cheon et al., 2017) for approximate operations on real numbers, BFV/BGV schemes for integer operations - allows the server to aggregate updates directly on encrypted data without ever decrypting them. Computational cost remains high today (two-to-three orders of magnitude slowdown relative to plaintext computation), but the maturity of open-source libraries - Microsoft SEAL, IBM HElib, OpenFHE - is bringing it within growing application perimeters.

The fourth layer is environmental: Trusted Execution Environments - Intel SGX, ARM TrustZone, AMD SEV - create hardware enclaves in which computation occurs in memory areas isolated even from the host operating system. Documented side-channel attacks (Chen et al., 2019) have shown that enclaves are not impenetrable, but their combination with Differential Privacy and Secure Aggregation produces defence-in-depth architectures that respond verifiably to AI Act Article 15 requirements on cybersecurity of high-risk systems and to EU Regulation 2022/2555 (NIS2) security obligations for essential operators in the healthcare sector.

The engineering lesson matured over three years of large healthcare consortia - MELLODDY for pre-competitive drug discovery, EXAM for COVID-19 stratification across 20 hospitals (Dayan et al., 2021), NVIDIA Clara Federated Learning collaborations with oncology-centre networks - is that no single technical layer is sufficient. Privacy in a federated healthcare system is built as stratified architecture: Differential Privacy for mathematical guarantee, Secure Aggregation for server isolation, Trusted Execution for hardware defence, and - above all - documented governance, audit trail recorded under AI Act Article 12, Data Protection Impact Assessment renewed at every model evolution.

§5. The network as regulatory fabric: who answers in distributed architecture

Federated learning solves a data-engineering problem and opens one of responsibility engineering. The AI Act distinguishes with precision the roles along the chain - provider, deployer, importer, distributor, authorised representative - and attributes specific obligations to each (Articles 16-27). The provider of the model is responsible for system conformity; the deployer - who uses the system in professional activity, typically the hospital - is responsible for use monitoring, incident reporting, application of provider instructions.

In a federated architecture, the provider/deployer distinction structurally complicates. Every hospital participating in training rounds contributes, with its gradients, to model evolution: is it still merely deployer or does it become, in substantive terms, co-provider? The aggregated model returning to the individual node after the training round - is it still the same system, or is it a modified system that - under Article 25 - entails renewed documentary obligations? The European legal literature is beginning to map these zones (Truby et al., 2022; Malgieri & Comandé, 2017 on the prior GDPR), but the geometry of distributed responsibilities is still an open problem that the practice of notified bodies is constructing case by case.

The mature engineering response, today, articulates three layers of parallel documentation. The first - the consortium agreement - formalises who participates, with which data, under which GDPR legal bases, with which distribution of controllership and joint controllership (GDPR Article 26). The second - the federated model card (extended from the proposal of Mitchell et al., 2019) - documents model evolution round by round, participants in each round, distributions of local data synthesised in heterogeneity metrics (KL divergence, earth mover's distance), pre-and-post aggregation performance. The third - the distributed audit log, typically implemented on distributed ledger technology or on immutable append-only archives - records every training event, every model update, every security event in reconstructable and verifiable form.

Human oversight under AI Act Article 14, in a federated network, is not a local function. It is a function of the network. Each deployer maintains oversight over local model use; the consortium maintains oversight over aggregate evolution; the provider - when distinct - maintains oversight over the distributed reference model. The stratification of oversights is not redundancy: it is the functional specification allowing the system to identify at which level a problem originated, in time to intervene.

The mature network, in this reading, is one in which each node can say - with verifiable technical support - "this update I do not accept", "this datum I do not share", "in this condition I suspend myself". The node's sovereignty is not an obstacle to the network: it is the condition of its trust. A federated healthcare network that does not provide explicit protocols for selective opt-out, local model rejection, graceful exit from the consortium, is not a mature network - it is a fragile aggregation waiting for the first rupture event.

Between the network and the node unfolds the geometry of European digital healthcare. The network guarantees statistical power, epidemiological breadth, robustness to individual local events; the node guarantees data sovereignty, respect for clinical controllership, proximity to the subject. There is no opposition between the two - there is, rather, a productive tension that system engineering must keep open. The node that does not participate in the network isolates itself in an impoverished local optimum; the network that absorbs the node transforms itself into the centralised monolith that federated learning was born to overcome.

The most important line of code, in a federated healthcare system, is the one allowing the node to say no. Not to the network as institution - to the individual update that the node, on its local evidence, on its own population, on its own confidence thresholds, recognises as improperly foreign. A system that has inscribed that line of code in its protocol is a system that has understood something precise: the network exists for the node, and the node exists for the subject. Every other configuration betrays the order of ends.

↑ Back to contents

by Antonio Fabbrizio · MMXXVI