Mon LLM a halluciné une vraie donnée client : que faire

## Containment Checklist
 
- [ ] Capturer les preuves
  - [ ] Screenshot de la conversation complète
  - [ ] request_id / trace_id de la requête
  - [ ] Timestamp précis (UTC)
  - [ ] User_id du destinataire
  - [ ] Logs structurés correspondants
 
- [ ] Identifier les acteurs
  - [ ] Qui a vu la donnée (utilisateur destinataire) ?
  - [ ] À qui appartient la donnée (client réel) ?
  - [ ] Étaient-ils autorisés à voir cette information ?
 
- [ ] Containment immédiat
  - [ ] Désactiver temporairement le chatbot/feature si risque récidive
  - [ ] Si feature : disable feature flag
  - [ ] Si chatbot : maintenance mode avec message informatif
  - [ ] Vérifier : la donnée a-t-elle été partagée plus loin ?
 
- [ ] Notification immédiate
  - [ ] SOC (alerte critical)
  - [ ] AI Officer
  - [ ] DPO (RGPD)
  - [ ] CISO si haute sensibilité
  - [ ] Manager produit

# investigation.py
import json
 
def investigate_incident(request_id: str):
    """Trace forensic à partir du request_id."""
    
    # 1. Récupérer le log structuré complet
    event = fetch_log_by_request_id(request_id)
    
    print(f"=== INCIDENT INVESTIGATION ===")
    print(f"Request ID: {request_id}")
    print(f"Timestamp: {event['ts']}")
    print(f"User: {event['actor']['user']['uid']}")
    print(f"Session: {event['actor']['session']['uid']}")
    print()
    
    # 2. Examiner le prompt complet (system + user + history)
    print("=== PROMPT COMPLET ===")
    print("System:", event['gen_ai']['content'].get('system_prompt_hash'))
    print("User:", event['gen_ai']['content']['prompt_redacted'])
    print("History length:", event['gen_ai']['content']['message_history_length'])
    print()
    
    # 3. Examiner les RAG retrievals
    print("=== RAG RETRIEVALS ===")
    rag_doc_ids = event['gen_ai']['content'].get('rag_doc_ids', [])
    for doc_id in rag_doc_ids:
        doc = fetch_rag_document(doc_id)
        print(f"  {doc_id}: tenant={doc['tenant_id']}, source={doc['source']}")
        # ALERTE si tenant != user.tenant_id
    print()
    
    # 4. Examiner les tool calls
    print("=== TOOL CALLS ===")
    for tc in event['gen_ai']['content'].get('tool_calls', []):
        print(f"  {tc['name']}: args_hash={tc['args_hash']}")
    print()
    
    # 5. Reproduction test
    print("=== REPRODUCTION TEST ===")
    same_prompt_responses = await test_reproduction(
        prompt=event['gen_ai']['content']['prompt_redacted'],
        rag_context=rag_doc_ids,
        n_attempts=10,
    )
    print(f"  Same hallucination occurred: {sum(r['leaked_data'] for r in same_prompt_responses)}/{len(same_prompt_responses)}")
    print()
    
    # 6. Identifier source probable
    sources = analyze_potential_sources(event)
    print("=== SOURCES POTENTIELLES ===")
    for source, score in sources:
        print(f"  {source}: probabilité {score:.0%}")
 
 
def analyze_potential_sources(event):
    """Détermine la source probable du leak."""
    findings = []
    
    # 1. RAG cross-tenant ?
    user_tenant = event['actor'].get('org_id')
    rag_doc_ids = event['gen_ai']['content'].get('rag_doc_ids', [])
    cross_tenant_docs = [
        d for d in rag_doc_ids
        if fetch_rag_document(d).get('tenant_id') != user_tenant
    ]
    if cross_tenant_docs:
        findings.append(("RAG cross-tenant leak", 0.9))
    
    # 2. Fine-tuning data avec PII ?
    if uses_finetuned_model(event['model']['name']):
        findings.append(("Fine-tuning data leak (PII in training)", 0.6))
    
    # 3. Memory cross-user ?
    session = event['actor']['session']['uid']
    if shared_memory_pattern_detected(session):
        findings.append(("Memory cross-user leak", 0.7))
    
    # 4. Hallucination par hasard
    findings.append(("True hallucination matching real data by chance", 0.05))
    
    return sorted(findings, key=lambda x: -x[1])

## Decision Checklist
 
### Évaluation breach RGPD
- [ ] Donnée réelle confirmée ? (oui/non)
- [ ] Personne autorisée ? (oui/non)
- [ ] Catégorie de données :
  - [ ] PII basique (nom, email)
  - [ ] PII sensible (coordonnées détaillées)
  - [ ] Données sensibles Art. 9 (santé, etc.)
  - [ ] Données financières
