Checklist RSSI : 30 points pour déployer une IA privée en entreprise

Une checklist RSSI pour le déploiement d'IA privée couvre six domaines de sécurité avant d'autoriser tout système IA : résidence des données et souveraineté, contrôle d'accès et gestion des identités, sécurité de l'inférence et isolation des modèles, piste d'audit et explicabilité, exigences contractuelles fournisseur, et procédures de réponse aux incidents. Appliquer cette checklist systématiquement prévient les défaillances les plus courantes qui créent une exposition réglementaire et sécuritaire dans les déploiements IA en entreprise.

La plupart des déploiements IA en entreprise échouent à la revue de sécurité non pas en raison de vulnérabilités exotiques, mais parce que les disciplines de sécurité fondamentales qui s'appliquent à tous les logiciels d'entreprise ne sont pas appliquées de manière cohérente aux systèmes IA. Les aspects uniques de l'IA créent de nouvelles surfaces d'attaque — exposition des journaux d'inférence, extraction de poids de modèle, injection de prompt — mais les contrôles fondamentaux sont familiers. Cette checklist applique la discipline de sécurité standard aux risques spécifiques à l'IA tout en couvrant les préoccupations IA que les revues de sécurité standard ne traitent pas.

Pourquoi un RSSI a besoin d'une checklist structurée avant tout déploiement IA

Les déploiements IA créent trois catégories de risque de sécurité que les frameworks d'évaluation logicielle traditionnels ne couvrent pas adéquatement.

Exposition des données via l'inférence. Chaque requête soumise à un système IA révèle des informations sur les centres d'intérêt du demandeur, les préoccupations de l'organisation et potentiellement le contenu des documents analysés. Dans les déploiements IA cloud, ces données d'inférence transitent et sont traitées par une infrastructure tierce. L'exposition ne concerne pas seulement les documents dans la base de connaissances — elle inclut le schéma des questions que l'organisation pose, qui peut être aussi sensible que les documents eux-mêmes.

Complexité de la chaîne d'approvisionnement. Les systèmes IA reposent sur des piles de dépendances complexes : modèles fondamentaux, frameworks de récupération, bases de données vectorielles, infrastructure de service de modèles, et middleware d'intégration. Chaque composant représente un point d'exposition de la chaîne d'approvisionnement. Une vulnérabilité dans une bibliothèque de dépendance peut compromettre un système qui semble sécurisé au niveau applicatif.

Ambiguïté de la gouvernance. Les sorties IA sont probabilistes plutôt que déterministes. La même requête peut produire des réponses différentes dans des conditions différentes. Ce comportement crée des défis de gouvernance que les contrôles logiciels traditionnels ne traitent pas : comment auditer un système dont les sorties ne sont pas reproductibles ? Les points de la checklist de la Section 4 adressent spécifiquement ce défi.

Section 1 : Résidence des données et souveraineté

Confirmer les frontières géographiques des données. Identifier où résident tous les composants de données : documents sources, embeddings générés, indices vectoriels, journaux de requêtes, réponses générées et poids de modèle. Chaque composant doit être dans vos frontières géographiques et juridictionnelles définies.
Évaluer l'exposition au CLOUD Act. Si un composant du système IA est opéré par une entité dont le siège social est aux États-Unis, évaluer l'exposition au CLOUD Act. Les données détenues par des sociétés américaines peuvent être contraintes à divulgation par les forces de l'ordre américaines, quel que soit le lieu de stockage. Éliminer cette exposition pour les données sensibles en utilisant une infrastructure opérée par des entités européennes sans dépendance à une société mère américaine.
Vérifier la classification des embeddings stockés. Les embeddings de documents sont dérivés des documents sources et peuvent être aussi sensibles que ces documents. Vérifier que les contrôles d'accès aux bases vectorielles sont équivalents aux contrôles d'accès aux documents sources — une omission courante qui crée un chemin d'exposition secondaire.
Documenter la rétention des journaux d'inférence. Clarifier où les journaux d'inférence sont stockés, ce qu'ils contiennent, combien de temps ils sont conservés et qui peut y accéder. Les journaux d'inférence contenant du contenu de requête sont soumis aux mêmes exigences de résidence des données que les documents sources.
Confirmer la capacité air-gap (si requise). Pour les déploiements servant des données classifiées, couvertes par un secret professionnel ou hautement sensibles, vérifier que le système peut fonctionner en isolation réseau totale. Exiger une documentation du mode de déploiement air-gap, pas seulement l'assurance du fournisseur.

