Espace européen des données de santé : guide EHDS 2026

Un hôpital, un laboratoire de biologie, un fabricant de dispositifs médicaux ou un promoteur d’essais cliniques ne pourra bientôt plus refuser de communiquer ses données de santé à un tiers qui les demande à des fins de recherche. Le règlement (UE) 2025/327 sur l’espace européen des données de santé (EEDS, ou EHDS pour European Health Data Space) transforme une faculté en obligation, sous peine d’amendes pouvant atteindre 20 millions d’euros ou 4 % du chiffre d’affaires mondial. Entré en vigueur le 26 mars 2025, il s’appliquera par vagues successives à partir du 26 mars 2027.

Beaucoup de responsables de traitement du secteur santé considèrent encore l’EEDS comme un sujet « pour plus tard ». C’est une erreur de calendrier : les obligations qui mordront en 2029 supposent une cartographie des données, un arbitrage sur la propriété intellectuelle et une refonte contractuelle qui prennent deux à trois ans. Voici ce que le texte impose réellement, et par quoi commencer.

L’EEDS en une phrase : le premier espace sectoriel de la stratégie européenne des données

L’espace européen des données de santé est le premier des onze espaces sectoriels prévus par la stratégie européenne pour les données. Il s’inscrit dans la même architecture que le Data Act et poursuit une logique voisine : casser les silos, imposer l’interopérabilité, et créer un droit d’accès aux données là où le droit commun ne prévoyait qu’une négociation contractuelle.

La différence tient au secteur. Là où le Data Act organise l’accès aux données générées par les objets connectés, l’EEDS organise l’accès aux données de santé — c’est-à-dire, dans l’écrasante majorité des cas, à des données sensibles au sens de l’article 9 du RGPD. C’est ce qui rend le texte à la fois plus ambitieux et plus contraignant que ses cousins.

Le règlement se structure en trois volets :

Volet	Objet	Chapitre
Utilisation primaire	Accès du patient et des soignants aux données, échange transfrontalier via MaSanté@UE (MyHealth@EU)	Chapitre II
Systèmes de DME	Exigences techniques et auto-certification des logiciels de dossier médical électronique et des applications de bien-être	Chapitre III
Utilisation secondaire	Obligation de mise à disposition des données pour la recherche, l’innovation et les politiques publiques, via les ORAD et DonnéesSanté@UE (HealthData@EU)	Chapitre IV

Pour la plupart des organisations que je conseille, c’est le chapitre IV qui change la donne. Les deux premiers volets sont des chantiers d’interopérabilité et de systèmes d’information ; le troisième est un chantier juridique et stratégique.

Le calendrier réel : ce qui s’applique, et quand

C’est le point sur lequel je vois le plus d’approximations. L’EEDS n’est pas « applicable depuis 2025 » : il est entré en vigueur, ce qui est différent. L’article 105 organise une application en cascade.

Date	Ce qui devient applicable
26 mars 2025	Entrée en vigueur du règlement. Aucune obligation opérationnelle.
26 mars 2027	Application du règlement pour l’essentiel des dispositions générales et de gouvernance, ainsi que plusieurs dispositions du chapitre IV (mise en place des ORAD, catalogues, coopération).
26 mars 2029	Cœur du dispositif : échange transfrontalier du premier groupe de catégories prioritaires (synthèse médicale, ordonnance et dispensation électroniques) et l’essentiel du régime d’utilisation secondaire.
26 mars 2031	Second groupe de catégories prioritaires (imagerie médicale et comptes rendus d’imagerie, résultats de biologie, lettres de sortie), exigences applicables aux systèmes de DME et aux applications de bien-être, et utilisation secondaire des données génétiques, génomiques et issues d’essais cliniques.
26 mars 2034-2035	Ouverture progressive aux pays tiers et organisations internationales dans DonnéesSanté@UE.

Deux précisions utiles. D’une part, la répartition précise entre 2029 et 2031 est fixée article par article et sera affinée par les actes d’exécution de la Commission — le raisonnement par grandes masses suffit pour planifier, pas pour trancher un cas limite. D’autre part, ce calendrier européen se double d’un calendrier français : la mise en œuvre suppose une adaptation du code de la santé publique et de la loi Informatique et libertés, portée par un projet de loi attendu en 2026 et des travaux pilotés par la Délégation au numérique en santé (DNS).

