Como definir períodos de retenção para chats de suporte ao cliente

Porque o histórico indefinido de chats é um risco

Um chat de suporte ao cliente pode conter dados de contacto, contexto da conta, histórico de reclamações, provas de pagamento ou entrega, capturas de ecrã, documentos e informações adicionadas internamente por um agente. Manter todos os registos para sempre raramente é uma predefinição operacional defensável.

Ao abrigo do princípio de limitação da conservação do RGPD, os dados pessoais identificáveis não devem ser conservados mais tempo do que o necessário para as finalidades para as quais são tratados. A questão prática não é se um histórico completo poderá ser conveniente um dia. É se uma finalidade definida ainda exige uma categoria específica de dados.

A retenção indefinida também aumenta o conjunto de registos expostos a acessos indevidos, divulgação, perda ou alteração. Pode tornar os pedidos de acesso e apagamento mais difíceis de satisfazer, complicar investigações e levar as equipas de suporte a procurar em contextos obsoletos.

• Não use «caso venhamos a precisar» como finalidade de retenção.
• Defina um período normal, um evento que inicia a contagem, um ponto de revisão e uma ação de eliminação.
• Permita a eliminação antecipada quando os dados deixarem de ser necessários.
• Trate uma exceção lícita e documentada como uma exceção, e não como motivo para preservar toda a caixa de entrada.

Faça o inventário dos dados de uma conversa de suporte antes de definir um período

Uma única vista da caixa de entrada não corresponde a uma única categoria de dados. Mapeie onde existe cada elemento, quem lhe pode aceder, porque é utilizado e se possui uma exportação, um repositório de anexos, uma cópia de segurança ou um sistema de relatórios separado. Este inventário é a base de uma política de retenção de chats de suporte ao cliente.

A webchat.vip disponibiliza uma caixa de entrada partilhada para conversas WebChat e WhatsApp, análises operacionais, registos de conversas, avaliações e relatórios exportáveis. As equipas também podem utilizar operadores, departamentos, encaminhamento, horários, níveis de serviço, modelos e etiquetas. Estes objetos operacionais podem ter finalidades e percursos de eliminação diferentes, pelo que não devem herdar automaticamente um único período ao nível da conversa.

Os ficheiros dos clientes exigem especial atenção. A webchat.vip armazena ficheiros numa subconta isolada da Apification Cloud para cada serviço omnicanal. Os responsáveis pela plataforma, segurança e gestão de registos da sua organização devem, ainda assim, mapear o acesso, as cópias, o tratamento de cópias de segurança, a capacidade de eliminação e as responsabilidades nesse percurso de armazenamento.

• Transcrições de conversas ativas e metadados de mensagens
• Notas internas, atribuições, histórico de encaminhamento e eventos de nível de serviço
• Anexos enviados pelo cliente e ficheiros enviados pela empresa
• Etiquetas, categorias, avaliações e registos de revisão de qualidade
• Exportações descarregadas para trabalho sobre casos, auditorias ou análises
• Relatórios agregados e resultados de análises
• Cópias de segurança, arquivos e sistemas ligados que possam conter cópias

Atribua uma finalidade antes de escolher um período de retenção

A retenção segue a finalidade. Para cada linha do cronograma, registe a finalidade operacional ou jurídica específica, o responsável pelos dados, o evento empresarial que inicia a contagem da retenção, o período normal e o resultado aprovado para quando esse período terminar.

As finalidades comuns incluem a continuidade de um pedido de serviço aberto, o tratamento de uma reclamação ou litígio, a investigação de suspeita de fraude ou de um incidente de segurança, o cumprimento de uma obrigação legal e a produção de relatórios para melhoria do serviço. Uma finalidade de elaboração de relatórios pode muitas vezes ser cumprida com informações agregadas ou efetivamente anonimizadas, em vez de transcrições identificáveis.

A sensibilidade, as necessidades de acesso e as alternativas menos intrusivas devem influenciar a decisão. Por exemplo, um anexo que contenha provas sensíveis pode exigir um período normal mais curto, acesso mais restrito e um processo de revisão separado, em comparação com uma etiqueta de baixa sensibilidade usada para encaminhamento.

• Necessidade: Que decisão, serviço ou obrigação exige estes dados?
• Sensibilidade: A categoria pode conter informações sensíveis, financeiras, de identidade ou de segurança?
• Acesso: Que funções precisam realmente de os consultar e durante quanto tempo?
• Alternativas: Um resumo curto do caso, um relatório agregado ou uma anonimização eficaz podem cumprir a finalidade?
• Cópias: O mesmo conteúdo existe na caixa de entrada, no repositório de ficheiros, numa exportação ou numa cópia de segurança?
• Revisão: Quem pode aprovar uma extensão e que provas deve registar?

Crie uma matriz de retenção, e não uma única regra para toda a caixa de entrada

