AIPD / DPIA pour agents IA : modèle d'évaluation des facteurs relatifs à la vie privée (Loi 25 + RGPD)

Au Québec, la Loi 25 (article 3.3) impose une évaluation des facteurs relatifs à la vie privée (EFVP — souvent appelée AIPD au Canada francophone, ou DPIA dans la terminologie RGPD article 35) avant toute mise en service d'un système qui traite des renseignements personnels « à risque élevé ». En Europe, l'AIPD est rendue obligatoire par le RGPD article 35 dès qu'un traitement est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes — et la CNIL considère depuis 2024 qu'un agent IA autonome qui orchestre des outils, prend des décisions ou retient un contexte conversationnel sur plusieurs sessions tombe presque toujours dans cette catégorie.

Le problème pratique : il n'existe aucun modèle d'AIPD prêt-à-l'emploi pour les agents IA. Les modèles fournis par la CAI Québec et la CNIL sont génériques (CRM, vidéosurveillance, RH) et ne couvrent ni les particularités d'un LLM (hallucinations, fuite de prompt système, exfiltration via prompt injection), ni les risques propres à un agent (boucle outil-LLM, mémoire long terme, accès filesystem ou API). Ce guide comble le vide : un template d'AIPD à copier-coller, structuré en 9 sections obligatoires, avec les cases déjà cochées pour un agent IA standard et la grille des risques spécifiques. Adossé à ClawPulse pour la couche traçabilité — une AIPD sans preuve de monitoring opérationnel est une AIPD non défendable devant un régulateur.

> Notre pillar de référence : ce satellite complète l'article Monitoring d'agents IA en conformité Loi 25 et RGPD : souveraineté des données. Lisez-le d'abord pour le cadrage juridique général ; ce tutoriel descend au niveau opérationnel.

---

1. Quand une AIPD est-elle obligatoire pour un agent IA ?

Trois cadres se superposent. Pour un agent en production qui traite des données de clients ou d'employés, l'AIPD est obligatoire dans 95% des cas.

1.1 Loi 25 (Québec) — article 3.3

> « Tout projet d'acquisition, de développement et de refonte de système d'information ou de prestation électronique de services impliquant la collecte, l'utilisation, la communication, la conservation ou la destruction de renseignements personnels doit faire l'objet d'une évaluation des facteurs relatifs à la vie privée. »

La CAI ne fournit pas de seuil quantitatif — tout nouveau système qui touche des renseignements personnels (RP) est concerné. Pour un agent IA qui ingère des prompts utilisateurs, c'est automatique. Référence officielle : cai.gouv.qc.ca/loi-25/EFVP.

1.2 RGPD (UE) — article 35

> « Lorsqu'un type de traitement, en particulier par le recours à de nouvelles technologies, et compte tenu de la nature, de la portée, du contexte et des finalités du traitement, est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques, le responsable du traitement effectue, avant le traitement, une analyse de l'impact des opérations de traitement envisagées sur la protection des données à caractère personnel. »

La CNIL publie une liste positive (DPIA obligatoire) et une liste négative. Les agents IA tombent dans la liste positive dès qu'au moins deux des neuf critères WP248 sont réunis. Pour un agent typique :

| Critère WP248 | Agent IA standard ? |

|---|---|

| Évaluation/scoring | ✅ (le LLM score implicitement) |

| Décision automatisée à effet juridique ou significatif | ✅ si l'agent agit (envoi email, création ticket) |

| Surveillance systématique | ⚠️ selon usage |

| Données sensibles | ⚠️ selon prompts |

| Données à grande échelle | ✅ généralement |

| Croisement/combinaison de données | ✅ (RAG, mémoire conversationnelle) |

| Personnes vulnérables | ⚠️ selon contexte (enfants, patients) |

| Usage innovant ou nouvelles solutions techniques | ✅ (LLM = nouvelle techno) |

| Empêche l'exercice d'un droit | ⚠️ rare |

Score moyen : 5/9 critères ✅ → DPIA obligatoire.

1.3 EU AI Act — article 27 (FRIA)

