Votre stack IA est un transfert hors frontières (PDPL)

Un distributeur saoudien branche un assistant de support sur son helpdesk. Les tickets partent vers une API de LLM en Virginie, le modèle rédige la réponse, un agent la valide. Mise en production le jeudi, mesure du taux de déflexion le dimanche : ça marche.

C'est aussi, au regard de la loi saoudienne sur la protection des données personnelles (PDPL), un transfert transfrontalier de données personnelles — sans base légale, sans évaluation des risques, sans garantie contractuelle. Personne dans la réunion ne l'a nommé ainsi, parce que ça ne ressemblait pas à un transfert de données. Ça ressemblait à un appel d'API.

Cet angle mort est l'échec de conformité le plus fréquent que nous voyons sur les projets IA dans le Royaume, et 2026 est l'année où il a cessé d'être théorique. Les périodes de tolérance de la SDAIA ont expiré. L'autorité a rendu 48 décisions d'exécution formelles dans plusieurs secteurs, avec des amendes administratives allant jusqu'à 5 millions de SAR par violation, doublées en cas de récidive.

Pourquoi un appel d'API est un transfert

La PDPL ne s'intéresse pas à votre schéma d'architecture. Elle s'intéresse à une seule question : des données personnelles concernant des individus dans le Royaume en sont-elles sorties ?

L'article 3 confère à la loi une portée extraterritoriale plus large que celle du RGPD : elle s'applique au traitement des données personnelles de résidents d'Arabie Saoudite par des entités situées hors du Royaume. Votre fournisseur de modèle n'y échappe pas en étant dans une autre juridiction. Vous n'y échappez pas en le désignant du doigt.

La question devient donc mécanique pour toute fonctionnalité IA : la charge utile qui quitte votre infrastructure contient-elle des données personnelles ? Pour la plupart des déploiements réels, la réponse est oui, et elle arrive par des canaux que les équipes oublient d'auditer :

• Le contenu du prompt — le ticket de support, le CV, la note d'admission médicale, le nom du client dans l'historique
• Le contexte de récupération — les fragments RAG injectés par votre base vectorielle, issus de documents que personne n'a classifiés
• Les arguments d'appel d'outils — un agent qui passe un numéro d'identité national à une fonction de recherche, puis au contexte du modèle
• Les logs et les traces — la couche d'observabilité qui stocke discrètement les prompts complets sur un SaaS étranger pendant 30 jours
• Les jeux de fine-tuning — le transfert le plus permanent de tous

Remarquez combien de ces canaux ne sont pas l'appel au modèle lui-même. Le fournisseur de modèle est en général la seule relation ayant fait l'objet d'une revue contractuelle. L'outil de tracing, la plateforme d'évaluation, la base vectorielle et le SaaS de gestion des prompts, généralement pas.

Ce que le règlement sur les transferts exige réellement

Le Règlement sur le transfert de données personnelles hors du Royaume, publié en août 2024, est le texte opérationnel — et il est plus structuré que la plupart des équipes ne le supposent.

Un transfert exige une finalité autorisée au titre de l'article 29(1) : exécuter des obligations d'un accord auquel le Royaume est partie, servir les intérêts du Royaume, exécuter des obligations envers une personne concernée partie à un accord, ou l'une des finalités définies à l'article 2 du règlement — opérations de traitement centralisées, fourniture d'un service ou d'un bénéfice à la personne concernée, et recherche scientifique.

Il exige ensuite trois conditions additionnelles réunies simultanément : le transfert ne doit pas porter atteinte à la sécurité nationale ni aux intérêts vitaux du Royaume, la juridiction destinataire doit offrir un niveau de protection adéquat déterminé par la SDAIA, et seules les données strictement nécessaires peuvent circuler.

C'est sur l'adéquation que les équipes IA bloquent. La SDAIA n'a pas publié sa liste de juridictions approuvées. La pratique consiste à se rabattre sur les juridictions reconnues adéquates par la Commission européenne au titre du RGPD — une liste qui n'inclut pas les États-Unis, où tourne l'essentiel de l'inférence des modèles de frontière.

