Politique de sécurité de l’IA : Définition, portée et composants essentiels

Une politique de sécurité de l’IA établit les règles pour protéger les systèmes d’IA qu’une organisation construit, achète ou permet à ses employés d’utiliser. Elle explique quels outils sont approuvés, quelles données peuvent y être intégrées, comment les modèles et les pipelines sont protégés, qui détient la supervision et comment les équipes réagissent si un système d’IA fuit des données, est manipulé ou se comporte de manière inattendue.

Qu’est-ce qu’une politique de sécurité de l’IA ?

Au fond, une politique de sécurité de l’IA transforme une gouvernance large de l’IA en pratique de sécurité quotidienne. Les employés savent ce qu’ils peuvent utiliser. Les équipes techniques savent comment les systèmes d’IA doivent être protégés. Les dirigeants obtiennent une norme pour approuver, surveiller et retirer l’IA.

Une politique générale de l’IA fixe la position de l’organisation sur une IA responsable. La politique de sécurité est plus étroite et plus opérationnelle : que pourrait-il mal se passer, qui détient le risque et quels contrôles le réduisent ?

Ce terme est également confondu avec l’IA pour la cybersécurité. Ici, le sujet n’est pas d’utiliser l’IA pour détecter des menaces. Il s’agit de sécuriser l’IA elle-même : protéger les modèles, les données, les invites, les sorties, les intégrations et les utilisateurs contre les abus, les compromissions, les fuites, les manipulations et les défaillances.

En termes quotidiens, la politique répond à quatre questions :

• Quels outils et systèmes d’IA sont autorisés ?
• Quelles données peuvent être utilisées avec eux ?
• Qui peut les approuver, y accéder, les surveiller et les modifier ?
• Que se passe-t-il lorsqu’un système d’IA se comporte de manière inattendue ou est attaqué ?

Politique de sécurité de l’IA vs. Politique d’IA

La politique de sécurité de l’IA est plus étroite qu’une politique d’IA générale. La politique générale peut couvrir l’éthique, la transparence, l’équité, l’approvisionnement, la conformité et l’utilisation responsable. La politique de sécurité se concentre sur les menaces, les contrôles, la propriété, la surveillance et la réponse aux incidents.

Dimension	Politique de sécurité de l’IA	Politique d’IA générale	Politique de cybersécurité
Concentration principale	Protéger les systèmes d’IA, les données, les modèles et les pipelines contre les menaces et les défaillances.	Gérer l’utilisation de l’IA en matière d’éthique, de conformité, d’opérations, d’équité, de transparence et de risque.	Sécuriser l’environnement informatique plus large : réseaux, points de terminaison, applications, identités et données.
Champ d’application	Cycle de vie des modèles, données d’entraînement, inférence, outils d’IA, fournisseurs d’IA et chemins d’attaque spécifiques à l’IA.	Le programme complet d’IA de l’organisation et son impact sur les personnes, les opérations et la conformité.	L’ensemble de l’infrastructure technologique, que l’IA soit impliquée ou non.
Propriétaire typique	CISO, équipe de sécurité, responsable de la gouvernance de l’IA ou groupe de sécurité/gouvernance partagé.	Directeur de l’IA, équipes juridiques, de conformité, de risque et de gouvernance exécutive.	CISO et organisation de la sécurité de l’information.

Politique de sécurité de l’IA vs. Politique de cybersécurité

Une politique de cybersécurité standard laisse généralement des lacunes. Elle peut bien couvrir les systèmes, les réseaux, les points de terminaison et les identités, mais l’IA introduit des risques que ces contrôles n’ont pas été conçus pour gérer.

Ces risques incluent des données d’entraînement empoisonnées, injection de prompt, inversion de modèle, entrées adversariales, vol de modèle et fuite d’informations sensibles à travers des prompts ou des sorties. Une politique de sécu AI étend le programme de cybersécurité au cycle de vie du modèle et aux manières spécifiques dont les systèmes d’IA peuvent être attaqués ou mal utilisés.

Pourquoi les politiques de sécurité de l’IA représentent un écart critique

Le principal problème n’est pas que les organisations doutent de la valeur de la politique de sécurité de l’IA. C’est que l’adoption de l’IA a dépassé la gouvernance de l’IA.