As durações exatas devem ser definidas pela sua organização de acordo com as suas finalidades, a legislação aplicável, os deveres contratuais e a avaliação de risco. Não copie um número genérico para todas as linhas. As expectativas de manutenção de registos do RGPD e as orientações da ICO apoiam a documentação separada de categorias, utilizações e períodos de retenção previstos.

Utilize o modelo seguinte como ferramenta de decisão. Substitua os campos entre parênteses retos por decisões internas aprovadas. Um responsável pela privacidade ou pela gestão de registos deve validar o cronograma antes de este se tornar operacional.

• Transcrições — Finalidade: resolver e assegurar continuidade num caso de suporte. Evento inicial: fecho do caso ou último contacto significativo do cliente. Período normal: [período aprovado]. Ação final: eliminar ou reter apenas um resumo necessário do caso. Responsável: Operações de Suporte.
• Notas internas — Finalidade: passagem de informação, garantia de qualidade ou tratamento de reclamações. Evento inicial: criação da nota ou fecho do caso. Período normal: [período aprovado, frequentemente avaliado em separado]. Ação final: eliminar com o caso relacionado, salvo se se aplicar uma exceção documentada. Responsável: Operações de Suporte.
• Anexos — Finalidade: verificar ou resolver o pedido específico. Evento inicial: receção, conclusão da verificação ou fecho do caso. Período normal: [período aprovado]. Ação final: eliminar do armazenamento de ficheiros e das cópias associadas de acordo com o procedimento de eliminação. Responsável: Responsável pelo caso, com supervisão da Segurança.
• Etiquetas e dados de encaminhamento — Finalidade: encaminhar, medir ou gerir uma interação de serviço. Evento inicial: fecho do caso. Período normal: [período aprovado]. Ação final: eliminar ou agregar sempre que possível. Responsável: Operações de Suporte.
• Avaliações e registos de qualidade — Finalidade: revisão e melhoria da qualidade do serviço. Evento inicial: conclusão da avaliação ou revisão. Período normal: [período aprovado]. Ação final: eliminar identificadores ou utilizar um resultado agregado quando adequado. Responsável: Responsável pela Qualidade.
• Exportações — Finalidade: análise, auditoria ou trabalho de caso definido. Evento inicial: criação da exportação. Período normal: [período curto aprovado]. Ação final: eliminar do destino e registar a conclusão. Responsável: Solicitante da exportação e responsável pelo sistema.
• Relatórios agregados — Finalidade: análise de tendências e relatórios operacionais. Evento inicial: geração do relatório. Período normal: [período aprovado]. Ação final: reter apenas se o resultado não for razoavelmente identificável; caso contrário, aplicar um período definido. Responsável: Responsável pelas Análises.

Dê aos anexos o seu próprio fluxo de trabalho de segurança e eliminação

Os ficheiros não são apenas mensagens de chat longas. Uma imagem, PDF ou folha de cálculo carregada por um cliente pode criar riscos diferentes de privacidade, malware e acesso, e pode permanecer útil durante muito menos tempo do que a transcrição que a rodeia.

Confirme os controlos de tratamento de ficheiros com os responsáveis relevantes pela plataforma e pela segurança. As orientações da OWASP para carregamento de ficheiros destacam armazenamento segregado, permissões de privilégio mínimo, autorização de carregamento, nomes de ficheiro gerados, validação de tipo e conteúdo, controlos de tamanho e verificações antimalware ou em sandbox, quando disponíveis. Não assuma que todos os controlos estão ativados ou disponíveis sem verificação.

Defina quem decide que um anexo já não é necessário. O agente que fecha um caso pode identificar o evento, mas um responsável pelo sistema deve assegurar uma execução fiável no repositório de ficheiros, nas exportações e nas cópias de segurança.

• Limite as permissões de carregamento aos utilizadores e fluxos de trabalho que delas necessitam.
• Informe os clientes para não enviarem informações sensíveis desnecessárias quando existir uma alternativa.
• Registe se estão disponíveis verificações de malware ou em sandbox, quem revê os alertas e como são isolados os ficheiros suspeitos.
• Evite descarregar anexos para pastas locais não geridas ou espaços de colaboração não aprovados.
• Teste se um pedido de eliminação alcança o repositório de anexos, bem como a vista da conversa.
• Escale imediatamente suspeitas de malware, divulgação acidental ou acesso não autorizado a ficheiros para o processo de incidente de segurança; não peça aos agentes de primeira linha que tomem sozinhos a decisão de contenção.

Não confunda eliminação, anonimização, restrição e arquivamento

Estes termos descrevem resultados diferentes e devem constar como campos separados no seu cronograma. Fechar, ocultar ou arquivar uma conversa não é eliminá-la. Os dados offline continuam a ser tratamento de dados pessoais e ainda precisam de um período de retenção justificado, controlos de segurança e tratamento adequado dos pedidos relativos a direitos.

