La règle finale de la GSA sur les LLM réduit son champ d’application mais maintient les obligations des prestataires d’IA

La règle finale de la GSA sur les LLM entre en vigueur le 19 octobre 2026, avec un champ d’application plus restreint mais des obligations de conformité substantielles pour les prestataires fédéraux d’IA concernés.

La General Services Administration cible désormais les systèmes dans lesquels la fonctionnalité de grand modèle de langage constitue une caractéristique substantielle et où des données gouvernementales entrent directement dans le modèle ou en sortent. Les outils internes de back-office et les fonctions d’IA accessoires peuvent être exclus de la clause.

Ce changement répond à certaines des objections les plus fortes de l’industrie technologique face aux premières versions. Pourtant, le texte final prévaut toujours sur les accords commerciaux contradictoires, s’étend aux sous-traitants concernés et impose des règles détaillées en matière de sécurité des données, de documentation, de signalement des incidents, de modification des modèles et de clôture des contrats.

Le résultat est un compromis, non un recul généralisé. La GSA a réduit le risque que des logiciels ordinaires soient intégrés à un régime contractuel spécifique à l’IA. Les fournisseurs qui vendent de véritables produits LLM au gouvernement doivent toujours assurer un niveau de visibilité opérationnelle que de nombreux déploiements commerciaux n’exigent pas.

La règle finale de la GSA sur les LLM applique un test de champ d’application en deux volets

La clause finale se concentre sur les systèmes d’IA que le gouvernement achète intentionnellement, plutôt que sur chaque système de prestataire utilisant par hasard un LLM.

La GSA a publié la clause 552.239-7001, Basic Safeguarding of Data within Large Language Model Artificial Intelligence Systems, au moyen d’une dérogation de catégorie au General Services Acquisition Regulation. Une dérogation de catégorie permet à l’agence d’appliquer un texte d’acquisition avant d’achever sa codification conventionnelle.

Le changement figure dans la mise à jour de septembre de la GSA concernant la clause finale. Cette mise à jour s’inscrit dans RGO-2026-01, une réforme plus vaste des règles d’acquisition de l’agence.

La clause s’applique lorsque deux conditions sont réunies. Premièrement, la GSA doit acquérir un LLM, un assistant génératif, un chatbot, un système agentique, un outil de productivité activé par LLM, ou un produit similaire dont la fonctionnalité LLM est substantielle.

Deuxièmement, des données gouvernementales doivent être soumises directement au LLM ou produites par celui-ci. Cette seconde condition lie la charge de conformité aux interactions réelles avec le modèle, plutôt qu’à la simple présence d’IA quelque part dans la pile technologique d’un prestataire.

Cette approche est sensiblement plus restreinte que la proposition de juin. Le texte proposé s’appliquait généralement lorsque des données gouvernementales devaient être traitées par un LLM, une formulation susceptible d’englober des systèmes de soutien et des usages accessoires.

La clause finale contient également un mécanisme d’extinction automatique. Sauf indication contraire d’un agent contractant, elle n’impose aucune obligation lorsque l’usage du LLM reste limité à des systèmes internes d’activité, de back-office, opérationnels ou d’aide à l’exécution auxquels le gouvernement n’accède pas.

Une seconde exclusion concerne les produits commerciaux dont la fonction LLM est incidente ou accessoire. L’exclusion s’applique lorsque l’IA n’est pas la finalité principale du produit, une exigence contractuelle, une fonctionnalité accessible au gouvernement ou un processeur de données gouvernementales.

Ces distinctions sont importantes pour les prestataires qui utilisent l’IA générative tout en fournissant un autre service. Un cabinet de conseil peut utiliser un assistant interne pour faciliter l’organisation du travail sans vendre cet assistant à la GSA. Un produit logiciel conventionnel peut inclure une fonction d’IA optionnelle que l’agence n’active jamais.

