Política de privacidade

O UserKit exerce dois papéis distintos sob a LGPD, porque o produto tem dois planos que nunca se misturam:

Controladora — para os dados das contas da equipe: as pessoas que criam conta no painel, participam de organizações e administram o serviço. Aqui as decisões sobre o tratamento são nossas, e esta política as descreve.

Operadora — para os dados dos contatos das organizações: os usuários dos produtos dos nossos clientes. Aqui o controlador é a organização que usa o UserKit; tratamos esses dados para prestar o serviço a ela e sob as instruções dela, nos termos do DPA, nunca para fins próprios.

Da conta da equipe: nome, e-mail, senha (armazenada apenas como hash bcrypt), configuração de dois fatores e as sessões ativas. Do uso do painel: endereço IP e user agent das requisições — usados para segurança da conta e para a trilha de auditoria que registra o que cada administrador fez, que é uma proteção da própria organização.

Este site público não usa cookies de rastreamento nem coleta dados de visitantes: toda página é estática e servida de CDN.

Os contatos que cada organização registra: identificadores (e-mail, identidade externa, identificadores anônimos de visita), atributos que a organização envia, sessões, e o registro de eventos de autenticação da conta do contato. Credenciais são armazenadas apenas como hash; segredos que precisam ser lidos de volta são criptografados em repouso.

Conforme a organização usa os módulos que existem além da autenticação, tratamos por conta dela também: os eventos de produto que ela envia (o nome do evento, as propriedades que ela escolhe, o momento e a quem o evento pertence); as conversas de suporte entre ela e os contatos dela, incluindo o conteúdo das mensagens e dos e-mails recebidos no domínio de entrada; as respostas de pesquisa e feedback que os contatos dela deixam; e a associação de cada contato aos segmentos que ela define. Nada disso é iniciativa nossa: cada módulo só passa a tratar dado quando a organização o utiliza, e o conteúdo das propriedades de um evento é escolha dela, não nossa.

Não usamos os dados dos contatos para nada além de prestar o serviço à organização controladora — não há publicidade, enriquecimento nem venda de dados, de nenhum dos dois planos.

Para os dados que controlamos: execução de contrato (art. 7º, V — criar e manter a conta e a organização é o serviço), legítimo interesse (art. 7º, IX — segurança, prevenção a abuso e fraude, e a trilha de auditoria), e cumprimento de obrigação legal (art. 7º, II — registros fiscais e o que a lei mandar guardar). Para os dados dos contatos, a base legal é definida pela organização controladora; nossa base para tratá-los como operadora é a execução do contrato com ela.

O serviço roda sobre os seguintes fornecedores, cada um nomeado com o que faz e onde processa:

Os três últimos são condicionais e a condição é da organização, não nossa. O Stripe só entra quando ela conecta o gateway dela — nesse caso a relação de pagamento é entre a organização e o Stripe, e nós espelhamos o que o gateway informa. O modelo que redige respostas automáticas de suporte e o que gera os vetores de busca da base de ajuda só recebem conteúdo quando a organização liga esse atendimento, que vem desligado; enquanto estiver desligado, nenhuma mensagem de contato sai para eles.

A tabela é a lista completa do que o serviço usa hoje. O código suporta ainda três integrações opcionais que a API não exige para subir e que esta implantação pode ou não ter ligado: captcha nos formulários públicos (Cloudflare Turnstile, que recebe o IP de quem preenche), armazenamento dos arquivos enviados e a fila que executa os trabalhos em segundo plano.

a definir quais dessas três estão ligadas nesta implantação e em que região ficam — enquanto isso não estiver confirmado, elas não entram na tabela acima, porque uma linha ali afirma que dados passam pelo fornecedor.

a definir se cada fornecedor desta tabela tem acordo de tratamento de dados assinado, e quais — o que existe hoje é a relação técnica; o instrumento contratual com cada um é ato da revisão jurídica.

Retenção é código neste serviço — uma rotina de limpeza roda os prazos, e os principais são estes:

Visitantes anônimos que nunca se identificaram expiram 30 dias após a última atividade. A fila interna de eventos elimina cada registro 48 horas após a publicação. Entregas de webhook concluídas são eliminadas após 30 dias. A trilha de auditoria da equipe é guardada por até 400 dias no banco — o plano define até onde a leitura alcança, nunca quanto tempo a trilha existe — e o próprio banco recusa apagar uma entrada dentro desse prazo. Sessões, códigos e tokens expirados são varridos continuamente.

Dois prazos ainda não são prazos, e é melhor dizer isso do que publicar um número que o código não pratica. Os eventos de produto são guardados em partições mensais que hoje só são criadas, nunca descartadas — na prática, ficam enquanto o ambiente existir — e eles sobrevivem à eliminação do contato que nomeiam, porque são história do produto e não um vínculo com a ficha: a definir por quantos meses os eventos de produto ficam disponíveis, o que é ao mesmo tempo uma decisão de retenção e um item de plano. As conversas de suporte e as respostas de pesquisa são guardadas enquanto a organização existir: a definir se existe prazo próprio para conversas encerradas e respostas antigas.

Ao encerrar uma organização, os dados são eliminados nesses mesmos prazos, exceto o que obrigação legal mandar manter.

Credenciais são armazenadas apenas como hash (SHA-256 para tokens, bcrypt para senhas); segredos que precisam ser lidos de volta são criptografados em repouso. Toda senha escolhida é verificada contra um corpus público de vazamentos por k-anonimato — apenas os cinco primeiros caracteres do SHA-1 saem do servidor, e nada derivado da senha toca disco ou log. O acesso administrativo da equipe é registrado numa trilha de auditoria que o banco de dados se recusa a alterar.

A LGPD garante ao titular confirmação, acesso, correção, anonimização, portabilidade e eliminação, entre outros (art. 18). O caminho depende do papel:

Se você tem conta no painel, os pedidos são exercidos diretamente conosco: a definir o endereço de contato para pedidos de titular e quem é o encarregado pelo tratamento (art. 41 da LGPD). Nenhum dos dois está no produto, então nenhum dos dois foi escrito aqui.

Se você é usuário do produto de um cliente nosso, o controlador dos seus dados é esse cliente, e é a ele que o pedido deve ser dirigido — somos operadora e agimos sob a instrução dele. Pedidos que chegarem diretamente a nós serão encaminhados ao controlador; o que as superfícies do serviço ainda não permitem que ele atenda sozinho, atendemos mediante solicitação dele.

A API e o banco de dados residem no Brasil (região GRU, São Paulo). Alguns subprocessadores da tabela acima processam dados fora do Brasil — hospedagem de front-end, envio de e-mail, monitoramento de erros e, quando a organização liga cada coisa, o gateway de pagamento e os modelos do atendimento automático. A tabela acima diz quais são e para quê, que é o fato que temos: a definir qual hipótese do art. 33 da LGPD ampara cada transferência e sob que instrumento — cláusulas-padrão, cláusulas específicas ou outra — fornecedor por fornecedor.

Alterações relevantes nesta política serão comunicadas ao e-mail das contas afetadas. Enquanto este documento for um rascunho, a versão publicada aqui é a vigente, com a ressalva marcada no topo da página, e a data da última revisão fica logo abaixo dela.

a definir o endereço para dúvidas sobre esta política, a razão social e o CNPJ da controladora — dados de registro da empresa, que o código não conhece.