Excluir e exportar histórico de chatbot: Controle seguro do usuário

Um histórico de chatbot é prático para os usuários: eles podem reler respostas, continuar uma conversa mais tarde ou transferir informações para o suporte. No entanto, essa mesma história pode conter números de pedidos, descrições de problemas, dados de contato ou outras informações sensíveis. Quem armazena conversas precisa, portanto, de mais do que uma opção discreta de "Histórico". Os usuários devem entender quais dados existem, como podem levá-los consigo, excluí-los ou revogar acessos futuros.

Este guia mostra um modelo de produto e tecnologia aplicável para chatbots de sites. Ele combina facilidade de uso, minimização de dados, verificação de identidade segura e estados de sistema compreensíveis. As orientações não constituem consultoria jurídica individual; obrigações concretas dependem, entre outros fatores, da finalidade, base legal, arquitetura do sistema e dados afetados.

Quatro funções em vez de um único botão de histórico

"Gerenciar histórico" é vago demais. Na interface e no backend, quatro intenções diferentes devem ser separadas:

• Visualizar: Os usuários leem conversas salvas, anexos e metadados identificáveis em uma cronologia compreensível.
• Exportar: Eles recebem uma cópia em um formato legível e, quando fizer sentido para o caso de uso ou for exigido por lei, também em um formato estruturado e legível por máquina.
• Excluir: Eles removem conversas individuais ou todo o histórico associado. A interface explica o escopo, os prazos e as possíveis exceções.
• Revogar acesso: Eles invalidam links de compartilhamento, dispositivos conhecidos ou tokens de retomada, sem necessariamente excluir imediatamente todos os dados de conteúdo.

Essa separação evita mal-entendidos perigosos. "Sair" não exclui dados da conversa. "Ocultar histórico" não é o mesmo que excluir. E um link expirado não significa automaticamente que os registros subjacentes desapareceram. Além disso, vale a pena consultar nosso guia sobre a retomada segura de conversas de chatbot.

Começar com um modelo de dados claro

Antes que as equipes projetem botões, elas devem inventariar os objetos armazenados. Uma conversa frequentemente não consiste apenas em mensagens. Adicionam-se identificadores de sessão, marcações de data/hora, referências de arquivos, eventos de segurança, tickets de suporte, feedback e logs técnicos. Para cada objeto, é necessário ter uma finalidade documentada, um responsável, uma regra de retenção e um fluxo de exclusão.

O Regulamento Geral sobre a Proteção de Dados (GDPR) menciona no Artigo 5, entre outros, a minimização de dados e a limitação da conservação. O Artigo 15 trata do direito de acesso, o Artigo 17 aborda o direito ao apagamento com requisitos e exceções, e o Artigo 20 aborda a portabilidade dos dados no seu respectivo escopo. Disso não se conclui que toda interface de chatbot deva oferecer funções idênticas. As equipes de produto, no entanto, devem construir fluxos de dados de forma que solicitações legítimas possam ser processadas com confiabilidade.

Verificar adequadamente a identidade antes da exportação e exclusão

Quem torna um histórico acessível apenas por meio de um link adivinhável ou um identificador de sessão reutilizado arrisca o vazamento de dados. Ao mesmo tempo, uma verificação de identidade não deve solicitar genericamente mais dados pessoais do que o necessário para a ação concreta. As diretrizes finais 01/2022 do EDPB sobre o direito de acesso tratam, entre outros pontos, da identificação, do escopo e do fornecimento seguro de cópias. O Artigo 12, parágrafo 6 do GDPR permite informações adicionais para confirmação de identidade se houver dúvidas fundamentadas sobre a identidade.

Na prática, uma gradação baseada em risco tem se provado eficaz. A exibição de um histórico pseudônimo curto no mesmo dispositivo pode exigir uma sessão válida e de curta duração. Uma exportação completa, uma exclusão irreversível ou a revogação de todos os dispositivos justifica uma reautenticação. As diretrizes atuais do NIST sobre gerenciamento de sessão descrevem reautenticação, limites de tempo e encerramento de sessão como controles independentes. A força concreta deve corresponder ao risco; as diretrizes do NIST para agências federais dos EUA não são uma exigência legal genérica para todas as empresas.

