L’ICO fait désormais de la sécurité de l’IA une obligation au titre de l’article 32 du RGPD britannique

5 points clés à retenir

1. La sécurité de l’IA devient un impératif de protection des données.
Les nouvelles recommandations de l’ICO considèrent les menaces liées à l’IA comme une obligation actuelle au titre de l’article 32 du RGPD britannique, et non comme un risque futur. Les organisations qui détiennent des données personnelles doivent agir dès maintenant.

2. Sept types d’attaques sont dans le viseur du régulateur.
Le guide cite explicitement le phishing dopé à l’IA, l’ingénierie sociale via deepfake, l’analyse automatisée de vulnérabilités, les malwares pilotés par l’IA, le credential stuffing, l’empoisonnement de données et l’injection indirecte de prompts.

3. Cinq étapes constituent le nouveau socle de conformité.
Veille sur les menaces, fondamentaux de la sécurité, protection des données personnelles, gouvernance de l’IA à plusieurs niveaux et surveillance avec réponse aux incidents. Rien de nouveau individuellement, mais l’urgence est bien réelle.

4. Les DPIA deviennent obligatoires pour les traitements d’IA à haut risque.
Les organisations qui utilisent des outils d’IA traitant des données personnelles à haut risque doivent réaliser une analyse d’impact relative à la protection des données et mettre en place des mesures de protection contre les attaques ciblant l’IA.

5. L’affaire Capita fait jurisprudence.
L’amende de 14 millions de livres infligée à Capita par l’ICO en octobre 2025 reposait sur l’absence de « mesures techniques et organisationnelles appropriées » au titre de l’article 32. Ce même standard s’applique désormais à l’infrastructure IA.

Ce que l’ICO a réellement déclaré le 13 mai 2026

Le 13 mai 2026, Ian Hulme, Interim Executive Director for Regulatory Supervision de l’ICO,
a publié
un article de blog intitulé « Five steps to protect your organisation from AI-powered cyber threats »
(orthographe britannique conservée dans le titre du document). Le message est court, direct.
Pour toute organisation traitant des données personnelles au Royaume-Uni, c’est le signal le plus clair à ce jour que la sécurité de l’IA n’est plus une question de conformité future.

Le guide commence par une liste des menaces suivies par le régulateur : phishing dopé à l’IA générant des messages personnalisés très convaincants, deepfakes audio et vidéo pour usurper l’identité de collègues, outils automatisés scannant les systèmes et exploitant les failles, malwares pilotés par l’IA qui adaptent leur comportement pour échapper à la détection, credential stuffing accéléré par l’IA, empoisonnement de données sur des modèles en production, et attaques d’injection indirecte de prompts où des instructions malveillantes sont cachées dans des contenus externes traités par l’IA comme des commandes légitimes.

Vient ensuite la partie qui doit faire évoluer la posture de tous les bureaux de RSSI et DPO : « Vos obligations au titre du RGPD britannique vous imposent de mettre en œuvre des mesures techniques et organisationnelles appropriées pour protéger les données personnelles. » Le régulateur ne crée pas de nouveau cadre. Il applique les menaces IA au cadre existant depuis 2018 et précise que ce standard s’applique dès maintenant, à la vitesse de l’IA, sans délai de grâce.

Pourquoi cela rebat les cartes pour l’article 32

L’article 32 du RGPD britannique impose des « mesures techniques et organisationnelles appropriées » adaptées au risque du traitement. Depuis 18 mois, l’ICO démontre, via ses actions de contrôle, à quoi ressemble ce standard en cas de défaillance des contrôles. L’exemple le plus parlant reste
l’amende de 14 millions de livres infligée à Capita en octobre 2025, après qu’une cyberattaque en 2023 a exposé les données personnelles de 6,6 millions de personnes. Le régulateur a estimé que Capita n’avait pas mis en place de mesures techniques et organisationnelles appropriées, notamment des protections insuffisantes pour les données sensibles, des contrôles défaillants pour empêcher les mouvements latéraux sur le réseau, et une réponse inadéquate aux alertes précoces.

