Évaluer les risques de l'IA

Ce que l'IA fait bien ici, ce qu'elle fait mal

Ce qu'elle fait bien

• Proposer les risques de chaque famille: le modèle écrit chaque risque en cause, événement et effet.
• Signaler une famille vide: il relève la famille sur laquelle la description ne dit rien.
• Relever les faits manquants: il nomme ce que la description tait sur les données, le fournisseur et les personnes touchées.
• Lire la documentation du fournisseur: il extrait les clauses sur la conservation, l'entraînement et la sécurité.
• Proposer des mesures: il associe à chaque risque une mesure que l'équipe retient ou écarte.

Ce qu'elle fait mal

• Noter la probabilité: le modèle donne une note plausible sans preuve tirée de votre cas d'usage.
• Connaître le contrat conclu avec le fournisseur: il ignore les clauses signées et leurs modifications.
• Trancher le droit d'auteur: il affirme un statut juridique que le droit suisse laisse en partie ouvert.
• Détecter une injection de prompt: il suit une instruction cachée dans un document qu'il lit.
• Connaître les personnes touchées: il omet les groupes qu'aucun document ne nomme.
• Déclencher le réexamen: il ne sait pas que le fournisseur a changé de modèle.
• Fixer la tolérance: il propose un seuil que seule la direction peut fixer.

Déroulé

L'unité évaluée: le cas d'usage

L'AI Act classe un système selon sa finalité. Un système à risque minimal peut divulguer une donnée personnelle, écarter un groupe de personnes ou publier un texte protégé. La classe de risque ne dispense donc pas d'une évaluation. L'évaluation porte sur un cas d'usage: une tâche, les données qu'elle traite, l'outil et son fournisseur, les personnes que le résultat touche. Le même outil porte d'autres risques quand il rédige des annonces que quand il trie des candidatures.

Le NIST AI Risk Management Framework (AI RMF 1.0) définit le risque comme la combinaison de la probabilité d'un événement et de l'ampleur de ses conséquences (§1.1). L'organisation fixe elle-même la tolérance au risque. Les exigences légales peuvent l'influencer (§1.2.2). Le NIST admet qu'une priorité plus élevée peut se justifier pour un système entraîné sur des données sensibles ou dont les résultats touchent des personnes (§1.2.3). Un système sans contact humain peut aussi avoir des effets en aval sur la sécurité ou sur la société.

Les familles de risques

Vie privée. Le profil d'IA générative du NIST (NIST AI 600-1) relève qu'un modèle peut divulguer, produire ou déduire une information sensible (§2.4). Le modèle peut déduire une donnée personnelle que personne ne lui a fournie. Cette déduction peut nuire à la personne même quand elle est fausse. Selon le Préposé fédéral à la protection des données et à la transparence (PFPDT), la loi fédérale sur la protection des données (LPD) s'applique directement à tout traitement de données personnelles par l'IA. La personne concernée a le droit de savoir qu'elle échange avec une machine. Un risque élevé exige une analyse d'impact. Vous trouverez les articles de la loi et la décision d'envoyer un document dans «La LPD et les données confidentielles».

Biais. Selon le NIST AI 600-1, l'IA peut accroître la vitesse et l'échelle auxquelles un biais nuisible se manifeste (§2.6). Le document relève des écarts de performance entre groupes de personnes et entre langues. En Suisse, l'équipe compare donc les résultats dans chaque langue du cas d'usage. Vous trouverez dans «Les biais» les points où un biais entre dans un système.

Sécurité. Selon le NIST AI 600-1, l'IA générative facilite les cyberattaques (§2.9). Elle élargit aussi la surface d'attaque du système qui l'intègre. L'injection de prompt glisse dans une entrée une instruction qui détourne le modèle. L'injection indirecte la cache dans un document ou une page que le modèle lit. L'empoisonnement altère les données dont le modèle apprend. La sécurité informatique contrôle le système avec la liste OWASP Top 10 for LLM Applications (version 2025).

Propriété intellectuelle. En droit suisse, une œuvre est une création de l'esprit qui a un caractère individuel (art. 2 al. 1 LDA). L'Institut Fédéral de la Propriété Intellectuelle (IPI) précisait en février 2023 que le droit d'auteur ne protège que les œuvres créées par un être humain. Une personne qui fournit l'effort créatif et se sert de l'outil peut obtenir la protection. Un résultat dont l'agent conversationnel accomplit l'acte créatif n'est pas protégé. Un modèle peut aussi restituer un passage de ses données d'entraînement (NIST AI 600-1, §2.10). Si une œuvre reste reconnaissable dans le résultat, l'autorisation de son auteur est en général requise. L'utilisateur qui publie ce résultat viole lui aussi le droit d'auteur. Les conditions d'utilisation de certains outils interdisent l'usage commercial du contenu généré.

L'équipe ajoute les autres risques du cas d'usage. Le NIST AI 600-1 en recense douze pour l'IA générative. Les hallucinations en font partie.