L'AI Act ajoute depuis 2025 une « Fundamental Rights Impact Assessment » (FRIA) pour les systèmes IA à haut risque. Ce n'est pas la même chose qu'une DPIA, mais les deux peuvent être conduites conjointement. Pour les agents qui font des décisions sur le crédit, l'embauche, l'éducation ou les services publics, c'est cumulatif. Référence : Article 27 AI Act.

---

2. Structure d'une AIPD agent IA — les 9 sections obligatoires

Voici le squelette officiel CAI/CNIL adapté agent IA. Chaque section ci-dessous est un modèle prêt à copier-coller dans votre Word/Notion/Confluence.

2.1 Description du traitement

```

Nom du traitement : Agent IA

Finalité primaire :

Finalité secondaire :

Base légale (RGPD art. 6) : ☐ Consentement ☐ Contrat ☐ Obligation légale

☐ Sauvegarde ☐ Mission d'intérêt public

☐ Intérêt légitime → si coché, joindre LIA (Legitimate Interest Assessment)

Responsable du traitement :

Sous-traitants (RGPD art. 28) :

- Fournisseur LLM : ☐ Anthropic ☐ OpenAI ☐ Google ☐ Mistral ☐ Self-hosted

- Hébergement infra : ☐ AWS région ___ ☐ GCP région ___ ☐ Azure région ___ ☐ OVH ☐ Scaleway

- Outil monitoring : ☐ ClawPulse (région ___) ☐ Autre : ___

- Vector DB : ☐ Pinecone ☐ Weaviate ☐ Qdrant self-hosted ☐ pgvector

DPA signé avec chaque sous-traitant ? ☐ Oui pour tous ☐ Liste manquante : ___

```

2.2 Description des données traitées

Crucial pour un agent IA — souvent sous-estimé. Ce qui rentre dans le LLM est un traitement.

```

Catégories de RP traitées par le LLM (entrée) :

☐ Identité (nom, email, téléphone) — via prompt utilisateur

☐ Données de connexion (IP, user-agent, session ID)

☐ Données de localisation

☐ Données économiques/financières

☐ Données de santé (article 9 RGPD — sensible)

☐ Données biométriques (article 9 — sensible)

☐ Opinions politiques/religieuses (article 9 — sensible)

☐ Données relatives à des infractions (article 10)

☐ Données concernant des mineurs

Catégories produites par le LLM (sortie) :

☐ Réponses contenant des RP de l'utilisateur

☐ Réponses contenant des RP de tiers (ex. agent SDR qui parle d'un prospect)

☐ Décisions automatisées (article 22 RGPD)

☐ Inférences (catégorisation, scoring)

Volume estimé :

- Personnes concernées : ___ par mois

- Prompts/requêtes : ___ par mois

- Tokens entrée/sortie : ___ par mois (utile pour le coût ET le risque)

```

2.3 Durées de conservation

Le piège n°1 des agents IA : la « mémoire conversationnelle » longue durée n'a généralement aucune finalité justifiable au-delà de quelques jours.

```

Logs de prompts bruts : ___ jours (recommandé : 7-30 jours)

Logs de réponses brutes : ___ jours (recommandé : 7-30 jours)

Métriques pseudonymisées : ___ jours (recommandé : 365 jours)

Mémoire conversationnelle : ___ jours (recommandé : 24h pour chat ; ≤30j pour assistance)

Embeddings / vectors : ___ jours (recommandé : durée de vie de la KB seulement)

Logs de monitoring (ClawPulse): 30 jours par défaut, configurable

Sauvegardes : ___ jours (recommandé : 90 jours puis purge)

```

Justification obligatoire pour chaque durée — pas de « on garde tout, on verra ».

2.4 Mesures techniques et organisationnelles (RGPD art. 32)

Le cœur opérationnel de l'AIPD. Liste des contrôles que vous mettez en œuvre (pas que vous « envisagez »).

| Mesure | Mise en œuvre | Preuve / instrument |

|---|---|---|

| Chiffrement en transit (TLS 1.2+) | ☐ Oui | Certificat + scan SSL Labs |

| Chiffrement au repos | ☐ Oui | Configuration KMS / disk encryption |

| Pseudonymisation à la source | ☐ Oui | Code helper `clawpulse_pseudo.py` (tutoriel) |

| Scrubber PII automatique | ☐ Oui | Suite pytest dans le repo |

| Contrôle d'accès RBAC | ☐ Oui | Matrice rôles → ressources |

