AI Act, RGPD et sécurité : mettre un projet IA en conformité

L’AI Act en entreprise ne se traite pas avec une case ajoutée à la fin du projet. La conformité dépend de la finalité du système, du rôle de l’entreprise, des personnes concernées, des données, du niveau de risque et de la manière dont l’outil est utilisé. Le RGPD continue de s’appliquer lorsque des données personnelles sont traitées, tandis que la cybersécurité doit couvrir les risques spécifiques des applications d’IA.

Depuis le 2 août 2026, une grande partie du règlement européen sur l’intelligence artificielle est applicable et les autorités disposent de pouvoirs de contrôle. Certaines dispositions, notamment pour des systèmes à haut risque liés à des produits réglementés, suivent encore un calendrier particulier. Une analyse doit donc se fonder sur la version et les dates applicables au projet réel.

Cet article fournit une méthode de cadrage, pas un avis juridique individuel.

En bref

Qualifiez l’usage, le rôle de l’entreprise et le niveau de risque avant de choisir les mesures.
Le RGPD s’applique dès qu’un traitement de données personnelles entre dans le projet.
Documentez les données, le modèle, les fournisseurs, les tests, la supervision et les incidents.
Protégez l’application contre l’injection de prompt, les fuites, les sorties dangereuses et l’autonomie excessive.
Maintenez des contrôles humains et déterministes pour les décisions ou actions critiques.

Commencer par décrire le système et sa finalité

Un nom commercial ou un modèle ne permet pas de qualifier un système. Décrivez ce qu’il fait, pour qui, à partir de quelles données, avec quel résultat et quelles conséquences. Un même modèle génératif peut servir à reformuler un courriel, présélectionner des candidats ou assister une décision médicale : le niveau de risque change entièrement.

Cartographiez aussi les composants : interface, fournisseurs de modèles, RAG, base de données, outils connectés, règles, journaux et utilisateurs. Identifiez la version et la date de mise en service.

Cette description rejoint le cahier des charges IA et doit être maintenue après le déploiement.

Quel est le rôle de l’entreprise au regard de l’AI Act ?

Une entreprise peut être fournisseur d’un système, déployeur — c’est-à-dire utilisatrice professionnelle sous son autorité —, importateur ou distributeur. Elle peut cumuler des rôles ou devenir fournisseur lorsqu’elle appose sa marque, modifie substantiellement le système ou change sa finalité dans certaines conditions.

Acheter un SaaS ne transfère donc pas toutes les responsabilités à l’éditeur. Le déployeur doit utiliser le système conformément aux instructions, organiser la supervision et respecter les obligations qui lui sont applicables. Le contrat doit permettre d’obtenir les informations nécessaires.

Pour un projet destiné à être commercialisé, la qualification doit être réalisée très tôt, car elle influence la documentation, les tests et les relations avec les fournisseurs de modèles.

Comprendre l’approche par les risques

Le règlement distingue notamment les pratiques interdites, les systèmes à haut risque, certains systèmes soumis à des obligations de transparence et les usages à risque plus limité. La classification dépend de la finalité prévue et des domaines définis par le texte.

Les usages liés au recrutement, à l’éducation, à l’accès à certains services essentiels, à la biométrie ou à des infrastructures critiques peuvent appeler une vigilance particulière. Une fonction apparemment simple de scoring ou de recommandation peut avoir un impact important sur les personnes.

Le calendrier européen actualisé prévoit l’application des règles visant les cas d’usage à haut risque de l’annexe III à partir du 2 décembre 2027. Pour les systèmes à haut risque intégrés à certains produits réglementés, l’échéance est fixée au 2 août 2028. Ces délais ne suspendent ni les autres textes applicables, ni la nécessité de concevoir dès aujourd’hui la documentation, la supervision et la sécurité.

Ne demandez pas seulement « ce modèle est-il conforme ? ». Demandez si le système complet, dans votre contexte et avec vos décisions, relève d’une catégorie et quelles obligations en découlent.

AI literacy : former les personnes qui utilisent l’IA

Les organisations doivent veiller à un niveau suffisant de maîtrise de l’IA pour les personnes qui exploitent des systèmes en leur nom, en tenant compte du contexte et des risques. La formation ne se limite pas au prompt.

Les utilisateurs doivent connaître la mission de l’outil, ses limites, les données autorisées, les erreurs possibles, les situations à transférer et la procédure de signalement. Les responsables doivent comprendre les indicateurs, les coûts et les conditions de suspension.

Conservez la trace des publics, contenus et dates de formation. Adaptez-la lorsque l’usage ou le système évolue.

RGPD : les questions à traiter

La CNIL a publié des recommandations détaillées pour aider les acteurs à déterminer le régime applicable, définir une finalité, qualifier les rôles, choisir une base légale, minimiser les données, informer les personnes et faciliter leurs droits.

Pour le projet, documentez :

les catégories de données personnelles et de personnes ;
la finalité et la base légale ;
les sources, destinataires et transferts ;
les durées de conservation ;
les mesures de sécurité ;
l’information et l’exercice des droits ;
la nécessité d’une analyse d’impact.

Une donnée accessible en interne n’est pas automatiquement réutilisable pour entraîner ou évaluer une IA. Vérifiez la compatibilité de la finalité et les conditions de collecte.

Minimiser les données et maîtriser les fournisseurs

