IA et RGPD : déployer l’IA en entreprise en restant conforme

Oui, une entreprise peut déployer l’IA en restant conforme au RGPD, le règlement européen qui encadre le traitement des données personnelles depuis 2018, à trois conditions : savoir quelles données personnelles transitent par le système, choisir où elles sont traitées (quel fournisseur, quel hébergement) et garder la capacité de les retrouver puis de les effacer sur demande. Ces trois points relèvent de choix d’architecture, pas de magie juridique : ils se décident au cadrage du projet, pas après la mise en production.

La question revient dans presque tous les projets que je cadre pour des PME et des ETI : peut-on brancher l’IA générative, cette IA qui produit du texte ou des images à la demande, sur nos données clients sans prendre de risque juridique ? La réponse honnête tient en deux temps. Techniquement, oui, des architectures existent pour garder la maîtrise de vos données. Juridiquement, cet article vous donne les bonnes questions à poser, mais il ne remplace pas l’avis d’un DPO (le délégué à la protection des données) ou d’un avocat. Voici comment aborder le sujet sans le subir.

Où est le risque RGPD concrètement

Le risque RGPD lié à l’IA vient bien plus des usages non encadrés que des projets structurés. Trois situations concentrent l’essentiel du danger.

Les usages sauvages des employés. Un commercial qui colle un fichier client dans un chatbot grand public gratuit, c’est-à-dire un assistant conversationnel accessible à tous sur le web, envoie des données personnelles vers un service que personne n’a validé, sans contrat et sans garantie sur la réutilisation de ces données. C’est aujourd’hui le scénario le plus fréquent, et le plus difficile à détecter, car il ne passe par aucun projet officiel.

Les données qui partent sans encadrement. Beaucoup d’outils IA grand public traitent les données hors de l’Union européenne, dans des conditions que l’entreprise ne connaît pas. Le problème n’est pas la destination en soi : c’est l’absence d’encadrement contractuel et de visibilité sur ce que devient la donnée une fois envoyée.

L’absence de registre. Si personne ne sait quelles données personnelles transitent par quels outils IA, impossible de répondre à une demande d’accès ou d’effacement, ni de documenter les traitements. L’entreprise se retrouve incapable de prouver quoi que ce soit, et cette incapacité est un problème en elle-même.

À l’inverse, un projet IA structuré force à répondre à ces questions dès la conception. Paradoxalement, lancer un projet encadré est souvent le meilleur moyen de reprendre la main sur des usages qui existent déjà en douce. Une charte d’usage interne, qui précise quelles données peuvent être saisies dans quels outils, complète le dispositif côté gouvernance et donne un cadre à ces pratiques.

Les cinq questions à poser avant tout projet IA

Avant de signer avec un fournisseur ou de lancer un développement, cinq questions structurent l’analyse. Un prestataire sérieux y répond sans détour.

1. Quelles données personnelles sont concernées ? Il s’agit de cartographier ce qui entrera réellement dans le système : noms, e-mails, contenus de conversations, documents RH. Beaucoup de projets découvrent à cette étape qu’ils peuvent fonctionner avec bien moins de données personnelles que prévu.

2. Où le modèle est-il hébergé ? Le LLM, ce grand modèle de langage qui comprend et rédige du texte, tourne quelque part : chez un fournisseur américain, sur un cloud européen, sur vos propres serveurs. Chaque option a des implications différentes, à documenter avant de choisir.

3. Le fournisseur s’engage-t-il à ne pas entraîner ses modèles sur vos données ? Les offres entreprise des grands fournisseurs incluent généralement cet engagement contractuel, contrairement aux versions grand public gratuites. C’est un critère de sélection, pas un détail.

4. Comment purger une donnée ? Si un client demande l’effacement de ses données, il faut pouvoir les retrouver dans les index, les journaux et les sauvegardes, puis les supprimer partout. Cette capacité se conçoit dès le départ : la rajouter après coup coûte cher.

5. Qui a accès aux journaux de conversation ? Les échanges avec une IA contiennent souvent des données personnelles. Qui peut les lire, combien de temps sont-ils conservés, servent-ils à autre chose qu’au support : autant de points à trancher et à écrire noir sur blanc.

Les architectures qui simplifient la conformité RGPD

Certains choix d’architecture réduisent mécaniquement la surface de risque. Aucun ne garantit la conformité à lui seul, mais tous rendent le travail du DPO plus simple.

