FRIA du règlement sur l’IA : analyse d’impact sur les droits fondamentaux

Vous construisez un dispositif médical ? Une FRIA ne s’y applique en général pas, voir Avez-vous besoin d’une FRIA pour l’IA médicale ?.

L’essentiel, les faits clés de l’obligation FRIA

• Qui doit la mener : les organismes de droit public, les entités privées fournissant des services publics, et les déployeurs de systèmes d’IA à haut risque visés à l’annexe III, points 5, b) et c) (solvabilité et assurance vie / santé). Les établissements d’enseignement publics tombent en pratique dans le premier groupe.
• Quand : avant la mise en service du système d’IA à haut risque. C’est une condition du déploiement licite, pas un exercice après coup.
• Ce qu’elle couvre : l’ensemble des droits fondamentaux de la Charte de l’UE, pas seulement la protection des données. Dignité, non-discrimination, liberté d’expression, droits de l’enfant, intégration des personnes handicapées, recours effectif, et d’autres encore.
• Écart avec une AIPD : une analyse d’impact relative à la protection des données (AIPD) au titre du RGPD ne couvre que les risques pour les données à caractère personnel. Une FRIA couvre les droits fondamentaux plus largement, y compris lorsqu’aucune donnée à caractère personnel n’est traitée.
• Peut-on la combiner avec une AIPD ? Oui. L’article 27, paragraphe 4 prévoit que la FRIA complète l’AIPD lorsque certaines obligations sont déjà satisfaites par celle-ci ; dans la pratique, un document unique à deux volets est la voie la plus propre.
• Notification : les résultats de la FRIA doivent être notifiés à l’autorité de surveillance du marché (modèle du Bureau de l’IA). L’enregistrement dans la base de données de l’UE relève de l’article 49.
• Obligation vivante : la FRIA doit être mise à jour lorsque les éléments changent, nouvelle version du système, nouveau contexte de déploiement, ou nouveaux éléments sur l’impact pour les droits fondamentaux.

Qu’est-ce qu’une FRIA et pourquoi elle compte

La FRIA, « analyse d’impact sur les droits fondamentaux », porte le titre officiel « Analyse d’impact des systèmes d’IA à haut risque sur les droits fondamentaux ». C’est l’une des obligations les plus lourdes, et les moins bien comprises, pour certains déployeurs de systèmes d’IA à haut risque au titre du règlement sur l’IA. Elle impose à des catégories précises de déployeurs d’évaluer de façon systématique la manière dont leur utilisation d’un système d’IA à haut risque peut affecter les droits fondamentaux des personnes concernées.

Contrairement à l’analyse d’impact relative à la protection des données (AIPD) du RGPD, la FRIA couvre la pleine étendue de la Charte des droits fondamentaux de l’Union européenne : dignité humaine, non-discrimination, liberté d’expression, recours effectif, droits de l’enfant, intégration des personnes handicapées, et d’autres. Elle existe parce que le législateur de l’Union a reconnu que les systèmes d’IA peuvent nuire aux personnes bien au-delà de la protection des données, par des décisions biaisées, des processus opaques et une discrimination systémique.

Si vous êtes un organisme de droit public, une entité privée fournissant un service public, ou le déployeur d’un système visé à l’annexe III, points 5, b) ou c), ce guide montre comment satisfaire l’obligation avant l’échéance du 2 décembre 2027 (reportée du 2 août 2026 par le Digital Omnibus, règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026). La FRIA est une obligation de déployeur liée à la voie de l’annexe III (article 6, paragraphe 2), pas à la voie produit de l’annexe I.

Qui doit mener une FRIA ?

L’article 27, paragraphe 1 impose une FRIA, avant le déploiement d’un système d’IA à haut risque visé à l’article 6, paragraphe 2 (sauf le domaine de l’annexe III, point 2), aux déployeurs qui sont des organismes de droit public ou des entités privées fournissant des services publics, ainsi qu’aux déployeurs de systèmes d’IA à haut risque visés à l’annexe III, points 5, b) et c).

Catégorie 1 : organismes de droit public

Agences gouvernementales, hôpitaux publics, universités publiques, administrations de l’aide sociale, services publics de l’emploi, autorités municipales, administrations fiscales, juridictions, services de l’immigration, et toute entité exerçant des fonctions de droit public.

