Où les normes de sécurité de l’IA s’arrêtent — et où la protection en temps réel doit commencer

Avec toutes les discussions sur les risques de sécurité de l’IA, un problème qui semble être négligé est le suivant : le fait que les systèmes d’IA ne fonctionnent qu’en exposant leurs actifs les plus précieux — les modèles et les données.

Contrairement aux logiciels traditionnels, l’IA n’exécute pas simplement une logique prédéfinie. Elle mélange en permanence des modèles propriétaires avec des entrées sensibles pour générer des sorties, souvent sur une infrastructure qui n’a pas été conçue pour protéger le calcul.

De cette façon, la sécurité traditionnelle est insuffisante. Le cryptage est efficace lorsque les données sont stockées ou transmises à travers un réseau, mais pas lorsque les données sont traitées ou opérées. Pour l’IA en particulier, le danger surgit lorsque un modèle est déployé. Ses paramètres sont chargés en mémoire, initialisés et exécutés à grande échelle – le point auquel le cryptage cesse – les exposant à un accès non autorisé potentiel. Lors de l’inférence, des données sensibles circulent dans cet espace exposé. Le résultat est une surface de risque très vulnérable : les systèmes d’IA qui peuvent sembler sécurisés – mais sont en réalité non protégés aux moments les plus critiques.

Les organismes de normalisation tels que le National Institute of Standards and Technology (NIST), l’Agence de cybersécurité de l’Union européenne (anciennement connue sous le nom d’Agence européenne pour la sécurité des réseaux et de l’information, ou ENISA), et le Open Web Application Security Project (OWASP) ont commencé à cartographier ce territoire. Ils décrivent les risques, nomment les vulnérabilités et définissent les principes de gouvernance. Mais ils s’arrêtent avant de prescrire comment protéger les modèles en tant que propriété intellectuelle et les données en tant qu’actifs confidentiels une fois l’exécution commencée. Combler cet écart nécessite de repenser la sécurité de l’IA – non pas comme un exercice de conformité, mais comme un problème de calcul lui-même. C’est là que le cryptage en cours d’utilisation, ou le cryptage de bout en bout, joue un rôle.

Le point aveugle de la sécurité de l’IA moderne

La plupart des conversations sur la sécurité de l’IA tournent encore autour de sujets familiers : la gouvernance des données de formation, les contrôles d’accès, la surveillance des API, et les politiques d’utilisation responsables. Ceux-ci sont nécessaires. Cependant, aucun d’entre eux n’aborde ce qui se passe après le déploiement, lorsque un modèle quitte le référentiel et devient un système vivant.

Une fois déployé, les paramètres d’un modèle ne sont plus des artefacts abstraits. Ils sont des actifs résidents en mémoire, continuellement accédés pendant l’inférence et souvent utilisés par plusieurs locataires ou clients via des services d’IA partagés. Cette exposition se produit avant toute demande d’inférence, aggravant ainsi le risque en introduisant des entrées sensibles et un comportement observable de l’extérieur.

Traiter la protection du modèle comme une préoccupation préalable au déploiement et la sécurité de l’inférence comme une préoccupation en temps réel manque l’essentiel. Dans les systèmes réels, ces risques se chevauchent. Les modèles et les données sont exposés tout au long de l’initialisation, de l’exécution et de la sortie. La sécurité qui commence et se termine avec les contrôles de stockage ne parvient pas à résoudre ces expositions.

Ce que NIST obtient bien — et où cela s’arrête

Le cadre de gestion des risques de l’IA de NIST est devenu une pierre angulaire pour les organisations qui tentent de gérer les risques de l’IA. Sa structure — gouverner, cartographier, mesurer, gérer — offre une manière disciplinée de réfléchir à la responsabilité, au contexte, à l’impact et à l’atténuation tout au long du cycle de vie de l’IA.

Ce que NIST fait particulièrement bien, c’est encadrer le risque de l’IA comme un risque systémique plutôt que comme un événement accidentel. Les défaillances de l’IA sont rarement des événements ponctuels ; elles émergent des interactions entre les modèles, les données, les personnes et l’infrastructure. Ce cadrage est essentiel.

Là où le cadre est limité, c’est en ne prescrivant pas comment les actifs de l’IA de haute valeur sont protégés une fois les systèmes en ligne. Les paramètres du modèle sont implicitement traités comme des artefacts de conception plutôt que comme des actifs en temps réel. Les environnements d’exécution sont supposés être suffisamment fiables.

Dans la pratique, les paramètres du modèle sont souvent les actifs les plus précieux que possède une organisation. Ils sont chargés en mémoire, copiés à travers les nœuds, mis en cache et réutilisés. Si la gestion des risques de l’IA ne tient pas compte de la confidentialité des modèles pendant le déploiement et l’exécution, un actif critique reste en dehors de la limite de risque, comme un canard assis.

ENISA et la réalité des menaces spécifiques à l’IA