Para widgets públicos e áreas logadas de clientes, o limite deve permanecer visível. Nosso artigo sobre identidade e acesso a dados no portal do cliente mostra por que um chat público não deve se tornar silenciosamente um canal de dados da conta.

Uma exportação deve ser compreensível e totalmente explicável

Uma boa exportação não é um dump bruto do banco de dados. Ela começa com uma visão geral: período de criação, conversas incluídas, anexos, fuso horário utilizado e versão do formato. Em seguida, os conteúdos vêm em uma ordem clara. JSON pode ser útil para processamento estruturado posterior; HTML ou PDF é mais fácil de ler para a maioria das pessoas. Se e em que medida um formato portátil é exigido por lei deve ser verificado para cada caso concreto.

Se o sistema gerar a exportação de forma assíncrona, a interface precisa de um status claro: "em preparação", "pronto até...", "expirado" ou "falhou". O link de download deve ser temporário, não adivinhável e revogável após o uso. Segredos como prompts internos, chaves de acesso ou dados de terceiros não pertencem ao pacote. Antes da disponibilização, um filtro no servidor deve verificar se conexões com casos de suporte, conversas compartilhadas ou conteúdos de terceiros exigem tratamento especial.

Exclusão como máquina de estados em vez de promessa imediata

Um botão com a mensagem "Tudo excluído" é problemático se o índice de busca, repositório de análises, sistema de suporte ou backup continuarem contendo cópias. É melhor usar uma pequena máquina de estados que reflita o processo real.

Estados de exclusão úteis

1. Solicitado: Identidade e escopo desejado foram confirmados.
2. Bloqueado: O histórico não está mais acessível para uso normal; tokens de retomada e compartilhamento foram invalidados.
3. Em processamento: Armazenamento primário, índice de busca, armazenamento de arquivos, destinos de análise e integrações estão sendo limpos.
4. Concluído: Os sistemas ativos previstos foram limpos; cópias de segurança restantes estão sujeitas à rotação de backup documentada ou a uma exceção justificada.
5. Parcialmente bloqueado: Um sistema não pôde ser limpo ou os dados precisam ser mantidos por enquanto. O caso é escalado de forma rastreável.

Não esquecer os dados dependentes

As mensagens podem fazer referência a arquivos, embeddings, índices de busca, avaliações de qualidade, registros de CRM ou tickets de suporte. Por isso, a solicitação de exclusão precisa de um ID de solicitação estável e etapas de trabalho idempotentes: uma nova execução não deve criar novas cópias nem reverter etapas já concluídas. Para dados de métricas, deve-se decidir no design se indicadores agregados que não possam mais ser atribuídos podem ser mantidos. Mais detalhes estão disponíveis no artigo sobre analytics com minimização de dados em chatbots.

Revogação protege especialmente em dispositivos compartilhados

Em hotéis, pontos de venda, oficinas ou residências familiares, as pessoas alternam com frequência no mesmo dispositivo. Por isso, "Revogar acesso" deve fazer mais do que simplesmente excluir um cookie localmente. No lado do servidor, tokens de sessão conhecidos, links de compartilhamento e, se aplicável, vínculos de dispositivos devem se tornar inválidos. A interface deve distinguir entre "este dispositivo", "todos os dispositivos" e "todos os links compartilhados".

Após a revogação, o botão Voltar não deve exibir um histórico sensível a partir do cache. Prévias em notificações, preenchimento automático do navegador e dados offline locais pertencem à verificação. Ao mesmo tempo, o usuário deve receber uma confirmação clara de quais acessos foram encerrados e se os dados da conversa ainda estão armazenados. Dessa forma, a revogação não é confundida com a exclusão.

Tornar a confirmação de exclusão acessível e tolerante a falhas

Uma ação irreversível precisa de uma confirmação calma e compreensível. A explicação do critério de sucesso 3.3.4 das WCAG 2.2 refere-se expressamente à alteração ou exclusão de dados controláveis pelo usuário. É prevista pelo menos uma opção para reversão, verificação ou confirmação. A variante adequada depende do produto.