Exemple : une commune déploie un système d’IA pour prioriser les demandes de logement social. Le système classe les demandeurs selon l’urgence et le besoin, et touche directement l’accès au logement, un droit fondamental au titre de l’article 34 de la Charte (sécurité sociale et aide sociale).

Catégorie 2 : entités privées fournissant des services publics, et déployeurs visés aux points 5, b) et c)

Cela recouvre, selon le droit de l’Union ou le droit national, des acteurs de la banque et du crédit, des entreprises d’assurance, des fournisseurs d’énergie, des services d’eau, des opérateurs de transport, des fournisseurs de télécommunications, des acteurs de la santé numérique, et d’autres qui fournissent un service public. S’y ajoutent, par le texte même de l’article 27, les déployeurs de systèmes d’évaluation de la solvabilité ou de cote de crédit (annexe III, point 5, b)) et d’évaluation des risques et de tarification en assurance vie et assurance maladie (point 5, c)).

Exemple : une banque de détail déploie un système d’IA tiers d’évaluation du risque de crédit. Le système examine les demandes de prêt et produit une évaluation du risque qui influe directement sur l’accès au crédit, donc sur la participation économique, la non-discrimination (article 21 de la Charte) et, éventuellement, le droit de propriété (article 17 de la Charte).

Catégorie 3 : établissements d’enseignement et de formation professionnelle

Écoles, universités et organismes de formation qui déploient des systèmes d’IA à haut risque pour évaluer des élèves ou étudiants, orienter les apprentissages, décider des admissions ou allouer des ressources éducatives. Ils sont visés lorsqu’ils sont organismes de droit public ou fournissent un service public, ce qui est le cas habituel des établissements publics. L’article 27 n’érige pas l’enseignement en troisième branche autonome, distincte de ces deux critères.

Exemple : une université publique utilise un système d’IA pour trier les candidatures en master et classer les candidats. Le système touche le droit à l’éducation (article 14 de la Charte), la non-discrimination (article 21) et, éventuellement, la liberté professionnelle (article 15).

Si aucune de ces situations ne vous concerne, la FRIA n’est pas légalement obligatoire. Une analyse volontaire des droits fondamentaux reste une bonne pratique et peut renforcer votre posture d’ensemble au titre des obligations du déployeur.

Quand la FRIA doit-elle être achevée ?

La FRIA doit être achevée avant la mise en service du système d’IA à haut risque. C’est une condition préalable, pas un exercice après déploiement. Déployer d’abord et évaluer ensuite est une violation directe de l’article 27.

L’analyse doit être mise à jour dès que :

• l’usage ou le contexte de déploiement du système change de façon substantielle
• de nouvelles informations apparaissent sur l’impact du système pour les droits fondamentaux
• le système est modifié de façon significative (nouvelle version, nouvelles données d’entraînement, paramètres changés)
• la surveillance après mise sur le marché révèle des impacts inattendus
• la population concernée change (nouveaux groupes, nouveau périmètre géographique)

Tous les champs obligatoires de la FRIA

L’article 27, paragraphe 1, points a) à f), fixe le contenu minimal de toute FRIA. L’article 27, paragraphe 3, porte sur la notification à l’autorité de surveillance du marché, pas sur une liste de quinze champs. Les points 1 à 6 ci-dessous reprennent le texte ; les points 7 à 15 sont des compléments pratiques que les autorités s’attendront souvent à voir.

1. Description des processus du déployeur dans lesquels le système d’IA à haut risque sera utilisé, conformément à sa destination (art. 27, § 1, a)). Décrivez le déroulement opérationnel concret, pas seulement ce que le système fait dans l’abstrait, mais la place qu’il occupe dans votre processus de décision.

2. Période et fréquence auxquelles le système est destiné à être utilisé (art. 27, § 1, b)), avec le périmètre géographique, temporel et démographique. Indiquez si l’usage est continu, périodique ou déclenché par des événements. Précisez les lieux, les périodes et les groupes de population couverts.

3. Catégories de personnes physiques et groupes susceptibles d’être concernés par l’utilisation du système dans le contexte spécifique (art. 27, § 1, c)). Identifiez les sujets directs (les personnes que l’IA évalue) et les sujets indirects (les personnes affectées par des décisions prises à partir des sorties de l’IA).

