La plupart des échanges sur la protection des données en matière de gouvernance de l’IA partent du mauvais endroit. On y demande quelles certifications détient un fournisseur, quels sous-traitants il déclare, dans quelle région se trouve son cloud. Ce sont de vraies questions. Mais pour la catégorie d’outils bien précise qui surveille vos agents IA — découvrir chaque agent, session, modèle et serveur MCP sur votre infrastructure et cartographier ce que chacun peut atteindre — une question plus fondamentale se cache en dessous : l’outil de gouvernance lui-même reçoit-il un jour vos données ?
Si la réponse est oui, vous venez de créer un nouveau sous-traitant, une nouvelle copie de données sensibles, un nouvel endroit susceptible d’être compromis, visé par une réquisition judiciaire ou contraint de renvoyer des informations à l’éditeur. Si la réponse est non — structurellement, par conception —, alors la plupart des questions RGPD en aval deviennent bien plus modestes. C’est l’argument en faveur de l’auto-hébergement d’une plateforme d’IA, et il mérite d’être posé avec précision, sans en faire trop.
La garantie de confidentialité qui compte est structurelle, pas un certificat
Un rapport SOC 2 ou un certificat ISO 27001 vous indique qu’un fournisseur dispose de processus encadrant les données qu’il détient. C’est utile, mais il s’agit d’une affirmation sur la gouvernance de l’accès à vos données. Une garantie bien plus forte consiste à ne pas détenir les données du tout. On ne peut ni divulguer, ni mal gérer, ni être contraint de communiquer ce que l’on n’a jamais reçu.
L’auto-hébergement offre précisément cela. Lorsque le control plane s’exécute au sein de vos propres hôtes, clusters ou clouds — y compris en mode entièrement air-gapped, sans aucune sortie de données —, les éléments sensibles qu’il observe ne franchissent jamais votre périmètre. Le fournisseur n’est pas un sous-traitant de vos données opérationnelles parce que le fournisseur ne les voit jamais. C’est un fait d’architecture, et non une promesse de politique interne qu’il vous faut auditer.
Pour être clair sur la situation de ce produit : Olivares AI est en phase de pré-lancement. Il n’est pas certifié SOC 2, ISO/IEC 27001, EU AI Act ni au titre d’aucun autre référentiel, et aucun audit n’est en cours. Le produit est conçu en visant les objectifs de contrôle que ces référentiels examinent — journalisation d’audit, contrôle d’accès, intégrité, chiffrement, gestion du changement —, de sorte qu’il soit prêt à être audité le moment venu. L’argument de résidence exposé ci-dessous ne dépend d’aucune certification, ce qui est précisément l’enjeu.
Des arêtes, pas des charges utiles
La décision de conception centrale porte sur ce qui est stocké. Un outil de gouvernance de l’IA doit comprendre qui peut toucher à quoi. Il n’a pas besoin du contenu des requêtes, du corps des prompts, des secrets ou des données personnelles qui transitent par ces accès.
Le graphe stocke donc des arêtes, pas des charges utiles : la relation d’accès entre un agent et une ressource, et le fait que cet accès soit en lecture (R) ou en lecture/écriture (RW). data-export-job → prod-postgres (RW) est une arête. Les lignes lues par ce job ne sont pas stockées. La carte enregistre qu’un agent a atteint un objet dans s3://billing-exports ; elle ne copie pas l’export.
| Stocké (la carte des accès) | Non stocké |
|---|---|
| Identité de l’agent (rôle / nom d’application) | Valeurs des identifiants, jetons, clés |
Ressource atteinte (prod-postgres) | Corps des requêtes, lignes de résultats |
| Type d’accès — R ou RW | Charges utiles des prompts et des réponses |
| Horodatage, résultat, niveau de confiance | Secrets, données personnelles en transit |
Les entrées susceptibles de contenir des secrets ou des données personnelles sont expurgées et passées au crible de la détection de secrets avant toute écriture : l’expurgation a donc lieu en bordure de collecte plutôt qu’en nettoyage ultérieur. Ce que vous ne stockez pas, vous ne pouvez pas le divulguer — et ce que vous ne pouvez pas divulguer n’élargit pas votre périmètre de traitement au sens du RGPD.
Comment les données restent à l’intérieur du périmètre
Trois propriétés maintiennent cette honnêteté en exploitation :
Observation en lecture d’abord. Le collecteur observe via des signaux que vous produisez déjà — journaux applicatifs et d’audit, OpenTelemetry, et eBPF comme filet de sécurité de vérité terrain au niveau du noyau. Ce n’est pas un proxy placé dans le chemin de données de l’agent : il voit donc la forme de l’accès, non son contenu, et s’il tombe en panne il ne casse jamais la production. Il n’y a aucun intermédiaire (man-in-the-middle) obligatoire qui copie votre trafic.
Aucune télémétrie renvoyée à l’éditeur. Sécurisé par défaut signifie aucun renvoi d’informations (phone-home). La télémétrie fournisseur est désactivée tant que vous ne l’activez pas explicitement. Rien concernant votre parc — ni les noms des agents, ni la carte des accès, ni les volumes d’utilisation — n’est renvoyé au fournisseur par défaut.
Air-gapped avec zéro sortie de données. Dans les réseaux déconnectés, réglementés ou classifiés, le control plane s’exécute entièrement en local, avec validation de la licence hors ligne. Il n’existe aucun chemin de sortie, un point c’est tout. Pour une exigence de résidence des données stipulant que les données de l’UE doivent rester sur une infrastructure de l’UE sous votre contrôle, un déploiement auto-hébergé en air-gapped est la réponse la plus littérale possible : les données ne bougent pas parce qu’il n’existe aucun endroit où elles pourraient aller.
La rétention et la purge sont configurables : vous contrôlez donc la durée de conservation, y compris celle de la carte des accès.
Correspondance avec l’article 28 du RGPD — honnêtement
L’article 28 du RGPD régit la relation entre le responsable du traitement et le sous-traitant, ainsi que ce que doit couvrir un accord de traitement des données. L’observation pertinente est que, dans un déploiement auto-hébergé, la relation habituelle « fournisseur en tant que sous-traitant » pour vos données opérationnelles se dissout en grande partie : parce que l’outil s’exécute dans votre infrastructure et ne reçoit jamais ces données, dans la plupart des déploiements vous demeurez responsable du traitement et sous-traitant de vos propres données au sein de votre propre environnement.
Cela ne rend pas pour autant l’accord de traitement inutile. Une relation commerciale gagne toujours à formaliser les responsabilités — pour la chaîne d’approvisionnement logicielle, pour les accès du support, pour tout composant managé à venir. Un accord de traitement des données au titre de l’article 28 est disponible sur demande dans le cadre d’un achat en entreprise. Ce qui change, c’est le périmètre : il n’existe aucune liste des endroits où vos données personnelles ont été envoyées, parce qu’elles n’ont jamais été envoyées. C’est une conversation bien plus courte et bien plus défendable avec un DPO ou un service achats que « faites confiance à notre liste de sous-traitants ».
C’est un argument structurel : traitez-en donc les limites avec la même honnêteté. L’auto-hébergement déplace la responsabilité de résidence et de traitement vers vous ; il ne la supprime pas. Vous devez toujours sécuriser l’hôte, contrôler la rétention et gouverner qui peut lire la carte des accès — et cette carte est elle-même sensible, raison pour laquelle chaque consultation privilégiée de celle-ci est auditée et pour laquelle les composants s’authentifient mutuellement par TLS mutuel (mutual TLS). Le produit réduit la surface fournisseur à quasiment zéro ; il n’absout pas l’exploitant.
À retenir
Si un régulateur, un DPO ou votre propre équipe de sécurité demande « où vont nos données lorsque nous adoptons cet outil de gouvernance de l’IA », la réponse la plus solide possible est « nulle part — elles ne sortent jamais, et l’outil ne les voit jamais ». Cette réponse découle de l’architecture : exécution auto-hébergée, stockage en arêtes-et-non-charges-utiles, expurgation avant écriture, aucune télémétrie renvoyée à l’éditeur, et exploitation air-gapped avec zéro sortie de données. Un certificat peut corroborer de bons processus ; il ne peut égaler la garantie de données qui n’ont jamais été reçues.
Si vous voulez la version complète et honnête de cette posture — y compris la position de conformité « pas encore certifié » et la façon dont s’inscrit un accord de traitement (art. 28 du RGPD) —, consultez /security. Si vous préférez lire le code qui étaye cette affirmation, le produit complet est auto-hébergeable sous licence AGPL-3.0 sur la page /open-source.