- [ ] Risque pour la personne :
  - [ ] Faible (information limitée)
  - [ ] Moyen (information identifiante)
  - [ ] Élevé (peut entraîner discrimination, fraude, perte significative)
  
→ Si breach + risque élevé : notification utilisateurs Art. 34 obligatoire
 
### Évaluation ampleur
- [ ] Bug systémique ou cas isolé ?
  - Test reproduction : succès récidive sur N tentatives
  - Si > 5/10 → systémique
- [ ] Combien d'utilisateurs potentiellement impactés ?
  - Si systémique : audit logs des 30 derniers jours
- [ ] Combien de clients dont les données peuvent fuiter ?
 
### Communication
- [ ] CNIL : notification dans 72h post-détection (formulaire en ligne)
- [ ] Utilisateurs impactés : si risque élevé, contact direct (email/courrier)
- [ ] Clients dont les données ont fuité : communication selon contexte
- [ ] Interne : CISO, comité IA, métier
- [ ] Externe : presse / public ? (avec Communication / Direction)

## Action Plan
 
### Notifications obligatoires
 
#### CNIL (Art. 33 RGPD), < 72h
- [ ] Préparer dossier notification
  - Description nature violation
  - Catégories et nombre approximatif personnes
  - Coordonnées DPO
  - Conséquences probables
  - Mesures prises ou proposées
- [ ] Soumettre via formulaire CNIL
- [ ] Suivi de la notification (référence dossier)
- [ ] Notification incomplète possible si pas tout connu, complétée ensuite
 
#### Utilisateurs (Art. 34 RGPD), si risque élevé
- [ ] Préparer modèle de communication
  - Nature violation (clair, sans jargon)
  - Données concernées
  - Conséquences possibles
  - Mesures prises
  - Contact DPO
- [ ] Validation Legal + Direction
- [ ] Envoi (email, courrier selon contexte)
- [ ] Hotline / FAQ pour questions
 
### Mitigation technique immédiate
 
#### Si RAG cross-tenant détecté
- [ ] Audit RAG store : vérifier filtrage tenant
- [ ] Hot fix : forcer filter immutable côté serveur
- [ ] Re-indexer si nécessaire
- [ ] Alerter SOC pour monitoring autres tentatives
 
#### Si fine-tuning data avec PII
- [ ] Retirer immédiatement modèle fine-tuné de production
- [ ] Rollback vers modèle base
- [ ] Re-finetune avec data pseudonymisée
- [ ] Auditer dataset training
 
#### Si memory cross-user
- [ ] Désactiver memory partagée
- [ ] Patch isolation per-user
- [ ] Purge memory si compromission
 