| Authentification forte (MFA) | ☐ Oui | Logs IdP |

| Journalisation des accès | ☐ Oui | Logs ClawPulse + retention ___ jours |

| Détection d'anomalies | ☐ Oui | Alertes ClawPulse sur taux d'erreur, coût, latence |

| Sauvegarde testée | ☐ Oui | Date dernier test de restauration : ___ |

| Plan de réponse à incident | ☐ Oui | Runbook + RACI publiés |

| Effacement à la demande | ☐ Oui | Procédure Art. 17 RGPD documentée |

| Portabilité (export JSON) | ☐ Oui | Endpoint d'export documenté |

2.5 Analyse des risques — grille spécifique agents IA

C'est la section qui distingue une AIPD agent IA d'une AIPD générique. Voici la grille à compléter avec une notation vraisemblance × gravité = risque sur 16 (4×4).

| Risque | V (1-4) | G (1-4) | Risque | Mesure de mitigation |

|---|---|---|---|---|

| Hallucination diffusée : le LLM invente un fait sur une personne (faux numéro de téléphone, faux statut juridique) | 3 | 3 | 9 | Confidence threshold + escalade humaine |

| Fuite du system prompt : un attaquant extrait les instructions internes via prompt injection (ex. « Ignore previous instructions ») | 4 | 2 | 8 | Pas de RP dans le system prompt + détection injection |

| Exfiltration via prompt injection : un document RAG contient une instruction malveillante qui pousse l'agent à envoyer des données à un endpoint tiers | 3 | 4 | 12 | Allowlist des outils + sandbox réseau + revue des sources RAG |

| Mémoire croisée entre utilisateurs : la mémoire long-terme leak des données d'un user A dans la session d'un user B | 2 | 4 | 8 | Partition stricte par user_id + tests d'isolation automatisés |

| Décision automatisée erronée (RGPD art. 22) : un agent refuse une demande sans recours humain | 3 | 4 | 12 | Droit d'opposition documenté + bouton « contester » |

| Re-identification des logs pseudonymisés par recoupement temporel | 2 | 3 | 6 | Sel rotatif + agrégation temporelle des métriques |

| Transfert hors UE/Canada non encadré : prompt envoyé à API LLM US sans clauses Schrems II | 4 | 3 | 12 | Choix région UE/CA OU CCT + analyse Schrems II + DPF |

| Conservation excessive : logs gardés « au cas où » pendant des années | 4 | 2 | 8 | Politique de purge automatisée + audit trimestriel |

| Biais discriminatoire dans les sorties (sexe, origine, âge) | 3 | 4 | 12 | Eval set diversifié + monitoring de fairness |

| Tool-call destructif : l'agent supprime un fichier ou envoie un email à la mauvaise personne | 2 | 4 | 8 | Confirmation humaine pour les actions irréversibles |

| Coût runaway (boucle infinie LLM-outil) | 3 | 2 | 6 | Hard limit tokens/session + alerte ClawPulse cost spike |

| Indisponibilité fournisseur LLM | 3 | 2 | 6 | Fallback multi-fournisseur + statut en temps réel |

| DDoS via prompts coûteux (ex. demande de génération de 100k tokens) | 2 | 2 | 4 | Rate limiting par user + cap tokens par requête |

Tout risque ≥ 9 doit être justifié et avoir une mesure de mitigation explicite. Tout risque ≥ 12 nécessite généralement une consultation préalable du régulateur (CAI ou CNIL — RGPD art. 36) si la mesure de mitigation ne le ramène pas sous 9.

2.6 Consultation des personnes concernées

```

☐ Une consultation a été menée auprès des personnes concernées

- Méthode : ☐ sondage ☐ groupe focus ☐ panel utilisateurs ☐ comité d'entreprise

- Date : ___

- Synthèse : ___ (annexe)

☐ Consultation impossible/disproportionnée

- Justification documentée : ___

```

2.7 Mesures additionnelles si transfert hors UE/Canada

Pour tout traitement qui implique d'envoyer des prompts à un LLM US (Anthropic, OpenAI, Google) :