Garder les données chez vous. L’auto-hébergement consiste à faire tourner les logiciels sur vos propres serveurs plutôt que chez un tiers. Dans une architecture de type RAG, ce système qui cherche les passages pertinents dans vos documents avant que l’IA rédige sa réponse, la base documentaire, l’index de recherche et l’orchestration (la coordination des différentes briques du système) peuvent rester intégralement sur votre infrastructure. Seuls de courts extraits partent vers le modèle au moment de la question, et même ce dernier maillon peut être internalisé avec un modèle open source. Le fonctionnement de cette approche est détaillé dans le guide complet du RAG.

La minimisation. N’envoyer au modèle que le strict nécessaire : anonymiser ou pseudonymiser quand c’est possible, filtrer les champs sensibles, tronquer ce qui ne sert pas la réponse. Moins de données personnelles en circulation, c’est moins de choses à protéger, à journaliser et à effacer.

Les offres entreprise des fournisseurs. Les grands fournisseurs de modèles proposent des offres avec engagements contractuels : pas d’entraînement sur vos données, durées de rétention définies, parfois hébergement européen. Pour beaucoup de PME, c’est le meilleur compromis entre effort et maîtrise.

La journalisation et l’effacement prévus dès la conception. Savoir qui a demandé quoi, quand, avec quelles données, et pouvoir effacer une information partout où elle apparaît. Ces deux capacités coûtent peu quand elles sont posées au début du projet.

Le tableau suivant résume les trois grandes approches et leur effort de mise en œuvre.

Ce que montrent deux projets réels

Deux missions récentes illustrent ces principes en conditions réelles, avec la prudence qui s’impose : ces architectures facilitent la conformité, elles ne la garantissent pas à elles seules.

Pour un acteur du conseil en droit social, j’ai construit un moteur de recherche juridique RAG qui indexe plus de 200 000 articles de conventions collectives. Le corpus est sensible et stratégique pour le cabinet. Le déploiement est conteneurisé et auto-hébergé : la base documentaire, l’index de recherche et les journaux restent dans le périmètre du client, et seuls les extraits nécessaires à chaque réponse partent vers le modèle. L’effacement et l’export des données ont été prévus dès la conception, pas ajoutés après coup.

Chez Geneva Trust, maison d’édition juridique et financière, la plateforme d’automatisation éditoriale est elle aussi déployée en conteneurs auto-hébergés. Les prompts (les instructions données à l’IA) sont versionnés en base avec possibilité de retour arrière, et rien n’est publié sans décision humaine. L’entreprise sait à tout moment ce que son IA traite, avec quelles consignes, et peut le montrer.

Ce que la conformité RGPD change au budget et au planning

La conformité coûte nettement moins cher prévue dès la conception que rattrapée après la mise en production. Journaliser les échanges, prévoir l’effacement, minimiser les données envoyées au modèle : posées au cadrage, ces exigences se traduisent par des choix de conception, pas par un surcoût majeur. Ajoutées après coup, elles imposent de reprendre l’architecture, de migrer des données et de refaire des tests, avec un coût sans commune mesure.

Côté planning, impliquez votre DPO ou votre conseil juridique dès le cadrage, pas à la veille du lancement. Selon les données concernées et l’ampleur du traitement, votre DPO déterminera aussi si une analyse d’impact (AIPD), l’étude formelle des risques pour les personnes exigée par le RGPD dans certains cas, est nécessaire avant le lancement. Un aller-retour au stade du schéma d’architecture prend quelques jours. Le même aller-retour sur un système déjà développé peut bloquer le lancement pendant des semaines. Un audit IA en amont sert précisément à cela : cartographier les usages existants (y compris les usages sauvages), identifier les données concernées et poser une architecture cible avant d’écrire la moindre ligne de code.

Un point doit rester parfaitement clair : cet article est un éclairage technique, pas un avis juridique. Le RGPD s’applique différemment selon votre secteur, vos données et vos traitements, l’AI Act (le règlement européen sur l’intelligence artificielle) déploie progressivement ses propres obligations, et la CNIL publie des recommandations utiles sur l’IA. Faites valider votre dispositif par un DPO ou un avocat spécialisé avant tout déploiement.

Vous voulez déployer l’IA sans découvrir les questions de conformité en cours de route ? Je suis Antoine Guerra, développeur et consultant IA freelance, diplômé d’Epitech et dans l’intelligence artificielle depuis 2018. J’interviens à distance dans toute la France comme consultant IA : un interlocuteur unique qui audite vos usages, conçoit l’architecture et développe le système, en dialogue avec votre DPO. Le premier échange est gratuit et vous recevez un devis sous 48 h.