Passer au contenu

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

BrazeAI OperatorTM s’intègre à OpenAI pour fournir une assistance basée sur l’intelligence artificielle. Cet article explique comment Operator gère les données, quelles informations sont partagées avec OpenAI, et comment limiter 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 déclenché par des événements et limité à chaque appel : il n’est jamais persistant. Chaque message de l’utilisateur ou événement de navigation, lorsqu’Operator est ouvert, déclenche une requête HTTP distincte vers OpenAI. Il n’existe ni connexion permanente ni flux de données persistant.

OpenAI n’a pas d’accès direct aux banques de données de Braze ni à l’intégralité de la table des utilisateurs. Le LLM reçoit uniquement le payload spécifique associé à la requête en cours.

Données 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 appeler).
  • Message de l’utilisateur du tableau de bord : Le texte saisi par l’utilisateur du tableau de bord.
  • Sorties des outils : Les résultats de recherche contenant des noms, des ID et des données associées.
  • Contenu extrait de la page : 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 de caractères contextuelles issues de la page active du tableau de bord.

Sous-traitants de données

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

Lorsque vous utilisez une intégration avec un fournisseur de LLM proposée 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 de Braze, conformément aux conditions de l’avenant relatif au traitement des données (DPA) conclu entre vous et Braze. BrazeAI OperatorTM s’intègre à OpenAI.

Utilisation des données avec OpenAI

Pour générer un résultat d’IA au moyen des fonctionnalités BrazeAI qui exploitent OpenAI (« Résultat »), Braze envoie certaines informations (« Entrée ») à OpenAI. L’Entrée comprend vos invites, 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 par l’intermédiaire de Braze ne sont pas utilisées pour entraîner ou améliorer les modèles d’OpenAI. Entre vous et Braze, le Résultat constitue votre propriété intellectuelle. Braze ne revendiquera aucun droit d’auteur sur ce Résultat. Braze n’offre aucune garantie d’aucune sorte concernant le contenu généré par l’IA, y compris le Résultat.

Conformité HIPAA et conservation des données

Conformité HIPAA

Si vous utilisez le cluster US-02 de Braze, Operator est couvert par le Business Associate Agreement (BAA) de Braze, et vous pouvez soumettre des informations de santé personnelles (PHI) à cette fonctionnalité conformément aux exigences de la loi HIPAA. Ne soumettez pas de PHI soumises à la loi HIPAA lorsque vous utilisez Operator sur d’autres clusters Braze.

Masquage des données d’identification

Le pipeline de requêtes d’Operator ne comporte aucune couche de masquage automatique des données d’identification. 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 du contenu n’est appliqué avant la transmission.

Conservation des données par OpenAI

La durée pendant laquelle OpenAI conserve les données envoyées via Operator dépend de votre cluster :

Cluster Conservation
US-02 (clients HIPAA) Zero Data Retention (ZDR). OpenAI ne stocke pas les données après leur traitement.
Tous les autres clusters 30 jours pour la surveillance des abus. Il s’agit d’une durée de conservation standard dans le secteur, imposée par OpenAI.

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 d’OpenAI. Ce point est régi par les 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 conclu entre Braze et ses clients.

Acheminement des données dans l’UE

L’acheminement des données dans l’UE n’est actuellement pas mis en œuvre pour Operator, et aucune mise en œuvre n’est prévue pour le moment.

Minimiser l’exposition des données d’identification

Plusieurs mesures vous permettent de limiter l’exposition des données d’identification lorsque vous utilisez Operator :

  • Désactivez le paramètre Voir les données d’identification pour tous les utilisateurs qui se servent d’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 extrait et inclus dans chaque requête envoyée à OpenAI.
  • Lors de vos tests, utilisez un profil utilisateur personnalisé plutôt que d’en sélectionner un existant. C’est le 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 des utilisateurs. 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 qu’Operator peut consulter et exécuter.
  • Ne demandez pas à Operator d’afficher des valeurs d’aperçu pour les attributs lorsque vous créez un Segment ou rédigez du code Liquid.

Gouvernance et contrôle d’accès

Restreindre l’accès à Operator

L’accès à Operator se gère au niveau de l’espace de travail grâce aux autorisations utilisateur granulaires. Les administrateurs peuvent accorder ou révoquer l’autorisation « Use BrazeAI Operator » pour chaque utilisateur, afin que seules les personnes autorisées puissent utiliser l’outil. Sans ces autorisations, l’interface d’Operator est entièrement masquée et les endpoints backend restent sécurisés.

Modèle avec intervention humaine

Par défaut, Operator demande une approbation explicite avant d’effectuer la moindre modification. Les modifications proposées s’affichent sous forme de cartes d’action que vous pouvez examiner. Si un utilisateur rejette une proposition, aucune modification n’est effectuée. S’il l’accepte, 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. En revanche, l’acceptation d’une action d’enregistrement, comme l’enregistrement d’un brouillon de Campaign, s’applique immédiatement.

Les utilisateurs peuvent activer Approuver automatiquement les actions dans le panneau de chat d’Operator. Les actions suggérées s’exécutent alors immédiatement, sans examen manuel. Certaines actions exigent toutefois 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 l’active pas sans qu’une personne soit présente pour confirmer.
  • 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 s’interrompt toujours d’abord pour demander une approbation.
  • Générer une image, ou exécuter un rapport, une requête ou une synchronisation de données. Ces actions peuvent entraîner un coût lié à l’utilisation : Operator s’interrompt donc toujours d’abord pour demander une approbation.

Pour connaître les actions qu’Operator ne peut pas effectuer du tout, quelle que soit l’approbation, consultez Limites d’Operator.

Héritage des autorisations utilisateur

Operator hérite entièrement du profil d’autorisations de l’utilisateur connecté. Il ne peut ni consulter de données ni exécuter d’actions, comme la modification de Campaigns, que l’utilisateur n’est pas déjà autorisé à effectuer lui-même.

Autorisation « View PII »

Operator n’a pas besoin de l’autorisation « View PII » pour fonctionner, et c’est voulu. Operator n’a aucun accès direct à votre stockage de données et n’interroge pas votre base de données de manière indépendante. Il envoie plutôt ses requêtes aux mêmes endpoints backend que le reste du tableau de bord, en utilisant les identifiants de session de l’utilisateur authentifié. Operator est donc 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 façons :

  • L’utilisateur saisit directement des données d’identification 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 afficher 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 saisies manuellement sont envoyées au modèle de langage sous-jacent. Pour réduire ce risque, consultez Limiter l’exposition des données d’identification.

New Stuff!