Continuar conversas com chatbots: sessões, troca de dispositivos e transferência segura

Um visitante faz três perguntas no chatbot do website, navega para a página do produto e regressa mais tarde. Uma cliente começa no smartphone e deseja continuar no portátil. No suporte, um operador humano acaba por assumir a conversa. Em todos os três casos, a expectativa é a mesma: a conversa deve continuar de forma fluida. No entanto, técnica e organizacionalmente, tratam-se de três tarefas distintas. Quem as mistura arrisca perder o contexto, expor dados indesejados ou manter uma sessão ativa durante mais tempo do que o necessário.

"Continuar" não é o mesmo que "reconhecer"

Para o planeamento, ajuda ter uma distinção clara entre três níveis de continuidade:

1. Dentro de uma visita: A conversa é mantida enquanto o utilizador navega entre páginas ou fecha e volta a abrir a janela do chat.
2. Num retorno posterior: O mesmo navegador reencontra uma conversa anterior dentro de um prazo limitado.
3. Entre dispositivos: Uma pessoa continua a conversa noutro navegador ou dispositivo. Para isso, é geralmente necessária uma associação fiável a uma conta ou um processo de transferência de curta duração ativado intencionalmente.

O simples facto de existir um histórico de conversa não comprova a identidade do utilizador. Quem possui um ID de conversa ou um link não deve, por isso, ter acesso automático a encomendas, dados contratuais ou informações pessoais. Trata-se da mesma fronteira fundamental que se aplica à separação entre um chatbot público e um portal de cliente autenticado: o contexto pode proporcionar conveniência, mas não substitui a autenticação nem a verificação de permissões.

A base técnica: referência no navegador, estado no servidor

Uma arquitetura robusta armazena no navegador apenas uma referência aleatória e sem significado intrínseco. O estado da conversa correspondente reside no servidor e é verificado a cada pedido quanto à validade, inquilino (tenant), permissões e data de expiração. As recomendações da OWASP sobre Session Management aconselham o uso de identificadores de sessão sem significado, difíceis de adivinhar e com limites de tempo controlados no servidor. Além disso, os identificadores de sessão não devem constar nos URLs: podem ser expostos através do histórico, registos do servidor, cabeçalhos de referência ou links partilhados.

O armazenamento do navegador tem diferentes alcances. Segundo a MDN Web Storage API, o sessionStorage está associado ao separador e à origem, terminando normalmente quando o separador é fechado. Por outro lado, o localStorage persiste entre sessões do navegador, mas permanece restrito ao mesmo perfil de navegador. Nenhum dos dois cria uma identidade entre dispositivos. Armazenar transcrições sensíveis ou tokens de acesso permanentes diretamente aí aumenta os danos em caso de acesso indevido a scripts ou ao próprio dispositivo.

Que dados deve conter o estado

Para uma continuação útil, o sistema necessita frequentemente de menos do que uma transcrição completa. Um conjunto de dados de estado compacto e versionado pode ser suficiente:

• o assunto atual e o objetivo confirmado,
• factos não sensíveis já esclarecidos,
• questões pendentes e o próximo passo lógico,
• fontes de conhecimento utilizadas ou as suas respetivas versões,
• estado do consentimento, autenticação e transição (handoff),
• data/hora da última atividade e a data de expiração definida.

Isto permite dar continuidade à conversa de forma coerente, sem copiar todas as mensagens anteriores indefinidamente para o prompt ativo. O histórico completo pode ser conservado separadamente, de forma resumida ou simplesmente não ser guardado – dependendo da finalidade, da expectativa do utilizador e das regras estabelecidas. Para dados pessoais, os princípios de limitação das finalidades, minimização dos dados e limitação da conservação constantes do Artigo 5.º do RGPD são diretrizes fundamentais de conceção. Isto não substitui o aconselhamento jurídico individual, mas fornece um requisito de produto claro: armazenar apenas o que é realmente necessário para um fim determinado.

