Red Hat a lancé asago, un projet communautaire open source qui vise à transformer la politique de gouvernance de l’IA en code de déploiement prêt pour la production.
Le projet se décrit comme un flux de travail automatisé et vérifiable qui relie les « étapes, outils et exigences fragmentés » des équipes d’ingénierie et de conformité. Avec l’entrée en vigueur de réglementations telles que la loi européenne sur l’IA, Red Hat définit le choix auquel les organisations sont confrontées comme suit : soit réduire l’innovation en matière d’IA au moyen d’un examen manuel, soit laisser les agents non gouvernés fonctionner en production sans que personne ne vérifie leur comportement par rapport à la politique.
asago s’appuie sur le travail de Red Hat et de NVIDIA au sein de l’Open Secure AI Alliance. Il est publié sous la licence Apache 2.0 et le projet est actuellement dans sa phase de formation, avec un référentiel ouvert sur GitHub pour que les développeurs, les chercheurs universitaires et les premiers utilisateurs d’entreprises puissent l’examiner et contribuer à la gouvernance.
Quatre étapes depuis le texte de la politique jusqu’à l’exécution des contrôles
Le flux de travail décrit par Red Hat s’exécute en quatre étapes. La cartographie des risques vient en premier : le cadre lit la politique de gouvernance téléchargée par une organisation et mappe ses exigences spécifiques par rapport aux cadres établis, notamment le NIST AI RMF, l’OWASP LLM Top 10 et l’EU AI Act catalogués via l’IA Risk Atlas d’IBM. Le langage politique devient automatiquement un profil de risque, plutôt que par le biais de références croisées manuelles effectuées par une équipe de conformité.
À partir de là, Asago passe à l’évaluation des risques. Le projet génère et exécute des scénarios adaptés au cas d’utilisation spécifique, en recherchant les comportements nuisibles signalés par sa cartographie des risques plutôt que de les tester par rapport à une liste de contrôle standard. L’atténuation des risques s’ensuit : le système recommande des garde-fous en fonction de ce que les tests ont fait ressortir et construit une piste de justification destinée à survivre à l’examen minutieux d’un évaluateur.
asago orchestre les contrôles recommandés dans des configurations prêtes au déploiement pour les environnements de cloud hybride et Kubernetes, selon Red Hat, éliminant ainsi le codage manuel de l’infrastructure qui se situerait autrement entre une recommandation d’atténuation et un contrôle en cours d’exécution. L’objectif déclaré de Red Hat est de réduire les délais de déploiement de quelques mois à quelques jours.
Piste d’audit en tant que produit
Chaque étape est censée alimenter une piste d’audit unique et continue. Chaque clause de stratégie est liée à un test spécifique et chaque test est lié à un contrôle d’exécution. En principe, un réviseur peut retracer tout contrôle actif dans un déploiement en direct jusqu’à la ligne politique qui l’a justifié.
Cette traçabilité est le véritable argument de vente. Le propre cadre de Red Hat traite la sécurité de l’IA moins comme un exercice de certification ponctuel que comme un utilitaire d’entreprise continu (c’est-à-dire quelque chose qui reste vérifiable à mesure que les agents continuent de fonctionner, et pas seulement au moment où ils sont approuvés pour la première fois.)
Steven Huels, vice-président de l’ingénierie IA chez Red Hat, déclare : « À mesure que les organisations passent de pilotes d’IA expérimentaux à des agents autonomes de longue durée, l’établissement de garde-fous opérationnels clairs devient une exigence essentielle en matière d’infrastructure. »
Huels se connecte à asago à l’initiative Lightwell de Red Hat, qui se concentre sur la sécurisation de la chaîne d’approvisionnement open source contre les vulnérabilités liées à l’IA, qualifiant asago de « prochaine étape logique pour l’IA d’entreprise en automatisant le lien entre les définitions de politique d’entreprise et les agents de production en direct ».
Stuart Battersby, architecte de la sécurité de l’IA et de l’évaluation des modèles chez Red Hat, est plus direct sur la forme prévue du projet : « Le projet asago est une véritable entreprise collaborative et open source réunissant des parties prenantes de l’industrie technologique, du monde universitaire et du gouvernement.
« Nous encourageons davantage de collaborateurs à se joindre à cet effort communautaire, en particulier dans les juridictions mondiales, pour garantir une couverture maximale des points de vue sur la sécurité de l’IA. »
Une liste de contributeurs majeurs, pas un seul fournisseur
La liste fondatrice est bien plus large que Red Hat et NVIDIA. Brave Software, IBM Research, Microsoft, le laboratoire MIT Lincoln, l’université d’État de Caroline du Nord et l’institut Alan Turing figurent tous parmi les contributeurs, aux côtés de la coalition EvalEval et de l’université interdisciplinaire de transformation autrichienne (IT:U). Alquimia AI, partenaire plutôt qu’institution de recherche fondatrice, est également citée.
Sarah Bird, directrice des produits pour l’IA responsable chez Microsoft, commente : « La plupart des défis les plus difficiles en matière de sûreté et de sécurité de l’IA ne sont toujours pas résolus, et aucune organisation ne peut les relever seule. »
Les voix académiques poussent une ligne similaire sous un angle différent. Veena Misra, de NC State, doyenne par intérim du College of Engineering, qualifie la sécurité de l’IA de « problème d’ingénierie autant que de problème politique ».
Les résultats d’asago sont censés être indépendants de l’infrastructure : des configurations déclaratives pour Kubernetes, Terraform et Ansible, selon Red Hat, de sorte qu’une posture de sécurité définie dans un cloud n’a pas besoin d’être réorganisée dans un autre.
Rien dans le projet n’est encore testé en production. Il n’y a aucune étude de cas client déployée dans l’annonce de Red Hat, aucun benchmark montrant que l’affirmation « jours, pas mois » résiste à un audit réglementaire en direct, et aucune indication sur la manière dont les différends entre les organisations contributrices sur les normes de cartographie des risques sont résolus une fois que le code a dépassé sa formation.
Pour l’instant, le projet existe sous la forme d’un référentiel et d’une structure de gouvernance sur GitHub, ouvert aux développeurs, aux chercheurs et aux équipes d’entreprise souhaitant s’appuyer sur une liste de contributeurs plutôt que d’adopter un produit fini.