Aucune enquête unique ne raconte toute l’histoire, mais le schéma est cohérent : de nombreuses organisations expérimentent déjà ou déploient l’IA, tandis que les règles de sécurité spécifiques à l’IA restent inégales. IBM a rapporté qu’une minorité d’organisations dispose de politiques de sécurité de l’IA formelles. Cisco a constaté que de nombreuses organisations expérimentant avec l’IA générative manquent encore de politiques de sécurité spécifiques. Le Forum économique mondial a également averti que de nombreux conseils n’ont pas encore discuté formellement des risques de sécurité spécifiques à l’IA.

Cet écart est important car les incidents liés à l’IA ne sont plus hypothétiques. Les incidents de confidentialité, les vulnérabilités des modèles, les fuites de données, les abus et les échecs éthiques font désormais partie de l’environnement opérationnel. Une politique donne aux équipes un moyen partagé de décider ce qui est autorisé, ce qui nécessite une révision, ce qui doit être enregistré et comment réagir lorsque quelque chose ne va pas.

Que couvre une politique de sécurité de l’IA ?

Une politique de sécurité de l’IA utile est plus qu’une simple déclaration d’intention d’une page. Elle couvre les endroits où le risque lié à l’IA apparaît réellement : utilisateurs, données, modèles, infrastructure, fournisseurs, surveillance et réponse aux incidents.

Règles d’utilisation acceptable et IA fantôme

Commencez par les outils et les cas d’utilisation. Une bonne politique précise quels outils d’IA sont approuvés, quels usages sont permis et quels usages sont interdits. La rédaction de documents, l’assistance à la programmation ou la recherche interne peuvent être autorisées sous certaines conditions ; le profilage discriminatoire, la génération de contenu trompeur ou l’entrée de données réglementées dans des outils publics peuvent être restreints ou interdits.

C’est également ici que se situe l’IA cachée. L’IA cachée se produit lorsque des employés utilisent des outils d’IA non approuvés en dehors de la visibilité de l’organisation. C’est risqué car cela contourne les procédures d’approvisionnement, de journalisation, de contrôle d’accès, les règles de gestion des données et l’examen de la sécurité. Une section claire sur l’utilisation acceptable offre aux employés un chemin plus sûr que l’improvisation.

Classification et protection des données

Cette section délimite les données. Les données confidentielles, réglementées, clients, employés et propriétaires nécessitent généralement des règles plus strictes que les informations publiques ou à faible risque.

Par exemple, la politique pourrait interdire aux employés d’entrer des données confidentielles dans des outils d’IA générative externes, à moins que l’outil ait été approuvé, que le contrat autorise cette utilisation et que les données soient protégées par des contrôles appropriés. La même section devrait couvrir les données d’entraînement, les invites, les résultats, les journaux, les ensembles de données de réglage fin et les historiques de conversation conservés.

Contrôle d’accès et identité

L’accès à l’IA doit s’inscrire dans la gestion normale des identités et des accès. La politique définit qui peut accéder aux modèles, aux API, aux ensembles de données, aux invites, aux résultats, aux consoles administratives et aux pipelines de déploiement.

Pour les systèmes à risque plus élevé, cela peut signifier des autorisations basées sur les rôles, des flux de travail d’approbation, des contrôles d’accès privilégiés, une surveillance et des examens d’accès périodiques. L’objectif est simple : les personnes doivent avoir l’accès dont elles ont besoin, et pas plus.

Lifecycle Security

La sécurité doit suivre le cycle de vie de l’IA, de la conception à la retraite. Cela inclut la collecte de données, la sélection de modèles, l’entraînement ou le réglage fin, les tests, le déploiement, la surveillance, la gestion des changements et le déclassement.

Avant qu’un modèle ne soit déployé, les équipes peuvent avoir besoin de modélisation des menaces, d’examen de la sécurité, de tests de l’équipe rouge, de validation des données d’entraînement et d’approbation des propriétaires de risques. Après le déploiement, la politique doit surveiller les dérives, les abus, les fuites, les résultats inhabituels et les changements dans l’exposition aux menaces. Lorsqu’un modèle est retiré, l’organisation doit établir des règles pour supprimer l’accès, préserver les dossiers requis et assainir les données lorsque cela est approprié.

Couverture des menaces spécifiques à l’IA

C’est ici que la politique devient véritablement spécifique à l’IA. Elle identifie les risques que l’organisation essaie de gérer et les relie aux contrôles.

Les menaces courantes incluent le poisoning de données, le vol de modèles, les exemples adversariaux, l’injection de prompts, l’inversion de modèles, la fuite de données d’entraînement et l’exfiltration de données par le biais de prompts ou de sorties. La politique ne doit pas se transformer en manuel technique, mais elle doit être suffisamment claire pour que les équipes de sécurité, les équipes de données et les propriétaires d’entreprise sachent quels risques ils sont responsables.