Tratar conversas anónimas e autenticadas de forma diferente

Retorno anónimo no mesmo navegador

Para visitantes anónimos, a funcionalidade "continuar conversa" deve permanecer como um recurso de conveniência limitado. É recomendável utilizar um período de retenção curto, um comando de eliminação bem visível e uma explicação clara de que o histórico só poderá ser recuperado neste navegador específico. O chatbot não deve presumir que, por haver um retorno, se trata da mesma pessoa física. Após a expiração ou a perda da referência local, é iniciada uma nova sessão.

Na prática, o chatbot pode perguntar ao retornar: "Gostaria de continuar a conversa sobre a seleção de produtos ou prefere começar de novo?" Isto é preferível a ativar silenciosamente um contexto antigo. Em dispositivos partilhados, esta confirmação impede que a pessoa seguinte veja imediatamente conteúdos que não lhe dizem respeito.

Troca de dispositivo com autenticação

A continuidade entre diferentes dispositivos deve estar associada a uma conta verificada e às suas permissões atuais. Após o início de sessão, o servidor carrega apenas as conversas atribuídas a essa conta e ao respetivo inquilino. Em ações sensíveis – como alteração de morada, consulta de contratos ou realização de encomendas –, é recomendável exigir uma nova autenticação, mesmo que o chat geral continue ativo.

As diretrizes atuais do NIST SP 800-63B sobre gestão de sessões descrevem as sessões como a ligação entre uma pessoa autenticada e um serviço através de um segredo de sessão. Exigem limites de tempo tanto por inatividade como globais, além do encerramento controlado no lado do servidor. Para as equipas de produto, a conclusão é clara: "autenticado" não pode ser um estado ilimitado, e um token de conta ou de sessão expirado não deve ser reativado pelo simples facto de ainda existir um histórico de chat.

Código de transferência apenas como uma ponte estritamente limitada

Algumas soluções pretendem permitir uma troca anónima através de um código de utilização única ou código QR. Nesses casos, o código deve ser de curta duração, descartável e revogável. Não deve conter transcrições nem dados do cliente, mas apenas uma referência aleatória para um estado de conversa mínimo e autorizado. Após a transferência bem-sucedida, a referência antiga é invalidada. O código funciona como uma ponte para o contexto, não como uma prova de identidade nem como uma autorização de acesso a dados sensíveis da conta.

As regras de expiração devem ser claras na interface

Os limites de tempo técnicos resolvem apenas metade do problema. Os utilizadores precisam de saber se e por quanto tempo a sua conversa será mantida. As recomendações do NIST para Customer Experience enfatizam a importância de informações claras sobre o fim da sessão, evitando que o trabalho se perca e que as pessoas recorram a soluções alternativas inseguras.

Portanto, um bom conceito de expiração responde diretamente na interface do chat a perguntas como:

• A conversa é mantida após fechar a janela?
• Isso aplica-se apenas a este navegador ou também após iniciar sessão noutros dispositivos?
• Quando é que a sessão termina por inatividade e quando é apagado o histórico guardado?
• Que partes podem ser removidas ou exportadas pelo próprio utilizador?
• O que acontece a um pedido de suporte pendente após a expiração?

Antes do fim previsto de uma sessão, um aviso discreto pode oferecer a opção de guardar as informações pendentes ou de as transferir para a equipa de suporte. Após a expiração, a interface deve distinguir claramente entre "sessão terminada" e "histórico eliminado". Uma refere-se ao acesso, a outra à retenção dos dados.

Human Handoff: transferir o contexto, tornar a responsabilidade visível

Ao transitar para um operador humano, um resumo estruturado e sucinto é frequentemente mais valioso do que um histórico longo e sem comentários. Ele deve destacar o objetivo, as informações confirmadas, os passos já sugeridos, as dúvidas pendentes e as fontes utilizadas. Conteúdos sensíveis só devem ser transferidos se forem necessários para o caso de suporte e tiverem sido autorizados.

