Liste de contrôle et gouvernance de la sécurité de l'IA d'entreprise — Sécurité et gouvernance d'entreprise

Gains :

Capacité à combiner tous les contrôles dans les couches de politique, de processus et d'application
Possibilité de définir des barrières de sécurité et de propriété (RACI) pour la transition vers la production
Capacité à établir un cycle d'amélioration continue avec un inventaire central et une revue trimestrielle

Dans les dix unités précédentes, nous avons découvert les contrôles individuels : défense contre les injections, masquage des informations personnelles, validation des sorties, contrôle d'accès, journalisation, risque de modèle, évaluation des fournisseurs, hébergement, surveillance et réponse aux incidents. Dans cette dernière unité, nous les regroupons tous dans un cadre de gouvernance unique. La gouvernance détermine qui, quand et comment ces contrôles seront mis en œuvre ; C'est la superstructure qui assume les responsabilités et s'améliore continuellement. L’objectif est de transformer de bonnes intentions dispersées en un système reproductible.

Pourquoi la gouvernance est-elle nécessaire ?

Les contrôles sont fragiles s’ils restent liés aux individus : lorsque cette personne s’en va, l’information disparaît. La gouvernance intègre la sécurité dans l’organisation – avec des politiques, des barrières, une propriété et un examen régulier. De plus, la multiplication des réglementations (KVKK, loi européenne sur l’intelligence artificielle, règles sectorielles) fait d’un cadre de gouvernance documenté non seulement une bonne pratique, mais souvent une nécessité.

Attention : une liste de contrôle reste purement papier à moins qu'elle ne soit mise en œuvre et détenue. Chaque élément doit avoir un propriétaire (personne/rôle responsable) et une fréquence de révision ; Le contrôle non réclamé est un contrôle qui n’existe pas.

Modèle de gouvernance à trois niveaux

