Valideriez-vous cette mise en production d’IA ? Un cas pratique sur les modifications après évaluation

8 novembre 2026

Par F. Jay Hall, Président-directeur général, GRC Careers

En bref : une évaluation d’intelligence artificielle (IA) ne vaut que pour la version qu’elle a testée. Si l’équipe modifie le système après une évaluation réussie, comparez le manifeste évalué à la version candidate. Classez chaque preuve : valide, périmée, manquante, en échec ou incertaine. Refaites les tests que les modifications touchent. Un seul responsable, désigné par sa fonction, valide, suspend ou fait remonter la décision. Ce cas suit une mise en production fictive, étape par étape.

Mis à jour le 8 novembre 2026. Nous avons vérifié ce jour-là toutes les sources de cette page.

Pour qui. Ce cas s’adresse aux professionnels de l’audit, de la protection des données, des risques ou de la conformité qui veulent démontrer leur jugement en assurance de l’IA. Il sert aussi aux recruteurs qui cherchent un exercice pratique équitable. Partez d’une compétence que vous exercez déjà. L’AI Assurance Engineering Skills Map (en anglais) montre comment en faire un projet de portfolio à présenter en entretien. Ce cas développe ses projets 2 (la règle de nouveau test) et 3 (le point de contrôle avant mise en production).

Sur cette page :

• un cas traité, avec chaque version et chaque responsable ;
• une décision de mise en production complète, sur une page ;
• un formulaire vierge, en PDF à imprimer et en tableur ;
• la question d’entretien et ce qu’une bonne réponse doit expliquer.

Que s’est-il passé entre l’évaluation et la demande de mise en production ?

L’équipe a évalué la version H-3 le jour 1, avec succès. Au cours des deux semaines suivantes, cinq éléments ont changé. Quatre d’entre eux peuvent modifier ce que l’assistant dit ou fait. Le jour 16, l’équipe a demandé la mise en production sous le nom H-3.1. Tout est fictif dans ce cas : Harbor Services, son système, les versions, les jours et les résultats.

Harbor Services est l’entreprise fictive du Skills Map. Son assistant documentaire interne rédige des synthèses pour le personnel à partir de documents validés. Il peut aussi créer des tickets à l’état de brouillon. Il ne peut ni approuver un paiement ni modifier une fiche client. La version H-2 est en production. Nous ne lui attribuons aucune classification de risque au sens juridique. La section sur le règlement européen sur l’IA explique ce qui changerait s’il s’agissait d’un système d’IA à haut risque.

Chronologie de Harbor (fictive) :

• Jour 1 : l’évaluation EV-H3 porte sur la version candidate H-3. Elle réussit tous les contrôles obligatoires.
• Jour 3 : l’équipe produit réécrit la consigne donnée au modèle (le prompt), de P-5 à P-6. Chaque synthèse se termine désormais par une liste d’actions. P-6 ajoute aussi deux exemples rédigés.
• Jour 6 : l’équipe données ajoute la bibliothèque des politiques de ressources humaines (RH) à l’index de recherche documentaire, de R-7 à R-8. Ses 1 400 documents portent une nouvelle étiquette d’accès, « RH restreint ».
• Jour 9 : le fournisseur du modèle fait pointer l’alias assist-large vers un instantané plus récent du modèle. La configuration de Harbor renvoie à l’alias. Le prochain déploiement utilisera donc le nouvel instantané.
• Jour 12 : les opérations demandent une nouvelle autorisation d’outil, de T-3 à T-4. L’assistant pourrait fixer la priorité des tickets et les affecter à la file d’une équipe, sans validation par le personnel.
• Jour 14 : le bouton du portail interne passe de Résumer à Rédiger une synthèse.
• Jour 16 : l’équipe demande la mise en production de H-3.1, au motif que « l’évaluation a réussi le jour 1 ».

Quelle version l’évaluation a-t-elle réellement couverte ?

L’évaluation couvre les composants inscrits dans son manifeste le jour du test. Elle ne couvre pas ce qui porte aujourd’hui le nom de la version. Le manifeste est la liste des composants et de leurs versions. Comparez-le ligne par ligne avec la version candidate. Si un composant n’y figure que sous un nom mobile, comme l’alias d’un modèle, le dossier ne prouve pas quelle version a été testée.

Exemple Harbor (fictif). Le dossier EV-H3 indique :