Ces situations disposent désormais d’un argument plus solide en faveur de l’exclusion. Toutefois, la clause finale ne rend pas invisible tout flux de travail interne fondé sur l’IA. Les prestataires doivent toujours déterminer si des données gouvernementales entrent dans une fonction LLM achetée, accessible ou exigée contractuellement.

La définition des données gouvernementales est également devenue plus précise. Les données couvertes en entrée sont soumises par le gouvernement ou en son nom, plutôt que simplement créées pour lui. Les métadonnées et les journaux sont exclus des données couvertes en sortie.

Cet ajustement limite l’univers d’informations contrôlé par la clause. Il n’élimine pas la nécessité de cartographier les données, car les prompts, les contenus récupérés, les réponses générées, les embeddings et les matériaux de fine-tuning peuvent toujours franchir des frontières couvertes.

Les exclusions fonctionnent donc davantage comme des règles de classification que comme des exemptions générales. Les fournisseurs ont besoin d’éléments montrant ce que le gouvernement achète, aux fonctions auxquelles il accède, les parcours des données et la contribution substantielle ou non d’un LLM au service fourni.

Le texte officiel crée également un problème d’interprétation. Son paragraphe d’extinction automatique énumère l’exclusion de back-office et l’exclusion relative aux fonctions accessoires sans les relier clairement par « et » ou « ou ».

Ce choix rédactionnel laisse planer une incertitude : chaque condition retire-t-elle indépendamment la clause, ou les deux doivent-elles être réunies ? Les agents contractants pourraient devoir clarifier la réponse lors des sollicitations ou des négociations.

La leçon pratique est simple. Les prestataires ne doivent pas supposer qu’une fonction d’IA est couverte simplement parce qu’elle existe. Ils ne doivent pas non plus supposer que qualifier une fonction d’accessoire règle la question.

Un énoncé des travaux, une description de produit, une architecture système et les flux réels de données pèseront davantage qu’une étiquette produit. C’est le premier changement majeur introduit par la règle finale de la GSA sur les LLM.

Un cadre du NIST remplace quatre rôles rigides de chaîne d’approvisionnement

La GSA est passée d’étiquettes fixes pour les fournisseurs à des tâches de cycle de vie, mais les contractants principaux restent responsables de l’identification de chaque participant concerné.

La proposition de juin divisait la chaîne d’approvisionnement des LLM en quatre rôles définis : développeur, opérateur de système, intégrateur de systèmes et prestataire de services. Chaque rôle était associé à une clause complémentaire et à un ensemble prescrit d’obligations de transmission.

La transmission signifie qu’un contractant principal doit intégrer les exigences gouvernementales pertinentes dans ses accords avec les sous-traitants. Elle empêche qu’une obligation s’arrête au premier niveau contractuel lorsqu’une autre entreprise traite réellement la technologie ou les données.

La clause finale remplace ces quatre catégories formelles par des descriptions de tâches issues du cadre de gestion des risques liés à l’IA publié par le National Institute of Standards and Technology.

Les tâches référencées couvrent la conception de l’IA, le développement de l’IA, le déploiement de l’IA, ainsi que l’exploitation et la surveillance. Elles englobent notamment la définition des exigences système, la création de modèles, l’intégration de composants, la mise en production de systèmes et l’évaluation des résultats après le lancement.

Cette approche reflète mieux la façon dont les produits d’IA modernes sont assemblés. Une entreprise peut héberger un modèle, une autre fournir une infrastructure de récupération d’informations, et une troisième relier le système aux flux de travail gouvernementaux.

Une étiquette de rôle traditionnelle peut masquer ces responsabilités qui se chevauchent. Un test fondé sur les tâches examine ce que fait réellement chaque participant et s’il traite des données gouvernementales dans ce cadre.

Le contractant principal doit transmettre les exigences applicables aux sous-traitants effectuant ces tâches lorsqu’ils collectent, traitent, stockent, conservent, utilisent pour l’entraînement, utilisent pour le fine-tuning ou manipulent autrement des données gouvernementales.

