Où vont nos données ? IA, RGPD et AI Act pour les décideurs

La plupart des projets IA que nous voyons ne bloquent pas sur le modèle. Ils bloquent en réunion, quand le DPO demande où vont les données clients et que personne autour de la table ne sait répondre.

La réponse courte : là où vous le décidez. Hébergement en Europe, dans votre cloud ou on-premise. Le vrai travail, c'est de trancher dès le premier jour, pas une fois le prototype en marche.

Cet article liste les questions que nous réglons avant d'écrire la moindre ligne de code. Ce n'est pas un avis juridique : votre avocat ou votre DPO a le dernier mot sur votre cas.

Partir des données, pas du modèle

Avant de choisir un modèle, notez ce que le système va lire. E-mails clients, contrats, dossiers médicaux, fiches de paie, tickets de support : chacun pèse un poids différent au regard du RGPD.

Suivez ensuite un enregistrement à travers le système. Où est-il stocké, où est-il traité, qui peut le lire, combien de temps y reste-t-il. Si l'une des réponses est « quelque part chez le fournisseur », vous tenez votre première tâche.

En pratique, trois questions couvrent l'essentiel :

• Y a-t-il des données personnelles ? Un nom dans un PDF compte. Un identifiant client qui renvoie à une personne aussi.
• Doivent-elles sortir de vos systèmes ? Souvent, seul un fragment en a besoin. Un assistant de support peut se contenter de la question et de l'article d'aide concerné, sans tout l'historique du client.
• Peut-on les retirer ou les masquer avant qu'elles sortent ? Pseudonymiser les noms et les identifiants avant l'appel au modèle coûte peu au départ et cher à ajouter plus tard.

Une première version qui envoie moins de données se valide en général plus vite. Cela seul peut épargner des semaines d'allers-retours avec le juridique.

RGPD et fournisseurs de modèles : lisez les conditions, pas la page d'accueil

Quand vous appelez un modèle par API, le fournisseur devient sous-traitant de tout ce que vous lui envoyez. Au sens du RGPD, il faut donc un accord de sous-traitance (DPA), et savoir ce qu'il contient.

• Entraînement. La plupart des grands fournisseurs indiquent que les données envoyées via leurs API professionnelles ne servent pas, par défaut, à entraîner leurs modèles. Les applications grand public suivent souvent d'autres règles. Vérifiez quelle offre vos équipes utilisent vraiment.
• Conservation. Certains fournisseurs gardent les requêtes et les réponses pendant une durée limitée, pour détecter les abus. Certains proposent une conservation réduite ou nulle sur demande. Obtenez le nombre de jours, par écrit.
• Localisation. Où les requêtes sont-elles traitées, où les journaux sont-ils stockés. Plusieurs fournisseurs proposent désormais un traitement dans l'UE, parfois seulement sur certaines offres ou régions.
• Sous-traitants ultérieurs. La liste, tenue par le fournisseur, de ceux qui touchent aussi aux données. Elle change ; quelqu'un chez vous doit recevoir les notifications.
• Tout ce qui entoure le modèle. Les requêtes finissent souvent dans des outils de logs et de supervision, et les documents dans un index de recherche, sous forme d'embeddings. Chacun de ces outils est un sous-traitant de plus, avec sa localisation et sa durée de conservation. Et quand quelqu'un demande l'effacement de ses données, elles doivent aussi sortir de l'index.

Si le fournisseur est une société américaine, le transfert de données doit reposer sur une base légale : le Data Privacy Framework UE–États-Unis ou les clauses contractuelles types. Un hébergement en région UE aide, mais certains DPO regardent aussi de quelle juridiction relève le fournisseur lui-même, car certaines lois américaines peuvent atteindre les données détenues par des sociétés américaines à l'étranger. Le poids de ce point pour vos données est une question pour votre conseil juridique.

Héberger l'IA en Europe, dans votre cloud ou on-premise

Nous construisons les trois. Le bon choix dépend moins du modèle que de vos données, et de qui fera tourner le système après le lancement.