• modèle : alias fournisseur assist-large, sans instantané daté ;
• index de recherche documentaire : R-7 ;
• consigne : P-5 ;
• politique d’outils : T-3, qui n’autorise que des tickets en brouillon, validés un par un par le personnel ;
• politique de gouvernance : G-5 ;
• tests : jeu TS-3 (300 documents internes), 40 requêtes pièges contre les fuites d’information et la batterie de tests sur les limites d’accès des tickets.

Le titre du rapport annonce que H-3 a réussi. Le manifeste montre que H-3 désignait R-7, P-5 et T-3. Harbor peut déduire de l’avis de changement du fournisseur que le test du jour 1 a utilisé l’ancien instantané. Son propre dossier ne le prouve pas. Et H-3.1 fonctionnerait avec le nouvel instantané.

Pourquoi le manifeste compte. Une prépublication de recherche sur la réutilisation des preuves d’assurance pose deux conditions. La réutilisation n’est sûre que si les dépendances déclarées de chaque contrôle couvrent tout ce qui peut en changer le résultat. Elle suppose aussi que le point de contrôle vérifie que la preuve réutilisée décrit bien la version candidate (Mukhopadhyay et Nalla, arXiv 2610.27672, version 1, page de présentation). Les auteurs ont rejoué 38 083 commits issus de 714 chaînes publiques Data Version Control. Dans 3,3 % des cas, une étape a été réutilisée alors que son code importé ou sa configuration avait changé. Les étapes d’évaluation étaient les plus exposées (même source). L’échantillon est constitué de dépôts publics. Ce chiffre décrit donc cet échantillon et ne dit rien de direct sur les systèmes d’IA des entreprises.

Ce qu’il faut demander :

• le manifeste de l’évaluation : chaque composant avec sa version ou son empreinte, la version du jeu de test, la date d’exécution et la personne qui l’a lancée ;
• le manifeste de la version candidate, au même format ;
• une comparaison des deux, produite par un outil plutôt que de mémoire ;
• pour un modèle fourni par un tiers, l’instantané daté publié par le fournisseur. Un alias peut désigner un autre modèle demain.

Le règlement européen sur l’IA impose la même rigueur aux systèmes à haut risque. Leur documentation technique doit indiquer « la version du système, faisant apparaître sa relation aux versions précédentes » (annexe IV, point 1 a)).

Qu’est-ce qui a changé après l’évaluation ?

Cinq éléments ont changé entre le jour 1 et le jour 16. Quatre peuvent modifier ce que l’assistant dit ou fait. Le cinquième n’a aucun effet sur le modèle. Classez chaque modification selon ce qu’elle peut affecter, et non selon sa taille dans la demande de changement.

Deux sources expliquent pourquoi une nouvelle consigne ne peut pas passer sans test. La première est le profil IA générative du National Institute of Standards and Technology (NIST) américain. Il relève que la sensibilité aux consignes peut creuser l’écart entre les bancs d’essai et l’usage réel (NIST AI 600-1, annexe A.1.4, page 49). La seconde est une prépublication de novembre 2026. Huit configurations d’un même modèle y obtiennent entre 68,2 % et 70,3 % d’exactitude. Pourtant, 24,3 % des questions reçoivent une étiquette différente selon la configuration (Yorke, arXiv 2611.06655, version 1, page de présentation).

Quelles preuves restent valables ?

Une preuve reste valable si rien de ce dont elle dépend n’a changé. Elle le reste aussi si une note d’équivalence écrite montre que la modification ne peut pas l’affecter. Chez Harbor, deux preuves sur six restent valables pour H-3.1. Trois sont périmées ou manquantes. La dernière manque parce qu’une modification demandée supprime le contrôle qu’elle testait.

L’objectif de 30 minutes et la fenêtre de 90 jours sont des choix fictifs de Harbor. Aucune source citée ici ne les fixe.

Comment attribuer chaque statut :

• valable : le dossier nomme les composants exacts de la version candidate, une personne habilitée l’a produit, le résultat est positif et il reste dans sa durée de validité ;
• périmée : un élément dont dépend le test a changé depuis son exécution ;
• manquante : aucun dossier ne couvre ce contrôle pour cette version ;
• en échec : le test a porté sur cette version et n’a pas réussi ;
• incertaine : on ne sait pas de quoi dépendait le test. Laissez-le visible plutôt que de l’arrondir à « valable ».

Que faut-il tester à nouveau avant la mise en production ?

Refaites chaque contrôle obligatoire dont la preuve est périmée ou manquante, sur la version candidate exacte. Pour le reste, ne touchez à rien et notez pourquoi. Harbor refait deux tests, ajoute une revue, reporte deux tests jusqu’à la décision du comité et rédige une note d’équivalence.

