Rapport d'écart de rémédiation avant le lancement dans l'UE

Pourquoi un rapport d’écart est important avant le lancement

Lorsque vous vous préparez à publier un système d’intelligence artificielle dans l’UE, vous devez démontrer que vous avez rempli les obligations énoncées dans l’Acte sur l’IA. Un rapport d’écart transforme ces exigences légales en une liste concrète de tâches que vous avez terminées et de tâches qui restent à accomplir. Cette liste est utile pour les équipes internes, les auditeurs et les organismes de régulation car elle montre exactement où des efforts sont nécessaires. Il ne promet pas la conformité ; il montre simplement l’état actuel des efforts.

Nous commençons par lire le texte officiel de l’Acte et les lignes directrices relatives de la Commission européenne. Chaque obligation est copiée textuellement dans une colonne de feuille de calcul. À côté de chaque obligation, nous ajoutons une colonne pour les preuves (telles qu’un document de politique, un résultat de test ou un commentaire de code). Si la colonne de preuves est vide, nous marquons la ligne comme un écart. Le tableau résultant devient la liste de travail qui conduit à la remediation.

Puisque l’Acte est rédigé dans un langage juridique, nous traduisons chaque phrase en actions simples. Par exemple, “fournir des informations claires sur les capacités du système d’IA” devient “créer une description destinée aux utilisateurs qui liste les types d’entrée, les formats de sortie et les limites connues”. Cette étape de traduction prévient les interprétations erronées et facilite l’attribution de propriétaires. Les outils tels que ClauseGuard et les directives de l’UE sur l’intelligence artificielle peuvent également être utiles pour garantir la conformité et la sürété. De plus, les agents tels que peuvent aider à la création et à la gestion de systèmes d’IA.

Comment nous cartographions les obligations de l'Acte aux contrôles techniques

La cartographie est l'activité principale qui transforme le texte juridique en travail d'ingénierie. Nous utilisons un tableau à trois colonnes : Obligation, Contrôle, Preuve. La colonne Obligation contient le libellé exact de l'Acte. La colonne Contrôle liste les mesures techniques ou procédurales concrètes que nous avons mises en place pour satisfaire ce libellé. La colonne Preuve contient une référence à un artefact (un lien de document, un journal de tests ou un fichier de configuration).

Ci-dessous se trouve un exemple du tableau que nous maintenons. Il montre un sous-ensemble d'obligations liées à la transparence et à la gouvernance des données. Le tableau est conservé dans une feuille de calcul partagée afin que les équipes produit, juridique et ingénierie puissent le mettre à jour en temps réel.

