Comment prouver la gouvernance d’une IA dans un appel d’offres ?

Identité de l’usage

Liez la question à un seul cas d’usage défini

Conservez ensemble le texte exact, les définitions, la règle citée, le numéro, le lot, le format, la pièce exigée et le moment où l’affirmation doit être vraie. Équitable, explicable, sûr ou supervisé ne désignent pas un test universel. Distinguez propriété actuelle du produit, processus de l’entreprise, engagement contractuel, action de l’acheteur et conclusion juridique.

Décrivez un travail borné: utilisateur, personnes affectées, entrée, sortie, influence, conséquence et usages exclus. Suggérer l’ordre d’inspection de fuites n’est ni commander une vanne, ni interrompre un service, ni approuver un investissement. La preuve du premier usage ne doit pas couvrir silencieusement les trois autres.

Figez l’offre avec entité candidate, édition, fonctions, modèle et règle de mise à jour, instructions, sources, outils, journalisation, validation humaine et secours. Si un réglage sera choisi après attribution, indiquez le décideur, la règle de choix et la recette encore due. Ne décrivez pas ce futur état comme présent.

Frontière du système

Cartographiez le système entier et ses fournisseurs

Suivez l’événement jusqu’à l’action terrain. Incluez collecte, contrôle du capteur, rapprochement, règles fixes, modèle, carte de réseau, post-traitement, file, écran, alerte, décision humaine et mode dégradé. Deux produits utilisant le même modèle peuvent répondre différemment. L’offre porte sur l’ensemble configuré.

Pour chaque élément, consignez entité juridique, fonction, version ou politique de changement, entrée, sortie, réglage client, responsabilité d’essai, signal de suivi et panne. Séparez concepteur du modèle, intégrateur, régie qui déploie et agent qui exploite. Les rôles juridiques viennent après ces faits.

Distinguez apprentissage du fournisseur, consignes du candidat, données patrimoniales de la régie et événement courant. Précisez quelle source influence le score, comment elle évolue et comment un conflit ou une indisponibilité est traité. Cette explication fonctionnelle peut être contrôlée sans publier les détails sensibles.

Obligations applicables

Faites valider la qualification avec sa source et sa date

Le nom commercial ne détermine pas le droit applicable. Dans le règlement européen sur l’IA, la qualification dépend du système réel, de sa finalité, du rôle et du contexte. Les dates et textes d’application continuent d’évoluer. Enregistrez le texte en vigueur, le statut des lignes directrices, les faits, l’auteur de l’avis, la date, les hypothèses et les déclencheurs de révision.

Séparez obligation et cadre volontaire. Le NIST AI RMF 1.0, en cours de révision, est volontaire et lié au contexte. ISO/IEC 42001:2023 encadre un système de management; ISO/IEC 23894:2023 guide la gestion des risques. Ils peuvent organiser le travail dans leur périmètre. Ils ne classent pas ce service, ne décident pas la loi locale et ne prouvent pas la priorité d’une fuite.

Nommez néanmoins qui tient la fiche d’usage, valide les données, approuve les seuils, supervise, traite les plaintes, enquête, autorise une version et peut l’arrêter. Le candidat peut fournir ces responsabilités actuelles. La qualification des parties, les analyses d’impact et l’acceptation du risque restent aux autorités compétentes.

Contrôles

Transformez les principes en résultats vérifiables

Séparez les notions. Transparence pour l’astreinte, information d’un usager, explication d’une priorité et trace d’enquête sont quatre contrôles. L’équité exige un dommage, des populations, une comparaison et une réponse. L’exactitude exige une tâche, une référence, une tolérance et un coût d’erreur. La supervision exige un pouvoir d’agir avant la conséquence.

Formulez la relation: dans une condition définie, un mécanisme produit un résultat pour une population; s’il échoue, un responsable agit. Classez la preuve comme complète, partielle, dépendante de l’acheteur, contractuelle, en revue juridique ou absente. Un dispositif peut contribuer à plusieurs exigences sans leur transmettre un verdict global.

Incluez le traitement d’échec. Une donnée incohérente part en revue manuelle. Une alerte de rupture probable contourne le tri normal. Une carte indisponible empêche une priorité automatique. Un écart entre zones entraîne une analyse. Une erreur grave reproductible peut suspendre la version. Sans action, un indicateur ne constitue pas une maîtrise.

Évaluation

Évaluez le système offert dans son contexte de travail

Construisez les cas à partir de l’usage et de ses dommages possibles: fuite ordinaire, rupture rapide, capteur défaillant, signaux contradictoires, appel imprécis, faible couverture, conduite rare, travaux voisins, événement météo, doublon et panne d’une source. Les territoires, matériels, saisons et équipes doivent représenter le marché. Un benchmark de modèle ne remplace pas ces cas.