Qui évalue

Selon le NIST, la cartographie des risques (fonction MAP) gagne à réunir une équipe interne diverse et à consulter des personnes extérieures (utilisateurs finaux, groupes touchés). Plus le système est risqué, plus la consultation s'étend. En pratique, l'analyste réunit le responsable métier du cas d'usage, le conseiller à la protection des données, la sécurité informatique et un juriste. Une personne du groupe touché relit les risques retenus.

Les étapes

1. L'analyste décrit le cas d'usage. Il note la tâche, les données qui entrent et celles qui sortent, les personnes touchées et qui décide sur la base du résultat. Il ajoute l'outil, le fournisseur et le pays où partent les données. La description ne contient aucun nom et aucun extrait réel.
2. Le modèle propose les risques de chaque famille. Le prompt modèle lui fait écrire chaque risque en cause, événement et effet comme dans «Identifier les risques». Il nomme la preuve qui permettrait d'en estimer la probabilité. Il ne note rien.
3. L'équipe trie la liste. Elle écarte les risques qui vaudraient pour n'importe quel outil et fusionne les doublons. Elle ajoute ce que le modèle ne pouvait pas savoir: le contrat conclu avec le fournisseur, les incidents passés, les groupes que la description omet.
4. L'équipe note la probabilité et l'impact. Elle utilise l'échelle de l'organisation. Le NIST fonde cette estimation sur l'usage prévu, les usages de l'IA dans des contextes semblables, les incidents publics et l'avis de personnes extérieures à l'équipe (MAP 5.1). Un test sur un échantillon fournit une preuve propre au cas d'usage. Chaque note porte sa preuve. Au réexamen, cette preuve permet de contester la note. La fiche Analyse et gestion des risques explique pourquoi la note reste aux parties prenantes.
5. Le responsable du cas d'usage choisit les mesures. Chaque risque au-delà de la tolérance reçoit une mesure, un responsable et une échéance. Le NIST range les réponses en réduction, transfert, évitement et acceptation (MANAGE 1.3). Pour réduire un risque, le responsable limite les données transmises, place un contrôle humain avant la publication, retire à l'outil un droit inutile ou change de service. Le contrat conclu avec le fournisseur transfère une part du risque. Ses clauses règlent la conservation des données, l'entraînement sur les entrées et l'avis préalable d'un changement de modèle. Renoncer au cas d'usage évite le risque.
6. Le responsable accepte le risque résiduel. Le NIST appelle risque résiduel le risque qui subsiste après le traitement. Il demande de le documenter et d'en informer les utilisateurs finaux (§1.2.3, MANAGE 1.4). Le responsable signe le risque résiduel et date sa signature.
7. Le responsable fixe le réexamen. Le NIST prévoit une surveillance continue et des revues périodiques dont l'organisation fixe la fréquence (GOVERN 1.5). Il demande aussi un inventaire des systèmes d'IA (GOVERN 1.6). Le responsable inscrit le cas d'usage à l'inventaire avec la date du prochain réexamen. Un changement de modèle ou de conditions du fournisseur, une nouvelle source de données, un nouvel usage ou un incident avancent le réexamen. Les mesures qui valent pour toute l'organisation passent dans la politique d'usage de l'IA.

Prompt modèle

Tu aides une équipe à évaluer les risques d'un cas d'usage de l'IA.