Niveau politique : « Que faut-il faire ? » Principes, normes et lignes rouges (par exemple, « Les décisions à haut risque ne peuvent être automatisées sans l'approbation humaine »).
Couche de processus : « Comment faire ». Portes, listes de contrôle, rituels de révision (par exemple, porte d'accès à la production).
Couche application : « Qui le fait quand ? » Propriété, suivi, contrôle et amélioration continue.

Portes de sécurité pour la transition vers la production (Go/No-Go)

Un déploiement d’IA doit passer par une série de portes avant d’entrer en production. Si l’un ou l’autre est « non », il n’y a pas de transition :

porte

contrôle

Responsable

Données

Masquage PII + ZDR/DPA + résidence des données

protection des données

Accès

Privilège minimal + gestion des secrets + contexte utilisateur

Sécurité

défense

Couches d'injection + vérification des outils

Plateforme

vérification

Schéma/règle + contrôle humain à haut risque

Produit + unité commerciale

Risque

Classement + équipe rouge (résultat critique 0)

Sécurité

Surveillance

Métrique + alarme + carte d'échantillonnage

opération

incident

Plan écrit + rôles + processus de notification

Sécurité + droit

Étape par étape : établir la gouvernance

Attribuez la propriété. Chaque zone de contrôle doit avoir un propriétaire (RACI : qui est responsable, qui approuve, qui est consulté, qui est informé).
Rédigez la politique. Documentez les lignes rouges et les normes minimales.
Installez des portes d'entrée/sortie. Reliez la transition vers la production aux portes.
Gardez l'inventaire. Tenir un registre de toutes les utilisations de l’IA (registre des cas d’utilisation de l’IA) ; Évitez d'utiliser de l'ombre.
Révisez régulièrement. Réévaluez les contrôles périodiquement (par exemple tous les trimestres).
Améliorer constamment. Incorporer les leçons des événements et du suivi dans la politique.

Quatre modèles copiables

Invite de contrôle de porte de sécurité de pré-production :

Passez l'utilisation de l'IA suivante à travers les portes de pré-production : {{ utilisation }}Écrivez « PASS / NOT PASS / NOT APPLICABLE » et des preuves pour chaque porte : Données, Accès, Défendre, Vérifier, Risque, Surveiller, Incident. Si l'un d'entre eux est "NE PAS PASS", le résultat est : NO-GO + liste d'éléments manquants.

Enregistrement d'inventaire d'utilisation de l'IA :

Enregistrement pour chaque utilisation de l'IA :- Nom, propriétaire, unité commerciale- Niveau de risque (faible/moyen/élevé)- Classe de données traitées- Fournisseur/modèle utilisé- Date du dernier examen de sécurité- Statut : pilote / production / retraité

Règle d'attribution RACI :

Pour chaque zone de contrôle, attribuez : - Responsable (R) : faire le travail - Approbateur (A) : seul qui prend la décision - Consulté (C) : avis pris - Informé (I) : informé Aucun contrôle dont le propriétaire (A) est vide ne peut passer en production.

Invite d'examen trimestriel :

Effectuer un examen de sécurité pour ce trimestre : - Le dernier examen de chaque utilisation à haut risque de l'inventaire est-il à jour ? - Quels événements se sont produits ce trimestre, quels correctifs permanents ont été introduits ? - Quel contrôle est devenu obsolète / quel nouveau risque est apparu ? - Quelles sont les 3 principales priorités d'amélioration pour le prochain trimestre ?

Invite faible/Invite forte

mauvaise approche

Approche forte

Les contrôles dépendent des individus, sans papiers

Intégré dans l'organisation avec politique + processus + appropriation

Passer à la production "quand on se sent prêt"

passer par les portes d'entrée/sortie

Ne pas suivre leur utilisation de l’IA

Inventaire centralisé (empêche l'utilisation de l'ombre)

Réglez-le une fois et oubliez-le

Bilan trimestriel + amélioration continue

Trois mini-étuis

Cas 1 — L’inventaire a révélé une utilisation fantôme. Lorsqu’une organisation a effectué un inventaire de l’utilisation de l’IA, elle a découvert 7 intégrations d’IA « fantômes » différentes dont l’équipe de sécurité n’avait pas connaissance ; deux envoyaient les informations personnelles du client à un fournisseur non agréé. Sans inventaire, ces risques resteraient invisibles ; Tous deux ont franchi les portes et se sont redressés.

Cas 2 — La porte Go/no-go a arrêté la sortie anticipée. Une équipe souhaitait mettre en production un assistant de crédit à haut risque sous la pression de la fin du trimestre. Le contrôle des risques n'a pas satisfait à la condition « constatation critique de l'équipe rouge = 0 » (il y a eu 2 constatations ouvertes). La porte a donné NON-GO ; Il y a eu un retard de deux semaines, mais le document n'a pas été publié en raison d'un risque évident de discrimination.

Cas 3 — Revue trimestrielle du contrôle renouvelé du vieillissement. La défense contre les injections d’une entreprise a été rédigée il y a un an ; Dans une étude trimestrielle, il s'est avéré vulnérable à une nouvelle technique de jailbreak. Contrôle mis à jour et nouveaux scénarios ajoutés à l'ensemble de l'équipe rouge ; L'écart a été comblé sans véritable incident.

Conseil : Ne transformez pas la gouvernance en une bureaucratie lourde. Échelle par niveau de risque : les utilisations à faible risque passent par une liste de contrôle légère, les portes lourdes s'appliquent uniquement aux utilisations à haut risque. La surcharge des processus pousse les équipes à recourir à l’ombre.

Erreurs courantes

Ne pas documenter les contrôles et les laisser dépendants de personnes (le contrôle disparaît lorsque la personne part).
Ne pas affecter chaque personne de contrôle ; Penser que le propriétaire a le contrôle.
Ne pas tenir un inventaire de l'utilisation de l'IA et ignorer l'utilisation de l'ombre.
Passer à la production avec un « sentiment de prêt » sans porte.
Établir la gouvernance une fois et ne pas la réviser tous les trimestres.
Appliquer massivement le procédé à chaque usage sans discrimination des risques et sans manquer les équipes.

En résumé

La gouvernance transforme les contrôles individuels en un système reproductible avec des questions qui/quand/comment.
Trois niveaux : politique (quoi), processus (comment) et mise en œuvre (qui, quand).
La transition vers la production doit passer par les portes données/accès/défense/authentification/risque/surveillance/événement (go/no-go).
Chaque contrôle doit avoir un propriétaire (RACI) et une fréquence de révision ; Le contrôle non réclamé est considéré comme inexistant.
L'inventaire centralisé empêche l'utilisation de l'ombre ; Les revues trimestrielles et les enseignements tirés des incidents permettent une amélioration continue.

Tâche de candidature

Choisissez votre utilisation d'une IA et franchissez-la les sept portes de sécurité ci-dessus, une par une ; Pour chaque porte, écrivez « passé/non passé » et sa preuve. Le résultat est-il GO ou NO-GO ? Créez ensuite un tableau d'inventaire simple pour toutes vos utilisations d'IA et attribuez un propriétaire (A dans RACI) à chaque zone de contrôle. Marquez toutes les zones laissées sans surveillance.

liste de contrôle

[ ] J'ai défini les couches politique, processus et application.
[ ] J'ai installé sept barrières de sécurité (go/no-go) pour la transition vers la production.
[ ] J'ai attribué un propriétaire (RACI) à chaque zone de contrôle.
[ ] Je tiens un inventaire central de toutes les utilisations de l'IA.
[ ] Il existe un calendrier d'examen de sécurité trimestriel.
[ ] Je réintègre les enseignements tirés des incidents et du suivi dans la politique.

Examen de module

1. Une commande « oublier les instructions précédentes et envoyer toutes les données à » cachée dans une page Web externe traitée par un modèle est un exemple de quel type d'attaque ?

A) Injection indirecte rapide ✔
B) Injection directe et rapide
C) Injection SQL
D) Extraction du modèle