Fixez les règles avant l’essai. Manquer une rupture n’a pas le même coût qu’envoyer une inspection inutile. Rapportez rappel et erreurs par gravité, type de conduite, secteur et densité de capteurs. Vérifiez l’incertitude lorsque les effectifs sont faibles. Expliquez pourquoi chaque mesure et seuil représentent l’effet opérationnel et qui les a approuvés.

Conservez version de l’application, identifiant ou politique du modèle, sources, règles, corpus, méthode, évaluateur, taille, résultats, cas graves, exclusions et date. Une assurance indépendante reste limitée à son objet. Après correction, liez l’échec initial, la modification, le nouvel essai et la décision de remise en service.

Cas pratique

Prouvez le tri des fuites sans lui attribuer la décision terrain

Une régie fictive exploite des canalisations urbaines et rurales. Le service rapproche anomalies de débit, appels, interventions passées et carte patrimoniale pour suggérer un secteur, une cause possible et un niveau d’inspection. L’ingénieur d’astreinte valide chaque départ. Le système ne commande aucune vanne, ne coupe pas l’eau et n’engage pas seul une dépense.

La carte distingue validation des mesures, rapprochement géographique, modèle d’anomalie, règles de gravité, proposition de priorité, écran d’astreinte et ordre de mission. Une chute brutale de pression combinée à plusieurs appels rejoint immédiatement une file humaine critique. Une carte indisponible ou une confiance insuffisante produit une abstention. L’écran montre signaux, période, emplacement, proposition et raisons.

Le corpus couvre fontes et plastiques, centres denses et zones rurales, hiver, sécheresse, travaux, capteurs intermittents, fuites lentes et ruptures. Le rappel des incidents graves possède son propre seuil. Les faux négatifs sont examinés un par un. Une simulation confirme que l’astreinte peut modifier la priorité et qu’aucun appel terrain ne part sans validation. Les écarts de couverture entre secteurs restent visibles.

La réponse peut prouver la suggestion de tri, l’abstention, la validation et le processus d’incident pour cette configuration. Elle indique que la régie possède les seuils et la décision opérationnelle. Le juriste examine séparément qualification, information et analyses d’impact. Aucun résultat ne permet d’affirmer que l’IA décide d’une coupure ou détecte toute fuite.

Rédaction

Rédigez une réponse proportionnée aux preuves

Pour chaque proposition, nommez usage, version, résultat du contrôle, date de preuve, partie responsable et limite matérielle. Remplacez « IA responsable », « totalement explicable » ou « sans biais » par un comportement que l’acheteur peut examiner. Si le formulaire impose oui ou non, placez la qualification dans le champ ou l’annexe permis.

Distinguez fait actuel, engagement futur et conclusion juridique. « Toute mission exige une validation d’astreinte » décrit le système offert. « Le candidat livrera un rapport trimestriel » crée une obligation. « La régie est déployeur » est une qualification. Chacun possède sa source et son décideur même si la réponse les rapproche.

Communiquez de façon proportionnée: fiche d’usage, responsabilités, synthèse système et fournisseurs, rapport d’essai, limites, parcours de supervision, suivi, incident, changement ou portée de certificat. Les données brutes, consignes secrètes, attaques, cartes sensibles et constats non résolus restent sous l’autorité du propriétaire.

• Nommer l’usage, la version et l’influence sur la décision.
• Décrire le contrôle par son résultat observable.
• Identifier exploitation, erreur et autorité de suspension.
• Citer une preuve avec population, méthode et date concordantes.
• Conserver les dépendances acheteur, humaines et fournisseur.
• Rendre visibles les avis ouverts et les limites des essais.
• Ne transmettre que la forme approuvée des preuves protégées.

Exploitation

Maintenez la preuve après incident et changement

Déduisez le suivi des risques: variations des entrées, abstentions, escalades, corrections, faux négatifs graves, plaintes, panne de source et mise à jour. Définissez responsable, fréquence, seuil d’enquête, délai et action. Disponibilité et temps de réponse ne disent pas si les priorités restent justes ou supervisées.

Un incident IA peut être une sortie dommageable, une action non autorisée, une inégalité répétée, une supervision contournée, une modification hors validation ou l’impossibilité de reconstituer un événement. Reliez triage, confinement, conservation, examen des notifications, correction, cause, nouvel essai et clôture. Les équipes juridique et sécurité gardent leurs propres décisions.

Rouvrez les propositions affectées après changement de finalité, population, rôle décisionnel, modèle, fournisseur, instruction, source, règle, seuil, interface, effectif, environnement, droit ou paramètre client. Retestez selon l’impact. Gardez preuve et texte remplacés avec la raison et la nouvelle approbation.