Transmettez seulement ce qui est nécessaire. Masquez ou pseudonymisez les informations lorsque le modèle n’a pas besoin de connaître l’identité. Évitez de placer des données sensibles dans les instructions, les journaux ou les exemples de démonstration.

Recensez les sous-traitants : éditeur, modèle, hébergeur, base vectorielle, observabilité, annotation et support. Examinez les lieux de traitement, la réutilisation, la suppression, les incidents et les changements de fournisseur.

Le guide sur les données d’un projet IA fournit les contrôles opérationnels.

Transparence envers les utilisateurs

Selon le système et le contexte, il peut être nécessaire d’informer une personne qu’elle interagit avec une IA ou qu’un contenu a été généré ou manipulé. Même en dehors d’une obligation spécifique, une information claire peut éviter une confusion et améliorer la confiance.

Expliquez aussi les limites et le canal humain. Pour une décision ayant un effet sur une personne, la transparence ne se résume pas à afficher « propulsé par l’IA ». L’organisation doit pouvoir expliquer le rôle du système, les données pertinentes et les possibilités de contestation selon le cadre applicable.

Supervision humaine : donner un pouvoir réel

Une validation humaine n’est utile que si la personne possède les compétences, le temps, les informations et l’autorité pour contredire le système. Évitez le simple clic de confirmation après une recommandation présentée comme certaine.

Montrez les sources, les incertitudes et les éléments manquants. Organisez les cas d’escalade et la suspension. Mesurez le taux de corrections et les situations où l’utilisateur suit l’outil malgré un doute.

Pour un agent, l’humain doit pouvoir arrêter les actions, consulter les journaux et annuler lorsque cela est possible.

Sécurité des LLM : les risques spécifiques

OWASP recense plusieurs catégories majeures, dont l’injection de prompt, la divulgation d’informations sensibles, les risques de chaîne d’approvisionnement, le traitement non sécurisé des sorties et l’autonomie excessive.

Une instruction malveillante peut être saisie par un utilisateur ou cachée dans un document consulté par un RAG. Le modèle peut produire du code ou une commande dangereuse si la sortie est exécutée sans validation. Un agent doté de droits trop larges peut multiplier l’impact.

Les mesures incluent : séparation des instructions et des données, validation des entrées et sorties, moindre privilège, fonctions étroites, confirmations, limites de volume, journalisation, tests d’attaque et surveillance. Les secrets ne doivent jamais être placés dans le prompt système.

Contrats et réversibilité

Le contrat précise les rôles, finalités, données, sous-traitants, niveaux de service, incidents, audits, propriété, maintenance et fin de relation. Pour les modèles et SaaS, prévoyez l’information en cas de changement ayant un impact sur la qualité ou la conformité.

Identifiez ce que l’entreprise récupère : données, index, configurations, prompts, jeux de test, journaux, documentation et développements. Une réversibilité théorique sans format, délai ni assistance peut être inutilisable.

Le choix d’un prestataire IA doit intégrer sa capacité à documenter ces points.

Documenter et surveiller pendant tout le cycle de vie

Conservez la description du système, les versions, les sources, les résultats des tests, les décisions, les incidents et les actions correctives. Réévaluez le risque lorsque la finalité, les utilisateurs, les données, les outils ou le modèle changent.

Le cadre de gestion des risques du NIST propose quatre fonctions complémentaires : gouverner, cartographier, mesurer et gérer. Cette logique rappelle que la conformité n’est pas un audit ponctuel mais un processus.

Prévoyez des indicateurs de performance et de risque, des seuils d’alerte et un responsable capable de suspendre le système.

Une checklist de démarrage

Avant le POC, vérifiez les éléments suivants :

la finalité et les utilisateurs sont décrits ;
les rôles AI Act et RGPD sont examinés ;
les données et fournisseurs sont inventoriés ;
les accès et secrets sont limités ;
un jeu de test inclut les cas difficiles et interdits ;
les erreurs critiques et la supervision sont définies ;
les coûts, journaux et incidents seront suivis ;
les documents contractuels et de transparence sont planifiés.

Cette liste n’épuise pas les obligations, mais elle évite de construire un POC impossible à sécuriser ensuite.

Questions fréquentes sur l’AI Act en entreprise

Toutes les entreprises qui utilisent une IA sont-elles concernées ?

Le règlement prévoit des obligations différentes selon le rôle, le système et le risque. Un usage professionnel peut relever des obligations du déployeur, tandis qu’un fournisseur supporte d’autres exigences. Il faut qualifier le cas précis.

Le respect du RGPD suffit-il pour être conforme à l’AI Act ?

Non. Les deux cadres se complètent. Le RGPD porte sur les données personnelles ; l’AI Act ajoute des règles propres aux systèmes d’IA. D’autres textes sectoriels et de cybersécurité peuvent aussi s’appliquer.

Un chatbot interne doit-il être sécurisé comme un logiciel classique ?

Oui, avec des risques supplémentaires liés au modèle et aux contenus. Authentification, droits, chiffrement et journaux restent nécessaires, auxquels s’ajoutent les tests d’injection, de fuite et d’actions non autorisées.

Sources utiles

Sécurisez le cadrage de votre projet IA

Décrivez la finalité, les utilisateurs, les données, le niveau d’autonomie et les contraintes de votre secteur. Codimiq qualifie le besoin avant de l’orienter vers des prestataires IA, data, cybersécurité ou conformité adaptés.

Décrire mon projet IA