IA souveraine en Asie du Sud-Est. Ce que disent les réglementations de Singapour et d'Indonésie.

Singapour : des principes, une pression sectorielle, une base qui évolue.

Depuis notre bureau de Singapour, nous entendons la même ouverture chez la plupart des équipes globales. Elles disposent d'une architecture IA opérationnelle pour l'Europe, parfois pour les États-Unis, et elles veulent comprendre ce qui change quand le même workload tourne pour une entité régulée à Singapour. La première réponse honnête, c'est que le cadre singapourien a rarement été ce qui bloque un déploiement. Le Personal Data Protection Act pose les attentes de base sur les données personnelles, avec des obligations de notification, de consentement et de redevabilité que toute entreprise bien gérée a déjà cartographiées. Ce qui s'est resserré ces dernières années, c'est la surcouche sectorielle, en particulier pour les services financiers et la santé, où les régulateurs publient une guidance avec laquelle tout déploiement IA sérieux est censé s'aligner.

Le Model AI Governance Framework, dans sa forme en évolution, est devenu un point de référence utile dans nos discussions avec les comités de pilotage. Il n'est pas statutaire au même titre que l'AI Act européen, mais il signale la discipline que les entités régulées basées à Singapour sont censées démontrer. Redevabilité interne, supervision humaine des décisions conséquentes, tests de robustesse, transparence sur le comportement du modèle. Le framework ne prescrit pas un choix technologique ; il prescrit les contrôles qui doivent entourer la technologie choisie, quelle qu'elle soit.

Pour une entreprise mondiale, cela signifie en pratique que la présence singapourienne ne requiert que rarement une stratégie IA séparée. Elle requiert une extension claire de la posture globale de gouvernance, avec des contrôles documentés qu'un régulateur singapourien peut examiner s'il le décide. Les équipes avec lesquelles nous travaillons et qui opèrent déjà sous une gouvernance IA à l'européenne trouvent généralement la charge singapourienne supplémentaire gérable, sous réserve que la documentation puisse être produite localement et expliquée à un public local.

Indonésie : l'UU PDP et la conversation sur la résidence.

Dans les conversations que nous tenons depuis notre bureau de Bali avec des équipes globales envisageant des déploiements indonésiens, la question réglementaire qui surgit en premier porte presque toujours sur la Loi 27 de 2022, la loi de protection des données personnelles communément appelée UU PDP. La loi a largement aligné la protection des données personnelles indonésienne sur des régimes comparables ailleurs, avec un jeu clair d'obligations d'operator et de controller, des bases légales pour le traitement, la notification de violation, et des dispositions sur le transfert transfrontalier.

Ce que nous signalons généralement aux clients en premier, ce n'est pas la substance de l'UU PDP, que la plupart des équipes juridiques peuvent lire en détail par elles-mêmes, mais les implications opérationnelles pratiques. Les régulateurs indonésiens ont montré un intérêt croissant pour l'endroit où la donnée se trouve, où elle est traitée, et quelles obligations de résidence s'appliquent aux systèmes manipulant les données personnelles de résidents indonésiens. L'attente, dans notre lecture, c'est que toute entreprise exploitant des workloads IA conséquents sur des données clients indonésiennes devrait pouvoir démontrer, en termes concrets, où vit la donnée au repos, où s'exécute l'inférence, et où la piste d'audit est conservée.

Pour les workloads construits sur des fournisseurs de modèles globaux, cela se traduit souvent en questions d'architecture très précises. Quels endpoints de modèles sont joignables depuis une région d'hébergement compatible avec la résidence indonésienne. Quelles configurations de logging envoient les données de prompts et de réponses hors de cette région. Quels instruments contractuels avec le fournisseur de modèles tiennent sous le regard indonésien. Aucune de ces questions n'est insurmontable. Toutes gagnent à être traitées avant qu'un workload ne soit en production plutôt que lors d'une escalade de conformité.

Superposer la conformité régionale sur une stack IA globale.

Le schéma d'architecture que nous recommandons le plus souvent, dans nos échanges avec les directions engineering globales, c'est de garder la stack IA elle-même globale et de traiter les obligations régionales comme un plan de contrôle autour. Les fournisseurs de modèles, l'outillage d'évaluation, la stack d'observability et l'approche de gestion des prompts restent cohérents entre les régions. Ce qui change, ce sont les frontières de résidence, les règles de routage, les configurations de logging et les politiques d'accès.

