Sécuriser l’utilisation de l’IA : les 10 mesures de sécurité de l’IA du Centre pour la cybersécurité

La plupart des organisations utilisent désormais l’IA quelque part : un chatbot sur le site web, un copilote dans la suite bureautique, un agent connecté au CRM. Le Centre canadien pour la cybersécurité a publié un court guide sur la manière de sécuriser ces usages, Les 10 mesures de sécurité de l’IA : introduction (ITSAP.10.049, mai 2026) (Cyber Centre). Il s’adresse aux organisations de toutes tailles et de tous secteurs, et complète les 10 principales mesures de sécurité TI existantes du Centre (ITSM.10.089) plutôt que de les remplacer.

Trois risques, trois piliers

Le Centre regroupe ses mesures selon l’origine du risque : des attaquants qui utilisent l’IA contre vous, des attaques visant vos propres systèmes d’IA, et la manière dont votre personnel et vos processus utilisent l’IA. Les conséquences qu’il énumère sont bien connues : vol de données, atteinte à la réputation, et pertes opérationnelles et financières.

Pilier 1 : se protéger contre l’utilisation malveillante de l’IA

1. Atténuer l’injection de prompts et le jailbreaking. Assainir les entrées, restreindre les agents et outils à haut risque, et valider ce qu’un système d’IA s’apprête à faire avant exécution.
2. Contrer les deepfakes et l’usurpation d’identité. Vérifier les identités et les médias, utiliser une authentification multifacteur résistante au phishing, et confirmer les demandes inhabituelles via un canal distinct.
3. Renforcer les défenses contre la fraude et les attaques générées par l’IA. Appliquer les correctifs plus rapidement, ajouter la détection de bots et la limitation de débit, et former le personnel aux menaces activées par l’IA.

Pilier 2 : protéger vos systèmes d’IA

4. Tester les systèmes d’IA et mener des exercices de red team. Évaluer régulièrement les modèles, les pipelines et les interfaces, et planifier pour eux la réponse aux incidents et la continuité.
5. Se protéger contre l’empoisonnement des données. Suivre la provenance des données, versionner les jeux de données, filtrer les données ingérées et contrôler l’accès tout au long de la chaîne de données.
6. Contrôler l’utilisation des données et prévenir le vol de modèles. Par défaut, ne pas entraîner sur vos données, journaliser l’accès aux modèles et aux données, et surveiller les API pour détecter des schémas d’extraction.
7. Sécuriser la chaîne d’approvisionnement de l’IA. Tenir une nomenclature des composants d’IA, signer les modèles et les artefacts, appliquer des pratiques de développement sécurisé et examiner les dépendances.

Pilier 3 : protéger les utilisateurs et les opérations

8. Appliquer des contrôles fournisseurs, contractuels et de confidentialité. Minimiser les renseignements personnels dans les prompts, chiffrer les données, publier une liste d’outils approuvés et non approuvés, traiter l’« IA fantôme » et intégrer les bonnes clauses dans les achats.
9. Garder l’humain aux commandes. Maintenir des contrôles humains dans les flux de travail automatisés, rendre les décisions explicables et auditables, et prévoir des procédures d’arrêt et d’escalade.
10. Rester résilient face à la dérive, aux hallucinations, aux biais et à la surdépendance. Surveiller les performances, réentraîner ou retirer les modèles, exiger une revue humaine des résultats critiques et maintenir des procédures de repli.

Ce que cela signifie pour les programmes de conformité

Aucune de ces mesures n’est un nouveau type de contrôle. Elles étendent des contrôles que la plupart des programmes possèdent déjà à une nouvelle catégorie de systèmes :

• Loi 25 (Québec) : la mesure 8 est d’abord une mesure de protection de la vie privée. Les renseignements personnels collés dans un outil d’IA externe constituent une communication à un fournisseur de services et peuvent être un transfert hors Québec. Les décisions fondées exclusivement sur un traitement automatisé entraînent aussi une obligation d’informer la personne concernée (article 12.1 de la loi sur le secteur privé).
• PCI DSS : les données de titulaires de carte n’ont pas leur place dans les prompts ni dans les jeux d’entraînement. Si un outil d’IA peut voir des données de compte, il entre dans le périmètre de votre environnement de données de titulaires de carte, tout comme son fournisseur.
• SOC 2 et ISO 27001 : les fournisseurs d’IA doivent être intégrés à votre processus de gestion des risques fournisseurs, et les systèmes d’IA à votre inventaire des actifs, à la gestion des changements et à la journalisation.
• ISO/IEC 42001 : le Centre renvoie au NIST AI Risk Management Framework et à l’ISO/IEC 42001:2023 pour les organisations qui souhaitent un système complet de management de l’IA.

Par où commencer

1. Dresser l’inventaire des outils d’IA utilisés, y compris ceux que personne n’a approuvés.
2. Publier une règle d’utilisation acceptable : quels outils, quelles données, qui décide.
3. Examiner les contrats des fournisseurs d’IA concernant l’utilisation des données, l’entraînement, la conservation et les droits d’audit.
4. Ajouter les systèmes et agents d’IA à votre prochain test d’intrusion et à votre évaluation des risques.

Besoin d’aide pour cartographier ces mesures à votre programme PCI DSS, SOC 2 ou Loi 25 ? Parlez à notre équipe.