4. Risques spécifiques de préjudice susceptibles d’avoir une incidence sur les catégories identifiées, compte tenu des informations fournies par le fournisseur au titre de l’article 13 (art. 27, § 1, d)). Prenez la notice d’utilisation du fournisseur comme base, puis complétez par votre propre analyse des risques propres à votre contexte de déploiement.

5. Description de la mise en œuvre des mesures de contrôle humain, conformément à la notice d’utilisation (art. 27, § 1, e)). Précisez qui exerce le contrôle, ses qualifications, les outils dont il dispose, et les circonstances dans lesquelles il peut écarter le système.

6. Mesures à prendre en cas de matérialisation des risques, y compris les dispositifs de gouvernance interne et les mécanismes de plainte internes (art. 27, § 1, f)). Cela inclut les voies d’escalade, les procédures de réparation, et la manière dont les personnes concernées peuvent contester une décision influencée par l’IA.

7. Droits fondamentaux potentiellement affectés, en renvoyant à des droits précis de la Charte (voir le tableau ci-dessous). Ce n’est pas un tiret du paragraphe 1, mais c’est le cœur de l’exercice.

8. Évaluation de la probabilité et de la gravité pour chaque risque identifié : quelle est la chance que le risque se matérialise, et quelle serait la gravité de l’impact pour les personnes ou groupes concernés.

9. Apports des parties prenantes, lorsque c’est pertinent : le déployeur devrait prendre en compte l’avis de représentants des personnes ou groupes susceptibles d’être concernés.

10. Procédures de suivi, comment le déployeur suivra l’impact du système sur les droits fondamentaux pendant le fonctionnement, y compris les indicateurs, la fréquence et les responsables.

11. Voies d’escalade, procédures claires lorsque le suivi révèle des impacts inattendus : qui est informé, quelles actions sont prises, quels seuils déclenchent l’escalade.

12. Protocoles de conservation, comment la documentation de la FRIA, les données de suivi et l’historique des mises à jour seront tenus et mis à disposition des autorités.

13. Calendriers de réexamen, fréquence des réexamens périodiques de la FRIA, y compris les critères qui déclenchent un réexamen hors cycle.

14. Attribution des responsabilités, rôles ou fonctions nommément responsables de la FRIA, du suivi continu et des mises à jour.

15. Articulation avec la gouvernance existante, comment la FRIA se relie aux structures de gestion des risques, de conformité et de gouvernance déjà en place (y compris la gouvernance RGPD, le cas échéant).

Identifier les droits fondamentaux concernés dans la Charte

La FRIA exige d’identifier quels droits précis de la Charte peuvent être affectés. C’est le point où la plupart des déployeurs sous-dimensionnent l’analyse. Les droits suivants sont les plus souvent engagés par des systèmes d’IA à haut risque :

Ne limitez pas l’analyse aux droits qui vous semblent les plus évidents. Les évaluateurs attendent une cartographie complète. Un système d’évaluation de la solvabilité n’affecte pas seulement le droit de propriété : il peut aussi toucher la non-discrimination (article 21), l’égalité en droit (article 20), la vie privée (article 7, s’il utilise des données financières personnelles), et éventuellement les droits des personnes âgées et l’intégration des personnes handicapées (s’il désavantage ces groupes de façon systémique).

FRIA et AIPD : comparaison

Lorsque les deux s’appliquent : dès qu’un système d’IA à haut risque traite des données à caractère personnel, les deux analyses sont dues. L’article 27, paragraphe 4, prévoit que la FRIA complète l’AIPD. L’approche pratique est une analyse unifiée à deux volets clairement étiquetés, l’un pour les risques RGPD, l’autre pour les droits plus larges de la Charte. Cela évite la duplication tout en satisfaisant les deux régimes.

Démarche pas à pas : mener une FRIA

Étape 1 : déterminer si une FRIA est requise

Confirmez que votre organisation entre dans le champ de l’article 27, paragraphe 1, et que le système d’IA que vous déployez est classé à haut risque au titre de l’article 6 et de l’annexe III (article 6, paragraphe 2). Si l’une des deux conditions manque, la FRIA n’est pas obligatoire, même si une analyse volontaire reste une bonne pratique. Utilisez l’outil gratuit de classification des risques pour confirmer la classification de votre système.

Étape 2 : délimiter et décrire le système dans votre contexte de déploiement

