Construire un assistant IA conforme au RGPD des le premier jour

En mai 2023, la Commission irlandaise de protection des donnees a inflige a Meta une amende de 1,2 milliard d’euros pour avoir transfere des donnees d’utilisateurs europeens vers les Etats-Unis sans garanties adequates. Deux ans plus tot, la CNPD luxembourgeoise avait impose a Amazon une sanction de 746 millions d’euros pour des violations du RGPD liees a son systeme de ciblage publicitaire. En 2019, la CNIL francaise avait inflige a Google une amende de 50 millions d’euros pour manque de transparence et de consentement valide dans la publicite personnalisee.

Ce ne sont pas des cas marginaux. Ce sont les consequences previsibles d’une approche qui consiste a construire d’abord des produits avides de donnees, puis a plaquer la conformite en matiere de vie privee apres coup. L’industrie de l’IA, avec son appetit insatiable pour les donnees d’entrainement et ses pipelines de traitement opaques, s’engage directement dans le meme champ de mines.

Quand nous avons commence a construire Morphee, nous avons pris une decision qui a faconne chaque choix architectural par la suite : la conformite au RGPD serait une propriete structurelle du systeme, pas une revue juridique avant le lancement. Cet article explique ce que cela signifie en pratique, pourquoi la plupart des applications IA echouent a l’atteindre, et les decisions d’ingenierie specifiques que nous avons prises pour y parvenir.

Comprendre le RGPD comme une specification d’ingenierie

La plupart des developpeurs decouvrent le RGPD comme un document juridique. Nous le traitons comme une specification d’ingenierie. Les principes fondamentaux du reglement, codifies dans l’Article 5, se traduisent directement en contraintes de conception systeme.

Liceite, loyaute et transparence (Article 5(1)(a)) signifie que chaque operation de traitement de donnees doit avoir une base juridique valide en vertu de l’Article 6 — qu’il s’agisse du consentement explicite, de la necessite contractuelle, d’une obligation legale, d’un interet vital, de l’interet public ou de l’interet legitime. Pour les assistants IA traitant des donnees conversationnelles, cette determination n’est pas triviale. Nous reviendrons sur la raison pour laquelle l’interet legitime ne fonctionne presque jamais pour l’entrainement de l’IA.

Limitation des finalites (Article 5(1)(b)) signifie que des donnees collectees dans un but precis ne peuvent pas etre reutilisees dans un autre but sans une base juridique compatible. Quand un assistant IA collecte des donnees de conversation pour fournir des reponses, utiliser ces memes donnees pour entrainer un modele generaliste est une finalite entierement differente.

Minimisation des donnees (Article 5(1)(c)) signifie que vous ne collectez que ce qui est strictement necessaire. Ce principe est fondamentalement en contradiction avec la philosophie IA dominante du “tout collecter, le modele determinera ce qui compte”.

Limitation de la conservation (Article 5(1)(e)) signifie que les donnees personnelles ne doivent pas etre conservees plus longtemps que necessaire. Pour un systeme IA qui a ingere des donnees utilisateur dans les poids du modele, cela cree un probleme quasi insoluble — un sujet qui a suscite une attention regulatoire considerable.

Integrite et confidentialite (Article 5(1)(f)) signifie des mesures techniques appropriees pour proteger les donnees contre l’acces non autorise, la perte accidentelle ou la destruction. Le Considerant 78 developpe ce point, appelant a des “mesures techniques et organisationnelles appropriees” tant au moment de la conception qu’au moment du traitement.

Responsabilite (Article 5(2)) signifie que vous devez pouvoir demontrer la conformite, pas simplement l’affirmer. C’est la ou la plupart des organisations echouent. Il ne suffit pas d’avoir une politique de confidentialite. Vous avez besoin de preuves auditables que vos systemes l’appliquent.

Pourquoi la plupart des applications IA echouent face au RGPD

