De la requête au modèle : des contrôles de sécurité à chaque étape.

Détection et minimisation

La passerelle analyse chaque requête avant son envoi pour repérer les catégories de données définies dans votre politique : noms, adresses e-mail, téléphones, identifiants financiers, secrets techniques ou données métiers.

Les catégories prises en charge, les langues couvertes et les taux d’erreur mesurés seront publiés dans la documentation au fur et à mesure qu’elles sont implémentées et testées. Aucun détecteur n’est parfait : des faux positifs et des faux négatifs restent possibles.

Transformation contextuelle

Selon la configuration, une donnée détectée peut être masquée, supprimée, généralisée ou remplacée par une entité fictive cohérente, afin que le modèle conserve le sens de la requête.

La documentation précise pour chaque mode si la transformation est réversible, où est conservée la table de correspondance, qui peut y accéder et quand elle est supprimée. Une substitution réversible relève de la pseudonymisation, pas de l’anonymisation.

Routage selon la sensibilité

Une politique peut autoriser un fournisseur externe approuvé pour certains usages, imposer un modèle hébergé dans une région déterminée, ou bloquer la requête si aucune destination conforme n’est disponible.

Le routage effectif dépend des fournisseurs intégrés, de vos contrats, de la configuration et du mode de déploiement retenu.

Journal d’audit

Chaque décision est enregistrée : date, identifiant technique de requête, politique appliquée, catégories détectées, action, destination, résultat et erreurs.

Le texte brut des prompts n’est pas enregistré par défaut. La durée de conservation, les droits d’accès, l’export et la séparation des journaux sont documentés. Les mécanismes d’intégrité ne seront décrits qu’une fois implémentés et testés.

Modes de déploiement

Service SaaS, proxy dans votre réseau, conteneur exécuté par vos équipes ou déploiement privé : chaque mode est présenté séparément, avec ses prérequis, les données qui transitent et le partage des responsabilités.

Seuls les modes réellement disponibles sont proposés ; les autres sont étudiés sur demande.

Limites et responsabilités

• La détection n’est pas parfaite ; les politiques doivent être testées sur les usages réels.
• Le remplacement de données peut dégrader la qualité ou la pertinence de la réponse du modèle.
• Le contenu indirectement identifiant et le contexte peuvent permettre une réidentification.
• Anonym’IA ne remplace pas l’analyse de risques, les règles internes, les contrats fournisseurs ou l’avis du DPO et du conseil juridique.
• La protection dépend aussi de la configuration, des accès, des clés, des fournisseurs et du comportement des utilisateurs.

Voir l’architecture et les frontières de confiance dans la documentation