Capita n’est pas un cas d’IA. Mais le cadre appliqué par le régulateur est identique à celui qu’Hulme étend désormais aux menaces IA. Le même raisonnement fondé sur l’article 32, qui a abouti à une amende de 14 millions de livres pour une réponse trop lente et des contrôles d’accès faibles, servira à sanctionner les manquements à la gouvernance des systèmes IA traitant des données personnelles. Le test juridique ne change pas parce que le vecteur de menace est l’IA. C’est le niveau d’exigence technique qui s’élève.

Pour les conseils d’administration, la conséquence est directe. Lors de la prochaine fuite majeure de données personnelles liée à l’IA au Royaume-Uni, le régulateur ne demandera pas si l’organisation avait déployé des défenses contre l’injection de prompts. Il demandera si l’organisation pouvait prouver l’authentification, le contrôle d’accès, le chiffrement, la surveillance, la réponse aux incidents et l’évaluation documentée des risques pour le système IA ayant accédé aux données personnelles. Cette liste est familière, car c’est celle que Capita n’a pas respectée.

Lire les cinq étapes à travers le prisme des données personnelles

La première étape consiste à faire de la veille – comprendre à quoi ressemblent vraiment les menaces IA dans votre environnement. L’ICO en identifie sept. La plupart des équipes sécurité en connaissent trois ou quatre. L’écart entre les attentes du régulateur et la réalité opérationnelle constitue le premier risque.

La deuxième étape concerne les fondamentaux de la sécurité : les cinq contrôles techniques du programme Cyber Essentials, le Cyber Governance Code of Practice, l’authentification multifactorielle sur tous les accès distants, comptes administrateurs et messagerie, des règles strictes sur les mots de passe et un processus de mise à jour solide. Rien de nouveau. L’ICO rappelle que ce sont les bases. L’IA ne change pas l’exigence, mais accélère la survenue d’une faille.

La troisième étape vise la protection des données personnelles : minimisation des données, audits réguliers sur ce qui est détenu et où, et formation du personnel à l’ingénierie sociale dopée à l’IA. Les problèmes d’hygiène des données, à l’origine de la moitié des récentes sanctions, relèvent de cette étape.
Le rapport prévisionnel 2026 de Kiteworks sur la sécurité et la conformité des données révèle que seulement 36 % des organisations ont une visibilité sur la gestion des données par leurs partenaires dans les systèmes IA, et 35 % citent l’utilisation de données personnelles dans les prompts comme un risque majeur pour la vie privée, la plupart misant sur la politique interne et la formation plutôt que sur des contrôles techniques. Une politique ne suffit pas à empêcher qu’une liste de clients soit copiée dans un assistant IA public à 23 h.

La quatrième étape concerne la défense en profondeur et la gouvernance IA. L’ICO cite explicitement : DPIA pour les traitements IA à haut risque, mesures de protection contre les attaques ciblant l’IA, respect du Cyber Security Code of Practice du gouvernement britannique, et recours au chiffrement et à la pseudonymisation pour limiter l’impact d’une fuite. « Défense en couches » est le mot-clé. La défense à contrôle unique échoue depuis dix ans en cybersécurité. L’IA réduit la fenêtre de réaction.

La cinquième étape porte sur la surveillance, la gouvernance de la supply chain et la réponse aux incidents. Le guide recommande une surveillance de la sécurité pour détecter toute activité suspecte, comme des connexions inhabituelles, des transferts de données inattendus ou une utilisation anormale des APIs. Il faut cartographier les accès des tiers, leur imposer des standards de sécurité adaptés et intégrer ces exigences dans les contrats. Un plan de réponse aux incidents doit être maintenu et testé régulièrement.

Quand le manque de maîtrise devient un risque de non-conformité

L’accent mis par l’ICO sur la défense en couches et la gouvernance IA cible un manque documenté sur le marché. Le rapport prévisionnel 2026 indique que 63 % des organisations ne peuvent pas limiter l’usage des IA à un objectif précis, 60 % ne peuvent pas désactiver rapidement une IA défaillante, et 55 % ne peuvent pas isoler les systèmes IA du reste du réseau. Il s’agit là des contrôles de confinement – la capacité à stopper une IA en cas de problème – et ce sont les plus grandes failles relevées dans
l’étude exclusive de Kiteworks.

