Votre DLP ne voit pas la zone de prompt

La plupart des équipes de sécurité ont passé une décennie à apprendre à leurs outils à surveiller les sorties. Passerelles de messagerie, scanners de stockage cloud, DLP sur les terminaux, contrôles USB. L'hypothèse sous-jacente à tout cela est que les données sensibles quittent l'entreprise par un canal que vous pouvez inspecter.

Puis un employé ouvre un nouvel onglet, colle le contrat d'un client dans un chatbot et lui demande d'« en résumer les principaux risques ». Aucun fichier n'a été déplacé. Aucun e-mail n'a été envoyé. Aucun téléchargement n'a été signalé. La chose la plus révélatrice que possède votre entreprise vient de sortir par une zone de texte que vos contrôles n'ont jamais été conçus pour lire.

C'est le problème silencieux de l'adoption de l'IA en ce moment. Le risque n'est pas que les gens utilisent l'IA. C'est que l'endroit où le risque se produit réellement, le prompt, se trouve dans un angle mort entre vos outils existants.

Pourquoi les contrôles habituels passent à côté

La DLP traditionnelle fonctionne sur des modèles qu'elle peut intercepter : une pièce jointe, un point de sortie défini, une destination connue. Le prompting avec l'IA brise ces trois hypothèses à la fois.

Les données sont souvent collées, et non jointes, de sorte que les règles basées sur les fichiers ne se déclenchent jamais. La destination est un domaine SaaS approuvé que vous avez probablement déjà mis sur liste blanche, de sorte que les règles réseau la laissent passer. Et le contenu sensible est fréquemment reformaté par l'employé en cours de route, quelques noms changés, un tableau aplati en texte, ce qui déjoue les signatures à correspondance exacte sur lesquelles s'appuie la DLP.

Le résultat est une catégorie d'exposition qui ressemble à du trafic de navigation normal. Vous pouvez disposer d'une pile DLP entièrement déployée et n'avoir aucune trace du fait que quelqu'un a introduit l'équivalent d'un trimestre de résultats financiers non publiés dans un modèle pour « rendre la diapositive du conseil d'administration plus claire ».

Une version concrète de la façon dont cela tourne mal : un analyste financier prépare une prévision, se heurte à un problème de mise en forme et colle le tableur brut dans un outil d'IA pour le nettoyer. Les données incluent des chiffres de revenus non annoncés. L'outil figure sur la liste approuvée. L'analyste est productif et serviable. Chaque décision individuelle semble raisonnable, et rien dans votre dispositif n'enregistre que des informations importantes et non publiques viennent de quitter votre contrôle. Vous ne le trouverez dans aucun journal, car il n'existe aucun journal conçu pour le détecter.

Une gouvernance écrite pour les fichiers, des comportements qui se produisent dans les prompts

Voici la partie qui devrait le plus préoccuper les responsables des risques. La plupart des dispositifs de gouvernance de l'IA d'aujourd'hui sont rédigés à la mauvaise altitude. Les politiques disent des choses comme « ne partagez pas de données confidentielles avec des outils d'IA tiers ». C'est une déclaration d'intention. Cela ne change rien au moment où un employé fatigué est à trois étapes de terminer une tâche et où le chemin le plus rapide passe par une zone de prompt.

L'écart entre la politique et le comportement n'est pas un problème de formation que vous pouvez combler avec un formulaire de consentement supplémentaire. C'est un problème de visibilité. Vous demandez aux gens de s'auto-discipliner sur une règle au moment précis où leur attention est sur le travail, pas sur le risque, et vous n'avez aucun instrument à ce moment-là pour rattraper les ratés.

C'est aussi pourquoi la surveillance a posteriori déçoit. Au moment où un prompt atteint les serveurs d'un fournisseur, l'exposition a déjà eu lieu. L'examiner plus tard vous dit ce qui s'est passé ; cela n'empêche rien. Pour les données réglementées, « nous l'avons détecté après coup » et « elles ont quitté l'entreprise » sont une seule et même phrase.

Où le contrôle doit vraiment se situer

Si le risque réside dans le prompt, c'est là que le contrôle doit aussi se situer. Localement, avant que le texte ne quitte l'appareil, dans la demi-seconde entre le collage et l'envoi. C'est un modèle différent de la surveillance des sorties. Cela signifie inspecter ce qui est sur le point de sortir au point de prompting, intercepter le fragment sensible et donner à l'employé une chance de s'arrêter avant que les données ne soient parties, plutôt qu'un rapport après coup.

Cela évite aussi que l'inspection elle-même ne devienne une seconde exposition. Acheminer chaque prompt vers un autre service cloud pour le vérifier ne fait que déplacer la fuite d'un cran en aval. Effectuer la détection sur l'appareil, en privilégiant la confidentialité, avant toute transmission, est la seule version qui ne recrée pas le problème qu'elle résout. C'est le principe sur lequel repose Sanitized AI, pour ce que ça vaut.

Le changement qui mérite d'être opéré ce trimestre n'est pas une ligne de politique supplémentaire ni un autre module de formation. C'est un audit honnête d'une seule question : au moment où un employé colle quelque chose de sensible dans un outil d'IA, qu'est-ce qui, dans votre environnement, le remarquerait réellement ? Si la réponse est rien, ce n'est pas un problème d'IA. C'est un angle mort que vous avez depuis que la zone de prompt est devenue l'application la plus utilisée de votre entreprise, et la première étape consiste simplement à admettre que vos outils existants n'ont jamais regardé là.