La plupart des projets PDPL s'enlisent parce que personne ne sait où sont les données.

Vous ne pouvez pas protéger, restreindre, transférer licitement ni supprimer sur demande des données que vous ne savez pas localiser. Presque tous les programmes de conformité enlisés que nous voyons le sont à cette étape.

Ce que nous produisons concrètement

• Un inventaire de chaque système, base, partage et export contenant des données personnelles.
• Les catégories de données personnelles dans chacun, les sensibles étant signalées.
• L'origine de chaque jeu de données, sa destination, et qui peut y accéder.
• Un registre des traitements que vous pouvez présenter à un régulateur.
• Les copies que personne n'avait en tête : tableurs sur des partages, anciennes sauvegardes, bases de test alimentées avec des enregistrements de production.

Cette dernière ligne est généralement la plus inconfortable. C'est aussi pourquoi une mission limitée aux politiques vous laisse exposé.

C'est la partie que le marché de la conformité ne vend généralement pas. Nous venons et nous la faisons.

Le travail

• Dédupliquer et rapprocher les enregistrements pour qu'une personne corresponde à un enregistrement, pas à neuf.
• Corriger les problèmes structurels qui rendent la conformité impossible : aucun champ de conservation, aucune source de consentement, aucune colonne de base légale, des champs libres contenant des identifiants.
• Classer et étiqueter les jeux de données pour que des règles d'accès puissent réellement s'y appliquer.
• Appliquer conservation et suppression aux données que vous n'avez plus de raison de détenir.
• Séparer la production des environnements de test, et purger les enregistrements de production des environnements qui n'auraient jamais dû les recevoir.
• Retirer les données personnelles des journaux, exports, caches et extractions de reporting.

Chaque suppression et chaque modification est consignée, donc le travail lui-même est auditable. Nous ne faisons pas disparaître des enregistrements en silence.

Une fois les données comprises et nettoyées, elles doivent souvent bouger. Un jeu de données qui ne peut pas licitement rester où il est constitue un constat que l'on corrige en le déplaçant, pas en le documentant.

Ce que comprend la migration

• Déplacer les jeux de données vers des systèmes et des régions correspondant à leur classe.
• Ramener le traitement dans le pays lorsque le transfert transfrontalier ne peut pas être justifié.
• Reconstruire les intégrations pour qu'elles cessent de recopier des données personnelles là où elles ne devraient pas arriver.
• Valider les volumes, l'intégrité et le contrôle d'accès après le déplacement, pas avant.
• Décommissionner l'ancienne copie, avec la preuve de sa disparition.

Nous avons mené ce travail sur des systèmes en production pour des clients de la santé, de la conformité et du négoce, et c'est de là que vient notre prudence sur les bascules.

Si vous avez déployé quoi que ce soit assisté par IA, l'écart de conformité est rarement le modèle. C'est tout ce qui l'entoure, et cela figure rarement dans la cartographie de qui que ce soit.

Régulièrement oubliés

• Les prompts, et les fragments de documents assemblés dedans.
• Les bases vectorielles et les plongements dérivés d'enregistrements personnels.
• Les journaux d'inférence et les outils de traçage, qui capturent souvent les charges complètes par défaut.
• Les réponses mises en cache, y compris au niveau d'une passerelle ou d'un CDN.
• Les jeux d'évaluation et corpus d'affinage construits à partir du trafic de production.
• Les files de revue humaine, où le personnel voit des enregistrements autrement inaccessibles.

Un test utile : demandez à votre équipe la durée de conservation des journaux de prompts. Si personne ne répond dans la journée, ces journaux ne sont pas inventoriés et sont probablement sans limite.

Les articles 22 et 23 de la PDPL régissent le transfert de données personnelles hors des Émirats. L'article 22 autorise le transfert vers des juridictions jugées offrir une protection adéquate. L'article 23 couvre tout le reste et vous restreint à des fondements précis : nécessité contractuelle, consentement explicite, coopération judiciaire internationale, ou intérêt public.

Lisez cela à l'aune d'un système que vous comptez exploiter des années. Le consentement est révocable. La nécessité contractuelle est tirée par les cheveux pour un outil interne. Aucun des deux n'est une base confortable.

Garder les données et le traitement dans le pays ne vous donne pas une meilleure réponse à la question du transfert : cela supprime la question. Lorsque c'est le bon choix, nous le construisons ainsi.

Obligations connexes que nous cadrons avec vous

• Article 21 : une évaluation d'impact documentée avant tout traitement à haut risque.
• Article 18 : un droit d'opposition aux décisions prises par traitement automatisé.
• Article 10 : si votre organisation doit désigner un délégué à la protection des données.

La découverte d'abord, parce que tout le reste n'est que conjecture sans elle.

Déroulé habituel

1. Découverte et cartographie des systèmes, avec le registre comme livrable.
2. Une revue des constats : ce qui est licite aujourd'hui, ce qui ne l'est pas, et ce qui ne peut pas rester en place.
3. Nettoyage et remédiation, priorisés par le risque et non par la facilité.
4. Migration, lorsqu'un jeu de données a besoin d'un autre hébergement.
5. Transfert : le registre, la piste de preuves, et les contrôles que votre équipe exploite ensuite.

Ce que nous ne faisons pas

Nous ne sommes pas vos avocats et nous ne vous certifions pas. Nous faisons le travail sur les données et l'ingénierie, et nous le documentons pour que votre conseil et vos évaluateurs puissent s'y appuyer. Lorsqu'une question relève du jugement juridique, nous le disons et vous invitons à l'obtenir.