Comparez ces lacunes aux attentes de l’ICO. Le régulateur veut voir une supervision humaine, une réponse aux incidents et la capacité à limiter les dégâts en cas de défaillance d’un contrôle. Une organisation incapable de désactiver rapidement ses IA ou de les isoler des systèmes sensibles est, selon le cadre du régulateur, une organisation dépourvue de mesures techniques et organisationnelles appropriées. Le calcul de l’amende Capita – 58 millions de livres au départ, ramenés à 14 millions après accord – illustre concrètement ce que signifie « approprié » lorsque les contrôles font défaut.

L’exposition aux IA tierces aggrave le problème. Le rapport prévisionnel 2026 montre que 30 % des organisations considèrent la gestion des données par les fournisseurs IA comme un enjeu majeur de sécurité, mais seules 36 % ont une visibilité sur la gestion des données par leurs partenaires dans les systèmes IA. Les 64 % restantes se fient aux contrats et questionnaires pour se protéger de risques qu’elles ne maîtrisent pas. L’ICO est explicite : il faut cartographier les accès des tiers, leur imposer des standards de sécurité adaptés et intégrer ces exigences dans les contrats. Le
rapport Data Threat 2026 de Thales confirme la crise de visibilité : seulement un tiers des organisations savent précisément où sont stockées leurs données, et 39 % seulement peuvent toutes les classifier. L’IA repose sur cette base déjà fragile.

Comment les DPIA et les protections contre les attaques ciblant l’IA deviennent obligatoires

L’ICO est sans équivoque sur les DPIA pour les traitements IA à haut risque. Si votre organisation utilise des outils IA traitant des données personnelles à haut risque, vous devez disposer d’une analyse d’impact documentée et de mesures adaptées contre les attaques ciblant l’IA. Ce n’est plus une « bonne pratique optionnelle », mais une « attente documentée au titre des articles 35 et 32 ».

Les chiffres du rapport prévisionnel 2026 sur ce point sont préoccupants. 74 % des organisations non concernées par l’AI Act européen n’ont pas d’analyse d’impact IA. 84 % n’ont jamais mené d’exercice de red teaming IA. 72 % n’ont pas de mécanisme de limitation d’usage. Même parmi les organisations soumises à l’AI Act, les taux restent élevés : 41 %, 61 % et 46 %. L’AI Act et l’ICO convergent vers la même exigence. La plupart des organisations ne sont pas prêtes.
Les résultats du DTEX 2026 Insider Threat Report illustrent le problème sous un autre angle : 92 % des organisations estiment que l’IA générative a fondamentalement changé la façon dont les employés accèdent et partagent l’information, mais seulement 13 % ont intégré formellement l’IA dans leur stratégie d’entreprise. Le déficit stratégique est un déficit de gouvernance.

Les attaques ciblant l’IA ont désormais une définition précise intégrée à l’article 32 par l’ICO. L’injection indirecte de prompts, où des adversaires cachent des instructions malveillantes dans les données récupérées par l’IA lors de l’inférence. L’empoisonnement de données, où les attaquants corrompent les données d’entraînement ou manipulent les résultats. L’empoisonnement d’outils, où des instructions sont dissimulées dans les métadonnées des outils utilisés par un agent IA. Il ne s’agit pas de cybermenaces génériques, mais de modes d’exploitation propres à l’IA que les règles DLP, EDR et SIEM classiques ne détectent pas. La défense doit être placée là où l’IA accède aux données.

Comment Kiteworks met en œuvre les cinq étapes de l’ICO pour les détenteurs de données personnelles

Le guide de l’ICO ne cite aucun fournisseur. Il n’en a pas besoin. L’architecture décrite est claire : accès authentifié, défense en couches, chiffrement et pseudonymisation, surveillance au niveau des données, préparation à la réponse aux incidents et gouvernance documentée. Kiteworks Compliant AI a été conçu sur la base de ces contrôles.

Kiteworks Compliant AI
contrôle l’accès des agents IA au niveau des données, et non au niveau du modèle ou de l’application. Chaque requête IA est authentifiée via OAuth 2.0 avec des jetons stockés dans le trousseau du système d’exploitation, jamais exposés au modèle. Chaque opération est évaluée en temps réel selon des politiques d’accès basées sur les attributs (ABAC) ou les rôles (RBAC). Chaque interaction génère une entrée de journal d’audit infalsifiable, transmise au SIEM sans limitation. Le chiffrement validé FIPS 140-3 protège les données en transit et au repos. L’agent hérite des autorisations de l’utilisateur qui l’a autorisé et ne peut pas les dépasser, que ce soit en cas de défauts dans le framework IA, de réussite d’une injection de prompt ou de compromission du modèle.

