La diff\u00e9rence entre la s\u00e9curit\u00e9 de l'IA et la s\u00fbret\u00e9 de l'IA est facile \u00e0 brouiller jusqu'\u00e0 ce qu'un appel de mod\u00e8le puisse affecter un client, un ticket, un document, une transaction ou un flux de travail d'agent. \u00c0 ce moment-l\u00e0, la distinction devient importante.<\/p>\n\n\n\n
La s\u00fbret\u00e9 de l'IA se demande si le syst\u00e8me se comporte de mani\u00e8re utile, fiable et align\u00e9e avec la t\u00e2che qu'il est cens\u00e9 accomplir. La s\u00e9curit\u00e9 de l'IA se demande si le syst\u00e8me, ses donn\u00e9es, ses outils ou ses chemins d'acc\u00e8s peuvent \u00eatre attaqu\u00e9s ou mal utilis\u00e9s. Les \u00e9quipes de production ont besoin des deux, car un mod\u00e8le s\u00fbr peut encore \u00eatre exploit\u00e9, et une int\u00e9gration s\u00e9curis\u00e9e peut encore produire des r\u00e9sultats nuisibles ou peu fiables.<\/p>\n\n\n\n
Pour les constructeurs travaillant avec des API de mod\u00e8les, le point de contr\u00f4le pratique est souvent l'appel du mod\u00e8le lui-m\u00eame : quel mod\u00e8le est s\u00e9lectionn\u00e9, quelle invite est envoy\u00e9e, quels outils sont autoris\u00e9s, quelles donn\u00e9es sont attach\u00e9es, ce qui est enregistr\u00e9, quel chemin de secours est disponible, et ce que l'utilisateur voit lorsque la r\u00e9ponse revient.<\/p>\n\n\n\n
La s\u00fbret\u00e9 de l'IA concerne le comportement et les r\u00e9sultats d'un syst\u00e8me d'IA. La question centrale est : le syst\u00e8me doit-il se comporter de cette mani\u00e8re pour cet utilisateur, cette t\u00e2che et ce contexte ?<\/p>\n\n\n\n
Le travail de s\u00fbret\u00e9 couvre souvent la qualit\u00e9 des sorties, le contenu nuisible, les biais, les hallucinations, les comportements de refus, la robustesse, l'\u00e9valuation et la supervision humaine. Il inclut \u00e9galement la question op\u00e9rationnelle \u00e0 laquelle chaque \u00e9quipe produit finit par faire face : que se passe-t-il lorsque le mod\u00e8le est incertain, erron\u00e9, incomplet ou sollicit\u00e9 pour faire quelque chose en dehors de son champ d'application pr\u00e9vu ?<\/p>\n\n\n\n
Au Le cadre de gestion des risques de l'IA du NIST<\/a> est utile ici car il traite le risque de l'IA comme quelque chose que les \u00e9quipes devraient gouverner, cartographier, mesurer et g\u00e9rer, et non comme une d\u00e9cision ponctuelle de s\u00e9lection de mod\u00e8le. Ce cadrage est particuli\u00e8rement important lorsqu'un produit r\u00e9partit le travail entre plusieurs mod\u00e8les ou fournisseurs.<\/p>\n\n\n\n La s\u00e9curit\u00e9 de l'IA concerne la protection de l'int\u00e9gration du mod\u00e8le contre les attaques, les acc\u00e8s non autoris\u00e9s, l'exposition des donn\u00e9es et les abus. La question centrale est : quelqu'un peut-il exploiter ce syst\u00e8me, son invite, ses outils, ses sources de r\u00e9cup\u00e9ration ou ses permissions ?<\/p>\n\n\n\n Le travail de s\u00e9curit\u00e9 couvre souvent l'injection d'invites, la divulgation d'informations sensibles, l'empoisonnement des donn\u00e9es d'entra\u00eenement ou de r\u00e9cup\u00e9ration, les risques de la cha\u00eene d'approvisionnement des mod\u00e8les, les permissions excessives des outils, les d\u00e9nis de service, les fuites d'identifiants et la conception non s\u00e9curis\u00e9e de plugins ou d'agents. Le Top 10 OWASP pour les applications de mod\u00e8les de langage \u00e9tendu<\/a> est une r\u00e9f\u00e9rence utile car il nomme de nombreux modes de d\u00e9faillance qui apparaissent une fois que les LLM sont int\u00e9gr\u00e9s dans des logiciels r\u00e9els.<\/p>\n\n\n\n La s\u00e9curit\u00e9 n'est pas seulement un probl\u00e8me de fournisseur de mod\u00e8les. Les constructeurs doivent encore prot\u00e9ger les cl\u00e9s API, authentifier les utilisateurs, d\u00e9finir les permissions des espaces de travail, filtrer les sources de r\u00e9cup\u00e9ration, contr\u00f4ler les outils des agents et surveiller les sch\u00e9mas d'utilisation anormaux. Un fournisseur peut s\u00e9curiser sa propre infrastructure tandis que votre application expose encore un acc\u00e8s risqu\u00e9 aux outils ou aux donn\u00e9es des utilisateurs.<\/p>\n\n\n\n Le chevauchement est l\u00e0 o\u00f9 de nombreuses d\u00e9faillances de production se produisent. L'injection de commandes est un probl\u00e8me de s\u00e9curit\u00e9 lorsqu'elle manipule des instructions ou l'acc\u00e8s aux donn\u00e9es, mais elle peut devenir un probl\u00e8me de s\u00fbret\u00e9 lorsque la r\u00e9ponse manipul\u00e9e atteint un utilisateur. Un agent avec des permissions \u00e9tendues est une pr\u00e9occupation de s\u00e9curit\u00e9, mais ses actions peuvent cr\u00e9er des risques de s\u00fbret\u00e9 et d'entreprise si le mod\u00e8le prend une d\u00e9cision peu fiable.<\/p>\n\n\n\n De nombreuses \u00e9quipes commencent avec un seul mod\u00e8le, une seule cl\u00e9 API et une seule invite. Cela peut fonctionner pour un prototype. Cela devient fragile lorsque le produit ajoute plusieurs mod\u00e8les, des param\u00e8tres sp\u00e9cifiques au client, des outils d'agent, de la r\u00e9cup\u00e9ration, un routage de secours, des contr\u00f4les de co\u00fbts ou une facturation bas\u00e9e sur l'utilisation.<\/p>\n\n\n\n Une couche de contr\u00f4le des appels de mod\u00e8le donne aux Constructeurs un endroit coh\u00e9rent pour appliquer des d\u00e9cisions avant et apr\u00e8s l'inf\u00e9rence. Elle peut aider \u00e0 r\u00e9pondre \u00e0 des questions telles que :<\/p>\n\n\n\nLa s\u00e9curit\u00e9 de l'IA contr\u00f4le les risques d'exploitation<\/h2>\n\n\n\n
S\u00fbret\u00e9 vs S\u00e9curit\u00e9 : La diff\u00e9rence pratique<\/h2>\n\n\n\n
Zone<\/th> S\u00e9curit\u00e9 de l'IA<\/th> Protection de l'IA<\/th><\/tr><\/thead> Question principale<\/td> Le syst\u00e8me doit-il produire ce comportement ?<\/td> Quelqu'un peut-il exploiter ce syst\u00e8me ?<\/td><\/tr> Risque typique<\/td> R\u00e9sultats nuisibles, biais\u00e9s, peu fiables ou trompeurs<\/td> Injection de prompt, exposition de donn\u00e9es, abus ou acc\u00e8s non autoris\u00e9<\/td><\/tr> Contr\u00f4les principaux<\/td> \u00c9valuations, garde-fous, revue humaine, choix de mod\u00e8le, politiques de sortie<\/td> Authentification, permissions, contr\u00f4les d'entr\u00e9e, gestion des secrets, isolation des outils<\/td><\/tr> Exemple d'\u00e9chec<\/td> Un assistant de support donne des conseils de remboursement dangereux<\/td> Un prompt malveillant trompe un agent pour exposer des donn\u00e9es priv\u00e9es de tickets<\/td><\/tr> Chevauchement de propri\u00e9taire<\/td> Produit, politique, ing\u00e9nierie, juridique, experts en domaine<\/td> S\u00e9curit\u00e9, plateforme, ing\u00e9nierie, op\u00e9rations<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Pourquoi les appels de mod\u00e8le ont besoin de leur propre couche de contr\u00f4le<\/h2>\n\n\n\n