#### Si vraie hallucination (cas A)
- [ ] Pas de mitigation technique data (rien n'a fuité)
- [ ] Évaluer engagement contractuel (cf Air Canada)
- [ ] Décision business : honorer ou contester ?

# Notification de violation de données personnelles
# Article 33 RGPD
 
Date de notification : 2026-05-03
Référence interne : INC-2026-014
 
## 1. Description de la violation
 
**Nature** : Divulgation potentielle de données client via chatbot IA.
 
**Contexte** : Le 1er mai 2026 à 09:23 UTC, un utilisateur de notre 
plateforme [App] a reçu, en réponse à une question légitime, des 
informations potentiellement appartenant à un autre client. La donnée 
mentionnée par le chatbot (nom, email partiel, numéro de commande) 
correspond à un client réel non autorisé à être communiqué à 
l'utilisateur ayant posé la question.
 
**Cause technique préliminaire** : RAG cross-tenant, filtrage défaillant 
suite à une mise à jour récente du moteur de recherche documentaire.
 
## 2. Catégories et nombre approximatif personnes
 
**Personnes affectées (dont données ont été divulguées)** :
- Catégorie : clients particuliers EU (B2C)
- Nombre estimé : 1 à 50 personnes (investigation en cours pour préciser)
 
**Personnes ayant reçu la divulgation** :
- Catégorie : utilisateurs de la plateforme
- Nombre estimé : équivalent (1 à 50)
 
## 3. Catégories de données concernées
 
- Nom et prénom
- Email (partiel observé)
- Numéro de commande
- (Investigation en cours pour identifier l'étendue exacte)
 
## 4. Conséquences probables
 
**Risque pour les personnes** : modéré.
 
Justification : données identifiantes mais non sensibles (pas de RGPD Art. 9, 
pas de données financières détaillées, pas de mots de passe).
 
## 5. Mesures prises ou proposées
 
**Containment immédiat (déjà fait)** :
- Désactivation de la fonctionnalité concernée à 10:15 UTC le 1er mai
- Investigation forensic en cours
- Audit logs des 30 derniers jours pour identifier ampleur
 
**Mitigation technique (en cours)** :
- Patch du filtrage tenant immutable (déploiement prévu 2026-05-04)
- Audit complet du moteur RAG
- Tests automatisés cross-tenant ajoutés au CI
 
**Notification utilisateurs** :
- En cours d'évaluation selon Art. 34 (risque élevé ou modéré)
- Décision attendue 2026-05-05
 
## 6. Contact
 
Délégué à la protection des données (DPO) :
Marie Lambert
dpo@zerodaysupport.com
+33 1 XX XX XX XX
 
## 7. Notification complémentaire
 
Cette notification pourra être complétée à mesure que l'investigation 
progresse, conformément à l'Art. 33.4 RGPD.

Sujet : Information importante concernant la sécurité de vos données
 
Madame, Monsieur,
 
Nous tenons à vous informer d'un incident de sécurité concernant vos 
données personnelles, conformément à nos obligations en vertu du 
Règlement Général sur la Protection des Données (RGPD).
 
## Que s'est-il passé ?
 
Le 1er mai 2026, un dysfonctionnement de notre assistant IA (chatbot) a 
pu permettre la divulgation de certaines informations vous concernant à 
un autre utilisateur de notre plateforme. Plus précisément :
 
- Votre nom, prénom
- Votre email
- Le numéro d'une de vos commandes
 
Aucune donnée bancaire, mot de passe, ou information sensible n'a été 
divulguée.
 
## Ce que nous avons fait
 
Dès la détection (le 1er mai à 10:15), nous avons :
- Désactivé immédiatement la fonctionnalité concernée
- Lancé une investigation technique
- Notifié la CNIL (le 1er mai)
- Identifié et corrigé la cause technique
 
## Conséquences possibles pour vous
 
Le risque principal est que la personne ayant reçu ces informations 
puisse vous contacter en se faisant passer pour notre service client 
(phishing). Nous vous recommandons :
- D'être vigilant·e à toute communication non sollicitée se réclamant 
  de notre marque
- De ne JAMAIS communiquer d'informations sensibles (mot de passe, 
  CB) suite à un contact non sollicité
- De nous contacter en cas de doute sur l'authenticité d'une 
  communication
 
## Vos droits
 
Vous pouvez à tout moment exercer vos droits RGPD (accès, rectification, 
effacement, portabilité, opposition) en contactant notre DPO :
 
Marie Lambert, dpo@zerodaysupport.com
 
Vous pouvez également déposer une réclamation auprès de la CNIL :
https://www.cnil.fr
 
## Pour toute question
 
Nous avons mis en place une hotline dédiée : 0X XX XX XX XX
ou par email : incidents@zerodaysupport.com
 
Nous nous excusons pour cet incident et la gêne occasionnée. Votre 
confiance est notre priorité, et nous renforçons en continu la sécurité 
de nos systèmes pour prévenir toute récidive.
 
Cordialement,
 
Direction ZerodaySupport

## Évaluation engagement potentiel
 
1. **Quel sujet ?** Politique remboursement / garantie / tarif / 
   conditions vente / livraison ?
   
2. **Quel niveau d'engagement** ?
   - Promesse explicite ("vous serez remboursé")
   - Implicite (description politique inexistante)
   - Suggestion vague (peu d'engagement)
 
3. **Le client a-t-il agi sur cette information ?**
   - Acheté un service basé sur une politique inventée ?
   - Engagé dépense pour profiter d'une remise inexistante ?
   - Seulement reçu l'info sans agir ?
 
4. **Décision business**
   - Honorer la fausse promesse (coût direct mais préserve réputation)
   - Contester (risque juridique + médiatique)
   - Solution intermédiaire (geste commercial sans reconnaissance)
 
→ Décision avec Direction + Legal + Communication. Jamais en solo.

# Liste sujets engageants à auditer
ENGAGING_TOPICS = [
    "politique remboursement",
    "politique garantie",
    "conditions vente",
    "tarifs",
    "délais livraison",
    "promotion / remise",
    "bonus / fidélité",
    "service après-vente",
]
 
def is_engaging_question(query: str) -> bool:
    """Détecte si la question porte sur sujet engageant."""
    keywords = [
        "remboursement", "refund", "garantie", "warranty",
        "tarif", "prix", "promotion", "remise", "discount",
        "politique", "policy", "condition", "delai",
    ]
    return any(kw in query.lower() for kw in keywords)
 
 
async def safe_response_engaging(query: str, rag_cgv_authoritative: list[str]):
    """Pour sujets engageants : grounding strict + disclaimer."""
    
    if not rag_cgv_authoritative:
        # Pas de source autoritaire → escalation humaine
        return {
            "answer": "Pour cette question importante, je vous mets en relation avec un conseiller qui pourra vous donner une réponse officielle.",
            "escalate": True,
        }
    
    # Grounding strict
    grounded_prompt = f"""Tu réponds UNIQUEMENT en utilisant les CGV/politiques 
officielles fournies ci-dessous. Si l'information n'est pas dans les sources, 
réponds 'Information non disponible dans nos politiques officielles, 
contactez un conseiller'.
 
NE JAMAIS inventer une politique. Citer la source.
 
SOURCES OFFICIELLES :
{chr(10).join(rag_cgv_authoritative)}
 
QUESTION : {query}
"""
    
    answer, _ = await call_llm([{"role": "user", "content": grounded_prompt}])
    
    # Disclaimer obligatoire
    answer += "\n\n⚠️ Cette information est fournie à titre indicatif. Pour toute décision importante, contactez notre service client : support@zerodaysupport.com"
    
    return {"answer": answer, "escalate": False}
 
 
@app.post("/chat")
async def chat(req: ChatRequest):
    if is_engaging_question(req.message):
        rag_cgv = await retrieve_authoritative_cgv(req.message)
        return await safe_response_engaging(req.message, rag_cgv)
    
    # Sinon flow normal
    return await standard_response(req.message)

# Post-mortem, Incident hallucination données client
 
**Référence** : INC-2026-014
**Date incident** : 2026-05-01 09:23 UTC
**Date détection** : 2026-05-01 09:35 UTC (12 min après)
**Date publication post-mortem** : 2026-05-15
**Owner** : Marie Lambert (DPO) + Jean Bernard (RSSI)
 
## 1. Résumé exécutif
 
Le 1er mai 2026, un défaut de filtrage tenant dans notre RAG store a 
permis qu'un utilisateur reçoive en réponse de notre chatbot IA des 
informations partielles d'un autre client. Investigation a confirmé un 
bug introduit dans la mise à jour 2.4.0 du moteur RAG (déployée 
2026-04-28). 47 utilisateurs potentiellement impactés sur les données 
de 12 clients. Notification CNIL effectuée le 1er mai. Notification 
utilisateurs effectuée le 3 mai. Patch déployé le 4 mai. Aucune 
récidive depuis. Statut : RÉSOLU.
 
## 2. Timeline détaillée
 
| Time UTC | Action |
|---|---|
| 2026-05-01 09:23 | Première occurrence (request_id: req_abc123) |
| 09:35 | Utilisateur destinataire signale via support |
| 09:42 | SOC alerté |
| 09:55 | AI Officer + DPO notifiés |
| 10:15 | Containment : désactivation chatbot |
| 10:30 | Investigation lance |
| 11:45 | Cause identifiée : RAG tenant filter cassé en 2.4.0 |
| 13:00 | Audit logs : 47 occurrences sur 30 jours |
| 14:30 | Comité crise : décision notifier CNIL |
| 16:00 | Notification CNIL soumise (référence Y-2026-0481) |
| 17:00 | Évaluation Art. 34 : notification utilisateurs requise |
| 2026-05-02 09:00 | Notification utilisateurs préparée |
| 11:00 | Validation Legal + Direction |
| 14:00 | Envoi notifications |
| 2026-05-04 18:00 | Patch 2.4.1 déployé production |
| 2026-05-05 | Réactivation chatbot avec monitoring renforcé |
| 2026-05-15 | Post-mortem publié |
 
## 3. Root Cause Analysis
 
### Cause technique
 
Mise à jour RAG engine v2.4.0 a introduit un changement dans la 
fonction `_apply_filters()` qui rendait le filtre `tenant_id` optionnel 
au lieu d'obligatoire en interne. Quand le LLM générait une query 
sémantique large, le filtre tenant pouvait être bypassé.
 
```python
# Code v2.3.x (correct)
def _apply_filters(query, filters):
    assert "tenant_id" in filters, "tenant_id required"
    return apply_all_filters(query, filters)
 
# Code v2.4.0 (bug introduit)
def _apply_filters(query, filters):
    if "tenant_id" in filters:
        return apply_all_filters(query, filters)
    return query  # ← bug : pas de filter si manquant