1. Pourquoi l’IA complique la conformité
Une IA générative (chat interne, assistant support, copilote juridique, outil de rédaction) n’est pas un « logiciel classique ». Elle introduit des risques nouveaux : entrées libres (prompts), sorties non déterministes, dépendance à un fournisseur (cloud), et parfois des fonctions d’agent (accès à des outils, actions automatiques). Pour une organisation suisse, le sujet n’est pas seulement « RGPD », mais aussi la LPD (Suisse), la gestion des transferts internationaux et la preuve que des mesures proportionnées sont en place.
Résumé opérationnel
Pour être conforme, vous devez : (1) classifier les données et interdire les données sensibles dans les prompts non maîtrisés, (2) cadrer contractuellement le fournisseur (DPA, sous-traitants, transferts), (3) limiter l’accès et journaliser, (4) sécuriser l’IA contre les attaques (prompt injection), (5) documenter les décisions (DPIA / analyse d’impact si risque élevé).
Note importante : ce guide n’est pas un avis juridique. Pour les cas à risque (données sensibles, santé, finance, RH, décisions automatisées), validez avec votre juridique/DPO et, si nécessaire, un conseil externe.
2. Cadre LPD (Suisse) + alignement RGPD
Beaucoup d’entreprises suisses sont « bi-réglementées » : elles sont soumises à la LPD, mais aussi au RGPD si elles traitent des données de résidents de l’UE ou opèrent sur le marché UE. L’objectif pratique : construire un socle de conformité unique, avec des variantes selon les périmètres.
2.1. Ce qu’il faut retenir (sans entrer dans le détail juridique)
- Finalité & proportionnalité : pourquoi vous utilisez l’IA et quelles données sont nécessaires.
- Transparence : informer les personnes (clients, employés) selon les cas.
- Sécurité : mesures techniques et organisationnelles proportionnées (accès, logs, chiffrement, surveillance).
- Sous-traitance : contrat, instructions, sous-traitants ultérieurs, rétention, localisation.
- Transferts : si les données sortent de Suisse/EEE, encadrement contractuel + analyse de risque.
2.2. Cas typiques où il faut être très strict
- RH : évaluations, performance, données sensibles (santé, syndicats).
- Support : conversations contenant des données personnelles.
- Juridique : dossiers clients, secret professionnel.
- Finance : informations patrimoniales, identifiants, fraude.
Sur ces cas, privilégiez une approche « zéro fuite » : LLM local/on-prem, ou cloud très encadré et données fortement minimisées.
3. Cartographier vos données & flux
La conformité IA commence par une cartographie simple : quelles données entrent dans le système, où elles vont, qui y accède et combien de temps elles sont conservées. Sans cette cartographie, impossible d’évaluer correctement les risques.
3.1. Classification recommandée (pragmatique)
| Niveau | Exemples | Règle IA |
|---|---|---|
| Public | FAQ, contenu marketing | OK cloud |
| Interne | Procédures, docs internes | Cloud encadré / RAG minimisé |
| Confidentiel | Contrats, clients, incidents | Préférer on-prem ou chiffrement + DPA strict |
| Sensible | Santé, biométrie, sanctions, RH | Interdit cloud par défaut, on-prem + contrôle renforcé |
3.2. Les 5 flux à documenter
- Entrée utilisateur : prompts, fichiers, formulaires.
- RAG : recherche dans votre base documentaire (vector DB).
- Appels LLM : cloud API vs modèle local.
- Outils : CRM, ticketing, ERP (agents qui agissent).
- Logs : observabilité, audit, rétention.
Point d’attention
Les logs deviennent souvent la principale source de fuite. Si vous logguez tout (prompt + documents + réponse), vous créez une « base de données sensible » difficile à sécuriser. Journalisez de manière minimale et contrôlée.
4. Choix fournisseur & transferts internationaux
Le choix d’un fournisseur LLM est un choix de conformité. Il ne suffit pas de comparer la qualité du modèle : il faut analyser la localisation, la rétention, la sous-traitance et la capacité à obtenir des engagements contractuels.
4.1. Questions à poser au fournisseur (checklist)
- Où sont traitées les données (pays, régions cloud) ?
- Rétention des prompts : durée, opt-out, possibilité de désactivation totale ?
- Usage pour l’entraînement : oui/non, comment le prouver ?
- Sous-traitants ultérieurs : liste, notification, droit d’opposition ?
- Chiffrement : en transit / au repos, gestion des clés (BYOK) ?
- Support audit : rapports de sécurité, attestations, procédures incident ?
4.2. Transferts : approche pragmatique
Si des données personnelles quittent la Suisse/EEE, vous devez encadrer et documenter. D’un point de vue opérationnel, retenez :
- Minimiser : ne pas envoyer de données identifiantes si ce n’est pas nécessaire.
- Pseudonymiser : remplacer les identifiants par des tokens si possible.
- Contractualiser : clauses contractuelles, DPA, engagements de non-entraînement.
- Option on-prem : quand la minimisation ne suffit pas.
Pour les stratégies on-prem, voir : Benchmark LLM locaux 2025.
5. Architectures conformes (4 patterns)
La conformité est aussi une affaire d’architecture. Voici 4 patterns fréquemment utilisés en entreprise, avec leurs avantages/limites.
Pattern A — Chat cloud « grand public » (à éviter en entreprise)
Usage direct d’un outil public, sans contrôle centralisé. Risque élevé : pas de gouvernance, pas de minimisation, logs non maîtrisés.
Pattern B — API cloud encadrée (DPA + no-training)
Vous appelez une API via un backend interne. Vous contrôlez l’auth, la journalisation, les filtres et la minimisation. C’est le pattern le plus courant pour démarrer vite.
Pattern C — RAG « données internes » (avec redaction)
Vous stockez vos docs dans une base vectorielle et n’envoyez au modèle que des extraits pertinents, après redaction (suppression des données sensibles). Sur le RAG : Guide RAG 2025.
Pattern D — LLM on-prem (données sensibles)
Le modèle tourne sur votre infra (ou chez un fournisseur souverain). Avantage : données confinées. Limites : capacité GPU, MLOps, monitoring, disponibilité. Voir : Checklist infra LLM local.
6. Sécurité LLM : prompt injection & exfiltration
La sécurité LLM n’est pas une option : même un assistant « interne » peut être attaqué (documents infectés, utilisateurs malveillants, prompt injection indirecte via RAG). Une attaque réussie peut conduire à l’exfiltration de documents, à la divulgation du prompt système, ou à l’exécution d’actions dangereuses (si l’agent a des outils).
Approfondissement : Sécurité LLM : prompt injection, data exfiltration, garde-fous.
6.1. Défense en profondeur (minimum viable)
- Input validation : limites de taille, filtrage, détection de patterns.
- Isolation : séparer instructions système / utilisateur / documents RAG.
- Output filtering : empêcher la fuite d’informations (secrets, PII).
- Moindre privilège : limiter accès aux outils et données.
- Monitoring : alertes sur comportements anormaux.
7. Gouvernance : rôles, politiques, logs
Une IA en production est un produit : elle a des propriétaires, des règles, des versions, des incidents. La conformité s’effondre si « tout le monde peut tout faire ».
7.1. RACI minimal
| Sujet | Responsible | Accountable | Consulted |
|---|---|---|---|
| Données & classification | Data Owner | Direction | DPO/Juridique |
| Sécurité & accès | RSSI/IT | RSSI | DPO |
| Contrats fournisseur | Achats | Direction | Juridique |
7.2. Politique d’usage (à formaliser)
- Ce qui est interdit : données sensibles dans un chat non maîtrisé, secrets, identifiants.
- Ce qui est autorisé : tâches génériques, reformulation, synthèse de documents non sensibles.
- Règles de validation humaine : contenus externes, décisions client, juridique.
- Règles de rétention : logs minimaux, durée, accès restreint.
8. Checklists opérationnelles
8.1. Checklist « Go Live » (LPD/RGPD)
- ☐ Finalité documentée + base légale identifiée
- ☐ Cartographie des flux (entrée → RAG → LLM → logs)
- ☐ Classification des données + règles d’interdiction
- ☐ DPA signé + sous-traitants ultérieurs documentés
- ☐ Paramètres « no training » activés quand disponible
- ☐ Gestion des transferts (analyse + clauses)
- ☐ Contrôles sécurité : auth, RBAC, chiffrement, monitoring
- ☐ Guardrails LLM : anti-injection + output filtering
- ☐ Procédure incident + contact RSSI/DPO
- ☐ Formation des utilisateurs + charte d’usage
8.2. Checklist « prompts » (exemple)
Avant de publier un prompt système ou un template d’équipe :
- Éviter d’ordonner au modèle de révéler des infos internes.
- Ajouter une clause : ne pas inventer et signaler les incertitudes.
- Définir le format attendu (tableau, bullets, JSON) pour contrôler la sortie.
- Inclure un rappel « pas de données sensibles » côté utilisateur.
Sur la standardisation des prompts : Prompting entreprise : standards & templates.
9. Dossier de preuve (audit-ready)
La meilleure conformité est celle que vous pouvez prouver. Préparez un dossier simple, versionné (wiki interne) :
- Décision d’architecture + justification (cloud vs on-prem).
- Cartographie des flux et des données.
- Contrat/DPA + liste des sous-traitants.
- Paramétrage du fournisseur (no training, rétention).
- Politique d’usage et supports de formation.
- Règles d’accès (RBAC) + revue périodique.
- Procédure incident + journal d’incidents (même vide).
- Résultats tests sécurité (prompt injection, exfiltration).
- Évaluations qualité (hallucinations, refus, satisfaction).
- Plan de révision trimestriel (modèle, prompts, docs).
- Si nécessaire : analyse d’impact (DPIA) et mesures.
- Registre des versions (prompt système, modèle, KB).
Pour la méthode DPIA : DPIA & IA générative : méthode simple.
10. Plan de déploiement 30 jours (pratique)
Une approche réaliste pour un premier déploiement conforme :
Semaine 1 : cadrage
- Définir le cas d’usage et les données autorisées.
- Choisir l’architecture (pattern B/C/D).
- Préparer la politique d’usage (draft).
Semaine 2 : implémentation
- Backend proxy + auth + logs minimaux.
- RAG (si applicable) + redaction.
- Guardrails anti-injection.
Semaine 3 : conformité & tests
- Contrats (DPA) + transferts.
- Test sécurité (prompt injection / exfiltration).
- Test qualité (jeu de questions) + critères Go/No-Go.
Semaine 4 : déploiement & adoption
- Pilote avec un groupe restreint.
- Formation (prompts, confidentialité, limites).
- Tableau de bord : coût, qualité, incidents.
Besoin d’un audit conformité IA (LPD/RGPD) ?
Je peux auditer votre cas d’usage, vos flux de données et votre architecture (cloud/on-prem), puis vous livrer un plan de remédiation priorisé et actionnable.
Pour des sujets connexes : RGPD/LPD : déployer une IA générative et Benchmark LLM locaux 2025.