```

Pays destinataire : ☐ USA ☐ Royaume-Uni ☐ Suisse ☐ Autre : ___

Outil de transfert :

☐ Décision d'adéquation (Royaume-Uni, Suisse, Israël, Japon, Corée du Sud, Canada-PIPEDA)

☐ Data Privacy Framework (USA — vérifier que le sous-traitant est certifié)

☐ Clauses Contractuelles Types (CCT) modèle 2021/914

☐ BCR

☐ Dérogation art. 49 (rare, ponctuel)

Analyse Transfer Impact Assessment (Schrems II) :

- Législation locale FISA 702 / Cloud Act applicable ? ☐ Oui ☐ Non

- Mesures supplémentaires : ☐ Chiffrement E2E ☐ Pseudonymisation forte ☐ Anonymisation

- Conclusion : ☐ Niveau équivalent garanti ☐ Niveau insuffisant → arrêt du transfert

```

2.8 Avis du DPO

Obligatoire si vous en avez un (CAI Québec : « personne responsable de la protection des renseignements personnels »).

```

Date d'avis : ___

☐ Favorable

☐ Favorable avec réserves : ___

☐ Défavorable : ___

Signature DPO : ___

```

2.9 Décision et approbation

```

Décision du responsable de traitement :

☐ Mise en service approuvée

☐ Mise en service approuvée sous réserves : ___

☐ Mise en service reportée — actions correctives : ___

☐ Consultation préalable du régulateur engagée (RGPD art. 36) le ___

Date de revue : ___ (par défaut : 1 an, ou avant si changement majeur)

Signature : ___

```

---

3. Comment ClawPulse génère les preuves d'AIPD automatiquement

Une AIPD n'est défendable devant un régulateur que si vous pouvez prouver que les mesures sont effectivement appliquées. C'est ce que ClawPulse instrumente.

3.1 Mapping section AIPD → preuve ClawPulse

| Section AIPD | Mesure | Preuve générée par ClawPulse |

|---|---|---|

| 2.2 Données traitées | Catégorisation des champs envoyés au LLM | Schéma `prompt_meta` documenté + audit régulier |

| 2.3 Durées de conservation | Purge automatique à 30j | Logs de purge + alerte si durée dépassée |

| 2.4 Pseudonymisation | Scrubber PII actif | Métrique `pii_detected_per_1000_traces` + alerte si > 0 |

| 2.4 Détection d'anomalies | Alertes coût/erreur/latence | Historique d'événements `AlertEvent` |

| 2.5 Risque exfiltration | Allowlist d'outils | Liste des `tool_calls` observés + diff vs allowlist |

| 2.5 Risque hallucination | Confidence + escalade | Métrique `human_handoff_rate` |

| 2.5 Mémoire croisée | Partition par user_id | Test d'isolation automatisé dans la suite pytest |

| 2.5 Décision automatisée | Bouton « contester » | Métrique `contestation_rate` + log de l'événement |

| 2.7 Transfert hors UE | Région d'hébergement | `region` dans la config ClawPulse + bannière dashboard |

3.2 Code minimal pour générer la preuve d'instrumentation

```python

# clawpulse_aipd_proof.py — Helper qui émet les preuves d'AIPD

from clawpulse_pseudo import cp_trace, RotatingSalt, clean_payload # cf. tutoriel pseudonymisation

from contextlib import contextmanager

import os, json, time, requests, hashlib

CLAWPULSE_TOKEN = os.environ["CLAWPULSE_AGENT_TOKEN"]

SALT = RotatingSalt()

ALLOWED_TOOLS = {"search_kb", "create_ticket", "send_reply"} # cf. AIPD section 2.5

@contextmanager

def aipd_trace(workflow: str, user_id: str, decides: bool = False):

"""

Emits a ClawPulse trace with all the metadata an AIPD requires:

- workflow (finalite)

- user_id pseudonymise (data minimization)

- has_decision (RGPD art. 22 flag)

- region (transfer evidence)

"""

pseudo_user = SALT.derive(user_id)

started = time.time()

metrics = {

"tool_calls": [],

"tokens_in": 0,

"tokens_out": 0,

"pii_detected": 0,

"human_handoff": False,

"contestation": False,

}

try:

yield metrics

finally:

duration_ms = int((time.time() - started) * 1000)

# Verify allowlist (AIPD section 2.5: risque exfiltration)

violations = [t for t in metrics["tool_calls"] if t not in ALLOWED_TOOLS]

requests.post(

"https://www.clawpulse.org/api/dashboard/tasks",

headers={"Authorization": f"Bearer {CLAWPULSE_TOKEN}"},

json={

"workflow": workflow,

"pseudo_user": pseudo_user,

"duration_ms": duration_ms,

"tokens_in": metrics["tokens_in"],

"tokens_out": metrics["tokens_out"],

"pii_detected": metrics["pii_detected"],

"tool_violations": violations,

"has_decision": decides,

"human_handoff": metrics["human_handoff"],

"contestation": metrics["contestation"],

"region": os.environ.get("CLAWPULSE_REGION", "ca-central-1"),

},

timeout=2,

)

```

