AI Act, RGPD, NLPD : les garde-fous à poser avant le premier pilote IA

Trois textes encadrent désormais l'usage de l'IA en entreprise dans l'espace franco-suisse. L'AI Act européen, dont les obligations principales sont entrées en application courant 2025 et 2026. Le RGPD, qui s'applique dès qu'un pilote traite des données personnelles. La NLPD suisse, équivalent helvétique du RGPD, applicable aux entreprises suisses ou aux flux transfrontaliers concernant des résidents suisses. Chacun apporte ses propres contraintes, et leur combinaison crée une géométrie de conformité qu'un sponsor exécutif a tout intérêt à instruire avant le pilote, pas après.

Le réflexe défensif, repousser l'instruction conformité à la fin du POC, produit régulièrement des découvertes tardives qui invalident plusieurs semaines de travail. Le réflexe excessif, instruire tout, exhaustivement, avant la première ligne de code, produit le pilot purgatory de la conformité, où aucun pilote ne démarre jamais. La discipline utile est ailleurs : instruire les bons garde-fous, au bon niveau de détail, au moment du cadrage.

Voici comment on procède, dans la pratique BUMPSLAB, pour un premier pilote IA en PME ou ETI franco-suisse.

L'AI Act : ce qui s'applique vraiment à un premier pilote

L'AI Act distingue plusieurs niveaux de risque. Pour un sponsor qui engage son premier pilote, l'essentiel tient en trois catégories.

Les systèmes interdits. Manipulation cognitive ciblée, exploitation de vulnérabilités, notation sociale par les autorités publiques, certaines formes de reconnaissance biométrique en temps réel dans l'espace public. Cette catégorie ne concerne, en pratique, quasiment aucun pilote PME ou ETI civilien. Le filtre est binaire, si vous y êtes, vous ne devriez pas être en cadrage de premier coup.

Les systèmes à haut risque. C'est la catégorie sensible. Sont concernés notamment les systèmes IA utilisés dans le recrutement, la gestion des employés, la notation crédit, certains usages dans l'éducation et la santé, l'accès à des services publics essentiels, l'application de la loi, et les composants de sécurité de produits régulés. Un pilote dans l'une de ces catégories impose un cadre lourd, documentation technique, gestion des risques, qualité des données, supervision humaine documentée, journalisation, transparence vis-à-vis des personnes concernées. Ce n'est pas un cadre qu'on improvise pendant un POC. C'est un préalable.

Les systèmes à risque limité ou minimal. La majorité des candidats IA en PME et ETI tombe dans cette catégorie. Recherche assistée documentaire, extraction de factures, pré-rédaction de devis, classification de mails internes. Les obligations restent significatives, transparence sur l'usage de l'IA auprès des utilisateurs finaux, marquage des contenus générés dans certains cas, mais elles sont compatibles avec un pilote livrable en six à huit semaines.

L'arbitrage fondamental se joue au cadrage : le candidat tombe-t-il dans la catégorie haut risque, ou en marge. Si le doute existe, il faut le lever avant le pilote. Engager un pilote en supposant qu'il est à risque limité alors qu'il est à haut risque expose à reprendre tout le cadre conformité après coup, généralement au prix d'une refonte.

Le RGPD : la grille des trois questions

Le RGPD s'applique dès qu'un pilote IA traite des données personnelles. La définition est large : un nom, un mail, un identifiant client, parfois même un identifiant interne. Beaucoup de pilotes labellisés « pas de données personnelles » en début de cadrage se révèlent en contenir au moment du scoping technique.

La grille pratique en trois questions, à poser au cadrage.

Première question : la base légale du traitement est-elle identifiée. Consentement, exécution contractuelle, intérêt légitime, obligation légale. Un pilote dont la base légale n'est pas écrite noir sur blanc est un pilote qui partira en arbitrage juridique au moment de la production, et ces arbitrages prennent des semaines.

Deuxième question : la finalité du traitement est-elle compatible avec la finalité initiale de collecte des données. Un pilote qui mobilise des données collectées pour un autre usage (par exemple analyser des comptes rendus de RDV collectés pour le suivi commercial) peut être en porte-à-faux. C'est ce qu'on appelle le détournement de finalité, qui peut nécessiter une information complémentaire des personnes ou une nouvelle base légale.

Troisième question : quelles sont les durées de conservation des données mobilisées par le pilote, y compris les données dérivées (embeddings, indexations, logs de prompts). C'est la question qu'on néglige le plus. Un système RAG produit, par exemple, des vecteurs dérivés des documents source, ces vecteurs sont des données personnelles s'ils peuvent être reliés à des personnes. Leur durée de conservation doit être cohérente avec la donnée source.

Si ces trois réponses ne sont pas claires en cadrage, le pilote partira sur des hypothèses qu'il faudra défendre devant le DPO ou un contrôle CNIL. Mieux vaut les poser à plat avant le code.

La NLPD : ce que change le périmètre suisse

La NLPD suisse, entrée en vigueur en septembre 2023, est largement alignée sur le RGPD mais conserve plusieurs spécificités importantes pour un pilote IA opéré en Suisse ou impliquant des résidents suisses.

L'analyse d'impact relative à la protection des données (DPIA en RGPD, AIPD ou équivalent en NLPD) est exigée dans des cas similaires, mais le seuil de déclenchement et les conditions de réalisation diffèrent. Un pilote conçu côté français avec une DPIA RGPD ne sera pas automatiquement conforme NLPD s'il opère en Suisse, il faut le confirmer.

Le profilage automatisé est encadré spécifiquement. La NLPD impose un droit d'objection et de transparence renforcée quand une décision automatisée a un effet significatif sur la personne concernée. Un pilote de scoring crédit ou de qualification commerciale automatisée doit prévoir ce mécanisme dès le cadrage.