A eliminação remove dados de acordo com o processo de descarte definido pela organização. Se o apagamento físico imediato não for tecnicamente possível em todas as camadas, defina como os dados são tornados inutilizáveis e como é tratada a eliminação das cópias de segurança. O descarte seguro deve corresponder à sensibilidade da informação e ao suporte de armazenamento.

A anonimização eficaz pode apoiar análises de longo prazo, mas deve impedir genuinamente a identificação. A pseudonimização, por si só, não põe fim às obrigações de limitação da conservação. A restrição também é distinta: nos termos do artigo 18.º do RGPD, os dados sujeitos a restrição podem geralmente ser conservados enquanto o tratamento adicional é limitado a circunstâncias especificadas.

• Eliminação: descartar o conteúdo e as cópias aplicáveis ao abrigo do procedimento documentado.
• Anonimização eficaz: manter apenas um resultado que já não seja identificável, após testar o risco de reidentificação.
• Restrição: preservar o registo com limites de tratamento enquanto uma questão definida é resolvida.
• Arquivo: mover dados para outro local; manter todas as obrigações de privacidade, segurança e retenção.
• Tratamento de cópias de segurança: documentar ciclos de cópia de segurança, salvaguardas de restauro e o momento em que os dados eliminados são removidos ou tornados inutilizáveis.

Gira as exceções com um processo controlado de suspensão

Um período normal de retenção pode ser suspenso ou alargado para um registo específico quando existe uma necessidade clara, como um litígio ativo, uma ação judicial, uma obrigação legal, uma revisão de fraude, uma investigação de segurança ou um pedido de cliente por resolver. A exceção deve ser limitada, fundamentada e revista.

Crie um registo de suspensões em vez de depender da memória dos agentes ou de uma etiqueta sem governação. O registo deve identificar o âmbito da suspensão, o seu motivo, quem a autorizou, os sistemas e categorias afetados, as restrições de acesso, a data de revisão e a decisão de levantamento. Preserve apenas os registos necessários para o assunto declarado.

Os pedidos de apagamento ou restrição dos clientes exigem um percurso de revisão humana. Não permita que um fluxo de trabalho automatizado prometa a eliminação quando uma exceção legal válida, uma restrição ativa ou uma verificação de identidade não resolvida possa afetar a resposta. Os responsáveis pela Privacidade ou pelo departamento Jurídico devem decidir os casos contestados e fornecer a resposta aplicável.

• Abrir suspensão: identificador do caso, finalidade, âmbito, autoridade e data de início.
• Limitar o acesso: restringir o material suspenso a funções autorizadas.
• Revisar: definir uma revisão com data, e não uma suspensão sem prazo.
• Levantar: remover prontamente a suspensão quando a necessidade terminar e devolver o registo ao fluxo de eliminação.
• Escalar: encaminhar ações judiciais, exigências regulamentares, incidentes de segurança e pedidos de direitos contestados para o departamento Jurídico, de Privacidade ou de Segurança, de acordo com os procedimentos de incidentes e registos da organização.

Controlos operacionais que tornam o cronograma real

Uma política é ineficaz se os contornos normais do trabalho criarem cópias não geridas. A retenção deve ser uma responsabilidade operacional conjunta: as Operações de Suporte são responsáveis pelos processos de caso; a Privacidade ou a Gestão de Registos é responsável pela base da política e pelo tratamento de direitos; a Segurança é responsável pelos controlos de acesso e de incidentes; e os responsáveis técnicos validam a configuração do sistema e o comportamento de eliminação.

Utilize acesso de privilégio mínimo para caixas de entrada, departamentos, ficheiros, exportações e funções administrativas. Reveja o acesso quando as pessoas mudam de função. Mantenha registos de administração auditáveis, mas evite colocar cópias desnecessárias de conteúdo de clientes no rasto de auditoria.

A webchat.vip pode organizar operadores, departamentos, encaminhamento, horários, níveis de serviço, modelos e etiquetas. Utilize essas funcionalidades organizacionais para reduzir o acesso alargado, mas confirme as capacidades precisas de retenção, exportação, eliminação, armazenamento de ficheiros e auditoria disponíveis no seu serviço implementado antes de as apresentar como controlos.

• Nomeie um responsável empresarial e um responsável técnico para cada linha de retenção.
• Configure uma revisão programada ou um fluxo de eliminação quando a capacidade validada da plataforma o permitir.
• Mantenha um registo de verificação de eliminação com a versão da regra, a categoria, a data de execução, o âmbito do sistema ou armazenamento, o resultado e a referência da exceção — sem copiar conteúdo de clientes.
• Teste uma amostra de eliminações concluídas, incluindo ficheiros, exportações e cópias de segurança aplicáveis.
• Concilie as entradas do registo de suspensões com os trabalhos de eliminação programados antes de cada execução.
• Reveja os acessos privilegiados e as permissões de exportação numa cadência definida.
• Forme os agentes para reconhecer ficheiros sensíveis, pedidos relativos a direitos, notificações legais e questões de segurança e, em seguida, escalar em vez de improvisar.