Obligation (libellé de l'Acte) | Contrôle (ce que nous faisons) | Preuve (artefact) Les fournisseurs doivent s'assurer que les personnes physiques sont informées qu'elles interagissent avec un système d'IA (Article 13(1)). | Ajouter une bannière persistante sur l'interface de chat qui indique "Vous parlez à un assistant d'IA". | Capture d'écran de la bannière dans l'environnement de préproduction (lien : internal/wiki/ai-banner).

Les fournisseurs doivent rendre disponibles, de manière claire et accessible, des informations sur les capacités et les limites du système d'IA (Article 13(2)). | Publier une carte de modèle qui répertorie l'utilisation prévue, les modes de défaillance connus et les métriques de performance. | Carte de modèle PDF stockée dans le référentiel de conformité (chemin : docs/model-card-v2.pdf).

Les fournisseurs doivent mettre en œuvre des mesures de gouvernance des données appropriées pour garantir que les données de formation sont pertinentes, représentatives et exemptes d'erreurs (Article 10(1)). | Exécuter un script de qualité des données chaque nuit qui vérifie les valeurs manquantes, les incohérences d'étiquetage et les échantillons hors distribution. | Journal de sortie du script pour la dernière...

Le tableau permet de voir facilement quelles obligations ont des preuves et lesquelles n'en ont pas. Les lignes de preuve manquantes deviennent les éléments de la liste de travail de remédiation. Nous examinons le tableau à chaque réunion de planification de sprint et attribuons des propriétaires pour combler les lacunes.

Construire la liste de travail : les étapes que nous suivons

Notre processus pour transformer l'Acte en une liste de travail consiste en cinq étapes répétables. Chaque étape est effectuée par une petite équipe multifonctionnelle qui comprend un analyste juridique, un responsable de produit et un ingénieur.

- Collecter les textes sources – télécharger la version officielle du Journal de l'Acte, les FAQ de la Commission, et toutes les normes pertinentes (par exemple les OWASP LLM Top 10 ou le NIST AI RMF). Les stocker dans un dossier en lecture seule. - Extraire les obligations – copier chaque phrase qui impose une obligation aux fournisseurs dans une liste maîtresse. Utiliser les termes exacts ; ne pas paraphraser à ce stade. - Traduire en actions – pour chaque obligation, écrire une phrase impérative courte qui décrit ce qui doit être fait pour la satisfaire. Garder la traduction sous 20 mots lorsque possible. - Associer aux contrôles – examiner les politiques, le code et la documentation existants pour voir si certains répondent déjà à l'action traduite. Si une correspondance existe, relier les preuves ; si ce n'est pas le cas, signaler un écart. - Donner la priorité aux écarts – attribuer une priorité en fonction du niveau de risque (élevé, moyen, faible) et de l'estimation d'effort (petit, moyen, grand). Les écarts à haut risque et à faible effort sont traités en premier.

Nous répétons le cycle chaque fois que l'Acte est modifié ou lorsque nous publions une nouvelle version du modèle. La liste maîtresse est stockée dans une page Confluence qui ne peut être modifiée que par le responsable de la conformité, garantissant ainsi une source unique de vérité.

Exemple : obligations de transparence (Article 13)

L'article 13 se concentre sur la garantie que les utilisateurs savent qu'ils interagissent avec un système d'IA et comprennent ce qu'il peut et ne peut pas faire. Pour satisfaire cela, nous avons pris trois mesures concrètes.

Premièrement, nous avons ajouté un avertissement visible à chaque point de terminaison orienté utilisateur. L'avertissement apparaît avant la première interaction et reste jusqu'à ce que l'utilisateur le supprime. Il contient la phrase exacte requise par l'Acte : "Vous interagissez avec un système d'IA". Le texte de l'avertissement est stocké dans le fichier de chaînes d'interface utilisateur (chemin : src/i18n/en.json) et est vérifié par notre suite de tests d'interface utilisateur automatisée.

Deuxièmement, nous avons créé une carte de modèle qui résume l'utilisation prévue du modèle, les limitations connues et les numéros de performance. La carte suit le format suggéré dans le guide de transparence OWASP LLM Top 10. Elle est hébergée sur notre site de documentation interne et est liée à partir de la page d'aide du produit.

Troisièmement, nous avons mis en place un examen trimestriel où l'équipe de produit vérifie que l'avertissement apparaît toujours après chaque version de l'interface utilisateur et que la carte de modèle reflète la dernière version. Toute déviation crée un nouvel élément d'écarts qui est ajouté à la liste de travail.

Exemple : Obligations de gouvernance des données (Article 10)

L'article 10 exige que les fournisseurs s'assurent que les données utilisées pour la formation sont appropriées et qu'ils documentent les étapes prises pour résoudre les problèmes de biais. Nous répondons à ces exigences grâce à une combinaison de vérifications automatisées et de documentation manuelle.

Nous exécutons un pipeline de qualité des données chaque nuit qui analyse l'ensemble de formation pour détecter les valeurs manquantes, les entrées en double et les erreurs d'étiquetage. Le pipeline est construit à l'aide de composants open-source et est configuré pour provoquer une erreur de construction si un seuil critique est dépassé. Les journaux du pipeline sont archivés dans notre bucket de conformité (chemin : gs://clauseguard-compliance/data-quality/).

Pour atténuer les biais, nous maintenons un registre vivant qui répertorie chaque intervention que nous avons appliquée, telle que le rééchantillonnage de groupes sous-représentés ou l'ajustement des poids de perte. Le registre inclut la date, la raison du changement et l'impact mesuré sur les métriques d'équité. Ce registre satisfait à l'exigence de documentation et est examiné par le conseil d'éthique avant chaque sortie de modèle.

Nous nous référons également au cadre de référence de l'AI de NIST (NIST AI RMF) lors de la sélection de contrôles pour la gouvernance des données.

Ce que ce n'est pas

Ce rapport d'écart n'est pas un certificat de conformité. Il ne garantit pas que le système d'intelligence artificielle répond à toutes les exigences de la loi. Il ne promet pas que les autorités de régulation accepteront les preuves que nous fournissons. Il ne prétend pas avoir un taux de succès de 100 % dans la détection de chaque écart possible. Il ne déclare pas que la liste de travail ne manquera jamais un problème. Il s'agit simplement d'un enregistrement transparent de ce que nous avons fait et de ce que nous devons encore faire, sur la base des sources que nous avons consultées.

Comment nous tenons le rapport à jour

Maintenir un rapport de lacunes précis nécessite des mises à jour régulières. Nous avons mis en place un rythme léger qui s'intègre dans notre cycle de sprint existant.

Au début de chaque sprint, le responsable de la conformité exécute un script qui compare la version actuelle de l'Acte (téléchargée du portail officiel de l'UE) avec la liste maîtresse des obligations. Les phrases nouvelles ou modifiées sont ajoutées en tant que nouvelles lignes. Le script vérifie également les liens de preuve pour voir si certains ont été déplacés ou sont devenus indisponibles ; les liens cassés sont signalés au propriétaire responsable.

Lors de la rétrospective du sprint, l'équipe examine la liste des lacunes et marque les éléments comme terminés lorsque les preuves associées sont téléchargées et vérifiées. Les éléments terminés sont déplacés vers un onglet d'archive afin qu'ils restent accessibles pour les audits mais ne gênent pas la vue active.

Tous les trimestres, nous organisons une réunion de révision formelle avec les responsables juridiques, produits et techniques. Lors de cette réunion, nous passons en revue les lacunes à haute priorité, confirmamos les estimations d'effort et ajustons les délais si nécessaire. Le résultat de la réunion est une brève note de mise à jour qui est ajoutée à la page Confluence.

Références

- OWASP LLM Top 10 pour les applications de modèles de langage à grande échelle - Cadre de gestion des risques liés à l'IA de NIST