Segurança no chat ao vivo: 7 pontos para proteger antes de a sua caixa de entrada entrar no ar

O chat ao vivo é um dos canais em que os clientes mais confiam. Um visitante digita uma pergunta que muitas vezes inclui o e-mail dele, o número do pedido, às vezes o endereço, de vez em quando um print do extrato bancário, e confia que o agente do outro lado é a pessoa certa e que a transcrição não fica exposta. As configurações padrão da maioria das ferramentas de chat ao vivo não foram escritas pensando nisso. Elas foram escritas para uma demo no estilo da Stripe, que nunca vê um cliente de verdade.

Esta é a checklist de segurança para chat ao vivo que entregamos às equipes que usam o Deskwoot, dividida nas sete decisões que realmente importam. A maior parte dela é a base de segurança de todos os planos do Deskwoot, inclusive o plano grátis Hacker (criptografia na transmissão, hospedagem na UE, 2FA, o DPA e as ferramentas para solicitações do GDPR). Assim, uma equipe que começa do zero não precisa configurar nada à mão antes de entrar em produção. Quando um controle exige um plano pago, nós avisamos.

1. Criptografe o canal e o armazenamento

Esta é a camada básica. Toda ferramenta de chat ao vivo que se diz segura deveria usar TLS 1.2 ou superior em todos os endpoints que visitantes e agentes acessam, e AES-256 em repouso para cada mensagem gravada em disco. Vale fazer duas perguntas ao seu fornecedor:

• O widget vem do seu próprio domínio ou da CDN de um fornecedor? Se o script do seu widget fica em uma CDN de terceiros que não exige TLS 1.3 ou que vem com uma CSP permissiva, você tem uma brecha nas suas camadas de defesa dentro da sua própria página. O widget do Deskwoot é um script curto que carrega via HTTPS (TLS) a partir do domínio do próprio Deskwoot e roda dentro do seu próprio iframe, e o painel dos agentes envia HSTS mais uma Content Security Policy com uma lista explícita dos hosts dos quais o navegador pode carregar ou aos quais pode se conectar.
• Os anexos das mensagens são criptografados em repouso? Alguns fornecedores criptografam o texto da mensagem e deixam de fora o armazenamento dos anexos. É justamente lá que os clientes enviam prints de reembolsos, documentos de identidade e extratos bancários. O Deskwoot armazena os anexos no Cloudflare R2 sob jurisdição da UE, onde a Cloudflare criptografa cada objeto em repouso, e só os libera por links com verificação de acesso: uma sessão de agente com login ou uma URL assinada de curta duração, nunca uma pública.

2. Verifique o cliente antes de revelar qualquer coisa sensível

A falha de segurança mais comum no chat ao vivo não é um ataque hacker. É um agente respondendo “Para onde vai o pedido #4821?” sem verificar quem está do outro lado. Essa resposta é um dado privado. A maioria das ferramentas de chat ao vivo não tem um fluxo de verificação embutido, então o agente improvisa (ou pula essa etapa).

O Fynn, bot de IA do Deskwoot (incluso a partir do plano Startup), traz um modelo de verificação em 4 níveis que é aplicado antes de qualquer detalhe privado sair da conversa:

• Nível 0: Perguntas públicas. “Vocês entregam em Portugal?” recebe resposta na hora. Sem verificação.
• Nível 1: Conferência do número do pedido mais o CEP. “Cadê o pedido #4821?” exige que o visitante informe o número do pedido e o CEP de entrega antes que o Fynn compartilhe o status ou o rastreio. Se não bater, o bot não diz nada sobre o pedido.
• Nível 2: Verificação por magic link no e-mail. Pedidos sobre histórico sensível disparam um magic link de uso único para o e-mail cadastrado. O visitante clica e volta verificado pelo resto da conversa.
• Nível 3: Alterações. Reembolsos, cancelamentos, mudanças de endereço. O Fynn propõe a ação e pede que o visitante responda “confirmar” antes de fazer a chamada de API. Essas ações vêm desligadas por padrão e são ativadas por workspace. Nada de reembolso por engano por causa de uma pergunta mal escrita.

Também vale integrar a verificação ao fluxo dos agentes: um aviso visível de “verificado” na barra lateral da conversa, para que o agente humano saiba com quem está falando.