Risques liés aux tiers et à la chaîne d’approvisionnement

La plupart des organisations utilisent des IA qu’elles n’ont pas construites elles-mêmes. Les API LLM publiques, les copilotes SaaS, les fonctionnalités d’IA intégrées, les modèles open-source, les modèles pré-entraînés et les systèmes gérés par des fournisseurs introduisent tous un risque tiers.

Les règles des fournisseurs couvrent la manière dont les fournisseurs d’IA sont évalués, quelles données peuvent leur être partagées, quelles journaux sont requis, si les données des clients sont utilisées pour l’entraînement, comment les sorties sont examinées et quelles protections contractuelles doivent être en place avant utilisation.

Surveillance humaine en tant que contrôle de sécurité

La surveillance humaine est souvent considérée comme une exigence éthique, mais c’est aussi un contrôle de sécurité. Une personne examinant la sortie de l’IA peut détecter des réponses manipulées, des instructions suspectes, des faits hallucinés, des recommandations dangereuses ou des réponses trop confiantes d’un système compromis ou mal configuré.

La politique doit préciser quand une révision humaine est requise, qui est qualifié pour l’effectuer et quelles décisions soutenues par l’IA ne peuvent pas être automatisées sans approbation.

Réponse et gestion des incidents

Les incidents liés à l’IA doivent être nommés dans le plan de réponse aux incidents. Les exemples incluent l’abus de modèle, l’injection de prompts, la fuite de données, l’accès non autorisé au modèle, la compromission de l’intégrité, des sorties nuisibles ou un service d’IA tiers se comportant de manière inattendue.

Les règles de journalisation sont importantes ici. Selon le système, l’organisation peut avoir besoin de conserver des enregistrements de prompts, de sorties, d’actions administratives, de modifications de modèles, d’accès aux données, d’utilisation d’API et d’alertes de sécurité. Sans surveillance, les équipes peuvent ne pas savoir qu’un système d’IA est mal utilisé jusqu’à ce que les dommages soient causés.

Normes pertinentes et cadres réglementaires

La politique de sécurité de l’IA ne doit pas être rédigée de manière isolée. Il appartient aux normes et réglementations qui façonnent déjà la gouvernance de l’IA, la sécurité et la gestion des risques. Le mélange exact dépend de l’industrie, de la géographie et du profil de risque de l’organisation.

Cadre	Pourquoi cela importe pour une politique de sécurité de l’IA
ISO/IEC 42001	Fournit une approche de système de gestion pour gouverner l’IA, y compris des contrôles, la responsabilité et l’amélioration continue.
NIST AI RMF	Offre aux organisations une structure de gestion des risques pour l’IA, y compris la fiabilité, la robustesse, la sécurité et la gouvernance.
MITRE ATLAS	Cartographie des tactiques et techniques adversariales contre les systèmes d’IA et d’apprentissage automatique.
Loi sur l’IA de l’UE	Introduit des obligations basées sur les risques pour les systèmes d’IA, y compris des attentes en matière de sécurité et de robustesse pour les utilisations à haut risque.
Convention sur l’IA du Conseil de l’Europe	Met l’accent sur les garanties tout au long du cycle de vie de l’IA, y compris la sécurité, la responsabilité et les contrôles des risques.
ISO/IEC 27001	Ancre les systèmes d’IA dans une gestion de la sécurité de l’information plus large en tant qu’actifs d’information et systèmes d’entreprise.

Idées reçues sur la politique de sécurité de l’IA

Idée reçue 1 : C’est juste une politique de cybersécurité à laquelle on a ajouté l’IA dans le titre.

Réalité : Une politique de cybersécurité est toujours nécessaire, mais l’IA ajoute des risques tels que l’injection de prompt, le poisoning de données, le vol de modèle, l’inversion de modèle et la fuite de données d’entraînement. Ces risques nécessitent des propriétaires désignés, des chemins de révision et des contrôles.

Idée reçue 2: La sécurité de l’IA signifie utiliser l’IA pour effectuer des travaux de sécurité.

Réalité : Dans ce contexte, la sécurité de l’IA signifie sécuriser les systèmes d’IA eux-mêmes. La politique peut également couvrir des outils de sécurité alimentés par l’IA, mais ce n’est pas son objectif principal.

Idée reçue 3 : Une fois la politique rédigée, le travail est terminé.

