Confidentialité et sécurité des données pour BrazeAI Operator

BrazeAI Operator^TM s’intègre à OpenAI pour fournir une assistance alimentée par l’intelligence artificielle. Cet article explique comment Operator gère les données, quelles informations sont partagées avec OpenAI, et comment minimiser l’exposition des données d’identification et contrôler les accès.

Comment Operator accède aux données

L’accès d’Operator aux données client est strictement événementiel et limité à la portée de l’invocation, et non persistant. Chaque message utilisateur ou événement de navigation lorsqu’Operator est ouvert déclenche une requête HTTP distincte vers OpenAI. Il n’y a pas de connexion permanente ni de flux de données persistant.

OpenAI n’a pas d’accès direct aux magasins de données Braze ni à la table utilisateur complète. Le LLM reçoit uniquement le payload spécifique associé à la requête active.

Quelles données sont incluses dans chaque requête

Chaque payload de requête envoyé à OpenAI peut inclure les éléments suivants :

• Métadonnées système : les prompts système rédigés par Braze et les schémas d’outils (définitions des outils que le LLM peut invoquer).
• Message de l’utilisateur du tableau de bord : le texte saisi par l’utilisateur du tableau de bord.
• Résultats des outils : les résultats de recherche contenant des noms, des ID et des données associées.
• Contenu de la page capturé : le contenu de la page active du tableau de bord, tronqué à environ 4 000 caractères.
• Chaînes de contexte de la page : les chaînes contextuelles de la page active du tableau de bord.

Sous-traitants ultérieurs de données

Fournisseurs de modèles en tant que sous-traitants ultérieurs ou fournisseurs tiers

Lorsque vous utilisez une intégration avec un fournisseur de LLM fournie par Braze dans le cadre des services Braze (« LLM fourni par Braze »), les fournisseurs de ce LLM fourni par Braze agissent en tant que sous-traitants ultérieurs de Braze, sous réserve des conditions de l’accord de traitement des données (DPA) conclu entre vous et Braze. BrazeAI Operator^TM s’intègre à OpenAI.

Comment les données sont utilisées avec OpenAI

Pour générer des résultats d’IA via les fonctionnalités de BrazeAI qui exploitent OpenAI (les « résultats »), Braze enverra certaines informations (les « entrées ») à OpenAI. Les entrées comprennent vos prompts, le contenu affiché dans le tableau de bord et les données de l’espace de travail pertinentes pour vos requêtes. Conformément aux engagements de la plateforme API d’OpenAI, les données envoyées à l’API d’OpenAI via Braze ne sont pas utilisées pour entraîner ou améliorer les modèles d’OpenAI. Entre vous et Braze, les résultats constituent votre propriété intellectuelle. Braze ne revendiquera aucun droit d’auteur sur ces résultats. Braze ne fournit aucune garantie de quelque nature que ce soit concernant tout contenu généré par l’IA, y compris les résultats.

Conformité HIPAA et conservation des données

Conformité HIPAA

Si vous utilisez le cluster US-02 de Braze, Operator est couvert par l’accord de partenariat commercial (BAA) de Braze, et les informations de santé protégées (PHI) peuvent être soumises à la fonctionnalité conformément aux exigences HIPAA. Ne soumettez pas de PHI soumises à HIPAA lorsque vous utilisez Operator dans d’autres clusters Braze.

Masquage des données d’identification

Il n’y a pas de couche automatisée de masquage des données d’identification dans le pipeline de requêtes d’Operator. Les données sont envoyées entièrement brutes et ne sont pas anonymisées avant leur transmission à OpenAI. L’accès est limité à la page active du tableau de bord ou à la saisie de l’utilisateur du tableau de bord, mais aucun filtrage de contenu n’est appliqué avant la transmission.

Conservation des données par OpenAI

La durée de conservation des données envoyées via Operator par OpenAI dépend de votre cluster :

Entraînement des modèles

Les données envoyées à l’API d’OpenAI via Braze ne sont pas utilisées pour entraîner ou améliorer les modèles OpenAI. Cela est régi par des accords contractuels entre Braze et OpenAI ainsi que par les engagements de la plateforme API d’OpenAI. OpenAI agit en tant que sous-traitant de Braze, et toutes les données personnelles sont soumises au DPA entre Braze et ses clients.

Routage des données dans l’UE

Le routage des données dans l’UE n’est pas actuellement implémenté pour Operator, et il n’y a pas de plans actuels pour l’implémenter.

Minimiser l’exposition des données d’identification

Vous pouvez prendre plusieurs mesures pour limiter l’exposition des données d’identification lorsque vous utilisez Operator :