Section 2 : Contrôle d'accès et gestion des identités

Intégrer avec les fournisseurs d'identité d'entreprise. Le système IA doit authentifier les utilisateurs via votre infrastructure d'identité existante (LDAP, Active Directory, SAML, OIDC). Les systèmes de credentials autonomes pour les plateformes IA créent un silo d'identité qui complique la gestion des accès et crée des comptes orphelins lorsque des utilisateurs quittent l'organisation.
Appliquer les permissions au niveau document dans la récupération. Vérifier que les opérations de récupération respectent les mêmes permissions au niveau document que l'accès direct aux documents. Un utilisateur qui ne peut pas accéder à un fichier dans SharePoint ne devrait pas pouvoir y accéder via une requête IA. Cela nécessite des tests actifs avec des utilisateurs à différents niveaux de permission, pas seulement l'attestation du fournisseur.
Tester l'héritage et la révocation des permissions. Les permissions dans les systèmes de gestion documentaire sont souvent héritées et parfois complexes. Vérifier que le système IA gère correctement les permissions héritées et que les révocations se propagent à la récupération sans délai. Un changement de permission doit être reflété immédiatement dans la récupération.
Appliquer les principes zéro confiance aux composants IA. Les composants du système IA (serveurs de modèle, bases de données vectorielles, passerelles API) ne devraient pas avoir de relations de confiance implicites. Appliquer le réseau zéro confiance : authentification explicite pour toutes les communications inter-composants, permissions minimales requises pour chaque composant, et segmentation réseau qui limite les mouvements latéraux.
Imposer l'isolation multi-équipe. Confirmer que le système impose une isolation stricte entre les groupes d'utilisateurs avec différentes portées d'accès aux données. C'est particulièrement critique dans les déploiements multi-clients ou multi-départements. Comme exploré dans le dilemme du cabinet de conseil, la similarité sémantique peut faire fuiter du contexte à travers des frontières logiques que les seuls contrôles d'accès ne peuvent pas sécuriser.

Section 3 : Sécurité de l'inférence et isolation des modèles

Vérifier l'architecture d'inférence locale. Confirmer que l'inférence du modèle se produit dans votre périmètre d'infrastructure sans appels d'API externes pendant le traitement des requêtes. Demander au fournisseur une documentation du trafic réseau montrant les patterns de trafic au moment de l'inférence.
Évaluer le risque d'injection de prompt. Les attaques par injection de prompt tentent de subvertir le comportement IA en intégrant des instructions dans le contenu des requêtes ou des documents. Évaluer les mitigations d'injection de prompt du fournisseur et tester avec des patterns d'attaque représentatifs contre votre déploiement.
Sécuriser le stockage des poids de modèle. Les poids de modèle doivent être stockés avec des contrôles d'accès appropriés. Un accès non restreint aux poids de modèle permet leur extraction et reproduction en dehors de votre infrastructure. Appliquer des contrôles d'accès au stockage équivalents à ceux protégeant vos logiciels les plus sensibles.
Évaluer l'isolation des conteneurs et l'environnement d'exécution. Les charges de travail d'inférence IA fonctionnent souvent dans des conteneurs. Évaluer la sécurité de l'environnement d'exécution des conteneurs : analyse des images, surveillance de l'exécution et contraintes de privilèges. Les conteneurs d'inférence doivent fonctionner avec les privilèges minimaux requis.
Réviser la posture de vulnérabilité des dépendances. Obtenir la nomenclature logicielle (SBOM) du fournisseur et évaluer le statut de vulnérabilité des dépendances. Établir des attentes pour les délais de divulgation et de correction des vulnérabilités.

Section 4 : Piste d'audit et explicabilité