Comparé au calendrier du Data Act, l’EEDS laisse donc plus de temps. Il en demande aussi beaucoup plus.

Utilisation primaire : les droits du patient et l’obligation de numériser

Le chapitre II poursuit et amplifie ce que le RGPD avait ouvert avec l’article 15. La personne concernée obtient un accès immédiat, gratuit et dans un format aisément lisible à ses données de santé électroniques prioritaires, ainsi que la possibilité de les partager avec le professionnel de son choix, y compris dans un autre État membre.

Symétriquement, les professionnels de santé accèdent aux données pertinentes de leurs patients, quel que soit le pays de l’Union où elles ont été produites, gratuitement et dans leur propre langue. C’est l’objet de l’infrastructure MaSanté@UE. En France, le point de contact national est opéré par l’Agence du numérique en santé via le service Sesali, qui permet déjà de consulter la synthèse médicale d’un patient européen ; l’ordonnance et la dispensation électroniques transfrontalières suivront.

La contrepartie, pour les établissements de santé, les cabinets médicaux, les laboratoires de biologie ou les pharmacies d’officine, est une obligation de numérisation et d’alimentation. On ne peut pas partager ce qu’on ne structure pas. Concrètement, cela signifie produire les documents prioritaires dans les formats européens d’échange, et raccorder son système d’information au point de contact national.

Point important sur le modèle économique : pour l’utilisation primaire, l’article 18 exclut toute rémunération. Ni l’émetteur ni le destinataire ne peuvent facturer le partage des données réalisé pour les besoins de la prise en charge. C’est un service public de fait.

Systèmes de DME : une nouvelle conformité produit pour les éditeurs

Le chapitre III crée une catégorie juridique nouvelle, celle des « systèmes de dossier médical électronique », soumise à un régime de conformité produit qui rappellera beaucoup de choses aux industriels : exigences essentielles d’interopérabilité et de journalisation des accès, documentation technique, environnement de test obligatoire, déclaration de conformité, marquage.

La mécanique est proche de celle que l’on retrouve dans le marquage CE des systèmes d’IA ou dans les régimes de conformité produit du secteur numérique. Une autorité de surveillance du marché contrôlera les acteurs économiques — fabricants, mandataires, importateurs, distributeurs.

Pour un éditeur de logiciel santé, la première question à trancher n’est pas technique mais qualificative : ma solution est-elle un système de DME, une application de bien-être, un dispositif médical, ou plusieurs de ces choses à la fois ? Les régimes se cumulent. Un logiciel d’aide au diagnostic peut relever simultanément du règlement dispositifs médicaux, de l’AI Act au titre du haut risque et du chapitre III de l’EEDS. Cette qualification conditionne la feuille de route produit pour les cinq prochaines années — mieux vaut la faire poser par écrit maintenant.

Utilisation secondaire : l’obligation de donner accès

C’est le changement de paradigme. Jusqu’ici, un détenteur de données de santé pouvait refuser de les partager, ou en négocier librement les conditions. L’EEDS crée une obligation de mise à disposition, assortie de sanctions financières.

Qui est « détenteur de données de santé »

La définition est large : tout organisme établi dans l’Union qui, dans le cadre de ses activités de santé ou de recherche, a le droit ou l’obligation de mettre à disposition des données de santé électroniques. Cela couvre les établissements et les EHPAD, les laboratoires, les industriels du médicament, les fabricants de dispositifs médicaux, les structures de recherche, les registres, les biobanques, et une partie des organismes complémentaires d’assurance maladie.

Deux limites méritent d’être connues. D’abord, seuls les détenteurs établis dans l’Union sont directement soumis au règlement : un promoteur d’essai clinique établi hors UE n’est pas visé, mais son entité européenne agissant comme responsable de traitement l’est — ce qui, en pratique, ramène une grande partie des données dans le champ. Ensuite, les microentreprises sont exonérées de l’obligation de mise à disposition : moins de dix personnes et un chiffre d’affaires ou un total de bilan annuel n’excédant pas 2 millions d’euros. Un infirmier libéral ou un cabinet de deux praticiens ne sont donc pas concernés par le chapitre IV.

Quelles données sont concernées

L’article 51 liste les catégories minimales que les détenteurs doivent rendre disponibles. Elles sont beaucoup plus étendues que le dossier médical stricto sensu :