Documentez ce que fait le système, comment il est utilisé dans votre contexte opérationnel précis, les décisions qu’il étaye ou automatise, et le périmètre géographique et démographique. Partez des informations fournies par le fournisseur dans sa notice d’utilisation, puis allez au-delà : le fournisseur décrit le système en termes généraux ; vous devez le décrire dans votre contexte.

Exemple : un service public de l’emploi qui déploie un système d’IA pour apparier demandeurs d’emploi et offres doit décrire non seulement l’algorithme d’appariement, mais aussi la façon dont les conseillers utilisent les correspondances (les suivent-ils toujours ? peuvent-ils les écarter ?), quels demandeurs sont soumis au système (tous les inscrits, ou certaines catégories ?), et ce qui se passe lorsqu’un demandeur n’est apparié à aucune offre.

Étape 3 : identifier toutes les personnes et tous les groupes concernés

Cartographiez toutes les personnes affectées par les sorties du système, directement et indirectement. Portez une attention particulière à :

• Groupes vulnérables : enfants, personnes âgées, personnes handicapées, personnes en difficulté économique, demandeurs d’asile, personnes peu à l’aise avec le numérique
• Groupes exposés à un impact disproportionné : minorités ethniques, femmes, personnes de certaines convictions religieuses, personnes LGBTQ+, personnes de certains milieux socio-économiques
• Personnes peu en mesure de contester : celles qui peuvent ignorer qu’elles sont soumises à une IA, ou qui n’ont pas les moyens de contester une décision influencée par l’IA

Étape 4 : cartographier les droits fondamentaux concernés

Pour chaque groupe concerné, identifiez quels droits précis de la Charte peuvent être engagés. Partez du tableau ci-dessus. Soyez complets : le règlement attend des déployeurs qu’ils considèrent toute l’étendue de la Charte, pas seulement les droits les plus évidents. Documentez la chaîne causale : comment la sortie du système conduit-elle à un impact sur un droit précis pour un groupe précis ?

Exemple : pour l’IA du service public de l’emploi, les droits concernés incluent : la liberté professionnelle (article 15 de la Charte, si le système restreint les offres montrées à certains demandeurs), la non-discrimination (article 21, si l’algorithme d’appariement désavantage certains groupes), le droit à une bonne administration (article 41, si l’appariement automatisé remplace un suivi individualisé), et la sécurité sociale (article 34, si l’absence d’appariement réduit des prestations).

Étape 5 : évaluer la probabilité et la gravité

Pour chaque risque identifié, estimez :

• Probabilité : quelle est la chance que le risque se matérialise ? Tenez compte des limites connues du système (documentation du fournisseur), de votre contexte de déploiement, du volume de personnes concernées, et de tout précédent de préjudices similaires.
• Gravité : si le risque se matérialise, quelle est la sévérité de l’impact ? Tenez compte de l’irréversibilité (la personne peut-elle s’en remettre ?), du nombre de personnes concernées, de l’importance du droit en jeu, et de l’existence d’un recours effectif.

Utilisez une échelle structurée (par exemple faible / moyen / élevé / critique pour les deux dimensions) et documentez votre raisonnement. Évitez les appréciations qualitatives vagues, sans éléments à l’appui.

Étape 6 : définir les mesures d’atténuation

Pour chaque risque noté au-dessus de « faible », documentez des mesures précises :

• Mesures techniques : suivi de l’exactitude, examen des biais, calibration des seuils, validation des entrées, indicateurs de confiance
• Mesures organisationnelles : procédures de contrôle humain (qui examine, quand, avec quelle autorité), formation du personnel sur les limites du système et les risques de biais, voies d’escalade pour les cas limites
• Mesures procédurales : mécanismes de plainte accessibles aux personnes concernées, voies de recours avec un décideur humain, réexamen périodique des décisions influencées par l’IA
• Mesures de communication : informer les personnes concernées du rôle du système d’IA, expliquer comment contester une décision influencée par l’IA, fournir des points de contact

Étape 7 : mettre en place le suivi, le réexamen et la notification

Suivi :

• Définissez des indicateurs pour suivre l’impact réel après le déploiement (par exemple résultats de décision ventilés par groupe démographique, volumes de plaintes, taux d’écart par les personnes chargées du contrôle).
• Fixez des seuils d’alerte qui déclenchent une investigation.
• Attribuez la responsabilité du suivi continu à un rôle ou une fonction nommé.

Réexamen :

