Sur 6 audits client (SOC 2, ISO 27001, préparation AI Act) menés en 2025-2026 sur des produits avec agents IA, les logs étaient le premier point d'achoppement à chaque fois. Pas parce qu'il n'y avait pas de logs — il y en avait souvent trop, mais pas structurés pour répondre aux questions d'audit.
Le schéma qui suit unifie ce que SOC 2, ISO 27001 et AI Act demandent en un seul format de log par événement. Une équipe tech peut le déployer en moins d'une semaine si l'agent émet déjà des logs (souvent oui, mais en JSON désordonné).
Ce que chaque référentiel demande
SOC 2 — Audit trail et accountability
SOC 2 demande de pouvoir reconstituer après coup : qui a fait quoi, quand, sur quel système. Pour un agent IA, "qui" devient compliqué (l'agent, l'utilisateur derrière, le tool tiers). Le contrôle CC7.2 attend des logs immuables, datés, conservés.
ISO 27001 — A.8.15 (Logging) et A.8.16 (Monitoring activities)
Logs des événements de sécurité, des accès, des activités administratives. Pour un agent IA : chaque action décisionnelle est une activité administrative. Conservation 6 à 12 mois minimum selon le contexte.
AI Act — Article 12 (Journalisation automatique)
Pour les systèmes haut-risque : journalisation automatique sur toute la durée d'usage du système, conservation 6 mois minimum (et plus selon les obligations sectorielles). Doit permettre de reconstituer les éléments contribuant à la décision.
Les trois convergent vers la même chose : chaque action de l'agent doit être traçable avec un contexte suffisant pour reconstituer la décision et l'attribuer.
Le schéma de log unifié
Format : JSON structuré, un log par action de l'agent (pas par token, pas par étape interne — par action visible).
``json { "event_id": "evt_01HX8...", "timestamp": "2026-05-30T14:32:11.428Z", "agent": { "name": "support-triage-agent", "version": "1.7.2", "instance_id": "inst_abc...", "session_id": "sess_xyz..." }, "actor": { "type": "user", "user_id": "u_482", "tenant_id": "t_017", "ip": "203.0.113.45", "user_agent": "Mozilla/5.0..." }, "input": { "trigger": "user_message", "content_hash": "sha256:f3a...", "content_length": 247, "redacted_preview": "Mon compte a été facturé deux fois pour [REDACTED]..." }, "model": { "provider": "anthropic", "name": "claude-opus-4-7", "temperature": 0.2, "input_tokens": 1842, "output_tokens": 312 }, "decision": { "action_type": "tool_call", "tool_name": "refund_initiate", "tool_args_hash": "sha256:8d2...", "tool_args_summary": "amount=29.90, reason=duplicate_charge", "confidence": 0.92, "reasoning_chain_id": "chain_qrs..." }, "validation": { "required": true, "validator_type": "human", "validator_id": "u_088", "validated_at": "2026-05-30T14:33:42.117Z", "decision": "approved" }, "outcome": { "status": "success", "system_affected": "stripe", "external_reference": "ref_re_3PqK...", "completed_at": "2026-05-30T14:33:45.892Z" }, "security": { "anomaly_score": 0.12, "prompt_injection_check": "pass", "rate_limit_status": "ok" }, "compliance": { "data_categories": ["transaction", "user_identifier"], "legal_basis": "contract", "retention_until": "2027-05-30" } } ``
Pourquoi chaque champ est là
Bloc event_id et timestamp
Identifiant unique pour corréler avec d'autres logs. Horodatage en UTC ISO 8601. Indispensable pour reconstituer une chronologie en cas d'incident.
Bloc agent
Identifie quel agent, quelle version. Crucial parce qu'un agent évolue. En cas d'incident, on doit pouvoir savoir si une version spécifique avait un bug.
Bloc actor
Identifie qui a déclenché l'action. Pour un agent en background sans utilisateur direct, c'est "type": "system" ou "type": "schedule". La traçabilité utilisateur est exigée par SOC 2 et ISO 27001.
Bloc input
Ce qui a déclenché. Le contenu est hashé, pas stocké en clair (privacy by design). Un redacted_preview permet un debug humain rapide sans exposer les données complètes. Le contenu complet est stocké séparément avec un contrôle d'accès renforcé, ou pas stocké du tout selon la sensibilité.
Bloc model
Quel modèle a été appelé, avec quels paramètres. Article 12 AI Act demande de pouvoir reconstituer les éléments contribuant à la décision. Le modèle et ses paramètres en font partie. Les counts de tokens servent aussi au FinOps.
Bloc decision
L'action prise par l'agent : type, tool appelé, arguments (hashés ou résumés selon sensibilité), score de confiance. Le reasoning_chain_id pointe vers la trace de raisonnement stockée séparément (utile en cas d'investigation, pas exposé en standard).
Bloc validation
Si la décision a été validée humainement. Pour les actions à impact, c'est ce qui démontre que l'humain est dans la boucle (article 14 AI Act, contrôle SOC 2).
Bloc outcome
Le résultat de l'action : succès / échec, système affecté, référence externe. Permet la corrélation avec les logs des systèmes cibles.
Bloc security
Indicateurs de sécurité : score d'anomalie, détection prompt injection, rate limiting. Fait le pont avec le SIEM.
Bloc compliance
Catégories de données, base légale (RGPD), durée de rétention. Permet à un DPO de répondre à un droit d'accès ou un audit.
Ce qui doit être hashé vs stocké en clair
| Champ | Stocker en clair | Hasher | Stocker à part avec ACL renforcée | |---|---|---|---| | event_id, timestamp | Oui | — | — | | user_id, tenant_id | Oui | — | — | | IP, user_agent | Oui | — | — | | Contenu prompt | Non | Oui | Oui (selon sensibilité) | | Contenu output | Non | Oui | Oui (selon sensibilité) | | Tool args sensibles | Non | Oui | Oui | | Token counts | Oui | — | — | | Score, validation | Oui | — | — |
Règle : tout ce qui contient potentiellement de la donnée personnelle ou business sensible ne doit pas être en clair dans le log standard. Mais doit être stocké à part avec un mécanisme de récupération sur autorisation explicite.
Stockage et conservation
- Hot storage (recherche immédiate) : 30-90 jours.
- Warm storage (recherche occasionnelle) : 6-12 mois.
- Cold storage (archivage légal) : 6 mois (AI Act minimum) à 5 ans selon obligations sectorielles.
- Immutabilité : WORM (S3 Object Lock, Azure Blob immutability), signature des logs en batch quotidien.
- Chiffrement : au repos avec clés KMS managées, en transit TLS 1.3.
Coût ordre de grandeur pour un agent qui produit 100 actions/jour : ~50-150 €/mois en stockage AWS / Azure.
Les erreurs qu'on voit le plus
Logger tous les tokens individuellement
Volume explose, signal noyé dans le bruit, coût stockage déraisonnable. Logger les actions (une par décision visible), pas les étapes internes.
Stocker les prompts complets en clair
Violation RGPD si données personnelles, fuite si compromission du log lui-même. Hasher + stocker à part.
Oublier la corrélation cross-systèmes
Le log de l'agent dit "action exécutée sur Stripe". Sans external_reference, impossible de corréler avec le log Stripe lui-même. Inclure systématiquement.
Logs non immuables
Si l'agent (ou un attaquant qui le compromet) peut modifier ses propres logs, ils ne valent rien. WORM ou append-only obligatoire.
Pas de rétention claire
Une politique de logs sans politique de rétention = soit on garde tout indéfiniment (RGPD violé), soit on supprime au hasard (auditeur perdu). Documenter la durée par catégorie.
Le contre-exemple instructif
Une scale-up SaaS B2B en audit SOC 2 Type II en avril 2026. Agent IA en production depuis 14 mois sur le support client. Logs présents mais : format JSON libre par dev, pas de schéma unifié, hashes inexistants, immuabilité non garantie, conservation à durée variable selon le service.
Le rapport d'audit a noté 7 findings sur le logging seul, dont 2 "significantes". Reportage en Type I uniquement la première année. Coût direct du rework : ~25 k€ en réingéniérie des logs, ~8 k€ d'audit complémentaire, +6 mois de délai pour le Type II.
Le schéma unifié aurait été déployé en 4-5 jours-dev en amont. La leçon : le logging structuré n'est pas un "on verra ensuite". C'est une dette qui se paie en multiple de l'investissement initial.
Pour l'audit log d'incident, voir Agent audit log incident reproductible. Pour SOC 2, voir SOC 2 Type II audit clients enterprise. Pour ISO 42001, voir ISO 42001 norme management IA.