3. Escolha onde seus dados ficam

Equipes sujeitas às regras da UE não podem rodar o chat ao vivo em uma infraestrutura só dos EUA e dizer que estão em conformidade com o GDPR. Mesmo equipes dos EUA que vendem para a UE têm obrigações sobre onde os dados ficam. É aqui que a avaliação da maioria dos fornecedores desmorona, porque a página de marketing diz “GDPR”, mas o acordo de processamento de dados, nas letras miúdas, ainda passa por us-east-1.

A infraestrutura principal do Deskwoot roda em europe-west4 (Holanda). Mensagens dos clientes, contas dos agentes, anexos e logs de auditoria ficam todos na UE por padrão. O plano grátis Hacker não deixa a hospedagem na UE de fora: você não precisa pagar a mais para manter os dados do seu suporte em solo europeu.

Duas coisas específicas para verificar com qualquer fornecedor de chat ao vivo:

• Onde exatamente fica o banco de dados de produção? “UE” não é específico o bastante. Pergunte a região da nuvem (eu-west-1, europe-west4 etc.) e em qual provedor ela está.
• As chamadas de IA saem da região? Muitas plataformas “hospedadas na UE” mandam o processamento de IA para um endpoint da OpenAI nos EUA e quebram em silêncio a própria promessa. O Deskwoot envia as solicitações de IA direto para a Anthropic, e a Anthropic aparece com finalidade e região no Anexo B do DPA do Deskwoot. Assim, você confere o caminho da IA do mesmo jeito que confere o banco de dados.

4. Restrinja o acesso dos agentes

O chat está criptografado, o cliente está verificado, os dados estão na região certa, e mesmo assim o Dave, seu engenheiro sênior, consegue ver todas as conversas de todas as contas, porque a ferramenta de chat ao vivo só tem uma função: admin. Essa é a segunda falha mais comum.

Um chat ao vivo seguro precisa de permissões de agente baseadas em funções:

• Escopo restrito: os agentes só veem as conversas atribuídas a eles. Útil para equipes de suporte terceirizadas, em que você não quer que cada prestador leia o histórico de todos os clientes.
• Por caixa de entrada: os agentes só veem as conversas de uma caixa de entrada específica. A equipe de cobrança vê os tickets de cobrança, o suporte vê os tickets de produto, e um não se mistura com o outro.
• SSO + 2FA: contas de agentes protegidas pelo seu provedor de identidade (Google Workspace, Microsoft Entra, Okta) mais um segundo fator. O Deskwoot não oferece SSO. Todos os planos incluem 2FA com um app autenticador, e no Enterprise um administrador pode exigi-lo de todos os membros.
• Retenção do log de auditoria: cada login, cada visualização de conversa, cada reembolso feito, quem fez e quando. Dá para investigar depois, em vez de ficar no escuro.

Combine o log de auditoria com um alerta no Slack ou por webhook para as ações que importam (exportação da conta, exclusão em massa, entrar como outro agente), e a equipe descobre um uso indevido no mesmo minuto em que ele acontece, não em uma análise 6 semanas depois.

5. Defina uma política real de retenção de dados

A maioria das plataformas de chat ao vivo guarda “tudo para sempre” por padrão, porque armazenamento é barato e elas não querem discutir conformidade. Para sempre é a configuração errada. A configuração certa é “tempo suficiente para atender o cliente, curto o bastante para limitar o estrago se houver um vazamento”.

Veja como o Deskwoot faz:

• Histórico de conversas: o histórico visível segue o plano: 30 dias no Hacker, 6 meses no Startup, 1 ano no Business, ilimitado no Enterprise. Conversas mais antigas ficam ocultas, não são apagadas, e voltam depois de um upgrade.
• Anexos: apagados automaticamente após 365 dias, independentemente do texto da mensagem, exceto no Enterprise, onde são mantidos.
• Dados pessoais dos visitantes: o fluxo do direito ao apagamento (Art. 17 do GDPR) está no painel em todos os planos. Encontre o contato pelo e-mail, veja exatamente o que será removido, confirme digitando o endereço de e-mail de novo, e os dados somem na hora. O apagamento fica registrado no log de auditoria, para que você possa provar que atendeu a solicitação.

6. Deixe o próprio widget preparado para se defender