• Fixez un rythme de réexamen, au minimum annuel, ou dès qu’un changement matériel, un incident ou un nouvel élément le justifie.
• Documentez qui mène le réexamen, ce qu’il évalue, et comment les constats sont suivis d’effet.

Notification et enregistrement :

• Au titre de l’article 27, paragraphe 3, notifiez un résumé des résultats de la FRIA à l’autorité de surveillance du marché compétente, en utilisant le modèle visé au paragraphe 5.
• Enregistrez-les dans la base de données de l’UE au titre de l’article 49.
• Conservez la documentation complète de la FRIA en interne et tenez-la à disposition des autorités sur demande.

Scénarios concrets

Scénario 1 : hôpital public déployant une IA diagnostique

Un hôpital public déploie un système d’IA qui aide les radiologues à prioriser les examens d’imagerie selon la gravité suspectée. La FRIA doit évaluer : le risque de mauvaise classification entraînant un retard de traitement (droit à la vie et à l’intégrité de la personne, articles 2 et 3 de la Charte), le risque que le système se comporte différemment selon l’âge ou l’origine des patients (non-discrimination, article 21), le risque que les patients ignorent que la priorité de leur examen a été influencée par une IA (droit à une bonne administration, article 41), et le risque que des patients vulnérables (personnes âgées, personnes handicapées) soient systématiquement dépriorisés si le système a été entraîné sur des données qui les sous-représentent.

Scénario 2 : banque déployant une IA d’évaluation de la solvabilité

Une banque qui déploie un système tiers d’évaluation de la solvabilité doit évaluer : le risque de biais systémique contre des demandeurs de certains codes postaux, tranches d’âge ou types d’emploi (non-discrimination, article 21), le risque que les demandeurs rejetés ne puissent ni comprendre ni contester la décision (droit à un recours effectif, article 47), et le risque que l’appui du système sur des données historiques de prêt encode une discrimination passée. La banque doit aussi coordonner la FRIA avec une AIPD au titre du RGPD, puisque des données financières personnelles sont traitées.

Scénario 3 : université déployant une IA de tri des admissions

Une université qui utilise une IA pour trier et classer les candidatures en master doit évaluer : le risque que le système désavantage des candidats issus de parcours éducatifs non traditionnels (droit à l’éducation, article 14), le risque de biais de genre ou d’origine dans le classement (non-discrimination, article 21), le risque que des candidats en situation de handicap soient désavantagés par des formats de données d’entrée pour lesquels le système n’a pas été conçu (intégration des personnes handicapées, article 26), et le risque que les candidats rejetés n’aient aucun moyen sérieux de comprendre pourquoi ils n’ont pas été retenus.

Coordonner la FRIA et l’AIPD du RGPD

Lorsque le système d’IA à haut risque traite des données à caractère personnel, ce qui est le cas de la plupart des déployeurs, une FRIA et une AIPD sont toutes deux requises. L’article 27, paragraphe 4, du règlement sur l’IA prévoit que la FRIA complète l’AIPD. L’approche recommandée :

1. Un seul document, deux volets. Une structure unifiée, avec un volet AIPD clairement étiqueté (risques RGPD) et un volet FRIA (droits plus larges de la Charte).
2. Identification partagée des risques. Beaucoup de risques se recoupent, biais dans les données à caractère personnel, transparence des décisions automatisées, sécurité des données. Identifiez-les une fois et rattachez-les aux deux régimes.
3. Reconnaissance des étendues distinctes. La FRIA couvre des droits que l’AIPD ne couvre pas (dignité, expression, droits de l’enfant, protection de l’environnement). Ne supposez pas que l’AIPD épuise la FRIA.
4. Consultation coordonnée. Si l’AIPD exige une consultation de l’autorité de protection des données (article 36 du RGPD), et que la FRIA exige une notification à l’autorité de surveillance du marché (article 27, paragraphe 3), coordonnez les deux pour éviter des représentations incohérentes.
5. Suivi unifié. Concevez un seul dispositif de suivi qui trace à la fois les indicateurs de protection des données et les indicateurs d’impact sur les droits fondamentaux.

Pour aller plus loin sur le rapport entre les deux régimes, voir le guide comparatif règlement sur l’IA / RGPD.

Erreurs fréquentes

Erreur 1 : traiter la FRIA comme un exercice de protection des données

