Cartographier les flux avant de connecter les outils

Listez les sources consultées, les traitements effectués et les résultats produits. Une information peut passer du CRM à un outil de génération, puis à un journal ou à une messagerie. Chaque étape doit être examinée, y compris les traces techniques qui peuvent contenir des extraits de données.

Distinguez les informations publiques, internes, confidentielles et les données personnelles selon votre classification. Cette distinction aide à définir les usages autorisés. Une donnée accessible à certains salariés ne doit pas devenir accessible à tous parce qu’elle entre dans une base consultée par l’agent.

Limiter les accès et les opérations

Attribuez uniquement les droits nécessaires au cas d’usage. La lecture, l’écriture, l’envoi et l’export doivent être distingués. Un connecteur installé ne doit pas donner automatiquement accès à toutes ses fonctions.

Testez les droits avec plusieurs profils. Un utilisateur ne doit pas obtenir, par l’intermédiaire de l’agent, une information qu’il ne pourrait pas consulter dans le système d’origine. Les contrôles doivent s’appliquer au moment de l’accès, pas seulement à l’affichage initial de l’outil.

Les identifiants et secrets techniques doivent être gérés dans des mécanismes adaptés, pas placés dans les consignes ou les documents consultables. Prévoyez leur rotation et leur révocation. Un départ de collaborateur ou un changement de prestataire doit conduire à revoir les accès concernés.

Réduire les données utilisées au nécessaire

Avant de transmettre un dossier complet, demandez quels champs sont réellement utiles. Pour préparer un résumé commercial, des coordonnées personnelles ou des pièces sans rapport avec le besoin peuvent être inutiles. Retirer ces éléments réduit l’exposition et facilite la vérification.

La CNIL rappelle que la sécurité des traitements doit être adaptée aux risques et combine les mesures classiques du système d’information avec l’examen des risques propres à l’IA. Cette analyse doit accompagner la conception, pas seulement intervenir après le déploiement.

Les tests peuvent souvent utiliser des données fictives ou préparées pour l’essai. Si des données réelles sont nécessaires, définissez un périmètre autorisé et des protections adaptées. Copier toute la production dans un environnement d’expérimentation n’est pas une étape neutre.

Contrôler les fournisseurs et les conditions d’usage

Vérifiez les conditions applicables à la solution effectivement utilisée : traitement des entrées, conservation, usages éventuels pour l’amélioration des modèles, sous-traitants et possibilités de suppression. Les paramètres peuvent varier selon l’offre et le contrat ; ne les déduisez pas d’une présentation commerciale générale.

Demandez des réponses documentées sur les lieux de traitement, les accès administrateurs et les mécanismes de sécurité. Lorsque des données personnelles sont concernées, faites examiner les obligations contractuelles et les éventuels transferts par les personnes compétentes.

Un hébergement local ne règle pas automatiquement tous les problèmes. Les accès, les mises à jour, les sauvegardes et les connecteurs restent à sécuriser. À l’inverse, l’usage d’une solution externe doit être évalué sur ses garanties concrètes et votre besoin, sans raccourci.

Protéger la frontière entre contenu et instruction

Les documents lus par l’agent peuvent contenir des consignes malveillantes ou simplement hors sujet. Une instruction trouvée dans une page ou un email ne doit pas modifier les règles de sécurité. Le système doit traiter ces contenus comme des données à analyser.

Limitez les destinations d’envoi et les actions possibles. Pour une opération sensible, vérifiez le destinataire, le contenu et l’autorisation au niveau de l’application. Ne comptez pas uniquement sur une phrase demandant au modèle de rester prudent.

Le guide de l’ANSSI sur la sécurité des systèmes d’IA générative traite la sécurisation de l’architecture, depuis la conception jusqu’à l’usage en production. Il constitue un support de travail pour les responsables techniques, à compléter par les exigences propres aux données et au métier.

Exemple : préparer un rendez-vous sans ouvrir toute la base

Dans cet exemple fictif, un agent doit préparer les rendez-vous d’une équipe commerciale. Le premier projet prévoit un accès global au CRM et à un répertoire de contrats. Une revue montre que seuls le compte concerné, les échanges autorisés et quelques documents produits sont nécessaires.

Le périmètre est réduit. L’agent ne peut pas exporter la base ni consulter les dossiers d’autres équipes. Les sorties sont conservées dans le dossier autorisé, avec une durée et des accès définis. Les erreurs ou refus d’accès sont journalisés sans recopier inutilement le contenu complet.

Le service reste utile, mais la conséquence d’un comportement inattendu est limitée. Cette réduction doit être testée : il faut vérifier qu’une demande portant sur un autre compte est effectivement refusée, pas seulement interdite dans une consigne.

Préparer la détection et la réponse aux incidents

Conservez les traces nécessaires pour comprendre les accès et les actions, avec une protection adaptée. Les journaux ne doivent pas devenir une copie non contrôlée des données sensibles. Définissez qui peut les consulter et dans quel but.

Prévoyez une suspension du dispositif, la révocation des accès et une procédure de reprise. Les équipes doivent savoir à qui signaler une sortie anormale ou une transmission inattendue. Un incident ne doit pas dépendre de la disponibilité de la personne qui a construit le prototype.

Testez régulièrement les scénarios importants : accès interdit, source indisponible, tentative d’envoi hors périmètre et changement de droits. Les évolutions du système justifient une réévaluation. La sécurité est une condition de fonctionnement, pas une validation définitive obtenue au lancement.

Les outils commerciaux et la gestion des données doivent être pensés ensemble. Un agent performant n’est utile que si son accès à l’information reste maîtrisé.

Vérifiez enfin la suppression de bout en bout. Retirer un document de la source ne garantit pas qu’il ait disparu des copies, des index ou des journaux associés. Le processus doit identifier ces emplacements et prévoir les opérations nécessaires selon les règles de conservation retenues. Cette vérification est particulièrement importante lors d’un changement de fournisseur ou de l’arrêt du service.