Un modèle managé, hébergé en Europe. Vous appelez un modèle commercial via une région UE. C'est le plus rapide à mettre en production, avec la meilleure qualité de modèle et le coût de départ le plus bas. La contrepartie : vous dépendez des conditions et des tarifs du fournisseur.

Votre propre cloud. Le modèle tourne dans votre compte AWS, Azure ou Google Cloud, via l'offre managée du fournisseur ou sous forme de modèle open-weight que vous déployez. Les données restent dans le périmètre que votre équipe sécurité audite déjà. Cela demande plus de mise en place, et quelqu'un pour l'exploiter.

On-premise. Un modèle open-weight sur vos propres serveurs. Rien ne sort de vos murs, ce que certains secteurs exigent. Vous payez le matériel, et les modèles les plus performants ne sont pas toujours disponibles sous cette forme.

Le choix est rarement tout ou rien. Un schéma courant : les documents sensibles passent par un modèle dans votre cloud, tout le reste par un modèle managé en Europe.

Ce que change l'AI Act, niveau de risque par niveau de risque

L'AI Act (règlement (UE) 2024/1689) ne réglemente pas l'IA en général. Il réglemente des usages, classés par niveau de risque. La plupart des projets d'entreprise se situent dans les niveaux bas, et savoir où vous êtes fixe la charge de travail.

• Risque inacceptable : interdit. Notation sociale, systèmes manipulateurs, reconnaissance des émotions au travail, entre autres. Ces interdictions s'appliquent depuis février 2025.
• Haut risque : obligations lourdes. Systèmes utilisés pour le recrutement, l'évaluation des salariés, la notation de crédit, l'accès à l'éducation ou aux services essentiels. Ils exigent gestion des risques, documentation, journalisation, contrôle humain et contrôle de la qualité des données. Ces obligations s'appliquent par étapes, et leur calendrier est en discussion au niveau européen : vérifiez les dates en vigueur avec votre conseil juridique.
• Risque limité : transparence. Un chatbot doit dire qu'il est une machine. Les images, sons ou vidéos générés qui pourraient passer pour réels doivent être signalés comme tels. Leurs dates d'entrée en application méritent aussi d'être vérifiées.
• Risque minimal : rien de spécifique. Résumer des documents internes, classer des tickets, rédiger des réponses relues par une personne. Le RGPD s'applique toujours ; l'AI Act ajoute peu.

Deux points prennent les entreprises de court. D'abord, le règlement distingue le fournisseur qui construit un système du déployeur qui l'utilise, et une entreprise qui déploie l'outil d'un tiers a elle aussi des obligations. Ensuite, le règlement attend des personnes qui utilisent des systèmes d'IA dans l'entreprise un niveau suffisant de maîtrise de l'IA, et ce que cela exige en pratique mérite d'être vérifié avec votre conseil.

Un exercice utile avant tout projet : écrivez un paragraphe sur ce que le système décide, à propos de qui, et qui le vérifie. S'il touche au recrutement, au crédit ou à l'accès de quelqu'un à un service, faites intervenir votre avocat avant la signature du cadrage.

L'inscrire dans le cadrage, pas dans une revue tardive

La conformité traitée à la fin coûte le plus cher. Un modèle remplacé parce que les conditions du fournisseur ne passent pas la revue, c'est une intégration à refaire. Un journal manquant, ce sont des décisions à reconstituer après coup.

Écrivez plutôt les réponses dans le cadrage. Votre DPO lit une page au lieu de courir après les réponses tout au long du projet.

La fiche données d'une page que votre DPO va demander

Réglées tôt, ces réponses orientent aussi la construction : masquage, journalisation et relecture humaine coûtent moins cher à prévoir qu'à ajouter après le lancement. Nous écrivons un cadrage au départ et construisons dans le respect de vos règles sur les données, avec une première version en 3 à 6 semaines.

Régler la question des données en premier

Si les données sont la première question que votre équipe posera, venez avec la personne qui la posera. Réservez un audit gratuit avec votre DPO ou votre CTO dans la pièce : une heure sur votre activité, puis un document court qui dit ce qui vaut la peine d'être construit, avec quelles données, et ce qui ne l'est pas.