La FRIA n’est pas une AIPD sous un autre nom. Elle couvre des droits que le RGPD ne touche pas : dignité, non-discrimination, liberté d’expression, droits de l’enfant, protection de l’environnement, accès à la justice. Si votre FRIA se lit comme une analyse de protection des données qui ne parle que de vie privée et de sécurité des données, elle est incomplète. Cartographiez toute la Charte.

Erreur 2 : achever la FRIA après le déploiement

Le règlement est explicite : la FRIA doit être achevée avant la mise en service du système. Déployer d’abord et évaluer ensuite viole l’article 27, quelle que soit la rapidité de l’analyse après coup. Intégrez l’achèvement de la FRIA comme une porte dans vos processus d’achat et de déploiement.

Erreur 3 : ne pas associer les parties prenantes

L’article 27, lu avec une exigence de sérieux de l’analyse, appelle, lorsque c’est pertinent, l’apport de représentants des personnes concernées. Dans le secteur public, aide sociale, justice, immigration, éducation, cela signifie consulter des organisations de la société civile, des communautés concernées, des représentants de patients, des instances étudiantes, ou leurs représentants désignés. Cet apport n’est pas un ornement ; c’est une exigence de fond que les évaluateurs vérifieront.

Erreur 4 : traiter la FRIA comme un exercice unique

La FRIA doit être mise à jour lorsque les circonstances changent, nouvelles versions, nouveaux usages, nouvelles populations concernées, nouveaux contextes de déploiement, ou nouveaux éléments sur l’impact du système. Une FRIA achevée en 2026 et jamais mise à jour est un écart de conformité dès 2027.

Erreur 5 : utiliser des descriptions de risques génériques

« Il existe un risque de discrimination » ne suffit pas. La FRIA exige une identification précise : quels groupes, quels droits, par quel mécanisme, avec quelle probabilité, et avec quelle gravité. Des énoncés génériques, sans analyse à l’appui, ne satisferont pas un contrôle de l’autorité de surveillance du marché.

Erreur 6 : ne pas se coordonner avec le fournisseur

La FRIA est à la charge du déployeur, mais la documentation du fournisseur au titre de l’article 13, y compris les limites connues, les indicateurs d’exactitude et les risques prévisibles, est un apport essentiel. Les déployeurs qui mènent une FRIA sans lire la notice d’utilisation du fournisseur travaillent avec une information incomplète. Demandez cette documentation et citez-la explicitement dans votre analyse.

Structure pratique d’un document FRIA

Un document FRIA pratique peut suivre cette structure :

1. Page de garde : nom du système, nom du déployeur, date, version, auteur, approbateur
2. Synthèse : une page sur le système, les risques clés et l’appréciation d’ensemble
3. Description du système : destination, contexte de déploiement, déroulement opérationnel, périmètre géographique et démographique (champs 1-2)
4. Cartographie des personnes concernées : sujets directs et indirects, groupes vulnérables, effectifs estimés (champ 3)
5. Cartographie des droits fondamentaux : tableau reliant chaque groupe concerné à des droits précis de la Charte, avec explication causale (champ 7)
6. Évaluation des risques : pour chaque couple droit-groupe : description précise du risque, probabilité, gravité, éléments à l’appui (champs 4, 8)
7. Mesures de contrôle humain : qui, comment, avec quelle autorité, dans quelles circonstances (champ 5)
8. Mesures d’atténuation : techniques, organisationnelles, procédurales et de communication pour chaque risque identifié (champ 6)
9. Apports des parties prenantes : qui a été consulté, quand, quel avis a été reçu, comment il a été intégré (champ 9)
10. Plan de suivi : indicateurs, fréquence, responsabilité, seuils d’alerte (champ 10)
11. Intégration à la gouvernance : comment la FRIA se relie aux processus existants de gouvernance, d’escalade et de réexamen (champs 11-15)
12. Intégration AIPD (le cas échéant) : volet combiné de protection des données
13. Annexes : documentation du fournisseur citée, comptes rendus de consultation, données d’appui

Prochaines étapes

1. Déterminez si votre organisation entre dans le champ de l’article 27, paragraphe 1.
2. Construisez l’inventaire de vos systèmes d’IA et identifiez les systèmes à haut risque que vous déployez.
3. Utilisez la structure de modèle ci-dessus comme point de départ de votre FRIA.
4. Si le système traite aussi des données à caractère personnel, combinez la FRIA avec votre AIPD.
5. Enregistrez les résultats de la FRIA dans la base de données de l’UE avant le déploiement.
6. Parcourez la liste de contrôle 2026 du règlement sur l’IA pour insérer la FRIA dans votre programme de conformité plus large.

