Expertise · AI Act des plateformes
AI Act des plateformes : passez chaque fonction IA au scanner.
Recommandation, modération, chatbot, génération de contenus, scoring ou détection de fraude : deux fonctions utilisant le même modèle peuvent relever de règles très différentes. Lawnch identifie ce que chaque système fait réellement, le rôle de votre plateforme et les obligations qui en découlent.
Inventaire · Fournisseur / déployeur · Risque · Transparence · Contrôle humain · Documentation · DSA · RGPD
Le nom du modèle ne suffit pas à comprendre ce que fait votre produit.
Deux plateformes peuvent utiliser exactement le même modèle. La première s’en sert pour reformuler des réponses du support. La deuxième génère des fiches produit. La troisième l’intègre dans un outil qui classe ou évalue des personnes.
Techniquement, une partie de la chaîne peut être commune. Juridiquement, les usages ne racontent plus la même histoire.
Le modèle
Votre fonctionnalité peut s’appuyer sur un modèle développé par une autre entreprise, un modèle open source, un modèle généraliste ou un modèle que vous avez vous-même développé ou modifié.
Quel modèle, dans quelle version, fourni par qui ?
Le système
Prompts, règles métier, interface, données, filtres, outils, seuils et actions peuvent transformer un modèle en une fonction beaucoup plus spécifique.
Que produit réellement ce système ?
L’usage
La même sortie peut simplement assister un salarié ou, dans un autre contexte, influencer directement l’accès d’une personne à un service ou une décision importante.
Qui subit ou utilise réellement le résultat ?
Modèle, système et usage sont trois niveaux différents. La qualification doit savoir les séparer.
Que fait réellement votre IA dans la plateforme ?
Sélectionnez une fonction. L’objectif n’est pas de lui attribuer immédiatement une étiquette juridique, mais de faire apparaître les questions qui décident de sa qualification.
Le système choisit ce qui apparaîtra en premier.
Produits, vendeurs, contenus, profils, services : le système décide de l’ordre dans lequel les options se présentent à l’utilisateur.
Questions AI Act
- s’agit-il d’un système d’IA au sens du règlement ?
- quelle est sa destination ?
- la recommandation influence-t-elle seulement l’affichage, ou participe-t-elle à une décision relevant d’un contexte particulier ?
- qui fournit le système ?
- qui le déploie ?
Autres règles possibles
DSA pour certains systèmes de recommandation · P2B lorsqu’un classement de professionnels est concerné · RGPD lorsque des données personnelles ou du profilage interviennent
Un moteur de recommandation n’est pas automatiquement « haut risque » au sens de l’AI Act simplement parce qu’il influence fortement la visibilité.
AI Act art. 3 · DSA art. 27 · P2B art. 5
Le système détecte, classe ou retire des contenus.
Détection de spam, détection d’images interdites, classement d’un signalement, restriction automatique d’une annonce, suspension d’un compte.
Questions AI Act
- le système recommande-t-il une décision ou l’exécute-t-il ?
- quel humain peut revoir le résultat ?
- quelles données sont utilisées ?
- quelles erreurs sont possibles ?
- le système agit-il directement sur les droits ou l’accès de l’utilisateur ?
Autres règles possibles
DSA · RGPD
Une modération automatisée peut être importante sans devenir pour autant un système à haut risque au titre de l’AI Act. Le DSA peut néanmoins créer ses propres obligations, notamment lorsqu’une décision doit être motivée.
DSA art. 17 · art. 20
Le système produit du texte, de l’image, du son, de la vidéo ou du code.
Fiche produit, résumé, image, réponse commerciale, description automatique, contenu proposé à l’utilisateur.
Questions AI Act
- qui fournit le système génératif ?
- qui publie la sortie ?
- quel type de contenu est produit ?
- un humain le revoit-il ?
- le contenu constitue-t-il un hypertrucage ?
- s’agit-il d’un texte destiné à informer le public sur une question d’intérêt public ?
- quelles obligations de marquage ou de divulgation concernent respectivement le fournisseur et le déployeur ?
Autres règles possibles
Propriété intellectuelle · RGPD · droit de la consommation · DSA selon la diffusion
« Contenu généré par IA » n’entraîne pas une mention universelle unique, applicable de la même manière à tous les acteurs de la chaîne.
AI Act art. 50
Le système parle directement avec l’utilisateur.
Chatbot support, assistant d’achat, assistant vendeur, FAQ dynamique, agent conversationnel.
Questions AI Act
- l’utilisateur comprend-il qu’il interagit avec une IA ?
- cela ressort-il déjà clairement du contexte ?
- quelles actions l’agent peut-il effectuer ?
- donne-t-il uniquement une réponse, ou modifie-t-il un compte, une commande ou une annonce ?
- quelles données reçoit-il ?
Autres règles possibles
RGPD · droit de la consommation
Un chatbot qui répond à une question et un agent capable d’annuler une commande ne doivent pas être gouvernés de la même manière.
AI Act art. 50, 1
Le système transforme des informations en un score.
Fraude, confiance, risque, qualité, priorité, solvabilité. La question centrale n’est pas le score lui-même : c’est ce qu’on en fait.
Questions AI Act
- le score aide-t-il un humain, ou déclenche-t-il seul une conséquence ?
- sert-il de simple signal, de critère de classement, de restriction ou de refus ?
- la décision devient-elle entièrement automatisée ?
- quelles personnes sont concernées, et dans quel contexte ?
Autres règles possibles
RGPD lorsque la décision est automatisée · DSA lorsqu’elle restreint un compte
« Score » n’est pas une catégorie juridique. Un score antifraude interne et une évaluation de la solvabilité d’une personne ne se qualifient pas nécessairement de la même manière.
RGPD art. 22 · AI Act annexe III
Le système décide qui passe à l’étape suivante.
Vérification de vendeur, validation documentaire, sélection de profil, mise en relation, présélection de candidats lorsque la plateforme propose ce type de service.
Questions AI Act
- quel est le contexte de sélection ?
- quelles personnes sont concernées ?
- le résultat influence-t-il substantiellement une décision ?
- existe-t-il un examen humain réel ?
- le système correspond-il à un cas visé par l’annexe III ?
Autres règles possibles
RGPD · droit du travail selon le contexte
Deux systèmes utilisant une technologie proche peuvent changer complètement de régime à cause de la décision à laquelle ils participent.
AI Act art. 6 · annexe III
La bonne unité d’analyse n’est donc ni « notre entreprise utilise de l’IA », ni « nous utilisons tel modèle ». C’est : cette fonction précise fait ceci, sur ces personnes, avec ce résultat et cette conséquence.
Vous achetez un modèle. Cela ne répond pas encore à la question de votre rôle.
L’AI Act répartit les obligations selon le rôle joué dans la chaîne. Pour une plateforme, ce rôle peut changer d’une fonction à l’autre.
modèle → intégration → système → plateforme → utilisateur
Vous utilisez un système fourni par une autre entreprise
Votre entreprise peut être principalement dans une logique de déploiement pour cet usage. Il faut alors identifier les obligations correspondant précisément à ce rôle et au système concerné.
Le point à ne pas manquer
Le fournisseur ne s’occupe pas de tout : ses obligations portent sur son système, pas sur l’usage que vous en faites.
AI Act art. 3, 4
Le modèle tiers devient une brique de votre propre fonction
La question n’est plus seulement celle de l’utilisation du modèle. Votre entreprise construit autour de lui ses propres instructions, ses données, ses règles, son interface, ses actions et son usage final.
Le point à ne pas manquer
Il faut déterminer quel rôle vous jouez à l’égard du système ainsi constitué, et non à l’égard du seul modèle sous-jacent.
AI Act art. 3, 3 · art. 25
Une modification peut changer la répartition des responsabilités
Pour certains systèmes, notamment dans le régime des systèmes à haut risque, une modification substantielle ou un changement de destination peut entraîner une nouvelle qualification de l’acteur qui la réalise.
Le point à ne pas manquer
Tout ajustement n’est pas une modification substantielle. C’est le cas concret qui doit être examiné, pas l’étiquette technique.
AI Act art. 25, 1
Votre nom sur le produit peut compter
Lorsqu’une entreprise met elle-même un système sur le marché, ou fournit sous son propre nom un système qu’elle a construit autour d’autres composants, la question du rôle de fournisseur doit être examinée précisément.
Le point à ne pas manquer
Le contrat entre les entreprises ne suffit pas toujours à décider du rôle réglementaire. Il faut regarder ce que chacun fait réellement.
AI Act art. 25, 1, a
Chaque fonction IA devrait pouvoir tenir sur une fiche.
Quatorze champs suffisent. Ce sont eux qui permettent ensuite de dire quelles obligations s’appliquent, et lesquelles ne s’appliquent pas.
- Nom interne
- Recommandation de produits, assistant support, détection de fraude… le nom que les équipes emploient réellement.
- Fonction
- Que fait le système, décrit en une phrase que le produit et le juridique valident tous les deux.
- Destination
- Pourquoi il existe, et pour quel usage il a été conçu.
- Modèle ou fournisseur
- Quelle technologie se trouve derrière, dans quelle version, fournie par qui.
- Rôle de la plateforme
- Fournisseur, déployeur, ou autre acteur de la chaîne pour cette fonction précise.
- Entrées
- Quelles informations le système reçoit, et d’où elles proviennent.
- Sorties
- Ce qu’il produit : un texte, un score, un classement, une décision.
- Action déclenchée
- Afficher, conseiller, bloquer, classer, générer ou décider.
- Personnes concernées
- Acheteurs, vendeurs, utilisateurs, salariés, candidats.
- Contrôle humain
- Qui peut examiner ou reprendre le résultat, et avec quelle autorité.
- Transparence
- Ce que l’utilisateur doit savoir, et à quel endroit il l’apprend.
- Journaux et preuve
- Ce que l’on conserve sur le fonctionnement et sur les décisions prises.
- Autres textes
- RGPD, DSA, P2B, droit de la consommation, propriété intellectuelle.
- Version
- Quel modèle et quelle configuration sont actuellement en production.
Une politique IA générale ne remplace pas cette fiche. C’est cette fiche qui permet de savoir ce qui doit être fait.
Une fois la fonction comprise, quel régime apparaît ?
Pratique interdite
L’AI Act interdit certaines pratiques définies précisément par le règlement. La qualification dépend des techniques utilisées, des personnes concernées, de l’objectif, du contexte et des effets prévus par le texte.
Cette catégorie ne se résume pas à « l’IA dangereuse », et toute personnalisation commerciale n’y entre pas.
AI Act art. 5
Système à haut risque
Certaines catégories d’utilisation relèvent d’un régime renforcé, notamment lorsqu’elles se trouvent dans les situations prévues par l’annexe III ou dans certains produits déjà réglementés : certains usages liés à l’emploi, à l’éducation, à l’accès à des services essentiels ou à la biométrie.
« Important pour notre entreprise » et « haut risque AI Act » ne signifient pas la même chose.
AI Act art. 6 · annexes I et III
Obligation spécifique de transparence
Le système n’est pas nécessairement à haut risque, mais quelque chose doit être rendu identifiable : interaction directe avec une IA, marquage technique des sorties artificiellement générées ou manipulées, hypertrucages, ou certains textes portant sur des questions d’intérêt public.
AI Act art. 50
Pas de haut risque, mais pas zéro obligation
La majorité des fonctions produit ne deviennent pas des systèmes à haut risque. Cela ne signifie pas que plus aucune règle ne s’applique : maîtrise de l’IA, obligations propres au rôle de fournisseur ou de déployeur, DSA, RGPD, P2B, droit de la consommation, propriété intellectuelle, contrats et gouvernance interne peuvent rester pertinents.
AI Act art. 4
Le scanner ne sert donc pas uniquement à détecter le haut risque. Il sert surtout à éviter deux erreurs : sur-réglementer une fonction banale, ou ignorer une fonction réellement sensible.
Ce n’est pas le mot « IA » qui fait basculer l’analyse. C’est ce qu’on lui demande de faire.
| Fonction | Cas A | Cas B | Ce que le contexte change |
|---|---|---|---|
| Recommander | Recommander un produit dans une marketplace. | Recommander ou classer des candidats pour un emploi. | Même mécanique apparente. Le second contexte peut faire entrer le système dans une catégorie prévue par l’annexe III. |
| Scorer | Prioriser les tickets à examiner pour fraude. | Évaluer la solvabilité d’une personne. | Le mot « score » ne permet aucune qualification à lui seul. |
| Générer | Rédiger un brouillon de fiche produit relu par un salarié. | Créer une vidéo représentant artificiellement une personne réelle d’une manière susceptible d’être perçue comme authentique. | Les obligations de transparence ne sont pas identiques. |
| Dialoguer | Répondre aux questions fréquentes. | Agent capable d’effectuer des actions sur le compte de l’utilisateur. | À mesure que l’agent obtient des capacités, la gouvernance opérationnelle doit être réexaminée. |
| Modérer | Détecter du spam et le signaler à un modérateur. | Suspendre automatiquement un compte. | Le degré d’autonomie et l’effet du résultat doivent être documentés. |
La qualification doit donc suivre la fonction jusqu’à sa conséquence réelle.
« Human in the loop » ne signifie rien tant qu’on ne sait pas ce que l’humain peut réellement faire.
Afficher un bouton « révision humaine » ne suffit pas si la personne chargée de la révision ne comprend pas la sortie, ne dispose pas des informations nécessaires, n’a pas le pouvoir de l’annuler, ou valide automatiquement ce que la machine propose.
Voir
La personne sait qu’une sortie ou une recommandation a été produite par le système.
Comprendre
Elle dispose de suffisamment d’informations pour interpréter correctement cette sortie dans le contexte concerné.
Questionner
Elle peut détecter une anomalie, une limite ou un résultat incohérent.
Arrêter
Elle peut empêcher que le résultat soit appliqué lorsque c’est nécessaire.
Remplacer
Elle possède réellement l’autorité pour prendre une autre décision.
La supervision humaine n’est pas la présence symbolique d’un humain : c’est une capacité opérationnelle. Les exigences précises dépendent du régime concerné : ces cinq niveaux sont une grille de lecture, pas une obligation universelle applicable à tout système d’IA.
AI Act art. 14, pour les systèmes à haut risque
La bonne information dépend de ce qui se passe devant l’utilisateur.
« Généré par IA » collé partout n’est ni ce que demande le règlement, ni ce qui informe utilement. Le texte distingue les acteurs, les formats et les usages.
Doit-il être informé ?
Les systèmes destinés à interagir directement avec des personnes doivent être conçus pour que celles-ci soient informées qu’elles interagissent avec une IA, sauf lorsque cela est évident dans les circonstances prévues par le texte.
À ne pas confondre : Cette obligation ne se reporte pas automatiquement sur tous les acteurs de la chaîne : elle suppose de qualifier d’abord le rôle de chacun.
AI Act art. 50, 1
Une obligation technique existe côté fournisseur
Certains fournisseurs de systèmes générant des contenus synthétiques doivent assurer un marquage dans un format lisible par machine et détectable comme artificiel, sous réserve des conditions et exceptions prévues par le règlement.
À ne pas confondre : Marquage technique et mention visible pour le public sont deux choses différentes. La première ne produit pas nécessairement la seconde.
AI Act art. 50, 2
La divulgation devient directement visible
Lorsqu’un déployeur utilise un système pour générer ou manipuler une image, un son ou une vidéo constituant un hypertrucage au sens du règlement, une obligation spécifique de divulgation peut s’appliquer.
À ne pas confondre : Des aménagements sont prévus pour certaines œuvres manifestement créatives, satiriques, artistiques ou fictives.
AI Act art. 50, 4
Un cas particulier existe pour certains textes
Lorsqu’un texte généré ou manipulé par IA est publié afin d’informer le public sur des questions d’intérêt public, une obligation spécifique peut s’appliquer au déployeur.
À ne pas confondre : Une exception est prévue lorsque le contenu a fait l’objet d’une revue humaine ou d’un contrôle éditorial et qu’une personne assume la responsabilité éditoriale.
AI Act art. 50, 4
L’AI Act n’impose donc pas un même bandeau sur tout contenu assisté par IA. Il désigne qui doit dire quoi, et dans quelles circonstances.
Avant d’intégrer un modèle, savez-vous ce que vous pourrez encore vérifier six mois plus tard ?
Une grande partie de la conformité dépend d’informations détenues par celui qui fournit la technologie.
Version
Quel modèle et quelle version utilisez-vous aujourd’hui en production ?
Destination et limites
Que dit le fournisseur sur les usages prévus et sur les limites connues du système ?
Données
Que deviennent les données envoyées au fournisseur ? Sont-elles conservées, réutilisées ?
Voir le RGPD des plateformesJournaux
Quelles informations restent accessibles pour comprendre un incident ou un résultat inattendu ?
Modification du modèle
Êtes-vous informé lorsqu’une nouvelle version change matériellement le comportement de la fonction ?
Sous-traitants et infrastructure
Quels autres acteurs interviennent, et où le traitement a-t-il lieu ?
Propriété intellectuelle
Quelles règles s’appliquent aux entrées, aux sorties et aux composants ?
Voir la propriété intellectuelleDocumentation AI Act
Selon votre rôle et celui de votre fournisseur, quelles informations nécessaires à la conformité doivent circuler le long de la chaîne ?
Un fournisseur fiable ne supprime pas vos propres obligations. Mais celles-ci deviennent difficiles à appliquer si vous ne pouvez obtenir aucune information utile sur le système.
Votre inventaire doit changer lorsque votre produit change.
Un inventaire réalisé une fois ne suffit pas. Le système peut changer sans qu’une nouvelle fonctionnalité apparaisse à l’écran.
Assistant support — exemple de fiche vivante
Modèle : version X · Fournisseur : entreprise Y · Propriétaire interne : équipe support et produit
Usage
Prépare une réponse et propose une action.
Automatisation
L’humain valide avant envoi.
Données
Compte et historique de ticket.
Population concernée
Utilisateurs.
Contrôle humain
Validation obligatoire.
Dernière revue
Date, et personne qui l’a menée.
Les événements qui obligent la fonction à repasser au scanner
- changement de modèle
- ajout d’un outil que le système peut appeler
- nouvelle donnée en entrée
- passage de la suggestion à l’action automatique
- ouverture à un nouveau pays
- nouvelle population concernée
- modification contractuelle importante côté fournisseur
La bonne question n’est pas « avons-nous un registre IA ? ». C’est « quel événement oblige une fonction à repasser au scanner ? »
L’interface n’a presque pas changé. Le rôle du système, si.
De suggestion à action
Avant : l’IA suggère qu’une annonce soit suspendue. Après : elle la suspend automatiquement.
Le niveau d’autonomie et les conséquences ont changé, donc l’analyse aussi.
De brouillon à publication
Avant : l’IA prépare une fiche relue par un vendeur. Après : la fiche est publiée automatiquement.
Les contrôles et les responsabilités doivent être réexaminés.
Nouveau modèle
Avant : version A. Après : version B, performances et limitations différentes.
Les tests, instructions ou contrôles existants sont-ils encore adaptés ?
Nouvelle population
Avant : outil interne utilisé par le support. Après : la même fonction est proposée directement aux clients.
De nouvelles obligations de transparence ou d’usage peuvent apparaître.
Nouvelle destination
Avant : un score sert uniquement à prioriser un contrôle. Après : il devient un critère automatique de refus.
La destination et la conséquence doivent être requalifiées.
En matière d’IA, une nouvelle version peut être un événement juridique même lorsque l’écran paraît presque identique.
Tout le monde n’a pas besoin de la même maîtrise de l’IA.
Les fournisseurs et les déployeurs doivent prendre des mesures pour soutenir le développement de la maîtrise de l’IA des personnes qui utilisent ou exploitent les systèmes pour leur compte, en tenant compte du contexte. Cela ne se traduit pas nécessairement par une formation identique pour chaque salarié.
Équipe produit
- ce que le système est censé faire
- ses limites
- ce qui déclenche une nouvelle qualification
- les conséquences d’une augmentation de l’autonomie
Équipe technique
- modèles et versions
- intégrations
- journaux
- paramètres importants
- changements techniques affectant la fonction
Support et modération
- comment interpréter le résultat
- quand ne pas lui faire confiance
- comment demander une reprise humaine
- comment documenter un problème
Marketing et contenu
- les règles applicables aux contenus synthétiques
- les usages sensibles
- la propriété intellectuelle
- la transparence selon le contenu diffusé
Juridique et conformité
- relier la fiche technique au rôle réglementaire
- identifier les textes qui se superposent
- déterminer les contrôles à conserver
- déclencher une nouvelle revue lorsque le produit change
La maîtrise de l’IA est donc moins une formation générique qu’une capacité à utiliser correctement les systèmes que l’entreprise a réellement déployés.
AI Act art. 4
Votre système n’a pas à choisir entre AI Act, RGPD et DSA. Les trois peuvent regarder la même fonction.
Le scénario : un système attribue un score à une annonce, puis la suspend automatiquement. Voici ce que chaque texte demande à propos de cette seule décision.
La couche AI Act
Quel système est utilisé ? Quel rôle joue l’entreprise à son égard ? Quelle qualification le système reçoit-il, et quelles obligations spécifiques en résultent ?
AI Act art. 3 · art. 6 · art. 25
La couche DSA
Une restriction de contenu ou de compte est-elle concernée ? Si oui, quelles obligations de motivation, de transparence sur le recours à des moyens automatisés, et quelles voies de recours s’appliquent au service ?
DSA art. 17 · art. 20
La couche RGPD
Des données personnelles interviennent-elles ? La décision est-elle uniquement automatisée ? Produit-elle un effet juridique ou affecte-t-elle significativement la personne ?
RGPD art. 22
Les couches qui s’ajoutent selon le cas
Le classement de professionnels, l’information due aux consommateurs ou l’utilisation de contenus protégés peuvent créer d’autres questions, sur la même fonction.
P2B art. 5 · C. consom. art. L111-7
Une fonction n’a pas « une loi ». Elle a une architecture réglementaire.
L’AI Act est déjà applicable. Toutes ses obligations ne commencent pourtant pas le même jour.
2 février 2025 — Pratiques interdites et maîtrise de l’IA
Les interdictions de l’article 5 et les obligations relatives à la maîtrise de l’IA sont entrées en application.
AI Act art. 4 · art. 5
2 août 2025 — Modèles d’IA à usage général
Entrée en application des obligations pesant sur les fournisseurs de modèles d’IA à usage général, selon le calendrier prévu par le règlement.
AI Act art. 53
2 août 2026 — Application générale
Date générale d’application du règlement, à laquelle interviennent notamment les obligations de transparence de l’article 50, selon leurs conditions propres.
AI Act art. 50
2 décembre 2026 — Régime transitoire pour le marquage
Délai supplémentaire prévu pour le marquage des contenus produits par certains systèmes génératifs déjà mis sur le marché avant le 2 août 2026.
2 décembre 2027 — Haut risque de l’annexe III
Date d’application désormais prévue pour les systèmes à haut risque relevant de l’article 6, paragraphe 2, et de l’annexe III. Ce report résulte du règlement dit « Digital Omnibus », adopté en juin 2026 : la date initialement prévue était le 2 août 2026.
2 août 2028 — Haut risque de l’annexe I
Date prévue pour les systèmes à haut risque intégrés à des produits déjà réglementés, visés par l’article 6, paragraphe 1, et l’annexe I.
Le calendrier comporte des règles transitoires et des dispositions particulières. La date pertinente dépend donc aussi du système concerné, du rôle joué et de sa date de mise sur le marché ou en service.
Avant de rédiger une politique IA, pouvez-vous répondre à ces neuf questions ?
- 01Système. Est-ce bien un système entrant dans le champ du règlement ?
- 02Fonction. Que fait-il réellement, décrit sans vocabulaire commercial ?
- 03Destination. Pourquoi est-il utilisé, et pour quel usage a-t-il été conçu ?
- 04Rôle. Qui fournit ? Qui déploie ? Qui intègre ?
- 05Personnes. Qui reçoit ou subit ses résultats ?
- 06Conséquence. Le résultat informe, recommande, classe, génère ou décide ?
- 07Risque. Un régime particulier — interdit, haut risque ou transparence — est-il susceptible de s’appliquer ?
- 08Humain. Qui peut comprendre, contrôler ou reprendre le résultat lorsque c’est nécessaire ?
- 09Preuve. Que pourra montrer l’entreprise six mois plus tard sur le système, sa version et son utilisation ?
Si trois équipes donnent trois réponses différentes à l’une de ces questions, le problème commence probablement avant même la rédaction juridique.
Des livrables construits autour de vos fonctions IA.
Le but n’est pas de produire une charte IA supplémentaire si personne ne peut l’utiliser. Les livrables doivent permettre de savoir quels systèmes existent, comment ils sont qualifiés, quelles règles ils déclenchent, qui est responsable de quoi, et comment l’entreprise réagit lorsqu’ils changent.
Cartographie et qualification
- Inventaire des fonctions IA
- Fiche d’identité par système
- Identification du modèle et du fournisseur
- Analyse du rôle : fournisseur, déployeur, autre
- Qualification du régime
- Analyse haut risque lorsque nécessaire
- Cartographie des textes connexes
- Calendrier d’application pertinent
Transparence et produit
- Mentions d’interaction avec une IA lorsque nécessaires
- Analyse des contenus générés ou manipulés
- Recommandations de marquage ou de divulgation selon le rôle
- Information dans les interfaces
- Cohérence avec le DSA, P2B ou le RGPD
- Microcopies lorsque la règle doit apparaître à l’écran
Gouvernance
- Règles de contrôle humain
- Procédure de validation
- Gestion des changements de modèle
- Critères déclenchant une nouvelle revue
- Gouvernance des incidents
- Maîtrise de l’IA adaptée aux équipes
- Inventaire opérationnel
- Checklists produit et techniques
Fournisseurs et documentation
- Revue des contrats IA
- Informations à obtenir auprès des fournisseurs
- Répartition des responsabilités
- Documentation des systèmes
- Suivi des versions
- Conservation des éléments utiles
- Clauses relatives aux évolutions ou incidents
- Coordination avec le RGPD et la propriété intellectuelle
Tout n’est pas nécessaire pour chaque fonction. Un chatbot de FAQ et un système à haut risque ne doivent précisément pas produire la même quantité de conformité.
Nous qualifions la fonction avant de rédiger sa conformité.
- 1Scanner. Nous isolons la fonction et partons du produit réel : ce que le système reçoit, ce qu’il produit et ce qui se passe ensuite.
- 2Situer. Modèle, fournisseur, intégrateur, plateforme et utilisateur sont distingués pour identifier le rôle réglementaire pertinent.
- 3Qualifier. Usage, destination, personnes concernées et conséquences sont rapprochés des catégories prévues par l’AI Act et des autres textes pertinents.
- 4Encadrer. Information, documentation, supervision humaine, journaux, contrats et procédures sont ajoutés uniquement là où ils répondent à un besoin identifié.
- 5Rejouer. Nouveau modèle, nouvelle autonomie, nouvelle donnée, nouvelle population ou nouvelle destination déclenchent une nouvelle analyse lorsque c’est nécessaire.
Premier retour écrit sous 48 h. Périmètre et honoraires fixés par écrit avant toute intervention.
L’AI Act lu comme une architecture de fonctions, pas comme une politique abstraite.
La fonction avant l’étiquette
Nous ne commençons pas par demander si votre entreprise « fait de l’IA ». Nous regardons ce que chaque système fait réellement dans le produit.
Le produit avant le PDF
Lorsqu’un contrôle doit exister dans une interface, un workflow, un journal ou une procédure humaine, il ne peut pas être remplacé par une politique publiée sur le site.
Les textes se superposent
Une recommandation peut concerner le DSA ou P2B. Une décision automatisée peut rencontrer le RGPD. Un contenu généré peut soulever des questions de propriété intellectuelle. L’AI Act est replacé dans cette architecture.
Une conformité qui suit les versions
Les systèmes évoluent beaucoup plus vite que les documents juridiques classiques. La méthode doit permettre de détecter lorsqu’un changement technique appelle une nouvelle revue.
Aucun résultat obtenu ni taux de succès ne figure sur ce site : la mission d’un avocat est une obligation de moyens. Ce qui est annoncé porte sur le délai, l’interlocuteur et le périmètre.
Les questions qui apparaissent dès qu’on ouvre réellement le produit.
Nous utilisons un modèle du marché via API. Sommes-nous fournisseur ou déployeur ?
Cela dépend de la manière dont le modèle est intégré et de ce que votre entreprise met elle-même à disposition. Une simple utilisation et la construction d’un système proposé sous votre propre responsabilité ne se raisonnent pas de la même manière. Il faut donc examiner la fonction et la chaîne concrète.
AI Act art. 3 · art. 25
Toute fonctionnalité utilisant de l’IA doit-elle être inscrite dans un registre ?
L’AI Act ne crée pas une obligation universelle identique de registre interne pour toute fonction IA. Un inventaire reste néanmoins très utile pour identifier les systèmes, leurs rôles, leurs versions et les obligations correspondantes. Certaines catégories font par ailleurs l’objet d’exigences de documentation ou d’enregistrement propres.
Un système de recommandation est-il à haut risque ?
Pas automatiquement. La qualification « haut risque » répond aux critères prévus par le règlement. Un système de recommandation peut en revanche relever d’autres règles, notamment celles du DSA ou de P2B selon le service et les personnes concernées.
AI Act art. 6
Devons-nous écrire « généré par IA » sur toutes nos fiches produit ?
Pas comme règle générale découlant automatiquement de l’article 50. Le règlement distingue le marquage technique des sorties par certains fournisseurs, les hypertrucages, et certains textes destinés à informer le public sur des questions d’intérêt public. Le format du contenu, son usage et le rôle de l’entreprise doivent donc être examinés avant de choisir une mention.
AI Act art. 50
L’AI Act oblige-t-il toujours à maintenir un humain dans la boucle ?
Non. Il ne faut pas transformer le contrôle humain en obligation universelle identique pour chaque système. Des exigences précises existent notamment pour certains systèmes à haut risque, tandis que d’autres textes peuvent rendre nécessaire un réexamen humain dans certains contextes. La fonction doit être analysée précisément.
AI Act art. 14
Notre fournisseur dit être conforme à l’AI Act. Sommes-nous couverts ?
Non automatiquement. Sa conformité concerne ses propres obligations et son propre rôle. Votre entreprise doit encore déterminer le sien, son usage du système, et les obligations qui lui reviennent.
Notre IA bloque automatiquement certains vendeurs. Quel texte faut-il regarder ?
Il faut d’abord comprendre la fonction et les données utilisées. Selon le contexte, plusieurs textes peuvent ensuite devenir pertinents : AI Act, DSA, RGPD, P2B ou règles contractuelles. Une même décision peut donc appeler plusieurs analyses différentes.
DSA art. 17 · RGPD art. 22
Devons-nous former toute l’entreprise à l’AI Act ?
Le règlement impose aux fournisseurs et aux déployeurs de prendre des mesures pour soutenir le développement de la maîtrise de l’IA des personnes qui exploitent ou utilisent les systèmes pour leur compte, en tenant compte du contexte. Cela n’impose pas une formation identique ou une certification pour chaque salarié.
AI Act art. 4
Quand faut-il refaire l’analyse d’un système ?
Lorsqu’un changement peut affecter sa fonction ou sa qualification : nouveau modèle, nouvelle destination, passage d’une recommandation à une décision automatique, nouvelle population, nouvelle donnée, modification substantielle ou évolution importante de l’intégration.
Une fonction IA peut avoir plusieurs couches juridiques.
Conformité DSA
Recommandation, classement, modération et restriction de contenus peuvent ajouter des obligations propres aux services intermédiaires et aux plateformes.
DSA art. 17 · art. 2702RGPD des plateformes
Données d’entraînement, prompts, profilage, scoring et décisions automatisées font intervenir les règles relatives aux données personnelles.
RGPD art. 2203Propriété intellectuelle
Entrées, contenus générés, code, modèles et jeux de données soulèvent des questions distinctes de droits et de licences.
CPI art. L131-304Droit des marketplaces
Recommandation d’offres, contrôle des vendeurs, génération de fiches et modération automatisée doivent être replacés dans le rôle de la plateforme vis-à-vis des professionnels et des acheteurs.
DSA · P2BCette page présente des principes généraux. Leur application dépend notamment du système concerné, de sa destination, de son rôle dans la chaîne de valeur, des personnes affectées, de la date de mise sur le marché ou en service et des autres règles applicables. Elle ne constitue pas une consultation juridique.
Premier échange
Montrez-nous ce que vos systèmes font réellement.
Décrivez simplement les fonctions déjà intégrées ou prévues : recommandation de produits, chatbot support, génération de fiches, détection de fraude, modération, scoring vendeurs.
Indiquez également les outils ou modèles utilisés, si le système recommande ou agit automatiquement, et qui est concerné par ses résultats. Ces quelques informations suffisent déjà pour identifier les fonctions à passer au scanner en priorité.
Premier retour écrit sous 48 h. Périmètre et honoraires fixés par écrit avant toute intervention.