Le travail d’ENISA sur la cybersécurité de l’IA pousse la conversation plus loin. Son cadre multicolore distingue entre la sécurité traditionnelle de l’infrastructure et les risques spécifiques à l’IA, en reconnaissant que les systèmes d’IA se comportent différemment — et défaillent différemment — que les logiciels conventionnels.

Pourquoi est-ce important ? L’IA introduit des menaces qui ne rentrent pas dans les contrôles existants : extraction de modèles, fuite de paramètres, exposition de co-tenancy et falsification pendant l’exécution. Ces risques n’exigent pas d’attaquants exotiques. Ils surgissent naturellement lorsque des modèles de haute valeur sont exécutés dans des environnements partagés ou gérés de l’extérieur.

Le cadre d’ENISA reconnaît implicitement que sécuriser l’IA signifie sécuriser le comportement, et non seulement le code. Mais comme la plupart des normes, il se concentre sur ce qui devrait être considéré, et non sur la manière dont les protections sont techniquement mises en œuvre une fois les modèles en cours d’exécution.

OWASP et le coût de l’intelligence observable

Le top 10 d’OWASP pour les applications de modèles de langage à grande échelle offre une vision plus concrète de la manière dont les systèmes d’IA sont rompus dans le monde réel. L’injection de prompt, la divulgation d’informations sensibles, la fuite d’incrustation, la transparence excessive de la sortie — ces préoccupations ne sont pas théoriques. Ce sont les sous-produits du déploiement de modèles puissants sans contraindre ce qu’ils révèlent.

Bien que ces problèmes soient souvent présentés comme des problèmes d’application, leurs conséquences sont plus profondes. L’exposition répétée du comportement du modèle peut conduire à un clonage efficace ; une mauvaise isolation des incrustations peut révéler la structure ; et l’abus d’inférence devient un chemin vers la réplication du modèle.

La taxonomie d’OWASP rend une chose claire : protéger l’IA ne consiste pas seulement à arrêter les mauvaises entrées. Il s’agit de limiter ce que les modèles exposent — à l’intérieur et à l’extérieur — une fois qu’ils sont opérationnels.

Une conclusion partagée, un travail inachevé

À travers NIST, ENISA et OWASP, il y a un large accord sur les fondamentaux :

• Le risque de l’IA s’étend sur tout le cycle de vie
• Les systèmes d’IA introduisent de nouvelles catégories de menaces
• Les modèles et les données sont des actifs de haute valeur
• L’exposition en temps réel est inévitable

Ce que ces cadres manquent, cependant, c’est un mécanisme pour faire respecter la confidentialité une fois les modèles déployés et le calcul commencé. Cette omission n’est pas une faille, car les normes définissent l’intention et la portée. La mise en œuvre est généralement laissée au concepteur de système.

Mais ils laissent un écart critique — qui grandit à mesure que les systèmes d’IA s’étendent.

Le cryptage en cours d’utilisation change l’équation

Le cryptage en cours d’utilisation déplace le modèle de sécurité. Au lieu de supposer que les données et les modèles doivent être exposés pour être utiles, il traite le calcul comme quelque chose qui peut être protégé.

En termes pratiques, cela signifie :

• Les modèles restent cryptés pendant le déploiement, l’initialisation et l’exécution
• Les entrées ne sont jamais visibles en texte clair pour l’environnement d’exécution
• Les états intermédiaires ne peuvent pas être inspectés ou modifiés
• L’infrastructure n’a plus besoin d’être implicitement fiable

Cela ne remplace pas les cadres de gouvernance ou les contrôles d’application — il les opérationnalise. Il transforme les principes de risque en garanties exécutoires dès que les systèmes d’IA sont les plus vulnérables.

En d’autres termes, le cryptage en cours d’utilisation est la couche manquante entre la politique de l’IA et la réalité de l’IA.

Lorsque la gouvernance se termine et que l’exécution commence : la sécurisation du calcul de l’IA

La sécurité de l’IA se brise en temps réel. Une fois déployés, les modèles d’IA et les données sensibles doivent être exposés en mémoire pour fonctionner, créant une surface de risque que les contrôles traditionnels — le cryptage au repos, le cryptage en transit et les cadres de gouvernance — n’ont jamais été conçus pour protéger.

Les organismes de normalisation tels que NIST, ENISA et OWASP ont fait des progrès critiques dans la définition des risques de l’IA, de la responsabilité et de l’utilisation abusive. Mais leurs conseils traitent largement les modèles comme des artefacts de conception et supposent que les environnements d’exécution peuvent être fiables. Dans la pratique, les paramètres du modèle et les entrées sensibles sont continuellement accédés, réutilisés et souvent traités dans des environnements partagés ou gérés de l’extérieur.

Combler cet écart nécessite de repenser la sécurité de l’IA non pas comme un exercice de conformité, mais comme un problème de protection du calcul lui-même — lorsque les modèles sont vivants, les données sont en cours d’utilisation et l’exposition est inévitable. Le cryptage en cours d’utilisation offre un moyen viable de maintenir les modèles d’IA et les entrées sensibles sécurisés à chaque étape du cycle de vie de l’IA.