« On a déjà un registre, on est en règle. » Cette phrase, entendue au lancement de presque tout projet d'IA à Monaco, est le meilleur indicateur que la conformité va déraper. Parce qu'un système d'Intelligence Artificielle ne se contente pas de traiter des données personnelles : il en ingère pour s'alimenter, il en croise pour proposer, il en transmet à des briques techniques pour fonctionner. Chacun de ces gestes déclenche une obligation précise au titre de la loi n°1.565, et c'est exactement à ces endroits, invisibles depuis un registre, que les déploiements se font rattraper.
La loi n°1.565 du 3 décembre 2024 a modernisé le cadre monégasque de protection des données personnelles et l'a aligné sur le RGPD européen et la Convention 108+ du Conseil de l'Europe. L'autorité de contrôle, l'APDP (Autorité de Protection des Données Personnelles), succède à la CCIN avec des pouvoirs élargis. Précisons d'emblée le périmètre de cet article : la loi n°1.565 régit la dimension « données personnelles » d'un projet, pas l'ensemble de la question de l'IA. C'est précisément cette dimension qui fait dérailler la majorité des déploiements, et c'est elle que nous déroulons ici, obligation par obligation, dans l'ordre où un pipeline les rencontre.
Le réflexe à corriger d'abord : l'IA n'est pas un traitement, c'est plusieurs
Quand un cabinet déclare « j'ai un projet d'IA », il pense en général à une finalité unique : répondre plus vite aux clients, préparer un dossier KYC, rédiger un projet de procès-verbal. Du point de vue de la loi n°1.565, ce n'est jamais un seul traitement. C'en est au moins trois, empilés, et chacun a sa propre logique de conformité.
- Le jeu de données qui alimente le système (documents indexés, historiques, courriels), avec sa licéité propre.
- Le traitement au moment de l'usage (l'agent qui lit, croise, propose), avec sa base légale et sa minimisation.
- Les flux sortants vers les briques techniques (modèle de langage, hébergeur, outils connectés), avec leur statut de sous-traitance et leurs transferts.
Tant qu'on raisonne « un projet, une déclaration », on passe à côté de deux tiers des obligations. La conformité d'un système d'IA se construit couche par couche, parce que c'est ainsi qu'il est bâti. Le registre ne ment pas : il décrit le projet tel qu'on l'a pensé, pas tel que la machine le fait vivre.
La base légale, appliquée à ce que fait réellement le modèle
La loi n°1.565 exige une base légale pour chaque traitement : consentement, exécution d'un contrat, obligation légale, ou intérêt légitime. Sur le papier, tout le monde le sait. La difficulté, avec l'IA, est que la base légale du métier ne couvre pas automatiquement ce que le système fait des données.
Prenons un family office qui consolide un patrimoine. La collecte des pièces du client repose sur l'exécution du contrat de mandat : limpide. Mais si l'on décide d'indexer dix ans d'archives clients pour qu'un agent puisse « retrouver des situations comparables », on a créé une nouvelle finalité, dont le fondement n'est plus le mandat d'un client donné, mais l'intérêt légitime du cabinet à mieux servir. Cet intérêt légitime se revendique, il se documente, et il se met en balance avec les droits des personnes concernées. Cette mise en balance n'est pas un détail de juriste : c'est l'analyse qui décide si le flux a le droit d'exister, et c'est elle qui manque le jour où l'APDP pose la question.
Le bon réflexe, dès le cadrage : pour chaque flux de données qui entre dans le système, écrire en une phrase pourquoi on a le droit de le faire. Si la phrase ne vient pas, le flux n'a rien à faire dans le pipeline. C'est un test brutal, et c'est le plus efficace que nous connaissions pour assainir un périmètre avant la première ligne de code.
La minimisation : un agent n'a pas besoin de tout voir
C'est l'obligation la plus contre-intuitive pour qui découvre l'IA, et la plus puissante. On imagine qu'un modèle est d'autant meilleur qu'on lui donne accès à tout. La loi n°1.565 dit l'inverse : on ne traite que les données adéquates, pertinentes et limitées à la finalité. Et la technique, bien menée, donne raison à la loi.
Concrètement, on ne branche pas un agent sur l'ensemble du système d'information. On lui ouvre un périmètre. Pour un assistant qui prépare des relances d'appels de fonds chez un syndic, l'agent a besoin du nom du copropriétaire, de sa quote-part et de son solde : il n'a aucun besoin de connaître la composition de son foyer, ses échanges privés avec le conseil syndical ou son dossier d'assurance. Ce cloisonnement n'est pas une consigne donnée au modèle (un modèle exécute mal les interdictions) : c'est une restriction d'accès posée en amont, au niveau de la donnée elle-même, par client et par finalité, de sorte que le système ne reçoive jamais ce qu'il n'a pas à voir, même s'il le voulait.
La minimisation n'est pas une contrainte que l'on subit après coup : c'est la meilleure protection technique qui existe. Une donnée qu'un agent n'a jamais reçue ne peut être ni fuitée, ni biaisée, ni reprochée par l'APDP. On ne sécurise jamais aussi bien que ce qu'on a choisi de ne pas exposer.
RAG ou entraînement : deux régimes, deux niveaux de risque
Voici la distinction qui sépare les projets bien conçus des autres, et que presque personne n'explique aux dirigeants. Faire fonctionner une IA sur vos documents peut signifier deux choses radicalement différentes.
L'entraînement (fine-tuning)
On modifie les paramètres internes du modèle avec vos données. Celles-ci sont alors absorbées dans le modèle, fondues dans ses poids, sans qu'aucune ligne ne reste isolable. Conséquences en conformité : il devient très difficile de prouver qu'une donnée a été effacée, car le droit à l'effacement de la loi n°1.565 se heurte à un modèle qui ne « désapprend » pas proprement ; et le risque de restitution involontaire d'une information confidentielle, au détour d'une réponse, existe réellement. Pour des données couvertes par le secret professionnel monégasque, c'est rarement le bon choix.
L'alimentation par récupération (RAG)
Ici, le modèle n'est pas modifié. Vos documents restent dans une base que vous contrôlez, découpés et indexés pour la recherche. À chaque question, le système va chercher les seuls passages pertinents et les fournit au modèle comme contexte, le temps d'une réponse, puis les retire. La donnée n'entre jamais dans les poids du modèle ; elle reste chez vous, à côté. Trois conséquences décisives en découlent : l'effacement redevient simple (on retire le document de l'index, il disparaît de toute réponse future) ; la traçabilité est native, puisque le système sait quelle source a servi à quelle réponse et peut la citer ; et le cloisonnement par client est réel, parce qu'on ne donne accès qu'à l'index autorisé.
Pour l'immense majorité des usages monégasques (gestion patrimoniale, dossiers d'armateurs, copropriétés, dossiers de clinique), un RAG sur des documents dont vous gardez la main est non seulement plus simple à exploiter, mais structurellement plus conforme. Quand un fournisseur propose « d'entraîner un modèle sur vos données », la première question à poser est donc : parle-t-on d'entraînement réel, ou de RAG ? Dans la conversation courante, le mot « entraîner » désigne souvent du RAG. Les implications juridiques, elles, ne sont pas du même ordre, et l'écart se paie au moment d'une demande d'effacement.
Décision automatisée et intervention humaine : une exigence, pas un confort
La loi n°1.565, dans la lignée du RGPD, encadre les décisions produisant des effets juridiques ou affectant significativement une personne lorsqu'elles sont prises sur un fondement exclusivement automatisé. La personne a alors droit à une intervention humaine, à l'expression de son point de vue, et à la contestation de la décision.
Ce point est systématiquement sous-estimé, parce qu'on se dit « mon IA ne décide pas, elle assiste ». La frontière est plus fine qu'il n'y paraît. Un agent qui classe automatiquement un dossier client en « risque LCB-FT élevé » et déclenche un blocage, un outil qui rejette une candidature de location dans un immeuble de prestige, un scoring qui refuse une entrée en relation : si l'humain ne fait qu'entériner la sortie de la machine sans réelle marge d'appréciation, on est en décision automatisée, avec les obligations qui vont avec.
D'où le principe que nous tenons sur chaque déploiement : l'IA prépare, ordonne, propose et motive ; l'humain décide. Le « human-in-the-loop » n'est pas une précaution d'image. C'est ce qui garde le traitement du bon côté de la loi, à condition que la validation soit substantielle. Un humain qui clique « OK » mille fois par jour sans lire ne constitue pas une intervention humaine au sens du texte. La conformité se joue alors dans l'ergonomie : on conçoit le poste de validation pour que le motif de la proposition soit lisible, que rejeter coûte le même geste qu'accepter, et que la décision reste réelle plutôt que réflexe.
Transferts et sous-traitants : pourquoi l'architecture souveraine simplifie tout
Un système d'IA « grand public » fait par défaut transiter vos données vers des serveurs hors de la Principauté, souvent hors d'Europe. La loi n°1.565 encadre strictement ces transferts hors du territoire monégasque et impose un encadrement contractuel des sous-traitants. Chaque brique technique que vous branchez (le modèle de langage, l'hébergeur, l'outil de messagerie connecté à l'agent) est juridiquement un sous-traitant, avec un contrat à signer, une localisation à connaître et des garanties à vérifier. Un pipeline d'IA assemble vite cinq ou six de ces briques ; autant de maillons à documenter.
C'est ici que l'architecture cesse d'être un sujet d'ingénieur pour devenir un sujet de conformité. Si le traitement se déroule en Principauté ou sur un cloud privé européen maîtrisé (chez un hébergeur local comme Monaco Cloud, Monaco Telecom ou Telis, ou en déploiement privé européen), la question des transferts hors zone se résorbe en grande partie : il n'y a tout simplement plus de flux à encadrer vers l'extérieur. Le nombre de sous-traitants fond, la chaîne contractuelle se raccourcit, et la démonstration de conformité devient lisible. On reste agnostique sur le modèle utilisé (Claude, Mistral AI ou Gemini selon les cas) : ce qui compte n'est pas la marque qui calcule, mais l'endroit où la donnée est traitée et la nature du contrat qui la régit.
Autrement dit, la souveraineté n'est pas qu'une posture rassurante pour la Place : c'est une décision d'architecture qui supprime mécaniquement une partie des obligations les plus lourdes de la loi n°1.565. À Monaco, où le secret professionnel est un pilier de réputation, cette suppression à la source vaut bien mieux qu'un empilement de clauses contractuelles censées rattraper un flux qu'on aurait pu ne jamais créer.
L'analyse d'impact (AIPD) : quand elle est requise et ce qu'elle contient
L'analyse d'impact relative à la protection des données n'est pas optionnelle lorsqu'un traitement est susceptible d'engendrer un risque élevé pour les droits des personnes. Or un projet d'IA coche très souvent les critères qui la déclenchent : traitement à grande échelle, données sensibles, croisement de sources, évaluation ou scoring de personnes, part d'automatisation. Pour beaucoup de cas d'usage monégasques, la question n'est pas « faut-il une AIPD ? » mais « l'a-t-on faite avant de coder, ou va-t-on la subir ? ».
Une AIPD utile décrit le traitement et ses finalités, justifie la nécessité et la proportionnalité (c'est là que la minimisation se prouve, pièce à l'appui), recense les risques pour les personnes et les mesures qui les réduisent (cloisonnement, journalisation, validation humaine, résidence des données), puis conclut sur le risque résiduel. Menée en amont, elle prend quelques jours et oriente l'architecture : elle dit où entraîner serait imprudent, quel flux retirer, quel accès restreindre. Menée après coup, elle se transforme en autopsie, et peut geler un projet entier au moment précis où il allait passer en production.
Le cas des acteurs financiers : 1.565 rencontre la LCB-FT
Pour une banque privée, un family office ou une profession financière, un deuxième cadre se superpose : la LCB-FT (lutte contre le blanchiment et le financement du terrorisme), encadrée par la loi n°1.362 et supervisée par le SICCFIN. Et les deux logiques peuvent tirer en sens opposé.
La LCB-FT impose de conserver, de surveiller, de documenter. La loi n°1.565 impose de minimiser, de limiter la durée de conservation, de respecter les droits des personnes. Un agent qui automatise une partie du screening LCB-FT vit exactement à cette intersection. La bonne nouvelle : les deux cadres se concilient si on les traite ensemble dès la conception. La conservation imposée par la LCB-FT constitue une obligation légale qui fournit, justement, la base légale et la durée que réclame la loi n°1.565 : ce que l'une commande, l'autre l'accepte, à condition que ce soit écrit. Encore faut-il distinguer ce qui relève de l'obligation réglementaire de ce qui relève du confort opérationnel, et ne pas conserver « par habitude » ce que rien n'impose de garder. Un droit d'accès exercé par un client sur le motif d'un blocage LCB-FT, lui, se heurte aux règles de non-divulgation propres à la matière : c'est typiquement le genre d'arbitrage qui se prépare en amont, pas en urgence.
À quoi ressemble un pipeline d'IA conforme
Mis bout à bout, voici le schéma d'un système d'IA qui tient devant l'APDP. Il se lit comme une chaîne, et chaque maillon répond à une obligation précise.
- Sources qualifiées : on sait quelles données entrent, d'où elles viennent, et sur quelle base légale (la cartographie d'abord, jamais la modélisation).
- Minimisation et cloisonnement : l'agent ne reçoit que le strict nécessaire, isolé par client et par finalité, restriction posée au niveau de l'accès.
- Traitement local et journalisé : le calcul a lieu en zone souveraine, en RAG plutôt qu'en entraînement, et chaque accès, chaque source, chaque sortie est tracé.
- Validation humaine substantielle : rien à effet significatif ne sort sans une décision humaine réelle, outillée pour rester réelle.
- Registre et AIPD vivants : le traitement est inscrit au registre, l'analyse d'impact est faite et mise à jour quand le périmètre bouge.
Ce n'est pas une couche que l'on pose à la fin sur un système déjà construit. C'est l'ordre dans lequel on le construit. La conformité bien menée ne ralentit pas le projet : elle lui évite de s'arrêter en route, ce qui reste la première cause d'échec des déploiements d'IA. Et lorsque le projet relève d'un programme numérique structurant, cette rigueur de cadrage est aussi ce qui rend un dossier présentable au Fonds Bleu d'Extended Monaco, dont le cofinancement public peut atteindre 70 % HT pour les entités éligibles.
Où s'arrête notre rôle
Disons-le sans détour : cet article décrit une méthode d'ingénierie de la conformité, pas un avis juridique. Minervia cadre ces obligations dès l'audit, conçoit l'architecture pour qu'elles soient tenues par construction, et documente ce qui doit l'être. Mais la qualification juridique d'un traitement, la rédaction des mentions, l'arbitrage d'un intérêt légitime délicat ou l'interface avec l'APDP relèvent de votre conseil juridique et de votre DPO. Les meilleurs projets que nous accompagnons sont précisément ceux où l'expertise technique et le conseil juridique travaillent ensemble, dès la première semaine, parce que la plupart des erreurs coûteuses se logent à la frontière des deux.
Si vous lancez un projet d'IA et que vous ne savez pas répondre, pour chaque flux de données, à la question « sur quelle base, vu par qui, traité où, validé par qui, tracé comment », c'est le bon moment pour un audit. Mieux vaut poser ces cinq questions avant la première ligne de code qu'après la première demande de l'APDP.