Privacy by Design et Safety by Design IA : intégrer la conformité dès la conception
Lancer un projet d'IA en interne sans cadre de conformité, c'est construire sur du sable. Entre les exigences du RGPD, les obligations de l'AI Act et la pression croissante des auditeurs, les équipes projet se retrouvent souvent à corriger en urgence ce qui aurait pu être anticipé. Privacy by Design et Safety by Design offrent une réponse structurée : intégrer la protection des données et la sécurité non pas comme une couche finale, mais comme des piliers architecturaux de chaque projet IA.
Pourquoi ces deux principes sont indissociables dans un projet IA
Le Privacy by Design est né dans les années 1990 sous la plume d'Ann Cavoukian, puis consacré par l'article 25 du RGPD. Il impose que la protection des données soit pensée dès la conception du système, et non ajoutée a posteriori. Le Safety by Design, lui, est explicitement repris par l'AI Act pour les systèmes à haut risque (annexe III) : les mécanismes de sûreté, de supervision humaine et de robustesse doivent être intégrés au cœur du système, pas greffés dessus.
Dans un projet IA, les deux sont liés. Un modèle de scoring RH qui ne minimise pas les données personnelles collectées (Privacy by Design) est aussi un modèle qui amplifie les biais discriminatoires faute de garde-fous architecturaux (Safety by Design). Traiter l'un sans l'autre crée des angles morts réglementaires et opérationnels.
Les 7 principes du Privacy by Design appliqués à l'IA
Voici comment les sept principes fondateurs se traduisent concrètement dans un projet de développement IA interne :
- Proactif, pas réactif : conduire une analyse d'impact (AIPD/DPIA) avant le premier sprint, pas après la mise en production.
- La vie privée comme paramètre par défaut : limiter dès le départ les données d'entraînement au strict nécessaire ; éviter les jeux de données enrichis sans finalité documentée.
- Intégré à la conception : placer les règles de pseudonymisation et de chiffrement dans les pipelines MLOps, pas dans les scripts de déploiement de dernière minute.
- Fonctionnalité complète (pas de compromis) : la performance du modèle ne justifie pas de sacrifier la minimisation des données. Un bon modèle peut être entraîné sur des données synthétiques ou anonymisées.
- Sécurité de bout en bout : journaliser les accès aux datasets, chiffrer les modèles au repos et en transit, gérer les droits d'accès dans le registre des traitements.
- Visibilité et transparence : documenter les finalités, les sources de données et les décisions algorithmiques dans la documentation technique du modèle (model card).
- Respect du cycle de vie de la donnée : prévoir dès la conception la date d'expiration des jeux de données et les procédures de retrait des modèles.
Safety by Design : les exigences concrètes de l'AI Act
Pour les systèmes IA à haut risque au sens de l'AI Act, le Safety by Design se traduit par des obligations techniques précises que l'équipe de développement doit piloter, et non le service juridique seul.
Supervision humaine (Human Oversight)
Le système doit permettre à un opérateur humain d'intervenir, de suspendre ou d'invalider une décision automatique. En pratique : prévoir une interface de supervision dans le backlog dès le sprint 0, avec des règles métier définissant les seuils de confiance en dessous desquels la décision est remontée à un humain.
Robustesse et gestion des erreurs
Un modèle de détection d'anomalies dans une chaîne industrielle doit rester fiable face à des données dégradées ou adversariales. Cela implique des tests de robustesse (fuzzing, données out-of-distribution) intégrés à la CI/CD, pas réalisés une fois avant la mise en production.
Traçabilité et journalisation automatique
L'AI Act impose une journalisation des événements suffisante pour reconstituer le contexte d'une décision contestée. Ce n'est pas une option : les logs doivent inclure la version du modèle, les features utilisées, le score de confiance et l'identité de l'opérateur ayant validé ou infirmé la décision.
Mise en pratique : un cadre opérationnel en 4 étapes
Pour les DPO, RSSI et responsables conformité qui accompagnent des équipes projet, voici un cadre actionnable :
- Étape 1 – Qualification du système IA : dès l'expression de besoin, déterminer si le système relève d'une catégorie à haut risque (AI Act) et si le traitement de données personnelles déclenche une DPIA obligatoire (RGPD, art. 35).
- Étape 2 – Architecture by design : organiser un atelier de 2 heures avec les développeurs pour cartographier les flux de données, identifier les points de minimisation et les exigences de supervision humaine.
- Étape 3 – Intégration dans le SDLC : ajouter des critères d'acceptation conformité dans chaque user story critique (ex. : « Le modèle ne stocke pas les données brutes au-delà de X jours »).
- Étape 4 – Documentation continue : maintenir une model card vivante, mise à jour à chaque nouvelle version du modèle, servant à la fois de documentation technique et de preuve de conformité pour l'auditeur.
Le shadow AI : l'angle mort que Privacy by Design doit couvrir
Un défi croissant pour les organisations : les équipes métier déploient des outils IA sans passer par la DSI ni le service conformité. Un outil de génération de contrats alimenté par des données clients sensibles, utilisé par le service commercial sans validation, constitue à la fois un risque RGPD (transfert de données hors UE potentiel) et un risque AI Act (système non qualifié, non supervisé).
Privacy by Design et Safety by Design ne s'appliquent pas qu'aux projets de développement interne formels. Ils doivent être portés par une politique d'IA gouvernée qui inclut un processus de déclaration et de qualification des usages IA spontanés — y compris les outils SaaS tiers consommés par les métiers.
Ce que les cabinets et les auditeurs vont vérifier
Lors d'un audit de conformité IA, les points de contrôle liés à ces principes sont devenus systématiques :
- Existence d'une DPIA documentée avant la mise en production du système.
- Présence de mécanismes de supervision humaine dans l'architecture technique (et non seulement dans la politique interne).
- Logs de traçabilité horodatés et intégrité garantie.
- Registre des traitements IA à jour, incluant la finalité, la base légale et la durée de conservation des données d'entraînement.
- Model card ou documentation équivalente accessible à l'auditeur.
L'absence de ces éléments ne sera plus interprétée comme un oubli, mais comme une non-conformité caractérisée à l'AI Act et au RGPD.
FAQ
Privacy by Design et Safety by Design sont-ils obligatoires pour tous les projets IA ?
Privacy by Design est obligatoire dès que le projet traite des données personnelles (RGPD, art. 25). Safety by Design s'impose pour les systèmes IA à haut risque au sens de l'AI Act. En pratique, il est recommandé de les appliquer à tous les projets IA pour réduire les risques réglementaires et opérationnels.
À quel moment du projet faut-il conduire une DPIA ?
La DPIA doit être conduite avant le début du traitement, idéalement lors de la phase de cadrage ou au plus tard avant le premier sprint de développement. La mener après la mise en production revient à constater des non-conformités sans pouvoir les corriger sans coût élevé.
Comment gérer le shadow AI dans une approche Privacy by Design ?
Il faut mettre en place un processus de déclaration des usages IA spontanés (outils SaaS, automatisations métier) et les soumettre au même processus de qualification que les projets internes formels. Un registre des outils IA utilisés par les métiers, audité régulièrement, est la base minimale.
Qu'est-ce qu'une model card et est-elle obligatoire ?
Une model card est un document synthétique décrivant la finalité du modèle, les données d'entraînement, les performances, les limites connues et les mécanismes de supervision. Elle n'est pas explicitement nommée dans l'AI Act, mais la documentation technique exigée (annexe IV) couvre les mêmes informations. Elle constitue également une preuve de conformité RGPD.