Vérifier la journalisation complète des requêtes. Confirmer que toutes les requêtes soumises au système sont journalisées avec attribution utilisateur, horodatage et contenu de la requête. Les journaux doivent être stockés dans une infrastructure que vous contrôlez et conservés conformément à vos exigences de conformité.
Exiger la citation des sources pour toutes les sorties. Chaque affirmation factuelle dans les réponses générées par IA doit être traçable vers un document source spécifique avec suffisamment de détail pour permettre la vérification. Une citation vers "la politique RH" est insuffisante. Une citation vers "Manuel de l'employé v3.2, Section 4.3, révisé le 15-01-2025" permet la vérification. Comme détaillé dans Glass Box AI, cette discipline de citation est ce qui rend les sorties IA utilisables dans des contextes professionnels et régulés.
Activer le suivi des versions de modèle. Journaliser quelle version de modèle a généré chaque réponse. Lorsque les modèles sont mis à jour, la capacité à reproduire les réponses historiques (avec la même version de modèle) est importante pour l'audit et l'investigation d'incidents.
Évaluer la surveillance de la qualité des sorties. Vérifier que le système inclut une surveillance automatisée de la qualité qui détecte la dégradation de la qualité de récupération ou de génération. La surveillance doit alerter lorsque les indicateurs de qualité tombent en dessous de seuils définis.
Documenter l'alignement EU AI Act. Pour les déploiements qui peuvent tomber sous la classification à haut risque de l'EU AI Act, documenter comment la piste d'audit et les mécanismes d'explicabilité satisfont les exigences de documentation technique et de supervision humaine du règlement — comme couvert dans notre guide de conformité EU AI Act.

Section 5 : Exigences contractuelles fournisseur

Exiger des clauses explicites de non-utilisation des données. L'accord fournisseur doit explicitement interdire l'utilisation de vos données — documents, requêtes, réponses, patterns d'utilisation — pour l'entraînement de modèles, l'amélioration de produits ou tout autre objectif au-delà de la prestation de service. Les engagements vagues de "ne pas partager avec des tiers" sont insuffisants.
Définir les délais de notification de violation. Spécifier les délais de notification de violation requis alignés sur vos obligations réglementaires. Le RGPD exige une notification dans les 72 heures aux autorités de contrôle. Votre contrat fournisseur doit exiger une notification plus rapide à votre équipe de sécurité.
Obtenir des dispositions de droit d'audit. Le contrat doit inclure votre droit d'auditer les pratiques de sécurité du fournisseur, y compris les tests de pénétration par vos auditeurs désignés, l'accès aux rapports d'audit et les droits d'inspection physique pour les composants on-premise ou cloud privé.
Traiter les obligations de la chaîne d'approvisionnement logicielle. Exiger que le fournisseur maintienne une SBOM, divulgue les changements significatifs de dépendances et respecte des délais de correction pour les vulnérabilités critiques. La chaîne d'approvisionnement du fournisseur fait partie de votre chaîne d'approvisionnement lorsque leurs logiciels fonctionnent dans votre périmètre.
Spécifier le traitement des données à la résiliation du contrat. Définir les obligations de retour et suppression des données à la fin du contrat. Spécifier les délais, les mécanismes de vérification (certificats de suppression) et les clauses de survie pour les données conservées dans les systèmes de sauvegarde.

Section 6 : Réponse aux incidents et scénarios de violation

Définir les catégories d'incidents spécifiques à l'IA. Élargir votre classification des incidents pour couvrir les scénarios spécifiques à l'IA : exposition des journaux d'inférence, vol de poids de modèle, attaques par injection de prompt, et manipulation de la récupération qui cause des sorties incorrectes dans des workflows critiques.
Attribuer une propriété claire pour les incidents IA. Lorsque le fournisseur IA est compromis, l'équipe de sécurité ou le fournisseur est-il responsable de diriger la remédiation ? Établir cela à l'avance, avec des chemins d'escalade clairs et des délais de réponse définis pour chaque type d'incident.
Tester les procédures de réponse aux incidents IA. Réaliser des exercices de simulation qui simulent des incidents spécifiques à l'IA : une violation du fournisseur qui expose les journaux d'inférence, une attaque par injection de prompt qui manipule les sorties dans un workflow sensible, et une mise à jour de modèle qui dégrade la qualité des sorties.
Planifier le rollback de modèle. Si une mise à jour de modèle cause une dégradation de la qualité, la capacité à revenir à une version précédente est une exigence de continuité. Vérifier que le fournisseur supporte l'épinglage de version de modèle et que les procédures de rollback sont documentées et testées.
Définir les déclencheurs de signalement réglementaire. Spécifier quels incidents IA déclenchent des obligations de signalement réglementaire au titre du RGPD, NIS2, DORA ou des cadres sectoriels spécifiques. S'assurer que le système de classification des incidents génère les bons chemins d'escalade pour chaque obligation réglementaire.

Signaux d'alerte : quand rejeter un fournisseur IA

Huit comportements fournisseurs qui devraient mettre fin à une évaluation IA :