Cette formulation va au-delà des développeurs de modèles. Les fournisseurs cloud, les sociétés d’hébergement, les intégrateurs de systèmes, les fournisseurs de solutions de récupération, les services d’évaluation et les partenaires d’exploitation gérée peuvent tous entrer dans la chaîne de conformité.

La clause exige des efforts raisonnables lors de la sélection et de la supervision de ces sous-traitants. Les prestataires peuvent s’appuyer sur des attestations, des preuves vérifiables de manière indépendante, des model cards, des system cards, de la documentation de sécurité, des documents d’audit et des certifications pertinentes.

Les artefacts existants peuvent satisfaire à l’exigence lorsqu’ils démontrent raisonnablement la conformité. Le prestataire n’a pas besoin de créer des documents en double uniquement pour satisfaire à la clause.

Toutefois, le contractant principal doit toujours relier ces artefacts au système couvert. Une certification de sécurité générique n’explique pas automatiquement si un fournisseur entraîne ses modèles sur des prompts gouvernementaux, conserve des sorties générées ou prend en charge une suppression requise.

Le texte final accorde un traitement particulier aux modèles entièrement ouverts et aux composants LLM open source. Les prestataires ne sont pas tenus de transmettre auxdits composants les dispositions relatives à l’origine, la propriété, la juridiction ou le contrôle étranger.

La GSA définit un modèle entièrement ouvert de manière plus stricte que l’expression vague « IA open source », souvent utilisée dans le marketing. L’architecture, les poids, le code pertinent et les jeux de données d’entraînement, de validation et de test doivent être publiquement inspectables sous des licences appropriées.

Les modèles à poids ouverts ne bénéficient pas de la même classification simplement parce que leurs paramètres sont téléchargeables. Si le code et les données correspondants restent indisponibles, la GSA traite le système différemment d’un modèle entièrement ouvert.

Cette distinction affecte la diligence raisonnable. Les composants ouverts peuvent être documentés à l’aide de poids publiquement accessibles, de rapports techniques, de documentation de modèle et de divulgations sur les données d’entraînement. Une attestation distincte et spécifique au contrat n’est pas toujours nécessaire.

Les modèles à poids ouverts nécessitent toujours un examen documenté fondé sur les meilleurs efforts. Le prestataire doit examiner la documentation du modèle, ses tests, les rapports techniques et son rôle dans l’exécution du contrat.

La structure du NIST offre aux prestataires davantage de flexibilité que la taxonomie de juin. Elle les oblige également davantage à maintenir une cartographie précise de leur chaîne d’approvisionnement.

Un fournisseur principal ne peut pas simplement attribuer une étiquette à chaque entreprise et passer à autre chose. Il doit comprendre quelles tâches du cycle de vie chaque partie effectue, quelles données gouvernementales chaque partie traite et quels paragraphes de la clause s’appliquent.

Ce travail peut devenir difficile lorsque des services d’IA commerciaux modifient leurs sous-traitants, leurs emplacements d’hébergement ou leurs familles de modèles. Les équipes contractuelles auront besoin de dossiers d’ingénierie et d’approvisionnement qui restent alignés tout au long de l’exécution.

La clause finale échange donc une catégorisation rigide contre une analyse factuelle continue. La structure est plus adaptable, mais elle n’est pas nécessairement plus légère pour les déploiements complexes.

Des protections de propriété intellectuelle élargies ne préservent pas toutes les conditions commerciales

Les prestataires conservent des droits renforcés sur les technologies préexistantes, tandis que le gouvernement donne toujours priorité à sa clause sur les accords fournisseurs contradictoires.

La propriété intellectuelle était l’un des aspects les plus contestés de l’approche antérieure de la GSA. Le projet de mars incluait une large licence gouvernementale et des restrictions qui inquiétaient les fournisseurs dont les produits reposent sur une technologie commerciale réutilisable.