Voilà à quoi ressemble la quatrième étape de l’ICO en production. La défense en couches tient même si un contrôle échoue. La traçabilité fournit les preuves requises au titre de l’article 5(2) (accountability) et de l’article 32 (« mesures appropriées »). Le DPIA devient réellement satisfaisant car les mesures techniques sont documentées, applicables et auditées. La gouvernance de la supply chain de l’étape cinq devient possible car la couche données applique la politique à chaque interaction, y compris celles initiées par des outils IA tiers.

Plus important encore, cette architecture répond à la question implicite du régulateur : lorsqu’un agent IA accède à des données personnelles, qu’est-ce qui l’empêche de dépasser ses autorisations ? Les garde-fous au niveau du modèle peuvent être contournés. Les logs au niveau applicatif peuvent être ignorés si l’application est conçue pour échouer en mode ouvert. La gouvernance au niveau des données, elle, ne fait pas confiance à l’agent pour bien se comporter. Elle vérifie chaque requête par rapport à la politique, à chaque fois.

Que doivent faire les RSSI, DPO et conseils d’administration ce trimestre ?

Premièrement, considérez les recommandations de l’ICO comme un socle de conformité, pas comme un simple avis.
Les cinq étapes correspondent directement aux attentes de l’article 32 et figureront dans les futurs avis de sanction de l’ICO comme preuves de ce à quoi ressemblent des « mesures appropriées » en 2026. Documentez la posture de votre organisation pour chaque étape.

Deuxièmement, réalisez un DPIA pour chaque système IA traitant des données personnelles à haut risque.
Le rapport prévisionnel 2026 de Kiteworks montre que 74 % des organisations hors champ de l’AI Act européen n’ont pas d’analyse d’impact IA. L’ICO vient de faire de ce manque un risque au titre du RGPD britannique. La solution : un DPIA documenté par système, et non une politique IA générique.

Troisièmement, auditez votre supply chain pour l’exposition à l’IA.
Les résultats du rapport prévisionnel 2026 de Kiteworks montrent que seulement 36 % des organisations ont une visibilité sur la gestion des données par leurs partenaires dans les systèmes IA. L’ICO attend de vous que vous cartographiiez les accès des tiers et intégriez des exigences de sécurité dans les contrats. Les questionnaires annuels aux fournisseurs ne suffiront pas.

Quatrièmement, comblez le déficit de maîtrise.
Les données du rapport prévisionnel 2026 de Kiteworks indiquent que 63 % des organisations ne peuvent pas limiter l’usage des IA à un objectif précis et 60 % ne peuvent pas désactiver rapidement une IA. L’accent mis par l’ICO sur la supervision humaine, la défense en couches et la réponse aux incidents fait de ces lacunes des risques de conformité, et non plus seulement de sécurité. Limitation d’usage, kill switches et isolation réseau passent de la feuille de route à la production.

Cinquièmement, déplacez la détection au niveau des données.
Les attaques ciblant l’IA – injection de prompts, empoisonnement de données, empoisonnement d’outils – contournent par conception la surveillance au niveau applicatif. L’exigence de surveillance de l’ICO n’est réaliste que si la télémétrie s’effectue là où l’IA accède réellement aux données.

Sixièmement, informez votre conseil d’administration ce trimestre.
Le précédent Capita, c’est une amende de 14 millions de livres qui en valait 58 au départ. La prochaine fuite majeure de données personnelles liée à l’IA au Royaume-Uni sera évaluée selon le cadre publié par Ian Hulme. La sensibilisation du conseil est un contrôle. Documentez-la.

Le cadrage de l’ICO est lucide, non alarmiste. « Rien de tout cela n’est nouveau », écrit Hulme dans le dernier paragraphe, « mais l’IA apporte une urgence et une rapidité accrues. » C’est le bon cadrage. Le standard n’a pas changé. Le tempo, si.