La sécurité de l'IA et la gouvernance de l'IA ne sont pas un seul et même problème.

La plupart des organisations s'attaquent au mauvais problème. Voici comment les distinguer et pourquoi c'est important avant votre prochain déploiement d'IA.

Pourquoi la sécurité de l'IA et la gouvernance de l'IA ne sont pas le même problème

La plupart des organisations informatiques traitent la sécurité et la gouvernance de l'IA comme un seul et même projet. Ces deux sujets sont abordés lors des mêmes réunions, confiés à la même équipe et traités selon les mêmes cadres de référence. Or, il s'agit de deux problématiques distinctes. La sécurité de l'IA empêche les menaces d'y accéder. La gouvernance de l'IA, quant à elle, contrôle le fonctionnement interne de vos IA.

Ignorer cette différence a un coût. On peut réussir un audit de sécurité et échouer à un audit réglementaire. On peut déclarer zéro violation de données et pourtant être totalement inexistant en matière de gouvernance. Les deux peuvent être vrais le même jour.

Les enjeux s'intensifient à mesure que les agents d'IA passent de la simple réponse aux questions à l'exécution de tâches dans les systèmes de production. Votre équipe de sécurité peut protéger un agent contre les attaques, mais elle n'a toujours aucun moyen de prouver ce qui lui a été autorisé à faire. Cet article explique comment distinguer ces deux problèmes, qui doit en être responsable et quelles questions poser aux fournisseurs avant votre prochain déploiement.

Qu’est-ce que la sécurité IA ?

La sécurité de l'IA protège votre système d'IA, ainsi que les données qu'il utilise, contre les menaces externes. Elle répond à une question essentielle: une personne peut-elle s'introduire dans le système, le manipuler ou y dérober des données ?

Il couvre trois domaines:

• Le modèle . Il protège le modèle contre les entrées adverses, les injections de signaux et les manipulations qui le poussent vers une sortie nuisible.
• Les données. Cela empêche la divulgation ou l'exfiltration non autorisée des enregistrements sensibles auxquels l'IA peut accéder.
• L'infrastructure. Elle renforce la sécurité des systèmes de calcul, du réseau et des intégrations sur lesquels l'IA s'exécute afin que les attaquants ne puissent pas les compromettre.

La sécurité basée sur l'IA renforce votre dispositif de sécurité existant. Vous conservez vos équipes et vos méthodes de travail, mais vous ajoutez une nouvelle surface d'attaque. Une organisation de sécurité mature est parfaitement préparée à relever ce défi. C'est une bonne nouvelle, mais c'est aussi là que la confusion commence.
 

Qu’est-ce que la gouvernance de l’IA, et en quoi est-elle différente ?

La gouvernance de l'IA contrôle le comportement de votre IA lorsqu'elle fonctionne conformément à sa conception, en l'absence d'attaque. Elle répond à une autre question: quelles sont les autorisations accordées à notre IA et pouvons-nous le prouver ?

La gouvernance repose sur trois composantes:

• Autorisation. Elle définit ce que l'IA peut faire, dans quelles conditions et dans quelle mesure.
• Responsabilité. Cela permet d'établir qui a approuvé chaque action et si un document relie l'action à cette personne.
• Auditabilité. Cela détermine si vous pouvez démontrer à un organisme de réglementation ce que l'IA a fait, quand et pourquoi, sans avoir à reconstituer les événements à partir de journaux épars.

La sécurité se demande: « Quelqu'un peut-il s'introduire dans le système ? » La gouvernance se demande: « Qu'est-ce que mon IA est autorisée à faire, et où sont les preuves ? »

Un agent parfaitement sécurisé peut toujours relancer une tâche par erreur, lire des données inutiles ou agir sans autorisation. Rien de tout cela n'est considéré comme un incident de sécurité. Tout est mis en évidence lors d'un audit.
 

Pourquoi la sécurité de l'IA et la gouvernance de l'IA nécessitent-elles des équipes et des cadres différents ?

Ces référentiels nécessitent des responsables différents car ils évaluent des aspects différents. Les référentiels de sécurité tels que SOC 2, ISO 27001 et le référentiel de cybersécurité du NIST se concentrent sur les menaces externes et la protection des systèmes et des données. Ils sont essentiels, mais n'abordent pas les questions de gouvernance.

Les cadres de gouvernance sont centrés sur l'interne. Le cadre de gestion des risques liés à l'IA du NIST, la loi européenne sur l'IA, les recommandations de l'OCC en matière de gestion des risques et la loi européenne sur la résilience opérationnelle numérique (DORA) convergent tous vers les mêmes exigences: une autorisation claire, une supervision humaine et des décisions traçables. Ces cadres n'évaluent pas votre périmètre.

Si vous confiez la gouvernance à l'équipe de sécurité et lui demandez d'utiliser des cadres de sécurité, vous obtiendrez exactement ce que ces cadres produisent: un audit de sécurité. Vous n'obtiendrez pas d'architecture de gouvernance.

Le meilleur modèle prévoit un partage de la propriété:

• La sécurité est responsable du périmètre. Elle protège le modèle, les données et l'infrastructure.
• La conformité, la gestion des risques et les opérations informatiques partagent la même gouvernance. Ces équipes savent quelles actions comportent des risques commerciaux et réglementaires.

