L’exécution d’agents IA sur des systèmes de production crée deux domaines de risque distincts pour les équipes data : les risques de sécurité techniques et l’exposition légale/réglementaire. L’avertissement de l’Autorité néerlandaise de protection des données de février 2026 au sujet d’OpenClaw était une déclaration formelle d’une APD d’un État membre de l’UE, et non l’opinion d’un chercheur en sécurité — une distinction qui influe sur la façon dont les praticiens des données devraient l’évaluer.
Ce que l’AP néerlandaise a réellement dit
Le 13 février 2026, l’Autoriteit Persoonsgegevens (AP néerlandaise) a émis une déclaration formelle qualifiant OpenClaw de « cheval de Troie » et exhortant les organisations à ne pas l’installer ni l’utiliser sur des systèmes contenant :
- Des codes d’accès et mots de passe
- Des données financières
- Des données sur les employés
- Des documents privés
- Des documents d’identité
Cette liste n’est pas abstraite. Pour les analytics engineers et les consultants data, elle décrit précisément les catégories de données impliquées dans la plupart des missions client. Les données financières sont au cœur de la plupart des travaux analytics. Les données sur les employés apparaissent dans les pipelines RH, les analytics de workforce et le reporting des notes de frais. Les codes d’accès et mots de passe sont les credentials utilisés pour se connecter aux entrepôts client. Si votre travail implique régulièrement l’une de ces catégories — et c’est probablement le cas — l’AP néerlandaise vous avertissait spécifiquement.
L’Information Commissioner’s Office britannique a suivi le 25 février 2026, le Commissioner John Edwards qualifiant l’IA agentique de « préoccupation future ». La posture réglementaire des autorités de protection des données de l’UE et du Royaume-Uni converge : l’IA agentique avec un large accès aux données est un risque de conformité actif, pas théorique.
Accords de traitement des données et IA tierce
La plupart des missions de conseil en analytics sont régies par un accord de traitement des données (ATD) — un document juridique qui spécifie comment le prestataire est autorisé à traiter les données personnelles du client. Les ATD précisent généralement les finalités du traitement, les mesures techniques et organisationnelles en place, les sous-traitants (tiers) autorisés à recevoir les données client et les conditions dans lesquelles les données peuvent être transférées.
Faire passer des données client par une API LLM crée une relation de sous-traitance avec le fournisseur LLM. Quand un agent OpenClaw interroge un entrepôt client et envoie les résultats à Claude, GPT-4o ou Gemini pour traitement, le fournisseur LLM reçoit ces données. Si l’ATD du client n’autorise pas explicitement le traitement par IA ou ne nomme pas le fournisseur LLM comme sous-traitant autorisé, ce transfert peut violer l’accord — indépendamment des propres politiques de traitement des données du fournisseur LLM.
Ce n’est pas hypothétique. Le flux de données ressemble à ceci :
Entrepôt client → Agent OpenClaw → API LLM (Anthropic/OpenAI/Google) → réponseL’étape intermédiaire — les données de l’entrepôt client allant vers l’API LLM — est la relation de sous-traitance que la plupart des ATD n’abordent pas. Les accords rédigés avant la vague actuelle d’outils IA ne couvriront certainement pas cela. Les accords récents peuvent le couvrir, mais seulement si les deux parties ont explicitement négocié des conditions de traitement par IA.
La question pratique avant d’exécuter un agent IA sur des données client est : l’ATD applicable autorise-t-il ce transfert de données ? Si vous ne connaissez pas la réponse, elle est probablement non.
La question de conformité RGPD
Le RGPD s’applique au traitement des données personnelles des personnes physiques de l’UE, quel que soit le lieu d’implantation de l’organisation effectuant le traitement. Si les données de votre client comprennent des données personnelles de résidents de l’UE — ce qui est probable pour toute organisation opérant en Europe — le RGPD régit la façon dont ces données sont traitées.
Le RGPD requiert une base légale pour chaque activité de traitement. Faire passer des données client par une API LLM est une activité de traitement. Les bases légales disponibles (intérêt légitime, nécessité contractuelle, consentement, etc.) nécessitent chacune des conditions spécifiques à remplir. Pour la plupart des cas d’usage analytics, la base applicable serait la nécessité contractuelle ou l’intérêt légitime — mais les deux nécessitent que le traitement soit réellement spécifié dans l’accord avec la personne concernée (les clients de votre client) ou soit véritablement nécessaire au contrat, pas seulement pratique.
« Je voulais utiliser un outil IA pour faciliter mon travail » n’est pas une base légale RGPD. « L’outil IA est open source » non plus.
La déclaration de l’AP néerlandaise incluait un point explicite à ce sujet : les organisations et les utilisateurs restent responsables de la conformité RGPD indépendamment du fait que le système IA soit open source. Open source signifie que vous pouvez inspecter et auditer le code. Cela ne signifie pas que les activités de traitement conduites avec l’outil sont conformes. Cela ne transfère pas la responsabilité du responsable de traitement des données (vous) vers le projet logiciel.
L’argument « l’open source ne transfère pas la responsabilité »
Une réponse courante aux préoccupations de sécurité et de conformité concernant OpenClaw est qu’il est open source, donc on peut l’auditer et on ne fait pas confiance à une boîte noire d’un fournisseur. Cela confond la transparence du code avec la responsabilité légale.
Le point de l’AP mérite d’être reformulé précisément : vous êtes responsable de ce que vous faites avec un outil, pas l’auteur de l’outil. Si vous traitez des données personnelles client via OpenClaw et que ce traitement viole votre ATD ou le RGPD, l’exposition est la vôtre — pas celle d’OpenClaw. L’open source fournit de la transparence et de l’auditabilité, deux caractéristiques réellement précieuses. Il ne crée pas un bouclier légal pour l’utilisateur.
Cet argument est parfois étendu davantage : « le fournisseur LLM traite les données, donc les problèmes de conformité sont les leurs. » Cela échoue également. Dans une chaîne de sous-traitance, le responsable du traitement (votre client) a une relation avec le sous-traitant (vous). Vous êtes responsable de vous assurer que vos sous-traitants (fournisseurs LLM) respectent les standards de conformité requis et sont dûment autorisés dans l’ATD. La chaîne de responsabilité passe par vous, pas autour de vous.
Réglementations sectorielles spécifiques
Au-delà du RGPD, plusieurs réglementations sectorielles imposent des exigences supplémentaires qui concernent l’usage des agents IA :
HIPAA (données de santé américaines) : Traiter des informations de santé protégées via une API LLM tierce nécessiterait un Business Associate Agreement (BAA) avec le fournisseur LLM. La plupart des accords d’API LLM standard ne sont pas des BAA. Faire passer des données de santé par l’API standard d’OpenAI ou d’Anthropic sans BAA constituerait une violation HIPAA.
SOX (données financières des sociétés cotées américaines) : Sarbanes-Oxley impose des exigences sur l’intégrité et l’auditabilité des processus de reporting financier. Faire passer des données financières par des systèmes IA qui peuvent les modifier ou les résumer sans piste d’audit claire crée un risque de conformité SOX.
PCI-DSS (données de cartes de paiement) : Les données de cartes de paiement ne doivent jamais entrer dans un contexte LLM. PCI-DSS interdit explicitement la conservation et la transmission inutiles des données des titulaires de cartes. Si un agent interroge des tables contenant des données de paiement, ces données doivent être masquées ou exclues de ce qui est transmis au LLM.
Pour les équipes analytics, l’étape pratique est de savoir quelles réglementations régissent chaque mission client et de tracer la façon dont les flux de données des agents IA interagissent avec chacune d’elles avant de connecter un agent aux systèmes de ce client.
À quoi ressemble un usage conforme
Les préoccupations de conformité ci-dessus ne signifient pas que les agents IA sont incompatibles avec le travail sur des données réglementées. Elles signifient que la clarté réglementaire doit précéder le déploiement, pas le suivre.
La séquence qui crée une exposition légale est : déployer l’agent → obtenir de la valeur → espérer que la conformité suive. La séquence qui crée un usage défendable est : réviser l’ATD et les réglementations applicables → identifier les activités de traitement couvertes par l’accord → limiter l’accès de l’agent à ce qui est couvert → mettre à jour l’ATD si un usage plus large est nécessaire → déployer l’agent.
En pratique, cela signifie :
Auditez vos ATD avant de connecter des agents aux systèmes client. Cherchez spécifiquement les clauses couvrant le traitement par IA, l’usage d’API LLM et l’autorisation de sous-traitants. Si l’accord date d’avant 2024, il ne couvre certainement pas cela.
Utilisez des modèles locaux pour tout ce qui doit rester local. Ollama faisant tourner Llama ou DeepSeek localement signifie qu’aucune donnée ne quitte votre machine via API. Vous perdez des capacités par rapport aux modèles de pointe, mais vous éliminez entièrement la relation de sous-traitance tierce. Pour les données qui ne peuvent pas aller vers des tiers, l’inférence locale est l’architecture appropriée.
Séparez l’accès des agents selon la sensibilité des données. L’agent qui génère des résumés à partir de métriques publiques n’a pas besoin d’accéder au même schéma que l’agent qui surveille les tables PII. Limitez l’accès au niveau du compte de service — chaque client dispose d’un compte de service dédié en lecture seule avec accès uniquement aux schémas dont l’agent a réellement besoin.
Documentez vos flux de données. Le principe d’accountability du RGPD exige que vous puissiez démontrer la conformité, pas seulement l’affirmer. Un diagramme de flux de données montrant ce à quoi l’agent accède, ce qui va vers quelle API LLM et sur quelle base légale est le début de cette documentation.
Le paysage réglementaire pour l’IA agentique est encore en formation. L’avertissement de l’AP néerlandaise et le commentaire de l’ICO britannique signalent tous deux que des orientations formelles sont à venir. La direction des évolutions réglementaires est claire ; faire des choix conservateurs sur l’accès aux données et l’usage des API LLM avant les règles formelles coûte moins cher que la remédiation après coup.
Consultez Posture de sécurité pour les agents IA pour les contrôles d’accès techniques qui soutiennent les déploiements conformes, et Risques de sécurité OpenClaw — Ce qui est documenté pour les incidents documentés spécifiques qui informent la réponse réglementaire.