Vos 129 questions, classées par thématique.

Partiellement, et le report n'est pas encore juridiquement acquis. Le 7 mai 2026, le Conseil, le Parlement et la Commission sont parvenus à un accord provisoire (« Digital Omnibus ») décalant les obligations haut risque de l'annexe III au 2 décembre 2027. Cet accord doit encore être formellement adopté et publié au Journal officiel pour produire ses effets — adoption attendue avant le 2 août 2026. À défaut, le calendrier d'origine s'applique. Le socle déjà en vigueur (littératie IA, transparence GPAI, interdictions, gouvernance) reste applicable, et les pouvoirs de sanction s'activent au 2 août 2026.

C'est un paquet législatif européen visant à simplifier le cadre numérique de l'UE. Le 7 mai 2026, les co-législateurs ont conclu un accord politique provisoire décalant les échéances les plus lourdes de l'AI Act, sans suspendre les obligations déjà en vigueur. L'accord attend son adoption formelle et sa publication au Journal officiel.

La littératie IA (article 4), les obligations de transparence des modèles GPAI, les interdictions de pratiques prohibées, la gouvernance institutionnelle, et l'activation des pouvoirs de sanction.

Jusqu'à 35 M€ ou 7 % du chiffre d'affaires mondial pour les manquements les plus graves. Un premier palier atteint 15 M€ ou 3 % du CA, et couvre désormais les manquements aux obligations d'information dans la chaîne de valeur.

Si vous développez, déployez ou utilisez des systèmes d'IA (y compris des chatbots, copilotes ou IA générative), oui. L'obligation de littératie IA concerne toutes les organisations utilisatrices.

C'est l'obligation de garantir un niveau suffisant de compétence en IA chez les personnes qui utilisent ou supervisent des systèmes d'IA. Elle est applicable depuis février 2025.

C'est l'usage d'outils d'IA non autorisés ou non encadrés par l'organisation. En 2026, 98 % des organisations sont concernées et 93 % de l'usage de ChatGPT en entreprise passe par des comptes personnels.

Parce qu'on ne peut pas gouverner, documenter ni sécuriser des usages qu'on ne voit pas. Le Shadow AI échappe à la politique de données, au RGPD et au cadre AI Act.

En identifiant tous les outils IA utilisés (autorisés et Shadow AI), par service et par type de données traitées. SiyadAI automatise cette cartographie sans projet de plusieurs mois.

Les domaines de l'annexe III : recrutement, scoring de crédit, éducation, biométrie, justice, services essentiels, infrastructures critiques, et gestion de la migration/asile.

C'est ce que prévoit l'accord du 7 mai 2026 : 2 décembre 2027 pour l'annexe III, 2 août 2028 pour les produits réglementés de l'annexe I. Tant que le texte n'est pas publié au Journal officiel, ce report n'a pas d'effet juridique et le calendrier initial reste opposable.

Non. Installer une gouvernance, cartographier les usages et documenter les systèmes prend des mois. Attendre 2027 revient à devoir tout construire en urgence, en restant exposé aux sanctions actives entre-temps.

C'est l'obligation de respecter simultanément le socle déjà applicable de l'AI Act et de préparer les obligations « haut risque » qui arrivent en décembre 2027.

L'AI Act est une obligation légale européenne. ISO/IEC 42001 est une norme volontaire de système de management de l'IA. Mettre en place ISO 42001 facilite et structure la conformité à l'AI Act.

ISO/IEC 42001:2023 est la première norme internationale de système de management de l'intelligence artificielle (AIMS). Elle définit gouvernance, gestion des risques et amélioration continue des usages IA.

Oui, indirectement. Si vous intégrez des modèles GPAI dans vos produits ou processus, la responsabilité « aval » de la chaîne de valeur peut vous concerner, notamment via les obligations d'information.

L'AI Office européen, ainsi que les autorités nationales de surveillance désignées par chaque État membre. En France, plusieurs autorités (dont la CNIL) interviennent selon les usages.

1) Cartographier les usages IA réels ; 2) les classer par niveau de risque ; 3) installer une gouvernance ; 4) déployer la littératie IA ; 5) documenter et tracer.

Non. Un tableur fige une photo périmée dès le lendemain et ne détecte pas le Shadow AI. Une plateforme dédiée maintient une vue vivante des usages et des obligations.