En pratique, cela signifie un seul ensemble d'agents, d'evaluation suites et de registres de prompts, avec des déploiements à portée régionale qui ancrent l'inférence, la rétention et l'audit à la bonne juridiction. L'équipe globale peut continuer à faire évoluer les capacités des agents sans avoir à maintenir un fork spécifique à Singapour ou à l'Indonésie du code base. Les équipes régionales peuvent démontrer, dossier par dossier, que la donnée traitée par leurs workloads reste à l'intérieur de la frontière qu'attend leur régulateur.

Un effet de bord utile de ce schéma, c'est qu'il rend la surcouche AI Act européen gérable lorsqu'elle s'appliquera à la même stack globale. La discipline qui consiste à séparer l'engineering cœur du plan de contrôle régional est similaire entre les grands régimes, même si les règles spécifiques diffèrent. Les équipes qui construisent cette discipline pour un marché trouvent généralement les marchés suivants plus faciles plutôt que plus difficiles.

Les décisions pratiques qui changent.

Quand une équipe globale nous fait entrer dans la conversation, les décisions que nous finissons par façonner avec elle sont concrètes et opérationnelles plutôt que philosophiques.

Où le workload est hébergé.

Pour les workloads indonésiens traitant des données personnelles, la conversation sur la résidence est passée d'optionnelle à valeur par défaut. Nous conseillons généralement aux clients d'identifier la région d'hébergement en premier, puis les fournisseurs de modèles joignables depuis cette région, puis la chaîne d'outillage. Tenter d'ajouter la résidence après coup à un workload architecturé pour la flexibilité globale est plus difficile que de partir avec la contrainte en tête.

Où vit l'environnement d'évaluation.

Les evaluation suites sont généralement construites une fois et réutilisées. Si ces suites portent de vrais prompts clients, elles portent des données personnelles, et l'endroit où l'évaluation tourne devient une question de résidence à part entière. Nous avons vu des équipes le sous-estimer. Un environnement d'évaluation robuste pour un workload singapourien ou indonésien devrait respecter la même posture de résidence que le workload de production.

Où vivent les logs et pour combien de temps.

L'observability pour les workloads IA est, en pratique, un magasin de données personnelles. Chaque prompt et chaque réponse qu'envoie un utilisateur régulé traverse le pipeline de logging. La politique de rétention, les contrôles d'accès et l'emplacement de stockage de ces logs méritent le même niveau de scrutin que la base de données de production. Dans plusieurs conversations avec les équipes sécurité, nous avons constaté que c'est la zone où l'écart entre l'intention et l'implémentation est le plus large.

Quels instruments contractuels encadrent le fournisseur de modèles.

Les conditions standard des fournisseurs de modèles ont évolué rapidement et ne sont pas toujours alignées avec les obligations qu'une entreprise régulée porte sous l'UU PDP ou la PDPA. La revue contractuelle sur ce point est un vrai travail, et nous recommandons généralement de faire entrer le conseil juridique dans la conversation de conception plutôt que dans un audit post-build.

La souveraineté comme contrainte opérationnelle.

Le cadre qui a le mieux tenu dans notre travail, c'est que la sovereign AI est une contrainte opérationnelle, comparable à un budget de latence ou de coût. Elle façonne l'architecture plutôt qu'elle ne bloque le déploiement. Traitée comme une barrière, elle retarde généralement les programmes et produit des choix défensifs qui limitent la capacité. Traitée comme une entrée précoce dans la conception, elle produit généralement des systèmes plus simples à défendre devant un régulateur et plus faciles à faire évoluer à mesure que les règles évoluent.

D'après les conversations que nous tenons depuis nos bureaux de Singapour et de Bali, le sens du voyage est clair. Les deux régulateurs attendent une discipline plus élevée d'année en année. Les entreprises qui adoptent la discipline tôt plutôt que tard passeront moins de temps à défendre des choix passés et plus de temps à livrer de nouvelles capacités. C'est l'arbitrage que nous posons généralement sur la table au début de chaque conversation IA régionale.