O widget que os clientes veem é a camada que os atacantes realmente tocam. Algumas coisas para exigir:

• SRI no script do widget. Hashes de Subresource Integrity prendem o script a um SHA-384 conhecido, para que uma CDN invadida não consiga trocá-lo em silêncio por JS malicioso.
• Nada de JS inline injetado pelo conteúdo do chat. Se um agente colar “<img src=x onerror=alert(1)>” em uma resposta, o widget deve limpar isso antes de exibir. O Deskwoot usa sanitize-html em toda resposta enviada, com uma lista rígida do que é permitido (sem scripts, sem handlers on*, sem URIs javascript:).
• CSP limpa no painel dos agentes. O painel roda com default-src 'self' mais uma lista explícita dos serviços aos quais o navegador pode se conectar. Os provedores de IA nem estão nessa lista, porque toda chamada de IA roda no servidor. Um arquivo JS de fornecedor comprometido não deve conseguir se comunicar com o servidor de um atacante.
• Cookies presos à origem. Os cookies de sessão são SameSite=Lax no painel dos agentes, e toda solicitação que muda algo precisa passar por uma verificação de Origin. Assim, uma página maliciosa não consegue usar CSRF para levar um agente a resolver conversas ou fazer reembolsos.

7. Faça a revisão de segurança no primeiro dia (com um plano grátis)

A armadilha em que a maioria das equipes cai: elas escolhem um fornecedor de chat ao vivo para uma demo de 14 dias, colocam em produção e percebem três meses depois que a configuração de segurança não é o que o CISO delas precisa. A essa altura, o custo da migração parece alto demais para corrigir.

O jeito mais barato de escapar dessa armadilha é avaliar uma ferramenta de chat ao vivo em um plano grátis que já inclua os padrões de segurança pelos quais você pagaria de outra forma. O plano Hacker do Deskwoot é grátis para um agente e roda com a mesma criptografia, a mesma hospedagem na UE, 2FA, DPA e ferramentas para solicitações do GDPR de todos os planos pagos. Os planos pagos acrescentam vagas de agente, o bot de IA com a verificação de clientes, um histórico mais longo e, no Enterprise, logs de auditoria, papéis customizados e 2FA obrigatório.

Na prática:

• O plano grátis Hacker cobre um agente, 100 conversas por mês, Copilot de IA com 10 conversas de IA por mês, hospedagem na UE, 2FA, o DPA e as solicitações do GDPR.
• O Startup ($4 por agente por mês, $3.20 cobrado anualmente) acrescenta mais agentes, o bot de IA Fynn com verificação de clientes, regras de automação, 1,000 conversas e 50 conversas de IA por mês, 6 meses de histórico.
• O Business ($8, $6.40 cobrado anualmente) acrescenta equipes, CSAT, tradução, conversas ilimitadas, 100 conversas de IA por mês, 1 ano de histórico.
• O Enterprise ($12, $9.60 cobrado anualmente) acrescenta logs de auditoria, papéis customizados, 2FA obrigatório, políticas de SLA, tokens de API, 300 conversas de IA por mês e histórico ilimitado.

Essa estrutura permite que uma equipe de segurança faça a revisão de verdade com dados reais e fluxos reais já no primeiro dia, em vez de adivinhar a partir de apresentações de vendas.

A versão em 30 segundos

Se você está avaliando ferramentas de chat ao vivo agora e só tem tempo para uma checagem rápida, faça estas sete perguntas a qualquer fornecedor:

1. O widget é servido via TLS 1.2+ com SRI na tag do script?
2. Existe um fluxo de verificação de clientes embutido que protege os dados privados?
3. Onde o banco de dados de produção fica fisicamente? A resposta é a mesma para o processamento de IA?
4. A plataforma traz permissões de agente baseadas em funções, SSO e um log de auditoria de verdade?
5. Os prazos de retenção de dados podem ser configurados por caixa de entrada e por tipo de conversa?
6. O widget limpa o conteúdo do chat e o painel roda com uma CSP limpa?
7. Dá para avaliar de verdade a base de segurança em um plano grátis antes de comprometer o orçamento?