Plan de Harbor (fictif) :

• Inscrire au manifeste un instantané daté du modèle, puis refaire E1 avec cet instantané, P-6 et R-8. Avant le test, définir un sous-ensemble de questions sur les politiques RH, avec sa propre règle de réussite.
• Refaire E2 avec de nouvelles requêtes pièges : demandes de documents « RH restreint » depuis des comptes extérieurs aux RH.
• Le référent protection des données examine la bibliothèque RH avant la mise en service de R-8. E5 est alors couverte.
• Reporter les nouveaux tests de E3 et E4 jusqu’à la décision du comité sur T-4. Si T-4 est abandonnée, E3 et E4 restent valables pour T-3.
• Aucun nouveau test pour le libellé du bouton. Consigner la note d’équivalence : le libellé n’est pas transmis au modèle.
• Ajouter R-8 et P-6 au manifeste de retour arrière, puis conserver E6.

Ce plan applique la règle du projet 2 du Skills Map. Si une version candidate modifie une donnée d’entrée d’un contrôle obligatoire, l’ancien résultat ne peut pas être réutilisé. Seule exception : une règle d’équivalence documentée montre que la modification ne peut pas affecter ce contrôle. Le cadre de gestion des risques de l’IA du NIST (AI RMF) classe ses attentes en quatre fonctions : gouverner (GOVERN), cartographier (MAP), mesurer (MEASURE) et gérer (MANAGE). Sa sous-catégorie MEASURE 2.3 demande de démontrer la performance dans des conditions proches du déploiement (AI RMF 1.0, page 29). Cette démonstration doit être documentée. L’ajout de la bibliothèque RH relève aussi du profil IA générative. Son action MP-4.1-008, rattachée à la fonction MAP, demande de réévaluer les risques quand on adapte un modèle à un nouveau domaine (NIST AI 600-1, page 26).

Valider, suspendre ou faire remonter la décision ?

Suspendez H-3.1, faites remonter la nouvelle autorisation d’outil et validez une version plus restreinte une fois les nouveaux tests réussis. On suspend quand le responsable de la mise en production peut combler les écarts lui-même. On fait remonter quand une modification exige une décision qui dépasse son autorité.

Ces règles sont une recommandation éditoriale de GRC Careers. Aucune norme ne les fixe.

Décision de Harbor (fictive) :

• Suspendre H-3.1 telle que demandée.
• Faire remonter T-4 au comité de gouvernance de l’IA. La politique G-5 impose une validation par le personnel pour chaque action sur un ticket. Le responsable de la mise en production ne peut pas y déroger.
• Valider H-3.2, c’est-à-dire H-3.1 sans T-4, dès que E1, E2 et E5 sont couvertes et que le manifeste de retour arrière est à jour.

Scinder la mise en production permet de livrer ce que les preuves couvrent et de confier le reste à ceux qui peuvent en décider. L’AI RMF du NIST décrit ce moment comme la décision de poursuivre ou non le développement ou le déploiement (AI RMF 1.0, MANAGE 1.1, page 32). Il cite comme réponses possibles l’atténuation, le transfert, l’évitement ou l’acceptation du risque (MANAGE 1.3, même page).

Qui porte la décision de mise en production ?

Une seule fonction décide, et le dossier la nomme avant toute signature. Chez Harbor, c’est la direction des Opérations de service. Ceux qui produisent ou examinent les preuves conseillent. Le comité ne tranche que ce qu’on lui soumet.

Rôles chez Harbor (fictifs ; ce sont des fonctions, pas des personnes) :

• Responsable de la mise en production : la direction des Opérations de service, qui signe la décision.
• Production des preuves : le responsable de l’assurance technique. Il exécute E1 et E2 et ne peut pas valider la mise en production.
• Avis protection des données : le référent protection des données, pour E5.
• Instance de recours : le comité de gouvernance de l’IA, présidé par la direction des risques. Il tranche sur T-4 et sur toute modification de la politique G-5.
• Contrôle indépendant : l’audit interne examine ensuite un échantillon de dossiers de décision. Il ne signe pas la mise en production.

