07. Tiers, chaîne d'approvisionnement et incidents IA

Section 7 du cours « Pilotez un système d’IA | ISO/IEC 42001 ».

Utiliser une IA fournie par un tiers demande de vérifier le fournisseur, le contrat et le fonctionnement réel du système. Il faut aussi préparer la réponse aux incidents.

Repères de vocabulaire

• API : interface permettant à deux logiciels d’échanger des données ou des commandes.

• ML / LLM : apprentissage automatique / grand modèle de langage.

• PCA : plan de continuité d’activité.

• SBOM / AI-BOM : inventaire des composants logiciels / inventaire adapté aux composants d’IA.

Notions

• IA tierce : modèle, API, brique open source, équipe externalisée ; open source gratuit = tiers aussi

• Responsabilité : outils externalisables ; performance, équité, conformité, impact restent à l'organisation

• Diligence à l'achat : transparence fournisseur, méthodes de dev, éthique, documentation, suivi après déploiement

• Questions d'achat : origine des données, fréquence de mise à jour, biais connus, explicabilité, sécurité

• Gouvernance contractuelle : accès doc, journaux, rapports de performance, protocole de mise à jour, imputabilité, notification rapide (panne, problème éthique), droit d'audit ou de preuve

• Registre unique : IA internes et tierces dans le même inventaire : provenance, objectif, niveau de risque, responsable, étape du cycle de vie, statut de contrôle

• Assurance algorithmique : chaque composant vérifiable, explicable, sécurisé, aligné valeurs et règles ; origine, données d'entraînement, limites, licence connues ; suivi jusqu'au retrait

• Chaîne d'approvisionnement modèles pré-entraînés (dépôts open source), bibliothèques ML (TensorFlow, PyTorch), modèles de fondation cloud, API spécialisées (vision, langage, recommandation)

• SBOM / AI-BOM : nomenclature logicielle ; variante IA : modèles, dépendances, historique

• Fiche registre composant : provenance, version, date d'intégration, contact fournisseur, cas d'usage, niveau de risque, limites et vulnérabilités connues