• Désactivez le paramètre Afficher les données d’identification pour tous les utilisateurs qui utilisent Operator. Si un utilisateur ne peut pas voir les données d’identification, Operator ne peut pas y accéder non plus.
• N’ouvrez pas Operator sur une page de profil utilisateur. Le contenu de la page est récupéré et inclus dans chaque requête envoyée à OpenAI.
• Lors des tests, utilisez un profil utilisateur personnalisé plutôt que d’en sélectionner un existant. Il s’agit du comportement par défaut d’Operator.
• Ne saisissez pas et ne collez pas de données d’identification directement dans le prompt d’Operator. Operator ne bloque pas les données d’identification incluses dans les prompts utilisateur. Si un utilisateur saisit manuellement des données d’identification dans une requête, ce contenu est envoyé au modèle de langage sous-jacent.
• Désactivez l’approbation automatique des actions pour garder le contrôle sur ce à quoi Operator peut accéder et exécuter.
• Ne demandez pas à Operator d’afficher les valeurs de prévisualisation des attributs lors de la création d’un Segment ou de l’écriture de Liquid.

Gouvernance et contrôle d’accès

Restreindre l’accès à Operator

L’accès à Operator est géré au niveau de l’espace de travail via les autorisations granulaires des utilisateurs. Les administrateurs peuvent accorder ou révoquer l’autorisation « Use BrazeAI Operator » pour chaque utilisateur, garantissant que seul le personnel autorisé peut interagir avec l’outil. Sans ces autorisations spécifiques, l’interface Operator est entièrement masquée et les endpoints backend restent sécurisés.

Modèle à validation humaine

Par défaut, Operator exige une approbation explicite avant d’effectuer toute modification. Les modifications proposées sont présentées sous forme de fiches d’action pour examen. Si un utilisateur rejette une proposition, aucune modification n’est appliquée. Si un utilisateur accepte une proposition, le tableau de bord est mis à jour. La plupart des modifications restent en attente jusqu’à ce que l’utilisateur les enregistre ou les lance manuellement, mais accepter une action d’enregistrement, comme enregistrer un brouillon de Campaign, s’applique immédiatement.

Les utilisateurs peuvent activer Auto-approve actions dans le panneau de chat d’Operator, ce qui entraîne l’exécution immédiate des actions suggérées sans examen manuel. Quelques actions spécifiques nécessitent toujours une confirmation supplémentaire, même lorsque l’approbation automatique est activée :

• Lancer une Campaign. Même avec l’approbation automatique activée, Operator ne la rendra pas active sans la confirmation d’une personne.
• Enregistrer, archiver ou désarchiver un élément, ou modifier un paramètre au niveau de l’espace de travail. Operator peut effectuer la modification, mais il marque toujours une pause pour obtenir l’approbation.
• Générer une image, ou exécuter un rapport, une requête ou une synchronisation de données. Ces opérations peuvent engendrer un coût basé sur l’utilisation, c’est pourquoi Operator marque toujours une pause pour obtenir l’approbation.

Pour les actions qu’Operator ne peut pas du tout effectuer, quel que soit le mode d’approbation, consultez les limites d’Operator.

Héritage des autorisations utilisateur

Operator hérite intégralement du profil d’autorisations de l’utilisateur connecté. Il ne peut ni consulter des données ni exécuter des actions, comme des modifications de Campaign, que l’utilisateur n’est pas déjà autorisé à effectuer de manière autonome.

Autorisation de consultation des données d’identification

Operator n’a pas besoin de l’autorisation « View PII » pour fonctionner, et c’est intentionnel. Operator n’a pas d’accès direct à votre base de données et n’interroge pas votre base de données de manière indépendante. Il effectue des requêtes vers les mêmes endpoints backend que le reste du tableau de bord, en utilisant les identifiants de session de l’utilisateur authentifié. Cela signifie qu’Operator est entièrement limité par les autorisations existantes de l’utilisateur et ne peut accéder à rien que l’utilisateur ne puisse déjà voir.

Les données d’identification ne peuvent parvenir à Operator que de deux manières :

• L’utilisateur saisit des données d’identification directement dans un prompt.
• L’utilisateur consulte déjà des données d’identification dans le tableau de bord lorsqu’il utilise Operator.

Si un utilisateur ne dispose pas de l’autorisation « View PII », Operator ne peut pas lui présenter de données d’identification. Gardez à l’esprit qu’Operator ne filtre pas le contenu saisi directement dans les prompts — les données d’identification entrées manuellement sont envoyées au modèle de langage sous-jacent. Pour réduire ce risque, consultez Minimiser l’exposition des données d’identification.

Auditer l’utilisation de l’équipe

Téléchargez le rapport d’événements de sécurité de Braze pour surveiller l’utilisation par l’équipe. L’événement « Requested BrazeAI Operator Response » fournit une piste d’audit complète, vous permettant de consulter les entrées exactes fournies à Operator.