Ce dernier point reprend la note d’indépendance du Skills Map. L’audit interne peut conseiller sur la conception des contrôles. Le management opérationnel reste propriétaire du contrôle et accepte le risque métier. L’AI RMF du NIST demande que les rôles, les responsabilités et les circuits de communication sur les risques de l’IA soient documentés et clairs. Il demande aussi que la direction générale assume les décisions sur les risques liés au développement et au déploiement de l’IA (AI RMF 1.0, GOVERN 2.1 et GOVERN 2.3, page 23). Il prévoit enfin que des experts internes extérieurs au développement, ou des évaluateurs indépendants, participent aux évaluations régulières (MEASURE 1.3, page 29).

À quoi ressemble une décision de mise en production complète sur une page ?

Elle nomme le manifeste évalué, chaque modification ultérieure, le statut de chaque preuve, la décision, ses conditions, son responsable et les événements qui la rouvriraient. Voici le dossier signé le jour 16 par la direction des Opérations de service de Harbor. Tout y est fictif.

Télécharger cet exemple complété (PDF, une page)

S’agit-il d’une « modification substantielle » au sens du règlement européen sur l’IA ?

Seul un système d’IA à haut risque peut déclencher la règle sur la modification substantielle. Il faut en outre que la modification intervienne après la mise sur le marché ou la mise en service. L’assistant de Harbor n’est pas classé : la règle ne s’applique pas à ce cas. S’il s’agissait d’un système à haut risque déjà en service, une modification substantielle imposerait une nouvelle procédure d’évaluation de la conformité.

Ce que dit la version consolidée du 27 juillet 2026, qui intègre les modifications du règlement (UE) 2026/1744 :

• Définition : une modification apportée après la mise sur le marché ou la mise en service. Elle n’est « pas prévue ou planifiée dans l’évaluation initiale de la conformité ». Elle nuit à la conformité aux exigences du chapitre III, section 2, ou modifie la destination évaluée (article 3, point 23).
• Conséquence : un système à haut risque déjà évalué repasse une procédure d’évaluation de la conformité en cas de modification substantielle. La règle vaut qu’il soit distribué plus largement ou reste chez le déployeur actuel (article 43, paragraphe 4, premier alinéa).
• Modifications prévues : certains systèmes à haut risque continuent d’apprendre. Pour eux, les modifications déterminées au préalable par le fournisseur ne sont pas substantielles. Elles doivent figurer dans la documentation technique (article 43, paragraphe 4, second alinéa, et annexe IV, point 2 f)).
• Qui devient fournisseur : un distributeur, un importateur, un déployeur ou un autre tiers peut modifier substantiellement un système à haut risque déjà sur le marché ou en service. S’il reste à haut risque, ce tiers est alors considéré comme son fournisseur (article 25, paragraphe 1, point b)).
• Dossiers : la documentation technique comprend les journaux et rapports de test, datés et signés par les personnes responsables (annexe IV, point 2 g)). Elle décrit aussi les modifications pertinentes apportées au fil du cycle de vie (annexe IV, point 6).
• Journaux : la journalisation doit permettre d’enregistrer les événements utiles pour repérer les situations susceptibles d’entraîner une modification substantielle (article 12, paragraphe 2, point a)).
• Calendrier : les exigences du chapitre III, sections 1 à 3, s’appliquent le 2 décembre 2027 aux systèmes de l’annexe III. Elles s’appliquent le 2 août 2028 à ceux de l’annexe I (article 113, point c)).
• Lignes directrices à suivre : la Commission doit publier des lignes directrices pratiques sur les modifications substantielles (article 96, paragraphe 1, point c)). Vérifiez si elles sont parues avant de vous appuyer sur une lecture de la définition.

Notre lecture, qui ne constitue pas un avis juridique. La question interne (nos preuves couvrent-elles cette version ?) et la question juridique (cette modification est-elle substantielle ?) sont distinctes. Une nouvelle consigne peut rendre une preuve de test périmée sans constituer une modification substantielle. Harbor suspendrait quand même la mise en production. Qualifier une modification de substantielle relève d’une analyse juridique, au vu des faits et du texte en vigueur à ce moment-là.

Que disent les cadres du NIST sur les modifications après évaluation ?

L’AI RMF du NIST est d’application volontaire. Il ne fixe aucune règle de nouveau test. Plusieurs de ses sous-catégories correspondent toutefois à cette décision. Son profil IA générative demande une réévaluation quand un modèle est enrichi ou transposé dans un nouveau domaine. Le NIST indique que l’AI RMF 1.0 est en cours de révision : vérifiez s’il existe une édition plus récente avant de le citer.

