Comment déployer des contrôles d'IA dans le navigateur chez de nombreux clients ?

La situation

Vous avez vendu un service de gouvernance de l'IA à douze clients. Quatre utilisent Microsoft 365 avec Intune. Trois sont sur Google Workspace. Deux ont encore un domaine Active Directory sur place, dont un avec quelques Mac dans l'équipe de design. Les autres sont de petits bureaux où la moitié du personnel utilise Firefox parce qu'il l'a toujours fait. Chacun d'eux a besoin du même contrôle dans le navigateur, configuré selon ses propres politiques et impossible à désactiver pour un employé pressé.

Le faire à la main ne survit pas au premier mois. Les utilisateurs ignorent l'invitation à installer, les nouveaux employés commencent sans le contrôle, et quelqu'un le désactive la première fois qu'il l'interrompt. Le contrôle doit arriver par les mêmes outils de gestion des navigateurs que vous utilisez déjà pour tout le reste, avec une configuration distincte et documentée pour chaque client. Si vous concevez encore l'offre elle-même, consultez ajouter un service de gouvernance de l'IA à l'offre d'un MSSP.

Ce que disent réellement les règles

Ici, les règles sont les politiques d'entreprise des éditeurs de navigateurs. Les trois principaux navigateurs documentent une façon d'installer une extension sans intervention et d'empêcher les utilisateurs de la retirer.

• Google Chrome. La politique ExtensionSettings régit la gestion des extensions et a préséance sur l'ancienne politique ExtensionInstallForcelist. Avec installation_mode réglé à force_installed, l'extension s'installe sans intervention de l'utilisateur, qui ne peut ni la désactiver ni la retirer. Elle peut être définie par stratégie de groupe Windows, et les navigateurs inscrits à Chrome Enterprise Core peuvent recevoir leurs politiques de la console d'administration Google, avec des jetons d'inscription qui placent un navigateur directement dans l'unité organisationnelle choisie.
• Microsoft Edge. La politique ExtensionInstallForcelist installe les extensions listées sans intervention, et les utilisateurs ne peuvent ni les désinstaller ni les désactiver. Edge prend aussi en charge la même approche ExtensionSettings, avec force_installed et une URL de mise à jour qui pointe vers le site des modules complémentaires Microsoft Edge ou le Chrome Web Store. Les deux peuvent être définies par stratégie de groupe ou, sous Windows, au moyen d'un profil du catalogue de paramètres Intune attribué à des groupes Microsoft Entra.
• Mozilla Firefox. La politique ExtensionSettings de Firefox comporte un mode force_installed qui installe l'extension et empêche l'utilisateur de la retirer. Elle peut être distribuée au moyen d'un fichier policies.json, d'une stratégie de groupe Windows ou de profils de configuration macOS.

Trois détails comptent pour la planification. D'abord, les politiques d'installation forcée de Chrome et d'Edge ne s'appliquent pas aux fenêtres de navigation privée ni InPrivate, que les deux navigateurs peuvent désactiver par politique. Firefox permet à un administrateur d'autoriser une extension précise dans les fenêtres privées grâce au paramètre private_browsing d'ExtensionSettings (Firefox 136 et versions ultérieures). Ensuite, sur les appareils Windows qui ne sont pas joints à un domaine (ou, pour Chrome, inscrits à Chrome Enterprise Core), Chrome et Edge limitent l'installation forcée aux extensions offertes dans leur propre boutique. Enfin, Chrome précise que, sur certains systèmes d'exploitation, sa protection contre le retrait est offerte au mieux; l'état doit donc être vérifié, pas présumé.

Pourquoi les politiques et les interdictions ne suffisent pas

Une règle écrite qui dit « utilisez seulement le navigateur géré » n'est pas un moyen de l'appliquer. Un blocage réseau des sites d'IA non plus : il s'arrête au pare-feu du bureau, pas à l'ordinateur portable branché sur un réseau à la maison.

L'installation manuelle échoue à grande échelle pour les raisons décrites plus haut, et le mode plus souple normal_installed, qui installe automatiquement l'extension mais permet à l'utilisateur de la désactiver, invite exactement le comportement que vous cherchez à prévenir. Le contrôle doit agir avant la soumission du contenu, parce qu'une fois dans un outil d'IA public, ce contenu ne peut plus être rappelé. Un contrôle qu'un utilisateur peut désactiver au moment où la pression monte offre peu d'assurance.

Enfin, soyez honnête sur la portée. Les politiques de navigateur atteignent les navigateurs gérés. Un téléphone personnel, un ordinateur personnel ou un navigateur non pris en charge sur un poste géré échappe à cette portée. Les clients méritent de l'entendre de vous avant de l'entendre d'un auditeur. Pour l'aspect des comptes personnels, consultez les stagiaires et les comptes d'IA personnels.

À quoi ressemble un contrôle pratique

1. Bâtir un modèle par client. Pour chaque client, consignez les navigateurs utilisés, l'outil de gestion qui les atteint, les paramètres d'installation de l'extension pour chaque navigateur et les politiques de détection du client. Conservez le modèle dans votre système de documentation et la configuration active dans l'environnement du client.
2. Séparer les environnements. Configurez chaque client dans son propre locataire Intune, sa console d'administration Google ou son domaine, au moyen d'un accès d'administrateur délégué. Ne placez jamais les appareils de deux clients dans une même portée de politique, et nommez les politiques avec le nom du client et un numéro de version pour que la piste d'audit soit lisible.
3. Déployer par vagues. Commencez par le personnel des TI et une équipe volontaire, puis un service, puis tout le monde. Attribuez les vagues au moyen de groupes Entra ou d'unités organisationnelles, pour que chaque étape soit un changement de groupe et non une nouvelle politique. À chaque étape, confirmez l'état des politiques sur un échantillon d'appareils, par exemple à la page chrome://policy.
4. Fermer les portes dérobées. Décidez pour chaque client s'il faut désactiver la navigation privée, bloquer les navigateurs que l'extension ne prend pas en charge, et exiger un appareil ou un navigateur géré pour accéder aux applications de travail.
5. Documenter les angles morts. Consignez ce qui est hors de portée, comme les appareils personnels et les navigateurs non pris en charge, et faites-le reconnaître par le client dans l'entente de service et dans sa politique d'IA.
6. Informer le personnel. Annoncez le contrôle avant son arrivée, y compris ce qu'il enregistre et ce qu'il n'enregistre pas. Les clients ontariens de 25 employés ou plus devraient vérifier auprès de leurs conseillers juridiques s'il doit figurer dans leur politique écrite sur la surveillance électronique.
7. Vérifier chaque mois. Comparez le nombre de navigateurs gérés au nombre d'appareils qui transmettent des événements, et expliquez l'écart. La couverture a sa place dans le rapport mensuel au client.

Sanitized Ai se déploie comme extension de navigateur au moyen des mêmes outils de gestion des navigateurs : Chrome, Edge et Firefox, installée par les politiques décrites ci-dessus, sans modification du réseau. Une fois installée, elle détecte les données sensibles dans les requêtes et les téléversements de fichiers vers les outils d'IA et les caviarde ou les bloque avant la soumission, avec une explication en langage clair pour la personne sur ce qui a été signalé et pourquoi. Les administrateurs voient les métadonnées des événements signalés (quel outil, quel type de données, quelle politique, à quel moment) et jamais le contenu des requêtes. Au moment de bâtir vos modèles par client, confirmez les détails d'installation à jour pour chaque navigateur avec l'équipe de Sanitized Ai au moyen du formulaire d'accueil.