La version de juin a modifié cette structure, mais les préoccupations du secteur ont persisté. La clause finale ajoute désormais une protection plus explicite pour les matériaux créés avant le contrat ou développés indépendamment pour une utilisation commerciale plus large.

Le gouvernement n’acquiert pas la propriété des produits commerciaux préexistants, de la technologie propriétaire ou des matériaux d’un prestataire utilisés auprès de plusieurs clients. Cette reconnaissance couvre les logiciels, configurations, flux de travail, documentation, modèles, scripts, méthodes techniques et savoir-faire.

Elle protège également les informations générées par le service, les analyses, les contenus de base de connaissances et les matériaux associés lorsqu’ils sont qualifiés d’actifs commerciaux préexistants ou développés indépendamment.

Cette protection reconnaît une caractéristique centrale des contrats d’IA. Les fournisseurs construisent rarement un modèle complet et une plateforme de soutien pour un seul client gouvernemental. Ils adaptent une infrastructure, des flux de travail, des évaluations et des composants techniques communs à de nombreux déploiements.

Le texte final restreint également la cession des améliorations dérivées de données gouvernementales. Les améliorations générales de capacité restent la propriété du prestataire lorsqu’elles n’incorporent pas, ne révèlent pas, ne divulguent pas et ne dérivent pas d’informations gouvernementales couvertes.

Cette exception réduit le risque que les améliorations ordinaires de plateforme deviennent automatiquement la propriété de l’État. Un fournisseur peut perfectionner une méthode générale de planification ou améliorer la fiabilité d’un système sans devoir céder ce travail au seul motif que l’apprentissage a eu lieu dans le cadre d’une mission fédérale.

La frontière devient plus difficile à tracer lorsqu’une amélioration dépend directement de données gouvernementales. Le réglage fin, les index de récupération, les jeux d’évaluation spécialisés ou les flux de travail propres à un domaine peuvent associer une ingénierie réutilisable à des informations issues du client.

Les prestataires devront documenter cette distinction avant qu’un différend ne survienne. Des référentiels séparés, des enregistrements de traçabilité des données, des inventaires de modèles et des historiques de modifications peuvent démontrer qu’une amélioration est généralisée ou spécifique au gouvernement.

La clause élargit également la notion de données préexistantes. Les prestataires peuvent conserver la propriété des informations admissibles qu’ils possèdent, contrôlent ou concèdent sous licence, y compris les éléments utilisés pour développer ou améliorer un LLM.

Le texte antérieur faisait référence aux données préexistantes dans leur forme d’origine. La suppression de cette limitation favorise le maintien de la propriété du prestataire lorsque des éléments admissibles sont modifiés ou enrichis pendant l’exécution du contrat.

Toutefois, les améliorations relatives à la propriété intellectuelle ne préservent pas toutes les conditions commerciales standard. La clause finale indique qu’elle complète les dispositions existantes du Federal Acquisition Regulation et du GSAR, tout en conservant la primauté sur les accords commerciaux contradictoires.

Cette règle peut entrer en conflit avec les contrats courants de cloud et d’IA. Les conditions standard des fournisseurs limitent souvent l’accès aux audits, prévoient des droits unilatéraux de modification des modèles, autorisent l’amélioration du service à partir des interactions clients ou définissent de larges pratiques de conservation.

Un contrat fédéral ne peut pas s’appuyer sans risque sur ces paramètres par défaut lorsque la clause de la GSA prévoit autre chose. Les titulaires principaux doivent examiner leurs accords avec les fournisseurs en amont avant de promettre leur conformité au gouvernement.

Le problème est particulièrement aigu pour les revendeurs et les intégrateurs. Ils peuvent être responsables envers la GSA d’une obligation que le fournisseur du modèle sous-jacent n’a pas accepté contractuellement.

Un revendeur peut promettre un préavis en cas de changement majeur de modèle sans recevoir d’engagement correspondant de son fournisseur. Il peut également accepter des exigences gouvernementales de suppression qui dépassent les contrôles techniques standard du fournisseur.