• MANAGE 1.1 : déterminer si le système atteint ses objectifs et si le développement ou le déploiement doit se poursuivre (AI RMF 1.0, tableau 4, page 32).
• MEASURE 2.1 et 2.3 : les jeux de test, les indicateurs et les outils sont documentés, et la performance est démontrée dans des conditions proches du déploiement (tableau 3, page 29).
• MANAGE 4.1 : les plans de surveillance après déploiement incluent la gestion des changements (tableau 4, page 33).
• MP-4.1-007 : réévaluer les modèles affinés ou enrichis à partir de modèles tiers (NIST AI 600-1, page 26).
• MP-4.1-008 : réévaluer les risques lorsqu’on adapte un modèle d’IA générative à un nouveau domaine, et prévoir des alertes quand les hypothèses antérieures ne tiennent plus (même page).
• MS-2.8-003, fonction MEASURE : les systèmes de gestion de versions permettent de suivre les changements tout au long du cycle de vie de l’IA (NIST AI 600-1, page 34).

Actualité des textes : l’AI RMF 1.0 date du 26 janvier 2023, le profil IA générative du 26 juillet 2024. Le 8 novembre 2026, la page de l’AI RMF sur le site du NIST indiquait que l’AI RMF 1.0 est en cours de révision dans le cadre du plan d’action de la Maison-Blanche sur l’IA.

Nous ne rattachons pas cet exercice aux clauses de la norme ISO/IEC 42001. Pour son articulation avec le règlement, voir notre comparaison entre ISO/IEC 42001 et le règlement européen sur l’IA (en anglais).

Quelles compétences ce cas démontre-t-il en audit, protection des données, risques et conformité ?

Il démontre que vous savez vérifier si une preuve correspond à ce qui part réellement en production. C’est un jugement que l’audit, la protection des données, les risques et la conformité exercent déjà. Partez de votre propre métier et montrez au recruteur la partie du cas qui le prouve.

Le vocabulaire officiel du règlement figure dans notre lexique anglais-français de l’IA et du règlement général sur la protection des données (RGPD). Notre glossaire de la gouvernance, des risques et de la conformité (GRC) de l’IA le complète. Notre article Le règlement européen sur l’IA, expliqué donne le contexte d’ensemble.

Question d’entretien : le système a réussi l’évaluation, puis il a changé. Que demanderiez-vous à voir ?

« Un système d’IA a réussi son évaluation, mais l’équipe l’a modifié ensuite. Que demanderiez-vous à voir avant de valider la mise en production ? »

Une bonne réponse explique :

• quelle version exacte l’évaluation a couverte, d’après son manifeste, avec l’instantané daté du modèle et non un alias ;
• chaque modification ultérieure, à partir d’une comparaison : consigne, données ou index, version du modèle, outils et droits, code, contexte de déploiement ;
• pour chaque preuve, si elle reste valable et pourquoi, avec une note d’équivalence écrite pour les modifications sans effet sur elle ;
• quels contrôles refaire sur la version exacte, avec des sous-ensembles définis avant le test, et pas seulement le score global ;
• qui décide, et quand la décision doit remonter au-dessus du responsable : conflit avec une politique, changement de destination ou de niveau de risque, acceptation de risque hors de son autorité, désaccord entre responsables ;
• ce qui bloquerait la mise en production, ce qui rouvrirait une validation et quel signal de surveillance révélerait un problème ensuite.

Une réponse faible dit « l’évaluation a réussi, on livre ». Ou bien elle exige de tout refaire sans dire ce qui a changé ni quels résultats la modification peut affecter.

Une question de relance. Changez un fait : le fournisseur confirme que l’instantané derrière assist-large n’a pas changé. Demandez quels statuts évoluent. Une bonne réponse indique que le modèle n’impose plus de refaire E1, mais que la consigne et l’index l’imposent toujours. E1 reste donc périmée.

Télécharger le formulaire de décision vierge

Le formulaire vierge reprend les champs du dossier de Harbor. Remplissez-le à la main ou dans le tableur, qui propose des listes déroulantes pour le statut des preuves et la décision.

• Formulaire de décision vierge (PDF, une page, format A4)
• Formulaire vierge et exemple Harbor (tableur, fichier .xlsx)
• Formulaire vierge (CSV, compatible avec tous les tableurs)
• Exemple Harbor complété (PDF, une page)

Ce formulaire est un exercice éditorial de GRC Careers. Ce n’est pas une norme, et un exemplaire rempli ne constitue pas un document de conformité.

Comment en faire une pièce de portfolio ?