Lancez l’évaluation gratuite au titre du règlement sur l’IA pour classer vos systèmes et identifier les obligations applicables, y compris la FRIA.

Pour le texte juridique, voir l’article 27 dans le guide complet du règlement sur l’IA.

Questions fréquentes

La FRIA est-elle obligatoire pour tous les déployeurs de systèmes d’IA à haut risque ?

Non. L’article 27, paragraphe 1, la réserve aux déployeurs qui sont des organismes de droit public ou des entités privées fournissant des services publics, ainsi qu’aux déployeurs de systèmes visés à l’annexe III, points 5, b) et c) (solvabilité, assurance vie et maladie). Les établissements d’enseignement publics y entrent en tant qu’organismes de droit public. Les autres déployeurs de systèmes d’IA à haut risque n’y sont pas légalement tenus, même s’ils restent soumis aux autres obligations du déployeur (contrôle humain, conservation des journaux, information des personnes concernées). Les FRIA volontaires sont une bonne pratique et pourront être attendues par les autorités de surveillance du marché dans de futures orientations.

Puis-je utiliser mon AIPD existante à la place d’une FRIA ?

Non, mais vous pouvez les combiner. Une AIPD ne couvre que les risques liés à la protection des données au titre du RGPD. Une FRIA couvre tous les droits fondamentaux de la Charte, dont beaucoup n’ont rien à voir avec les données à caractère personnel (dignité, non-discrimination, liberté d’expression, droits de l’enfant). L’article 27, paragraphe 4, prévoit que la FRIA complète l’AIPD ; un document unique est l’approche recommandée, mais le volet FRIA doit traiter les droits de la Charte que l’AIPD ne couvre pas.

Que se passe-t-il si je déploie un système d’IA à haut risque sans avoir achevé la FRIA ?

Déployer sans FRIA achevée, lorsqu’elle est due, est une violation directe de l’article 27. Les amendes pour manquement aux obligations du déployeur au titre du règlement sur l’IA peuvent atteindre 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial. Au-delà des amendes, les autorités de surveillance du marché peuvent vous enjoindre de suspendre ou de cesser l’utilisation du système jusqu’à l’achèvement de la FRIA. Voir le guide des sanctions et amendes.

Quelle doit être la précision de la consultation des parties prenantes ?

L’article 27 demande de prendre en compte, « lorsque c’est pertinent », l’apport de représentants des personnes concernées. Le seuil de pertinence n’est pas défini avec précision, mais en pratique : si votre système d’IA touche directement le public (demandeurs d’aide sociale, étudiants, patients, demandeurs d’emploi), la consultation est clairement pertinente. Elle n’exige pas d’audiences publiques formelles ; un échange structuré avec des organisations représentatives, des mécanismes de retour, ou des comités consultatifs peuvent y suffire. Documentez qui a été consulté, quel avis a été reçu, et comment il a influencé l’analyse.

La FRIA doit-elle être rendue publique ?

La FRIA complète n’a pas à être publiée, mais un résumé doit être notifié à l’autorité de surveillance du marché compétente et enregistré dans la base de données de l’UE au titre de l’article 49. Cette base est accessible au public, donc le résumé sera visible. La FRIA interne complète doit être conservée et fournie aux autorités sur demande lors d’un contrôle ou d’une enquête.

Comment la FRIA s’articule-t-elle avec l’évaluation de la conformité ?

La FRIA est une obligation du déployeur ; l’évaluation de la conformité est une obligation du fournisseur. Elles sont juridiquement distinctes, mais liées en pratique. L’évaluation de la conformité et la documentation technique du fournisseur (annexe IV) fournissent un apport essentiel à la FRIA du déployeur, surtout sur les limites connues, les indicateurs d’exactitude et les risques prévisibles. Si le fournisseur n’a pas achevé l’évaluation de la conformité, le déployeur peut manquer des informations nécessaires à une FRIA sérieuse.

Legalithm est un outil d’accompagnement à la conformité assisté par l’IA, ce n’est pas un conseil juridique. Les décisions finales de conformité doivent être revues par un conseil juridique qualifié.