L’industrie de l’IA a un probleme structurel de conformite. Ce n’est pas que les entreprises ignorent deliberement le reglement. C’est que l’approche dominante de construction de produits IA est fondamentalement incompatible avec plusieurs principes fondamentaux du RGPD.

Entrainement sur les donnees utilisateur sans consentement valide

La base juridique la plus courante invoquee par les entreprises d’IA pour l’entrainement sur les donnees utilisateur est l’interet legitime (Article 6(1)(f)). L’argument est le suivant : “Nous avons un interet legitime a ameliorer notre produit, et l’entrainement sur les donnees utilisateur sert cet interet.”

Cet argument est faible pour plusieurs raisons. L’interet legitime necessite un test de proportionnalite : l’interet de l’entreprise ne doit pas l’emporter sur les droits fondamentaux de la personne concernee. Quand la personne concernee est un enfant utilisant un assistant IA familial, ces droits ont un poids supplementaire en vertu du Considerant 38. Le Comite europeen de la protection des donnees a signale a plusieurs reprises que l’entrainement de modeles IA justifie un consentement explicite plutot qu’un recours a l’interet legitime. Et la decision Meta a clairement montre que les regulateurs rejettent les pretentions d’interet legitime, meme venant d’entreprises dotees d’equipes juridiques sophistiquees.

Le consentement valide en vertu du RGPD doit etre libre, specifique, eclaire et univoque (Article 4(11)). Un generique “J’accepte les Conditions d’utilisation” ne repond pas a cette norme quand les conditions incluent une clause sur l’entrainement de modeles IA avec les donnees conversationnelles.

Le probleme du droit a l’effacement

L’Article 17 etablit le droit a l’effacement — communement appele le “droit a l’oubli”. Quand un utilisateur demande la suppression de ses donnees, le responsable du traitement doit les effacer “dans les meilleurs delais”.

Pour les applications traditionnelles, c’est simple : supprimer les lignes de la base de donnees, purger les sauvegardes, c’est fait. Pour les applications IA, c’est quasiment inextricable. Les donnees utilisateur incorporees dans les poids du modele par l’entrainement ne peuvent pas simplement etre “desentrainees”. Les donnees sont dissoutes dans des milliards de parametres en virgule flottante. Les techniques de desapprentissage automatique existent en recherche mais ne sont pas encore fiables a l’echelle de la production.

Chaque entreprise d’IA entrainant sur des donnees utilisateur fait face a un choix : investir dans un desapprentissage couteux et imparfait, reentrainer le modele de zero sans les donnees de l’utilisateur supprime (d’un cout prohibitif), ou ne jamais entrainer sur les donnees utilisateur.

Nous avons choisi la troisieme option.

Minimisation des donnees contre l’approche “tout collecter”

Le paradigme dominant dans le developpement IA est de collecter autant de donnees que possible. Plus de donnees signifie generalement de meilleurs modeles, et le stockage est bon marche. Cette approche est directement antagoniste a l’Article 5(1)(c).

La minimisation des donnees ne consiste pas seulement a collecter moins de champs. Il s’agit de concevoir des systemes qui limitent structurellement quelles donnees peuvent etre accedees par quels composants. Un systeme de journalisation qui enregistre le contenu integral des conversations a des fins de debogage viole la minimisation des donnees, meme si aucun humain ne lit jamais ces journaux. Les donnees existent, elles peuvent faire l’objet d’une injonction, elles peuvent fuiter, et leur seule existence constitue un risque de conformite.

Transferts transfrontaliers de donnees et Schrems II

La decision Schrems II (juillet 2020) a invalide le Privacy Shield UE-US et impose des exigences strictes aux clauses contractuelles types (CCT) pour le transfert de donnees vers des pays sans protection adequate des donnees. L’amende infligee a Meta etait une consequence directe de cette decision.

