Vos systèmes d'IA exigent désormais un registre, un responsable désigné et des preuves.

Le Règlement 10 complète la loi sur la protection des données n° 5 de 2020 du DIFC et s'applique aux organisations qui traitent des données personnelles via des systèmes autonomes ou semi-autonomes. Les obligations pèsent sur les déployeurs et les opérateurs, et les plus lourdes concernent le traitement à haut risque.

Les quatre obligations en pratique

1. Certification. Les systèmes d'IA commerciaux à haut risque doivent être certifiés. La certification porte sur le système et non sur l'entité : certifier votre organisation ne certifie pas votre prochain modèle.
2. Un responsable des systèmes autonomes. Les déployeurs et opérateurs réalisant un traitement à haut risque doivent en désigner un pour assurer une surveillance indépendante.
3. Un registre et une explication. Vous tenez un registre de vos systèmes d'IA et devez pouvoir expliquer le traitement, en termes non techniques et preuves à l'appui, aux personnes concernées.
4. Évaluation des risques avant traitement. Les risques pour la vie privée sont évalués et documentés avant tout traitement à haut risque, puis atténués. Consigner un risque ne revient pas à le traiter.

Il existe aussi un droit de contestation : une personne concernée peut contester un résultat produit par un système d'IA, ce qui suppose de pouvoir reconstituer la manière dont une décision précise a été prise.

Traitez le périmètre comme une question juridique. Savoir si un système relève du haut risque au sens du Règlement 10 se décide avec un conseil, pas depuis la page d'un prestataire.

Commencez par le registre. Toutes les autres obligations en dépendent, car un contrôle ne peut pas s'attacher à un système que personne n'a consigné.

Ce que doit contenir un registre

• Chaque système qui prend une décision ou l'informe de façon déterminante, y compris ceux achetés par carte et jamais revus.
• Le modèle et sa version derrière chacun, pour qu'un résultat soit traçable jusqu'à ce qui l'a produit.
• Quelles données personnelles entrent, d'où elles viennent, et la base légale pour cet usage.
• Si un humain valide le résultat, et qui par fonction.
• L'évaluation des risques, sa date, et ce qui a été fait de ses conclusions.
• L'infrastructure que personne n'enregistre : bases vectorielles, journaux de requêtes et de réponses, files de revue, jeux d'évaluation et extractions de reporting.

C'est sur cette dernière ligne que les évaluations échouent. Le modèle est examiné avec soin ; les composants autour ont été mis en place pendant un pilote et n'ont jamais rejoint le processus de gouvernance.

C'est le même registre qu'ADHICS demande aux établissements de santé d'Abou Dabi pour leurs actifs informationnels. Si vous en tenez déjà un, vous êtes plus avancé que vous ne le pensez.

Avant toute construction, nous établissons ce que vous exploitez réellement et où cela se situe face au régime qui vous concerne.

Ce que produit l'évaluation

• Un inventaire complet des systèmes d'IA et de décision automatisée en service, y compris les déploiements non déclarés.
• Un niveau de risque par système, avec le raisonnement écrit pour que le classement puisse être défendu ou révisé.
• Une mise en correspondance entre chaque système et les obligations qui l'atteignent : PDPL, votre norme sectorielle et, si vous êtes agréé au DIFC, le Règlement 10.
• Les écarts, classés par exposition réglementaire et non par facilité de traitement.
• Un plan de remédiation avec un responsable et une séquence, et les preuves que chaque étape doit laisser.

Où les organisations sont généralement les plus faibles

• Personne ne détient la liste complète : l'inventaire est reconstitué depuis trois listes partielles qui se contredisent.
• Les décisions automatisées affectant des personnes n'ont jamais été reconnues comme telles, donc l'article 18 de la PDPL n'a jamais été examiné.
• Le transfert transfrontalier a été décidé par le fournisseur que l'équipe technique préférait.
• La revue humaine existe dans la description du processus mais pas dans le système : rien ne prouve qu'une validation a eu lieu.

Nous construisons la couche de gouvernance comme un logiciel en fonctionnement dans votre environnement, non comme un corpus de politiques à exécuter ensuite à la main.

Une mission type

1. Mener l'évaluation de maturité et arrêter la classification des risques.
2. Mettre en place le registre des systèmes d'IA comme un enregistrement vivant relié aux systèmes qu'il décrit, afin qu'il reste à jour au lieu de vieillir dans un tableur.
3. Instrumenter la journalisation des décisions : entrée, version du modèle, sortie, qui a validé et quand, écrit là où cela ne peut plus être modifié.
4. Construire le flux d'évaluation des risques et de revue, avec des portes de validation qui bloquent le déploiement au lieu de signaler qu'on les a contournées.
5. Assembler le dossier de preuves qu'un évaluateur, un organisme de certification ou une demande d'une personne concernée réclamera.
6. Livrer avec le registre peuplé, la journalisation active et vos équipes capables d'exploiter les deux.

Le tout se déploie sur votre infrastructure. Les enregistrements de décisions et les journaux de requêtes contiennent des données personnelles et souvent des jugements sensibles sur le plan commercial : ils restent soumis aux mêmes règles de résidence et d'accès que le reste de vos données.

Il vaut la peine d'être explicite, car la frontière est souvent brouillée sur ce marché.

Ce que nous ne faisons pas

• Nous ne délivrons pas la certification du Règlement 10. Seul un organisme de certification accrédité par le DIFC peut le faire, et aucun prestataire technique ne peut garantir un résultat décidé par un tiers accrédité. Nous vous préparons à cette évaluation et construisons les preuves sur lesquelles elle s'appuie.
• Nous ne donnons pas de conseil juridique. Le caractère à haut risque d'un système, la validité d'un mécanisme de transfert et l'application d'une obligation à votre entité relèvent d'un conseil qualifié. Nous construisons selon la position retenue par vos conseils.
• Nous n'assurons pas le rôle de responsable des systèmes autonomes ni de DPO. Les attentes d'indépendance liées à ces nominations relèvent de vos conseils. Nous donnons à celui qui occupe la fonction le registre, les journaux et le reporting pour l'exercer correctement.

Si un prestataire vous promet une certification garantie, demandez quel organisme accrédité la délivre et sur quelle base. La réponse est instructive.