Il partecipante rimane padrone di cio che e stato detto.

I lavoratori che partecipano a un colloquio vengono informati di cio che accadra prima dell'inizio della conversazione. Acconsentono o rifiutano prima che la registrazione inizi. Qualsiasi cosa chiedano di oscurare viene oscurata nella fase di oscuramento. Se revocano il consenso dopo il colloquio, ogni fatto derivato dalla loro conversazione viene ritirato dall'Intelligence Layer tramite il meccanismo di tombstone.

Questa pagina descrive il flusso di consenso all'avvio, l'elenco di oscuramento estensibile che Lei controlla, il percorso di revoca e come una revoca si propaga attraverso i fatti derivati.

L'agente di colloquio apre ogni conversazione descrivendo quattro cose al partecipante: cosa verra acquisito (audio e una trascrizione strutturata), come l'output verra arricchito (affermazioni tipizzate sulla percezione del marchio, punti critici, opportunita), quali endpoint raggiungeranno l'output arricchito (il Suo pannello di controllo, l'API brand partner, il feed degli agenti) e quali sono i diritti del partecipante (revoca, richiesta di oscuramento, record di trasparenza).

Il partecipante conferma verbalmente. La conferma viene acquisita nel record di consenso allegato alla conversazione. Se il partecipante rifiuta, la registrazione non inizia e nessuna voce nel data lake viene scritta.

Lo script di consenso e pubblicato. Il Suo team legale puo esaminarlo prima di qualsiasi distribuzione. Lo script puo essere adattato alla Sua giurisdizione (Loi 25 Quebec, GDPR, varianti di consenso informato HIPAA) senza modificare il flusso sottostante.

La fase di oscuramento rimuove nomi, identificatori di persone ed evocazioni dalla trascrizione grezza prima che venga eseguita qualsiasi chiamata di arricchimento. L'elenco predefinito copre i nomi dei partecipanti e i pattern di identificatori comuni. Oltre ai predefiniti, l'elenco di oscuramento e Suo da estendere. Qualsiasi elemento specifico della Sua attivita che non dovrebbe mai comparire in una trascrizione, lo aggiunge all'elenco.

Estensioni comuni: numeri di account cliente, codici di progetto interni, nomi del personale interno identificabile dalla descrizione del ruolo, nomi di fornitori vincolati da un accordo di riservatezza, nomi di dirigenti concorrenti che il partecipante potrebbe menzionare. L'elenco viene modificato nella console operatore. Le modifiche hanno effetto dalla conversazione successiva.

L'elenco di oscuramento e con versioning. Una conversazione arricchita sotto la versione 4 dell'elenco porta un riferimento a tale versione nei suoi metadati, in modo che un audit possa stabilire cosa e stato oscurato al momento dell'elaborazione.

Un partecipante che revoca il consenso contatta l'operatore (o, in alcune distribuzioni, utilizza un link self-service incluso nell'email post-colloquio). La revoca scrive un evento di tombstone rispetto all'identificatore di conversazione nell'indice del data lake. Il tombstone porta il timestamp di revoca e lo scope richiesto (l'intera conversazione, un argomento specifico o una citazione specifica).

Il tombstone ha effetto immediato lato lettura. Il worker di interrogazione verifica il flag di tombstone prima di servire qualsiasi dato dalla conversazione interessata. Le righe di entita della conversazione nel repository di fatti vengono contrassegnate come non valide al timestamp del tombstone al prossimo aggiornamento di arricchimento. Gli aggregati calcolati prima del tombstone vengono ricalcolati al prossimo ciclo di aggiornamento completo.

Ogni riga di fatto nel corpus porta un identificatore di chunk nella forma transcript_id / turn_id / sentence_id che punta alla frase sorgente. L'identificatore di chunk e l'handle di propagazione.

Quando viene scritto un tombstone, l'indicizzatore del corpus trova ogni fatto il cui identificatore di chunk si risolve nella conversazione tombstoned e contrassegna il fatto invalid_at = tombstone_ts. Il percorso di interrogazione bi-temporale filtra i fatti la cui finestra di validita include il momento della query, in modo che i fatti tombstoned cessino di essere restituiti. Non vengono eliminati; la pista di audit ne preserva l'esistenza e lo stato di tombstone.

Per gli aggregati gia calcolati prima del tombstone, il ricalcolo al prossimo aggiornamento esclude i fatti tombstoned. L'aggregato pre-tombstone viene conservato per audit con un riferimento all'evento di tombstone che ha innescato la sua sostituzione.

L'evento di tombstone e permanente. Ogni fatto il cui identificatore di chunk si risolve nella conversazione tombstoned porta il suo riferimento di tombstone. Una query come "mostratemi ogni pezzo di intelligence derivato dalla conversazione con il partecipante X, e confermate che nessuno di essi viene attualmente servito nel pannello di controllo" e rispondibile dal riferimento di tombstone e dalla finestra di validita bi-temporale.

Per gli organi di regolamentazione che richiedono prova di conformita con una richiesta di diritto alla cancellazione, la pista di audit e la prova. Il partecipante riceve una conferma che elenca ogni fatto derivato dalla sua conversazione e il timestamp in cui ogni fatto ha cessato di essere servito.

Gli aggregati gia condivisi in un report pubblicato non possono essere ritirati dal report; cio che possiamo fare e escludere il contributo del partecipante dal prossimo aggregato e modificare il dataset sottostante del report. Il tombstone e retroattivo sul corpus; non puo riscrivere un PDF che ha lasciato la piattaforma nel trimestre scorso.

Gli artefatti statistici di un singolo partecipante in un corpus ampio sono tipicamente al di sotto della soglia di re-identificazione pratica. Il tombstone si applica comunque. L'operatore del corpus puo decidere se ricalcolare un aggregato o lasciarlo invariato con una nota a pie di pagina che fa riferimento al tombstone.