Pour les applications IA, les transferts transfrontaliers sont quasiment inevitables si vous dependez de modeles heberges dans le cloud. Chaque appel API a un LLM cloud achemine des donnees conversationnelles a travers des serveurs potentiellement situes hors de l’UE. Meme avec des CCT en place, les mesures supplementaires requises apres Schrems II sont effectivement impossibles quand le fournisseur doit dechiffrer les donnees pour les traiter.

La solution architecturalement saine est de traiter les donnees localement, sur l’appareil de l’utilisateur, dans une juridiction qu’il controle. Le traitement cloud devrait etre un choix explicite, protege par le consentement — pas le mode par defaut.

Article 25 : Protection des donnees des la conception et par defaut

L’Article 25 est la disposition la plus significative du reglement sur le plan architectural. Il exige des responsables de traitement qu’ils mettent en oeuvre des “mesures techniques et organisationnelles appropriees” tant au moment de la determination des moyens de traitement qu’au moment du traitement lui-meme. Il exige en outre que, par defaut, seules les donnees personnelles necessaires a chaque finalite specifique soient traitees.

Ce n’est pas une recommandation. C’est une obligation legale. Et elle impose que la vie privee soit une propriete structurelle du systeme, pas une option de configuration ajoutee par-dessus.

Voici comment nous avons implemente l’Article 25 a chaque couche de l’architecture de Morphee.

Isolation des donnees par groupe

Dans Morphee, chaque donnee utilisateur appartient a un groupe — une famille, une classe ou une equipe. Chaque requete en base de donnees du systeme filtre par identifiant de groupe. Il ne s’agit pas d’un controle d’acces au niveau applicatif qui pourrait etre contourne par un developpeur imprudent ou une attaque par injection. C’est une contrainte structurelle integree au niveau des requetes — chaque operation de recuperation de donnees inclut un filtre de groupe obligatoire comme condition parametree.

Il n’existe aucune requete dans le code qui recupere des donnees sans filtre de groupe. Il n’existe aucun endpoint d’administration qui renvoie des donnees entre groupes. La frontiere d’isolation des donnees est le groupe, et elle est appliquee au niveau de la couche de persistance, rendant les fuites de donnees entre groupes architecturalement impossibles via les chemins applicatifs normaux.

Cette conception simplifie egalement la conformite a l’Article 17. Quand un groupe exerce son droit a l’effacement, nous supprimons le groupe et chaque enregistrement lie en cascade disparait avec lui. Il n’y a pas d’enregistrements orphelins disperses dans des tables denormalisees.

Stockage securise des identifiants : les identifiants ne touchent jamais la base de donnees

Les identifiants — cles API, jetons OAuth, cles de chiffrement — sont les donnees les plus sensibles de toute application. La plupart des applications les stockent dans la base de donnees, parfois chiffres, parfois non. Si la base de donnees est compromise, chaque identifiant est expose.

L’architecture de Morphee stocke les identifiants dans le stockage securise natif du systeme d’exploitation : le Trousseau macOS, le Gestionnaire d’identifiants Windows ou l’equivalent sur mobile. La base de donnees ne les voit jamais. L’application recupere les identifiants depuis le stockage securise au moment de l’execution, les utilise pour l’operation specifique et ne les persiste jamais en dehors de l’enclave securisee geree par le systeme d’exploitation.

C’est a la fois une mesure de securite et une mesure de minimisation des donnees. La base de donnees ne contient que les donnees minimales necessaires au fonctionnement de l’application. Les identifiants sont necessaires a l’execution, pas a la base de donnees. Le stockage securise les garde la ou ils doivent etre.

Consentement granulaire et auditable

Le consentement RGPD doit etre granulaire — vous ne pouvez pas regrouper des activites de traitement sans rapport dans une seule demande de consentement (Article 7, Considerant 32). Le systeme de consentement de Morphee implemente cela avec des types de consentement granulaires pour chaque activite de traitement — du partage de donnees avec l’IA cloud a l’extraction de memoire, en passant par les integrations de services tiers et les preferences de notification. Chaque activite de traitement distincte possede son propre type de consentement controlable independamment.