Changez un fait à la fois et refaites le dossier. Un relecteur doit pouvoir reproduire votre décision à partir de la page, sans vous poser de question.

• Le fournisseur confirme que l’instantané n’a pas changé. Quels statuts évoluent ?
• Le nouveau test E2 renvoie un document « RH restreint » à un compte de la direction financière. Que devient H-3.2, et qui faut-il informer ?
• Rédigez en moins de 300 mots la note au comité sur T-4 : la demande, la politique qu’elle contredit, les options et la décision attendue.
• Ajoutez une étape d’audit : prenez trois mises en production passées et vérifiez si le manifeste de chaque évaluation correspondait à ce qui a été déployé.

Présentez le tout comme une simulation et utilisez des données synthétiques. Ne présentez jamais un exercice d’apprentissage comme un système en production ni comme une preuve de conformité juridique.

Sources et vérifications

Toutes les sources ont été vérifiées le 8 novembre 2026.

1. Règlement (UE) 2024/1689 (règlement sur l’intelligence artificielle), version consolidée du 27 juillet 2026, intégrant le règlement (UE) 2026/1744. Articles 3, point 23 ; 12, paragraphe 2, point a) ; 25, paragraphe 1, point b) ; 43, paragraphe 4 ; 96, paragraphe 1, point c) ; 113, point c). Annexe IV, points 1 a), 2 f), 2 g) et 6. Version consolidée sur EUR-Lex.
2. NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), janvier 2023. GOVERN 2.1 et 2.3 (page 23), MEASURE 1.3, 2.1 et 2.3 (page 29), MANAGE 1.1 et 1.3 (page 32), MANAGE 4.1 (page 33). NIST AI 100-1 (PDF, en anglais).
3. NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, juillet 2024. MP-4.1-007 et MP-4.1-008 (page 26), MS-2.8-003 (page 34), annexe A.1.4 (pages 48 et 49). NIST AI 600-1 (PDF, en anglais).
4. NIST, page de l’AI Risk Management Framework, pour les dates de publication et l’état de la révision. nist.gov.
5. Atanu Mukhopadhyay et Shravya Reddy Nalla, « Reusing Assurance Evidence in AI Pipelines: Validity Conditions, a Fail-Closed Release Gate, and a Replay of 714 Public Data Version Control Pipelines », arXiv 2610.27672, version 1, 20 octobre 2026. Page de présentation. arXiv, prépublication de recherche.
6. Louise Yorke, « Beyond accuracy: what AI assurance needs to establish in public services », arXiv 2611.06655, version 1, 4 novembre 2026. Page de présentation. arXiv. Une seule tâche, une seule famille de modèles.

Harbor Services, son système, ses versions, ses jours, ses résultats et ses rôles sont fictifs. Les règles de décision, le formulaire, les conseils d’entretien et les exercices de portfolio sont des recommandations éditoriales de GRC Careers.

Questions fréquentes

Une évaluation d’IA réussie reste-t-elle valable si le système change ?

Seulement pour ce que la modification ne peut pas affecter. Comparez le manifeste évalué à la version candidate. Tout résultat qui dépend d’un composant modifié est périmé, jusqu’à un nouveau test ou une note d’équivalence écrite.

Une nouvelle consigne (prompt) impose-t-elle un nouveau test ?

En général oui, pour tous les contrôles qui dépendent de la sortie du modèle. Le profil IA générative du NIST relève que la sensibilité aux consignes peut creuser l’écart entre bancs d’essai et usage réel (NIST AI 600-1, annexe A.1.4). Une modification qui n’atteint jamais le modèle, comme le libellé d’un bouton, appelle seulement une note d’équivalence.

Qui doit signer une mise en production d’IA ?

Un responsable unique, désigné par sa fonction. C’est en général le responsable métier du système. Il signe après que ceux qui produisent et examinent les preuves ont consigné leurs résultats. Une modification contraire à une politique, ou qui change la destination du système, remonte au propriétaire de cette politique, par exemple un comité de gouvernance de l’IA.

À lire également

• Emplois en gouvernance de l'intelligence artificielle à Bruxelles
• Emplois en gouvernance de l'intelligence artificielle à Paris
• Comment débuter une carrière en protection des données
• Emplois en gouvernance, risques et conformité à Genève
• Emplois en gouvernance, risques et conformité en Suisse

Tout ce que nous publions en français · Glossaire de la gouvernance de l’IA et de la GRC

Emplois liés au règlement européen sur l’IA · Tous les postes GRC

This site in English