06. Risques, éthique et IA fantôme

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

La gestion des risques associe sécurité, éthique et usages réels. Elle doit aussi couvrir l’IA fantôme : les outils utilisés sans être déclarés à l’organisation.

Repères de vocabulaire

• SMIA / AIMS : système de management de l’IA.

• LLM : grand modèle de langage.

• KPI : indicateur clé de performance.

• MFA : authentification multifacteur.

• CASB : outil de contrôle des accès et usages des services cloud.

• CCPA : loi californienne sur la protection des données personnelles.

Notions

• Familles de risques : éthique, sécurité, opérationnel, conformité

• éthique : biais, opacité, responsabilité floue, vie privée

• sécurité : violation de données, attaque adversariale, faille, menace interne

• opérationnel : panne, intégration à l'existant, passage à l'échelle, maintenance

• conformité : réglementation mouvante (RGPD), référentiels sectoriels, documentation

• Cadre de gestion : identification -> analyse (probabilité x impact, quali et quanti, scénarios) -> notation et priorisation -> plans d'action -> suivi par KPI -> amélioration continue

• Modélisation menaces : threat modeling : par scénario et contexte, dès la conception, mise à jour à chaque réentraînement

• STRIDE : Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege

• MITRE ATLAS : base des tactiques et techniques d'attaque contre l'IA

• Évasion : entrées adversariales qui trompent filtres et classifieurs

• Prompt injection : manipulation d'un LLM : fuite d'instructions, contournement des filtres, contenu interdit ; avec hallucinations et contenus non autorisés

• Red teaming : testeurs internes ou externes qui cherchent à contourner le système

• Registre des menaces : incidents, quasi-accidents, nouveaux risques -> ajustement des plans

• Débiaisage : pré-traitement (données), in-traitement (algorithme), post-traitement (sorties)

• Protection des données dès la conception : définir la finalité et la base légale, limiter les données et prévoir leur sécurité. Le consentement est une base légale possible, pas une obligation systématique.

• Transparence : ouverture sur le fonctionnement et la décision ; documentation, open source

• Responsabilité : accountability : développeurs et opérateurs répondent des décisions

• Explicabilité : XAI : méthodes à base de règles, méthodes agnostiques du modèle

• Éthique by design : équité, transparence, dignité, non-discrimination au même rang que performance et rapidité

• Confiance by design : vérification continue que ces valeurs tiennent en exploitation

• IA fantôme : shadow AI : système utilisé ou déployé sans aval ni rattachement à l'AIMS

• Modèle voyou : rogue model : contourne les contrôles ou dérive hors de ses limites

• AIMS : Artificial Intelligence Management System, système de management de l'IA

À retenir

• Atténuation éthique : audits d'équité, modèles explicables, gestion sécurisée des données, cadre de responsabilités.

• Atténuation sécurité : pare-feu, chiffrement, entraînement adversarial, évaluations régulières, programme menaces internes.

• Atténuation opérationnelle : redondance, sauvegardes, tests de compatibilité, gestion de capacité, maintenance.

• Atténuation conformité : veille réglementaire, chiffrement et contrôle d'accès, lignes directrices, documentation complète.

• Cas sectoriels : santé (données patients), finance (biais, fuites), industrie (pannes), commerce (vie privée), transport (sécurité).

• Direction : impulsion, ressources, culture du risque (communication ouverte, formation, reconnaissance des efforts).

Tester les menaces

• Menaces IA hors cyber classique : venant du modèle lui-même (hypothèses, dépendance aux données, hors contexte).

• Empoisonnement : ex. détection de fraude entraînée sur exemples truqués ; parade : traçabilité, circuits sécurisés, accès restreint.

• Évasion : ex. image anodine qui trompe la reconnaissance faciale ; parade : tests adversariaux en validation, sanitisation des entrées.

• Adapter les tests au cycle de vie : atelier sur les menaces pendant la planification, tests de contournement pendant le développement, journaux au déploiement, puis suivi du registre en exploitation.

• Exemple financier : un chatbot est détourné pour fournir des astuces d’évasion fiscale. Réponses proposées : filtrer les requêtes, limiter le contexte accessible et prévoir une modération humaine.

• Cas drones : spoofing GPS et vision ; scénarios ATLAS -> canaux GPS sécurisés, données enrichies, reprise manuelle, revue trimestrielle.

Éthique et confiance

• Équité : définir l'équité par cas d'usage, données représentatives, audits réguliers.

• Exemples : revoir les données d’un recrutement biaisé ; sécuriser les accès en finance. En santé, justifier une base légale de l’article 6 et une exception de l’article 9 du RGPD ; le consentement explicite n’est pas la seule possibilité.

• Cadres juridiques cités : RGPD, CCPA ; bonnes pratiques : audits, formation des équipes, politiques internes.

• Confiance : transparence + responsabilité + implication des utilisateurs ; difficile sur réseaux de neurones profonds.

• Éthique by design : part de la politique IA (clause 5) -> rôles, budget, validations, incitations.