• Évaluation pré-intégration licence, origine des données (biais, droit d'auteur), tests sur jeux internes, qualité des explications et de la doc

• Traitement du risque tiers surveillance des sorties, contrôles compensatoires, refus d'intégrer si doute sérieux

• Incident IA : tout événement où le système agit de façon nuisible, trompeuse, opaque ou injustifiée ; panne et intrusion incluses, mais aussi biais, hallucination, perte de confiance

• Plan de réponse IA : définition de l'incident, rôles (détection, tri, enquête, escalade, communication, résolution), collecte des enseignements ; intégré au dispositif global d'incidents

• Détection : automatique (dérive, faux positifs/négatifs, équité, seuils) + humaine (signalement, tickets, plaintes, sans représailles)

• Tri : gravité, impact, probabilité de répétition -> ajustement simple ou réponse complète

• Communication de crise : qui parle, quel message, quand, par quel canal ; public, interne, régulateur

À retenir

• achat d'IA externe = décision de gouvernance, traitée au-delà d'un achat informatique classique

• Former l’équipe achats aux risques de l’IA. L’évaluation porte aussi sur les impacts et sur le respect des règles internes, au-delà du prix de la licence.

• circuit d'approbation IA tierce : validation technique, analyse juridique, classification des risques, enregistrement

• Prévoir au contrat les informations et les preuves accessibles. Sans elles, il devient difficile d’expliquer le fonctionnement du système lors d’un incident.

• architecture -> points d'ancrage pour que les outils internes évaluent l'IA externe et remontent les résultats

• Réévaluer les risques lorsqu’un fournisseur change de modèle. Vérifier les conséquences pour les utilisateurs et pour la conformité.

• API boîte noire : validation statistique des sorties, retours utilisateurs, suivi des incidents

• fonctionnalité de remplacement de modèle prévue dans l'architecture (exemple FinTech : bascule vers modèle interne)

• clauses du cours : 6 risques des dépendances, 7 documentation et ressources, 8 cycle de vie y compris tiers, 10 leçons tirées

• exigences possibles envers fournisseurs critiques : leurs propres évaluations de risques, voire adoption d'ISO 42001

• exemple banque : fournisseur refuse les données d'entraînement -> clauses d'audit biais, préavis de mise à jour, tests par groupe démographique

• exemple santé : performance variable selon l'âge -> revue par radiologue pour moins de 18 ans et plus de 70 ans

• plan d'incident testé par exercices sur table et simulations, comme un PCA ou un plan cyber

• équipe incident pluridisciplinaire : juridique, communication, conformité, direction, éthique, sécurité

• communication publique : reconnaître, expliquer simplement, mesures prises, empathie

• exemple LLM service client : hallucinations -> retour à la version précédente, analyse des journaux, déclaration publique, corpus limité aux documents validés, action corrective enregistrée, alerte sur mots-clés

• exemple aides sociales : refus disproportionnés -> suspension, comité d'éthique, variables indirectes (résidence, éducation)

• Après l’incident, rechercher les causes et suivre les actions correctives. Vérifier leur efficacité, puis présenter les enseignements en revue de direction.

• responsable désigné de la réponse aux incidents IA + guide de communication de crise publié

flowchart TD
    A[Signal : alerte de monitoring ou signalement humain] --> B[Enregistrement de l'incident]
    B --> C{Tri : gravité, impact, probabilité}
    C -- mineur --> D[Ajustement ou réentraînement]
    C -- majeur --> E[Équipe pluridisciplinaire : juridique, comm, conformité, direction]
    E --> F[Confinement : retour version précédente, suspension, bascule de modèle]
    F --> G[Enquête : journaux, données, logique du modèle]
    E --> H[Communication : public, interne, régulateur]
    G --> I[Action corrective enregistrée]
    D --> I
    I --> J{Efficacité vérifiée ?}
    J -- non --> G
    J -- oui --> K[Retour d'expérience -> revue de direction, registre des risques]

Lien avec l'audit IA

• Registre tiers : « Montrez les IA tierces et open source de votre inventaire » Preuve : registre avec provenance, version, responsable, niveau de risque, statut

• Achat : « Quel questionnaire IA pour les fournisseurs ? » Preuve : grille de diligence remplie, circuit d'approbation signé (technique, juridique, risques)

• Contrat : « Droit d'audit, notification des mises à jour, accès aux journaux ? » Preuve : clauses

• Changement fournisseur : « Dernière mise à jour du modèle tiers, qui l'a évaluée ? » Preuve : analyse d'impact datée

• Surveillance tiers : « Comment suivez-vous une API boîte noire ? » Preuve : tableaux de bord, tests statistiques

• Plan d'incident : « Définition d'un incident IA, rôles, escalade ? » Preuve : plan, compte rendu d'exercice

• Signalement : « Canal ouvert aux clients et salariés ? » Preuve : formulaire, tickets, politique anti-représailles

• Clôture : « Dernier incident : causes, action corrective, vérification ? » Preuve : fiche d'action corrective (clause 10.2), passage en revue de direction

• Déjà traité : incidents 72 h et cadre légal : ai-governance-fundamentals docs/08-cadre-europeen-et-france.md ; RACI : ai-governance-fundamentals docs/05-roles-raci.md ; fournisseurs et incidents de sécurité : iso-27001 (annexe A 5.19 à 5.23, 5.24 à 5.28)

Précisions et points à vérifier

Les points ci-dessous signalent les limites du cours et les vérifications à poursuivre. Les exemples et recommandations du formateur ne sont pas tous des exigences de la norme.

• mesures de l'annexe A sur les tiers : A.10 (répartition des responsabilités, fournisseurs, clients) ; numérotation exacte dans ISO/IEC 42001:2023

• communication des incidents aux parties intéressées : mesure A.8.4 selon ma lecture, à confirmer dans ISO/IEC 42001:2023

• le cours dit qu'ISO 42001 « recommande » de trier les incidents par gravité : pas d'exigence de tri explicite dans les clauses, plutôt bonne pratique (vérifier annexe B)

• SBOM et AI-BOM : absents du texte de la norme, pratiques de marché citées par le cours

• « IAMS, système de gestion des incidents et actions » : erreur de transcription probable pour AIMS

• exemple santé : « toute sortie considérée comme hautement fiable doit être revue » ; sens probable : revue obligatoire même si le modèle se dit très confiant

• Incidents graves, AI Act art. 73 : signaler immédiatement selon les conditions de l’article. Les délais de 15 jours, de 10 jours en cas de décès et de 2 jours pour certains cas sont des maxima ; ils n’autorisent pas à attendre. Pour les infrastructures critiques, le cas visé est une perturbation grave et irréversible. Source : article 73.

• Violation de données, RGPD art. 33 : documenter toute violation. Notifier l’autorité compétente sans délai injustifié, si possible dans les 72 h après connaissance, sauf si le risque pour les personnes est improbable. Le risque élevé concerne l’information des personnes, avec les exceptions de l’article 34. Source : CNIL, notification.

• Déployeur, AI Act art. 26 § 5 : en cas d’incident grave, informer immédiatement d’abord le fournisseur, puis l’importateur ou le distributeur et les autorités de surveillance concernées. Source : article 26.

Questions de révision

• un modèle open source gratuit relève-t-il de la gestion des tiers ? Réponse : oui, inventaire, responsable interne, tests d'équité

• quatre clauses contractuelles clés avec un fournisseur d'IA ? Réponse : accès doc et journaux, préavis de mise à jour, droit d'audit, notification d'incident

• qu'est-ce qu'un AI-BOM ? Réponse : nomenclature des modèles, dépendances et historique, sur le modèle du SBOM

• trois critères de tri d'un incident IA ? Réponse : gravité, impact, probabilité de répétition

• quelle clause porte les actions correctives après incident ? Réponse : clause 10 (non-conformité, action corrective, efficacité vérifiée)

Leçons couvertes

Contrôles des risques IA liés aux tiers et aux fournisseurs ; Sécurité de la chaîne d'approvisionnement et assurance algorithmique ; Gestion des incidents IA et communication de crise.