A.9 — Usage responsable des systèmes d'IA
Trois contrôles sur ce que les gens font réellement de vos systèmes. La dérive d'usage est plus fréquente que la dérive du modèle, et bien moins surveillée.
Le domaine A.9 compte trois contrôles : A.9.2 sur le processus d’usage responsable, A.9.3 sur les objectifs d’usage responsable, A.9.4 sur l’usage conforme à l’usage prévu.
Il traite d’un sujet qu’on aborde rarement de front : l’écart entre ce pour quoi un système a été mis en service et ce qu’on en fait six mois plus tard.
L’usage prévu, notion centrale
Tout le domaine repose sur cette notion. A.9.4 demande que le système soit utilisé conformément à son usage prévu — ce qui suppose que cet usage ait été écrit quelque part, et qu’il soit connu de ceux qui s’en servent.
C’est une notion qu’on retrouve au-delà de la norme : la qualification d’un système et les obligations qui s’y attachent, dans la réglementation comme dans la norme, dépendent de l’usage pour lequel il est mis sur le marché ou mis en service. Un système requalifié par son usage réel change de régime.
La dérive d’usage
Elle est plus fréquente que la dérive du modèle, et beaucoup moins surveillée. Le scénario est toujours le même : un outil déployé pour une tâche fonctionne bien, quelqu’un l’essaie sur une tâche voisine, ça marche à peu près, et l’usage s’installe.
Le problème n’est pas l’initiative — c’est même souvent une bonne idée. Le problème est que le nouvel usage n’a fait l’objet d’aucune évaluation d’impact, d’aucune appréciation du risque, et que personne ne sait qu’il existe.
Trois niveaux de mise en œuvre
Minimal crédible. Pour chaque système, une mention explicite de l’usage prévu et de ce qui est exclu, dans le mode d’emploi. Une session d’information courte pour les utilisateurs directs. Un point périodique — même annuel — où l’on demande aux équipes ce qu’elles en font réellement.
Mature. Des conditions d’usage formalisées : qui peut utiliser le système, sur quels types de données, pour quelles décisions. Des ateliers de sensibilisation pour les utilisateurs clés. Et un suivi des usages effectifs, qui permet de constater une dérive plutôt que de l’apprendre par un incident.
À éviter. Exiger le passage devant une instance pour chaque nouvelle requête, ou sanctionner tout usage inhabituel avant de l’avoir examiné. L’effet est l’inverse du but : les usages nouveaux ne disparaissent pas, ils deviennent invisibles. Interdire jusqu’à l’essai exploratoire est le meilleur moyen de ne plus rien savoir de ce qui se passe.
Ce que le domaine ne demande pas
Aucune surveillance nominative des utilisateurs, aucun outil de contrôle d’usage, aucune interdiction de l’expérimentation. Il ne demande pas non plus de figer les usages : il demande que les usages soient connus, et que l’écart déclenche un examen plutôt qu’une découverte.