La protection élargie de la propriété intellectuelle ne résout donc qu’une partie du conflit commercial. Les fournisseurs bénéficient de limites de propriété plus claires, mais doivent toujours concilier les exigences gouvernementales avec les conditions opérationnelles de chaque fournisseur important.

La règle finale favorise les prestataires par rapport aux versions antérieures, mais elle ne transforme pas l’acquisition fédérale de LLM en un abonnement logiciel ordinaire.

Les contrôles des données et le signalement des incidents conservent un poids réel

Le champ d’application restreint n’affaiblit pas la clause lorsqu’un système y est soumis, en particulier lorsque des informations gouvernementales transitent par des modèles, des embeddings et des sous-traitants.

Les prestataires concernés ne peuvent pas utiliser les données gouvernementales pour entraîner ou affiner un LLM destiné à d’autres clients ou à des fins commerciales. Ils ne peuvent pas non plus les utiliser à des fins publicitaires ni les vendre à des tiers.

Ces restrictions exigent une séparation technique, et non une simple déclaration de confidentialité. Les fournisseurs ont besoin de contrôles empêchant les requêtes, sorties et contenus récupérés du gouvernement d’entrer dans les pipelines généraux d’entraînement ou d’amélioration des produits.

Le chiffrement, les contrôles d’accès, la journalisation, les limites de conservation et les procédures de suppression font tous partie des éléments attestant de la conformité. Les prestataires ont également besoin de registres indiquant où les informations résident dans leurs propres systèmes et dans les environnements de leurs sous-traitants.

La génération augmentée par récupération pose un défi particulier. Cette technique fournit à un modèle des informations externes sélectionnées au moment de la réponse, souvent par l’intermédiaire d’embeddings et de bases de données vectorielles.

Ces magasins de données auxiliaires peuvent contenir des éléments gouvernementaux même lorsque le modèle de fondation ne s’entraîne jamais dessus. Les prestataires doivent donc gérer l’application qui entoure le modèle, et pas seulement le modèle de base.

La clôture du contrat soulève une question connexe. Les embeddings pertinents, les poids affinés, les entrées stockées, les sorties et les artefacts dérivés peuvent devoir être supprimés ou restitués à la fin de la mission.

La suppression peut être difficile dans des systèmes distribués. Les sauvegardes, bases de données répliquées, pipelines de télémétrie, environnements d’évaluation et copies de reprise après sinistre peuvent conserver des données après leur suppression de l’application principale.

Un plan de clôture crédible doit identifier ces emplacements à l’avance. Attendre la fin du contrat peut révéler qu’un fournisseur ne peut pas isoler ou supprimer les informations d’un client sans perturber un système partagé.

La clause finale maintient également un délai de signalement de 72 heures pour les événements couverts. Le déclencheur est plus restreint que dans la proposition de juin, qui pouvait s’étendre à des incidents survenant n’importe où dans un vaste réseau de prestataires.

Désormais, l’incident pertinent doit affecter un LLM utilisé pour le contrat et être susceptible d’affecter la confidentialité, l’intégrité ou la disponibilité des données gouvernementales. Cela rapproche davantage l’obligation du risque contractuel réel.

Le délai de 72 heures commence lorsque le prestataire a effectivement connaissance de l’événement pertinent. Les prestataires devraient définir qui peut acquérir cette connaissance et comment l’information circule des ingénieurs ou fournisseurs vers l’équipe chargée des contrats gouvernementaux du titulaire principal.

Les rapports FedRAMP, de la Cybersecurity and Infrastructure Security Agency ou d’autres organismes fédéraux peuvent satisfaire à la clause lorsqu’ils contiennent des informations substantiellement équivalentes et parviennent simultanément à l’agent contractant.

Cette sphère de sécurité réduit les signalements en double. Elle n’élimine pas la coordination, car le prestataire doit confirmer qu’un rapport existant contient les informations attendues par la GSA.

