Sécurité dans le monde de l'IA : les risques réels, les quatre composants et le cadre SAIF

Dans presque toutes les entreprises qui discutent d'IA, la même répartition de voix apparaît : la moitié de la direction voit l'efficacité et l'avantage concurrentiel, l'autre moitié alerte sur les brèches, les fuites de données et l'atteinte à la marque. La réponse qui ouvre « Introduction to Security in the World of AI », de Google Skills, est celle qui ordonne la conversation : commencer par comprendre les risques réels et comment ils sont atténués. Ce qui suit parcourt cette compréhension de bout en bout, avec un outil de clôture, le Secure AI Framework (SAIF), le cadre de Google pour sécuriser les systèmes d'IA.

Les risques d'utiliser l'IA, et ceux qui persistent sans l'utiliser

Qui adopte l'IA dans l'entreprise affronte quatre familles de risques. Vol de données : fuite ou mauvais usage de données internes ou clients. Atteinte au droit d'auteur : matériel protégé généré par des modèles. Perte financière : fraude, vol, interruptions opérationnelles et, en fond, les coûts de mise en œuvre et de maintenance. Et risques de conformité : résultats discriminatoires ou violations de la vie privée.

Le détail qui surprend presque toujours : la liste ne se rétrécit pas si l'entreprise décide de ne pas utiliser l'IA. Les acteurs malveillants exploitent l'IA pour attaquer ; l'IA est déjà intégrée dans beaucoup d'outils que les gens utilisent sans s'en rendre compte ; et si l'entreprise n'autorise pas les outils d'IA, les employés finiront par utiliser les non autorisés, exposant des vulnérabilités que personne n'a évaluées. La conclusion du matériel tient en une ligne : la connaissance est votre première ligne de défense.

Comment fonctionne un modèle, pour pouvoir discuter sécurité

Avant de parler de contrôles, il vaut comprendre ce qu'on sécurise. Un modèle d'IA est un ensemble d'équations mathématiques complexes qui prend des entrées (prompts) et produit des sorties : classification, prédictions ou recommandations. Certains modèles utilisent le machine learning, ce qui signifie que l'équation s'adapte avec de grands volumes de données d'entraînement que le modèle utilise pour « apprendre » des patrons et relations ; une fois entraîné, il est déployé et prédit sur de nouvelles données.

Les prédictions sont des prédictions, et leur qualité dépend du cas d'usage. L'exemple du matériel est inoubliable : 40 % de précision peut être acceptable dans un pari de courses de chevaux, alors qu'une voiture autonome a besoin de 99 % ou plus en détection et classification d'objets. La consistance du résultat compte autant que la précision, et la compréhension du cas d'usage décide de combien de précision il faut et si une supervision humaine est nécessaire.

L'IA générative va au-delà de l'appariement entrée-sortie : elle apprend d'une masse énorme de données d'entraînement, comme lire des milliers de livres ou regarder des millions d'images, pour générer du texte, des images, de la vidéo, de l'audio ou du code novateur. Pour l'analyse de sécurité, la différence pratique est dans le type de sortie possible : elle génère des choses que personne n'a revues avant qu'elles existent.

Les trois façons d'interagir, et à qui revient la responsabilité

Les modèles sont rarement utilisés isolément. L'utilisateur interagit avec une application ou une API, qui est un pont avec des règles et des spécifications pour qu'un logiciel utilise celui d'un autre ; l'application gère l'envoi, l'envoie au modèle et présente la sortie, en cachant la technologie sous-jacente.

Cela ouvre trois façons d'interagir avec l'IA, et chacune répartit différemment la responsabilité de la sécurité. Construire des modèles : créer ou personnaliser, y compris le fine-tuning d'un modèle préentraîné. Construire des applications ou APIs qui exploitent des modèles. Utiliser des applications ou APIs avec IA. Dans les deux premières, on a le contrôle total de la sécurité et aussi la responsabilité de sa robustesse. En utilisant des applications d'autrui, on dépend des mesures du fournisseur, il faut donc comprendre ses pratiques.

La question que le matériel propose de remplacer est celle-ci : la question de savoir si l'IA est sûre, remplacée par celle de comment opère l'application concrète qui l'utilise. Le modèle par lui-même est une équation, et sans entrée il ne fait rien ; les applications et APIs construites autour sont celles qui interagissent avec vos données et décident comment elles sont stockées, utilisées et protégées. Leur sécurité s'avère être, fondamentalement, la même que celle de tout autre logiciel.

Les données : un carburant avec des questions inconfortables

La donnée d'entraînement est le carburant du modèle, et sa qualité impacte directement la sortie : de mauvaises données donnent de mauvais résultats, des données sensibles peuvent se révéler par accident et des données avec des grossièretés ou des liens non sécurisés peuvent finir par apparaître dans la sortie.

Les applications s'améliorent continuellement avec de nouveaux modèles entraînés sur des données qui peuvent provenir de la saisie de l'utilisateur, et si une application collecte des données dépend de comment elle a été conçue. Fournir des informations à une application d'IA ressemble à remplir un formulaire web : cela exige d'évaluer l'application avant.

Les licences font la différence. Les versions entreprise apportent généralement des garanties de confidentialité plus strictes, en s'assurant que les données de l'utilisateur ne servent pas à entraîner davantage le modèle ; les applications grand public peuvent utiliser les interactions pour améliorer le modèle avec le temps. Avant d'en utiliser une, il vaut revoir les politiques de traitement des données et les termes de la licence concrète.

Et face à un prompt avec des données médicales personnelles attribuables, le matériel réduit la décision à deux questions : est-ce que l'application d'IA stocke les entrées et les sorties ? Est-ce qu'elle obfusque ou anonymise les données personnelles identificables (PII) avant de les stocker ou les traiter ?