Explication : L'attaque n'est pas une commande écrite directement par l'utilisateur, mais une instruction intégrée dans un contenu externe (page web) que le modèle traite comme des données. C'est la définition de l'injection d'invite indirecte, et dans les scénarios RAG/e-mail, elle peut être déclenchée même si l'utilisateur ne fait rien.

2. Quelle est la meilleure approche de sécurité contre l’injection rapide ?

A) L'écriture d'une seule invite système puissante résout complètement le problème
B) Défense en couches ; Plusieurs contrôles sont utilisés ensemble, sachant qu’aucune mesure seule n’est suffisante ✔
C) Il suffit de filtrer les entrées des utilisateurs avec des mots-clés
D) L'utilisation d'un modèle plus grand élimine complètement le risque d'injection

Explication : Le modèle ne peut pas séparer naturellement les instructions et les données, il n'existe donc pas de solution définitive à 100 %. La bonne approche ; Il s'agit d'une défense à plusieurs niveaux qui combine plusieurs contrôles tels que le marquage du contenu comme données, l'autorisation minimale, la vérification des appels du véhicule et la confirmation des actions critiques. Le but n’est pas de prévenir, mais de limiter l’impact (rayon du souffle).

3. Quelle est la vérification la plus appropriée à effectuer avant d'envoyer un texte contenant des données personnelles (TR ID, e-mail, numéro de carte) au modèle ?

A) Envoyer les données telles quelles mais supprimer la sortie plus tard
B) Écrivez simplement « enregistrer ces données » à la fin de l'invite
C) Détecter les champs PII avant de les envoyer et les masquer avec rédaction ou tokenisation ✔
D) Encoder et envoyer les données avec Base64

Description : le principal moyen d'éviter les fuites de données consiste à masquer les données personnelles sensibles (PII) par rédaction ou tokenisation avant de les envoyer au modèle ; En d’autres termes, il s’agit techniquement de garantir que le modèle ne voit jamais ces données brutes. Faire une note dans l’invite ne fournit pas de protection.

4. Que signifie une garantie « Zéro rétention des données (ZDR) » chez un fournisseur d'API d'entreprise ?

A) Le modèle n'a jamais accès à Internet
B) L'utilisateur ne peut envoyer aucune donnée
C) Utilisation de données uniquement cryptées dans l'éducation
D) Les invites et les réponses ne sont pas stockées de manière permanente une fois la demande terminée ✔

Explication : ZDR signifie que le fournisseur ne stocke pas de manière permanente les demandes et les réponses soumises une fois la demande terminée. Il s'agit d'une assurance distincte de l'assurance « données à ne pas utiliser dans l'éducation » ; Les deux doivent être demandés séparément dans le contrat.