Famille	Exemples
Données de soins	Dossiers médicaux électroniques, données de remboursement et de facturation, données administratives liées à la prise en charge
Données produites par des dispositifs	Données issues de dispositifs médicaux, de dispositifs de diagnostic in vitro, d’applications de bien-être et d’objets connectés de santé
Données biologiques	Données génétiques, génomiques et moléculaires humaines, données de biobanques
Données de recherche	Données d’essais cliniques et d’investigations cliniques, données de cohortes, questionnaires et enquêtes
Données de registres	Registres de maladies, registres de mortalité, registres de médicaments et de dispositifs médicaux, données de santé publique

Chaque détenteur devra communiquer annuellement à l’organisme national une description de ses jeux de données, afin d’alimenter un catalogue de métadonnées exhaustif. C’est, dans les faits, un travail très proche de celui du registre des activités de traitement prévu par l’article 30 du RGPD — mais orienté « jeux de données » plutôt que « traitements », et destiné à être publié.

Finalités autorisées, finalités interdites

L’accès n’est ouvert qu’aux finalités limitativement énumérées par l’article 53. Les finalités interdites de l’article 54 sont, elles, d’application immédiate et sans exception.

Finalités autorisées (art. 53)	Finalités interdites (art. 54)
Intérêt public en santé publique et santé au travail	Prendre une décision préjudiciable ou discriminatoire à l’égard d’une personne ou d’un groupe
Élaboration et évaluation des politiques publiques de santé	Publicité et démarchage commercial auprès des professionnels de santé ou des patients
Statistiques nationales et européennes	Développer des produits nuisibles à la santé (stupéfiants illicites, boissons alcoolisées, tabac)
Enseignement et formation dans le domaine de la santé	Activités contraires aux dispositions éthiques nationales
Recherche scientifique en santé	Ajuster une prime d’assurance ou refuser un contrat sur la base des données obtenues
Développement et innovation de produits et services de santé	Prendre une décision relative à l’emploi ou à l’accès au crédit
Entraînement, test et évaluation d’algorithmes, y compris d’IA en santé
Amélioration de la qualité et de la sécurité des soins

La ligne « entraînement, test et évaluation d’algorithmes » mérite d’être soulignée. C’est, pour les acteurs de l’IA en santé, la principale ouverture du texte : un accès légal, encadré et documenté à des données réelles pour valider un modèle. Elle se combine avec les obligations de qualité des données applicables aux systèmes d’IA à haut risque.

La procédure : l’ORAD, l’autorisation de traitement, l’environnement sécurisé

Chaque État membre institue un organisme responsable de l’accès aux données (ORAD, Health Data Access Body ou HDAB). C’est le guichet unique.

Le mécanisme se déroule en cinq temps :

1. Demande. L’utilisateur de données saisit l’ORAD en précisant les catégories de données demandées, la finalité poursuivie, les garanties mises en œuvre, et surtout s’il sollicite des données anonymisées ou pseudonymisées.
2. Instruction. L’ORAD vérifie que la finalité figure à l’article 53, que le demandeur dispose de l’expertise requise, et que le traitement envisagé repose sur une base légale valable au sens de l’article 6 du RGPD. Si la demande porte sur des données pseudonymisées, le demandeur doit décrire précisément comment il respectera le RGPD.
3. Décision. L’ORAD dispose de trois mois pour délivrer ou refuser une autorisation de traitement de données. L’autorisation fixe les catégories et formats de données, la finalité, les personnes habilitées et la durée d’accès.
4. Mise à disposition. L’ORAD relaie la demande aux détenteurs concernés, qui doivent s’exécuter. Certains détenteurs « de confiance » — en France, les entrepôts de données de santé sont les premiers candidats — se verront déléguer une partie des missions de l’ORAD.
5. Traitement. Les données ne sortent pas. Elles sont exploitées dans un environnement sécurisé de traitement, hébergé et traité sur le territoire de l’Union, sous forme anonymisée ou pseudonymisée.

Ce dernier point est essentiel et souvent mal compris. L’EEDS ne crée pas un « lac de données » européen dans lequel on puiserait librement. Il crée un régime d’accès sur autorisation, spécifique à chaque projet, dans un environnement clos. La distinction entre pseudonymisation et anonymisation devient ici décisive : elle conditionne la nature du dossier à constituer, l’application du RGPD au traitement en aval, et les garanties exigées.

Redevances, propriété intellectuelle et secret des affaires