Chaque fonctionnalite qui traite des donnees personnelles via un tiers verifie le consentement de maniere programmatique avant de proceder. Si l’utilisateur n’a pas accorde le type de consentement specifique requis, l’operation ne s’execute pas. Le statut du consentement est stocke par utilisateur, et le retrait est immediat — revoquer le consentement pour le traitement IA cloud arrete immediatement tous les appels aux modeles cloud pour cet utilisateur.

Ce n’est pas un simple bouton “mode privee” binaire. C’est un systeme de consentement a grain fin qui correspond directement a des activites de traitement specifiques, exactement comme le RGPD l’exige.

Suppressions en cascade : droit a l’effacement structurel

La conformite a l’Article 17 n’est aussi solide que votre modele de donnees. Si les donnees utilisateur sont dispersees dans des tables sans integrite referentielle, la suppression devient un processus manuel sujet aux erreurs et aux oublis.

Le schema de Morphee utilise la suppression en cascade automatique pour toutes les donnees propres a l’utilisateur. Quand un compte utilisateur est supprime, chaque relation de cle etrangere propage automatiquement la suppression. Conversations, memoires, preferences, enregistrements de consentement, jetons de session — tout est supprime en une seule operation atomique. Pour les donnees partagees qui doivent survivre a la suppression d’un utilisateur (comme les parametres au niveau du groupe), l’association personnelle est supprimee tandis que l’enregistrement lui-meme est preserve.

Nous ne comptons pas sur des taches en arriere-plan, des scripts de nettoyage ou une coherence eventuelle pour la suppression. La suppression est immediate, complete et verifiable.

Journalisation et evenements sans donnees personnelles

La minimisation des donnees s’etend au-dela du magasin de donnees principal. Les journaux et les flux d’evenements sont frequemment des vecteurs negliges de fuite de donnees personnelles.

Le systeme de journalisation de Morphee applique une regle stricte : aucune donnee personnelle identifiable a aucun niveau de journalisation. Les journaux referencent les utilisateurs par user_id, les groupes par group_id et les memoires par memory_id. Jamais par email, nom ou contenu. Cela s’applique au niveau TRACE comme au niveau ERROR — il n’y a pas d’exceptions au niveau debug qui vident le contenu des conversations.

Notre systeme d’evenements interne suit le meme principe. Les charges utiles des evenements ne transportent que des identifiants opaques. Si un consommateur en aval a besoin d’afficher le nom d’un utilisateur, il le recupere via le chemin API standard avec controle d’acces, qui applique l’isolation de groupe et la journalisation d’audit. Le flux d’evenements lui-meme est exempt de donnees personnelles par construction.

Cette conception signifie que nos journaux peuvent etre envoyes a n’importe quel service de surveillance sans creer une nouvelle activite de traitement de donnees necessitant une base juridique en vertu de l’Article 6.

Traitement local par defaut : le choix architectural par defaut

Le moyen le plus efficace d’eviter les problemes de transfert transfrontalier de donnees est de ne pas transferer de donnees du tout. Le pipeline de traitement par defaut de Morphee s’execute entierement sur l’appareil de l’utilisateur :

Embeddings : Generes localement a l’aide de modeles d’embedding optimises qui fonctionnent sur CPU sans acces reseau.
Inference de modeles : Executee sur l’appareil avec prise en charge de l’acceleration CPU et GPU.
Stockage memoire : Une base de donnees vectorielle embarquee pour la recherche semantique et des connaissances versionnees pour les informations structurees, le tout stocke localement.
Traitement audio et video : Sur l’appareil via les API natives de la plateforme.

Le traitement cloud est disponible pour les utilisateurs souhaitant acceder a des modeles plus puissants, mais il est protege par un consentement explicite. La configuration par defaut traite tout localement. Ce n’est pas un “mode confidentialite” — c’est le mode de fonctionnement standard. Le cloud est l’exception, pas la regle.

