Journaux, surveillance et incidents : construire la chaîne de preuve AI Act.

Concevoir des journaux reliés aux risques

Les systèmes à haut risque permettent l’enregistrement automatique d’événements pendant leur durée de vie. Les événements retenus doivent aider à repérer les situations à risque ou une modification substantielle, faciliter la surveillance après commercialisation et suivre le fonctionnement du système.

Définir conservation et exploitation

Le fournisseur conserve les journaux sous son contrôle pendant une période adaptée à la destination, d’au moins six mois sauf règle contraire applicable. Les durées doivent être conciliées avec les autres droits applicables, notamment la protection des données.

Passer de la surveillance au signalement

Le système de surveillance collecte et analyse activement les données de performance et de conformité. En cas d’incident grave, le fournisseur qualifie le lien avec le système, transmet le signalement dans le délai applicable, préserve les éléments et conduit les investigations et mesures correctives sans compromettre l’analyse des causes.

Journaliser ce qui aide à comprendre et agir

Commencez par les questions auxquelles l’organisation devra répondre : quelle version a produit la sortie, avec quelles entrées et paramètres, qui l’a utilisée, quelle décision a suivi et quelle intervention humaine a eu lieu. Les journaux doivent soutenir la surveillance, les contrôles, l’investigation et la preuve. Collecter tout sans finalité augmente les coûts et les risques sans garantir une meilleure compréhension.

Définissez les identifiants qui permettent de relier système, session, utilisateur, décision, version et dossier métier. Documentez les horodatages, fuseaux, formats et limites. Vérifiez que les journaux sont lisibles, exportables et protégés contre les modifications non autorisées.

Construire une surveillance exploitable

Associez les indicateurs techniques à des signaux métiers : erreurs, dérive, latence, refus, modifications humaines, plaintes, écarts entre populations et usage hors périmètre. Chaque seuil a un propriétaire, un délai de traitement et une action prévue. Une alerte sans circuit de réponse crée seulement du bruit.

Testez le dispositif avec des scénarios. Vérifiez qu’une personne reçoit l’alerte, comprend le contexte, accède aux preuves et peut suspendre ou limiter le système. Conservez le résultat des exercices et corrigez les points de friction avant un incident réel.

Gérer l’incident avec une chronologie commune

La fiche d’incident commence par les faits observés, les personnes et activités affectées, les mesures de protection et les éléments préservés. Elle distingue l’impact confirmé, le risque potentiel et les hypothèses. La chronologie enregistre les événements, décisions, auteurs et preuves. Cette discipline évite que plusieurs équipes travaillent avec des versions contradictoires.

L’analyse des notifications couvre l’AI Act et les autres régimes susceptibles de s’appliquer, notamment les données personnelles, la cybersécurité, le secteur et le contrat. La décision, y compris l’absence de notification, est justifiée et datée par les personnes compétentes.

Apprendre sans diluer les responsabilités

Après correction, vérifiez la non-régression, les conditions de reprise et le risque résiduel. Le retour d’expérience met à jour le registre, les contrôles, les contrats, la formation ou la politique. Il ne se limite pas à la cause technique. Une interface ambiguë, une pression opérationnelle ou une supervision impossible peuvent être déterminantes.

Suivez le délai de détection, d’escalade, de protection, d’investigation et de clôture. Analysez les incidents récurrents et les quasi-incidents. Leur traitement précoce révèle souvent une faiblesse avant qu’elle ne cause un dommage important.