<cas_d_usage>
[DESCRIPTION DU CAS D'USAGE]
</cas_d_usage>

<donnees>
[DONNÉES TRAITÉES]
</donnees>

<outil>
[FOURNISSEUR ET OUTIL]
</outil>

<personnes>
[PERSONNES TOUCHÉES]
</personnes>

<consignes>
1. Appuie chaque risque sur une phrase des blocs ci-dessus. Cite cette phrase.
2. Traite les familles dans cet ordre:
   a. Vie privée: le résultat peut-il divulguer une donnée personnelle reçue? Peut-il en déduire une que personne n'a fournie?
   b. Biais: le résultat peut-il être moins bon pour un groupe de personnes ou pour une langue?
   c. Sécurité: une entrée peut-elle contenir une instruction cachée? L'outil a-t-il des droits dont la tâche n'a pas besoin?
   d. Propriété intellectuelle: le résultat peut-il reprendre une œuvre reconnaissable? Les conditions de l'outil limitent-elles l'usage commercial?
3. Écris chaque risque sous la forme cause, événement incertain, effet sur les personnes ou sur l'organisation.
4. Pour chaque risque, nomme la preuve qui permettrait d'estimer sa probabilité: un incident public, un usage semblable, un test sur un échantillon, une clause du contrat.
5. Propose une mesure par risque.
6. Ne donne aucune note de probabilité ni d'impact. L'équipe note.
7. Si les blocs ne permettent pas de traiter une famille, écris «à vérifier» et formule la question à poser.
8. Termine par un tableau: famille, risque, phrase citée, preuve à réunir, mesure proposée.
</consignes>

• [DESCRIPTION DU CAS D'USAGE] décrit la tâche, ce que l'outil produit et qui décide sur la base du résultat.
• [DONNÉES TRAITÉES] nomme les catégories de données qui entrent et qui sortent. Le bloc ne contient aucun nom et aucun extrait réel.
• [FOURNISSEUR ET OUTIL] nomme le service, le type de compte, le pays de traitement et les droits de l'outil sur les systèmes de l'organisation.
• [PERSONNES TOUCHÉES] nomme les groupes que le résultat concerne. Il nomme aussi ceux qui ne voient jamais l'outil.

Exemple

Une régie immobilière de Bienne gère 2'400 logements. L'assistant d'IA de son compte d'entreprise rédige les annonces de location en français et en allemand. Il reçoit la fiche technique de l'objet, les notes de l'état des lieux de sortie et les plans que fournissent les propriétaires. Un gérant relit chaque annonce et la publie sur les portails immobiliers. Selon l'AI Act, ce cas d'usage relèverait du risque minimal.

La régie note la probabilité et l'impact de chaque risque sur l'échelle faible, moyen, élevé. Le niveau de risque reprend la plus haute des deux notes. Sa direction accepte un risque de niveau faible et fait traiter les autres avant la mise en service. Le modèle a proposé onze risques. L'équipe en a gardé trois et en a ajouté un.

Le modèle avait classé le risque de vie privée en «à vérifier». La description mentionnait des notes d'état des lieux sans dire ce qu'elles contiennent. La cheffe du service location a relu 30 notes. Leur contenu a fixé la probabilité.

Le modèle n'avait pas vu de risque de sécurité dans les plans. Le responsable informatique l'a ajouté au tri et l'a testé. Un seul PDF piégé a suffi à changer le loyer publié. La régie a retiré les plans de l'entrée plutôt que de compter sur la relecture.

La directrice a signé les quatre risques résiduels le 15 septembre 2026 et fixé le réexamen au 15 mars 2027. Un changement de fournisseur, de modèle ou de portail l'avance.

Essayer avec l'AI Incident Database

L'AI Incident Database du Responsible AI Collaborative recense les dommages que des systèmes d'IA ont causés ou ont failli causer. La recherche ne demande pas de compte. Saisissez un terme de votre domaine en anglais («real estate», «chatbot», «recruitment»). Chaque incident décrit un usage réel et ce qui a mal tourné. Inscrivez l'incident comme preuve à côté de la note de probabilité.

Vérifier le résultat

• La description nomme-t-elle la tâche, les données, l'outil, le fournisseur et les personnes touchées?
• La description envoyée au modèle était-elle exempte de nom et d'extrait réel?
• Chaque famille a-t-elle été examinée même sans risque retenu?
• Chaque risque sépare-t-il la cause, l'événement et l'effet?
• L'équipe a-t-elle ajouté les risques hors des familles?
• Chaque note vient-elle de l'équipe et cite-t-elle une preuve?
• L'échelle et la tolérance sont-elles celles de l'organisation?
• Chaque risque au-delà de la tolérance a-t-il une mesure, un responsable et une échéance?
• Le responsable a-t-il signé et daté le risque résiduel?
• Une personne du groupe touché a-t-elle relu les risques retenus?
• Le cas d'usage figure-t-il à l'inventaire avec la date du réexamen et ses déclencheurs?

Limites et risques

Les preuves sont elles-mêmes des données personnelles. Dans l'exemple, 7 des 30 notes relues nomment le locataire sortant. Deux décrivent un aménagement pour fauteuil roulant. Ce sont des données sur la santé, donc des données sensibles (art. 5 let. c ch. 2 LPD). L'équipe garde les échantillons, les sorties des tests et le registre des risques dans le stockage de l'organisation. Elle ne les transmet pas au modèle. Pour décider ce qui peut partir vers un outil, suivez «La LPD et les données confidentielles».

Les conditions du fournisseur changent. Un fournisseur modifie la conservation des données, l'entraînement sur les entrées ou le modèle utilisé sans que l'outil change d'aspect. L'analyste relit les conditions de l'abonnement à chaque réexamen.

Le droit d'auteur reste en partie ouvert. En février 2023, l'IPI tenait pour non tranchée la question de l'entraînement sur des œuvres protégées. Des procès étaient en cours aux États-Unis et en Angleterre. L'analyste note l'état du droit à la date de l'évaluation. Le juriste le relit à chaque réexamen.

La tolérance appartient à l'organisation. Sans tolérance fixée, l'équipe ne peut dire quel risque exige une mesure. L'analyste la demande à la direction avant de noter.

Techniques liées

• Analyse et gestion des risques: le registre, les échelles et le traitement où l'évaluation inscrit chaque risque.
• Liste des parties prenantes: les groupes touchés que les documents du projet ne nomment pas.
• Analyse des exigences non fonctionnelles: une mesure de sécurité ou de vie privée devient une exigence au seuil vérifiable.