Registre des risques RGPD assumés

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

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) — RETIRÉ le 2026-06-29

• Statut : résolu. DeepSeek (siège : République Populaire de Chine) a été entièrement retiré du pipeline le 2026-06-29 — client API, sélecteurs de modèles et mécanisme de rollback supprimés du code. Plus aucun appel à un sous-traitant établi en Chine n'est effectué dans l'analyse.
• Remplacement : la couche « texte pur » (extraction L1, split, briefings, synthèse RAG) utilise désormais Mistral Small 4 (Mistral AI, siège Paris, UE — Apache 2.0), avec repli Gemini Flash-Lite (UE) en l'absence de clé. Bénéfice de conformité : la tâche autrefois confiée à DeepSeek est traitée par un sous-traitant établi dans l'Union européenne.
• Historique conservé(traçabilité AIPD) : DeepSeek était précédemment utilisé pour le workflow Quick Scan (extraits de documents déjà parsés, jamais pour les livrables finaux), sous kill-switch et restriction d'usage. Bench interne (2026-06-29) : Mistral Small ≈ Gemini en qualité et >> DeepSeek → le retrait est un gain qualité et conformité, sans compromis.
• Sous-traitants LLM restants (voir le registre des sous-traitants) : Google (Gemini) et Anthropic (Claude) — États-Unis, encadrés par les clauses contractuelles types / Data Privacy Framework — et Mistral AI (UE). Plus aucun sous-traitant hors zone d'adéquation de type « transfert vers la Chine » dans le pipeline.

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