Traiter la conformité de l’IA comme une étape finale consistant à cocher la case est un échec. Pour suivre le rythme, nous devons intégrer la gouvernance directement dans le pipeline d’ingénierie lui-même.
J’ai passé des années à assurer la conformité des produits de sécurité. Autorisations FedRAMP et Department of War Impact Level, pipelines de gestion des vulnérabilités : ils suivent tous le même modèle. Créez le produit, puis prouvez qu’il répond aux exigences. La couche de conformité se situe en dehors du flux de travail d’ingénierie. Il passe en revue ce qui existe déjà.
Ce modèle fonctionnait lorsque le produit restait statique entre les audits. Ça casse pour l’IA.
Les systèmes d’IA changent même si le modèle de base ne change pas. Un index de récupération est mis à jour du jour au lendemain. Un nouvel outil est ajouté à l’espace d’action d’un agent. Une évaluation adoptée mardi ne reflète plus ce que fait le système jeudi. L’approche de conformité en tant que révision suppose que l’élément que vous révisez reste inchangé entre les cycles de révision. Pour l’IA, cette hypothèse est fondamentalement fausse. La plupart des organisations avec lesquelles je parle essaient encore de gouverner l’IA de la même manière qu’elles gouvernent les logiciels traditionnels : construisez-la, expédiez-la, puis demandez au service juridique de cocher la case. Pour l’IA, cela laisse le processus de publication aveugle à ce qui est le plus susceptible de changer.
Lorsque j’ai commencé à rechercher comment d’autres pays gèrent ce problème pour mon prochain livre sur l’écosystème chinois de l’IA, j’ai découvert quelque chose qui remettait en question mes hypothèses. Les entreprises chinoises d’IA ne considèrent pas la gouvernance comme une porte qu’elles franchissent une fois le modèle fonctionnel. Ils le traitent comme une infrastructure de publication : des points de contrôle de conformité intégrés dans le pipeline de déploiement lui-même. Pas de dédouanement aux points de contrôle, pas de lancement de produit. La couche de gouvernance n’examine pas le produit. Cela fait partie du produit.
Lors d’une revue de déploiement d’IA à laquelle j’ai participé, l’équipe produit disposait de tout ce que la réunion de lancement récompense habituellement : des mesures de performances, des cas d’utilisation client, des chiffres de latence et une date de sortie ferme. Les pièces manquantes ne figuraient sur la liste de contrôle de personne. Personne ne pouvait pointer vers un enregistrement actuel, généré par le pipeline, de l’index de récupération alimentant le modèle. Personne n’était propriétaire des seuils de surveillance des résultats. Personne n’avait lié les résultats de l’évaluation du modèle à une procédure de libération exécutoire. L’équipe n’ignorait pas la gouvernance. La gouvernance n’avait tout simplement pas sa place dans le processus de publication lui-même.
La couche de révision échoue déjà
Cette scène n’est pas inhabituelle. Lorsque la gouvernance se situe en dehors du flux de travail d’ingénierie, elle entre en concurrence avec les délais de livraison. Les délais de livraison gagnent à chaque fois. Le cadre de gestion des risques liés à l’IA du NIST identifie la gouvernance, la cartographie, la mesure et la gestion comme fonctions essentielles pour les risques liés à l’IA, mais il ne prescrit pas où se situent ces fonctions dans un processus de publication. Cela laisse la difficile question architecturale à l’organisation de la sécurité. La plupart des entreprises s’en remettent par défaut à ce qu’elles connaissent : un cycle d’examen périodique emprunté à la conformité informatique traditionnelle. Ce cycle a été conçu pour les systèmes qui restent immobiles entre les audits.
Les systèmes d’IA ne restent pas immobiles. Un modèle affiné sur les données clients du dernier trimestre produit différents résultats une fois que les données de ce trimestre entrent dans le pipeline. Un système de génération augmentée par récupération renvoie des réponses différentes selon les documents qui se trouvent dans son index aujourd’hui par rapport à hier. Un flux de travail agentique qui enchaîne trois modèles produit des comportements émergents qu’aucune évaluation de modèle unique ne capture. La gouvernance en tant qu’examen périodique a été conçue pour un monde dans lequel l’artefact examiné ne change pas. Nous déployons des artefacts qui changent continuellement.
L’écart entre la rapidité avec laquelle les systèmes d’IA évoluent et la lenteur avec laquelle les cycles de gouvernance des couches de révision fonctionnent constitue la principale vulnérabilité. Chaque semaine, cet écart se creuse, les organisations accumulent des dettes de gouvernance qu’elles devront éventuellement rembourser, soit selon leurs propres conditions, soit selon celles d’un régulateur.
À quoi ressemble l’infrastructure de publication dans la pratique
Lorsque j’ai étudié le processus de déploiement de l’IA en Chine, je m’attendais à trouver un système d’approbation sévère qui ralentissait les entreprises. J’ai trouvé le contraire.
La Chine exige que les entreprises déployant l’IA générative remplissent une déclaration réglementaire avant que leur produit n’atteigne les consommateurs. Le dépôt exige une documentation des sources de données de formation, des mécanismes de sécurité du contenu, des contrôles de sortie et des divulgations destinées aux utilisateurs. Les entreprises qui autorisent le processus sont expédiées. Les entreprises qui ne le font pas attendent.
Ce qui m’a surpris, c’est la vitesse. Baidu a lancé Ernie Bot au public le 31 août 2023, seize jours après l’entrée en vigueur des règles chinoises sur l’IA générative. Des dizaines d’entreprises ont suivi en quelques semaines. Le processus de dépôt n’a pas arrêté le déploiement. Il a trié les entreprises selon celles qui avaient déjà mis en place le système de preuves à transmettre. Les entreprises qui considéraient la conformité comme un exercice juridique du dernier kilomètre ont pris du retard.
Cette découverte est importante pour les dirigeants occidentaux en matière de sécurité. Nous ne devrions pas reproduire le modèle réglementaire chinois. Le problème opérationnel sous-jacent est cependant identique. La loi de l’UE sur l’IA arrive à la même conclusion à partir d’une tradition réglementaire différente : ses exigences en matière d’évaluation de la conformité et de gestion continue des risques pour les systèmes d’IA à haut risque supposent une conformité continue et non une certification ponctuelle. La question opérationnelle que partagent les deux cadres est la même que celle à laquelle je suis confronté dans mon propre travail : où se situe réellement la gouvernance dans le processus de développement ? Si la réponse est « après la formation du modèle et avant sa livraison », vous avez recréé le goulot d’étranglement de la couche de révision. Les équipes d’ingénierie trouveront des moyens de contourner ce problème.
J’ai vu le même schéma avec les SBOM. Lorsque les équipes ont traité le SBOM comme un document assemblé pour un questionnaire client, il a vieilli presque immédiatement. Lorsqu’ils l’ont généré à partir du pipeline de construction, il est devenu une partie intégrante du dossier d’exploitation du produit. La documentation du modèle doit évoluer de la même manière. Une carte modèle écrite à la main après sa sortie est un instantané. Une carte modèle générée à partir du pipeline en est la preuve.
Trois changements que les responsables de la sécurité devraient opérer dès maintenant
J’ai commencé à appliquer ce principe dans mon propre travail et dans la façon dont je conseille les équipes évaluant l’état de préparation au déploiement de l’IA. Trois équipes opérationnelles font la différence.
Tout d’abord, déplacez la documentation du modèle dans le pipeline CI/CD. Traitez les fiches modèles, les enregistrements de provenance des données de formation et les lignes de base de comportement de sortie de la même manière que vous traitez les SBOM : comme des artefacts générés automatiquement pendant le processus de création, et non comme des documents rédigés par un analyste de conformité après coup. Si la documentation de votre modèle n’est pas versionnée avec votre code, elle est déjà obsolète. Chaque cycle de recyclage du modèle qui ne produit pas d’artefacts de conformité mis à jour élargit votre écart de gouvernance.
Deuxièmement, faites des preuves de conformité une porte de déploiement plutôt qu’un élément d’audit post-lancement. Votre pipeline de versions bloque probablement déjà le déploiement si les tests unitaires échouent ou si une image de conteneur comporte une vulnérabilité critique. Ajoutez des points de contrôle de gouvernance de l’IA à ce même pipeline. Le modèle comporte-t-il une évaluation actuelle des risques par rapport aux seuils définis par votre organisation ? Le traçage des données de formation est-il documenté et traçable ? Les contrôles de sortie sont-ils configurés, testés et surveillés ? Si la réponse à l’une de ces questions est non, le déploiement ne se poursuit pas. Le pipeline bloque déjà les conteneurs vulnérables. Les points de contrôle de gouvernance de l’IA appartiennent à la même couche. Il s’agit d’étendre votre architecture de sécurité existante pour couvrir une nouvelle classe de risques.
Rien de tout cela ne nécessite d’attendre une réglementation. Les organisations qui seront les mieux placées lorsque les mandats de conformité spécifiques à l’IA arriveront, qu’il s’agisse du calendrier d’application de la loi européenne sur l’IA, de la législation émergente au niveau des États américains du Colorado et de la Californie ou des règles spécifiques au secteur des régulateurs financiers et de la santé, sont celles qui intègrent désormais la gouvernance dans leur infrastructure de publication. Ceux qui le traitent encore comme une couche de révision se démèneront pour moderniser ce que leurs concurrents proposent déjà.
J’ai appris cette leçon en étudiant comment un système très différent a d’abord résolu ce problème. Les traditions réglementaires sont différentes. La logique opérationnelle est la même : la gouvernance fournie avec le produit l’emporte sur la gouvernance qui l’examine après coup.
Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?
