A.2 — Politiques relatives à l'IA

Le domaine A.2 compte trois contrôles : A.2.2 sur la politique relative à l’IA elle-même, A.2.3 sur son alignement avec les autres politiques de l’organisme, A.2.4 sur sa revue.

Ils prolongent l’exigence de la clause 5.2, qui impose la politique. Le domaine, lui, précise ce qu’on attend de son contenu et de son entretien.

Ce que l’auditeur regarde

Trois choses, dans cet ordre.

Que la politique existe et soit approuvée. Un document daté, avec un approbateur identifiable au niveau de la direction. C’est immédiat à vérifier, et l’absence d’approbation formelle est un écart en soi.

Qu’elle soit spécifique à l’organisation. Une politique interchangeable avec celle de n’importe qui ne fournit aucun cadre. La question que pose l’auditeur est concrète : quelle décision cette politique a-t-elle permis de trancher ?

Qu’elle ne contredise pas les autres. C’est l’objet d’A.2.3, et le point le plus souvent négligé. Une politique IA qui autorise ce que la politique de sécurité interdit place les équipes devant un arbitrage qu’elles ne peuvent pas rendre — et elles trancheront dans le sens le plus commode.

Trois niveaux de mise en œuvre

Minimal crédible. Un document d’une à deux pages, établi par la direction. Il porte d’abord ce que la clause 5.2 exige de toute politique, quelle que soit la taille de l’organisme. Deux engagements : respecter les exigences qui s’imposent à vous, et faire progresser en continu votre système de management de l’IA. Puis un texte réellement ajusté à la raison d’être de l’organisation, et qui serve de point d’appui aux objectifs que vous fixerez pour l’IA. Il existe par écrit, il est diffusé en interne, il renvoie aux autres politiques concernées — sécurité, données personnelles, achats — et reste communicable aux parties intéressées lorsque c’est pertinent. L’Annexe B y ajoute deux recommandations utiles : les principes qui guident vos activités d’IA, et la manière de traiter une dérogation ou une exception. Vous y placerez enfin, selon vos besoins, le périmètre des systèmes couverts, ce qui est autorisé et ce qui ne l’est pas, et la fréquence de revue (A.2.4). Approuvé, daté, et effectivement lisible par quelqu’un qui n’a pas participé à sa rédaction : à ces conditions, le niveau couvre ce que 5.2 impose et les trois contrôles du domaine.

Mature. La politique devient un chapitre d’un ensemble de gouvernance : définitions, périmètre par type de système, principes déclinés en règles, procédure d’approbation d’un nouvel usage. Les renvois aux politiques de sécurité, de protection des données et d’achat, déjà présents au niveau minimal, deviennent une articulation détaillée : chaque règle relative à l’IA dit à quelle règle voisine elle se rattache (A.2.3). Une revue annuelle est coordonnée par une fonction identifiée, et ses conclusions sont tracées.

À éviter. La charte de vingt pages en langue juridique, exigeant une signature manuscrite de chaque salarié, révisée après chaque réorganisation mineure. Le formalisme n’ajoute pas de solidité : il rend le document illisible, donc inappliqué, donc faux. Un auditeur qui interroge trois salariés et constate qu’aucun ne sait ce que la charte autorise en tire la conclusion qui s’impose.

Ce que le domaine ne demande pas

Aucun format, aucune longueur, aucun plan type. Aucune fréquence de revue chiffrée : vous la fixez et vous la respectez, sans attendre l’échéance prévue lorsqu’un changement — juridique, technique, d’organisation — appelle une revue anticipée.

Il n’exige pas non plus une politique distincte. Un chapitre dans un corpus de politiques existant satisfait le contrôle, et c’est souvent le choix le plus solide : une politique isolée vieillit plus vite que celle qui vit avec les autres.