La clause exige séparément une notification après la connaissance effective d’une violation substantielle. Une violation est substantielle lorsqu’elle cause, ou devrait raisonnablement être susceptible de causer, un préjudice important à l’exécution, aux droits du gouvernement, à la sécurité, à la confidentialité, à la conformité juridique ou à l’administration du contrat.

Cette norme exige une appréciation juridique et technique rapide. Les équipes ont besoin d’un processus d’escalade partagé, car un ingénieur peut identifier une exposition de données sans savoir encore si elle atteint le seuil de gravité prévu par le contrat.

Les changements de modèle ajoutent une autre charge opérationnelle. Le gouvernement peut s’attendre à être informé et à disposer d’un accès concernant les changements qui affectent la fiabilité, la sécurité ou l’intégrité opérationnelle.

Pour les services d’IA hébergés, les mises à jour de modèles peuvent être fréquentes et échapper au contrôle du client. Un prestataire qui dépend d’un endpoint commercial évoluant rapidement a besoin d’un préavis contractuel de son fournisseur et d’un processus pour tester le modèle mis à jour.

Ces obligations expliquent pourquoi le critère d’applicabilité plus restreint est si important. Une entreprise hors du champ de la clause évite un système de contrôle exigeant. Une entreprise qui y est soumise fait face à des obligations couvrant la sécurité, la gestion de produit, l’examen juridique, les achats et l’évaluation de l’IA.

La charge de travail des prestataires rapportée comprend un délai de divulgation de 120 jours, le signalement des incidents, la suppression à la clôture, un préavis avant les changements majeurs de modèle et des droits d’évaluation pour le gouvernement.

Tous les prestataires ne connaîtront pas chacune de ces obligations de la même manière. La conception du déploiement, les relations avec les sous-traitants, l’autorisation du système et les instructions de l’agent contractant façonneront la mise en œuvre.

Les fournisseurs concernés devraient néanmoins traiter la clause comme une exigence d’ingénierie. Un document de politique ne peut à lui seul démontrer le contrôle des pipelines d’entraînement, magasins de données, versions de modèles, journaux d’accès ou opérations de suppression.

La norme relative aux biais se resserre, mais les tests gouvernementaux demeurent

La GSA a remplacé des règles idéologiques détaillées par une norme d’efforts raisonnables, réduisant un différend de conformité sans résoudre la manière dont la qualité des modèles sera mesurée.

La proposition de juin contenait de vastes « Principes d’IA impartiale ». Elle appelait à des systèmes véridiques, neutres et non partisans tout en limitant l’influence idéologique par les données d’entraînement, les requêtes, les sources de récupération et d’autres choix de configuration.

Ces dispositions reflétaient une ordonnance fédérale sur les marchés publics de juillet 2025, qui demandait aux agences d’acquérir des LLM conformes à des principes de recherche de la vérité et de neutralité idéologique.

Des groupes industriels et des organisations de la société civile se sont demandé si ces idées pouvaient être converties en critères contractuels objectifs. Les sorties des modèles varient selon la requête, le contexte, les paramètres d’échantillonnage, les informations récupérées et la configuration du système.

La clause finale supprime l’essentiel du cadre prescriptif. À la place, les prestataires doivent déployer des efforts raisonnables pour concevoir, entraîner et configurer les LLM couverts de manière à privilégier l’exactitude, la recherche scientifique et l’objectivité lorsque les utilisateurs demandent des informations ou analyses factuelles.

Les « efforts raisonnables » constituent une norme plus souple qu’une garantie de comportement neutre. Ils reconnaissent que les modèles probabilistes ne peuvent pas promettre une exactitude parfaite ni des réponses cohérentes à chaque requête.

Le texte révisé supprime également l’interdiction explicite d’intégrer des jugements partisans ou idéologiques. Il ne crée plus le même mandat de surveillance continue spécifiquement lié à l’ancien cadre sur les biais.