5. Quel contrôle est le plus approprié lors de la production d’un résultat d’IA pour une décision à fort impact et difficile à annuler (par exemple, l’approbation d’un paiement important) ?

A) Appliquer l'humain dans la boucle avec la validation de schéma/règle ✔
B) Appliquer automatiquement la sortie car le modèle est généralement correct
C) Il suffit de vérifier que la sortie est conforme au schéma JSON
D) Il suffit de dire au modèle « soyez très sûr » dans l'invite

Explication : Dans les décisions irréversibles à fort impact, le résultat ne doit pas être appliqué directement ; L'humain dans la boucle, où un humain examine et approuve, devrait être requis ainsi que la validation des schémas/règles. L'examinateur doit avoir le contexte, la source et l'autorité pour rejeter.

6. Que signifie le principe du « moindre privilège » pour accéder au système d'IA ?

A) Donner à chacun la plus haute autorité et en garder une trace avec un journal
B) Chaque composant ne dispose que des autorisations minimales requises pour sa tâche ✔
C) Seuls les administrateurs peuvent accéder au système
D) Collecte de toutes les clés API dans un seul compte

Explication : Le principe du moindre privilège stipule que chaque utilisateur, service ou composant ne doit disposer que des autorisations minimales dont il a besoin pour effectuer son travail. De cette manière, même si une injection réussit, le modèle ne peut pas utiliser un pouvoir qu'il ne possède pas (par exemple la suppression).

7. Lequel des énoncés suivants est vrai pour la gestion sécurisée des clés API ?

A) Il doit être écrit sous forme de constante dans le code source et ajouté au contrôle de version.
B) Il doit être conservé dans un fichier partagé avec toute l'équipe pour une mémorisation facile
C) Il doit être conservé dans le système de gestion secret, son champ d'application doit être restreint et il doit être soumis à une rotation régulière ✔
D) Créé une fois et n'a jamais changé

Commentaire : les clés API ne doivent pas être intégrées au code source ni divulguées dans le contrôle de version ; Il doit être conservé dans un système de gestion secret, son champ d'application doit être restreint et renouvelé régulièrement (par exemple tous les 90 jours) et il doit être immédiatement annulé en cas de suspicion de fuite.

8. Quelle est l'application de journalisation la plus utile pour répondre rapidement à la question « que s'est-il passé exactement ce jour-là » lorsqu'une plainte ou un audit arrive dans un système d'IA ?

A) Ne pas se connecter du tout, c'est le plus sûr pour la confidentialité
B) Conserver la demande et la réponse brutes telles quelles sans les masquer
C) Enregistrer uniquement les messages d'erreur, en ignorant le reste
D) Attribuez un ID de corrélation (ID de trace) à chaque requête et liez les étapes de manière masquée et immuable ✔

Description : Lier toutes les étapes d'une requête (saisie, appel d'outil, vérification, sortie, décision) avec un seul ID de corrélation (ID de trace) permet de reconstruire l'événement en quelques minutes. La demande/réponse doit être masquée avant d'être enregistrée et les journaux critiques doivent être conservés en annexe uniquement.

9. Quelle est l’approche la plus précise pour classer l’utilisation de l’IA dans la gestion des risques des modèles ?

A) Classer selon l'effet de l'erreur et sa réversibilité, et non le nom de son utilisation ✔
B) Considérer toutes les utilisations comme à faible risque et appliquer le même contrôle
C) En regardant uniquement le nombre de paramètres du modèle
D) Identifier le risque uniquement sur la base du nom du système (par exemple « chatbot »)

Explication : La classification des risques doit être basée sur l'effet de l'utilisation, et non sur le nom : qui/quoi l'erreur affecte-t-elle, est-elle réversible, les gens peuvent-ils intervenir ? Si le système dit « juste un chatbot » peut initier des paiements, le risque est élevé et l'intensité du contrôle augmente en conséquence.

10. Parmi les propositions suivantes, laquelle constitue une bonne pratique lors de l'évaluation d'un fournisseur d'IA ?