• Traduire les principes en contrôles mesurables : tests d’équité, possibilité de retracer une décision et procédure de recours humain.

• Équipe pluridisciplinaire : ingénieurs IA, data, juristes, éthiciens, métier, parties prenantes.

• Comité d'éthique doté d'un pouvoir réel : retarder, modifier, bloquer un déploiement.

• Cas streaming : évaluation d'impact, contraintes d'équité, « pourquoi cette vidéo », tableau de bord équité dans l'AIMS.

• Cas aides au logement : communautés vulnérables impliquées, pas de critères proxy, vérification par travailleurs sociaux, contestation, consultation annuelle.

• Indicateurs de confiance : perception utilisateurs, taux de réclamation, retours parties prenantes, impact constaté.

Repérer les usages non déclarés

• IA fantôme : chatbots non déclarés, scripts ML, IA tierce cachée dans les outils ; cause fréquente : frustration ou méconnaissance.

• Périmètre (clause 4) : inclure expérimentations, équipes isolées, fournisseurs ; l'AIMS cherche aussi l'inconnu.

• Clause 8 : enregistrement et évaluation avant entraînement, test ou déploiement.

• Détection : analyse réseau, revue de code, journaux d'API, audit des intégrations, flux de données, logs d'accès et de calcul.

• Face à une IA non autorisée, évaluer les conséquences et isoler le système si nécessaire. Décider ensuite de l’encadrer ou de l’abandonner, rechercher la cause et renforcer les contrôles.

• Cas distribution : modèle de prévision non enregistré pilote les stocks -> retrait, formation, détection auto, relais AIMS local.

• Cas LegalTech : IA générative activée par mise à jour fournisseur -> retrait, clauses de transparence IA, checklist prestataires.

• Prévention : inventaire central à jour, contrôles AIMS dans les environnements de dev, déclaration dès la planification, audits de l'infrastructure.

• Ajout hors cours, liste des outils autorisés : outil ou modèle, offre (entreprise, sans entraînement sur nos données), usages permis, niveau de données max (public, interne, confidentiel, personnel), procédure de demande d'ajout. Critère = outil x type de données. Preuve de A.2.2, A.9.2, A.9.4.

Discipline et sanctions : distinguer trois sujets

• ISO 42001 : la norme ne fixe ni amendes ni sanctions disciplinaires. Des écarts peuvent affecter la certification.

• Droit du travail : une charte qui crée des obligations générales et permanentes de discipline relève des formalités du règlement intérieur ou de ses adjonctions. L’absence d’annexion ne signifie pas que tout comportement est insusceptible de sanction. Examiner la règle violée, le régime applicable à l’entreprise et la sanction envisagée.

• Formalités : consultation du CSE lorsqu’il existe, communication à l’inspection du travail, dépôt et publicité. L’entrée en vigueur respecte le délai légal d’au moins un mois après les formalités de dépôt et de publicité. Faire examiner les clauses disciplinaires par un juriste en droit du travail. Source : ministère du Travail.

• Règlement intérieur obligatoire : une sanction autre que le licenciement doit y être prévue. Ne pas transformer cette règle en interdiction générale de sanctionner dès qu’une charte IA n’est pas annexée. Source : Cass. soc., 23 mars 2017, n° 15-23.090.

• Signalement : organiser un canal confidentiel et protéger les signalements conformément au régime applicable. Distinguer le signalement de bonne foi et l’examen des faits signalés.

• AI Act, art. 99 : plafonds de 35 M€ ou 7 % du chiffre d’affaires mondial pour les pratiques interdites ; 15 M€ ou 3 % pour les manquements énumérés au § 4 ; 7,5 M€ ou 1 % pour les informations visées au § 5. Le montant le plus élevé s’applique en principe. Le plus faible est retenu pour les PME ; pour les petites entreprises à moyenne capitalisation, cette règle concerne les § 4 et 5. Les modèles à usage général relèvent de l’article 101. Ce sont des plafonds, pas des sanctions automatiques. Source : article 99 consolidé.

• RGPD, art. 83 : les plafonds dépendent du manquement. Ne pas les confondre avec les sanctions de l’AI Act ni avec la discipline des salariés. Source : CNIL, chapitre VIII du RGPD.

Lien avec l'audit IA

• Mesures annexe A (ISO/IEC 42001:2023, numérotation à confirmer sur le texte)

• Politique, valeurs : clause 5.2 ; A.2 politique IA

• Rôles, comité : A.3.2 rôles et responsabilités ; A.3.3 signalement des préoccupations

• Impact : clause 6.1.4 ; A.5 évaluation d'impact (individus, groupes, société)

• Cycle de vie : A.6.2.4 V&V (tests adversariaux) ; A.6.2.6 surveillance ; A.6.2.8 journaux

• Données : A.7 (qualité, provenance, préparation)

• Transparence : A.8 information des parties intéressées ; A.6.2.7 documentation technique

• Tiers : A.10 fournisseurs et clients (cas LegalTech)