Pour une analyse approfondie des compromis architecturaux entre le traitement local et cloud de l’IA, consultez notre article sur l’IA locale vs IA cloud.

Articles 35 et 30 : Documentation de conformite vivante

Le RGPD exige deux documents specifiques pour les organisations traitant des donnees personnelles a grande echelle : une Analyse d’impact relative a la protection des donnees (AIPD, Article 35) et un Registre des activites de traitement (RAT, Article 30).

La plupart des organisations traitent ces documents comme des textes statiques produits lors des efforts de conformite initiaux et rarement mis a jour. Nous maintenons les deux comme des documents vivants qui evoluent avec le produit.

Notre AIPD est mise a jour chaque fois que nous introduisons une nouvelle activite de traitement, integrons un nouveau service tiers ou modifions le fonctionnement des flux de donnees existants. Elle identifie les risques, evalue leur gravite et leur probabilite, et documente les mesures d’attenuation en place. Pour un assistant IA qui gere des conversations familiales — incluant potentiellement les donnees d’enfants — l’AIPD n’est pas une formalite. C’est le document qui nous oblige a affronter les implications en matiere de vie privee de chaque fonctionnalite avant qu’elle ne soit deployee.

Notre RAT repertorie chaque activite de traitement du systeme : quelles donnees sont traitees, la base juridique du traitement, les durees de conservation, les categories de personnes concernees et les tiers eventuellement impliques. Quand une nouvelle fonctionnalite ajoute une activite de traitement, le RAT est mis a jour dans le cadre du processus de developpement, pas apres coup.

Les deux documents sont maintenus en controle de version aux cotes du code, revus avec la meme rigueur que les modifications de code. C’est la responsabilite au sens de l’Article 5(2) : nous pouvons demontrer, a tout moment, exactement quelles donnees nous traitons, pourquoi, et quelles garanties sont en place.

La checklist de conformite RGPD pour les produits IA

Sur la base de notre experience de construction de Morphee et de notre etude du paysage reglementaire, voici dix points specifiques que chaque equipe produit IA devrait evaluer.

1. Auditez votre base juridique pour chaque activite de traitement. Ne comptez pas sur l’interet legitime pour l’entrainement IA sur des donnees utilisateur. Si vous devez entrainer, obtenez un consentement explicite, granulaire et librement donne en vertu de l’Article 6(1)(a). Documentez la base juridique dans votre RAT.

2. Implementez l’isolation des donnees au niveau des requetes. Les politiques de controle d’acces peuvent etre contournees. Le filtrage au niveau des requetes (chaque SELECT inclut un filtre tenant/groupe) ne le peut pas. Rendez l’acces aux donnees entre tenants architecturalement impossible, pas simplement interdit par une politique.

3. Concevez pour la suppression des le premier jour. Utilisez des contraintes de cles etrangeres avec suppression en cascade automatique pour les donnees propres a l’utilisateur. Testez que la suppression de compte supprime effectivement chaque enregistrement. Executez des tests automatises qui creent un utilisateur, peuplent des donnees dans toutes les tables, suppriment l’utilisateur et verifient qu’il reste zero enregistrement.

4. Separez le stockage des identifiants des donnees applicatives. Utilisez le stockage securise natif du systeme d’exploitation pour les cles API, jetons et secrets. Votre base de donnees ne devrait jamais contenir d’identifiants, meme chiffres. Une compromission de base de donnees ne devrait pas compromettre les integrations tierces.

5. Eliminez les donnees personnelles des journaux et flux d’evenements. Auditez chaque instruction de journalisation et chaque charge utile d’evenement. Remplacez les noms, emails et contenus par des identifiants opaques. Cela s’applique a tous les niveaux de journalisation, y compris debug et trace. Des regles de linting automatisees peuvent l’imposer.