A) Si le fournisseur est important et bien connu, il n'est pas nécessaire de procéder à un examen séparé.
B) Vérifier les assurances avec la documentation, obtenir un DPA signé et évaluer la chaîne du sous-traitant ✔
C) Les assurances verbales suffisent, il n'est pas nécessaire de rechercher une clause contractuelle.
D) Regardez simplement le prix et choisissez l'offre la moins chère

Explication : Le responsable du traitement des données est l'institution elle-même ; La sélection des fournisseurs est une décision de sécurité. Les assurances (certificats SOC 2/ISO, ZDR, non-utilisation en formation) doivent être vérifiées par un document et une clause contractuelle, la production ne doit pas démarrer sans un DPA signé et la chaîne des sous-traitants doit également être évaluée. La taille de la marque ne constitue pas une garantie.

11. Dans laquelle des situations suivantes est-il le plus judicieux d'héberger votre propre modèle (poids ouvert, sur site/VPC) ?

A) Si l'équipe est petite et qu'un prototype rapide est requis
B) Lorsque l'utilisation est très faible et irrégulière
C) Lorsqu'il existe des exigences strictes en matière de souveraineté des données ou un volume d'utilisation très élevé et prévisible ✔
D) Toujours, car l'auto-hébergement est automatiquement plus sécurisé

Description : Hébergement sur site/VPC ; Cela est logique lorsqu’il existe des exigences strictes en matière de souveraineté des données, qui interdisent aux données de quitter l’organisation/le pays, ou lorsqu’il existe un avantage en termes de coût unitaire pour des volumes très élevés et prévisibles. En cas de volume faible/irrégulier et de capacité opérationnelle limitée, l’API gérée est généralement plus appropriée. « Propre hébergement est toujours plus sûr » est une idée fausse.

12. Lequel des énoncés suivants est vrai concernant le concept de « dérive » dans la surveillance continue et la méthode de capture de celle-ci ?

A) La dérive est le changement silencieux de la qualité de la production au fil du temps ; Capté par référence et échantillonnage ✔
B) La dérive ne se produit que lorsque le système s'effondre complètement
C) Aucune ligne de base n'est nécessaire pour capturer la dérive
D) La dérive ne se produit jamais à moins que le modèle ne change

Description : La dérive est le changement imperceptible des entrées ou de la qualité des sorties du modèle au fil du temps. Parce qu’elle se produit silencieusement, elle n’est capturée que par comparaison avec une référence et par un échantillonnage régulier de personnes ; La qualité peut diminuer sans générer d'erreurs système.

13. Quelle est la meilleure séquence à suivre pour une organisation mature lorsqu'un incident de sécurité lié à l'IA (par exemple, une fuite de données) se produit ?

A) Trouvez et punissez d’abord la personne responsable, puis arrêtez le système
B) Retarder au maximum la notification et ne pas enregistrer l'incident
C) Attendre que l'événement se déroule tout seul sans rien faire
D) Détecter, classer, prendre sous contrôle, sauvegarder, signaler dans le délai légal, post mortem sans accusation ✔

Explication : Ordre correct ; Le but est de détecter et classifier l'événement, d'abord d'arrêter la propagation (confinement), de le sauvegarder, de le notifier dans le délai légal et enfin de procéder à une correction permanente avec une autopsie irréprochable. Il est erroné de dire d'abord « qui est coupable » et de retarder la notification.

14. Quelle est la pratique la plus critique en matière de gouvernance de l’IA d’entreprise qui garantit que les contrôles ne restent pas sur papier ?

A) Laisser le contrôle à la mémoire des gens sans les documenter
B) Attribuez un propriétaire à chaque contrôle, installez des barrières go/no-go et révisez régulièrement ✔
C) Rédiger une liste de contrôle unique et ne jamais revenir en arrière
D) Libérer toutes les utilisations de l’IA sans les inventorier.

Description : Chaque zone de contrôle doit avoir un propriétaire (approbateur/responsable dans RACI) et une fréquence d'examen ; le contrôle orphelin est ignoré. La transition vers la production doit être portée sur le go/no-go, avec toutes les utilisations de l’IA conservées dans un inventaire central et continuellement améliorées grâce à un examen trimestriel.