Données sensibles et IA : architectures de cloisonnement
Utiliser un modèle d'IA sur des données sensibles n'oblige ni à tout interdire ni à tout confier à un service externe. Cinq architectures, du plus simple au plus strict, et les critères pour choisir.
La question revient dans tous les comités : peut-on utiliser l’intelligence artificielle sur nos données sensibles ? Dossiers de santé, données de ressources humaines, contrats, informations clients, secrets industriels. Les réponses extrêmes (« non, jamais » ou « oui, tout va dans le service externe ») sont rarement les bonnes. Entre les deux existe une gamme d’architectures. Ce guide les présente du plus simple au plus strict, pour choisir un niveau de cloisonnement des données sensibles adapté à chaque usage.
Avant de choisir : classer
Le choix d’une architecture dépend de trois questions qu’on doit trancher en amont.
- Quelle sensibilité ? Données publiques, internes, personnelles, de santé, couvertes par le secret professionnel, classifiées : chaque niveau appelle des règles différentes.
- Quel cadre juridique ? RGPD, droit sectoriel (santé, finance), obligations de localisation, secret des affaires. L’AI Act européen ajoute des exigences selon le niveau de risque du système.
- Quel usage ? Résumer un document, répondre à des questions sur une base interne, assister un conseiller, entraîner un modèle : le risque n’est pas le même.
Option 1 : pseudonymiser avant l’envoi
Les données identifiantes (noms, numéros, adresses) sont remplacées par des marqueurs avant l’envoi au modèle, puis réinjectées dans la réponse. Le modèle externe travaille sur un texte dépourvu d’identifiants directs.
- Simple à mettre en œuvre
- Réduit l’exposition des identités
- Compatible avec un service externe
- Ne protège pas le contenu lui-même (un contexte peut permettre de réidentifier)
- Les données pseudonymisées restent des données personnelles
- La détection automatique des identifiants n’est jamais parfaite
Option 2 : un service externe contractualisé
On utilise un service d’IA hébergé par un fournisseur, dans un cadre contractuel strict : contrat de sous-traitance conforme à l’article 28 du RGPD, garantie de non-réutilisation des données pour l’entraînement, localisation dans l’Union européenne, conservation limitée ou nulle, journalisation. Notre guide sur les clauses de sécurité d’un contrat informatique détaille ces points.
Cette option convient à des données internes ou personnelles non critiques, à condition de vérifier les engagements du fournisseur et de les faire figurer au contrat. Elle ne convient généralement pas aux données couvertes par un secret strict.
Option 3 : un hébergement dédié
Le fournisseur déploie une instance du modèle réservée à l’organisation, souvent chez un hébergeur européen ou dans un environnement de nuage isolé. Les données ne se mélangent pas à celles d’autres clients et ne servent pas à l’entraînement. Le contrôle sur la localisation, les clés de chiffrement et les accès est plus fin. Le coût est plus élevé, et l’organisation reste dépendante de l’exploitation du fournisseur.
Option 4 : un déploiement interne
L’organisation fait tourner un modèle ouvert sur sa propre infrastructure ou sur un nuage qu’elle maîtrise. Aucune donnée ne sort. C’est l’option la plus protectrice sur le plan de la transmission, et la plus exigeante : il faut des compétences, du matériel adapté, une chaîne de mise à jour, une supervision, et accepter que les modèles disponibles soient parfois moins performants que les plus grands services du marché.
Option 5 : un traitement hybride
Les tâches sont réparties selon la sensibilité : les données les plus critiques sont traitées par un modèle interne ou dédié, les autres par un service externe. Un composant d’aiguillage décide selon des règles claires (classification du document, profil de l’utilisateur, nature de la demande). Cette architecture offre un bon équilibre, au prix d’une plus grande complexité de gestion.
| Option | Données adaptées | Effort | Point d’attention |
|---|---|---|---|
| 1. Pseudonymisation | Personnelles, peu sensibles | Faible | Réidentification par le contexte |
| 2. Service contractualisé | Internes, personnelles courantes | Faible à moyen | Qualité des engagements du fournisseur |
| 3. Hébergement dédié | Sensibles | Moyen à élevé | Dépendance à l’exploitation tierce |
| 4. Déploiement interne | Très sensibles, secrets | Élevé | Compétences et maintenance |
| 5. Hybride | Mixtes | Élevé | Fiabilité de l’aiguillage |
Quelle que soit l’option : cinq principes communs
- Contrôle d’accès hérité. Dans un système de recherche augmentée, le modèle ne doit retrouver que les documents que l’utilisateur est autorisé à lire. Les droits sont appliqués à la recherche, non après coup.
- Séparation des environnements. Les données d’essai et celles de production ne se mélangent pas ; les invites (prompts) et les réponses ne sont pas stockées au-delà du nécessaire.
- Journalisation. Qui a posé quelle question, sur quelles sources, avec quelle réponse : indispensable pour l’audit et pour comprendre un incident.
- Tests d’exfiltration. Vérifier qu’une invite habile ne fait pas sortir des informations qu’elle ne devrait pas obtenir. Les risques propres aux applications fondées sur des modèles de langage sont recensés par l’OWASP dans son classement des dix principaux risques.
- Gouvernance d’usage. Une règle claire pour les employés : ce qu’on peut saisir, dans quel outil, et ce qui est interdit.
Ce n’est souvent pas une attaque sophistiquée, mais un employé qui colle un document sensible dans un service grand public faute d’outil autorisé. Fournir un outil sûr et facile est la meilleure mesure de prévention.
Comment trancher
Partez des usages à plus forte valeur, classez les données qu’ils manipulent, et associez à chaque classe l’architecture minimale qui la protège. Le plus souvent, une organisation finit avec deux ou trois niveaux plutôt qu’un seul. Notre travail sur l’automatisation des processus et la page IA d’entreprise décrivent comment nous cadrons ces choix, et le diagnostic permet d’établir la classification de vos données.
Questions fréquentes
Peut-on envoyer des données personnelles à un service d'IA externe ?
Oui sous conditions : base légale, contrat de sous-traitance conforme à l'article 28 du RGPD, garanties sur la localisation et sur l'absence de réutilisation des données pour l'entraînement, analyse d'impact si le risque est élevé. Pour des données très sensibles, une architecture plus fermée est souvent préférable.
La pseudonymisation suffit-elle ?
Elle réduit le risque mais ne l'élimine pas : des données pseudonymisées restent des données personnelles au sens du RGPD, et une réidentification est parfois possible par recoupement. Elle se combine avec d'autres mesures.
Qu'est-ce qu'une recherche augmentée (RAG) et pourquoi pose-t-elle un problème d'accès ?
Le modèle répond à partir de documents retrouvés dans une base. Si la base ne respecte pas les droits d'accès par utilisateur, un employé peut obtenir par le modèle une information qu'il ne pourrait pas lire directement.
Un modèle hébergé en interne est-il toujours plus sûr ?
Pas automatiquement. Il supprime certains risques (transmission à un tiers) mais exige de maîtriser la sécurité, les mises à jour et les compétences. Un mauvais déploiement interne peut être moins protégé qu'un service bien contractualisé.