Digital twins in healthcare promise to simulate disease progression and personalise care. But a patient’s digital twin is, first of all, a large-scale processing of health data: when do synthetic data remain personal data? Who is the controller in a federated architecture? And what happens to the data of the deceased? The reflections that follow take up and develop our contribution, as an AI & Data Protection expert, to a European workshop last March 2026 on decentralised digital-twin environments.
In March 2026 we had the pleasure of contributing, as an AI & Data Protection expert, to a European workshop on the ethics and implementation of decentralised digital-twin environments in healthcare. The so-called Decentralised Digital Twin Environment (DDTE) is one of the most concrete areas of application of the whole of European digital law: the GDPR, the AI Act, NIS 2 and the European Health Data Space (EHDS) Regulation converge on it simultaneously.
Not computing power, but governance maturity
The first question posed by the project concerned the technical capabilities needed to join a decentralised digital-twin environment. Our answer starts from a premise: the issue is less about computing power and more about governance maturity. Participating research infrastructures — universities, research centres, hospitals — must be able to demonstrate a GDPR-compliant data-processing set-up, the ability to store data locally in secure environments with access controls, logging and up-to-date procedures, and the adoption of standardised interfaces and formats for interoperability: documented APIs, FAIR-aligned metadata, shared ontologies. Not all infrastructures will have the same degree of readiness, and that is physiological: what is needed is a definition of minimum entry requirements and progression paths, for which voluntary standards such as ISO/IEC 27001 and ISO/IEC 42001 can serve as a benchmark, without certification becoming a mandatory condition of participation.
The synthetic-data knot: when the anonymous is not anonymous
The digital twin produces synthetic data from real patient data. The decisive question is whether such synthetic data are genuinely anonymous under Recital 26 of the GDPR, for which data-protection principles do not apply to “anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable”. Indeed, if the generative model was trained on real data, the risk of model memorisation could allow information referable to specific individuals to be extracted: in that case the synthetic data would remain, to all effects, personal data. Among the mitigation techniques is differential privacy, which introduces controlled noise into the training data but entails a trade-off with model accuracy — a circumstance that must be documented in the impact assessment under Article 35. To this is added the risk of re-identification from external sources: if a sufficiently sophisticated AI system — and today one speaks of agentic AI too — were able to cross-reference a digital twin’s profile with data available in federated health-data spaces, the risk of reconstructing the patient’s identity would become concrete. It is the so-called linkage attack, a scenario that must expressly enter the DPIA.
Local and federated: the dividing line is legal, not technical
Which information must remain local and which can be federated? The dividing line should be guided by data-protection principles, not by technical convenience. Health data in identifiable or pseudonymised form must remain local, in observance of the minimisation principle under Article 5(1)(c), along with consent registers, identity management, access logs and incident-response capacity — bearing in mind that Article 33 imposes breach notification within 72 hours, while NIS 2 requires a first alert within 24 hours. Aggregated model parameters, genuinely anonymised datasets, governance metadata and the compliance documentation of the AI components can instead be federated: the federated-learning architecture, in which the model parameters travel rather than the raw data, is intrinsically aligned with this approach. The critical point remains, once again, the synthetic datum: if it retains any trace of re-identifiability, it is personal data and cannot circulate as if it were anonymous.
The chain of responsibilities in the federated architecture
Then there is the knot of roles. The GDPR distinguishes controller (Article 24), joint controllers (Article 26) and processor (Article 28); but in a federated architecture, where the data do not move and the model does, the qualifications are anything but obvious. If several research infrastructures collaborate in training a federated model, jointly determining its purposes and means, joint controllership arises, requiring a transparent arrangement. The AI Act, in turn, distinguishes the obligations of the provider from those of the deployer (Articles 16 and 26): in a research project such roles often overlap. On the safeguards and approvals side, the picture is dense: DPIA under Article 35 and, in case of high residual risk, prior consultation of the authority under Article 36; fundamental-rights impact assessment under Article 27 of the AI Act for high-risk systems; ethics-committee opinion where required by national law; authorisation of the health-data access body under Chapter IV of the EHDS for the secondary use of electronic health data. And, contractually: joint-controllership agreements, Article 28 agreements with cloud providers, clauses on data quality, purpose limitation and intellectual property of the federated model.
A point of attention: the biological samples of the deceased
Finally, we wish to draw attention to an often-overlooked aspect. Recital 27 of the GDPR excludes the data of deceased persons from its scope, deferring to national laws. However, genetic data derived from biological samples of the deceased contain information about living relatives, who are fully protected by the Regulation. Did the original consent cover use for generating digital twins? Do living relatives have a right to information or objection? These are questions that must find an answer in the project’s contracts and governance, before they do in litigation.
Conclusions
The health digital twin condenses into a single object all the tensions of European digital law: the promise of personalised medicine and the risk of re-identification, the push towards federated sharing and the minimisation principle, the layering of GDPR, AI Act, NIS 2 and EHDS on a single infrastructure. Treating each regulation as a separate compliance requirement would be a mistake: what is needed is a modular, integrated approach, resting on a common base and able to map the additional national requirements that Article 9(4) of the GDPR allows Member States for genetic, biometric and health data. In the light of the above, one wonders whether patient trust — the true critical infrastructure of every health-data ecosystem — can rest on formal compliance with the rules alone, or whether it does not rather require effective transparency and involvement. Governing the digital twin means, in the end, holding together the protection of the person and that of their digital replica, where each touches the very essence of identity.