Réalité : Les systèmes d’IA, les réglementations et les méthodes d’attaque évoluent rapidement. La politique nécessite des révisions programmées, ainsi que des mises à jour déclenchées par des événements lorsque de nouveaux outils, incidents, lois ou risques apparaissent.

Idée reçue 4: La politique ne s’applique qu’aux modèles que l’organisation construit en interne.

Réalité : Les outils d’IA tiers créent souvent le plus grand écart de visibilité. Les chatbots publics, les fonctionnalités d’IA SaaS, les copilotes, les API externes et les modèles open-source relèvent tous du champ d’application de la politique.

Idée reçue 5: C’est un document purement technique.

Réalité : Les contrôles techniques sont importants, mais les personnes et les processus le sont tout autant. La formation, les approbations, la responsabilité, l’examen des fournisseurs, la supervision humaine et le reporting des incidents doivent tous figurer dans la politique.

Foire aux questions

Quelle est la différence entre une politique de sécurité de l’IA et une politique de sécurité de l’IA générative ?

Une politique de sécurité de l’IA générative est une version plus étroite d’une politique de sécurité de l’IA. Elle se concentre sur des systèmes tels que les grands modèles de langage, les générateurs d’images, les copilotes et les chatbots. Ses zones de risque incluent souvent l’injection de commandes, les données sensibles dans les commandes, les résultats hallucinés, le contenu toxique ou dangereux, l’exposition à la propriété intellectuelle et la fuite de données à travers les réponses générées.

Qu’est-ce que l’IA fantôme et pourquoi une politique l’aborde-t-elle ?

L’IA fantôme est l’utilisation d’outils d’IA sans approbation ou supervision organisationnelle. Un exemple courant est un employé qui colle des informations confidentielles dans un chatbot public. Une politique aborde l’IA fantôme en nommant les outils approuvés, en établissant des règles de gestion des données et en fournissant aux employés un processus clair pour une utilisation sûre de l’IA.

Qui possède et applique une politique de sécurité de l’IA ?

La propriété revient souvent au CISO, à la direction de la sécurité ou à un responsable de la gouvernance de l’IA. L’application nécessite généralement plusieurs groupes : sécurité, juridique, conformité, données, informatique, approvisionnement et propriétaires d’entreprise. La politique rend ces rôles explicites afin que la responsabilité ne se perde pas entre les équipes.

Une politique de sécurité de l’IA couvre-t-elle des outils comme ChatGPT, Copilot et les fonctionnalités d’IA SaaS ?

Oui. Les outils d’IA tiers sont inclus dans le champ d’application car ils peuvent exposer des données, créer des résultats non examinés ou déplacer des décisions en dehors des systèmes approuvés. Une bonne politique précise qui peut les utiliser, quelles données peuvent être partagées, comment l’utilisation est enregistrée et quels outils nécessitent un examen supplémentaire.

À quelle fréquence une politique de sécurité de l’IA doit-elle être révisée ?

Il n’existe pas d’intervalle universel, mais une révision annuelle seule n’est généralement pas suffisante. De nombreuses organisations combinent une révision annuelle ou semi-annuelle programmée avec des mises à jour déclenchées par de nouveaux outils d’IA, de nouvelles réglementations, des incidents de sécurité, des changements majeurs de fournisseurs ou des méthodes d’attaque émergentes.

Quelles réglementations exigent une politique de sécurité de l’IA ?

Une loi peut ne pas exiger un document avec ce titre exact, mais plusieurs cadres créent des obligations que la politique de sécurité de l’IA aide à satisfaire. ISO/IEC 42001, le NIST AI RMF, la loi sur l’IA de l’UE, la convention sur l’IA du Conseil de l’Europe et ISO/IEC 27001 influencent tous la manière dont les organisations gouvernent, sécurisent et surveillent les systèmes d’IA. Les exigences varient selon la juridiction, le secteur et le cas d’utilisation.

Conclusion

Une politique de sécurité de l’IA fournit à une organisation des règles pratiques pour protéger l’IA tout au long de son cycle de vie : approbation des outils, gestion des données, sécurisation des modèles, gouvernance de l’IA tierce, maintien de l’humain dans la boucle et réponse en cas de problème.

Ce n’est pas un remplacement pour une politique générale sur l’IA ou une politique de cybersécurité. Elle se situe entre elles, traduisant les risques spécifiques à l’IA en règles que les équipes de sécurité, les équipes de gouvernance et les propriétaires d’entreprise peuvent réellement utiliser. À mesure que l’IA se propage au sein de l’organisation, cette clarté devient moins un atout en matière de gouvernance et plus une exigence opérationnelle de base.