• Contrôle possible : inventaire : « comment savez-vous que la liste des systèmes IA est complète ? » Preuve : registre daté, méthode de découverte (logs API, CASB, revue de code)

• Contrôle possible : déclaration : « à quelle étape un projet IA doit-il être enregistré ? » Preuve : procédure, exemples d'enregistrement en phase de planification

• Contrôle possible : outils autorisés : « quels outils IA un salarié a-t-il le droit d'utiliser, avec quelles données ? » Preuve : liste publiée et datée, procédure de demande, adjonction au règlement intérieur (formalités L1321-4)

• Contrôle possible : incident IA fantôme : « dernier cas détecté, traitement ? » Preuve : fiche d'incident, analyse de cause racine, action corrective (10.2)

• Contrôle possible : threat modeling : « méthode, fréquence, participants ? » Preuve : compte rendu d'atelier STRIDE ou ATLAS, registre des menaces IA

• Contrôle possible : red team LLM : « tests d'injection de prompt avant ouverture ? » Preuve : jeu de prompts adverses, résultats, filtres mis en place

• Contrôle possible : comité d'éthique : « a-t-il déjà bloqué ou modifié un projet ? » Preuve : procès-verbaux, décisions, critères de go / no go

• Contrôle possible : recours : « une personne peut-elle contester une décision ? » Preuve : procédure de contestation, délai, revue humaine tracée

• Contrôle possible : fournisseurs : « clause d'information sur l'IA embarquée ? » Preuve : contrats, checklist d'intégration prestataire

• Déjà traité : inventaire, RACI : ai-governance-fundamentals docs/02-inventaire.md, 05-roles-raci.md

• Déjà traité : politique d'usage (IA fantôme côté salariés) : ai-governance-fundamentals docs/04-politique.md

• Déjà traité : STRIDE, gestion des incidents, fournisseurs : dépôt iso-27001

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.

• ISO 27001 et ISO 31000 cités pour identifier les risques IA : la référence dédiée est ISO/IEC 23894:2023 (s'appuie sur ISO 31000), plus clause 6.1 d'ISO/IEC 42001.

• ISO 27001 et ISO 27035 présentées comme « lignes directrices éthiques » de responsabilité : ce sont sécurité et gestion des incidents ; pour l'éthique voir ISO/IEC 42001 A.5 et ISO/IEC TR 24368.

• Le cours dit que 42001 « exige » de traiter l'empoisonnement et « propose » les tests adversariaux : non nommés dans les exigences ; vérifier annexe C (sources de risque) et A.6.2.4.

• Fintech : démarche « rendue obligatoire » par l'AIMS : 42001 impose l'appréciation des risques, pas une méthode ni un red team.

• Enregistrement obligatoire de « tous les modèles avant entraînement » : formulation du cours ; vérifier A.4.2 (documentation des ressources) et A.6.

• Comité d'éthique avec droit de veto : bonne pratique, non exigée par la norme.

• « Article 10 » et « ISO 402001 » : erreurs de transcription pour clause 10 et ISO/IEC 42001.

• STRIDE transcrit « Tempering » : Tampering.

• Prompt injection : OWASP Top 10 LLM 2025, LLM01 ; fuite d'instructions = LLM07 (system prompt leakage).

• CCPA : amendée par la CPRA (en vigueur 2023).

• Recrutement et aides publiques au logement : haut risque, AI Act annexe III points 4 et 5 ; contestation et intervention humaine : RGPD art. 22, AI Act art. 14 et 86.

• IA fantôme et formation : obligation de maîtrise de l'IA, AI Act art. 4, applicable depuis le 2 février 2025.

Questions de révision

• quatre familles de risques IA du cours ? Réponse : éthique, sécurité, opérationnel, conformité.

• que signifie le T de STRIDE ? Réponse : Tampering, altération.

• trois moments de correction des biais ? Réponse : pré-traitement, in-traitement, post-traitement.

• clause qui fixe le périmètre incluant l'IA fantôme ? Réponse : clause 4 (4.3, domaine d'application de l'AIMS).

• réponse à un modèle non autorisé en production ? Réponse : évaluer, isoler, régulariser ou retirer, cause racine (clause 10).

Leçons couvertes

Risques liés à l'IA et stratégies d'atténuation ; Modélisation des menaces IA et risques adversariaux ; Gestion des risques éthiques, de sécurité et de confidentialité ; Confiance, responsabilité et transparence ; Éthique et confiance dès la conception ; Gestion de l'IA fantôme et des modèles non autorisés.

Repères RGPD corrigés

• Base légale : choisir et documenter la base adaptée au traitement. Le consentement d’un salarié est rarement approprié à cause du lien de subordination. Source : CNIL, base légale pour l’IA.

• Données de santé : cumuler une base de l’article 6 et une exception de l’article 9. Examiner aussi les formalités nationales applicables. Source : CNIL, traitements de données de santé.

• DPO : informe, conseille et contrôle. Le responsable de traitement reste responsable des décisions ; le DPO ne le remplace pas et ne valide pas les règles disciplinaires du seul fait de sa fonction. Source : CNIL, statut du DPO.