Sommaire : Gouvernance de la confidentialité IA
- Le RSSI au cœur de la tempête IA
- Cartographier les flux de données IA : l'étape n°1
- Comment adapter votre PSSI aux enjeux de l'IA générative
- Auditer ses fournisseurs d'IA : les questions qui fâchent
- Le On-Premise comme socle de la confiance numérique
- Cas pratique : Politique de 'Privacy by Design' pour un Callbot
- Questions Fréquentes
Le RSSI au cœur de la tempête IA
En 2026, l'intelligence artificielle est devenue le défi majeur des directions de la sécurité des systèmes d'information (RSSI) et des directions informatiques (DSI). D'un côté, les directions métier poussent pour un déploiement massif afin de gagner en productivité. De l'autre, les risques de fuite de données, d'espionnage industriel et de non-conformité réglementaire atteignent des sommets. Ce guide a pour vocation d'aider les responsables SI à construire une stratégie d'IA qui concilie innovation et protection absolue des actifs de l'entreprise.
Cartographier les flux de données IA : l'étape n°1
On ne peut protéger ce que l'on ne voit pas. La première mission du RSSI est de réaliser une cartographie exhaustive de tous les flux de données alimentant les systèmes d'IA de l'entreprise. Quels documents sont envoyés au RAG ? Quels flux audio transitent vers l'agent vocal ? Où sont stockés les vecteurs d'embedding ? En 2026, la réponse à ces questions détermine votre niveau d'exposition au risque cyber.
Comment adapter votre PSSI aux enjeux de l'IA générative
Votre Politique de Sécurité des Systèmes d'Information (PSSI) doit évoluer. Elle doit désormais intégrer des clauses sur :
- La classification des données IA : Définir quelles données peuvent être traitées par des IA cloud et lesquelles sont strictement réservées au on-premise.
- Le contrôle des accès : Gestion des clés d'API et authentification multi-facteurs pour tous les portails d'IA.
- La purge des données : Politiques de rétention strictes pour les logs de conversation et les fichiers temporaires de traitement vocal.
Auditer ses fournisseurs d'IA : les questions qui fâchent
Si vous utilisez des briques cloud, vous devez poser des questions précises à vos prestataires :
- Utilisez-vous mes données pour ré-entraîner vos modèles ?
- Où se situent physiquement les serveurs de traitement (STT/LLM/TTS) ?
- Êtes-vous soumis à des lois extraterritoriales (Cloud Act) ?
- Quelle est votre procédure en cas de compromission de votre infrastructure ?
Le On-Premise comme socle de la confiance numérique
Pour un RSSI, la solution la plus sereine reste le déploiement on-premise. En reprenant le contrôle de l'infrastructure, vous appliquez vos propres standards de sécurité physique et logique. L'IA devient une brique logicielle comme une autre dans votre SI, auditable, maîtrisée et étanche vis-à-vis de l'extérieur. C'est le choix de la raison pour les entreprises manipulant des données critiques ou stratégiques.
Questions Fréquentes pour RSSI & DSI
Quelle est la responsabilité du RSSI face à l'IA générative ?
Le RSSI doit garantir que l'usage de l'IA respecte la PSSI de l'entreprise, évaluer les risques de fuite de données et mettre en place les contrôles techniques nécessaires.
Le chiffrement suffit-il à protéger les données envoyées à une IA cloud ?
Non. Les données sont déchiffrées pour être traitées par le fournisseur cloud. Seul le on-premise garantit que les données restent au sein de votre périmètre de confiance.
Faut-il privilégier les solutions IA open-source ?
L'open-source permet l'auditabilité des modèles, ce qui est un avantage majeur en termes de sécurité et de transparence.
Cartographie complète des risques IA pour le RSSI
Matrice de risques IA par catégorie de données
Le RSSI doit établir une classification des données qui transitent par les systèmes d'IA. Chaque catégorie présente un niveau de risque différent et exige des mesures de protection proportionnées :
| Catégorie de données | Exemples | Niveau de risque | Mesure on-premise |
|---|---|---|---|
| Données publiques | FAQ, horaires, informations générales | Faible | Recommandé |
| Données internes | Procédures, organigramme, tarifs | Modéré | Fortement recommandé |
| Données clients | Noms, coordonnées, historique | Élevé (RGPD) | Obligatoire |
| Données sensibles | Santé, finance, juridique | Critique (RGPD art. 9) | Impératif + HDS si santé |
| Données vocales | Enregistrements, empreintes vocales | Critique (biométrie) | Impératif + consentement |
Les vecteurs de fuite spécifiques aux systèmes d'IA
Au-delà des vecteurs de fuite classiques (exfiltration réseau, compromission de poste), les systèmes d'IA introduisent des vecteurs spécifiques que le RSSI doit connaître :
- Fuite par les prompts : Un utilisateur copie-colle un document confidentiel dans un chatbot IA cloud. Les données sont instantanément transmises au fournisseur et potentiellement utilisées pour entraîner le modèle.
- Fuite par les réponses : Un LLM mal configuré peut divulguer des informations provenant de sa base de connaissances RAG à un utilisateur non autorisé.
- Fuite par les logs : Les journaux d'interaction avec le LLM contiennent l'intégralité des requêtes et des réponses. S'ils ne sont pas protégés, ils constituent une mine d'or pour un attaquant.
- Fuite par le modèle lui-même : Un modèle fine-tuné sur vos données peut, sous certaines conditions, régurgiter des fragments de ses données d'entraînement (attaque de mémorisation).
Adapter votre PSSI aux spécificités de l'IA
Les 8 clauses à ajouter à votre Politique de Sécurité des Systèmes d'Information
Votre PSSI existante doit être enrichie de clauses spécifiques à l'IA. Voici les huit clauses que nous recommandons :
- Classification des systèmes IA : Chaque système d'IA doit être inventorié, classifié par niveau de risque (AI Act) et rattaché à un responsable fonctionnel.
- Politique de données d'entraînement : Définir quelles données peuvent être utilisées pour le fine-tuning, avec quelle anonymisation, et selon quel processus de validation.
- Contrôle d'accès au LLM : Qui peut interroger le LLM ? Avec quelles données ? Les accès doivent être nominatifs et journalisés.
- Politique de rétention des logs IA : Les interactions avec le LLM doivent être conservées pour audit pendant une durée définie, puis supprimées de manière sécurisée.
- Gestion des incidents IA : Procédure spécifique en cas de comportement anormal du LLM (hallucination dangereuse, fuite de données, prompt injection réussie).
- Évaluation des fournisseurs IA : Grille d'évaluation obligatoire avant tout recours à un service d'IA externe (localisation des données, juridiction, certifications).
- Interdiction de la Shadow IA : Les collaborateurs ne doivent pas utiliser de services d'IA non approuvés par la DSI. Sanctions prévues en cas de violation.
- Plan de réversibilité : Procédure de migration ou d'arrêt du système IA sans perte de données ni interruption de service.
Intégrer la sécurité IA dans votre processus d'homologation
Tout nouveau système d'IA (ou toute modification significative d'un système existant) doit passer par un processus d'homologation de sécurité avant sa mise en production. Ce processus inclut : une analyse de risques spécifique (EBIOS RM adaptée à l'IA), un test d'intrusion ciblé (prompt injection, extraction de données), une validation de la conformité RGPD (AIPD si nécessaire) et une revue par le comité d'éthique IA de l'entreprise.
Auditer vos fournisseurs d'IA : les 10 questions essentielles
Avant de confier vos données à un fournisseur d'IA, posez-lui ces dix questions et exigez des réponses documentées :
- Où sont physiquement hébergés vos serveurs d'inférence ? Dans quel pays et chez quel hébergeur ?
- Êtes-vous soumis au Cloud Act américain, au FISA ou à toute autre loi extraterritoriale ?
- Les données de mes requêtes sont-elles utilisées pour entraîner ou améliorer vos modèles ?
- Quelle est votre politique de rétention des requêtes et des réponses ?
- Pouvez-vous me fournir un rapport SOC 2 Type II ou une certification ISO 27001 ?
- En cas de fuite de données, quel est votre processus de notification et de remédiation ?
- Garantissez-vous contractuellement que mes données ne seront pas transférées hors de l'Union Européenne ?
- Quel est votre plan de continuité d'activité en cas de panne majeure ?
- Quelles sont vos mesures de protection contre le prompt injection et l'extraction de données ?
- Pouvez-vous me fournir un DPA (Data Processing Agreement) conforme au RGPD ?
Le on-premise comme socle de confiance numérique
Architecture de référence pour un déploiement sécurisé
L'architecture de référence que nous déployons chez AIO Orchestration répond aux exigences des RSSI les plus exigeants :
Les avantages concrets pour le RSSI
- Zéro transfert de données : Aucune donnée ne quitte le périmètre physique de l'entreprise. Le RSSI n'a pas à gérer de DPA, de clauses contractuelles standard ou d'analyses d'impact liées à un transfert vers un sous-traitant.
- Auditabilité complète : Le RSSI a accès à l'intégralité des logs, des configurations et du code source. Il peut auditer le système à tout moment, sans dépendre du bon vouloir d'un fournisseur.
- Maîtrise des mises à jour : Les mises à jour du modèle sont contrôlées par le RSSI. Pas de changement de comportement surprise lié à une mise à jour automatique du modèle par un fournisseur cloud.
- Isolation réseau : Le serveur d'inférence n'a aucun accès à internet, éliminant les risques d'exfiltration par le réseau et les attaques exploitant des vulnérabilités réseau.
Les 5 erreurs des RSSI face à l'IA
Erreur 1 : Appliquer les mêmes règles que pour le SaaS classique
L'IA n'est pas un SaaS comme les autres. Les données envoyées à un LLM cloud sont potentiellement mémorisées par le modèle et pourraient être restituées à d'autres utilisateurs. Les règles de sécurité applicables au SaaS classique (chiffrement en transit, DPA) sont nécessaires mais insuffisantes.
Erreur 2 : Interdire l'IA au lieu de la gouverner
Bloquer l'accès à ChatGPT et consorts sans proposer d'alternative crédible pousse les collaborateurs vers la Shadow IA (utilisation de leur smartphone personnel, par exemple). Offrez une alternative on-premise sécurisée et les utilisateurs l'adopteront naturellement.
Erreur 3 : Déléguer la sécurité IA à l'éditeur
La sécurité de votre système IA est votre responsabilité, pas celle de votre fournisseur. Le fournisseur doit vous donner les outils (chiffrement, journalisation, contrôle d'accès), mais c'est à vous de les configurer et de les superviser correctement.
Erreur 4 : Ne pas tester le prompt injection
Le prompt injection est l'équivalent de l'injection SQL pour les LLM. Si vous ne testez pas la résistance de votre système IA à cette attaque, vous ne connaissez pas votre niveau réel de sécurité. Intégrez des tests de prompt injection dans vos campagnes de pentest régulières.
Erreur 5 : Ignorer la sécurité des données RAG
La base de connaissances utilisée pour le RAG contient souvent des documents internes sensibles (procédures, contrats, données clients). Elle doit être protégée avec le même niveau de sécurité que votre GED (gestion électronique de documents) : contrôle d'accès, chiffrement au repos, journalisation des accès.
FAQ approfondie pour RSSI et DSI
L'IA on-premise est-elle compatible avec une certification ISO 27001 ?
Oui, et elle la facilite même. L'ISO 27001 exige la maîtrise des actifs informationnels, le contrôle des accès, la journalisation et la gestion des incidents. Un système IA on-premise, correctement déployé, répond nativement à ces exigences. Nous fournissons à nos clients une documentation de sécurité compatible ISO 27001 pour faciliter leur processus de certification.
Comment gérer le droit d'accès RGPD pour les données traitées par l'IA ?
En on-premise, vous maîtrisez l'intégralité des logs d'interaction. Lorsqu'une personne exerce son droit d'accès (article 15 RGPD), vous pouvez extraire toutes les interactions la concernant à partir de votre base de journalisation. Avec un service cloud, vous dépendez du fournisseur pour obtenir ces informations, sans garantie de complétude.
Faut-il réaliser une AIPD (Analyse d'Impact sur la Protection des Données) pour un agent vocal IA ?
Oui, dans la plupart des cas. L'AIPD est obligatoire lorsque le traitement est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes. Un agent vocal IA qui traite des données vocales (biométriques) et des données personnelles entre clairement dans cette catégorie. L'AIPD doit être réalisée avant le déploiement et mise à jour régulièrement.
Comment empêcher les collaborateurs d'utiliser des LLM cloud non autorisés ?
Une approche en trois volets : technique (blocage DNS des domaines des principaux LLM cloud, analyse du trafic HTTPS par un proxy filtrant), organisationnelle (politique d'utilisation claire, sanctions en cas de violation) et culturelle (mise à disposition d'une alternative on-premise attractive et performante). Le blocage seul ne suffit jamais.
Quel budget prévoir pour sécuriser correctement un déploiement IA on-premise ?
Le budget sécurité spécifique à l'IA représente généralement 15 à 20% du budget total du projet. Pour un projet d'agent vocal on-premise à 25 000 EUR, comptez 3 750 à 5 000 EUR pour la sécurisation (audit initial, configuration du pare-feu applicatif, mise en place du SIEM, test de prompt injection, formation des équipes IT). Ce coût est largement inférieur au risque financier d'un incident de sécurité non maîtrisé.
Conclusion : De la peur de l'IA à la maîtrise de l'IA
La mission des RSSI et DSI en 2026 n'est pas de dire non à l'IA, mais de dire comment la faire en toute sécurité. En passant d'une posture de réaction face à la Shadow IA à une posture proactive de déploiement d'architectures souveraines, vous devenez le moteur d'une innovation responsable. La confidentialité n'est pas un obstacle, c'est l'armure qui permettra à votre entreprise de gagner la guerre économique de demain.