Comment reconstruire ce que votre IA a fait après un incident
Réponse courte
Parce que Senthex proxifie chaque appel, il conserve un enregistrement par appel centré métadonnées — modèle, route, verdicts et scores des shields, horodatages et comptes de tokens. Après un incident, vous pouvez reconstruire la chronologie de ce que votre IA a fait, tous fournisseurs confondus, et dans le pilote v1.1.7 prouver que cette chronologie n'a pas été éditée. Ce qu'il ne rejoue pas par défaut : les prompts et complétions verbatim, qui ne sont pas stockés.
Que pouvez-vous réellement reconstruire après un incident IA ?
À partir de l'enregistrement centré métadonnées, vous reconstruisez l'histoire opérationnelle d'une session :
- Quels appels ont eu lieu — vers quel modèle et fournisseur, avec quel statut ;
- Quels shields ont déclenché — verdict, score et version de règle pour chacun, pour voir ce qui a été signalé, bloqué ou rédigé ;
- Dans quel ordre, et quand — horodatages et comptes de tokens donnent la séquence et le timing.
C'est suffisant pour cadrer le rayon d'impact (« quelles sessions ont touché l'entrée empoisonnée ? »), bâtir la chronologie d'incident, et remettre à la sécurité un enregistrement exportable vers un SIEM — sans faire de votre journal d'audit une seconde copie des prompts clients.
Pourquoi les logs applicatifs ordinaires échouent-ils en investigation ?
Les logs applicatifs sont écrits par le service même qui a pris la décision : ils peuvent être édités ou tournés, et corrèlent rarement les appels entre plusieurs fournisseurs de modèles. Quand la question est « prouver à un client ou un régulateur ce qui s'est exactement passé », des logs dispersés et mutables sont difficiles à assumer. Un proxy voit tout le chemin d'appel au même endroit, l'enregistre selon un calendrier défini, et — dans le pilote — vous laisse prouver que l'enregistrement est intact.
Comment Senthex reconstruit-il une session ?
Chaque appel est un enregistrement structuré, corrélé pour parcourir une session de bout en bout. Vous exportez la fenêtre pertinente vers votre dashboard ou SIEM et lisez la séquence directement. Pour l'intégrité, le pilote d'audit vérifiable (v1.1.7) chaîne les enregistrements en SHA-256 et ancre la chaîne à un horodatage RFC 3161, et un vérifieur offline le recontrôle — donc « voici ce qui s'est passé, et ça n'a pas été édité » est confirmable indépendamment par un auditeur, pas seulement affirmé par vous.
Ce que cela ne vous donne pas (la partie honnête)
Trois limites, dites d'emblée :
- Pas le contenu verbatim par défaut. Senthex journalise des métadonnées, pas les prompts et complétions bruts. Vous reconstruisez ce qui a tourné et ce qui a déclenché, pas les mots exacts, sauf si vous avez délibérément activé la capture de contenu (qui a ses propres compromis de confidentialité).
- Pas une trace complète si la journalisation était coupée. Un enregistrement prouve ce qui a été journalisé, jamais ce qui n'a jamais été capturé.
- La preuve d'intégrité est un pilote. La version publiée fait la journalisation de métadonnées ; la chaîne SHA-256 + RFC 3161 + vérifieur offline est le pilote v1.1.7.
Comment cela s'inscrit-il dans l'EU AI Act et les obligations de signalement ?
L'enregistrement par appel est la matière première de la tenue de registres (article 12) et de la rétention (article 19, au moins six mois) — pas l'article 15. Il aide aussi quand s'appliquent les obligations de signalement du règlement sur la cyber-résilience (CRA) (incidents graves et vulnérabilités activement exploitées, à partir du 11 septembre 2026) : une chronologie défendable se produit bien plus facilement depuis un enregistrement côté proxy que depuis des logs applicatifs reconstitués. Voir le mapping EU AI Act pour le détail ligne à ligne.
Reconstruire un incident IA
| Ce dont l'investigation a besoin | Logs applicatifs / base dispersés | Enregistrement par appel Senthex |
|---|---|---|
| Quels appels cette session a-t-elle faits ? | Peut-être — si chaque service a journalisé de façon cohérente | Oui — un enregistrement par appel, au même endroit |
| Chronologie multi-fournisseurs (OpenAI + Anthropic + …) ? | Rarement corrélée | Oui — le proxy voit le trafic de chaque fournisseur |
| Quel shield a déclenché, et pourquoi ? | Non | Verdict, score et version de règle par shield |
| Pouvez-vous prouver que l'enregistrement n'a pas été édité ? | Non | Oui, dans le pilote v1.1.7 (chaîne SHA-256 + RFC 3161) |
| Prompts et complétions verbatim ? | Seulement si vous les avez stockés (un risque de confidentialité) | Non par défaut — métadonnées, pas corps bruts |
Questions fréquentes
Comment reconstruire ce que mon IA a fait après un incident ?
Utilisez l'enregistrement par appel de Senthex : quel modèle et fournisseur chaque appel a touché, quels shields ont déclenché avec leur verdict et score, et les horodatages qui donnent la séquence. Vous exportez la fenêtre pertinente vers votre dashboard ou SIEM et parcourez la session de bout en bout. Dans le pilote v1.1.7, vous pouvez aussi prouver que l'enregistrement n'a pas été édité.
Puis-je rejouer le prompt et la réponse exacts ?
Pas par défaut. Senthex journalise des métadonnées, pas les prompts et complétions bruts ; vous reconstruisez donc ce qui a tourné et ce qui a déclenché — pas les mots verbatim — sauf si vous avez délibérément activé la capture de contenu, qui a ses propres compromis de confidentialité. Le défaut honnête est centré métadonnées.
En quoi est-ce différent de garder des logs applicatifs ?
Les logs applicatifs sont écrits par le service qui a pris la décision, peuvent être édités ou tournés, et corrèlent rarement les appels entre fournisseurs. Un proxy enregistre tout le chemin d'appel au même endroit selon un calendrier défini, et dans le pilote laisse un auditeur vérifier que l'enregistrement est intact plutôt que de vous croire sur parole.
Cela prouve-t-il que la chronologie n'a pas été altérée ?
Dans le pilote v1.1.7, oui — les enregistrements sont chaînés en SHA-256 et ancrés à un horodatage RFC 3161, et un vérifieur offline recontrôle la chaîne. C'est tamper-evident, pas tamper-proof : les modifications sont détectables, pas empêchées. La version publiée fait la journalisation de métadonnées.
Puis-je envoyer les enregistrements vers mon SIEM ?
Oui — les enregistrements sont exportables, ce qui rend une trace côté proxy utilisable pour la réponse à incident et le suivi post-commercialisation, plutôt qu'un simple dashboard à contempler.
Construisez la chronologie avant d'en avoir besoin
L'enregistrement n'aide que s'il tourne déjà quand l'incident survient. Démarrez sur le plan Free pour voir le dashboard par appel, et lisez comment prouver que la trace est intacte. Pour un déploiement self-host intégré au SIEM, parlons-en.