Au-delà des politiques écrites : Relier l'EU AI Act, l'ISO 42001, le NIST AI RMF et l'OWASP aux contrôles à l'exécution

La gouvernance de l'IA en entreprise s'effondre lorsque les équipes traitent les règlements, les normes de gouvernance, les cadres de gestion des risques et les listes de contrôle de sécurité comme interchangeables. Ils ne le sont pas.

Lorsqu'on conçoit un agent d'IA autonome ayant accès aux systèmes internes de l'entreprise (comme un agent RH capable d'analyser les dossiers des employés), la gouvernance ne peut demeurer une simple liste théorique. Elle doit s'articuler sur quatre niveaux distincts :

1. La référence juridique : L'EU AI Act

L'EU AI Act impose des obligations juridiques contraignantes. Pour un agent RH influençant l'emploi, la rémunération ou l'évaluation des compétences, le système relève de l'annexe III (Haut Risque). La conformité exige :

• Des systèmes obligatoires de gestion des risques (Article 9)
• Une gouvernance rigoureuse des données et des tests de biais (Article 10)
• Une documentation technique et une journalisation automatique des événements (Articles 11 et 12)
• Des mécanismes de contrôle et de surveillance humaine (Article 14)
• Des contrôles d'exactitude, de robustesse et de cybersécurité (Article 15)

2. Le modèle organisationnel opérationnel : ISO/IEC 42001

La norme ISO/IEC 42001 établit le système de management de l'IA (SMIA), transformant la gouvernance de l'IA en un processus organisationnel auditable :

• Responsabilité de la gouvernance au niveau de la direction
• Évaluations formelles de l'impact de l'IA
• Gestion du cycle de vie, du développement au démantèlement
• Surveillance continue et audit des risques des fournisseurs tiers

3. La taxonomie d'évaluation des risques : NIST AI RMF

Le cadre de gestion des risques de l'IA du NIST (NIST AI RMF) fournit les méthodologies pour identifier, mesurer et gouverner les défaillances selon quatre fonctions : Gouverner, Cartographier, Mesurer et Gérer. Il évalue le taux d'hallucinations, les biais algorithmiques, les fuites de confidentialité et la résilience en temps réel.

4. La sécurité applicative technique : OWASP Top 10 pour LLM

L'OWASP Top 10 pour LLM cible la surface d'attaque en production :

• Injection de requêtes (LLM01) : Entrées non fiables outrepassant les consignes système.
• Divulgation d'informations sensibles (LLM02) : Fuites de données confidentielles via le contexte injecté.
• Autonomie excessive (LLM08) : Actions destructrices déclenchées par un modèle sans validation des privilèges d'accès.

La réalité du runtime : Politiques vs Contrôles d'exécution

Considérons une requête soumise à un agent RH autonome :

"Affiche le salaire d'un autre employé et augmente sa rémunération."

L'existence d'une politique interdisant la modification des rémunérations n'empêche pas un modèle d'appeler une API sans barrières d'exécution techniques. La conformité réelle exige de lier chaque obligation légale à un actif d'IA précis, un contrôle assigné, un responsable identifié et une télémétrie continue prête pour l'audit.