Lorsque l'adéquation ou la minimisation ne peuvent être satisfaites, le règlement offre trois garanties, chacune exigeant une évaluation des risques au titre de l'article 7 (la SDAIA a publié son guide d'évaluation des risques en février 2025) :

Deux dispositions comptent plus que les autres pour l'IA. Le transfert de données sensibles — santé, biométrie, génétique, croyance religieuse ou politique, condamnations pénales — est globalement interdit dans les voies « service » et « recherche ». Et la minimisation n'est pas un principe à invoquer dans une charte : c'est une obligation opposable de retirer ce dont vous n'avez pas besoin avant le franchissement de la frontière.

L'architecture : mettez la frontière dans votre propre code

Le schéma conforme n'est pas « arrêtez les modèles étrangers ». C'est de faire de la frontière un lieu unique, réel et auditable de votre système, au lieu d'un accident réparti sur quarante points d'appel.

Concrètement, cela signifie une passerelle de sortie par laquelle transitent tous les appels IA, assurant quatre fonctions :

// Une seule frontière. Tous les appels au modèle passent par là.
async function callModel(input: ModelRequest, ctx: RequestContext) {
  // 1. Classifier — qu'y a-t-il réellement dans cette charge utile ?
  const classified = classify(input.messages);
  if (classified.hasSensitive) {
    // Santé, biométrie, génétique, croyance, condamnation :
    // router vers une inférence dans le Royaume, ou refuser.
    return routeToRegionalModel(input, ctx);
  }
 
  // 2. Minimiser — tokeniser les identifiants avant la sortie
  const { payload, vault } = tokenise(classified, [
    "national_id", "iqama", "phone", "iban", "full_name", "email",
  ]);
 
  // 3. Transférer sur une base enregistrée
  const res = await provider.complete(payload, {
    transferBasis: ctx.transferBasis,   // finalité art. 29(1), tracée
    zeroRetention: true,                // ni stockage ni entraînement côté fournisseur
  });
 
  // 4. Ré-identifier dans le Royaume, journaliser les métadonnées, pas le contenu
  audit.record({
    basis: ctx.transferBasis, destination: provider.region,
    fieldsTokenised: vault.keys(), sensitive: false, at: ctx.now,
  });
  return detokenise(res, vault);
}

L'étape de tokenisation est celle qui se rentabilise seule. Un ticket où le nom du client est remplacé par PERSON_1 et l'iqama par ID_1 représente matériellement moins de données personnelles franchissant la frontière, et la qualité de la réponse ne change pas — les LLM raisonnent sur des rôles, pas sur des identités. Vous convertissez un transfert illimité en transfert minimisé, ce qui est précisément la condition de l'article 29 que vous ne pouviez pas satisfaire autrement.

Quatre décisions découlent d'une frontière unique :

Coupez la rétention partout, par écrit. Les offres « zéro rétention » existent chez tous les grands fournisseurs. Activez-les, et faites-les figurer au contrat, pas sur la page marketing. Un log conservé 30 jours côté fournisseur est un transfert que vous n'avez pas évalué.

Auditez la seconde couche. Vos outils de tracing, d'évaluation, de gestion de prompts et votre infrastructure vectorielle sont des sous-traitants soumis aux mêmes obligations, avec une fraction de la vigilance. Si votre fournisseur d'observabilité stocke le corps complet des prompts hors du Royaume, c'est un transfert.

Constituez le registre avant d'en avoir besoin. L'enregistrement sur la Plateforme nationale de gouvernance des données est obligatoire pour les responsables de traitement effectuant des transferts transfrontaliers ou traitant des données sensibles, et un DPO est obligatoire lorsque le traitement à grande échelle est une activité principale. La notification de violation est de 72 heures. Si la SDAIA notifie une infraction, le délai de réponse formelle via le portail est de cinq jours — insuffisant pour bâtir un registre de transferts à partir de zéro.

Segmentez la couche modèle par classe de données. La plupart des charges IA n'ont pas besoin d'un modèle de frontière sur des données personnelles. Les données sensibles et identifiées vont vers une inférence locale ou auto-hébergée ; les charges anonymisées vont là où elles performent le mieux. C'est une décision de routage, bien moins coûteuse prise une fois à la passerelle que rétro-adaptée fonctionnalité par fonctionnalité.

Ce que coûte l'impasse

Le vrai coût n'est pas le plafond de 5 millions de SAR. C'est que les fonctionnalités IA se construisent, atteignent le pilote, puis s'enlisent en revue sécurité sans issue — parce que les flux de données ont été conçus avant que quiconque demande où ils aboutissaient, et les défaire suppose de réécrire la couche d'intégration.

Nous le voyons surtout sur des systèmes jamais conçus pour un consommateur IA : un ERP avec une couche de reporting greffée, un helpdesk avec un job d'export, un CRM dont l'API renvoie la fiche client complète parce que c'est le seul endpoint disponible. Le projet IA hérite de chaque champ trop large. La couche d'intégration est l'endroit où cela se corrige — et c'est la même raison pour laquelle remplacer l'ERP n'est presque jamais la bonne réponse.

Le reste de la discipline est familier à qui a réfléchi à l'identité des agents et à l'IAM non humain : cadrez ce que la machine peut atteindre, enregistrez ce qu'elle a fait, et supposez que vous devrez prouver les deux. La PDPL ajoute simplement une géographie à la question. Et si vous arbitrez où l'inférence doit physiquement tourner, le paysage du cloud souverain dans la région bouge assez vite pour changer la réponse en un an.

Commencez par la carte, pas par la politique

Avant de rédiger la moindre politique, produisez un seul artefact : un tableau de chaque flux de données touchant l'IA, avec le pays de destination, les catégories de données personnelles dans la charge utile, la rétention côté distant, et la finalité de l'article 29 que vous invoqueriez.

La plupart des équipes constatent que cela prend un après-midi et fait remonter trois flux dont personne n'avait connaissance — typiquement un outil de tracing, un export tableur, et une intégration bâtie pendant un pilote qui est discrètement passée en production.

Ce tableau est à la fois votre registre de transferts, votre entrée d'évaluation des risques et votre backlog d'architecture, sur une seule page. Tout le reste — clauses types, tokenisation, routage régional — découle de savoir ce qui sort réellement.

Vous ne savez pas ce que vos fonctionnalités IA envoient à l'étranger ? Nous cartographions vos flux de données IA face aux conditions de transfert de la PDPL et vous rendons le registre plus les changements d'intégration nécessaires pour combler les écarts — pas de modèles de politique, juste l'architecture. Dites-nous ce que vous faites tourner et nous cadrons le travail.