SiyadAI cartographie automatiquement les usages IA (Shadow AI inclus), les classe par niveau de risque, génère le registre et la documentation attendus, et pilote la conformité AI Act et ISO 42001 depuis un tableau de bord unique.

La gouvernance de l'IA est l'ensemble des politiques, rôles, processus et outils par lesquels une organisation encadre le cycle de vie de ses systèmes d'intelligence artificielle, afin de garantir des usages sûrs, conformes et alignés sur sa stratégie. Elle couvre l'IA développée, achetée, intégrée et subie (Shadow AI).

Sans gouvernance, une entreprise cumule trois risques : juridique (sanctions AI Act et RGPD), sécurité (fuite de données via des outils non validés) et stratégique (usages anarchiques sans valeur capturée). La gouvernance transforme un usage subi en usage piloté.

La responsabilité ultime revient à la Direction générale. Elle est opérée par un comité IA transverse réunissant le RSSI (sécurité), le DPO (conformité RGPD), la DSI (intégration technique), les métiers (cas d'usage) et les RH/juridique.

La conformité AI Act est une obligation réglementaire précise. La gouvernance de l'IA est le cadre organisationnel plus large qui permet de satisfaire l'AI Act, mais aussi le RGPD, l'ISO 42001 et les bonnes pratiques de sécurité, à partir d'une source unique de vérité.

Par la visibilité : cartographier les usages et systèmes d'IA réellement utilisés dans l'entreprise. On ne gouverne pas ce qu'on ne voit pas. Le registre des usages est la fondation de tout le reste.

C'est l'inventaire structuré des systèmes d'IA de l'organisation : quels outils, par qui, pour quelles finalités, avec quelles données, à quel niveau de risque. Il sert de socle documentaire commun à l'AI Act, au RGPD et à l'ISO 42001.

Un document interne qui définit ce qui est autorisé, encadré ou interdit en matière d'IA : outils validés, données proscrites, cas d'usage sensibles, procédures de validation et responsabilités. Sa version pédagogique et accessible s'appelle la charte IA.

La politique IA est le document de référence détaillé (règles, procédures, responsabilités). La charte IA en est la version courte, lisible par tous les salariés, qui rappelle les principes et les bons réflexes au quotidien.

Le comité IA est l'instance de pilotage transverse qui valide la politique, arbitre les cas d'usage sensibles et suit le registre. Il réunit Direction, RSSI, DPO, DSI, métiers et RH, généralement de façon trimestrielle, pour suivre le rythme d'évolution des outils.

Elle n'est pas nommée « obligatoire » en tant que telle, mais elle est la condition pratique pour respecter l'AI Act (transparence, documentation, littératie), le RGPD (AIPD, bases légales) et démontrer une maîtrise des risques. En pratique, elle est incontournable en 2026.

Le Shadow AI désigne l'usage d'outils d'IA non validés par l'entreprise, souvent des SaaS grand public. C'est le principal angle mort. Une gouvernance efficace le rend visible et le ramène dans un cadre maîtrisé plutôt que de l'interdire à l'aveugle.

Le RSSI est garant de la sécurité : contrôle des flux de données, prévention des fuites (DLP), évaluation des risques de sécurité des outils, sécurisation des IA génératives et gestion des incidents. Il est souvent le pilote naturel du registre des usages.

Le DPO est garant de la conformité RGPD : bases légales, réalisation des analyses d'impact (AIPD), gestion des droits des personnes et articulation entre RGPD et AI Act. Son rôle de conseil est essentiel pour tout usage traitant des données personnelles.

En reprenant l'esprit de l'AI Act : usages interdits, usages à haut risque, usages à risque limité (soumis à transparence) et usages à risque minimal. Cette classification détermine les contrôles et les priorités.

L'ISO/IEC 42001 est la norme internationale de système de management de l'IA (AIMS). Elle structure et certifie la démarche de gouvernance. Attention : une certification ISO 42001 ne vaut pas présomption de conformité à l'AI Act ; les deux sont complémentaires.

Une première cartographie et la constitution du comité IA peuvent être réalisées en quelques semaines. La gouvernance complète (politique, garde-fous, formation) se déploie sur quelques mois, puis devient un processus continu.

Non, l'inverse. Sans cadre, les usages restent dispersés, non fiables et non capitalisés. La gouvernance permet de déployer l'IA à l'échelle en confiance, en supprimant l'incertitude qui bloque les décisions.

L'article 4 de l'AI Act impose que les personnes qui déploient ou utilisent des systèmes d'IA disposent d'un niveau suffisant de compréhension. Concrètement, cela se traduit par des actions de formation et de sensibilisation intégrées à la gouvernance.

Oui. Dès qu'une PME utilise des outils d'IA — y compris grand public comme ChatGPT ou Copilot — elle est concernée. Le cadre se dimensionne à sa taille, mais les principes (visibilité, rôles, règles, contrôle) restent les mêmes.

SiyadAI construit et maintient automatiquement le registre des usages d'IA : détection des outils réellement utilisés (y compris Shadow AI), cartographie des données exposées, classification des risques et tableau de bord pour le comité IA. La gouvernance devient un système piloté plutôt qu'un document théorique.

C'est l'ensemble des mesures techniques et organisationnelles visant à protéger les systèmes fondés sur des modèles de langage (copilotes, chatbots, RAG, agents) contre le détournement, la fuite de données et les actions non autorisées. Elle s'appuie sur des référentiels comme l'OWASP Top 10 for LLM Applications et les recommandations de l'ANSSI.

C'est un référentiel publié par l'OWASP qui classe les dix risques de sécurité majeurs des applications fondées sur des LLM. La version 2025 va de l'injection de prompt (LLM01) à la consommation non bornée (LLM10).

L'injection de prompt (LLM01). Une entrée en langage naturel manipule le comportement du modèle, pouvant contourner ses garde-fous ou déclencher des actions via des outils connectés.

En injection directe, l'utilisateur manipule lui-même le modèle par ses instructions. En injection indirecte, l'instruction malveillante est cachée dans une source externe (e-mail, page web, document) que le modèle consulte.

L'ANSSI a publié en avril 2024 le guide ANSSI-PA-102 avec 35 recommandations couvrant les trois phases du cycle de vie d'un système d'IA générative : entraînement, intégration/déploiement et production.

35 recommandations, réparties sur les trois phases du cycle de vie et destinées aux RSSI, DSI, data scientists et data engineers.

C'est le risque LLM06 : un système IA dispose de trop de permissions, d'outils ou d'autonomie. Une manipulation se traduit alors par une action réelle et potentiellement destructrice.

Oui. Un chatbot répond ; un agent agit (appelle des outils, exécute des requêtes, envoie des e-mails). Une manipulation d'agent peut provoquer des actions non autorisées, pas seulement une mauvaise réponse.

De trois façons : des collaborateurs collent des données sensibles dans des services grand public ; un système RAG expose des documents mal cloisonnés ; le modèle restitue des informations confidentielles apprises ou accessibles (risque LLM02).

Le RAG (Retrieval-Augmented Generation) enrichit les réponses du modèle avec des documents internes via une base vectorielle. Mal cloisonnée, cette base peut laisser fuiter des données entre équipes ou être empoisonnée (risque LLM08).

Indirectement, oui. L'article 15 de l'AI Act impose robustesse et cybersécurité aux systèmes à haut risque, le RGPD s'applique aux données personnelles, et l'ISO/IEC 42001 exige une maîtrise des risques IA.

La sécurité protège techniquement les systèmes (confidentialité, intégrité, disponibilité). La gouvernance encadre l'usage de l'IA (rôles, politiques, conformité). Les deux sont complémentaires et doivent partager un registre commun.

La Shadow AI désigne les usages d'IA non déclarés et non encadrés. On ne peut sécuriser que ce que l'on connaît : ces usages invisibles constituent un angle mort majeur de la sécurité.

Par la cartographie : recenser tous les systèmes d'IA (officiels, expérimentaux, non déclarés), puis les classifier par risque avant d'appliquer les référentiels OWASP et ANSSI.

C'est l'exposition des instructions internes d'un système IA (règles, secrets, logique métier), qui peut révéler son fonctionnement et faciliter d'autres attaques. Nouvelle catégorie de l'OWASP 2025.

Injection de prompt, fuite de données sensibles, agence excessive, faiblesses du RAG/bases vectorielles, et gouvernance de la Shadow AI.

Oui. Tester un système IA en conditions adverses (tentatives d'injection, de contournement, d'abus d'outils) avant sa mise en production est une bonne pratique recommandée, notamment pour les agents.

Ce sont les trois familles de scénarios décrites par l'ANSSI : manipulation (détourner le comportement), infection (empoisonner données ou chaîne d'approvisionnement) et exfiltration (extraire données ou modèle).

Oui. L'article 15 exige des systèmes à haut risque un niveau approprié d'exactitude, de robustesse et de cybersécurité tout au long de leur cycle de vie.

SiyadAI cartographie en continu les usages d'IA (Shadow AI compris), constitue un registre vivant des systèmes, associe à chacun ses risques (grille OWASP/ANSSI) et son statut de conformité, et fournit au RSSI comme au DPO une visibilité unique et permanente.

Une AIPD (analyse d'impact relative à la protection des données, ou DPIA) est une démarche documentée qui cartographie un traitement de données personnelles, évalue ses risques pour les personnes et définit un plan de mesures. Elle est prévue à l'article 35 du RGPD.

Le plus souvent, oui. Dès qu'un traitement est susceptible d'engendrer un risque élevé, l'AIPD est obligatoire. Les systèmes d'IA cumulent généralement plusieurs critères de risque élevé, ce qui rend l'AIPD obligatoire dans la majorité des cas.

Selon l'EDPB, dès que deux des neuf critères de risque élevé sont réunis (scoring, décision automatisée, surveillance systématique, données sensibles, grande échelle, croisement de données, personnes vulnérables, technologie innovante, obstacle à un droit/service).

La CNIL recommande fortement une AIPD pour le développement d'un système d'IA, notamment lorsque deux critères sont réunis (données de personnes vulnérables, croisement de jeux de données, solution innovante), et la rend obligatoire dès qu'il existe un risque de mésusage, de violation de données ou de discrimination.

Aucune : DPIA (Data Protection Impact Assessment) est le terme anglais de l'AIPD. Les deux désignent l'analyse d'impact de l'article 35 du RGPD.

L'AIPD (RGPD) porte sur les risques liés aux données personnelles. La FRIA (AI Act, article 27) couvre un spectre plus large de droits fondamentaux et des dimensions techniques. La FRIA peut s'appuyer sur l'AIPD lorsque les deux sont requises.

Une description systématique du traitement, une évaluation de la nécessité et de la proportionnalité, une appréciation des risques pour les personnes, et les mesures prévues pour traiter ces risques.

Le responsable de traitement en est responsable. Le DPO donne un avis et conseille sur la démarche. Métiers, DSI et RSSI contribuent à l'identification des risques et des mesures.

Généralement oui, s'il traite des données personnelles (échanges clients ou salariés). Il cumule souvent traitement à grande échelle, technologie innovante et parfois données sensibles.

Oui. Le tri de candidatures cumule évaluation de personnes, décision à effet significatif et risque de discrimination : l'AIPD est obligatoire.

Oui. Le RGPD s'applique à la constitution des jeux de données et à l'apprentissage, pas seulement à l'usage. L'AIPD doit traiter les deux phases distinctement.

En documentant la représentativité des données, les tests d'équité, et les mesures de détection et correction des biais. Le risque de discrimination doit faire l'objet d'une section dédiée.

Consulter la CNIL avant de démarrer le traitement, au titre de la consultation préalable prévue à l'article 36 du RGPD.

Oui. L'AIPD découle du RGPD, pas de l'AI Act. Le report de certaines obligations de l'AI Act à 2027 ne change rien à l'obligation d'AIPD, déjà en vigueur.

Oui. L'article 27.4 de l'AI Act prévoit que la FRIA peut s'appuyer sur l'AIPD réalisée au titre du RGPD. Une cartographie commune évite le double travail.

À chaque évolution significative : réentraînement, nouvelle source de données, changement de finalité ou de périmètre. L'AIPD est un document vivant.

En principe, une par traitement. Une AIPD peut couvrir plusieurs traitements similaires à risques comparables, mais un système d'IA aux finalités distinctes justifie des analyses distinctes.

De quelques jours à plusieurs semaines selon la complexité, quand elle est menée manuellement. L'outillage (référentiel commun, trames, génération assistée) réduit fortement ce délai.

Un manquement au RGPD exposant à des sanctions de la CNIL, sans compter le risque réputationnel et l'impossibilité de démontrer l'accountability en cas de contrôle ou d'incident.

Avec une plateforme de gouvernance de l'IA qui cartographie les usages, génère les AIPD (et le volet FRIA), suit les risques résiduels et produit le dossier de preuve. C'est le rôle de SiyadAI.

C'est l'inventaire structuré, tenu à jour et opposable de tous les systèmes d'IA utilisés ou développés par une organisation — internes, achetés ou embarqués dans un SaaS. Il documente pour chacun sa finalité, son fournisseur, les données traitées, son niveau de risque AI Act et son responsable.

La cartographie est l'action de découvrir et recenser les systèmes d'IA ; le registre est le livrable structuré qui en résulte et qu'on maintient dans le temps. On cartographie pour alimenter le registre.

Il n'existe pas un article unique l'imposant, mais plusieurs obligations de l'AI Act (art. 12, 26, 50) et du RGPD (art. 30, 35) le rendent indispensable de fait. C'est aussi la première pièce réclamée lors d'un contrôle.

Le registre RGPD recense les traitements de données personnelles ; le registre des usages IA recense les systèmes d'IA, qu'ils traitent ou non des données personnelles. Les deux sont distincts mais couplés : un système d'IA traitant des données personnelles doit figurer dans les deux.

Au minimum : identifiant, finalité, type et fournisseur, statut, propriétaire, données traitées, localisation/transferts, classification AI Act, base RGPD/AIPD, risques et mesures, dates de revue, preuves.

En pratique, le pilotage revient souvent au DPO ou au RSSI, sous mandat de la direction, avec des contributeurs métier. La responsabilité finale relève de la direction générale.

L'article 50 (transparence) s'applique au 2 août 2026 : dès que vous exposez de l'IA à des personnes, vous devez les informer. Impossible sans savoir où vous exposez de l'IA — d'où la nécessité de la cartographie en amont.

Ce sont les fonctions d'IA intégrées dans des logiciels tiers que vous utilisez déjà (bureautique, CRM, RH), souvent activées par défaut. C'est le plus gros angle mort d'une cartographie qui ne s'appuierait que sur le déclaratif.

Les cartographies révèlent fréquemment 2 à 3 fois plus de systèmes que ce que la direction estimait, en raison du Shadow AI et de l'IA embarquée.

Pour démarrer à une dizaine de systèmes, oui. Au-delà, ses limites (pas d'historisation fiable, pas de rappels de revue, pas de liaison avec le RGPD/AIPD, risque d'erreur manuel) le rendent inadapté et risqué.

Au minimum une revue trimestrielle, plus une mise à jour à chaque nouvel usage d'IA. Le principe : « pas de nouvel outil IA sans inscription au registre ».

Selon l'AI Act : pratique interdite (art. 5), haut risque (annexe III), risque limité soumis à transparence (art. 50), ou risque minimal. En cas de doute sur le haut risque, documentez le raisonnement.

Oui. Les obligations de transparence (art. 50) et de littératie IA (art. 4) ne dépendent pas de la taille. Une PME qui utilise un chatbot ou de l'IA générative est concernée.

Le registre identifie quels systèmes traitent des données personnelles à risque élevé ; ce sont ceux qui déclenchent une AIPD (art. 35 RGPD). Le registre est donc le point de départ de la démarche AIPD.

Vous vous exposez à ne pas pouvoir démontrer votre conformité (transparence, traçabilité), ce qui aggrave votre situation et peut conduire à des sanctions sous l'AI Act et le RGPD.

Oui — une fois découvert. L'objet même de la cartographie est de faire remonter le Shadow AI (usages non déclarés) pour le régulariser ou l'arrêter.

Oui, avec le statut « en test ». Beaucoup de risques naissent d'expérimentations passées en production sans validation. Le statut permet de les suivre.

Par recoupement de trois sources : questionnaires métier (déclaratif), analyse technique (flux réseau, connexions SaaS, dépenses), et revue des contrats fournisseurs (IA embarquée).

Oui. C'est un actif commercial (répondre aux appels d'offres), un outil de maîtrise des coûts (rationaliser les abonnements) et un socle de sécurité (identifier les surfaces d'attaque liées à l'IA).

SiyadAI industrialise la découverte des usages, structure le registre, automatise la classification AI Act, relie chaque système à ses AIPD et preuves, et produit les tableaux de bord attendus par la direction et les auditeurs.

Oui. Le Data Privacy Framework reste juridiquement en vigueur : la décision d'adéquation du 10 juillet 2023 n'a été ni annulée ni retirée. Son avenir est toutefois incertain après l'arrêt Trump v. Slaughter du 29 juin 2026.

La Cour suprême US a jugé le 29 juin 2026 que les restrictions au pouvoir présidentiel de révoquer les commissaires de la FTC sont inconstitutionnelles. Or la décision d'adéquation européenne repose sur l'indépendance de la FTC, citée 259 fois. Son raisonnement est fragilisé.

Non. Aucun texte n'interdit leur usage. La démarche : identifier le mécanisme de transfert de chaque outil, mettre à jour la TIA et préparer un plan de repli. Une migration précipitée serait coûteuse et prématurée.

Une TIA (Transfer Impact Assessment) est l'analyse documentée vérifiant que le droit du pays destinataire ne prive pas d'effectivité les garanties d'un transfert (souvent des CCT). Elle découle de Schrems II et suit la méthode en 6 étapes des recommandations 01/2020 de l'EDPB.

Probablement pas si elle conclut favorablement en s'appuyant sur l'indépendance des autorités de contrôle américaines (FTC, PCLOB, DPRC). L'étape 6 de la méthode EDPB impose une réévaluation à chaque évolution significative ; l'arrêt du 29 juin en est une.

Non, pas à elles seules. Depuis Schrems II, les CCT doivent être accompagnées d'une TIA et, si elle révèle une insuffisance, de mesures supplémentaires. Une mesure purement contractuelle ne suffit pas quand le droit local permet l'accès malgré le contrat.

C'est fortement recommandé. Maintenir les deux mécanismes coûte peu et fournit un fondement de repli mobilisable immédiatement en cas d'invalidation, sans interruption de service. C'est la leçon de l'invalidation du Privacy Shield en 2020.

Non. L'accès à distance depuis un pays tiers constitue un transfert au sens du chapitre V du RGPD. Données hébergées en Irlande mais accessibles par une équipe support américaine : il y a transfert.

Pas nécessairement. S'il appelle l'API d'un modèle américain pour sa fonctionnalité d'IA, un transfert existe dans votre chaîne de traitement — il est le vôtre. Obtenez et documentez la liste de ses sous-traitants ultérieurs.

Non pour un usage courant. Les dérogations de l'article 49 visent l'occasionnel. De plus, dans une relation de subordination, la validité du consentement d'un salarié est très contestable. Un usage quotidien appelle un mécanisme de l'article 45 ou 46.

En consultant nommément la liste publique sur dataprivacyframework.gov et en vérifiant que la certification est active. Une mention marketing de « conformité DPF » ne suffit pas. La certification s'apprécie au niveau de l'entité juridique destinataire.

La plus efficace est le filtrage en amont des données envoyées au modèle : empêcher qu'un identifiant, une donnée de santé ou un extrait RH figure dans un prompt réduit le risque à la source. S'y ajoutent pseudonymisation, chiffrement, politique d'usage et engagements de non-réutilisation.

Pas de recouvrement juridique : le RGPD protège les données, l'AI Act encadre les systèmes. Mais les deux régimes exigent la même donnée d'entrée — un inventaire fiable des systèmes d'IA. Deux référentiels séparés divergent mécaniquement.

L'article 50 de l'AI Act devient applicable : informer les personnes qu'elles interagissent avec une IA, marquer les contenus générés, informer en cas de catégorisation biométrique. Un délai court jusqu'au 2 décembre 2026 pour le marquage lisible par machine des systèmes déjà en marché.

Les manquements au chapitre V relèvent du plafond le plus élevé : 20 M€ ou 4 % du CA mondial. Au-delà, le risque opérationnel est l'injonction de suspendre le transfert, qui peut interrompre un service en production.

Oui, les transferts internationaux et l'IA générative figurent parmi les chantiers 2026 de la CNIL. Les thématiques prioritaires annoncées sont le recrutement, le répertoire électoral unique et les fédérations sportives ; la cybersécurité représente la moitié des contrôles.

Ce n'est pas une obligation. La CNIL recommande d'évaluer les alternatives européennes dès que techniquement réalisable, cas d'usage par cas d'usage. Un usage documentaire interne se bascule aisément ; une intégration profonde, beaucoup moins.

L'AIPD (art. 35 RGPD) évalue le risque d'un traitement pour les personnes. La TIA (chapitre V) évalue si les garanties d'un transfert restent effectives compte tenu du droit local. Un même traitement d'IA peut nécessiter les deux, avec des conclusions distinctes.

Pour une PME/ETI disposant déjà d'un registre des traitements, une cartographie initiale des systèmes critiques prend 2 à 4 semaines. La difficulté n'est pas l'analyse mais l'exhaustivité : usages non déclarés et IA embarquée représentent souvent la majorité de l'exposition.

Par l'inventaire de tous les systèmes d'IA, y compris non souscrits et embarqués. Puis vérifier, pour les cinq flux les plus sensibles, le mécanisme de transfert, l'existence de CCT en parallèle et l'option de résidence UE. Enfin, mettre à jour leur TIA en intégrant la décision du 29 juin.

La FRIA (Fundamental Rights Impact Assessment), ou analyse d'impact sur les droits fondamentaux, est l'évaluation imposée par l'article 27 de l'AI Act avant le premier déploiement d'un système d'IA à haut risque. Elle décrit l'usage prévu, les personnes et groupes affectés, les risques de préjudice, la surveillance humaine et les mesures correctives, y compris les mécanismes de plainte.

Partiellement. L'article 27 §2 autorise à s'appuyer sur des analyses d'impact antérieures ou sur celles du fournisseur, dans des cas similaires. Mais les points (c), (e) et (f) — groupes affectés, organisation de la surveillance humaine, mécanismes de plainte — dépendent de votre contexte et ne peuvent structurellement pas venir du fournisseur.

Lorsqu'un des éléments du paragraphe 1 a changé ou n'est plus à jour : nouvelle version du système, extension du périmètre d'usage, nouvelle population concernée, incident, évolution du cadre juridique. L'article 27 §2 en fait une obligation explicite. Sans fait générateur de révision défini et sans traçabilité des versions, la FRIA est périmée l'année suivante.

Le régime de l'article 99 prévoit, pour les manquements des déployeurs, des amendes pouvant atteindre 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial. Les États membres déterminent le régime applicable aux organismes publics. Au-delà, l'exposition principale est contentieuse et réputationnelle : droit de plainte (article 85), droit à l'explication des décisions individuelles (article 86), demandes de communication.

Pas en tant que tel : un usage bureautique général ne bascule pas automatiquement en haut risque. En revanche, si un assistant conversationnel est intégré dans un processus relevant de l'annexe III — instruction de demandes d'aide sociale, tri de candidatures, orientation scolaire — la classification haut risque doit être examinée, et les obligations de transparence de l'article 50 s'appliquent de toute façon.

L'obligation vise la première utilisation. L'article 111 organise le sort des systèmes déjà mis en service avant les dates d'application, avec un traitement particulier pour les systèmes utilisés par les autorités publiques. Un système existant modifié substantiellement, ou dont le périmètre d'usage est étendu, doit dans tous les cas faire l'objet d'une analyse à jour.

Aucun texte n'impose un pilote unique. En pratique, le DPO apporte la méthode et l'articulation avec l'AIPD, le DSI/RSSI la connaissance technique, le référent métier la réalité du processus, la direction juridique la qualification, et la direction générale l'arbitrage. Une FRIA portée par le seul DPO produit un document, pas une décision.

L'analyse elle-même se conduit en deux à quatre ateliers. Ce qui prend du temps, c'est l'amont : constituer l'inventaire des systèmes d'IA et les classifier prend de quelques semaines à plusieurs mois selon la taille de l'organisation et l'existence d'un registre préalable.

L'article 27 impose la notification à l'autorité de surveillance du marché, pas la publication. Pour une collectivité, une synthèse publiée volontairement peut néanmoins constituer une réponse anticipée aux demandes de communication et un élément de confiance vis-à-vis des usagers.