Chaque partie organise ses propres réunions, définit ses propres critères de réussite et pose ses propres questions aux fournisseurs. Pour les équipes mainframe, la présence des opérations informatiques à la table de gouvernance est primordiale. Le personnel d'exploitation sait quels traitements par lots ne peuvent pas redémarrer à 8 h et quels sous-systèmes sont interdépendants.
 

Quelles sont les questions qui distinguent la sécurité de l'IA de sa gouvernance ?

Le moyen le plus rapide de les distinguer est de comparer les questions que chacun pose à un fournisseur. Utilisez les deux ensembles de questions dans chaque évaluation d'IA.

Questions de sécurité à poser:

• Comment protéger le modèle contre les entrées adverses ?
• Comment contrôlez-vous et enregistrez-vous les accès aux données pour détecter les violations de données ?
• Quelle est votre procédure de réponse aux incidents si un attaquant compromet le modèle ?

Questions de gouvernance à se poser:

• Quelles sont les actions autorisées pour l'agent IA, et comment faire respecter ce périmètre d'action ?
• Qui a approuvé chacune des actions entreprises par l'agent, et où se trouve ce document ?
• Pouvez-vous produire une piste d'audit immuable de l'activité de l'agent pour un contrôle réglementaire ?

Un fournisseur qui répond correctement aux critères de la première liste, mais qui échoue sur le second, ne dispose pas d'une architecture de gouvernance. Ce fournisseur propose un agent bien protégé, mais dont personne ne peut assurer un contrôle total.

Que se passe-t-il lorsque l'on considère la sécurité et la gouvernance de l'IA comme une seule et même chose ?

Vous vous retrouvez avec des défaillances de gouvernance que vos outils de sécurité ne détectent jamais. En voici trois qui se produisent en situation réelle.

Une panne non autorisée. Un agent d'IA relance un traitement par lots en production en pleine journée, provoquant une chute brutale des temps de réponse. L'équipe de sécurité vérifie les journaux et ne détecte aucune brèche, aucune intrusion, aucune anomalie. Impossible cependant d'identifier l'auteur de cette relance, faute d'étape d'approbation. Il s'agit d'un manquement à la gouvernance.

Un audit qui répond à la mauvaise question. Un organisme de réglementation demande un compte rendu détaillé de toutes les actions des agents d'IA au cours des 90 derniers jours, avec les noms des personnes ayant approuvé chaque action. L'équipe de sécurité fournit un journal d'activité du périmètre vierge. Ce journal prouve qu'aucune intrusion n'a eu lieu, mais il ne dit rien des actions des agents. C'est un manquement grave à la gouvernance.

L'agent qui détient tous les accès. Un agent IA s'exécute avec les identifiants complets d'un opérateur senior. Aucune faille de sécurité n'a été constatée, et personne n'a encore fait un usage abusif des données. Cependant, rien ne limite le champ d'action de cet agent: il peut lire, modifier ou supprimer tout ce qu'un opérateur peut faire. C'est une faille de gouvernance potentielle qui ne demande qu'à être exploitée.

Dans chaque cas, votre dispositif de sécurité a tenu bon. Votre dispositif de gouvernance, lui, n'a jamais existé.

Comment construire la sécurité et la gouvernance de l'IA sans les confondre ?

Gérez-les comme deux projets parallèles, avec des responsables et des critères d'évaluation distincts. Ne les fusionnez pas en un seul programme. Continuez d'investir dans la sécurité, puis mettez en place la gouvernance que votre architecture de sécurité n'a jamais été conçue pour assurer.

Cette couche nécessite quatre capacités:

• Identité de l'agent: Chaque agent agit sous ses propres identifiants, distincts de ceux de l'opérateur humain.
• Autorisation limitée: les agents n’accèdent qu’aux ressources nécessaires à chaque tâche.
• Contrôles humains: Les actions à haut risque sont suspendues jusqu'à ce qu'une personne les autorise.
• Piste d'audit immuable: chaque action, sa justification et son approbateur sont consignés dans un enregistrement que personne ne peut modifier a posteriori.

Fusée^® EVA^™ Rocket EVA est conçu selon ce type d'architecture de gouvernance. Chaque agent se voit attribuer des identifiants temporaires et limités dans le temps. Les règles opérationnelles sont appliquées par le biais de politiques définies dans le code, et les actions à haut risque sont soumises à l'approbation humaine. Chaque étape est consignée dans un journal d'audit immuable, lié à la fois à l'agent et à l'approbateur humain.

Rocket EVA s'intègre à votre infrastructure de sécurité existante sans la remplacer. Cette infrastructure comprend la gestion des identités et des accès, la gestion des services informatiques et les outils d'observabilité. Votre équipe de sécurité conserve la maîtrise du périmètre. Vos équipes de conformité, de gestion des risques et d'exploitation disposent d'un historique exploitable. Vos opérateurs bénéficient d'opérations automatisées et gouvernées qui accélèrent les diagnostics dans les environnements mainframe, distribués et cloud, sans engendrer de nouveaux risques.

Vous n'avez pas à choisir entre rapidité et responsabilité. En mettant en place ces deux axes de travail dès maintenant, votre prochain déploiement d'IA reposera sur des bases reconnues par les autorités réglementaires.

Découvrez comment l'architecture de Rocket EVA aborde la gouvernance de l'IA, et pas seulement la sécurité.

Rocket est une marque déposée de Rocket Software, Inc. et de ses filiales.