Que signifie pour les entreprises le décret de Biden sur les mesures de sécurité de l’IA ?
2 novembre 2023
0 minutes de lectureLe 30 octobre, le président américain Joseph Biden a publié un vaste décret présidentiel (« EO ») visant à rendre l’IA plus sûre et plus responsable.
Résumé du décret présidentiel sur l’IA
Le décret couvre un large éventail de sujets, des biais algorithmiques à la protection de la vie privée, en passant par la réglementation de la sécurité des modèles d’IA de pointe. Les modèles de pointe sont les modèles les plus grands et les plus avancés, comme GPT-4, Bard et Llama 2. Le décret impose à de nombreuses agences gouvernementales de créer des domaines spécifiques de réglementation de l’IA au cours de l’année à venir. Il comporte également une section consacrée à l’encouragement du développement ouvert des technologies d’IA, à la promotion de l’innovation en matière de sécurité de l’IA et à la création d’outils utilisant l’IA pour améliorer la sécurité.
Le monde de la technologie examine encore le décret et évalue ses conséquences potentielles. Sur certains sujets importants, le décret ne dit rien. Par exemple, il ne mentionne pas l’open source et ne prévoit aucune exemption pour les projets open source qui pourraient, par exemple, créer de nouveaux modèles fondamentaux. Dans d’autres domaines, l’interprétation du texte reste incertaine. Le décret indique que les modèles nécessitant plus qu’une certaine quantité de ressources de calcul doivent communiquer leurs résultats, mais ne précise pas clairement si cela concerne tous les modèles ou uniquement ceux qui pourraient être facilement détournés à des fins malveillantes.
Le décret n’est pas non plus un ensemble de règles juridiquement contraignantes : il vise plutôt à établir le cadre des prochaines réglementations. Il devrait donc orienter les priorités et l’approche des autorités de régulation, et influencer les futures lois sur l’IA. La grande question, bien sûr, est de savoir quel effet ce décret aura sur le développement et le déploiement de technologies dans les entreprises et les organisations qui créent des systèmes d’IA ou s’appuient sur eux (dans cet article, un « système d’IA » désigne tout système de données, logiciel, matériel, application, outil ou utilitaire fonctionnant entièrement ou en partie grâce à l’IA). L’IA évolue très rapidement, et votre organisation est peut-être déjà en train de mettre en place des pratiques en matière d’IA qu’il pourrait être difficile ou coûteux de modifier lorsque les réglementations entreront en vigueur. L’idéal est d’éviter cette situation et d’anticiper les évolutions pour pérenniser vos opérations d’IA et vos produits en adoptant les bonnes pratiques recommandées par le décret présidentiel.
Principales questions soulevées par le décret présidentiel sur l’IA
Voici un aperçu des grandes questions que nous entendons et des réponses qui nous semblent pertinentes à ce stade. (Remarque : nous pourrons mettre cet article à jour au fil de l’évolution de la situation. Les mises à jour seront accompagnées d’une date.)
Questions abordées
Le décret présidentiel évoque un registre des modèles d’IA. Devrai-je m’y inscrire ?
Qu’est-ce qui déclenche les obligations de déclaration prévues par le décret présidentiel ?
On dirait que nous allons peut-être avoir besoin d’un AIBOM !
Q : Le décret présidentiel évoque un registre des modèles d’IA. Devrai-je m’y inscrire ?
R : Ce n’est pas encore clair, mais nous pensons que, dans la plupart des cas, les entreprises qui créent de petits modèles d’IA ou utilisent des modèles existants n’auront pas à s’inscrire.
Q : Qu’est-ce qui déclenche les obligations de déclaration prévues par le décret présidentiel ?
R : Le décret impose aux développeurs d’IA de déclarer tout entraînement d’IA à grande échelle susceptible de présenter un risque important pour la sécurité. Il impose également de déclarer les résultats des évaluations de sécurité ou des exercices de « red teaming ». Les fournisseurs de services cloud doivent aussi avertir le gouvernement si une personne étrangère tente d’acheter des services de calcul capables d’entraîner un grand modèle d’IA.
D’après le texte du décret, le seuil de déclaration concernera les très grands modèles, entraînés avec des dizaines de millions d’heures de calcul sur les derniers GPU. En termes opérationnels, cela correspond à des modèles entraînés sur un cluster dont la puissance de calcul dépasse 1026 opérations en nombres entiers ou en virgule flottante, ou sur tout cluster informatique dont le débit du réseau local dépasse 100 Gbit/s. En remontant le calcul, cela implique un entraînement sur des dizaines de billions de jetons. Selon certaines sources, GPT-4 a été entraîné sur 1,7 billion de jetons, soit un ordre de grandeur de moins. Autrement dit, à court terme, les seuils du décret ne concerneront probablement que les plus grands créateurs de modèles et les plus grands clusters de calcul, utilisés pour entraîner les modèles les plus imposants et dont chaque entraînement coûte plusieurs millions de dollars. Notez toutefois que le décret précise que le gouvernement pourra modifier ces critères à l’avenir : les seuils pourraient donc augmenter ou diminuer, selon les décisions réglementaires.
Q : Le décret présidentiel évoque des normes de déclaration pour les modèles d’IA « à double usage ». Comment sont-ils définis ?
R : En bref, le décret ne les définit pas clairement. Il semble viser les modèles d’IA susceptibles d’être utilisés à des fins malveillantes. En pratique, presque toutes les IA peuvent toutefois être entraînées et utilisées à de telles fins : la formulation reste donc assez vague. Cela dit, nous proposons quelques recommandations de base ci-dessous.
Q : Le décret présidentiel ne dit rien sur les logiciels open source. Comment s’appliquera-t-il aux modèles d’IA open source ?
R : Il n’existe pas encore de recommandations claires sur les modèles et l’IA open source. Dans l’ensemble, les recommandations générales du décret s’appliqueront probablement à l’IA open source et aux modèles développés puis publiés en open source.
Q : Le décret présidentiel porte spécifiquement sur les très grands modèles fondamentaux. Les grands modèles open source comme Llama 2, Falcon 70B ou Mistral sont-ils concernés ?
R : Le décret précise que ses dispositions et réglementations s’appliqueront aux modèles qui n’ont pas encore été publiés. Ces modèles existants feront donc probablement l’objet de niveaux de contrôle différents. Si vous développez des solutions à partir de ces modèles et que vous les modifiez, il est fort possible que votre équipe doive respecter au moins une partie des obligations de contrôle réglementaire et de déclaration.
Q : Le décret présidentiel aborde largement la sécurité de l’IA. Pouvez-vous me donner des recommandations concrètes ?
R : La sécurité est une notion assez subjective, mais voici quelques pistes. Le décret insiste sur la nécessité de systèmes d’IA sûrs et sécurisés. Il exige des évaluations robustes, fiables, reproductibles et normalisées des systèmes d’IA, ainsi que des politiques et des mécanismes permettant de tester, comprendre et atténuer les risques liés à ces systèmes avant leur mise en service. Si votre organisation entraîne ou ajuste des systèmes d’IA destinés à des produits accessibles au public ou à des applications en production, envisagez de mettre en place des processus de sécurité structurés et auditables, spécifiquement axés sur vos actifs liés à l’IA.
Q : Une section du décret présidentiel porte sur les libertés civiles, la vie privée et les biais algorithmiques. Quelles conséquences cela pourrait-il avoir pour mon organisation ?
R : Le décret exige que la vie privée et les libertés civiles des Américains soient protégées à mesure que l’IA progresse. Il ne fournit pas de recommandations précises, mais, dans les faits, d’autres lois ont déjà commencé à traiter ces questions, au niveau des États (comme en Californie) ou à l’échelle nationale (par exemple dans l’Union européenne). En définitive, les applications et modèles d’IA doivent bénéficier des mêmes garanties, de la même transparence et de la même traçabilité que les applications traditionnelles qui n’utilisent pas l’IA. Il peut être particulièrement difficile d’entraîner des systèmes d’IA avec des jeux de données contenant des biais cachés ou des informations personnelles identifiables (PII) anonymisées, susceptibles d’être extraites à l’aide des bons prompts. Ces deux situations peuvent entraîner des violations de la loi, voire des poursuites judiciaires.
Q : Quel est l’impact du décret sur le code généré par l’IA ?
R : Le décret présidentiel ne contient aucune disposition spécifique sur le code généré par l’IA et ne le mentionne pas. Vous devez néanmoins vous attendre à ce que le code généré par l’IA soit soumis aux réglementations plus générales sur la sécurité des applications et du code, et plus particulièrement à celles sur la sécurité de la chaîne d’approvisionnement. Nous pensons que toute entreprise qui développe des logiciels et utilise des outils de codage par IA devrait considérer ces outils comme faisant partie de sa chaîne d’approvisionnement logicielle. C’est particulièrement important pour les logiciels open source, qui peuvent comporter de nombreuses dépendances transitoires, imbriquées, conditionnelles ou directes vis-à-vis d’autres entreprises open source. En d’autres termes, vous verrez probablement apparaître des exigences similaires à celles qui se développent autour de la nomenclature logicielle (SBOM).
Q : On dirait que nous allons peut-être avoir besoin d’un AIBOM !
R : En effet, créer un document de type AIBOM, équivalent à votre SBOM, est une bonne idée. À tout le moins, consigner tous vos usages de l’IA, vos processus et vos données d’entraînement, et même effectuer un audit simulé et vérifier votre conformité aux réglementations en vigueur sur les logiciels et les technologies, pourrait constituer une bonne approximation d’un AIBOM et préparer votre organisation aux réglementations susceptibles d’être mises en œuvre à court ou moyen terme.
Q : Je travaille avec des données biologiques. Quel impact les dispositions relatives aux armes biologiques auront-elles sur mon organisation ?
R : Le seuil de calcul déclenchant les obligations de déclaration est légèrement inférieur pour les entraînements. Les modèles utilisant une puissance de calcul supérieure à 1023 opérations en nombres entiers ou en virgule flottante doivent faire l’objet d’une déclaration. Ce seuil reste toutefois relativement élevé et dépasse largement celui de la plupart des modèles utilisés aujourd’hui avec des données biologiques.
Q : Je travaille sur de très grands modèles, mais je ne les conçois pas. Quel impact ce décret aura-t-il sur moi ?
R : Si vous entraînez de très grands modèles dont les seuils de calcul approchent ceux indiqués, vous pourriez devoir déclarer vos entraînements et les résultats des évaluations de sécurité, même si vous utilisez des modèles existants. Même si vos entraînements n’atteignent pas ces seuils ou s’en approchent, vous pourriez quand même devoir enregistrer votre application. Vous n’en aurez probablement la certitude qu’une fois le processus réglementaire à venir achevé.
Q : Le décret comporte une disposition sur la cybersécurité et les outils d’IA. Dois-je prendre des mesures à ce titre ?
R : Non. Cette disposition vise principalement à favoriser le développement de nouveaux outils et de nouvelles recherches en cybersécurité, que ce soit pour utiliser l’IA ou pour surveiller et sécuriser les modèles d’IA, l’AIOps, ainsi que le développement et le déploiement d’applications faisant appel à l’IA. Bien sûr, si vous développez de nouvelles fonctionnalités de cybersécurité grâce à l’IA ou pour vous protéger contre les risques liés à l’IA, DARPA serait probablement ravie que vous participiez à son concours !
Q : J’utilise déjà beaucoup d’applications et de modèles d’IA open source. Que dois-je faire pour m’assurer qu’ils sont sûrs ?
R : L’IA open source faisant désormais partie de votre chaîne d’approvisionnement, vous devez la traiter comme telle et vous attendre à ce que des acteurs malveillants tentent de contaminer la chaîne d’approvisionnement de l’IA open source, comme ils ont essayé de le faire avec celle des logiciels open source. (En réalité, ces deux chaînes d’approvisionnement se recoupent largement.) Veillez tout particulièrement à identifier qui contrôle les composants et le code de l’IA open source, et à analyser régulièrement ce code pour détecter les vulnérabilités. Vous devez également surveiller les changements de contrôle des composants, les modifications inexpliquées du code ou des données, ainsi que tout autre indicateur susceptible d’introduire des risques.
Q : Le décret semble formulé de manière très générale et ambiguë, ce qui m’empêche de savoir si les futures réglementations découlant de ces directives auront des conséquences pour moi ou mon entreprise. Quel est l’intérêt de directives aussi peu claires ?
R : Lorsque de nouveaux domaines font l’objet d’un contrôle réglementaire, il est courant que les organismes de réglementation formulent leurs directives et leurs règles de manière très générale, car ils ignorent comment la situation va évoluer. Cette formulation ambiguë leur permet de conserver la souplesse nécessaire pour couvrir autant de scénarios que possible. Nous pensons qu’il en va de même pour ce décret : les règles gagneront en précision après la première vague de réglementations, lorsque davantage de cas d’usage et de scénarios commenceront à se dessiner. C’est pourquoi les organisations doivent faire preuve de prudence et adopter des politiques et des procédures plus strictes concernant les systèmes d’IA, afin de ne pas être prises au dépourvu par l’évolution de la réglementation.
Q : Quelles sont les principales conclusions pour les équipes de cybersécurité, de sécurité des applications, de conformité et d’audit ?
R : Le décret définit le terme « système d’IA » comme « … tout système de données, logiciel, matériel, application, outil ou utilitaire qui fonctionne entièrement ou en partie grâce à l’IA ». Cela inclut
« Les tests et les évaluations, y compris le suivi des performances après le déploiement, contribueront à garantir que les systèmes d’IA fonctionnent comme prévu, résistent aux utilisations abusives ou aux modifications dangereuses, sont développés et exploités de manière éthique et sécurisée, et respectent les lois et politiques fédérales applicables. » En d’autres termes, vous devez vous attendre à sécuriser vos systèmes d’IA, votre pile d’IA et tous les éléments qui l’entourent, y compris le code généré, au même niveau que le reste de votre base de code, de votre infrastructure et de votre surface d’attaque. Qu’est-ce que cela signifie pour les équipes de sécurité ?
Tout d’abord, considérez ce décret comme le coup d’envoi d’une probable course à la réglementation de l’IA. Vous devriez donc envisager de mettre en place des garde-fous et des mesures de sécurité pour protéger l’ensemble de votre infrastructure d’IA, notamment vos données, vos pipelines opérationnels et le code applicatif utilisé pour développer vos applications d’IA. Cela implique d’étendre, lorsque cela s’applique, toutes vos mesures de cybersécurité existantes à l’AIOps. Par exemple, même si votre pile d’IA évolue rapidement, analyser le code à l’aide d’outils de scan et automatiser les pratiques de sécurité, qui étaient auparavant un plus, deviennent désormais indispensables.
Ensuite, partez du principe que votre pile et vos processus d’IA feront l’objet d’un audit, ou que des audits seront exigés pour assurer la conformité juridique. Vous devrez donc mettre en place un processus et un plan de conformité pour l’IA, et documenter toutes les mesures de cybersécurité liées aux applications d’IA.
Enfin, pour le code généré par l’IA, veillez à soumettre toutes les suggestions de code de l’IA au même niveau d’examen et d’audit que n’importe quel autre code. De solides éléments montrent que les organisations qui utilisent des suggestions de code générées par l’IA gagnent en productivité et accélèrent la livraison de leur code. Il devient donc encore plus important d’effectuer des contrôles de sécurité automatisés pour suivre le rythme d’évolution toujours plus rapide de la base de code.
À retenir ? Continuez à appliquer les bonnes pratiques.
Snyk est un leader de la sécurité du code généré par l’IA. Nos solutions sont 50 fois plus rapides que les autres et effectuent des contrôles en toute discrétion, en temps réel, dans l’IDE et avec une compréhension complète du contexte applicatif. Mieux encore, elles s’intègrent à l’outil de programmation par IA générative dont votre entreprise a besoin, aujourd’hui comme demain. Sécurisez votre pile d’IA de bout en bout, en commençant par le code généré par l’IA, pour rester protégé et conforme.
Commencez à sécuriser le code généré par l’IA
Créez gratuitement votre compte Snyk pour commencer à sécuriser le code généré par l’IA en quelques minutes. Vous pouvez aussi réserver une démonstration avec un expert pour découvrir comment Snyk répond à vos besoins en sécurité des développeurs.