Le répondant reste maître de ce qui a été dit.

Les travailleurs qui participent à un entretien entendent ce qui se passera avant le début de la conversation. Ils consentent ou refusent avant que l'enregistrement ne commence. Tout ce qu'ils demandent à caviarder est caviardé à l'étape de caviardage. S'ils révoquent leur consentement après l'entretien, chaque fait dérivé de leur conversation est retiré de la couche d'intelligence via le mécanisme de mise en tombeau.

Cette page décrit le flux de consentement au démarrage, la liste de caviardage extensible que vous contrôlez, le chemin de révocation, et comment une révocation se propage à travers les faits dérivés.

L'agent d'entretien ouvre chaque conversation en décrivant quatre choses au répondant : ce qui sera capturé (audio et transcription structurée), comment le résultat sera enrichi (affirmations typées sur la perception de marque, les points de douleur, les opportunités), quels endpoints le résultat enrichi atteindra (votre tableau de bord, l'API partenaire de marque, le flux d'agents), et quels sont les droits du répondant (révocation, demande de caviardage, dossier de transparence).

Le répondant confirme verbalement. La confirmation est capturée dans le dossier de consentement attaché à la conversation. Si le répondant refuse, l'enregistrement ne commence pas et aucune entrée dans le lac de données n'est écrite.

Le script de consentement est publié. Votre équipe juridique peut l'examiner avant tout déploiement. Le script peut être adapté à votre juridiction (Loi 25 du Québec, RGPD, variantes de consentement éclairé HIPAA) sans modifier le flux sous-jacent.

L'étape de caviardage supprime les noms, les identifiants de personnes et les évocations de la transcription brute avant toute exécution d'appel d'enrichissement. La liste par défaut couvre les noms des répondants et les schémas d'identifiants courants. Au-delà des défauts, la liste de caviardage est la vôtre à étendre. Tout ce qui est propre à votre activité et qui ne devrait jamais apparaître dans une transcription, vous l'ajoutez à la liste.

Extensions courantes : numéros de compte client, codes de projets internes, noms du personnel interne pouvant être identifiés par leur description de rôle, noms de fournisseurs liés à un accord de confidentialité, noms de dirigeants concurrents que le répondant pourrait mentionner. La liste est modifiée dans la console opérateur. Les modifications prennent effet dès la prochaine conversation.

La liste de caviardage est versionnée. Une conversation enrichie sous la version 4 de la liste porte une référence à cette version dans ses métadonnées, de sorte qu'un audit peut établir ce qui a été caviardé au moment du traitement.

Un répondant qui révoque son consentement contacte l'opérateur (ou, dans certains déploiements, utilise un lien en libre-service inclus dans l'email post-entretien). La révocation écrit un événement de mise en tombeau contre l'identifiant de conversation dans l'index du lac de données. La mise en tombeau porte l'horodatage de révocation et la portée demandée (la conversation entière, un sujet spécifique, ou une citation spécifique).

La mise en tombeau prend effet immédiatement côté lecture. Le worker de requête vérifie l'indicateur de tombeau avant de servir des données de la conversation affectée. Les lignes d'entité de la conversation dans le magasin de faits sont marquées invalides à l'horodatage de tombeau lors du prochain rafraîchissement d'enrichissement. Les agrégats calculés avant la mise en tombeau sont recalculés lors du prochain cycle de rafraîchissement complet.

Chaque ligne de fait dans le corpus porte un identifiant de fragment de la forme transcript_id / turn_id / sentence_id pointant vers la phrase source. L'identifiant de fragment est le handle de propagation.

Lorsqu'une mise en tombeau est écrite, l'indexeur du corpus trouve chaque fait dont l'identifiant de fragment résout vers la conversation mise en tombeau et marque le fait invalid_at = tombstone_ts. Le chemin de requête bi-temporel filtre les faits dont la fenêtre de validité inclut le temps de requête, de sorte que les faits mis en tombeau cessent d'être retournés. Ils ne sont pas supprimés ; la piste d'audit préserve leur existence et leur statut de tombeau.

Pour les agrégats déjà calculés avant la mise en tombeau, le recalcul lors du prochain rafraîchissement exclut les faits mis en tombeau. L'agrégat pré-tombeau est conservé pour audit avec une référence à l'événement de tombeau qui a déclenché son remplacement.

L'événement de mise en tombeau est permanent. Chaque fait dont l'identifiant de fragment résout vers la conversation mise en tombeau porte sa référence de tombeau. Une requête telle que «montrez-moi chaque élément d'intelligence dérivé de la conversation avec le répondant X, et confirmez qu'aucun d'eux n'est actuellement servi dans le tableau de bord» est répondable à partir de la référence de tombeau et de la fenêtre de validité bi-temporelle.

Pour les régulateurs qui demandent une preuve de conformité avec une demande de droit à l'effacement, la piste d'audit est la preuve. Le répondant reçoit une confirmation qui liste chaque fait dérivé de sa conversation et l'horodatage auquel chaque fait a cessé d'être servi.

Les agrégats déjà partagés dans un rapport publié ne peuvent pas être retirés du rapport ; ce que nous pouvons faire est d'exclure la contribution du répondant du prochain agrégat et de modifier le jeu de données sous-jacent du rapport. La mise en tombeau est rétroactive sur le corpus ; elle ne peut pas réécrire un PDF qui a quitté la plateforme le trimestre dernier.

Les artefacts statistiques d'un seul répondant dans un grand corpus sont généralement en dessous du seuil de ré-identification pratique. La mise en tombeau s'applique quand même. L'opérateur du corpus peut décider de recalculer un agrégat ou de le laisser tel quel avec une note de bas de page référençant la mise en tombeau.