Checklist RGPD pour un projet d'IA documentaire

Cette checklist s'adresse aux équipes qui construisent ou achètent un système de Document AI traitant des données personnelles : dossiers KYC, bulletins de paie, comptes rendus médicaux, baux, pièces d'identité. À utiliser avant de signer un contrat fournisseur ou de passer un pipeline en production, pas après. Elle ne suffira pas à elle seule à vous rendre conforme, mais elle permet de repérer les erreurs qui ressortent habituellement lors d'un audit ou d'une fuite de données.

Cadrer les données

• Lister chaque type de document traité par le système et signaler ceux qui contiennent des données personnelles (une facture n'a rien à voir avec un compte rendu médical ou une pièce d'identité)
• Identifier les données sensibles : informations de santé, données biométriques sur les cartes d'identité et passeports, appartenance syndicale mentionnée dans des dossiers RH
• Confirmer une base légale de traitement (contrat, consentement, intérêt légitime) pour chaque type de document
• Vérifier si certains documents concernent des mineurs ou des personnes vulnérables (règles plus strictes applicables)
• Cartographier où atterrissent les données extraites en aval (CRM, data warehouse, outil de ticketing)

Due diligence fournisseur et architecture

• Confirmer où s'exécute le modèle : votre infrastructure, le cloud du fournisseur, ou une API LLM tierce (cela détermine qui est sous-traitant et qui pourrait être sous-traitant ultérieur)
• Obtenir un Data Processing Agreement signé auprès de chaque fournisseur ayant accès aux données personnelles
• Demander si les documents ou le texte extrait servent à entraîner les modèles du fournisseur (de nombreuses API LLM généralistes le font par défaut, sauf opt-out)
• Vérifier la localisation des données : le traitement reste-t-il dans l'UE, ou transite-t-il par des serveurs américains
• Examiner la documentation sécurité et conformité du fournisseur, y compris son statut SOC 2 ou ISO 27001
• Pour comparer plusieurs prestataires, suivre un processus structuré comme la checklist d'évaluation des fournisseurs IDP

Journalisation et conservation

• Décider ce qui est journalisé : documents bruts, champs extraits, prompts envoyés au modèle, scores de confiance
• Fixer une durée de conservation pour chaque type de journal et la faire respecter par une suppression automatisée, pas par une politique écrite que personne ne contrôle
• Masquer ou caviarder les données personnelles dans les journaux utilisés pour le débogage ou l'évaluation des modèles
• Vérifier que les journaux du fournisseur LLM (s'il y en a) respectent aussi vos règles de conservation, pas seulement votre propre base de données
• Consulter les détails dans notre guide sur la conformité RGPD et SOC 2 pour la journalisation des LLM

Droits des personnes concernées

• Mettre en place un moyen de retrouver tous les enregistrements liés à une personne à travers les documents, les champs extraits et les journaux (nécessaire pour les demandes d'accès et d'effacement)
• Tester une demande d'effacement de bout en bout, y compris dans les sauvegardes et toute copie côté fournisseur
• Documenter la procédure de réponse à une demande dans le délai légal d'un mois
• Vérifier que les décisions automatisées (validation ou rejet automatique) fondées sur des données extraites permettent une relecture humaine sur demande

Garde-fous techniques

• Chiffrer les documents au repos et en transit, y compris le stockage temporaire utilisé pendant l'OCR ou le parsing
• Appliquer un contrôle d'accès par rôle afin que seules les personnes habilitées puissent consulter un bulletin de paie ou un compte rendu médical
• Comparer les approches d'extraction, car le choix entre OCR et VLM a un impact sur la quantité de texte brut exposée à des modèles tiers
• Pseudonymiser les données quand c'est possible avant de les envoyer à un modèle généraliste
• Surveiller la précision en continu ; une erreur d'extraction sur un relevé bancaire ou un avis d'imposition peut elle-même devenir un problème de protection des données (une donnée erronée associée à la mauvaise personne)

Gouvernance et documentation

• Réaliser une Analyse d'Impact relative à la Protection des Données si le projet implique un traitement à grande échelle ou systématique (c'est le cas de la plupart des pipelines KYC et de traitement de sinistres)
• Inscrire le projet dans votre registre des traitements au titre de l'article 30
• Désigner un responsable pour la conformité dans la durée, pas seulement pour le lancement
• Décider entre développement interne et recours à un fournisseur, en pesant la charge de conformité face au contrôle obtenu ; voir développer ou acheter sa solution IDP
• Budgétiser le travail de conformité lors de la comparaison des coûts, pas seulement les frais de licence, à l'aide d'un outil comme le calculateur de ROI

Erreurs courantes

• Traiter l'AIPD comme un document ponctuel au lieu de la mettre à jour quand l'ensemble documentaire ou le modèle évolue
• Supposer que l'argument marketing « conforme RGPD » d'un fournisseur vous dispense de vos propres obligations en tant que responsable de traitement
• Envoyer des documents complets à une API LLM généraliste sans vérifier sa politique de conservation et d'entraînement des données
• Tout journaliser « par précaution » sans plan de suppression
• Oublier que les erreurs d'extraction sur des champs sensibles (état de santé, revenus, numéros d'identité) constituent un problème d'exactitude des données au sens du RGPD, et pas seulement un indicateur de qualité
• Repousser un véritable test d'effacement jusqu'à ce qu'un régulateur ou un client le demande effectivement

FAQ

Avons-nous besoin d'une AIPD pour un projet de Document AI ?

En général oui, si le traitement est systématique, à grande échelle, ou implique des données sensibles comme des dossiers de santé ou des données biométriques d'identité. Le traitement de sinistres, l'onboarding KYC et le traitement de documents de santé répondent presque toujours à ces critères. En cas de doute, réalisez l'analyse quand même : c'est moins coûteux que de devoir justifier après coup la décision de ne pas l'avoir fait.

Recourir à une API LLM tierce rend-il automatiquement non conforme ?

Non, mais cela ajoute un sous-traitant ultérieur et un flux de données à documenter et à maîtriser. Vérifiez les clauses contractuelles d'opt-out sur l'entraînement, la localisation des données et la durée de conservation. De nombreux fournisseurs proposent un traitement exclusivement européen ou des modes sans conservation. Le risque ne vient pas de la technologie elle-même, mais de son utilisation sans DPA signé ou sans savoir où vont réellement les données.

En quoi cela diffère-t-il d'une évaluation fournisseur classique ?

Une checklist RGPD se concentre étroitement sur la base légale, les flux de données et les droits des personnes. La checklist d'évaluation des fournisseurs IDP couvre en plus la précision, le coût et l'intégration. Utilisez les deux : la conformité peut disqualifier un fournisseur par ailleurs solide, et un pipeline non conforme reste un risque juridique, quelle que soit sa précision.