Si vous déployez un agent d'IA dans un processus réglementé (triage des délits financiers, contrôle des paiements, intégration des prêts, règlement des réclamations), vous devez presque certainement effectuer une évaluation d'impact sur la protection des données en vertu de l'article 35 du RGPD (https://eur-lex.europa.eu/eli/reg/2016/679/oj). Et si ce même système présente un risque élevé en vertu de la Loi de l'UE sur l'IA, vous devez également effectuer une évaluation d'impact sur les droits fondamentaux en vertu de l'article 27. Les deux évaluations se chevauchent fortement, la réglementation attend de vous que vous réutilisiez le chevauchement, et pourtant la plupart des équipes les effectuent comme deux exercices administratifs déconnectés qui s'éloignent au moment où le modèle change. Ce guide fait le contraire : il vous donne une structure DPIA qui correspond clairement à votre FRIA (et à votre évaluation des intérêts légitimes) afin que vous produisiez un ensemble de preuves combiné au lieu de trois documents qui se contredisent lors de l'audit. Vous pouvez générer ce pack combiné avec le générateur DPIA + FRIA. La thèse de KLA tout au long : une évaluation d'impact ne vaut le papier sur lequel elle repose que si les contrôles qu'elle promet s'exécutent réellement au moment où l'agent agit : gouvernent par l'exécution, pas par PDF.
Quand une DPIA est-elle obligatoire pour un système d'IA ?
Une DPIA n’est pas une bureaucratie facultative. L'article 35(1) impose une obligation légale avant le début du traitement chaque fois que le traitement ("notamment utilisant les nouvelles technologies") est susceptible d'entraîner un risque élevé pour les droits et libertés des personnes physiques. Les agents d’IA qui agissent sur les données personnelles dans un flux de travail réglementé sont proches du cas paradigmatique que les rédacteurs avaient en tête.
L'article 35(3) énumère trois déclencheurs statutaires, dont chacun rend une DPIA obligatoire. L'article 29 Working Party guidance (WP248) (approuvé par l'EDPB) ajoute neuf critères et une règle générale : si votre traitement en répond à deux ou plus, traitez une DPIA comme requis. Les autorités nationales de contrôle publient également leurs propres "listes noires" de traitements qui en ont toujours besoin. Le tableau ci-dessous présente les critères les plus souvent utilisés par les agents d'IA dans les services financiers et l'assurance voyage.
Le point pratique à retenir pour un déployeur d'IA réglementé : ne passez pas une semaine à vous demander si vous êtes techniquement obligé. Si votre agent dresse le profil des personnes, les note ou alimente une décision qui affecte l'accès au crédit, aux paiements ou au paiement d'une assurance, vous êtes presque certainement dans le champ d'application : documentez la sélection et passez au fond.
| Déclencheur | Source | Scénario typique d'un agent IA qui le frappe |
|---|---|---|
| Évaluation ou profilage systématique et approfondi, basé sur un traitement automatisé, sur lequel sont basées les décisions | Art. 35(3)(a) | Agent de surveillance des transactions qui évalue les clients pour leur risque de criminalité financière ; notation de fraude comportementale |
| Décisions produisant des effets juridiques ou d'importance similaire sur la personne | Art. 35(3)(a) / Art. 22 | Décision automatisée d'intégration des prêts ; acceptation ou refus automatisé des réclamations |
| Traitement à grande échelle de données particulières ou pénales | Art. 35(3)(b) | Contrôle AML contre les sanctions/médias indésirables qui déduisent l'origine ethnique, la visibilité politique ou les antécédents criminels |
| surveillance systématique d'une zone accessible au public à grande échelle | Art. 35(3)(c) | Moins courant pour les agents de back-office ; pertinent pour l'intégration de l'identité/biométrique |
| Correspondance ou combinaison d'ensembles de données | WP248 | Enrichissement d'un dossier de candidat en joignant les données KYC, d'appareil et de bureau tiers |
| Données concernant les personnes concernées vulnérables | WP248 | Tarification du crédit de détail ou de l'assurance affectant les consommateurs ayant un pouvoir de négociation limité |
| Utilisation innovante de nouvelles solutions technologiques | WP248 | Déployer un système de décision basé sur LLM ou agent : un signal quasi-automatique |
Ce qu'une DPIA doit réellement contenir : Article 35(7)
L'article 35(7) est court et prescriptif. Une DPIA conforme contient au moins quatre éléments, et un régulateur recherchera chacun d'eux explicitement, sans être enfoui dans le récit.
Deux tâches procédurales accompagnent le contenu. En vertu de l'article 35(2), le responsable du traitement doit demander l'avis du délégué à la protection des données, et en vertu de l'article 35(9) doit, le cas échéant, demander l'avis des personnes concernées ou de leurs représentants. Pour un système agent, l’approbation du DPO et l’enregistrement des personnes consultées font partie des preuves et non une réflexion après coup. Et selon Article 36, si le risque résiduel reste élevé après atténuation, vous devez consulter l'autorité de contrôle avant la mise en service.
Les quatre éléments de contenu obligatoires sont :
- (a) Une description systématique des traitements envisagés et des finalités du traitement, y compris, le cas échéant, l'intérêt légitime poursuivi par le responsable du traitement.
- (b) Une évaluation de la nécessité et de la proportionnalité des opérations de traitement par rapport aux finalités : la partie ignorée par la plupart des DPIA et la partie la plus susceptible d'échouer lors de l'audit.
- (c) Une évaluation des risques pour les droits et libertés des personnes concernées.
- (d) Les mesures envisagées pour faire face aux risques, y compris les garanties, les mesures de sécurité et les mécanismes pour garantir la protection des données personnelles et démontrer la conformité.
Le chevauchement : où la DPIA et la FRIA sont le même document
La loi européenne sur l'IA ne vous demande pas de repartir de zéro. L'article 27(4) est explicite : lorsque les obligations de la FRIA sont déjà remplies par une AIPD menée en vertu de l'article 35 GDPR, la FRIA "doit compléter" cette analyse d'impact sur la protection des données. Autrement dit, le législateur attend du réemploi, et pénalise les duplications qui dérivent.
Les deux évaluations ne sont pas identiques. Une DPIA est une obligation de contrôleur concernant les données personnelles ; a FRIA est une obligation de déployeur concernant tous les droits fondamentaux énoncés dans la Charte européenne : y compris les droits qui n'ont rien à voir avec la protection des données, comme la non-discrimination, la dignité humaine et l'accès à un recours effectif. La FRIA est plus large et elle doit être évaluée à juste titre (vous ne pouvez pas compenser un préjudice de discrimination par un gain d'efficacité). Mais l’épine dorsale structurelle (décrire le système, le justifier, identifier les risques, énoncer les mesures d’atténuation) est partagée presque élément par élément.
Le tableau ci-dessous mappe chaque élément DPIA de l'article 35(7) à son homologue de l'article 27(1) FRIA. Lorsqu'une cellule indique FRIA uniquement, il s'agit d'un contenu que la DPIA ne capture pas et que vous devez ajouter. Traitez les lignes partagées comme écriture unique : créez-les dans le pack combiné et référencez-les à partir des deux évaluations plutôt que de les copier.
| Élément de la DPIA : art du RGPD. 35(7) | Élément FRIA : Loi sur l'IA Art. 27(1) | Statut de réutilisation |
|---|---|---|
| (a) Description systématique du traitement et des finalités | (a) Description des processus du déployeur dans lesquels le système à haut risque sera utilisé ; (b) période et fréquence d'utilisation prévue | Partagé : une description de système/processus sert à la fois |
| Catégories de personnes concernées et de données personnelles (dans la description (a)) | (c) Catégories de personnes physiques et de groupes susceptibles d'être concernés | Partagé : étendre la liste des personnes concernées aux groupes concernés pour FRIA |
| (b) Évaluation de la nécessité et de la proportionnalité | Implicite dans l'art. 27 context-of-use ; renforcé par la proportionnalité de la Charte | Partagé : le raisonnement de nécessité/proportionnalité est transversal |
| (c) Risques pour les droits et libertés des personnes concernées | (d) Risques spécifiques de préjudice susceptibles d'avoir un impact sur les personnes et les groupes concernés | Partagé mais élargi : FRIA couvre tous les droits de la Charte, pas seulement la protection des données |
| (d) Mesures, garanties et sécurité pour faire face aux risques | (f) Mesures de gouvernance, y compris la surveillance humaine, et (g) modalités de plainte/recours | Partagé mais élargi : FRIA exige explicitement une surveillance humaine et des mesures de réparation |
| Avis du DPO (Art. 35(2)); opinions des personnes concernées (Art. 35(9)) | (e) Mesures de surveillance humaine conformément aux instructions d'utilisation | Partiellement partagé : conserver une seule fois le dossier de consultation, satisfaire aux deux |
| , (non requis par le RGPD) | Notification de la FRIA à l'autorité de surveillance du marché (Art. 27(3)) | FRIA uniquement : ajouter cette étape ; pas d'équivalent DPIA |
Intégration de l'évaluation des intérêts légitimes (LIA)
Si votre base légale pour le traitement est des intérêts légitimes en vertu de l'article 6(1)(f) (commun pour la détection de fraude et la LBC, que les considérants du RGPD reconnaissent expressément comme des intérêts légitimes), vous devez également une évaluation des intérêts légitimes. La bonne nouvelle : la LIA n’est pas un troisième silo. Ses emplacements de test en trois parties s'insèrent directement dans le DPIA que vous êtes déjà en train d'écrire.
Le test de finalité de la LIA (y a-t-il un intérêt légitime ?) et le test de nécessité (le traitement est-il nécessaire pour cela ?) sont la même analyse qu'exige l'article 35(7)(b). Le test d'équilibre de la LIA (l'intérêt l'emporte-t-il sur les droits de la personne concernée, compte tenu de ses attentes raisonnables ?) est une version plus précise de l'évaluation des risques de l'article 35(7)(c). Créez l'intérêt légitime une fois dans la description systématique de votre DPIA (l'article 35(7)(a) l'invite explicitement : "y compris, le cas échéant, l'intérêt légitime poursuivi"), et référencez-le à partir de la sortie du générateur LIA.
Une mise en garde spécifique aux agents IA : un agent piloté par LLM peut tranquillement étendre le objectif du traitement à mesure que vous ajoutez des outils et du contexte. Un intérêt légitime évalué pour "l'examen des transactions par rapport aux listes de sanctions" ne couvre pas automatiquement "le profilage du style de vie du client à partir des récits de transaction." Le test de mise en balance doit être réexécuté lorsque l'objectif effectif de l'agent change, c'est exactement pourquoi l'évaluation ne peut pas vivre uniquement dans un document statique.
Un ensemble de preuves combiné, et pourquoi il doit être en ligne
Exécuter la DPIA, la FRIA et la LIA dans trois fichiers Word distincts est la façon dont les équipes finissent par défendre les contradictions dans un audit : la DPIA promet un examen humain, la FRIA décrit un modèle de surveillance différent et la LIA équilibre un objectif qu'aucun des autres ne mentionne. Le correctif est un pack de preuves combiné unique avec des sections partagées à écriture unique et trois superpositions spécifiques à l'évaluation. Construisez-le avec le générateur DPIA + FRIA, qui produit les éléments Article 35(7) et Article 27(1) comme un seul document mappé.
Mais le problème le plus difficile n'est pas la création : c'est la dérive. Une analyse d’impact décrit le système tel qu’il était le jour où vous l’avez rédigé. Dès que quelqu’un ajoute un outil à l’agent, échange le modèle ou élargit son accès aux données, l’évaluation est obsolète et une DPIA obsolète est non conforme. Il s'agit de la position fondamentale de l'KLA : gouverner par l'exécution, pas par la paperasse. Les atténuations promises par votre DPIA (examen humain des décisions à fort impact, blocages des données hors champ, escalade lorsque la confiance est faible) ne doivent pas être des phrases dans un PDF ; il doit s'agir de contrôles exécutés lorsque l'agent agit.
Dans le plan de contrôle KLA, ce mappage est concret. Les mesures auxquelles vous vous engagez dans l'article 35(7)(d) et dans l'article 27(1)(f) de la FRIA deviennent des Policy Builder portes avec des décisions explicites (autoriser, avertir, require_approval ou bloquer. Les modalités de surveillance humaine et de réparation (FRIA Art. 27(1)(e)–(g)) devient un Decision Desk approbation par deux personnes des décisions qui ont un effet juridique ou significatif. Et chaque action fermée) ce que l'agent a fait, quelle politique a été déclenchée, qui a approuvé : atterrit dans le Evidence Room sous la forme d'un dossier d'exécution scellé et inviolable. C'est la différence entre une évaluation qui réclame une sauvegarde et un ensemble de preuves qui peuvent prouver que la sauvegarde a été appliquée sur une transaction spécifique à un moment précis.
La lacune du modèle de l'article 27(5) et comment agir maintenant
L'article 27(5) demande au Bureau de l'IA de développer un modèle de questionnaire (comprenant un outil automatisé) pour aider les déployeurs à réaliser la FRIA de manière simplifiée. Depuis le 2026 juin, ce modèle n'a pas été publié. Les déployeurs qui demandent "devrions-nous attendre le format officiel ?" posent la mauvaise question : l'obligation n'attend pas le modèle et les éléments de contenu sous-jacents de l'article 27(1) sont déjà fixés dans le règlement.
Il existe un deuxième point de timing. L'Omnibus numérique sur l'IA de l'UE, adopté le 29 juin 2026, a déplacé les obligations autonomes à haut risque de l'annexe III, y compris l'article 27 FRIA, du 2 août 2026 to 2 décembre 2027. Considérez le report comme une commodité de planification et continuez à élaborer l’évaluation. (Voir le guide des modèles FRIA pour une image complète de la date limite.)
La voie pragmatique consiste donc à s'appuyer sur la structure qui est stable aujourd'hui : le squelette de l'article 35(7) du RGPD, mappé à l'article 27(1) éléments comme dans le tableau ci-dessus. Lorsque le modèle AI Office arrive, vous réexportez dans son format, mais votre substance, votre analyse des risques et vos preuves sont déjà terminées et déjà en cours d'exécution.
Foire aux questions
Une DPIA est-elle toujours requise pour un système d'IA ?
Pas littéralement toujours, mais très souvent. Une DPIA est obligatoire en vertu de l'article 35(1) du RGPD chaque fois que le traitement est susceptible d'entraîner un risque élevé pour les droits et libertés des personnes, en particulier en utilisant les nouvelles technologies. L'article 35(3) répertorie trois déclencheurs automatiques (profilage systématique qui alimente les décisions, données de catégories spéciales à grande échelle et surveillance publique à grande échelle) et les lignes directrices WP248 traitent deux ou plusieurs de ses neuf critères comme un seuil. La plupart des agents d’IA réglementés qui profilent, notent ou conduisent à une décision conséquente ont atteint au moins un déclencheur. La solution par défaut consiste donc à supposer qu’une DPIA est requise et à documenter votre sélection.
Quelle est la différence entre une DPIA et une FRIA ?
Une DPIA (article 35 du RGPD) est une obligation de contrôleur axée sur les risques pour les données personnelles et la vie privée. Une FRIA (EU AI Act Article 27) est une obligation de déployeur axée sur tous les droits fondamentaux de la Charte européenne (y compris la non-discrimination, la dignité humaine et l'accès aux recours) et s'applique même lorsque peu ou pas de données personnelles sont impliquées. Ils partagent une épine dorsale structurelle (décrire, justifier, évaluer les risques, atténuer), c'est pourquoi l'article 27(4) indique qu'une FRIA devrait compléter une DPIA existante plutôt que de la dupliquer.
Un document peut-il satisfaire à la fois à la DPIA et à la FRIA ?
Vous pouvez satisfaire les deux avec un pack de preuves combinées qui contient des sections partagées à écriture unique ainsi que des superpositions spécifiques à l'évaluation, et l'article 27(4) encourage activement la réutilisation. Mais ils ne sont pas interchangeables : la FRIA est plus large (tous les droits de la Charte, évalués droit par droit) et ajoute des étapes qui manquent à la DPIA, comme la notification à l'autorité de surveillance du marché en vertu de l'article 27(3). Alors mappez-les ensemble, mais gardez les deux évaluations distinctement adressables.
Quels sont les quatre éléments requis d'une AIPD en vertu de l'article 35(7) ?
(a) une description systématique du traitement et de ses finalités, y compris tout intérêt légitime poursuivi ; (b) une évaluation de la nécessité et de la proportionnalité du traitement par rapport à ces finalités ; (c) une évaluation des risques pour les droits et libertés des personnes concernées ; et d) les mesures envisagées pour faire face à ces risques, y compris les garanties et la sécurité. Parallèlement à cela, l'article 35(2) exige l'avis du DPO et l'article 35(9) exige de rechercher l'avis des personnes concernées, le cas échéant.
Le Bureau d'IA a-t-il déjà publié le modèle d'article 27 FRIA ?
Non. Depuis le 2026 le juin, le Bureau d'AI n'a pas publié le modèle de questionnaire ni l'outil automatisé envisagés par l'article 27(5). L'obligation elle-même ne dépend pas de ce modèle (les éléments de contenu sont fixés dans l'article 27(1)), l'approche pratique consiste donc à s'appuyer maintenant sur la structure stable de l'article 35(7) du RGPD et à la réexporter dans le format officiel lors de sa publication.
Comment une évaluation des intérêts légitimes s'intègre-t-elle dans la DPIA ?
Si votre base juridique est constituée d'intérêts légitimes en vertu de l'article 6(1)(f) (commun pour la fraude et la LBC), le test en trois parties de la LIA (objectif, nécessité, équilibre) correspond directement à la DPIA. Les tests d'objet et de nécessité sont l'analyse de nécessité et de proportionnalité de l'article 35(7)(b), et le test de mise en balance affine l'évaluation des risques de l'article 35(7)(c). Créez l'intérêt légitime une fois dans la description systématique de la DPIA, ce que l'article 35(7)(a) invite explicitement, et faites-y référence à partir de votre LIA.
Points clés à retenir
Une DPIA, une FRIA et une LIA ne sont pas trois tâches concurrentes : ce sont trois points de vue sur la même question : ce système d'IA est-il nécessaire, proportionné et correctement régi avant d'agir sur une personne réelle ? L'article 35(7) du RGPD vous offre l'échafaudage le plus stable et testé par les régulateurs disponible aujourd'hui, et l'article 27(4) vous demande pratiquement de construire votre FRIA par-dessus plutôt qu'à côté. Cartographiez les éléments une fois, intégrez l’analyse des intérêts légitimes et vous obtenez un seul ensemble de preuves combinées au lieu de trois documents qui s’éloignent les uns des autres. La dernière étape est celle que les documents ne peuvent jamais fournir à eux seuls : les mesures d'atténuation que vous vous engagez à exécuter (comme portes, comme approbations à deux, comme dossiers d'exécution scellés) au moment où l'agent agit. Démarrez l'évaluation combinée avec le générateur DPIA + FRIA et créez les contrôles afin que les preuves fassent leurs preuves.