Playbook 6 — Registre de documentation

Pourquoi la documentation est tout l’enjeu

Tous les autres playbooks de cette série produisent une décision — un niveau de risque, une validation de fournisseur, un résultat de contrôle des biais, une approbation de mise en service. Rien de tout cela ne vous protège si ce n’est pas écrit quelque part où vous pouvez le retrouver. Un système d’IA sans documentation n’a ni mémoire, ni défense, ni rien à montrer à un client, un régulateur ou votre propre équipe dans six mois quand quelqu’un demande « pourquoi l’avons-nous construit ainsi ? ».

Inventaire des systèmes d’IA — modèle principal

Une ligne par système ou outil d’IA réellement utilisé. C’est le document le plus utile de toute la série — commencez par là si vous commencez quelque part.

Fiche de projet IA d’une page — par système

Une par système, et seulement pour ceux qui en ont besoin — généralement tout ce qui est de niveau Élevé :

• Nom du système
• Propriétaire
• Niveau de risque
• Objectif / justification métier
• Données utilisées
• Fournisseur, le cas échéant
• Risques principaux et leurs mesures d’atténuation
• Cadence de revue
• Palier / statut actuel
• Date de dernière revue
• Entrées liées dans le journal des décisions

Note d’adéquation du cas d’usage — sept choses à écrire

Une fois qu’un cas d’usage passe le triage du playbook 1, écrivez ces éléments une fois. C’est plus détaillé que le canevas Valeur, coût et risque de la série Mesurer la valeur, le risque, les coûts et les KPI, et cela filtre autre chose : ce canevas demande si la justification métier tient, celui-ci demande quelle exposition de gouvernance le cas d’usage porte. Ils sont complémentaires, pas redondants.

1. Usage prévu — et mésusage prévisible.
2. Impacts positifs et négatifs identifiés.
3. Modes de défaillance prévisibles et leur atténuation.
4. Les groupes de personnes auxquels le système s’applique.
5. La complexité du système — un filtre à base de règles, ou un modèle qui ne cesse de changer.
6. Où se situe un humain dans la boucle.
7. Tout effet sur l’emploi ou les compétences dont votre équipe a besoin.

Modèle de journal des décisions

Toutes les décisions n’ont pas besoin d’une fiche de projet complète — mais toute décision conséquente a besoin d’une ligne ici.

Ensemble documentaire minimum — liste de contrôle

• L’inventaire des systèmes d’IA existe et est revu chaque trimestre (playbook 5).
• Chaque système de niveau Élevé dispose d’une fiche de projet IA complète.
• Chaque système de niveau Élevé fourni par un tiers dispose d’un dossier de due diligence archivé (playbook 2).
• Le journal des décisions est mis à jour chaque fois qu’un désaccord de gouvernance est résolu (playbook 5).
• La documentation est stockée quelque part où tout le comité de gouvernance peut y accéder — pas dans la boîte mail d’une seule personne.

Emprunter un terme : la déclaration d’applicabilité

L’ISO/IEC 42001 utilise une déclaration d’applicabilité : un document qui liste chaque mesure de l’annexe A et, pour chacune, si elle s’applique, pourquoi ou pourquoi pas, et son état de mise en œuvre. Le triage du playbook 1 fait déjà cela de façon informelle. Le nommer « notre déclaration d’applicabilité » dans ce registre ne coûte rien et se lit comme le vocabulaire que reconnaît un COO qui mène une due diligence fournisseur.

Étapes suivantes

Si vous ne devez mettre en place qu’une seule chose de toute cette série, mettez en place l’inventaire des systèmes d’IA. Tout le reste de la série s’y déverse, et c’est le seul document qui transforme « nous pensons être prudents » en quelque chose que vous pouvez réellement montrer à quelqu’un.