Les flux transfrontaliers vers des pays sans niveau de protection adéquat (notamment certaines configurations vers les États-Unis) demandent des clauses contractuelles types ou un accord d'adéquation. C'est un sujet à instruire si le pilote mobilise un fournisseur de modèles IA hébergé hors UE ou hors Suisse.

Sur un pilote franco-suisse, la pratique utile consiste à instruire conjointement RGPD et NLPD au cadrage, pour identifier les écarts éventuels et caler le pilote sur le niveau d'exigence le plus haut des deux. Ça évite les surprises lors du passage en production.

L'hébergement et la souveraineté

Au-delà du strict cadre légal, la question de l'hébergement des modèles et des données mobilisés par le pilote est devenue, en 2026, une partie intégrante du cadrage conformité.

Les options se sont diversifiées. Modèles propriétaires hébergés en UE ou en Suisse (Mistral AI, certaines offres Microsoft Azure en région suisse ou européenne, déploiements souverains spécialisés). Modèles open-weights opérés sur infrastructure interne ou sur cloud souverain. Modèles propriétaires américains avec données traitées sous contrôle (Bedrock, Vertex AI dans certaines configurations).

Le choix dépend du périmètre du pilote. Pour des données strictement internes non personnelles, l'arbitrage est principalement économique. Pour des données personnelles ou sensibles, l'arbitrage devient un sujet de gouvernance, à instruire avec le DPO et la sécurité.

L'erreur fréquente : engager un pilote sur une infrastructure cloud sans avoir instruit l'arbitrage hébergement, et découvrir au passage en production que la configuration n'est pas tenable. La règle pratique : poser l'hébergement comme une contrainte du cadrage, pas comme une variable d'ajustement post-POC. Ça change parfois le choix du modèle technique, mais évite les refontes.

Le cas client : un pilote suspendu par un détournement de finalité

Un acteur de la santé suisse, 90 collaborateurs, avait engagé en 2025 un pilote IA de recherche assistée sur les comptes rendus médicaux internes. Le pilote technique fonctionnait. Le métier était demandeur. Le sponsor exécutif portait le projet.

Au moment du passage en production, le DPO a signalé un détournement de finalité. Les comptes rendus avaient été collectés et conservés pour le suivi patient. Leur indexation pour une recherche transversale par un outil IA constituait un nouveau traitement, avec une finalité distincte. Sans nouvelle base légale ni information complémentaire des patients, le pilote n'était pas déployable en l'état.

Six semaines de suspension. Renégociation de la base légale (intérêt légitime avec mise en balance documentée), information complémentaire dans le parcours patient, restriction du périmètre indexé. Le pilote a finalement passé en production, mais avec un retard et une perte de confiance interne qui auraient été évités par un cadrage conformité au démarrage.

Sur un AI Use Case Audit, cette question, finalité initiale des données vs finalité du pilote, est instruite J2, au moment de la vérification d'actif. Elle ne demande pas une expertise juridique avancée pour être posée. Elle demande qu'on y pense avant le code.

L'instruction conformité dans un audit en 5 jours

Un audit cinq jours ne produit pas une analyse juridique exhaustive. Il produit un cadre instruit au niveau qui permet d'engager le pilote sans surprise majeure. Concrètement, cela couvre cinq éléments.

D'abord, le classement du candidat dans la grille AI Act (interdit, haut risque, limité, minimal). Si le candidat est en haut risque ou en marge, l'audit le signale et le sponsor décide d'engager le cadre lourd ou de basculer sur un autre candidat.

Ensuite, l'identification des données personnelles mobilisées, et la qualification de la base légale et de la finalité. Si ces éléments ne sont pas clairs, l'audit produit la liste des questions à poser au DPO avant le pilote, pas l'analyse juridique elle-même.

Puis, le périmètre d'hébergement requis, en fonction de la sensibilité des données et des contraintes franco-suisses. Cela conditionne le choix du modèle technique et le chiffrage.

Quatrième élément : les éventuels droits des personnes concernées qui doivent être préservés (information, accès, objection, droits sur les décisions automatisées). C'est rarement complexe pour un premier pilote, sauf si le sujet est en haut risque AI Act.

Cinquième élément : le journal d'audit et la traçabilité minimale à prévoir dès le pilote. Pas le journal complet d'un système industriel, mais le squelette qui sera étoffé en production.

Ces cinq éléments, instruits en cinq jours, suffisent à éviter 80 % des surprises de conformité au passage en production. Le reste, analyse juridique formelle, validation DPO, instruction sécurité, vient ensuite, sur un cadre déjà posé.

Ce qu'il faut éviter

Trois écueils fréquents.

Supposer que le pilote n'est pas concerné parce qu'il est petit ou interne. Le RGPD et la NLPD s'appliquent indépendamment de la taille du pilote. Un POC de quinze utilisateurs sur des données personnelles relève des mêmes obligations qu'un déploiement de mille.

Reporter l'instruction conformité au passage en production. La conformité n'est pas un sujet de fin de POC. C'est un sujet de cadrage, parce que les choix de cadrage (données mobilisées, hébergement, mécanismes de contrôle) déterminent les obligations.

Confondre conformité et opportunité de communiquer. La conformité ne se règle pas par une page « Notre engagement IA responsable » sur le site corporate. Elle se règle par des décisions de cadrage tracées dans la fiche initiative.

---

Si vous engagez un pilote IA en contexte franco-suisse et que vous souhaitez instruire AI Act, RGPD et NLPD au cadrage plutôt qu'au passage en production, l'AI Use Case Audit en cinq jours intègre l'instruction conformité dans la fiche initiative, sans transformer l'audit en analyse juridique exhaustive.