Résistance aux clauses de droit d'audit. Les fournisseurs qui refusent de permettre les audits de sécurité de leur plateforme ont quelque chose à protéger que votre équipe de sécurité devrait examiner.
Incapacité à décrire le déploiement air-gap. Si un fournisseur ne peut pas fournir des procédures documentées pour le déploiement air-gap, son architecture a des dépendances externes qu'il ne divulgue pas.
Langage vague de traitement des données dans les contrats. "Mesures commercialement raisonnables" et "pratiques standard du secteur" ne sont pas des engagements exécutoires. Exiger des obligations de traitement des données spécifiques et mesurables.
Collecte de télémétrie par défaut. Les plateformes qui collectent des données d'utilisation par défaut avec des mécanismes de désinscription ont des incitations commerciales qui entrent en conflit avec vos exigences de souveraineté des données.
Absence de fourniture de SBOM. Un fournisseur qui ne peut pas fournir de nomenclature logicielle ne peut pas démontrer de connaissance de sa propre surface de risque des dépendances.
Références limitées aux secteurs non régulés. Les fournisseurs d'IA en entreprise sans références dans des secteurs régulés similaires au vôtre peuvent manquer de la conscience de conformité nécessaire pour soutenir votre déploiement.
Performances inexpliquées dans les démonstrations. Les environnements de démo optimisés pour les performances qui ne peuvent pas être reproduits dans votre infrastructure sont trompeurs. Exiger un déploiement POC sur votre infrastructure avant tout engagement.
Historique lent de réponse aux vulnérabilités. Rechercher les noms de fournisseurs dans les bases de données CVE et les avis de sécurité. Un schéma de réponse lente aux vulnérabilités divulguées prédit une mauvaise maintenance de sécurité future.

Questions fréquentes

Quelles questions de sécurité un RSSI doit-il poser à un fournisseur IA ?

Les questions critiques incluent : Où toutes les données sont-elles traitées pendant l'inférence ? Quels appels d'API externes la plateforme effectue-t-elle en fonctionnement ? Pouvez-vous fournir une documentation complète du trafic réseau ? Quel est votre SLA de notification de violation ? Pouvons-nous auditer vos pratiques de sécurité ? Quel est votre délai de divulgation et de correction des vulnérabilités ? Comment les poids de modèle sont-ils protégés dans notre environnement ? Votre contrat interdit-il explicitement l'utilisation de nos données pour l'entraînement de modèles ?

Quelles exigences de résidence des données s'appliquent à l'IA d'entreprise en France ?

Le RGPD exige que les données personnelles transférées hors de l'UE satisfassent des exigences d'adéquation ou utilisent des mécanismes de transfert approuvés. L'EU AI Act ajoute des exigences pour les systèmes à haut risque. DORA exige que les entités financières gèrent les risques liés à la localisation des données pour les systèmes critiques. La certification SecNumCloud en France exige l'absence d'obligations légales extra-européennes. L'effet combiné pour les entreprises régulées est que les systèmes IA traitant des données sensibles doivent traiter toutes les données dans une infrastructure UE opérée par des entités sans dépendances juridiques américaines.

Comment auditer les sorties d'un système IA pour la conformité ?

Un audit efficace des sorties IA nécessite : une journalisation complète de toutes les requêtes et réponses avec attribution utilisateur ; la citation des sources pour chaque affirmation factuelle permettant la vérification par rapport au document original ; un scoring de qualité qui détecte la dégradation de précision au fil du temps ; et une révision humaine par échantillonnage des sorties dans les workflows à enjeux élevés. La piste d'audit doit être sous votre contrôle — les journaux stockés dans l'infrastructure du fournisseur ne sont pas auditables de manière significative.

Quelles protections contractuelles les entreprises doivent-elles exiger des fournisseurs IA ?

Les protections contractuelles essentielles incluent : une clause explicite de non-utilisation des données interdisant l'utilisation pour l'entraînement ou l'amélioration de produits ; une notification de violation dans les 24 heures à votre équipe de sécurité (pas seulement les délais réglementaires) ; une disposition de droit d'audit couvrant les pratiques de sécurité et les logiciels ; des obligations de suppression des données à la résiliation du contrat avec mécanisme de vérification ; et une spécification claire de ce à quoi le fournisseur peut accéder dans votre environnement de déploiement et dans quelles circonstances.

Pour voir comment Scabera est conçu pour passer cette checklist par architecture, et non par contrat, demandez une démonstration.