Il s’agit d’une concession importante. Elle réduit le risque qu’une seule réponse contestée établisse automatiquement un manquement contractuel.

Toutefois, les efforts raisonnables doivent toujours être étayés. Les prestataires peuvent avoir besoin de plans d’évaluation, de requêtes système documentées, de résultats de benchmarks, de rapports sur les limitations connues, de cartes de modèles et de registres des mesures correctives.

Le gouvernement conserve également la capacité d’évaluer les systèmes déployés. Les prestataires ne peuvent pas supposer que leurs affirmations internes sur l’exactitude ou l’objectivité seront acceptées sans tests.

C’est ici que le cadre du NIST devient davantage qu’un vocabulaire de chaîne d’approvisionnement. Son approche du cycle de vie considère les tests, l’évaluation, la vérification et la validation comme des activités qui se poursuivent tout au long de la conception, du développement, du déploiement et de l’exploitation.

Aucun benchmark unique ne peut déterminer si un modèle généraliste est exact ou objectif. Les performances évoluent selon les domaines, les langues, les sources de récupération, les outils et les cas d’usage gouvernementaux.

Un marché portant sur le résumé de documents nécessite des tests d’omission, de fidélité des citations et de traitement des éléments restreints. Un assistant destiné au public nécessite des contrôles de factualité, de comportement de refus, d’accessibilité, de confidentialité et de conseils non étayés.

Les systèmes agentiques créent un risque supplémentaire, car ils peuvent appeler des outils ou effectuer des actions. Leur évaluation doit couvrir la logique des flux de travail et les limites d’autorisation, et pas seulement la qualité du texte généré.

La clause permet au gouvernement de suspendre à tout moment l’utilisation d’un LLM couvert. Le texte antérieur présentait la suspension de manière plus directement liée à des problèmes de performance non résolus.

Ce droit plus large crée une incertitude commerciale. Un système techniquement conforme peut tout de même subir une interruption opérationnelle pendant que l’agence enquête sur une préoccupation.

La clause finale modifie également la responsabilité liée au démantèlement. Elle rattache ces coûts à une résiliation faisant suite à un avis de non-conformité à la clause, plutôt qu’aux seules violations des anciennes dispositions sur l’IA impartiale.

La responsabilité du prestataire pour ces coûts de démantèlement est plafonnée à 25 % de la tâche ou du bon de livraison concerné. Les coûts de nouvel approvisionnement et le développement d’un système de remplacement sont exclus de ce calcul.

Le plafond offre aux fournisseurs une limite plus claire. Pourtant, une suspension ou une résiliation peut encore entraîner des atteintes à la réputation, des pertes de revenus et des dépenses d’ingénierie dépassant le montant défini pour le démantèlement.

La principale question non résolue concerne la cohérence des évaluations. Différentes agences, différents agents contractants et différentes équipes techniques peuvent utiliser des requêtes, jeux de données ou seuils distincts.

Un modèle peut obtenir de bons résultats sur un benchmark général tout en échouant dans un flux de travail gouvernemental spécialisé. Il peut aussi améliorer sa factualité tout en devenant moins utile parce qu’il refuse trop souvent.

Les prestataires doivent donc relier les évaluations au cas d’utilisation acheté. Les scores marketing généraux sont moins pertinents que les éléments démontrant le comportement de la configuration déployée face à des tâches gouvernementales représentatives.

La formulation finale évite judicieusement de promettre un état impossible de neutralité parfaite. Sa norme d’efforts raisonnables laisse néanmoins place à des différends sur les évaluations appropriées et sur le niveau de performance jugé acceptable.

Trois signaux montreront si la règle fonctionne

Le prochain test concerne la mise en œuvre : les agents contractants, les fournisseurs principaux et les fournisseurs de modèles doivent transformer cette clause en pratiques contractuelles et d’ingénierie applicables.

