Les garde-fous de l’IA en entreprise pourraient compter davantage que les modèles de pointe

Oubliez les modèles d’IA de pointe. Les clients réclament aux entreprises davantage de garde-fous pour l’IA déjà utilisée, et l’expérience du PCI DSS offre un modèle utile.

La période de grâce réglementaire accordée à l’IA est terminée. Des révélations récentes ont suscité des discussions sur le ralentissement des progrès de pointe et l’imposition de contrôles. L’un des rares points de consensus est que les contrôles devraient être indépendants des modèles et faire l’objet d’une vérification indépendante.

La suite fait débat, mais les autorités de régulation passent à l’action. La loi de l’Union européenne sur l’IA instaure progressivement des obligations de sécurité, notamment la responsabilité des acheteurs. Aux États-Unis, le cadre de gestion des risques liés à l’IA du NIST est adopté comme norme de diligence raisonnable. À l’échelle mondiale, le Top 10 de l’OWASP pour les applications LLM est devenu une référence courante dans les évaluations de sécurité, et la certification ISO/IEC 42001 apparaît dans les documents d’approvisionnement.

Les développeurs de modèles ne sont donc pas les seuls à devoir rendre des comptes. Les entreprises qui utilisent des modèles déjà commercialisés sont elles aussi exposées à des obligations et à des risques en matière de sécurité, en particulier dans les cas d’usage à haut risque. Des réponses erronées à un questionnaire de sécurité client ou dans une réponse à un appel d’offres pourraient faire échouer une transaction entre entreprises.

Le PCI DSS montre la voie

Heureusement, ce scénario nous est familier. Il y a vingt ans, la sécurité des applications web reposait principalement sur des audits de code périodiques, des analyses statiques et la rigueur des développeurs. Puis, l’exigence 6.6 du PCI DSS, publiée en 2006 et appliquée à partir de 2008, a imposé aux organisations qui traitent des données de titulaires de carte soit d’examiner l’ensemble du code de leurs applications pour y détecter des vulnérabilités, soit d’installer des contrôles techniques automatisés. Par la suite, l’examen du code n’a plus été une option et les contrôles techniques sont devenus obligatoires.

Mais le PCI DSS n’a pas commencé par une loi. Tout a commencé par une norme contractuelle qui a transformé le marché, probablement plus rapidement qu’une loi ne l’aurait fait, car les contrats évoluent plus vite que les lois gouvernementales.

De la même manière, les organisations subissent aujourd’hui des pressions pour mettre en place des garde-fous concernant l’IA déployée, non pas de la part des autorités de régulation, mais de leurs clients et partenaires, au moyen de questionnaires de sécurité, de clauses dans les appels d’offres et d’exigences dans les polices d’assurance.

Résoudre le problème opérationnel, puis assurer la conformité

Il peut être difficile de répondre à ces pressions, car la gouvernance de l’IA ne se limite pas aux politiques. Elle exige des preuves techniques continues.

De nombreuses entreprises avec lesquelles je m’entretiens font fonctionner en production une demi-douzaine de modèles, voire davantage, et les enchaînent ou les orchestrent fréquemment, de sorte que la sortie de l’un alimente l’entrée d’un autre. Imaginez qu’il faille démontrer l’application d’une seule politique à l’échelle de tout le système — par exemple, empêcher les sorties des modèles de contenir des données personnelles identifiantes (PII) — dans ces conditions. Auditer manuellement plusieurs modèles configurés individuellement mobiliserait énormément de temps de développement. En outre, la plupart des organisations peinent à maîtriser les usages de l’IA non autorisés et à haut risque, par exemple lorsque des employés collent des données sensibles dans des outils d’IA grand public ou que des fournisseurs SaaS activent discrètement de nouvelles fonctionnalités d’IA. Pourtant, la responsabilité incombe entièrement à l’entreprise.

Dans des situations aussi complexes, les exigences peuvent se résumer à une tâche simple : démontrer que vous pouvez encadrer en continu les entrées et les sorties des modèles, tout en consignant cette activité à des fins de vérification. Lorsque des applications font appel à des modèles, que des agents invoquent des outils et que des modèles exécutent des actions ou déclenchent des flux de travail, c’est l’action qu’il faut contrôler : l’appel d’outil, la requête API ou le déclenchement du flux de travail.

Intégrer la sécurité au chemin d’inférence

Cette action constitue le point de contrôle que les spécialistes de la sécurité des applications s’emploient depuis 20 ans à mettre en place pour le trafic applicatif. En particulier lorsque l’inférence passe par une infrastructure partagée, ce chemin d’inférence devient le point de contrôle idéal pour l’ensemble des modèles, et même pour les usages de l’IA non autorisés. Le trafic d’inférence de l’IA doit être acheminé, inspecté, authentifié et gouverné comme toute autre interaction importante avec une application, en fonction de sa provenance et de ce qu’il cherche à accomplir. Contrairement aux audits manuels, la gouvernance du trafic d’inférence peut passer à l’échelle.

Comment commencer

Compte tenu de l’orientation que prennent les réglementations, les organisations doivent dès maintenant entreprendre trois démarches :

1. Cartographier votre périmètre de responsabilité, des API SaaS et des points de terminaison hébergés jusqu’à l’IA parallèle.
2. Dissocier les politiques de sécurité et leur mise en application des modèles, et les intégrer au chemin d’inférence.
3. Veiller à ce que les journaux d’audit soient générés indépendamment des modèles et des agents, qui ont tenté de modifier les enregistrements de leurs propres actions.

Les critères d’un suivi et d’une mise en application adéquats sont encore en cours de définition, mais vos équipes chargées des opérations et de la sécurité savent ce qui peut réellement être appliqué, quel est le coût d’un contrôle en matière de latence et de complexité, et dans quels cas une règle bien intentionnée risque d’aboutir au mauvais résultat. Faites-les participer dès maintenant. Les risques et les obligations liés à l’utilisation de l’IA sont réels, et vos clients comme vos dirigeants se soucient sans aucun doute davantage des risques auxquels ils sont confrontés aujourd’hui que des menaces que les modèles de pointe pourraient représenter demain.