Registre des risques RGPD assumés

Article 35 RGPD (analyse d'impact) · Dernière mise à jour : 2026-05-09

Ce document détaille les risques RGPD identifiés et formellement assumés par GELOC SAS, avec les mitigations appliquées. Conforme à l'esprit d'une analyse d'impact relative à la protection des données (AIPD) — cf. lignes directrices CNIL.

Risque #1 — DeepSeek (LLM Chine)

• Sous-traitant : DeepSeek (siège : République Populaire de Chine).
• Pays sans décision d'adéquation RGPD au sens de l'article 45.
• Usage : workflow Quick Scan (analyse rapide d'un dossier en moins de 30s) — fichier lib/inngest/functions/workflow-quick-scan.ts.
• Données envoyées : extraits de documents juridiques déjà parsés (textes sans PII brute — les PII visibles dans les documents sont incluses dans les extraits).
• Mitigations en place :
  • Kill-switch ENV DEEPSEEK_KILL_SWITCH=1 — désactive DeepSeek en moins de 5 minutes (fallback automatique vers Gemini Flash-Lite).
  • Restriction d'usage : uniquement pour le quick-scan exploratoire, jamais pour les livrables finaux (note comité, brief acheteur, mémo).
  • Aucune donnée d'identification directe (email, nom complet) n'est envoyée — seuls les extraits parsés.
  • Pas d'entraînement sur les données client (clause à confirmer côté DeepSeek).
• Triggers d'escalade (désactivation immédiate) :
  • Demande explicite d'un client ou de son DPO
  • Contrôle CNIL ou demande RGPD entrante
  • Déclaration de breach data chez DeepSeek
  • Évolution réglementaire (refus politique des transferts vers la Chine)
• Justification du maintien : DeepSeek offre un coût marginal et une latence très inférieurs aux alternatives EU/US sur la tâche quick-scan (≈ 70% moins cher). Le risque résiduel est jugé acceptable par GELOC SAS au stade MVP, sous condition du kill-switch et de la restriction d'usage. Cette décision sera ré-évaluée trimestriellement.

Risque #2 — Pseudonymisation de l'audit log lors du RTBF

L'article 17 RGPD (droit à l'effacement) entre en tension avec l'obligation de traçabilité (audit log immuable, généralement conservé 5 ans). GELOC tranche en faveur d'une pseudonymisation du user_id (passage à l'UUID nul) plutôt qu'une suppression complète de la ligne d'audit. Cela permet de conserver la trace des opérations sans permettre de remonter à l'utilisateur.

Cette pseudonymisation est techniquement implémentée via une fonction SQL SECURITY DEFINER qui bypasse le trigger BEFORE UPDATE de l'audit log. C'est le seul cas autorisé de modification d'une ligne d'audit log ; cette fonction est verrouillée à service_role et appelée uniquement depuis le endpoint /api/user/account/delete.

Contact

Toute question : dpo@geloc.eu