Le règlement ne dépouille pas le détenteur. L’article 62 lui permet de percevoir des redevances proportionnées aux coûts de mise à disposition — pseudonymisation, anonymisation, préparation et fourniture des jeux de données. Ces redevances ne peuvent en revanche pas couvrir les coûts de collecte et de maintenance des données, ce qui exclut toute logique de valorisation de l’actif. Une partie revient à l’ORAD au titre de l’instruction. Des tarifs réduits, voire la gratuité, bénéficieront à certains acteurs publics et académiques.

Le règlement aménage aussi l’obligation de partage lorsqu’elle heurte des droits de propriété intellectuelle, un secret des affaires ou un droit de producteur de bases de données. Le détenteur doit être mis en mesure de faire valoir ces droits et de justifier précisément le risque encouru. En cas de risque grave de violation qui ne peut pas être atténué par des mesures contractuelles ou techniques, l’ORAD refuse l’accès. Mais — et c’est le point sensible — la décision appartient à l’ORAD, pas au détenteur. La logique est très proche de celle que le Data Act retient pour le secret des affaires, avec la même faiblesse : l’absence de mécanisme de licence ou de compensation pour la valeur économique de la donnée partagée.

C’est aujourd’hui le principal point de friction du texte avec les industriels, et le sujet sur lequel je recommande de travailler en priorité : identifier, documenter et opposabiliser ses droits avant la première demande, pas au moment où elle arrive.

Les nouveaux droits des personnes

Deux droits s’ajoutent à ceux du RGPD, et ils ne se confondent pas avec eux.

Le droit d’opposition à l’utilisation secondaire (art. 71). C’est un véritable opt-out, exerçable à tout moment, sans motivation, réversible, et qui doit être rendu accessible et compréhensible. Il se distingue du droit d’opposition de l’article 21 du RGPD, qui suppose des motifs tenant à la situation particulière de la personne. Deux effets concrets, confirmés par les FAQ de la Commission : l’opt-out ne vaut que pour l’avenir — il ne remet pas en cause les autorisations déjà délivrées — et il ne s’applique pas lorsque le détenteur ne peut pas identifier la personne dans le jeu de données, par exemple quand les données sont pseudonymisées sans possibilité de rapprochement avec la liste d’opposition. Les États membres pourront prévoir des exceptions limitées, notamment pour l’intérêt public.

Le droit d’être informé d’une constatation significative. Si l’exploitation secondaire révèle une information cliniquement significative pour une personne identifiable, celle-ci doit pouvoir en être informée — et peut aussi refuser de l’être. C’est une transposition réglementaire du débat sur les découvertes fortuites en génomique.

La conséquence opérationnelle pour les détenteurs est lourde : il faudra un mécanisme technique capable de recueillir, propager et appliquer les oppositions à chaque constitution de jeu de données. Ce n’est pas un chantier juridique, c’est un chantier système d’information.

Articulation avec le RGPD : coexistence, pas substitution

L’EEDS ne remplace pas le RGPD, il s’y superpose. Dès lors que les données de santé électroniques sont des données à caractère personnel, le RGPD continue de s’appliquer intégralement : principe de minimisation, durées de conservation, sécurité au sens de l’article 32, notification des violations, information des personnes.

Trois points d’articulation à retenir :

• Les bases légales. L’EEDS ne dispense pas d’en avoir une. Le régime de l’utilisation secondaire s’appuie sur les dérogations de l’article 9(2) du RGPD selon la finalité poursuivie, avec les garanties de l’article 89 pour la recherche et les statistiques. L’ORAD vérifie ce point à l’instruction.
• Les autorités. L’ORAD n’est pas la CNIL. Le premier autorise l’accès, la seconde reste l’autorité de contrôle compétente pour la protection des données personnelles. Deux guichets, deux logiques, un risque réel de zones grises que les lignes directrices en préparation devront lever.
• Les analyses d’impact. Un projet de réutilisation secondaire à grande échelle de données de santé remplit sans difficulté les critères de l’AIPD. L’autorisation délivrée par l’ORAD ne s’y substitue pas, pas plus que l’AIPD spécifique aux systèmes d’IA lorsque le projet vise l’entraînement d’un modèle.

Sur ce dernier point, l’EDPB a annoncé des travaux destinés à clarifier les notions d’anonymisation et de pseudonymisation dans le contexte de l’EEDS — un chantier qui, pour l’instant, laisse les praticiens avec plus de questions que de réponses.