Bons diálogos especificam concretamente "3 conversas e 2 anexos" em vez de apenas "dados". A ação primária e a ação destrutiva são visualmente distinguíveis, acessíveis via teclado e não explicadas apenas por cores. Após o envio, uma área de status acessível informa que a solicitação foi aceita. Uma lixeira com um período de recuperação limitado pode conter erros de operação, mas não deve contradizer secretamente uma exclusão imediata prometida.

Transição para o suporte humano sem cópia oculta

Se uma conversa for transferida para atendimento humano, é comum criar um ticket de suporte separado. Esse objeto pode ter uma finalidade diferente, diferentes funções de acesso e outra regra de retenção. As configurações de histórico no chatbot não devem excluir esse ticket de forma invisível nem ignorá-lo silenciosamente. Antes da transferência, a interface deve explicar quais conteúdos serão transferidos. Em uma solicitação posterior, o sistema deve encontrar o vínculo e tratar o caso de acordo com as regras aplicáveis.

Se uma exclusão automática falhar ou a identidade e o escopo forem incertos, o processo precisará de um canal humano seguro. O artigo sobre Human Handoff no suporte de sites descreve pacotes de contexto e regras de escalonamento para essa finalidade. Apenas o que o atendente responsável realmente necessita deve ser transferido.

Checklist de implementação para equipes de produto e suporte

1. Inventariar todos os objetos de dados e locais de armazenamento de uma conversa.
2. Modelar visualizar, exportar, excluir e revogar como permissões separadas.
3. Exigir reautenticação com base no risco para ações sensíveis.
4. Estruturar pacotes de exportação de forma compreensível e definir tempos de expiração seguros.
5. Tornar as etapas de exclusão idempotentes e rastreá-las com um ID de solicitação.
6. Incluir índice de busca, arquivos, analytics, integrações, caches e casos de suporte.
7. Testar diálogos de confirmação e mensagens de status com teclado e leitor de tela.
8. Simular dispositivos compartilhados, links expirados e dispositivos perdidos.
9. Escalar falhas parciais de forma visível sem copiar conteúdos sensíveis para logs.
10. Revisar regularmente as regras de retenção e exclusão com a equipe de proteção de dados e departamentos responsáveis.

Os testes mais importantes antes do lançamento

Os casos de teste não devem cobrir apenas o cenário ideal. Verifique solicitações de exclusão paralelas, um login expirando durante a exportação, links já revogados, novas mensagens durante uma exclusão em andamento e a falha de um sistema integrado. Além disso, controle se uma exportação contém mensagens de terceiros em contas compartilhadas e se um arquivo excluído ainda está acessível por meio de uma URL antiga.

Para cada ação, é necessário um resultado esperado na interface, API e banco de dados. Um bom teste de homologação não termina, portanto, em uma mensagem de sucesso verde. Ele verifica subsequentemente os repositórios de dados determinantes, tokens e URLs públicas. Logs de eventos devem comprovar que uma etapa foi executada, sem salvar novamente o conteúdo excluído da conversa.

Conclusão: O controle do usuário é uma propriedade de ponta a ponta

Um chatbot confiável não apenas torna o histórico fácil de encontrar. Ele separa visualização, exportação, exclusão e revogação, verifica ações sensíveis de forma adequada e mostra o status real de processamento. A conexão da UX clara com um modelo de dados que conhece todos os sistemas dependentes é decisiva.

Quem integra essas funções antecipadamente na arquitetura, nos processos de suporte e nos testes reduz exceções manuais e evita falsas promessas. Ao planejar, verifique também quais recursos do ChatReact combinam com seu site e processo de suporte. Comece com um inventário de dados e um único teste de ponta a ponta: exportar o histórico, revogar acessos, acionar a exclusão e comprovar o resultado em todos os sistemas envolvidos.

Fontes e referências adicionais

• EUR-Lex: Regulamento (UE) 2016/679, especialmente os Artigos 5, 12, 15, 17 e 20.
• EDPB: Guidelines 01/2022 on data subject rights – Right of access, Versão 2.1.
• NIST SP 800-63B: Session Management.
• W3C: Understanding WCAG 2.2 Success Criterion 3.3.4.