6. Implementez un consentement granulaire, pas des boutons generiques. Chaque activite de traitement distincte necessitant un consentement devrait avoir son propre type de consentement. Les utilisateurs doivent pouvoir accorder et revoquer le consentement pour des activites individuelles de maniere independante. Le retrait doit etre immediat et effectif.

7. Privilegiez le traitement local par defaut. Si une operation de traitement peut s’executer sur l’appareil, elle devrait s’executer sur l’appareil par defaut. Le traitement cloud devrait necessiter un consentement explicite avec une explication claire de quelles donnees seront envoyees et ou. Cela elimine les preoccupations de transfert transfrontalier pour le cas par defaut.

8. Maintenez votre AIPD et votre RAT comme des documents vivants. Mettez-les a jour a chaque sortie de fonctionnalite. Stockez-les en controle de version. Revisez les modifications des documents de conformite avec le meme processus que celui utilise pour la revue de code.

9. Implementez et testez votre plan de reponse aux violations de donnees. L’Article 33 exige la notification a l’autorite de controle dans les 72 heures. L’Article 34 exige la notification aux personnes concernees dans les cas a haut risque. Ayez un plan. Conduisez des exercices de simulation. Sachez qui est votre autorite de controle et comment la contacter.

10. Conduisez des audits de confidentialite reguliers. N’attendez pas qu’une autorite de protection des donnees vous audite. Menez des audits internes a cadence fixe. Verifiez la presence de donnees personnelles dans les journaux, verifiez l’exhaustivite des suppressions, testez l’application du consentement et examinez le partage de donnees avec des tiers. Documentez les constatations et les actions correctives.

Le cout de l’erreur

Les amendes sont significatives — la penalite de 1,2 milliard d’euros infligee a Meta est la plus importante jamais prononcee au titre du RGPD — mais elles ne sont pas le seul cout. Les actions d’application prennent des annees a se resoudre, consomment l’attention des dirigeants et les ressources d’ingenierie, et endommagent la confiance des utilisateurs d’une maniere qu’aucune campagne marketing ne peut reparer.

Pour les produits IA, le risque est amplifie. Le Reglement europeen sur l’IA ajoute des obligations en matiere de transparence, de supervision humaine et de gouvernance des donnees qui vont au-dela du RGPD. Construire une architecture respectueuse de la vie privee maintenant, ce n’est pas seulement une question de conformite actuelle — c’est se preparer a l’environnement reglementaire qui se dessine clairement.

La vie privee comme avantage concurrentiel

Il y a une tendance a considerer la conformite RGPD comme un centre de cout — une taxe sur l’innovation. Nous voyons les choses differemment.

Quand les familles confient a Morphee leurs conversations, les questions de leurs enfants, leurs routines quotidiennes, cette confiance est l’actif le plus precieux du produit. Chaque decision architecturale decrite dans cet article — isolation de groupe, traitement local, consentement granulaire, journalisation sans donnees personnelles — existe pour gagner et maintenir cette confiance.

Les familles qui utilisent Morphee ne sont pas des personnes concernees abstraites. Ce sont des gens qui ont choisi un assistant IA precisement parce qu’il respecte leur vie privee. Ce choix n’est possible que parce que nous avons integre la conformite dans l’architecture des le premier commit, pas lors du dernier sprint.

Pour en savoir plus sur notre approche de la vie privee specifiquement pour les familles avec enfants, consultez notre article detaille sur la vie privee de l’IA et les donnees familiales. Pour un apercu complet de notre posture de securite et de nos engagements en matiere de confidentialite, visitez notre page securite.

La vie privee n’est pas une fonctionnalite que nous avons ajoutee. C’est la fondation sur laquelle nous avons construit. Si vous recherchez un assistant IA qui traite les donnees de votre famille avec le soin qu’elles meritent, rejoignez la liste d’attente pour etre parmi les premiers a decouvrir Morphee.