Le cas français : ORAD, Health Data Hub et SNDS

La France part avec un avantage et une complexité. L’avantage : un écosystème déjà structuré autour du Système national des données de santé (SNDS) et de la Plateforme des données de santé, avec plusieurs milliers de projets instruits. La complexité : cet écosystème a été bâti sur une logique d’autorisation nationale qui devra être réarticulée avec la procédure européenne.

Le rôle d’ORAD devrait revenir à la Plateforme des données de santé (Health Data Hub), sous réserve d’un ajustement de ses missions. Le sujet a été identifié dans la stratégie nationale IA et données de santé, qui annonce l’examen de plusieurs scénarios et un véhicule législatif en 2026. Les entrepôts de données de santé hospitaliers, eux, ont vocation à être reconnus comme détenteurs de confiance, avec une délégation partielle des missions de l’ORAD.

Deux points de vigilance pour les acteurs français :

• L’hébergement. Les données traitées dans les environnements sécurisés doivent rester dans l’Union. Cela ne dispense pas de la certification HDS pour l’hébergement des données de santé, ni des interrogations récurrentes sur l’exposition aux injonctions étrangères visées à l’article 48 du RGPD lorsque l’hébergeur relève d’un groupe extra-européen. La qualification SecNumCloud reste, sur ce terrain, l’exigence la plus protectrice.
• La cybersécurité. Les établissements de santé sont par ailleurs des entités essentielles ou importantes au sens de NIS2. L’ouverture des flux de données imposée par l’EEDS augmente mécaniquement la surface d’attaque. Les deux chantiers doivent être menés ensemble, pas en silos.

Sanctions : un régime calqué sur le RGPD

L’article 64 organise deux plafonds, dans une logique familière aux praticiens des sanctions RGPD.

Type de manquement	Plafond
Manquements « simples » — par exemple, le détenteur ne met pas les données à disposition malgré une autorisation valide, ou ne transmet pas la description annuelle de ses jeux de données	10 M€ ou 2 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu
Manquements graves — notamment le traitement pour une finalité interdite par l’article 54, ou la réidentification de personnes à partir de données anonymisées	20 M€ ou 4 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu

Ces plafonds s’ajoutent, le cas échéant, à ceux du RGPD. Un même fait — par exemple une réidentification illicite — peut relever des deux régimes. Comme pour les sanctions Data Act, l’articulation entre autorités et le principe non bis in idem devront être précisés en droit national.

Que faire maintenant : sept chantiers à ouvrir

Trois ans avant l’échéance de 2029, voici l’ordre dans lequel je recommande de traiter le sujet.

1. Qualifier sa position. Êtes-vous détenteur de données, utilisateur de données, éditeur de système de DME — ou plusieurs à la fois ? Un CHU est les trois. Cette qualification détermine tout le reste. Vérifiez au passage l’exonération microentreprise.
2. Cartographier les jeux de données. Quelles données de l’article 51 détenez-vous, où, dans quel format, sous quelle responsabilité ? Le registre des traitements est un bon point de départ mais ne suffit pas : il faut passer d’une vue « traitements » à une vue « jeux de données » avec métadonnées, volumétrie et qualité.
3. Identifier les droits opposables. Sur quels jeux de données détenez-vous des droits de propriété intellectuelle, un secret des affaires ou un droit de producteur de bases ? Documentez-les maintenant, avec les éléments de preuve. C’est le seul levier de refus prévu par le texte.
4. Chiffrer les coûts de mise à disposition. Les redevances de l’article 62 devront être justifiées ligne à ligne. Commencez à instrumenter la mesure des coûts d’extraction, de pseudonymisation et d’anonymisation.
5. Préparer la mécanique d’opt-out. Testez la capacité de vos systèmes à porter et propager une opposition individuelle jusqu’aux extractions. C’est le chantier technique le plus long.
6. Auditer les contrats. Contrats de recherche, conventions hospitalo-universitaires, contrats fournisseurs, clauses de sous-traitance au sens de l’article 28 : la plupart ne prévoient rien sur la mise à disposition obligatoire, ni sur la répartition des redevances. Les renouvellements des trois prochaines années doivent intégrer ces clauses.
7. Rattacher le sujet à une gouvernance. Le DPO est le point d’entrée naturel, mais l’EEDS déborde largement son périmètre — direction de la recherche, DSI, direction juridique, propriété intellectuelle. Nommez un pilote et un comité.

