Journaux d'audit sans contenu : comment nous prouvons ce que le modèle a fait sans conserver les prompts

Toute action administrative effectuée dans AI Suite produit une ligne d'audit JSONL. La ligne enregistre l'horodatage, l'adresse e-mail de l'acteur, le verbe d'action, la ressource concernée, le X-App-Id du client à l'origine de l'action et un hash stable qui permet à un évaluateur de corréler la ligne avec des événements ultérieurs. La ligne n'enregistre rien des entrées ou sorties du modèle. Aucun texte de prompt, aucun texte de complétion, aucun contenu de document, aucune entité extraite. Ce choix — sans contenu par conception — est ce qui rend la ligne d'audit utile aux évaluateurs achats et conformité, et il mérite d'être explicité.

Ce que contient une ligne d'audit, et ce qu'elle ne contient pas

Une ligne représentative, légèrement caviardée :

{"ts":"2026-06-05T09:14:22Z","actor":"[email protected]","action":"license.assign",
 "subject":"[email protected]","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

Ce qu'elle contient : suffisamment de métadonnées pour répondre aux questions sur les obligations du déployeur que posent les auditeurs — qui a fait quoi, quand, sur quelle ressource, depuis quel client. Ce qu'elle ne contient pas : aucune charge utile issue du workflow IA. Si l'action a appelé un modèle (ce n'est pas le cas dans cet exemple, mais cela pourrait l'être), il y aurait une ligne consignant l'événement d'invocation, mais aucune trace du prompt ni de la réponse dans notre infrastructure.

Cette séparation est délibérée. La ligne d'audit est la preuve qu'une action a eu lieu. Le contenu de l'action — le prompt envoyé au modèle, la réponse renvoyée — vit sur le propre matériel du déployeur, régi par sa propre politique de rétention. Nous ne le voyons jamais.

Pourquoi le contenu reste en dehors de la ligne

Deux raisons, l'une réglementaire et l'autre opérationnelle.

Réglementaire : l'EU AI Act impose aux déployeurs d'IA à haut risque de conserver les journaux « pendant une durée appropriée », de surveiller le fonctionnement du système et de démontrer la conformité sur demande ^[1]. L'obligation incombe au déployeur de démontrer ce qui s'est passé. Les API LLM cloud répondent à cela en stockant le prompt et la réponse sur l'infrastructure du fournisseur, ce qui transfère le problème de gestion des données au fournisseur — et crée un second périmètre de conformité que le déployeur ne maîtrise pas. L'audit local sans contenu répond à la même question réglementaire sans ce transfert : le déployeur conserve le contenu, dans son propre stockage, sous ses propres règles de rétention.

Opérationnelle : chaque octet de contenu de modèle stocké est un octet qu'il faut chiffrer, contrôler en accès, conserver, supprimer dans les délais et produire en e-discovery. Les lignes sans contenu sont compactes (quelques centaines d'octets), de forme fixe, en ajout seul et trivialement sérialisables dans le SIEM existant du déployeur. Elles constituent la plus petite unité probante qui satisfait encore à l'obligation.

À quoi cela correspond dans les grands cadres

Le NIST AI RMF 1.0 désigne l'auditabilité comme une dimension centrale de l'IA digne de confiance et demande aux déployeurs de tenir des « relevés des actions système suffisants pour reconstruire les décisions » ^[2]. « Suffisants pour reconstruire » est l'expression clé : la ligne doit permettre à un évaluateur de reconstituer ce qui s'est passé. Une ligne sans contenu y parvient pour les actions administratives (une licence a été émise, une politique a été modifiée, un serveur a été enrôlé) sans conserver le contenu d'une inférence. Pour le volet « contenu d'inférence » de l'obligation, c'est le stockage local du déployeur qui répond à la question.

Le guide de cybersécurité de l'IA de l'ENISA cadre la question sous l'angle de la modélisation des menaces ^[3] : chaque prompt et chaque réponse stockés sur l'infrastructure d'un fournisseur élargit la surface d'attaque du déployeur jusqu'à inclure celle du fournisseur. Retirer le contenu du modèle du côté fournisseur réduit cette surface à ce que le déployeur maîtrise déjà.

La forme que nous livrons — l'interface AI Admin Console, l'audit JSONL du démon aisuite-server et le hook de transfert SIEM par organisation — implémente cela directement. Tout événement administratif atterrit dans une ligne lisible par le déployeur ; aucun contenu de prompt ni de réponse ne quitte jamais le périmètre du déployeur.

À quoi cela ressemble dans une revue d'achats

La question d'achat qui enlise les fournisseurs d'IA cloud est : « où vit le contenu d'inférence, et notre équipe conformité peut-elle le produire à la demande ? » La question d'achat à laquelle l'audit sans contenu répond est la même, avec deux réponses nettes : le contenu vit sur votre matériel, et votre équipe le produit parce qu'elle l'a déjà. La ligne d'audit de notre côté prouve que l'action a eu lieu ; le contenu de votre côté prouve ce que l'action a fait.

Pour le cadrage d'achats plus large — notamment comment ouvrir le questionnaire fournisseur sur ces propriétés plutôt que sur des certifications côté fournisseur — voir Pourquoi les déploiements d'IA on-prem s'enlisent en phase d'achats et l'article sur la conformité à l'EU AI Act.

Ce qui reste à la charge du déployeur

L'audit sans contenu est une propriété structurelle du déploiement, pas une solution de conformité de bout en bout. Le déployeur reste responsable de :

• Définir ce que « suffisant pour reconstruire » signifie pour ses propres workflows — durée de rétention, règles de masquage, posture e-discovery.
• Exploiter le stockage local du contenu (quel que soit le choix du déployeur — système de fichiers, base de documents, stockage blob chiffré) et transférer les lignes d'audit de notre côté vers le SIEM où il les corrèle avec ses propres journaux.
• Rédiger la note sur les obligations du déployeur qui pointe vers cette architecture pendant la phase d'achats.

Notre côté livre l'architecture et le format de la ligne d'audit. Tout ce qui en aval — y compris la politique de rétention du contenu — est l'endroit où l'équipe conformité du déployeur applique ses propres règles.

Références

1. Commission européenne. « AI Act — Regulatory framework on AI. » digital-strategy.ec.europa.eu. Consulté le 2026-06-03.
2. NIST. « AI Risk Management Framework (AI RMF 1.0). » nist.gov/itl/ai-risk-management-framework. Consulté le 2026-06-03.
3. ENISA. « Artificial Intelligence Cybersecurity. » enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Consulté le 2026-06-03.

Articles connexes

• AI Admin Console : ce que fait réellement chacune des six capacités
• Zéro échec de projet depuis 2007 — les règles d'ingénierie qui tiennent ce bilan
• EU AI Act en 2026 : ce que le déploiement on-prem change à la conformité
• Pourquoi les déploiements d'IA on-prem s'enlisent en phase d'achats (et le cadrage qui débloque la situation)
• Tous les articles →