O Deskwoot responde sim para a maioria delas, com três lacunas que admitimos: o script do widget não tem hash SRI, não há SSO, e o período do histórico segue o plano em vez de uma configuração por caixa de entrada. A verificação de clientes vem com o bot de IA a partir do Startup, e os logs de auditoria e papéis customizados com o Enterprise. Comece o teste de 7 dias (Enterprise, sem cartão, 30 vagas incluindo a sua) para revisar toda a configuração de segurança com dados reais, ou vá direto para a página de preços para ver o detalhamento por plano. A página de recursos mostra o resto da plataforma; este post é o recorte focado em segurança.

Perguntas frequentes: o que mais ouvimos sobre chat ao vivo seguro

Chat ao vivo privado é o mesmo que chat ao vivo criptografado? Os dois se sobrepõem, mas não são a mesma coisa. “Criptografado” geralmente se refere à transmissão (TLS) e ao armazenamento (AES). “Privado” quer dizer que a conversa não é usada para treinar modelos de IA externos, não fica visível para a equipe de suporte do fornecedor sem um acordo por escrito e não é guardada além da política que você definiu. O Deskwoot criptografa toda conexão com TLS, também criptografa credenciais, tokens e segredos armazenados com AES-256-GCM, e o conteúdo das conversas enviado ao provedor de IA é usado para responder, não para treinar modelos.

Ainda precisamos de um acordo de processamento de dados (DPA) no plano grátis? Sim, e o Deskwoot oferece um que você mesmo aceita. Usuários do plano grátis Hacker aceitam o DPA em Configurações > Conformidade > Acordo de Processamento de Dados e recebem o PDF por e-mail, sem precisar falar com vendas.

Qual é a configuração certa de retenção? Comece com 12 meses e baixe para 30 dias em qualquer caixa de entrada que lide com documentos de identidade, prints de pagamento ou dados de saúde (PHI). E garanta que as solicitações de apagamento do Art. 17 do GDPR possam ser atendidas pelo painel, em vez de um ticket para o seu fornecedor.

O widget funciona em uma loja Shopify sem quebrar a CSP da loja? Sim. O widget carrega de forma assíncrona e roda dentro do seu próprio iframe, então não mexe nos scripts da loja. Veja o guia de atendimento ao cliente para Shopify para saber como instalar.

O bot de IA lê conversas anteriores para responder à próxima? Só dentro da mesma conversa, e os dados da conta só depois de passar pelo nível de verificação adequado. O Fynn não tem memória entre conversas.

O chat ao vivo é seguro para os clientes em 2026?

O chat ao vivo é seguro para os clientes quando a plataforma cuida de 4 coisas: criptografia TLS 1.2 ou superior para cada mensagem em trânsito, criptografia AES-256 em repouso no banco de dados da plataforma, nenhum script de terceiros dentro do widget que possa capturar o que é digitado, e políticas claras de retenção que apagam as mensagens depois de um período definido.

A maioria das plataformas de chat ao vivo confiáveis em 2026 já cumpre esses padrões desde o início. Os clientes podem conferir lendo a página de segurança da plataforma (procure menções a SOC 2 Type II, DPA do GDPR e criptografia em repouso) e inspecionando o script do widget em busca de rastreadores de terceiros inesperados (abra o DevTools do navegador e observe a aba de rede). O Deskwoot descreve a sua configuração na página de segurança: TLS (HTTPS) em toda conexão, AES-256-GCM para credenciais e tokens armazenados e nenhum script de terceiros dentro do widget.

Os agentes do chat ao vivo conseguem ver o que você digita antes de enviar?

Algumas plataformas de chat ao vivo deixam os agentes verem o que o cliente está digitando antes de ele apertar enviar (chamado de “sneak peek” ou “prévia de digitação”). Grandes plataformas que oferecem isso: LiveChat.com, Intercom e Zendesk Chat. Plataformas menores e focadas em privacidade geralmente não têm esse recurso.

O Deskwoot decidiu de propósito não ter a prévia de digitação. São dois motivos: os clientes esperam, com razão, que um texto ainda não enviado não esteja visível para ninguém, e o ganho de produtividade para os agentes é pequeno (a prévia de digitação economiza no máximo 1 a 3 segundos por resposta). A troca é pequena, mas a postura de privacidade importa quando um cliente está digitando algo sensível, como um número de pedido, um ID de conta ou, pior ainda, um dado de pagamento sem ocultação, antes de perceber e reescrever.