O utilizador deve perceber claramente que uma pessoa assumiu o atendimento, que informações foram transmitidas e se haverá um novo tempo de espera. Ao mesmo tempo, a IA deve saber, após a transferência, se deve permanecer em silêncio, apenas prestar suporte organizacional ou se poderá retomar a conversa mais tarde. Condições de ativação concretas e regras de escalamento são abordadas no artigo sobre Human Handoff em chatbots de websites.

Implementação em seis passos

1. Especificar cenários de utilização: Definir separadamente a navegação entre páginas, o retorno posterior, a troca de dispositivo e a transferência para um operador humano.
2. Definir níveis de confiança: Determinar que conteúdos estão disponíveis de forma anónima, após a associação à conta ou apenas após uma nova autenticação.
3. Minimizar o estado: Conceber um estado de continuação (resume-state) estruturado com o objetivo, dados confirmados, pontos pendentes e tempo de expiração.
4. Aplicar o ciclo de vida: Testar no lado do servidor os limites de inatividade, o limite absoluto, a eliminação, a revogação e o encerramento de sessão (logout).
5. Estruturar as transferências: Tornar visíveis a confirmação do utilizador, o resumo para o suporte, o estado de espera e a atribuição de responsabilidades.
6. Medir o sucesso sem texto integral: Registar eventos como "continuação oferecida", "aceite", "expirada", "troca de dispositivo concluída" e "handoff bem-sucedido". O guia de Analytics para chatbots de IA explica como o fazer com minimização de dados.

Matriz de testes para desktop, dispositivos móveis e casos limite reais

Antes do lançamento, é crucial testar mais do que o caminho ideal (happy path). Uma pequena matriz de testes permite cobrir as falhas mais comuns:

• Navegação dentro do mesmo website com a janela de chat aberta e fechada,
• Retorno no mesmo navegador antes e depois do limite de inatividade,
• Retorno em janela de navegação privada ou após limpar os dados locais do navegador,
• Troca de dispositivo antes e depois de iniciar sessão, bem como após o encerramento da sessão,
• Troca de conta num dispositivo partilhado,
• Código de transferência expirado, já utilizado ou revogado,
• Conversa eliminada, conta bloqueada e alterações nas permissões do inquilino,
• Continuação da conversa após uma atualização na base de conhecimento,
• Handoff com e sem resumo expressamente autorizado,
• Títulos extensos, idiomas com diferentes comprimentos de texto e larguras em ecrãs móveis sem quebras horizontais indesejadas.

Em cada cenário, a verificação deve incluir, além da resposta visível, os acessos à rede, a invalidação da sessão, os registos de erros e os eventos de analytics. O chatbot pode explicar cordialmente que determinado contexto já não está disponível, contudo, nunca deve tentar reconstruí-lo a partir de dados de utilizadores semelhantes nem atribuí-lo a uma nova pessoa.

Conclusão: continuidade é uma transferência controlada

Proporcionar uma boa experiência de continuação não significa guardar tudo para sempre. Significa transportar o contexto certo e mínimo ao longo de um percurso claramente delimitado. O mesmo navegador, um segundo dispositivo autenticado e um canal de suporte humano necessitam de regras de confiança e de expiração distintas. Quando o estado da conversa, a identidade e as permissões permanecem separados, obtém-se conveniência sem comprometer a privacidade dos dados.

Integrar estas regras precocemente no design de Conversational UX permite reduzir interrupções de sessão e tornar as transferências para o suporte mais claras. As funcionalidades do ChatReact oferecem uma visão geral dos componentes disponíveis para chatbots em websites; a configuração concreta das sessões e da proteção de dados deve depois ser planeada e testada à medida de cada caso de uso.

Fontes

• NIST SP 800-63B: Session Management
• NIST SP 800-63C: Customer Experience
• OWASP Session Management Cheat Sheet
• MDN: Web Storage API
• EUR-Lex: Regulamento Geral sobre a Proteção de Dados, Artigo 5.º