O respondente permanece no controle do que foi dito.

Os trabalhadores que participam de uma entrevista ouvem o que acontecerá antes do início da conversa. Eles consentem ou recusam antes do início da gravação. Qualquer coisa que peçam para redigir é redigida na etapa de redação. Se revogarem o consentimento após a entrevista, cada fato derivado de sua conversa é retirado da camada de inteligência por meio do mecanismo de tombamento.

Esta página descreve o fluxo de consentimento no início, a lista de redação extensível que você controla, o caminho de revogação e como uma revogação se propaga pelos fatos derivados.

O agente de entrevista abre cada conversa descrevendo quatro coisas ao respondente: o que será capturado (áudio mais uma transcrição estruturada), como a saída será enriquecida (afirmações tipadas sobre percepção de marca, pontos de dor, oportunidades), quais endpoints a saída enriquecida alcançará (seu painel, a API de parceiro de marca, o feed de agentes) e quais são os direitos do respondente (revogação, solicitação de redação, registro de transparência).

O respondente confirma verbalmente. A confirmação é capturada no registro de consentimento associado à conversa. Se o respondente recusar, a gravação não começa e nenhuma entrada no data lake é gravada.

O script de consentimento é publicado. Sua equipe jurídica pode revisá-lo antes de qualquer implantação. O script pode ser adaptado à sua jurisdição (Loi 25 Quebec, GDPR, variantes de consentimento informado HIPAA) sem modificar o fluxo subjacente.

A etapa de redação remove nomes, identificadores de pessoas e evocações da transcrição bruta antes de qualquer chamada de enriquecimento ser executada. A lista padrão cobre nomes de respondentes e padrões comuns de identificadores. Além dos padrões, a lista de redação é sua para estender. Qualquer elemento específico do seu negócio que nunca deva aparecer em uma transcrição, você adiciona à lista.

Extensões comuns: números de conta de clientes, códigos de projetos internos, nomes de pessoal interno que poderiam ser identificados pela descrição de seu papel, nomes de fornecedores vinculados a um acordo de confidencialidade, nomes de executivos de concorrentes que o respondente possa mencionar. A lista é editada no console do operador. As alterações entram em vigor na próxima conversa.

A lista de redação é versionada. Uma conversa enriquecida sob a versão 4 da lista carrega uma referência a essa versão nos seus metadados, de modo que uma auditoria pode estabelecer o que foi redigido no momento do processamento.

Um respondente que revoga o consentimento entra em contato com o operador (ou, em algumas implantações, usa um link de autoatendimento incluído no e-mail pós-entrevista). A revogação escreve um evento de tombamento contra o identificador de conversa no índice do data lake. O tombamento carrega o timestamp de revogação e o escopo solicitado (a conversa inteira, um tópico específico ou uma citação específica).

O tombamento entra em vigor imediatamente no lado de leitura. O worker de consulta verifica o sinalizador de tombamento antes de servir qualquer dado da conversa afetada. As linhas de entidade da conversa no armazenamento de fatos são marcadas como inválidas no timestamp do tombamento na próxima atualização de enriquecimento. Os agregados calculados antes do tombamento são recalculados no próximo ciclo de atualização completo.

Cada linha de fato no corpus carrega um identificador de chunk da forma transcript_id / turn_id / sentence_id apontando para a frase fonte. O identificador de chunk é a alça de propagação.

Quando um tombamento é gravado, o indexador do corpus encontra cada fato cujo identificador de chunk resolve para a conversa tombada e marca o fato como invalid_at = tombstone_ts. O caminho de consulta bi-temporal filtra fatos cuja janela de validade inclui o tempo de consulta, de modo que os fatos tombados param de ser retornados. Eles não são excluídos; a trilha de auditoria preserva sua existência e seu status de tombamento.

Para agregados já calculados antes do tombamento, o recálculo na próxima atualização exclui os fatos tombados. O agregado pré-tombamento é retido para auditoria com uma referência ao evento de tombamento que acionou sua substituição.

O evento de tombamento é permanente. Cada fato cujo identificador de chunk resolve para a conversa tombada carrega sua referência de tombamento. Uma consulta como 'mostre-me cada parte da inteligência derivada da conversa com o respondente X e confirme que nenhuma delas está sendo servida no painel' é respondível a partir da referência de tombamento e da janela de validade bi-temporal.

Para reguladores que pedem prova de conformidade com uma solicitação de direito ao apagamento, a trilha de auditoria é a prova. O respondente recebe uma confirmação que lista cada fato derivado de sua conversa e o timestamp em que cada fato parou de ser servido.

Agregados já compartilhados em um relatório publicado não podem ser retirados do relatório; o que podemos fazer é excluir a contribuição do respondente do próximo agregado e corrigir o conjunto de dados subjacente do relatório. O tombamento é retroativo no corpus; ele não pode reescrever um PDF que saiu da plataforma no trimestre passado.

Artefatos estatísticos de um único respondente em um corpus grande estão tipicamente abaixo do limiar de re-identificação prática. O tombamento ainda se aplica. O operador do corpus pode decidir se recalcula um agregado ou o deixa como está com uma nota de rodapé referenciando o tombamento.