Cet émetteur de 40 lignes produit, pour chaque exécution d'agent, 9 des 12 preuves réclamées par le tableau de la section 3.1. Les 3 restantes (pseudonymisation, purge, contestation côté UI) sont configurables via dashboard.

3.3 Exemple d'usage dans un agent Anthropic

```python

import anthropic

from clawpulse_aipd_proof import aipd_trace

client = anthropic.Anthropic()

def handle_support_request(user_id: str, prompt: str):

with aipd_trace("support_l1", user_id, decides=False) as m:

# 1. Scrub PII avant envoi (cf. tutoriel pseudonymisation)

clean_prompt = clean_payload(prompt)

m["pii_detected"] = prompt != clean_prompt

# 2. Appel LLM avec tool use

msg = client.messages.create(

model="claude-opus-4-7",

max_tokens=1024,

tools=[{"name": t, "input_schema": {"type": "object"}} for t in ALLOWED_TOOLS],

messages=[{"role": "user", "content": clean_prompt}],

)

m["tokens_in"] = msg.usage.input_tokens

m["tokens_out"] = msg.usage.output_tokens

# 3. Trace les tool_calls effectivement emis

for block in msg.content:

if block.type == "tool_use":

m["tool_calls"].append(block.name)

# 4. Si confidence basse, handoff humain (mitigation hallucination)

if msg.stop_reason == "end_turn" and "[uncertain]" in str(msg.content):

m["human_handoff"] = True

return msg

```

À chaque exécution, ClawPulse reçoit un événement complet — sans aucune donnée personnelle en clair — qui constitue la preuve continue d'application des mesures déclarées dans l'AIPD. C'est cette traçabilité que la CAI ou la CNIL voudra voir lors d'un contrôle, pas le PDF de l'AIPD lui-même.

---

4. Les 7 erreurs qui font rejeter une AIPD agents IA

Sur la base des fiches pratiques CNIL et des décisions publiées de la CAI Québec, voici les motifs récurrents de non-conformité spécifiques aux agents IA.

1. Aucune mention du LLM comme sous-traitant. Anthropic, OpenAI, Google sont des sous-traitants au sens RGPD art. 28 même si vous payez le service à la demande. Liste-les explicitement et joins le DPA.

2. « Mémoire conversationnelle illimitée » sans justification de finalité. C'est l'erreur la plus fréquente. Une mémoire long-terme n'est justifiable que si une finalité l'exige (assistance à plusieurs sessions sur un même dossier). Sinon, purge à 24h.

3. AIPD copiée d'un CRM, sans la grille spécifique des risques agents IA (section 2.5 ci-dessus). Un régulateur identifie ça en 30 secondes.

4. Pas de Transfer Impact Assessment Schrems II quand l'API LLM est US. Les CCT 2021/914 ne suffisent pas seules — il faut documenter pourquoi le niveau est équivalent.

5. Pas de bouton « contester » pour les décisions automatisées. RGPD art. 22 impose qu'une personne puisse demander une intervention humaine. Si votre agent prend des décisions, ce bouton doit exister et être tracé.

6. Pas de purge automatisée des logs. Une politique de durée écrite mais non implémentée techniquement = non-conformité. Automatisez la purge ET émettez la preuve d'exécution dans ClawPulse.

7. Pas de revue annuelle. L'AIPD est un document vivant. RGPD art. 35.11 impose une réévaluation « lorsqu'un changement du risque survient », et la CAI recommande une revue à 12 mois minimum. Bloquez un Calendar invite récurrent.

---