Le premier signal sera la manière dont la GSA applique le test de portée en deux volets après le 19 octobre. Les appels d’offres devront préciser si la fonctionnalité LLM est substantielle et si des données gouvernementales entreront directement dans le système ou en sortiront.

Des décisions claires renforceraient l’idée que la GSA a véritablement resserré la règle. L’insertion systématique de cette clause dans des contrats pour des fonctionnalités d’IA accessoires affaiblirait cette conclusion et recréerait l’incertitude que la formulation finale cherchait à éliminer.

Les prestataires doivent surveiller si les appels d’offres expliquent pourquoi la clause s’applique. Ils doivent également examiner comment les agents contractants interprètent les deux conditions d’exclusion automatique.

Le deuxième signal sera la qualité des clauses de répercussion applicables aux sous-traitants. Les fournisseurs principaux ont besoin d’accords correspondant aux tâches du cycle de vie NIST et aux données gérées par chaque fournisseur.

Les fournisseurs de modèles et les plateformes cloud subiront une pression pour proposer des conditions adaptées au gouvernement, couvrant la conservation, les restrictions d’entraînement, la notification des incidents, les modifications de modèles, l’accès aux évaluations et la suppression.

Des avenants standardisés faciliteraient la conformité pour les petits intégrateurs. Le refus des grands fournisseurs d’accepter ces conditions concentrerait les opportunités fédérales entre les mains de fournisseurs disposant d’un pouvoir de négociation accru ou d’offres spécifiquement dédiées au gouvernement.

Les modèles ouverts et à poids ouverts constituent un autre test. La clause finale distingue les modèles dont les artefacts sont entièrement publics des produits qui ne publient que leurs poids.

Les prestataires devront démontrer que leurs classifications sont techniquement exactes. Un langage marketing ambigu sur l’ouverture ne devrait pas remplacer la vérification des licences, de la disponibilité du code source, des jeux de données et de la documentation.

Le troisième signal sera la manière dont la GSA gère l’évaluation des modèles et les cas de non-conformité. Les efforts raisonnables offrent de la flexibilité, mais cette flexibilité exige des tests reproductibles et des recours proportionnés.

Les évaluations gouvernementales doivent refléter le cas d’utilisation acheté, la configuration divulguée, les éléments disponibles et les limites techniques connues. Une seule invite adversariale ne devrait pas définir automatiquement la performance d’un déploiement complexe.

Dans le même temps, les fournisseurs ne devraient pas utiliser la variabilité des modèles comme prétexte à des contrôles insuffisants. Ils peuvent documenter les suites de tests, les jeux de données d’évaluation, les seuils de revue humaine, les sources de récupération et les décisions de remédiation.

Les organisations qui préparent actuellement des offres doivent constituer un dossier de preuves avant le début des négociations contractuelles. Il devrait inclure des schémas d’architecture, des cartes de flux de données, des inventaires de sous-traitants, des calendriers de conservation, des procédures de modification de modèles, des résultats d’évaluation et des plans de clôture.

Une archive technique consultable peut aider les équipes à relier ces artefacts entre l’ingénierie, la sécurité, les achats et l’examen juridique. Le système doit néanmoins respecter les restrictions contractuelles relatives aux données gouvernementales.

La règle finale de la GSA sur les LLM est plus étroite que ses prédécesseurs, mais elle n’est pas légère. Son compromis central consiste en des limites plus claires en échange d’une responsabilité accrue lorsque le gouvernement achète délibérément un système LLM.

Pour les prestataires d’IA, la question immédiate n’est pas de savoir s’ils utilisent l’IA générative quelque part. Elle est de savoir si le gouvernement achète cette capacité, si des données gouvernementales y sont exposées et si chaque participant peut prouver sa conformité.

Avant le 19 octobre, les fournisseurs devraient tester cette réponse au regard de leur architecture et de leurs contrats réels. Si un fournisseur modifiait son modèle demain, le fournisseur principal pourrait-il identifier l’impact, notifier la GSA, préserver les preuves et protéger les données gouvernementales sans improviser ?