Les quatre composants d'un système d'IA

Un système d'IA est un système complet de quatre composants interconnectés, et il faut sécuriser les quatre.

flowchart TD
    A[Application ou API : filtrer les entrées et gérer les sorties] --> M[Modèle : données sensibles et inférences]
    M --> D[Données : réglementations, consentement et PII]
    D --> I[Infrastructure : contrôle d'accès et protection du modèle]

L'application (ou l'API) est l'interface : elle doit filtrer les entrées selon les règles et limitations du modèle et décider comment gérer les sorties éthiquement problématiques. Le modèle est le cerveau : il peut manipuler des données sensibles dans les données d'entraînement, l'historique de chat ou les prompts, et inférer des informations sensibles sur les personnes. Les données sont le carburant : elles exigent de respecter les réglementations, d'obtenir le consentement de l'utilisateur et de masquer les PII quand c'est approprié. L'infrastructure est le matériel et le logiciel qui l'exécute : elle requiert un contrôle d'accès granulaire et de protéger le modèle contre le vol ou la modification non autorisée.

Les sujets se chevauchent entre composants parce que les systèmes d'IA sont interconnectés et que les contrôles peuvent s'appliquer à plusieurs niveaux.

Trois intersections entre sécurité et IA

La carte du terrain a trois zones. La première : contrer les cyberattaques propulsées par l'IA. Phishing et ingénierie sociale plus convaincants et personnalisés, y compris des appels vocaux ; automatisation des variantes de malwares ; identification de vulnérabilités ; DDoS et ransomwares sophistiqués. La seconde : intégrer l'IA dans les produits de sécurité, avec des outils comme Google SecOps et Google Threat Intelligence pour investiguer, répondre et prédire les menaces, et Security Command Center avec sa vue centralisée de posture, la simulation de routes d'attaque et Web Security Scanner. La troisième, le focus de ce texte : sécuriser les systèmes et services d'IA.

Rester sûr, dans ce cadre, implique d'être éduqué, préparé et protégé ; s'éloigner de l'IA ne figure pas sur la liste.

SAIF : quatre étapes et six éléments

Face à l'absence de standards de l'industrie, Google a créé SAIF comme cadre pour sécuriser les systèmes d'IA. Le processus a quatre étapes. Comprendre l'usage : le problème métier, les exigences de données et d'utilisateur, d'où vient le modèle. Réunir une équipe transverse : propriétaires de cas métier, sécurité, ingénierie cloud, risque et audit, confidentialité, juridique, data science, développement, IA responsable et éthique. Aligner avec une initiation à l'IA pour chaque membre de l'équipe. Et appliquer les six éléments.

flowchart LR
    S1[1. Comprendre l'usage] --> S2[2. Réunir l'équipe transverse]
    S2 --> S3[3. Aligner avec une initiation à l'IA]
    S3 --> S4[4. Appliquer les six éléments]
    S4 --> E[Éléments continus : processus, sécuriser, détecter et répondre, automatiser, consistance, améliorer]

Les six éléments sont continus et ne requièrent aucun ordre. Intégrer la sécurité de l'IA dans les processus, avec évaluations de risques de bout en bout, lignage des données, validation et surveillance. Sécuriser, avec une base de sécurité forte pour tous les systèmes qui s'étend à l'écosystème d'IA. Détecter et répondre, en adaptant le renseignement sur les menaces aux risques uniques de l'IA et en surveillant les anomalies dans les entrées et les sorties. Automatiser les défenses, en utilisant l'IA pour faire monter en charge et accélérer la réponse aux incidents. Assurer la consistance, avec des protections cohérentes entre plateformes et outils. Et s'améliorer continuellement et prendre de l'avance, en testant les systèmes et en restant à jour avec les pratiques.

Les quatre cas, en un coup d'œil

Le cadre s'éprouve sur quatre scénarios. Finance, avec détection de fraude de cartes en temps réel : la décision de processus (si une transaction signalée désactive automatiquement la carte, exige une révision humaine ou permet la contestation), chiffrement et anonymisation, surveillance des attaques qui modifient le comportement du modèle, réponses automatiques avec Google SecOps, et conformité avec explicabilité du blocage. Santé, avec diagnostic de maladies sous HIPAA et autres réglementations locales, équité entre démographies et communication aux patients et régulateurs en cas d'incident. Médias, avec recommandations de contenu, bulles de filter, manipulation et red teaming sur le système. Retail, avec descriptions de produits générées par IA, lois sur la publicité véridique, modération assistée avec révision humaine et transparence envers le client.

Ce que le cadrage laisse et ce qui est resté non exécuté

Ce qui survivrait à un changement d'interface, ce sont deux choses. La première : la bonne question sur tout outil d'IA qui entre dans l'organisation est comment opère l'application concrète, et cette réponse s'évalue comme celle de tout autre logiciel. La seconde : avant de coller des données personnelles dans un modèle, les deux questions de stockage et de PII règlent la décision.

Ce qui est resté non exécuté dans cette documentation : les deux quizzes (celui des fondamentaux et celui du cadre SAIF) n'ont ni été ouverts ni soumis, et les réponses documentées proviennent de contrôles intégrés dans les leçons que le matériel montre lui-même ; les vidéos citées s'appuient sur leurs transcriptions incluses dans les leçons, pas sur l'audio ; et les liens de ressources supplémentaires (SAIF, blog et le paper « Secure, Empower, Advance ») n'ont pas été téléchargés.

---

*Source : « Introduction to Security in the World of AI », de Google Skills (cours google.ai-security-intro).*