Cette conversion d’une cartographie RGPD existante en inventaire de jeux de données exploitable est exactement le type de travail que Legiscope automatise.

Ce qu’il faut retenir

• L’EEDS crée une obligation de partage, pas une faculté. Les détenteurs de données de santé établis dans l’Union devront mettre leurs jeux de données à disposition sur autorisation d’un organisme national, sous peine d’amendes jusqu’à 20 M€ ou 4 % du chiffre d’affaires mondial.
• Le calendrier est en cascade : application générale le 26 mars 2027, cœur du régime d’utilisation secondaire le 26 mars 2029, données génétiques et d’essais cliniques le 26 mars 2031.
• L’accès est encadré, pas libre : finalités limitativement énumérées à l’article 53, finalités interdites à l’article 54, autorisation délivrée en trois mois par l’ORAD, traitement en environnement sécurisé dans l’Union.
• Le RGPD continue de s’appliquer intégralement. L’EEDS s’y superpose : bases légales, minimisation, sécurité, AIPD et compétence de la CNIL restent inchangées.
• En France, l’ORAD devrait être la Plateforme des données de santé, avec un projet de loi d’adaptation attendu en 2026 et une reconnaissance probable des entrepôts hospitaliers comme détenteurs de confiance.
• Les trois chantiers à ouvrir dès maintenant : cartographie des jeux de données, documentation des droits de propriété intellectuelle et du secret des affaires, et capacité technique à porter l’opt-out.

Suivez l’application de l’EEDS et des règlements européens sur les données. Recevez nos analyses de conformité chaque semaine — décryptages, échéances et documents types, sans bruit.

FAQ

L’EEDS s’applique-t-il déjà aux hôpitaux et aux laboratoires français ?

Non, pas encore au sens opérationnel. Le règlement est en vigueur depuis le 26 mars 2025, mais ses obligations deviennent applicables à partir du 26 mars 2027, et l’essentiel du régime d’utilisation secondaire le 26 mars 2029. En revanche, les chantiers de cartographie et de mise en conformité contractuelle doivent être engagés dès maintenant compte tenu de leur durée.

Un patient peut-il s’opposer à ce que ses données servent à la recherche ?

Oui. L’article 71 institue un droit d’opposition à l’utilisation secondaire, exerçable à tout moment, sans avoir à se justifier, et réversible. Il ne vaut toutefois que pour l’avenir : il ne remet pas en cause les autorisations déjà délivrées. Les États membres pourront prévoir des exceptions limitées, notamment pour des motifs d’intérêt public en santé publique.

Peut-on refuser de communiquer des données couvertes par le secret des affaires ?

Pas directement. Le détenteur doit signaler ses droits de propriété intellectuelle, son secret des affaires ou son droit de producteur de bases de données et justifier précisément le risque encouru. C’est ensuite l’ORAD qui décide : il peut imposer des mesures de protection contractuelles ou techniques, et ne refuse l’accès qu’en cas de risque grave qui ne peut pas être atténué autrement.

Une petite structure de santé est-elle concernée par l’obligation de partage ?

Les microentreprises sont exonérées de l’obligation de mise à disposition pour l’utilisation secondaire : moins de dix personnes et un chiffre d’affaires ou un total de bilan annuel n’excédant pas 2 millions d’euros. Attention toutefois : cette exonération ne couvre pas le volet utilisation primaire, qui impose des obligations de numérisation et d’accès patient à l’ensemble des professionnels de santé.

Quelle différence entre l’ORAD et la CNIL ?

L’ORAD (organisme responsable de l’accès aux données) délivre les autorisations d’accès aux données de santé pour l’utilisation secondaire et organise la mise à disposition. La CNIL reste l’autorité de contrôle en matière de protection des données personnelles : elle conserve ses pouvoirs d’enquête et de sanction sur le fondement du RGPD, indépendamment de l’autorisation délivrée par l’ORAD.

L’EEDS autorise-t-il l’entraînement de modèles d’IA sur des données de santé ?

Oui, l’article 53 mentionne expressément l’entraînement, le test et l’évaluation d’algorithmes, y compris de systèmes d’intelligence artificielle, parmi les finalités autorisées. L’accès reste soumis à autorisation, au traitement en environnement sécurisé, et au respect du RGPD ainsi que des obligations de l’AI Act applicables aux systèmes concernés.