Avaliação de impacto sobre a proteção de dados (art. 35 do GDPR) – Reprodução de sessões do MousePlayer

1. Por que esta avaliação é necessária

O art. 35(1) do GDPR exige uma avaliação de impacto quando um tipo de tratamento, em particular com novas tecnologias e considerando sua natureza, âmbito, contexto e finalidades, provavelmente resultar em alto risco para os direitos e as liberdades das pessoas físicas. O MousePlayer grava o comportamento dos visitantes de sites continuamente e por padrão: movimentos do ponteiro, cliques, rolagem, toques e mudanças de aba, juntamente com uma captura completa da página vista pelo visitante e cada alteração posterior nela, além do texto que o visitante digita em formulários. O material gravado é armazenado, reproduzido, pontuado e pode ser compartilhado. Isso não é um caso marginal do art. 35(1); é o seu núcleo.

Um ponto de enquadramento precisa ser formulado com precisão, em vez de repetido. O art. 35(3) lista três casos em que uma DPIA é necessária em particular, e nenhum dos três se enquadra perfeitamente. A alínea (a) abrange a avaliação sistemática e extensa baseada em tratamento automatizado que fundamenta decisões com efeitos jurídicos ou de importância semelhante — a avaliação existe aqui (veja o Risco R8), mas não foi encontrada nenhuma decisão desse tipo contra um visitante. A alínea (b) abrange o tratamento em larga escala de categorias especiais nos termos do art. 9 — não é pretendido aqui, embora categorias especiais cheguem à gravação por uma via não intencional (Risco R1), e os volumes medidos neste sistema não constituem larga escala. A alínea (c) abrange o monitoramento sistemático de uma área acessível ao público em larga escala, voltado à observação física, e não a um site. Citar a alínea (b) como fundamento para a reprodução de sessões seria incorreto, e uma citação incorreta é a primeira coisa que uma autoridade rejeita.

A via correta é o próprio art. 35(1), aplicado por meio dos nove critérios das diretrizes do WP29 sobre DPIA (WP248 rev.01, endossadas pelo EDPB). Dois critérios são geralmente considerados indicativos de alto risco. Este tratamento satisfaz seis ou sete.

• Avaliação ou pontuação — satisfeito. Cada sessão recebe engagement_score (0-255), session_quality e is_bot; no levantamento de agosto de 2026 existiam 4.043 linhas de características e 3.203 narrativas de sessão redigidas por máquina. Outras pontuações e derivações foram acrescentadas desde então (veja R8).
• Tomada de decisões automatizada com efeito jurídico ou semelhante — não constatada em relação aos visitantes. É constatada contra clientes e endereços IP (bloqueio automático, is_suspicious), que constituem outro grupo de titulares dos dados.
• Monitoramento sistemático — satisfeito na forma mais intensa. A gravação é contínua, metódica e invisível para a pessoa observada assim que o banner desaparece.
• Dados sensíveis ou de natureza altamente pessoal — satisfeito. Entradas em formulários, o texto completo da página conforme exibida para aquela pessoa e um registro minuto a minuto do que ela leu e dos pontos em que hesitou.
• Larga escala — não satisfeito segundo os números medidos deste sistema de desenvolvimento (levantamento de agosto de 2026: 706 sessões, 329 identificadores distintos de visitantes, 7 projetos, 4 contas. Situação em 16/10/2026: 8.648 sessões humanas com 7.363 identificadores distintos de visitantes desde 21/07/2026, dos quais 3.515 identificadores distintos nos últimos 30 dias, em 3 de 75 projetos criados; adicionalmente, 186.163 sessões marcadas como bots dos últimos 14 dias, excluídas quando seu prazo expira; 24 contas, 19 delas reconhecíveis como contas de teste). É satisfeito pela intenção de concepção, e a concepção não contém limite superior.
• Cruzamento ou combinação de conjuntos de dados — satisfeito. MousePlayer.setUserId() e a via automática 'uid' do dataLayer vinculam o identificador próprio do cliente à gravação; a exportação para BigQuery envia visitor_id, custom_user_id e ip_address ao repositório de dados do próprio cliente.
• Titulares dos dados vulneráveis — possivelmente satisfeito. O visitante não consegue ver o que foi gravado, não consegue verificá-lo e, em 92 casos no levantamento de agosto de 2026, não podia sequer ser associado aos seus próprios registros (situação em 16/10/2026: nenhuma sessão desse tipo; veja R9).
• Uso inovador — satisfeito. A reprodução de todo o DOM combinada com narrativas comportamentais geradas por máquina não é uma técnica consolidada e bem compreendida.
• Impedimento do exercício de um direito ou do uso de um serviço — satisfeito de duas formas restritas: o bloqueio automático de IP encerra o acesso posterior, e a lacuna de identificação (R9) torna o cumprimento dos arts. 15 e 17 tecnicamente impossível para parte dos dados armazenados.

O art. 35(4) obriga cada autoridade de controle a publicar uma lista de operações de tratamento para as quais a DPIA é obrigatória. A autoridade competente aqui é a UODO polonesa. a preencher: quais itens da lista atual da UODO nos termos do art. 35(4) se aplicam à reprodução de sessões e a data da versão da lista verificada

2. Papéis: quem tem essa obrigação e em relação a quê

O MousePlayer ocupa duas posições simultaneamente, e a resposta a quase todas as perguntas deste documento depende de qual delas está em questão. A distinção não é uma escolha de apresentação; está escrita no código. class/Server.class.php:416 declara no próprio código-fonte: "REGEL B ... Hier sind wir AUFTRAGSVERARBEITER" — aqui somos o operador.

Dados	Papel do MousePlayer	Controlador	Consequência
Visitantes dos sites dos clientes: gravações, conteúdo das páginas, entradas em formulários, identificadores, pontuações derivadas	Operador (art. 28)	O cliente do MousePlayer que opera o site	A obrigação do art. 35 cabe formalmente ao cliente. A obrigação do MousePlayer é prestar assistência nos termos do art. 28(3)(f).
Os próprios clientes do MousePlayer: contas, faturamento, suporte, logs de acesso ao portal, trilha de auditoria	Controlador (art. 24)	LW IT Solutions Company Lukas Wójcik	O MousePlayer deve realizar a avaliação do art. 35 para esse tratamento em nome próprio — embora essa parte, isoladamente, não a desencadeasse.

Isso produz um resultado que merece ser expresso claramente, porque com frequência é interpretado incorretamente em ambas as direções. O tratamento que exige uma DPIA é aquele em relação ao qual o MousePlayer não é o controlador. Um operador não pode realizar a avaliação do controlador por ele, decidir em seu nome sobre a necessidade nem consultar a autoridade de controle em seu lugar nos termos do art. 36. O que um operador pode e deve fazer é fornecer ao controlador tudo de que ele precisa — a descrição da alínea (a), os fatos medidos da alínea (c) e uma lista honesta da situação da alínea (d). Este documento é isso: a avaliação do próprio MousePlayer sobre suas próprias operações e a base factual de que o cliente precisa para a sua.

3. Encarregado da proteção de dados: o teste do art. 37

Nenhum encarregado da proteção de dados foi designado. O art. 37(1) vincula igualmente "o controlador e o operador", portanto a questão é do próprio MousePlayer e não pode ser repassada aos clientes. Os três casos legais:

Art. 37(1)	Teste	Resultado segundo os fatos medidos
(a)	Tratamento por uma autoridade ou órgão público	Não se aplica. LW IT Solutions Company é uma empresa privada.
(b)	As atividades principais exigem monitoramento regular e sistemático de titulares dos dados em larga escala	Atividade principal: sim, sem discussão — o monitoramento é o produto, e não uma função de apoio. Regular e sistemático: sim — contínuo, metódico, segundo um sistema previamente definido. Larga escala: não, segundo os números medidos (levantamento de agosto de 2026: 706 sessões, 329 identificadores, 4 contas; situação em 16/10/2026: 3.515 identificadores distintos de visitantes humanos em 30 dias; uma instância de desenvolvimento).
(c)	As atividades principais consistem no tratamento em larga escala de dados dos arts. 9 ou 10	Não por concepção. Ainda assim, categorias especiais entram no conteúdo de página armazenado pela via descrita no Risco R1. Isso é incidental, e não constitutivo, portanto o caso não está configurado hoje — mas passa a ser defensável assim que um cliente dos setores de saúde, jurídico ou financeiro é integrado.

O WP243 (endossado pelo EDPB) avalia "larga escala" pelo número de titulares dos dados, pelo volume e pela variedade dos dados, pela duração e pela abrangência geográfica. Três desses quatro fatores já estão no máximo aqui: a variedade é uma reconstrução completa da sessão da pessoa, a duração é contínua e a abrangência geográfica é a dos públicos dos clientes. Apenas o número de pessoas é pequeno. Para que o limite não seja percebido tarde demais, srv/cron_status.php conta, uma vez por dia desde 19/08/2026, os identificadores distintos de visitantes humanos dos últimos 30 dias (excluindo 'unknown' e sessões marcadas como bots), compara o número com o limite de 100000 usuários finais por mês e comunica por e-mail tanto sua ultrapassagem quanto o vencimento da revisão anual. Situação em 16/10/2026: 3.515.

Disso decorrem duas coisas, e ambas são recomendações, e não afirmações sobre a lei. Primeiro, registrar agora uma avaliação escrita do limite, com um número declarado de usuários finais monitorados a partir do qual a designação ocorre automaticamente e um intervalo fixo de revisão — para que a decisão seja documentada como tomada, e não apenas como ainda não tomada. Segundo, observar que o art. 37(4) permite que a legislação dos Estados-Membros exija a designação em outros casos. a preencher: confirmação jurídica sobre se a legislação polonesa, nos termos do art. 37(4), cria uma obrigação de designar além do art. 37(1). O limite e o intervalo de revisão estão decididos: mais de 100000 usuários finais observados por mês, pelo menos anualmente

O art. 35(2) exige que o controlador solicite a orientação do encarregado da proteção de dados, quando designado, ao realizar uma DPIA. Como nenhum encarregado foi designado, essa etapa não se aplica, e sua omissão não é uma falha. Aprovada por Lukas Wójcik, proprietário, em 17/08/2026. Não foi obtida orientação externa sobre proteção de dados. Revisada anualmente e a cada alteração do tratamento; as versões datadas são mantidas no controle de versões em ai/cms/.

4. Método, fontes e limites desta versão preliminar

Cada afirmação factual deste documento foi conferida em relação ao sistema em operação — código-fonte, esquema do banco de dados, contagens de linhas, lista de processos, valores de configuração e arquivos de log —, em vez de obtida de descrições de produto ou do que o software deveria fazer. Quando uma medição contradiz uma intenção, a medição é apresentada. Quando um fato não pôde ser determinado, um marcador ocupa seu lugar; nenhum número foi estimado e nenhum prazo de retenção foi inventado.

• O sistema medido é a instância de desenvolvimento (APP_ENV=dev). Vários números são, portanto, artefatos dos dados de teste e são identificados como tais — sobretudo os registros de consentimento, em que 671 de 706 sessões têm consent_source='testdata' com data e hora NULL, gravadas por ai/devdata/001_altsitzungen_markieren.sql (levantamento de agosto de 2026; situação em 16/10/2026: 566 de 8.648 sessões humanas).
• Algumas medições foram feitas com minutos de diferença e, por isso, apresentam pequenas variações (705 contra 706 sessões; 36.409 linhas de log contra 36.542 endereços verificados). Ambos os números são apresentados conforme medidos, sem conciliação posterior.
• Não havia acesso de nível root. Por isso, não foi possível verificar a configuração das jails do fail2ban, os crontabs de root e www-data nem a chegada do backup externo ao destino. Cada item é marcado como não verificado, em vez de presumido. Acréscimos posteriores: o operador do sistema realizou, entretanto, a transição do backup com direitos de root, e a chegada do backup externo ao destino está comprovada desde 11/08/2026, porque a execução diária a registra e verifica por conta própria — há registros de 11/08/2026 e 12/08/2026 (veja R5). Verificado novamente em 16/10/2026: o fail2ban executa nove jails, entre elas mp-nginx-429 para endereços que acionam repetidamente o limite de requisições do nginx. As execuções agendadas do MousePlayer estão listadas em /etc/cron.d/mouseplayer e passam por srv/cron_run.sh sob a conta dedicada mouseplayer-dev; os serviços dos workers também são executados sob essa conta. O backup diário ainda é iniciado pelo cron de root, e a execução diária de exclusão ainda ocorre dentro do processo db_worker.
• Os diretórios de fornecedores (Stripe SDK, Google Cloud SDK, PHPMailer, Symfony) não foram pesquisados em busca de endpoints de saída. O código próprio foi pesquisado exaustivamente quanto a curl_init, curl_exec, file_get_contents em http, fsockopen e stream_context_create, e quanto a todos os literais https.
• Um número desta avaliação — 92 sessões com visitor_id 'unknown' — foi adotado como medição estabelecida no levantamento de agosto de 2026, porque não pôde ser medido novamente na ocasião. Medido novamente em 16/10/2026: nenhuma sessão tem mais visitor_id 'unknown'. O código ainda pode gravar esse valor quando uma sessão é criada (srv/db_worker.php); portanto, R9 continua possível.

5. (a) Descrição sistemática das operações de tratamento e das finalidades

5.1 Como a gravação funciona

O cliente incorpora um arquivo JavaScript estático (www/mp.js) no seu site. Antes de qualquer gravação, duas barreiras precisam ser abertas. Primeiro, uma verificação de bots encerra o processo para navegadores automatizados. Depois dela está a máquina de estados de consentimento mpEinw, que permite a construção do rastreador somente com um sinal positivo de consentimento — de uma chamada da API do próprio cliente, do Google Consent Mode, de uma CMP compatível ou de uma string TCF. Qualquer outro resultado, incluindo ausência total de sinal, uma CMP que não carrega, um erro de script e uma origem desconhecida, resulta em nenhuma gravação. O princípio orientador está registrado nas próprias notas de trabalho do projeto e vale em todo o código: em caso de dúvida, não gravar.

Uma vez autorizado, o script abre um WebSocket criptografado (/mp_wss/) para o servidor de gravação. A criptografia TLS termina no nginx; o próprio servidor WebSocket (srv/server.php) escuta somente no endereço de loopback 127.0.0.1:8081 e recebe dali a conexão sem criptografia dentro da mesma máquina. O servidor aplica a barreira uma segunda vez, independentemente do navegador: class/Server.class.php:977-1004 admite apenas GRANTED ou GRANTED_LATE, ou uma isenção regional explícita, e fecha a conexão com o código 1008 em caso de revogação, país desconhecido ou qualquer situação pouco clara. Uma lista de exclusão de caminhos é executada antes disso, comparando somente o caminho, e não a URL completa. Se o WebSocket não puder ser estabelecido três vezes seguidas (um proxy ou firewall bloqueando o handshake), o script envia as mesmas mensagens por HTTPS POST para /mp_wst; esse endpoint não decide nada e as entrega ao mesmo processo do servidor, no qual passam pela mesma barreira (www/api/ws_tunnel.php, class/HttpTunnel.class.php). Uma captura de página maior que 1 MB é enviada pelo script por HTTPS POST para /mp_dom (www/api/dom_upload.php); esse endpoint verifica um token de acesso com prazo limitado assinado pelo servidor, mantém a captura no Redis por no máximo 120 segundos e não decide mais nada — ela é recuperada pela mesma conexão que já passou pelas barreiras. Além disso, /mp_wsfail conta as conexões WebSocket malsucedidas por projeto, sem identificador de visitante; o endereço IP só é usado ali como hash para desduplicação e expira após uma hora. Os eventos passam pela fila do Redis e são gravados no MariaDB por um worker de longa duração (srv/db_worker.php).

O que é armazenado não é um vídeo. É a própria página: uma cópia serializada do DOM no momento da visualização de página, mais cada alteração posterior nela, reproduzida depois em um iframe com as posições gravadas do ponteiro desenhadas por cima. Essa distinção importa para a avaliação de risco, porque significa que o material armazenado contém tudo o que a página continha — incluindo texto que o visitante nunca digitou e nunca viu como "dados".

5.2 Registro das operações de tratamento

Finalidade	Papel	Tabelas principais	Eliminação (situação em 23/09/2026)
Gravação de comportamento: movimentos, cliques, rolagem, toques, mudanças de aba	Operador	mouse_events (225.892 linhas, 322,6 MB), session_pageviews, visitor_sessions	Limpeza diária por plano, monitorada (veja R7)
Conteúdo da página: captura do DOM e alterações ao vivo, para reproduzir a página conforme vista	Operador	session_pageviews.payload_blob (1.848 linhas, 162,9 MB), mouse_events.target_selector para alterações (66.153 linhas)	A mesma limpeza
Entradas em formulários, caractere por caractere, mascaradas conforme o nível configurado	Operador	mouse_events.target_selector para eventos de entrada (599 linhas)	A mesma limpeza; para as 173 linhas legadas, veja R2
Reconhecimento do mesmo visitante entre sessões e visualizações de página	Operador	visitor_sessions.visitor_id / custom_user_id, visitor_nicknames (329 linhas)	visitor_nicknames: com a última sessão do visitante
Determinação da rede e da localização aproximada	Operador	visitor_sessions.ip_address, country, city, asn_number, asn_org; ip_lifetime_stats (446 linhas)	ip_lifetime_stats: 365 dias
Prova do consentimento e das suas alterações (art. 7(1))	Operador, mantida para o ônus da prova do cliente	consent_events (120 linhas), visitor_sessions.consent_*	730 dias a partir de the withdrawal; mantida deliberadamente até lá, pois é a prova de que o consentimento foi revogado
Eventos personalizados, sinais de frustração, erros de JavaScript	Operador	session_custom_events (823), session_custom_event_params (1.264)	A mesma limpeza
Características derivadas e narrativas de sessão redigidas por máquina	Operador	ai_session_features (4.043), ai_timelines (3.203 linhas, 5,5 MB)	Com a sessão, na mesma cadeia de exclusão
Operação das contas dos próprios clientes do MousePlayer	Controlador	users (4), user_ip_history (5), workspace_users, workspace_invites	Com a conta; contas inativas após 24 meses e um aviso entregue
Registro de acesso, segurança e alterações do portal	Controlador	mouseplayer_logs (36.409), security_access_logs (1.354), audit_logs (666), banned_ips	60 dias / 72 horas / 60 dias / na expiração
Solicitações de suporte	Controlador	support_requests	730 dias
Colaboração em uma reprodução: comentários e links de compartilhamento	Misto — controlador em relação ao autor, operador em relação ao conteúdo gravado	session_comments (12), session_shares (9)	Comentários com a sessão; links de compartilhamento 90 dias após sua expiração
Aceitação pelo cliente das regras regionais de gravação	Controlador	consent_region_acceptances (0 linhas)	730 dias

5.3 Base legal

Para tudo no caminho da gravação, a base é o consentimento, e a fundamentação está documentada na migração que introduziu a arquitetura de consentimento (ai/migrations/018_consent.sql): a gravação é observação comportamental nos termos do Considerando 24 e acesso ao equipamento terminal nos termos da implementação polonesa das regras de ePrivacy; exige consentimento, e o interesse legítimo não a sustenta. Todos os 7 projetos estão definidos como consent_mode='required'. O interruptor geral site_settings.consent_gate_active está ativado. Essa análise é correta e excepcionalmente bem documentada; não é atenuada em nenhum ponto do código.

Para quatro operações, o código não indica base alguma: a operação das próprias contas do MousePlayer, os logs de acesso e segurança do portal, as solicitações de suporte e os comentários de reprodução. São as operações no papel de controlador. Interesse legítimo (art. 6(1)(f)) e execução do contrato (art. 6(1)(b)) são os candidatos óbvios, mas um candidato não é uma determinação, e o art. 6(1)(f) exige um teste de ponderação documentado. Respondido em 17/08/2026: dados de conta e faturamento, art. 6(1)(b); para a retenção de faturas, (c) (cinco anos a partir do final do ano civil em que venceu o prazo de pagamento do tributo). Logs de acesso, segurança e alterações, bem como reCAPTCHA e logs do servidor: (f), finalidade de defesa contra abusos e responsabilização; os testes de ponderação estão apresentados no registro, em B.2 e B.5. A demonstração da página inicial: consentimento, (a). Solicitações de suporte: (b) quando quem pergunta é um Cliente e a solicitação diz respeito ao contrato; caso contrário, (f) (registro, B.3). Comentários de reprodução e links de compartilhamento são tratados pelo MousePlayer segundo instruções do Cliente (registro, A.9).

5.4 Destinatários e transferências para países terceiros

No caminho da gravação, não foi encontrada nenhuma chamada de saída para terceiros. A geolocalização usa arquivos locais do banco de dados MaxMind, em vez de um serviço web — uma decisão deliberada de concepção registrada no código, para que nenhum terceiro seja contatado antes de existir consentimento. Fontes, bandeiras e scripts são servidos localmente. É um resultado realmente bom e deveria ser apresentado como tal.

Destinatário	O que é transferido	Situação atual
O cliente	Tudo o que foi gravado, por meio do painel e dos três endpoints do player	Ativo — esta é a finalidade
Qualquer pessoa que tenha um link de compartilhamento, sem nenhum login	Uma reprodução completa de uma sessão	Ativo; situação em 16/10/2026: 5 links de compartilhamento criados; cada acesso é registrado com horário, endereço IP e identificador de navegador (share_views)
Google Cloud Storage, Varsóvia (até 05/09/2026: Google Drive, EUA)	Uma cópia diária completa de cada banco de dados e de toda a árvore web. Até 11/08/2026 sem criptografia. Desde 11/08/2026 criptografada no nosso próprio servidor antes da transferência	Ativo diariamente. A transferência em texto claro terminou em 11/08/2026; os dados legados sem criptografia no Google foram excluídos em 12/08/2026. Desde 05/09/2026, conta empresarial, região europe-central2 (Varsóvia), abrangida pelo Google Cloud Data Processing Addendum; as cópias na antiga conta do Drive foram excluídas em 06/09/2026 — veja o Risco R5
Stripe (EUA / Irlanda)	E-mail, nome, endereço de faturamento e dados de pagamento do cliente — nenhum dado de visitante	Somente chaves de teste; chaves de produção vazias
Namecheap Private Email (envio de e-mails por SMTP)	Endereço do destinatário, assunto e conteúdo dos e-mails enviados aos clientes e ao operador do sistema, como confirmação de conta, redefinição de senha, convites, avisos de login em novos dispositivos, aviso antes da exclusão de contas inativas, avisos de alteração dos documentos contratuais, relatório semanal, respostas de suporte, avisos sobre marcações e anomalias e alertas do sistema	Ativo desde 23/09/2026, remetente office@mouseplayer.com; listado entre os suboperadores
Telegram (fora da UE)	Até 11/08/2026: solicitações de suporte na íntegra, incluindo o endereço IP não truncado e o texto completo da mensagem. Desde 11/08/2026: somente uma frase fixa — "MousePlayer: es liegt eine neue Supportanfrage vor." — nenhuma variável, nenhum número de caso, nenhum link; nenhum dado pessoal sai mais do sistema por este canal	Canal ainda ativo (tokens definidos em .env), mas, desde 11/08/2026, não é um destinatário de dados pessoais e, portanto, não é um operador
Google reCAPTCHA (EUA)	Páginas de login, cadastro, suporte e faturamento	Desativado neste sistema (APP_ENV=dev); ativo em produção
Google BigQuery (projeto do próprio cliente)	session_id, visitor_id, custom_user_id, ip_address, country, referrer, agente de usuário, tamanho da tela, datas e horários, tipo de dispositivo	Inativo: desativado em todos os 7 projetos, e o processo não está em execução
URL de webhook definida pelo cliente (destino sem restrições)	Dados do evento mais um link direto do player para a sessão	Inativo: desativado em todos os 7 projetos, processo despachante em execução

5.5 Retenção, conforme medida, e não conforme pretendida

Existe uma rotina automática de exclusão, e ela é executada. Fica dentro do processo worker permanentemente em execução (srv/db_worker.php), sendo executada no início do processo e, depois, uma vez por dia civil; o mesmo processo limpa os prazos das sessões marcadas como bots a cada hora. A execução de exclusão não tem uma entrada própria no cron. Sua ausência, porém, já não passa despercebida: o worker registra seu resultado, e srv/cron_status.php — outro processo — o avalia, comunica por e-mail uma execução ocorrida há mais de 48 horas e registra a falha como entrada nos Logs Urgentes da área administrativa. As outras execuções agendadas estão listadas em /etc/cron.d/mouseplayer; as falhas e as pausas excessivamente longas dessas execuções também são comunicadas pelo mesmo processo de status (situação em 16/10/2026).

No levantamento de agosto de 2026, a rotina ainda não havia excluído nada: todos os projetos pertenciam a um proprietário no nível enterprise com 365 dias de retenção, e a sessão mais antiga tinha 20 dias. Em 16/10/2026, ela comprovadamente exclui: os prazos dos logs e das derivações produzem efeitos (a entrada mais antiga em audit_logs está no prazo de 60 dias), sessões marcadas como bots são excluídas após 14 dias, e suas gravações são esvaziadas após o próprio prazo (prazo em dias: 1). O prazo do nível para sessões humanas ainda não alcançou nenhuma sessão, porque os dois projetos com tráfego genuíno de visitantes ainda pertencem a um proprietário no nível enterprise com 365 dias, e suas sessões mais antigas datam de 21/07/2026.

6. (b) Avaliação da necessidade e da proporcionalidade

A necessidade e a proporcionalidade são avaliadas em relação à finalidade declarada: permitir que o operador de um site compreenda como os visitantes o usam, onde encontram dificuldades e por que o abandonam. Essa finalidade é legítima, e a técnica geral é capaz de atendê-la. A pergunta do art. 35(7)(b) é mais restrita e mais difícil: é este tratamento, com este nível de detalhe, necessário para essa finalidade — e a intrusão é proporcional ao benefício?

Componente	Necessário para a finalidade?	Proporcional conforme implementado?
Movimentos do ponteiro, cliques, rolagem, toques	Sim. Esse é o sinal a que se refere a finalidade.	Sim.
Estrutura e disposição da página visitada	Sim. As coordenadas não têm sentido sem a disposição à qual se referem.	Sim, em princípio.
Todo o conteúdo textual da página, literalmente	Não — não em geral. Compreender onde um visitante encontrou dificuldades exige a estrutura e os rótulos, e não o conteúdo pessoal exibido nela.	Não, conforme implementado atualmente. O mascaramento precisa ser solicitado por elemento; o padrão é armazenar tudo. Veja R1.
Entradas em formulários	Discutível. Saber que um campo foi abandonado é valioso; saber o que foi digitado nele raramente é necessário.	Em parte. O patamar mínimo de mascaramento é forte, e todos os projetos usam o nível mais rigoroso — mas a concepção ainda permite níveis mais fracos, e a identificação dessa configuração está invertida (o nível 0 é o mais rigoroso, a dica do painel diz o contrário).
Estado de caixas de seleção e botões de opção	Discutível.	Não. Eles nunca são mascarados, em nenhum nível — e uma caixa de seleção pode conter uma declaração de saúde, uma filiação política ou um consentimento para uma finalidade sensível.
Reconhecimento entre sessões	Sim para análise de visitantes recorrentes; não para a finalidade principal.	Condicionalmente. O reconhecimento pseudônimo é proporcional; o identificador fornecido pelo cliente é o ponto em que a proporcionalidade termina. Veja R6.
Endereço IP	Sim para atribuição de localização aproximada (país; a cidade somente a partir do endereço já truncado) e defesa contra abusos.	Sim, prospectivamente: o endereço é truncado imediatamente após a leitura, antes de qualquer consumidor desse dado vê-lo. Os dados legados no caminho da gravação foram limpos em 17/08/2026; veja R3.
Pontuação e narrativas de sessão	Não. São facilidades para o fluxo de revisão do cliente.	Questionável, e a parte menos examinada do sistema — nenhuma base legal é indicada para ela em qualquer lugar do código.
Cópia completa externa (para um fornecedor de país terceiro até 05/09/2026)	Um backup externo, sim — atende à disponibilidade (art. 32(1)(c)). Seu âmbito vai além deste serviço: contém todos os bancos de dados da máquina.	Desde 05/09/2026, sim, com ressalva quanto ao âmbito. A cópia é criptografada antes da transferência e mantida em uma região europeia sob um acordo nos termos do art. 28. Até 05/09/2026, não: nenhum contrato estabelecido, e sem criptografia até 11/08/2026. Veja R5.

Quanto à minimização dos dados (art. 5(1)(c)), o sistema mostra duas faces opostas. A minimização deliberada é visível em vários pontos e bem fundamentada no código: os nomes dos campos são classificados, em vez de transmitidos, porque o nome bruto de um campo em uma loja costuma ser descritivo o suficiente para identificar a pessoa; a string TCF só é armazenada como hash SHA-256; o payload de reprodução é deliberadamente excluído da API pública. Em oposição a isso está a decisão central de concepção de armazenar a página inteira literalmente por padrão, o contrário da minimização, sem compensação por nenhuma das medidas acima.

Quanto à limitação da conservação (art. 5(1)(e)), a avaliação foi inequívoca e desfavorável até 17/08/2026. Treze tabelas com dados pessoais não tinham prazo de eliminação de espécie alguma, incluindo as duas que contêm o material mais legível: ai_timelines, que contém cada sessão convertida em prosa legível, e visitor_nicknames. A rotina que existia nunca havia sido executada sobre dados reais. Um conceito de retenção que nunca excluiu um registro é um plano, e não uma salvaguarda. Desde 17/08/2026 todas as treze tabelas têm um prazo, a limpeza comprovadamente exclui, e sua ausência é comunicada (veja R7).

7. (c) Avaliação dos riscos para os direitos e as liberdades dos titulares dos dados

Os riscos são avaliados para o titular dos dados, e não para a empresa. A probabilidade é classificada como Remota, Possível, Provável ou Materializada — a última significa que o evento não é uma previsão, mas um estado atual e medido dos dados. A gravidade é classificada como Limitada, Significativa, Grave ou Muito grave, segundo o que a pessoa afetada pode perder: não constrangimento, mas a exposição de características de saúde, financeiras ou outras protegidas, a perda de controle sobre a identificação e a impossibilidade de exercer um direito.

ID	Risco	Probabilidade	Gravidade	Nível
R1	Categorias especiais de dados no conteúdo das páginas gravadas	Provável	Muito grave	Muito alto
R2	Entradas de formulários sem mascaramento nos dados legados (173 linhas) — classificação do levantamento; as linhas foram excluídas em 17/08/2026, e está pendente uma reclassificação pelo controlador	Materializada	Significativa	Alto
R3	Endereços IP não truncados nos dados legados e nos logs do portal — classificação do levantamento; os dados legados foram truncados em 17/08/2026, e os logs do portal têm prazos desde então; uma reclassificação está pendente	Materializada	Significativa	Alto
R4	Links de compartilhamento expõem uma reprodução completa sem nenhum login	Possível	Grave	Alto
R5	Cópia diária completa externa — sem criptografia até 11/08/2026, criptografada no nosso próprio servidor antes da transferência desde 11/08/2026; os dados legados sem criptografia foram excluídos no fornecedor em 12/08/2026. Desde 05/09/2026, a cópia é mantida em um bucket do Google Cloud Storage na região europe-central2 (Varsóvia), sob uma conta empresarial, abrangida pelo Google Cloud Data Processing Addendum; as cópias na antiga conta do Drive foram excluídas em 06/09/2026. O âmbito permanece inalterado. Se ambos os arquivos de chaves forem perdidos, o backup será irrecuperável; cópias impressas são mantidas em um cofre	Remota (reclassificada em 17/09/2026). Antes disso: transferência em texto claro até 11/08/2026, transferência sem base legal estabelecida até 05/09/2026 — ambas materializadas e encerradas	Muito grave	Médio — reclassificado em 17/09/2026; muito alto até 05/09/2026. A condição da avaliação (remoção dos scripts antigos) foi cumprida em 16/10/2026; a reclassificação de R5 cabe ao controlador
R6	Reconhecimento entre sessões e cruzamento com os próprios registros do cliente	Provável	Grave	Alto
R7	Ausência de prazo de eliminação para treze tabelas; corrigida desde 17/08/2026, a limpeza ocorre diariamente e é monitorada	Remota (reclassificada em 23/09/2026). Até 17/08/2026: materializada	Grave	Baixo — reclassificado em 23/09/2026; alto até 17/08/2026
R8	Pontuação e classificação automatizadas de cada sessão	Provável	Significativa	Médio
R9	92 sessões inacessíveis por qualquer identificador; nenhum caminho da pessoa ao registro — classificação do levantamento; situação em 16/10/2026: nenhuma sessão desse tipo, consulta por autoatendimento desde 17/08/2026; uma reclassificação está pendente	Materializada	Significativa	Alto
R10	Sem criptografia em repouso, sem TLS para o banco de dados, Redis sem proteção de acesso (até 16/08/2026; acesso restrito desde então, banco de dados e Redis também acessíveis pela rede local — uma reclassificação está pendente)	Possível	Muito grave	Médio-alto
R11	Nenhum registro de quem visualizou qual gravação	Materializada	Significativa	Médio-alto
R12	Qualidade das provas de consentimento; adaptadores CMP não testados	Materializada (dados de desenvolvimento)	Grave	Médio
R13	Solicitações de suporte para o Telegram incluindo o IP não truncado — até 11/08/2026; desde 11/08/2026, é enviado apenas um texto fixo de aviso sem nenhuma variável. O que permanece é o armazenamento local da solicitação com endereço de e-mail e IP em support_requests; desde 17/08/2026, com prazo de 730 dias (veja R7)	Transferência: corrigida em 11/08/2026. Armazenamento local: materializado	Significativa — até 11/08/2026 para a transferência; desde então, somente para o armazenamento local	Corrigido em 11/08/2026 quanto à transferência; o armazenamento local remanescente é acompanhado em R7 (classificado ali como baixo desde 23/09/2026)
R14	Saída para destinatários escolhidos pelo próprio controlador — uma solicitação de eliminação não chega a eles	Possível (depende de o controlador ativar uma ponte; nos dados atuais: nenhuma ativada)	Substancial	Médio

R1 — Categorias especiais de dados no conteúdo das páginas gravadas

Este é o risco mais grave do sistema e o menos visível, porque nada nele parece uma falha. O mascaramento da captura da página atua somente dentro de regiões marcadas (www/mp.js:3934-3970): dentro de um elemento com data-mp-mask ou a classe .mp-masked, cada caractere que não seja espaço em branco é substituído, e os atributos fora de uma lista de preservação são definidos como [FILTERED]. Todo o restante é armazenado literalmente. O mascaramento é, portanto, uma anotação opcional que o cliente precisa aplicar, elemento por elemento, a uma página que talvez não controle integralmente.

A consequência é que a proteção abrange o que o visitante digita e não o que a página lhe devolve. Uma página de confirmação de um consultório médico exibindo uma consulta com uma especialidade identificada; um carrinho de farmácia; uma cotação de seguro listando doenças preexistentes; um extrato bancário; um resumo de atendimento de assistência jurídica — tudo isso é saída da página, fora de qualquer campo de entrada, e tudo chega a payload_blob sem alteração. Isso não é hipotético: 1.848 linhas estão preenchidas, com média de 90,3 kB, e uma amostra confirma que o valor armazenado começa com o documento <html> completo. O mesmo vale para cada alteração posterior da página, serializada como fragmentos HTML em mouse_events.target_selector ao longo de 66.153 linhas de alterações.

Probabilidade — Provável. O mecanismo de proteção exige ação deliberada de alguém que não é a pessoa em risco, armazena tudo por padrão e não possui detecção, aviso ou relatório que informe ao cliente que conteúdo pessoal sem mascaramento está sendo capturado. Nada no sistema faz amostragem do payload armazenado para procurar padrões que indicariam isso. A probabilidade de pelo menos uma página de cliente exibir dados de categorias especiais se aproxima de um em qualquer período significativo de operação.

Gravidade — Muito grave. Os dados do art. 9(1) recebem a proteção mais elevada, e nenhuma das exceções do art. 9(2) está disponível aqui. O consentimento do visitante para a gravação de sessões não é um consentimento explícito para o tratamento de dados de saúde, nem poderia sê-lo — nem o visitante, nem o cliente, nem o MousePlayer sabem, naquele momento, que tais dados estão sendo capturados. O material é armazenado literalmente, pode ser integralmente reproduzido e exportado, está incluído na cópia diária externa (R5) e pode ser entregue a um terceiro não identificado por um link de compartilhamento (R4).

R2 — Entradas de formulários sem mascaramento nos dados legados

173 linhas em mouse_events contêm valores de entrada de formulários em texto claro. Foram localizadas pela correspondência de um padrão na estrutura armazenada ('"v":"' seguido por um caractere diferente do caractere de mascaramento), situam-se no intervalo de 21/07/2026 a 27/07/2026 e incluem entradas como o nome completo de uma pessoa. As linhas gravadas em 10/08/2026 estão mascaradas, portanto o comportamento no sistema em operação agora é correto: todos os 7 projetos usam smart_masking=0, que, apesar da sua identificação, é a configuração mais rigorosa e substitui cada caractere de cada campo; um patamar mínimo incondicional substitui senhas e dados de pagamento em qualquer configuração.

Probabilidade — Materializada. Isso não é uma previsão. As linhas existem agora e, como mouse_events só é limpo pela rotina do nível — que não exclui nada antes de um registro completar 365 dias e nunca foi executada —, permanecerão pelo menos até julho de 2027, salvo remoção manual. A probabilidade prospectiva de recorrência é baixa.

Gravidade — Significativa. As amostras conhecidas são inofensivas, mas o conteúdo das linhas restantes não foi classificado, e as categorias de campos reconhecidas pelo sistema incluem e-mail, telefone, pagamento, endereço e nome. Não foi determinado se o patamar mínimo incondicional para senhas e pagamentos já existia naquele intervalo. Concluído em 17/08/2026: as linhas foram excluídas sem revisão (decisão do controlador). Na medição, eram 174 linhas de 18 sessões de um único projeto, de 21/07/2026 a 06/08/2026; após a execução, restam 0. A própria lacuna já havia sido fechada: desde 07/08/2026, nenhum valor contém texto claro. Quase um segundo erro na medição: o caractere de mascaramento é o asterisco, e não o marcador de lista — um padrão baseado no marcador encontrou 862 linhas com ocorrência mais recente de hoje e, assim, parecia um vazamento em andamento. Uma exclusão baseada nesse número teria levado junto 688 linhas corretamente mascaradas.

R3 — Endereços IP não truncados nos dados legados e nos logs do portal

O truncamento de IP no caminho da gravação está implementado corretamente e no lugar certo: class/Server.class.php:432-435 substitui o último octeto IPv4 ou o último grupo IPv6 imediatamente após a leitura do endereço, antes de existir qualquer consumidor do valor. Sua eficácia foi verificada para dados novos — toda sessão gravada desde 07/08/2026 está truncada. Ele não é retroativo, e não existe rotina de preenchimento retroativo; em vez disso, os dados legados foram limpos manualmente, uma única vez, em 17/08/2026 — veja a nota de situação abaixo da tabela.

Tabela	Endereços não truncados (situação na avaliação, antes de 17/08/2026)	Prazo de eliminação
visitor_sessions	236 de 705, datados de 21/07/2026 a 07/08/2026, endereços públicos completos	Limpeza do nível — nunca executada
ip_lifetime_stats	291 de 446	Nenhum, em lugar algum
mouseplayer_logs	Nenhum dos 36.542 endereços verificados estava truncado	60 dias
audit_logs	Todas as 666 linhas	Nenhum
user_ip_history	Todas as 5 linhas	Nenhum
security_access_logs	1.004 de 1.354	72 horas
support_requests	Todos, e encaminhados adiante — veja R13	Nenhum
Log de acesso do Apache	Todos	14 rotações diárias

Probabilidade — Materializada. Gravidade — Significativa. Um endereço IP isolado representa uma exposição limitada. Em visitor_sessions, ele não está isolado: fica na mesma linha que a gravação, associando uma identidade de rede e, por meio dela, uma pessoa a uma reprodução completa do comportamento dessa pessoa — incluindo tudo o que R1 captura. Os logs do portal são menos críticos, mas muito maiores, e constituem o tratamento no papel de controlador, no qual o MousePlayer responde diretamente pela escolha.

Concluído em 17/08/2026: os endereços legados em audit_logs (681) e user_ip_history (7) foram truncados retroativamente, no mesmo formato que o gravador já usa; restam 0. Os prazos futuros estão em vigor desde o mesmo dia. (decisão do controlador, 17/08/2026)

Situação em 17/08/2026. Os dados legados no caminho da gravação estão resolvidos: na medição, 267 de 267 endereços em ip_lifetime_stats foram truncados e 881 de 901 em visitor_sessions; os 20 restantes contêm 0.0.0.0 e vêm dos dados de teste de análise de formulários, portanto não são endereços de visitantes. Nos logs do portal, o endereço completo permanece — deliberadamente, e desde 17/08/2026 com um prazo declarado: mouseplayer_logs 60 dias, security_access_logs 72 horas, audit_logs 60 dias, user_ip_history 90 dias a partir da última vez em que um endereço foi visto (desde 24/09/2026), support_requests 730 dias. A razão pela qual o endereço completo é necessário para solicitações de suporte está apresentada no registro do art. 30, em B.3.

R4 — Links de compartilhamento expõem uma reprodução completa sem nenhum login

Uma regra de reescrita mapeia /s/<40 caracteres hexadecimais> diretamente para o player. O token é toda a barreira, e a concepção reconhece isso com honestidade: o token tem 20 bytes de random_bytes (160 bits, não adivinhável), os identificadores de canal e sessão vêm exclusivamente do token, e não da requisição, a string de consulta restante é substituída em vez de ignorada, o papel permanece NULL para que a exclusão e um novo compartilhamento sejam impossíveis no servidor, todos os três endpoints do player ficam restritos à sessão do token, e tokens inventados, expirados e revogados produzem uma resposta idêntica, para que tentativas de sondagem não revelem nada. A duração padrão é de 7 dias, mínimo de 1, máximo de 90; existe revogação. É um mecanismo cuidadosamente construído.

A exposição residual não é criptográfica, mas humana, e dois detalhes de implementação a ampliam. Primeiro, a página que mostra a gravação por um link de compartilhamento (player.php em modo de compartilhamento) contém os cabeçalhos Referrer-Policy: no-referrer e Cache-Control: no-store, mas não o cabeçalho X-Robots-Tag; noindex aparece apenas em www/share.php, que agora é somente a página de erro, e robots.txt permite tudo (verificado em 16/10/2026). Segundo, desde 17/08/2026, o sistema registra cada acesso a um link de compartilhamento — horário, endereço IP não truncado e identificador de navegador em share_views (veja também R11) —, mas não é possível determinar a pessoa por trás do acesso a partir disso.

Probabilidade — Possível. O token não será descoberto por força bruta. Será encaminhado — colado em um ticket, uma conversa em grupo, uma troca de e-mails que ganha outro destinatário — e poderá vazar por um cabeçalho Referer. Gravidade — Grave: um link expõe uma sessão inteira a um público ilimitado e não identificado, incluindo tudo o que R1 e R2 abrangem; depois, só é possível determinar o endereço e o navegador de onde houve acesso (share_views), e não quem viu a sessão. Uma questão relacionada está registrada como pendente nas próprias notas do projeto e continua não verificada: medido em 17/08/2026: o limite de visualizadores não é contornado pelos links de compartilhamento — ele simplesmente não se aplica a eles. Os visualizadores ao vivo são contados pelo sinalizador IS_LIVE_VIEWER na conexão WebSocket (class/Server.class.php, zaehleLiveViewers). www/player.php não contém nenhum código WebSocket; o player apenas reproduz. Um link de compartilhamento leva ao player, e não à visualização ao vivo. O que é realmente ilimitado é outra coisa: quantas pessoas abrem o mesmo link simultaneamente. Não existe limite para isso e, diferentemente da visualização ao vivo, também não existe contador. Desde 17/08/2026, pelo menos cada acesso é registrado (share_views, registro B.6), permitindo estabelecer posteriormente quantas vezes e de onde um link foi usado.

R5 — Cópia diária completa externa (para o Google Drive até 05/09/2026, desde então para o Google Cloud Storage em Varsóvia; transferida criptografada desde 11/08/2026; dados legados excluídos em 12/08/2026)

Este risco não está presente na base factual técnica; foi estabelecido a partir do próprio arquivo de pendências do projeto e está documentado ali em detalhe. Até 11/08/2026 um script anterior de backup era executado pelo cron de root às 02:00 todos os dias. Ele executava mysqldump em todos os bancos de dados e compactava com tar toda a árvore web, depois enviava o resultado por rclone para gdrive:backups/rpi-ls5/daily — sem criptografia em qualquer etapa. Localmente, a saída está confirmada em 653 MB de banco de dados e 678 MB de arquivos por dia. Desde 11/08/2026 a linha do cron foi alterada: a execução diária é um novo script de backup mantido no projeto, que captura o mesmo âmbito, mas o criptografa no nosso próprio servidor antes da transferência (rclone crypt) e grava em uma pasta de destino própria e separada; está agendado para 03:00. Os nomes dos arquivos e diretórios também são criptografados, portanto o que fica no fornecedor são blocos sem significado. A execução de 11/08/2026 foi iniciada manualmente e chegou ao destino (733 MB de banco de dados, 678 MB de arquivos); a execução de 12/08/2026 foi concluída conforme o agendamento às 03:00. Ambas estão registradas em log, e a verificação no destino encontrou ali o dump do banco de dados com a mesma contagem de bytes em ambas as ocasiões.

O que sai da máquina, portanto, não é um backup de gravações de sessões. É uma cópia completa de cada banco de dados e de cada sistema no host — incluindo as gravações com suas capturas de DOM, as 173 entradas de formulários em texto claro, os 236 endereços não truncados e cada arquivo .env com seus segredos de produção. O âmbito permanece inalterado; a criptografia não faz nada a esse respeito. O que mudou é a legibilidade no fornecedor: até 11/08/2026 não existia camada de criptografia antes do envio, e o texto claro chegava como texto claro; desde 11/08/2026 a criptografia ocorre no nosso próprio servidor antes de qualquer saída, e as chaves ficam em dois arquivos com modo 600 nesse mesmo servidor — o Google não as possui. Os dados legados não estavam abrangidos por isso: o novo script limpa somente sua própria pasta de destino, e a pasta anterior mantinha cópias semanais por até 364 dias. Ela foi excluída em 12/08/2026; portanto, cópias completas sem criptografia anteriores a 11/08/2026 não estão mais no fornecedor.

• A transferência é real e diária. Até 11/08/2026 não estava verificado se ela chegava ao destino: a execução usava a configuração rclone de root, o script não registrava nada em log, e o cron descartava sua saída. Desde 11/08/2026 a execução grava um log e verifica por conta própria após a transferência se o dump do banco de dados está no destino com a contagem de bytes esperada; há registros de ambos os pontos em 11/08/2026 (manual) e 12/08/2026 (agendada, às 03:00), cada qual com verificação aprovada. Portanto, há comprovação da operação diária, e não somente da primeira tentativa. Isso não resolve o risco de disponibilidade, mas o desloca: se ambos os arquivos de chaves forem perdidos, todo o backup externo será irrecuperável. Uma medida que elimina a legibilidade no fornecedor cria, assim, uma nova dependência da custódia das chaves; fora desta máquina, segundo o controlador, elas são mantidas impressas em um cofre (seção 8.3). O operador do sistema testou a descriptografia — essa é a declaração dele, e não uma medição realizada por este documento.
• Até 05/09/2026, nenhum instrumento de transferência estava estabelecido. A cópia era mantida no Google Drive sob uma conta privada (respondido em 17/08/2026), sem possibilidade de contratar uma região europeia de dados e sem acordo com operador. Desde 05/09/2026, é mantida em um bucket do Google Cloud Storage na região europe-central2 (Varsóvia), sob uma conta empresarial, e é abrangida pelo Google Cloud Data Processing Addendum; as cópias na conta do Drive foram excluídas em 06/09/2026.
• O script antigo constituía uma elevação de privilégios. Até 11/08/2026 era propriedade de root, executado pelo cron de root, e seu modo de arquivo era 777: qualquer pessoa com a conta SSH pi tinha acesso root às 02:00. Desde 11/08/2026 a execução diária já não passa por esse script; a transferência para o Google Drive foi removida dele em 09/09/2026. Os scripts antigos de backup foram removidos em 16/10/2026. A reclassificação de R5 cabe ao controlador.
• Até 05/09/2026, a cópia estava fora de qualquer instrução do cliente. O art. 28(3)(a) exige que o operador atue somente segundo instruções documentadas; uma cópia diária das gravações dos visitantes do cliente para um serviço de nuvem de consumo dos EUA não era abrangida por nenhuma instrução registrada. Desde então, a seção 9 do acordo de tratamento de dados e a lista de suboperadores identificam o backup no Google Cloud Storage.

Superado desde 05/09/2026 (veja acima); mantido aqui como histórico. Respondido em 17/08/2026: conta privada. Portanto, não é possível contratar uma região europeia de dados, e não existe acordo de tratamento de dados — para uma conta privada do Google, os termos de tratamento de dados não estão disponíveis. Decisão do controlador: o backup permanece ali por enquanto. Testes de restauração mensais a partir de agora. Os dois arquivos de chaves são mantidos impressos em um cofre acessível somente ao controlador (declaração do controlador, 17/08/2026); portanto, sobrevivem à perda desta máquina.

Medido em 17/09/2026: o último backup bem-sucedido foi executado às 03:30 naquele dia e aprovado na verificação no destino. O exercício de restauração está planejado mensalmente; foi aprovado antes de as cópias do Drive serem excluídas em 06/09/2026, e nenhum monitor lembra o próximo. Em 07/10/2026, também foi realizada uma restauração completa dos dados do backup na nuvem em um ambiente separado (cerca de 70 minutos; amostras do arquivo e do banco de dados sem erros). Desde 06/10/2026, o backup diário também contém o arquivo de gravações (/mnt/mouseplayer-dev-archive); ele fica no mesmo disco do sistema. Salvo indicação contrária ali, a lista acima descreve a situação anterior a 05/09/2026.

R6 — Reconhecimento entre sessões e cruzamento com os próprios registros do cliente

Um identificador pseudônimo é criado e mantido no localStorage do visitante como mp_visitor_id. Isoladamente, isso é comum e proporcional para a análise de visitantes recorrentes. Dois outros mecanismos mudam seu caráter. MousePlayer.setUserId() permite que o cliente vincule à gravação seu próprio identificador — um nome de login, um número de cliente —, armazenado em visitor_sessions.custom_user_id com um índice dedicado; e o mesmo valor é obtido automaticamente de um caminho do dataLayer chamado 'uid', sem qualquer ação deliberada do cliente. Quando um gerenciador de tags já publica um ID de usuário, as gravações passam a ser atribuíveis a uma pessoa identificada como efeito colateral da instalação.

A partir daí, a gravação já não é pseudônima nas mãos do cliente. Ela pode ser cruzada com seu CRM, e a exportação para BigQuery foi construída para carregar exatamente as colunas que tornam o cruzamento trivial: visitor_id, custom_user_id e ip_address na mesma linha. Essa exportação está atualmente desativada em todos os projetos, e seu processo não está em execução — a capacidade existe, a atividade não.

Uma fragilidade de concepção deveria ser registrada sem exagero. visitor_nicknames tem uma restrição UNIQUE somente sobre visitor_id, sem limite entre locatários — a tabela é estruturalmente transversal aos projetos. Na prática, o identificador fica em localStorage e, portanto, está restrito a uma origem, de modo que isso, por si só, não cria rastreamento entre sites de domínios de clientes diferentes. É um limite ausente no esquema, e não um vazamento demonstrado, e deveria ser estabelecido antes de qualquer implantação em que dois projetos possam compartilhar uma origem.

Probabilidade — Provável para reconhecimento entre sessões (é o comportamento padrão, e há 329 identificadores registrados); Possível a Provável para identificação, dada a via automática do dataLayer. Gravidade — Grave: a identificação elimina o fator de mitigação que torna tolerável a gravação comportamental, e o faz retroativamente — uma vez vinculado um identificador, as sessões anteriormente pseudônimas daquele visitante também passam a ser atribuíveis.

R7 — Ausência de prazo de eliminação para treze tabelas; prazos definidos em 17/08/2026

A limpeza que considera o nível exclui cinco tabelas: mouse_events, session_custom_event_params, session_custom_events, session_pageviews e visitor_sessions. Treze tabelas com dados pessoais não constam dessa lista: ai_session_features, ai_timelines, consent_events, session_comments, session_shares, visitor_nicknames, ip_lifetime_stats, audit_logs, user_ip_history, users incluindo last_ip, support_requests, consent_region_acceptances e heatmap_page_stats.

A consequência prática é pior do que a lista sugere, devido à ordem em que as coisas aconteceriam. Quando a limpeza finalmente for executada, a sessão desaparecerá e as derivações permanecerão — ai_timelines manteria a sessão como prosa legível, 3.203 linhas e 5,5 MB dela, descrevendo uma pessoa cujo registro subjacente foi excluído. Hoje não existem esses registros órfãos, mas somente porque nada jamais foi excluído.

Três outras falhas agravam isso. A rotina não é agendada pelo cron nem pelo systemd, mas executada dentro do processo worker; portanto, se esse processo parar, a eliminação para e nada comunica isso. Sua consulta de seleção une sessões a projetos, espaços de trabalho, proprietários e usuários com inner joins, de modo que uma sessão cujo projeto foi excluído nunca poderá ser selecionada nem eliminada — uma das 706 sessões já está nessa situação. E a retenção efetivamente em vigor é de 365 dias para todos os projetos do sistema, diante de um conjunto de dados cujo registro mais antigo tem 20 dias; isso significa que a cadeia de exclusão nunca foi exercitada de ponta a ponta.

Probabilidade — Materializada. Gravidade — Grave, como violação do art. 5(1)(e) estrutural, e não acidental. Alterado em 17/08/2026. A própria execução permanece no db_worker, mas sua AUSÊNCIA agora é percebida: o worker registra seu resultado (mp_purge_status), e srv/cron_status.php — um processo DIFERENTE — o avalia a cada 60 segundos, grava sys_purge para a área administrativa e comunica por e-mail quando a última execução ocorreu há mais de 48 horas. No máximo uma mensagem por dia; um monitor que envia e-mails a cada minuto é ignorado e, então, também não comunica a falha real a ninguém. O monitor deliberadamente não fica no worker: um processo morto não pode comunicar a si mesmo. Situação em 23/09/2026: o envio de e-mails está implementado; a mensagem vai para o endereço de alerta definido na área administrativa.

Situação em 17/08/2026. Resolvido. Cinco das treze tabelas fazem parte da cadeia compartilhada de exclusão desde 12/08/2026, seis receberam um prazo próprio, configurável na área administrativa (migração 039), e duas estavam totalmente ausentes da lista: ai_visitor_value e ai_insights — precisamente a pontuação da pessoa e o texto gerado sobre ela. Os prazos ficam em site_settings e são lidos da mesma linha usada pelo registro do art. 30 para seu próprio texto. A limpeza é de fato executada; a execução de 17/08/2026 às 17:37:09 está registrada no log do worker. A preocupação desta seção — a sessão desaparece e a derivação fica órfã —, portanto, já não pode se concretizar. A execução ainda depende do processo worker e não é agendada pelo cron nem pelo systemd; desde 17/08/2026, sua ausência é comunicada pelo monitor do processo de status e, desde 23/09/2026, também por e-mail.

Reclassificado em 23/09/2026. Medido no mesmo dia: a última limpeza ocorreu 21 horas antes, a linha mais antiga em audit_logs tem 60 dias — exatamente o prazo configurado — e nenhuma sessão está sem projeto. A seleção ainda usa inner joins; mesmo assim, não surgem sessões órfãs, porque a exclusão de um projeto ou conta leva junto suas sessões por channelid. Desde 24/09/2026, user_ip_history também tem prazo próprio: 90 dias a partir da última vez em que um endereço foi visto, no máximo até a exclusão da conta. Probabilidade — Remota. Gravidade — Grave. Nível geral — baixo.

R8 — Pontuação e classificação automatizadas de cada sessão

Cada sessão é avaliada automaticamente. engagement_score (0-255) é calculado a partir de sinais de profundidade e de irritação; session_quality separa as sessões em que pouca coisa aconteceu; is_bot, com um código de motivo, classifica o visitante como não humano, e essa verificação ocorre antes da barreira de consentimento. As pontuações são indexadas e orientam a ordenação da lista de revisão do cliente, o que significa que determinam quais pessoas são observadas. No levantamento de agosto de 2026, existiam 4.043 linhas de características e 3.203 narrativas geradas.

Isso é definição de perfis nos termos do art. 4(11) — avaliação automatizada de aspectos pessoais relativos a uma pessoa física, especificamente para analisar ou prever seu comportamento. Segundo as evidências, não é tomada de decisões automatizada nos termos do art. 22: não foi encontrada nenhuma decisão de crédito, preço, acesso ou elegibilidade contra um visitante. Um mecanismo está mais próximo desse limite do que os demais e deveria ser identificado: ao detectar um clique de raiva, www/mp.js envia um julgamento comportamental a widgets de chat de terceiros em execução no próprio navegador do visitante — o Intercom recebe um sinalizador, e o LiveChat, uma variável de sessão. Um julgamento formado sobre o visitante sai, assim, do sistema em tempo real e pode mudar como essa pessoa é tratada no site.

Âmbito da definição de perfis, situação em 16/10/2026. Desde o levantamento, outras pontuações e derivações foram acrescentadas, e todas pertencem a este risco: frases e relatórios formulados por máquina sobre visitantes individuais (ai_insights, ai_besucher_bericht; os resultados são calculados, e um modelo de linguagem nas nossas próprias máquinas, na mesma rede local, os formula); um modelo de saída (regressão logística) que estima o risco de saída no navegador do visitante e, quando o operador do site o ativa, aciona uma oferta de saída cujo texto só é exibido após aprovação pelo operador; um indicador de perda baseado em regras para visitantes recorrentes (ai_churn); perfis comportamentais que agrupam sessões segundo seu percurso (k-means, mp_profile, mp_profil_sitzung) e padrões de sequência; um escore de atrito por sessão; pesquisas e um botão de feedback com as respostas do visitante; rastreamento de elementos, que atribui cliques a elementos marcados; um índice dos textos exibidos para busca (mp_text_block, mp_text_pv, 30 dias); e mensagens do console, bem como requisições malsucedidas ou lentas da página do cliente (sem corpo nem cabeçalhos). Segundo as evidências, nenhum deles toma uma decisão nos termos do art. 22 contra o visitante; a oferta de saída, porém, muda diretamente o que é exibido a ele na página e, por isso, é a mais próxima desse limite entre os itens listados. Os detalhes estão apresentados no registro do art. 30.

Separadamente, duas consequências automatizadas têm efeitos reais, mas contra clientes e endereços IP, e não visitantes: uma conta automaticamente marcada como is_suspicious no cadastro tem sua retenção de dados reduzida para 24 horas, e um IP que excede os limites de conexão é bloqueado; depois disso, toda requisição posterior é encerrada — no levantamento de agosto de 2026, estavam registrados 24 bloqueios desse tipo. No levantamento, nenhum dos dois tinha uma via documentada de revisão humana nem canal de oposição; para o bloqueio, existe um desde 17/08/2026 (abaixo); para o sinalizador is_suspicious, ainda não existe.

Probabilidade — Provável (comportamento padrão). Gravidade — Significativa: nenhum efeito jurídico para visitantes, mas receber pontuação e classificação sem saber e ter essa pontuação exportada para um widget de terceiros é precisamente a perda de controle descrita no Considerando 75. Avaliado em 17/08/2026. Desde esse dia, o bloqueio automático expirava por conta própria após 7 dias; antes disso, nunca expirava. Em 16/10/2026, o servidor WebSocket bloqueia por conta própria, e o bloqueio expira após 24 h (configurável de 1 a 168 h); o fail2ban bloqueia por uma hora; banned_ips só é preenchido manualmente. Uma oposição passa pelo formulário de suporte ou por office@mouseplayer.com e é tratada por uma pessoa; a área administrativa pode suspender o bloqueio. A duração fica em site_settings (autoban_stunden). A medida tem, portanto, efeito limitado, revisão humana mediante solicitação e uma via identificada para isso — as características relevantes para o art. 22. A própria classificação continua sendo uma questão jurídica; o que está decidido é a salvaguarda, e não a interpretação. (decisão do controlador, 17/08/2026)

R9 — 92 sessões inacessíveis por qualquer identificador; nenhum caminho da pessoa ao seu registro

92 sessões contêm visitor_id 'unknown'. Para esses registros, não existe chave alguma que leve a eles: os dados existem, são pessoais, contêm uma reprodução e possivelmente um endereço e não podem ser recuperados por nenhuma consulta que uma solicitação de titular dos dados pudesse acionar. A eliminação do art. 17 não pode ser realizada para eles, e o acesso do art. 15 não pode ser atendido. Medido novamente em 16/10/2026: nenhuma sessão tem mais visitor_id 'unknown'; o código, porém, ainda pode gravar o valor quando uma sessão é criada.

O problema mais amplo é pior do que as 92 linhas e já está registrado como não resolvido nas próprias notas do projeto. Mesmo quando existe um visitor_id, ele fica no localStorage do visitante, e a pessoa não o conhece. Não existe caminho de uma pessoa real — que pode fornecer nome, e-mail, data e página — aos seus registros. Um botão de eliminação ao qual a pessoa que tem direito de pressioná-lo não consegue chegar é um adereço.

O art. 11 oferece uma resposta parcial e desconfortável: quando o controlador pode demonstrar que não está em condições de identificar o titular dos dados, os arts. 15 a 20 não se aplicam — mas o art. 11(2) exige que o controlador informe isso ao titular, e este pode fornecer informações adicionais que permitam a identificação. Essa última disposição é o ponto: o visitante pode fornecer seu identificador, porque ele está no seu próprio navegador. Uma página de autoatendimento que mostre ao visitante seu próprio mp_visitor_id converteria uma solicitação impossível em uma solicitação rotineira, tornando difícil defender o recurso ao art. 11 enquanto essa página não existir.

Probabilidade — Materializada. Gravidade — Significativa, elevando-se a Grave em combinação com R1: a pessoa com menos condições de chegar ao seu registro é aquela que não sabe que ele existe. Decidido em 17/08/2026: será implementado um autoacesso às informações para visitantes — uma página na qual um visitante vê seu próprio identificador e pode acionar a exclusão das suas gravações, com link na política de privacidade. (decisão do controlador, 17/08/2026) Em operação desde 17/08/2026 em /my-data (alemão /meine-daten, polonês /moje-dane), com link no rodapé de cada página. Mostra a quantidade de sessões, o período e os domínios envolvidos — nenhuma gravação: o identificador é um token ao portador, e qualquer pessoa que o conhecesse poderia, de outro modo, ver o comportamento de outra pessoa. A exclusão entra na fila e é realizada pelo worker com a cadeia existente; a própria página não exclui.

Até que ponto isso reduz R9 depende de onde o visitante foi gravado, e esse limite é técnico: o armazenamento do navegador é separado por origem. O identificador fica no armazenamento do site em que o script foi executado, e não no nosso. Portanto, uma página em mouseplayer.com não consegue vê-lo por conta própria — verificado nos dados, nos quais nenhum identificador aparece em mais de um domínio. Disso decorrem três caminhos de acesso:

• Visitantes do próprio mouseplayer.com acessam seus dados diretamente, porque aqui o armazenamento do navegador é nosso. Para eles, R9 é eliminado.
• Visitantes de um site de cliente acessam os dados por um link que o cliente coloca no seu próprio aviso de privacidade; MousePlayer.privacyUrl() o retorna pronto, incluindo o identificador. Isso não é uma evasiva, mas a divisão de papéis nos termos do art. 28: perante seus próprios visitantes, o cliente é o controlador, e o aviso do art. 13 já deve constar na política dele. Nós fornecemos a ferramenta e somos o destinatário.
• Quem já conhece seu identificador o insere na página.

Quando um cliente não coloca o link, R9 permanece integralmente para os visitantes desse cliente — a solicitação então não é impossível, mas passa pelo cliente, e não por nós; para esse caso, a declaração do art. 11 está na política de privacidade. Quem limpou o armazenamento do navegador não é alcançável por nenhuma das três vias. Portanto, a página não elimina R9; desloca-o de "tecnicamente impossível de cumprir" para "possível de cumprir, desde que o controlador indique o caminho".

R10 — Sem criptografia em repouso, sem TLS para o banco de dados nem para o Redis pela LAN

Três lacunas de infraestrutura estão documentadas como não implementadas e foram verificadas, e não presumidas. A criptografia das tabelas, dos logs e das tabelas temporárias do InnoDB está desativada, e o disco não é criptografado; portanto, todo o conjunto — 322,6 MB de eventos e 162,9 MB de capturas de página — está em repouso em texto claro. A conexão com o banco de dados funciona sem TLS: o servidor o suporta, mas nenhum certificado, chave ou CA está configurado; a conexão é local, o que mitiga o problema, mas não o elimina. Até 16/08/2026, o Redis funcionava sem proteção de acesso enquanto persistia dados em disco, e suas filas contêm o IP truncado, a URL completa e o payload do DOM em trânsito.

Probabilidade — Possível. A exploração remota é improvável: no levantamento, Redis e banco de dados estavam vinculados somente a localhost (para a situação atual, veja abaixo), HTTPS é imposto, e a conexão TLS do WebSocket termina com um certificado real no nginx. As vias realistas são físicas — roubo da máquina, descarte do disco — e a via do backup em R5, que levava o mesmo texto claro para fora da máquina toda noite até 11/08/2026 e, desde então, transfere de forma criptografada; as cópias sem criptografia anteriores a essa data foram excluídas no fornecedor em 12/08/2026. Gravidade — Muito grave se concretizado, porque tudo é exposto de uma só vez.

Respondido em 17/08/2026: o servidor fica em uma sala trancada sob videomonitoramento em Lodz; o acesso é exclusivo do controlador. O disco USB de backup fica na mesma sala que o servidor. Respondido em 17/08/2026: a criptografia em repouso não será introduzida antes da produção — inviável na fase inicial no Raspberry Pi (decisão do controlador). Portanto, este risco permanece integralmente: todos os dados ficam em texto claro no disco, e o disco USB de backup está na mesma sala. A salvaguarda restante é física — uma sala trancada sob videomonitoramento, com acesso somente pelo controlador — e protege contra roubo ou descarte inadequado de um disco apenas na medida em que essa sala protege. Reavaliar assim que as operações saírem do Raspberry Pi.

Situação em 17/08/2026. Uma parte está resolvida, outra mudou. O Redis tem acesso restrito desde 16/08/2026; verificado no serviço, recusa requisições sem autenticação. A criptografia em repouso continua ausente. A suposição mitigadora desta seção, porém, já não se sustenta: desde 16/08/2026, Redis e banco de dados não escutam mais somente em localhost, mas também no endereço da LAN (bind-address = 127.0.0.1,192.168.20.2), para que um segundo nó possa acessar o estado compartilhado; as linhas ssl- na configuração do servidor permanecem comentadas. Enquanto apenas um nó funciona, isso permanece teórico. Com o segundo, conteúdo de sessões e tráfego do banco de dados atravessam a rede em texto claro, e as vias deixam de ser somente físicas. A classificação deste risco deve ser reavaliada antes de um segundo nó entrar em operação.

Situação em 16/10/2026. As conexões vindas da internet são criptografadas com TLS; a criptografia termina no nginx, e o servidor WebSocket escuta somente em 127.0.0.1:8081, isto é, na mesma máquina. O MousePlayer usa sua própria instância Redis em 127.0.0.1:6381, com restrição de acesso e persistência em disco (arquivo somente de acréscimo); portanto, o conteúdo das filas e os endereços IP não truncados mantidos durante o bloqueio automático (24 h) também chegam ao disco. Uma instância Redis mais antiga e compartilhada também escuta, com acesso restrito, no endereço da LAN. O MariaDB escuta em 127.0.0.1 e no endereço da LAN 192.168.20.2 sem TLS (nenhum certificado configurado), e há conexões da rede local. Portanto, dentro da nossa própria rede local no mesmo local, conexões com banco de dados e Redis funcionam sem criptografia; têm acesso restrito e só são alcançáveis pela nossa própria rede local (sem encaminhamento de portas). A criptografia em repouso continua ausente.

R11 — Nenhum registro de quem visualizou qual gravação

O log de auditoria registra ações de escrita — criação e revogação de compartilhamentos, exclusão de comentários, exclusão de sessões e visitantes, bloqueios automáticos, ações de superadministradores, 666 entradas no total no levantamento. Ele não registra leituras. Uma chamada à página do player, ao endpoint de eventos ou ao endpoint do teatro não deixa rastro. Ninguém consegue estabelecer depois qual funcionário de um cliente assistiu à sessão de uma pessoa identificada, com qual frequência, nem se um administrador do MousePlayer o fez. Desde 17/08/2026, pelo menos os acessos por links de compartilhamento são registrados (share_views); chamadas de usuários autenticados não deixam rastro (situação em 16/10/2026).

Probabilidade — Materializada como lacuna de controle. Gravidade — Significativa, com um efeito cumulativo mais importante que o direto: após qualquer incidente, os arts. 33 e 34 exigem que o controlador descreva as categorias e o número aproximado de titulares dos dados e registros envolvidos. Sem registro de leituras, essa descrição não pode ser produzida a partir de evidências, e toda notificação se torna uma estimativa.

R12 — Qualidade das provas de consentimento e adaptadores CMP não testados

O art. 7(1) atribui ao controlador o ônus de provar o consentimento, e o código declara isso expressamente como motivo para a existência do log de consentimento. Nos dados medidos do levantamento (agosto de 2026), 671 de 706 sessões contêm consent_source='testdata' com data e hora NULL, gravadas por uma massa de teste de desenvolvimento — não provam coisa alguma. Os registros genuínos somavam então 35: 27 da API, 5 do Google Consent Mode, 2 concessões tardias, 1 revogação. Em 16/10/2026, 566 de 8.648 sessões humanas contêm consent_source='testdata'; as demais contêm um registro da API (7.451), do adaptador Consented (620) ou do Google Consent Mode (9). A exclusão na revogação existe como opção e está desativada em todos os projetos (situação em 16/10/2026); portanto, uma revogação interrompe gravações futuras, mas mantém as gravações anteriores.

Dos seis adaptadores CMP e das três camadas de detecção de consentimento, somente três vias foram exercitadas na realidade: a API direta, Google Consent Mode e Cookiebot. TCF e cinco adaptadores — Usercentrics, OneTrust, Consentmanager, Borlabs, Complianz — estão construídos, mas nunca funcionaram contra uma CMP em operação. Dado o princípio orientador de bloqueio em caso de falha, um adaptador que interprete mal um sinal falha no sentido de não gravar, que é a direção segura; o risco é, portanto, principalmente de provas não verificadas, e não de gravação ilícita.

Probabilidade — Materializada para este conjunto de dados. Gravidade — Grave em termos de produção, porque um consentimento que não pode ser comprovado é, em uma disputa, um consentimento que não existiu. Essa classificação se aplica aos dados de desenvolvimento e precisa ser medida novamente. a preencher: a proporção medida de sessões de produção com um registro genuíno de consentimento e a data em que cada adaptador CMP foi verificado em uma instalação em operação

R13 — Solicitações de suporte encaminhadas ao Telegram com o IP não truncado (transferência encerrada em 11/08/2026)

Até 11/08/2026, quando uma solicitação de suporte era enviada, todo o caso era transmitido ao Telegram: situação da conta, endereço de e-mail, assunto, o texto completo da mensagem, a URL de origem e o endereço IP não truncado. Os tokens estavam definidos, portanto esse ramo estava ativo. Quem solicita frequentemente não é um cliente, e o texto de suporte não tem limites — as pessoas descrevem situações de saúde, disputas e circunstâncias financeiras em tickets de suporte, porque é isso que o campo convida a fazer. Desde 11/08/2026 cfg/lib.php envia exatamente uma string fixa: "MousePlayer: es liegt eine neue Supportanfrage vor." Nenhuma variável chega à mensagem, não existe parse_mode e, deliberadamente, não há número de caso — que seria um identificador relativo a uma pessoa — nem link construído a partir do nome de host solicitado, porque esse valor vem da própria requisição. Um verificador (ai/pruefstand/test_telegram_signal.php) verifica não o resultado, mas a possibilidade: quais variáveis podem chegar à mensagem. Quatro são permitidas, 15 identificadores são proibidos, e o texto precisa ser uma string entre aspas simples sem interpolação; o verificador foi executado contra duas versões deliberadamente defeituosas e detectou ambas. O que não foi corrigido é o armazenamento local. A solicitação é armazenada sem alteração em support_requests, incluindo endereço de e-mail e endereço IP — isso é intencional, o operador do sistema precisa deles para disputas —, e support_requests não tinha prazo de retenção até 17/08/2026; desde então, a solicitação é eliminada após 730 dias (veja R7). O objetivo da alteração é que os dados não saiam, e não que desapareçam.

Probabilidade — Materializada até 11/08/2026 em cada envio; desde 11/08/2026, a transferência não ocorre mais. Gravidade — Significativa: até 11/08/2026, porque o Telegram está fora da UE e não oferece acordo de tratamento para canais de bots; desde então, a mesma classificação se aplica somente ao armazenamento local, porque o que permanece é a manutenção de endereço de e-mail, IP e texto livre sem limites no banco de dados do próprio operador do sistema — limitada a 730 dias desde 17/08/2026. O elemento de país terceiro deixou de existir, a retenção tem limites; é acompanhada em R7. A decisão foi tomada e datada: o canal é mantido e, desde 11/08/2026, a mensagem não contém dados. Portanto, uma base legal e um instrumento de transferência para um país terceiro já não são necessários, porque nenhum dado pessoal chega ao Telegram; para esta operação, o Telegram não é um operador. Nível geral — médio até 11/08/2026; baixo desde então.

R14 — Saída para destinatários escolhidos pelo próprio controlador

O MousePlayer oferece pontes pelas quais itens individuais são transmitidos aos sistemas do próprio controlador: seu sistema de relacionamento com clientes, central de atendimento, marketing, publicidade, armazenamento ou tarefas, ou um endereço que ele mesmo indica. Somente ele faz a seleção e armazena as credenciais; a transmissão é, portanto, sua instrução. Os detalhes estão apresentados no Registro, seção 4.1.

Onde está o risco. Não no volume: o que é transmitido são identificadores e nomes de eventos, nunca o conteúdo da página gravada, a trajetória do mouse ou o texto de formulários. O risco está na irreversibilidade. Se uma solicitação de eliminação do art. 17 chega até nós, eliminamos nossa cópia — não conseguimos alcançar a cópia no destinatário. Por quanto tempo ele a mantém, para onde a leva e a quem a repassa está fora da nossa influência e não é algo que possamos monitorar. O mesmo vale para uma transferência a país terceiro: o controlador determina o destino e, com ele, a salvaguarda nos termos do Capítulo V.

O que foi feito a respeito. A política de privacidade declara ambos claramente — o que sai e que uma solicitação de eliminação não produz efeito ali — e direciona o titular dos dados ao operador do site, que tomou essa decisão, quanto à questão de quais destinatários estão ativados. O Acordo de Tratamento de Dados esclarece que esses destinatários não são suboperadores do MousePlayer. Tecnicamente, o volume é mantido pequeno, e nome, endereço de e-mail, número de telefone e endereço IP expressamente não são enviados a redes de publicidade. Desde 20/08/2026, cada projeto mantém um log de entrega (Registro A.11), no qual o controlador pode consultar o que efetivamente saiu — antes disso, não era visível para ele.

O que permanece. Um risco residual que não pode ser eliminado por engenharia enquanto a funcionalidade existir: a divulgação é intencional, e suas consequências ficam fora da nossa esfera. Ele é assumido pelo controlador que ativa a ponte e é informado a ele no Acordo de Tratamento de Dados e nesta avaliação.

8. (d) Medidas previstas para enfrentar os riscos

Cada medida abaixo tem um status, e os status não são decorativos. Implementada significa verificada hoje no sistema em operação. Parcial significa que o mecanismo existe, mas ainda não atinge sua finalidade. Planejada significa que não existe. Uma DPIA que apresenta medidas planejadas como implementadas é a crítica habitual ao instrumento, e é a crítica que destrói o valor do documento na única situação em que ele importa.

8.1 Implementadas hoje — verificadas

Medida	Enfrenta	Evidência
Barreira de consentimento no navegador, com bloqueio em caso de falha: ausência de sinal, falha da CMP, erro de script e origem desconhecida resultam todos em "não gravar"	Licitude	Máquina de estados mpEinw em www/mp.js, após a verificação de bots
Aplicação independente no servidor: somente GRANTED ou GRANTED_LATE ou uma isenção regional explícita passam; revogação, país desconhecido e qualquer situação pouco clara fecham a conexão	Licitude	class/Server.class.php:977-1004; 24 conexões bloqueadas registradas no levantamento
Lista de exclusão de caminhos aplicada antes da barreira, comparando somente o caminho	Minimização	class/Server.class.php:963-975; 71 conexões bloqueadas registradas no levantamento
Truncamento do IP no momento da leitura, antes de qualquer consumidor do valor	R3, somente prospectivamente	class/Server.class.php:432-435; todas as sessões desde 07/08/2026 truncadas
Mascaramento de formulários com um patamar mínimo incondicional para senhas e dados de pagamento em qualquer configuração; todos os projetos no nível mais rigoroso	R2, somente prospectivamente	www/mp.js:4818-4853
Nomes dos campos classificados, em vez de transmitidos	Minimização	www/mp.js:4653-4674
Mascaramento do DOM dentro de regiões marcadas, aplicado também às alterações ao vivo	R1, parcialmente	www/mp.js:3934-3970 e 4732-4768
String TC armazenada somente como hash SHA-256	Minimização	visitor_sessions.tcf_hash
Payload de reprodução deliberadamente excluído da API pública	R4	www/api/v1_session_detail.php:25
Links de compartilhamento: token de 160 bits, padrão de 7 dias e máximo de 90 dias, identificadores obtidos somente do token, string de consulta substituída em vez de ignorada, papel NULL, todos os três endpoints restritos, resposta idêntica para tokens inventados, expirados e revogados, revogação disponível	R4	cfg/lib.php mp_share_erstellen / mp_share_pruefen; www/.htaccess
Geolocalização com arquivos locais do banco de dados — nenhuma chamada a terceiros em qualquer ponto do caminho da gravação	Transferências para países terceiros	class/IP2CityLite.class.php:37; class/Server.class.php:724
Modelo de funções por espaço de trabalho; exclusão restrita a owner e admin e sempre limitada ao projeto	Controle de acesso	www/player.php:267, 275-282
Log de eventos de consentimento deliberadamente mantido além da exclusão da sessão, como prova de que ocorreu uma revogação	Art. 7(1)	srv/db_worker.php:257-259
Log de auditoria das ações de escrita	Responsabilização	cfg/lib.php:2878-2890; 666 entradas no levantamento
Segurança de transporte: HTTPS obrigatório; TLS com um certificado real termina no nginx, inclusive para o WebSocket (/mp_wss/), o túnel HTTP (/mp_wst), o envio de capturas (/mp_dom) e o ponto de medição (/mp_wsfail); o servidor WebSocket escuta somente no endereço de loopback. As conexões com banco de dados e Redis dentro da rede local não são criptografadas (veja R10)	Confidencialidade	www/.htaccess; configuração do nginx (srv/nginx/); srv/server.php vinculado a 127.0.0.1:8081
Tokens CSRF de random_bytes com comparação em tempo constante; cookie de sessão httponly, SameSite=Lax, secure; hashing de senhas; instruções preparadas em todos os caminhos de escrita auditados; limitação da taxa de login; bloqueio automático e limites de conexão por IP; fail2ban em execução	Confidencialidade	cfg/lib.php:110-132; www/login.php; class/Server.class.php:449-455, 660-668
Segredos fora do controle de versões	Confidencialidade	.gitignore abrange .env; somente .env.example é versionado
Retenção imposta para os logs do portal: 60 dias e 72 horas, respectivamente, mais a expiração dos bloqueios	Limitação da conservação	srv/db_worker.php (execução diária de exclusão)
Execução diária de exclusão por nível e por prazos separados para as outras tabelas, mais os prazos das sessões marcadas como bots a cada hora; sua ausência é comunicada por um processo separado de status, por e-mail e nos Logs Urgentes	Limitação da conservação, R7	srv/db_worker.php; srv/cron_status.php (sys_purge); entrada mais antiga em audit_logs em 16/10/2026 no prazo de 60 dias
fail2ban com nove jails, entre elas mp-nginx-429, que bloqueia endereços que acionam repetidamente o limite de requisições do nginx; mais limites de taxa no nginx	Disponibilidade, prevenção de abusos	fail2ban-client status, verificado em 16/10/2026
Arquivamento antes da exclusão definitiva: a exclusão de projetos, espaços de trabalho e contas, bem como a exclusão por endereço IP ou visitante, primeiro oculta os dados e interrompe a gravação; a exclusão definitiva ocorre após 30 dias ou antes, mediante solicitação, executada e recontada pelo worker. A exclusão de contas inativas não arquiva primeiro	Integridade, limitação da conservação	Migração 189; cfg/archivierung_lib.php; mp_loesch_archiv
Prazos para sessões marcadas como bots: gravação esvaziada (prazo em dias: 1), linha da sessão excluída após 14 dias	Limitação da conservação	site_settings retention_bot_recording_days e retention_bot_session_days; srv/db_worker.php

8.2 Parciais — existem, mas ainda não atingem sua finalidade

Medida	Por que ainda não é eficaz
Mascaramento do DOM	Opcional por elemento. Protege o que o visitante digita, e não o que a página apresenta — o conteúdo de R1
Exclusão na revogação	Implementada como opção, desativada em todos os projetos (situação em 16/10/2026); portanto, uma revogação não remove o que já foi gravado
Cabeçalhos noindex e no-referrer	A página que mostra a gravação por um link de compartilhamento (player.php em modo de compartilhamento) contém Referrer-Policy: no-referrer e Cache-Control: no-store, mas não o cabeçalho X-Robots-Tag; noindex aparece somente em www/share.php, a página de erro, e robots.txt permite tudo (verificado em 16/10/2026)

8.3 Planejadas — não implementadas

Medida	Enfrenta	Prioridade
Criptografar a cópia externa antes do envio — concluído em 11/08/2026: a execução diária criptografa no nosso próprio servidor antes da transferência (rclone crypt, incluindo nomes), e as chaves ficam em dois arquivos com modo 600. Excluir os dados legados sem criptografia na pasta de destino anterior — concluído em 12/08/2026. Depositar os arquivos de chaves para que sobrevivam à destruição da máquina — concluído em 17/08/2026: são mantidos impressos em um cofre (declaração do controlador). Estabelecer ou encerrar o acordo com o Google Drive – concluído em 05/09/2026: desde esse dia, a cópia externa é mantida em um bucket do Google Cloud Storage na região europe-central2 (Varsóvia) e abrangida pelo Google Cloud Data Processing Addendum. O restante na conta privada do Drive foi excluído em 06/09/2026, após a aprovação do exercício de restauração a partir do novo destino. Remover os scripts antigos de backup — concluído em 16/10/2026.	R5	Não se aplica mais — concluído
Inverter o padrão do conteúdo da página: armazenar texto mascarado salvo liberação explícita e exigir confirmação por escrito do cliente antes de capturar o texto literal da página	R1	Primeira
Política contratual por setor: quais setores são admitidos e sob quais condições adicionais	R1	Primeira
Truncamento ou exclusão, uma única vez, dos 236 + 291 + 666 + 5 endereços legados — concluído em 17/08/2026: os dados legados no caminho da gravação e em audit_logs e user_ip_history estão truncados (veja R3)	R3	Não se aplica mais — concluído em 17/08/2026
Revisar e eliminar as 173 linhas de entrada em texto claro — concluído em 17/08/2026: excluídas sem revisão (decisão do controlador, veja R2)	R2	Não se aplica mais — concluído em 17/08/2026
Estender a limpeza às treze tabelas não abrangidas; transferi-la para um agendamento monitorado; corrigir a lacuna de inner join para que sessões órfãs sejam alcançáveis	R7	Não se aplica — concluído em 17/08/2026 (prazos e monitor); a seleção por inner join permanece, não surgem sessões órfãs (veja R7)
Registrar os acessos de leitura ao player e aos dois endpoints de dados	R11, art. 33	Alta
Referrer-Policy e X-Robots-Tag na página do player; duração padrão menor dos compartilhamentos — Referrer-Policy: no-referrer está definido no modo de compartilhamento (verificado em 16/10/2026); X-Robots-Tag e uma duração padrão menor (ainda 7 dias) estão pendentes	R4	Média
Consulta por autoatendimento para que um visitante recupere seu próprio identificador, tornando possível atender às solicitações dos arts. 15 e 17 — concluído em 17/08/2026: /my-data (alemão /meine-daten, polonês /moje-dane), veja R9	R9	Não se aplica mais — concluído em 17/08/2026
Nunca isentar do mascaramento o estado de caixas de seleção e botões de opção; estender o mascaramento a ele	R1, R2	Média
Criptografia em repouso; TLS para o banco de dados; proteção de acesso para o Redis — proteção de acesso para o Redis concluída em 16/08/2026; criptografia em repouso e TLS para o banco de dados estão pendentes (veja R10)	R10	Média
Remover o IP da notificação do Telegram ou substituir o canal — concluído em 11/08/2026: a notificação agora consiste em um texto fixo de aviso sem variável alguma (cfg/lib.php), protegido por ai/pruefstand/test_telegram_signal.php	R13	Não se aplica — concluído em 11/08/2026
Prazo de retenção para support_requests, audit_logs e user_ip_history	R7	Não se aplica — concluído em 17/08/2026 para support_requests e audit_logs, em 24/09/2026 para user_ip_history
Limite entre locatários em visitor_nicknames	R6	Baixa
Via documentada de revisão e oposição para o bloqueio automático e o sinalizador is_suspicious — para o bloqueio automático concluído em 17/08/2026 (expiração então após 7 dias, agora após 24 h, oposição pelo formulário de suporte, suspensão na área administrativa, veja R8); para o sinalizador is_suspicious, está pendente	R8	Baixa
Verificar cada adaptador CMP em uma instalação em operação antes de oferecê-lo	R12	Baixa

8.4 Procedimentos e salvaguardas ainda a estabelecer

O art. 35(7)(d) exige salvaguardas, medidas de segurança e mecanismos — o que inclui os procedimentos organizacionais, e não apenas o código. No levantamento, quatro estavam ausentes; a situação atual é indicada para cada um.

• Estabelecido em 17/08/2026. Detecção: o controlador, um Cliente ou um visitante do site. Via de comunicação para nós: privacy@mouseplayer.com. Decisão sobre a notificação à autoridade de controle: Lukas Wójcik, proprietário, no prazo de 72 horas nos termos do art. 33(1). Informação ao Cliente: por e-mail, sem demora injustificada nos termos do art. 33(2), no máximo no prazo de 48 horas (acordo de tratamento de dados, seção 8). Envio: o envio de e-mails está configurado desde 23/09/2026 por SMTP no Namecheap Private Email (remetente office@mouseplayer.com); portanto, a via prometida ao Cliente está implementada. Nenhum exercício foi realizado até agora.
• Respondido em 17/08/2026: até então, nenhum teste de restauração havia sido realizado; estava planejado um teste mensal, com tempo objetivo de recuperação de no máximo 24 horas. Os dois arquivos de chaves são mantidos impressos em um cofre acessível somente ao controlador. Realizado desde então: um exercício de restauração a partir do novo destino no Google Cloud Storage antes da exclusão das cópias do Drive (05/09/2026 e 06/09/2026) e, em 07/10/2026, uma restauração completa dos dados do backup na nuvem em um ambiente separado — cerca de 70 minutos, amostras do arquivo e do banco de dados sem erros. Isso comprova a recuperação de dados, e não a reconstrução de uma máquina completa de produção; não existe monitor que lembre o próximo teste.
• Respondido em 17/08/2026: NÃO existem alertas automáticos; a verificação é manual. Medido no mesmo dia: o código não contém monitoramento de falhas, espaço em disco ou sucesso de backups — as únicas ocorrências de Telegram ficam em uma biblioteca de terceiros que ninguém chama, srv/cron_status.php apenas grava um valor de status no Redis, e system_alerts está vazio. Até 17/08/2026, as TOM prometiam o contrário ("em caso de falha do sistema, o administrador recebe uma notificação automática"). Era uma garantia que o código não cumpre; foi corrigida no mesmo dia. Resolvido em 19/08/2026: srv/backup-crypt.sh agora registra o resultado de cada execução em um arquivo de status, e srv/cron_status.php verifica, além dos cinco componentes existentes, o sucesso do backup, o espaço livre nos volumes do sistema e do backup e – como monitor jurídico, e não operacional – o limite do art. 37. Cada verificação malsucedida é comunicada por e-mail no máximo uma vez por dia. O monitor consulta o último backup bem-sucedido, e não a última tentativa: um script que inicia toda noite e aborta toda noite tem um horário recente e nenhum backup, exatamente como a atualização do GeoIP passou despercebida por cinco dias. Um limite permanece e é declarado, em vez de implícito: o monitor é executado na máquina que monitora e não pode comunicar a falha total dessa máquina; não existia verificação externa de disponibilidade. Desde 02/10/2026, uma segunda máquina no mesmo local verifica a aplicação a cada minuto (TOM, seção 5); uma falha da conexão com a internet ainda não é detectada por ela. As TOM foram alinhadas no mesmo dia (versão 1.2), portanto a correção não está limitada a este documento.
• As opiniões dos titulares dos dados não foram solicitadas. Fundamentação: perante os usuários finais observados, o MousePlayer atua exclusivamente como operador e não tem um canal próprio com eles — qualquer abordagem passaria pelos sites dos Clientes e, por si só, seria um tratamento dos seus dados para uma nova finalidade. Os interesses dos titulares são considerados indiretamente: pela barreira de consentimento, que não grava nada sem sinal, pelo mascaramento das entradas e pelos prazos de eliminação. Solicitar suas opiniões continua possível assim que existir um canal que os alcance sem capturá-los novamente para essa finalidade. (decisão do controlador, 17/08/2026)

9. Risco residual e consulta prévia nos termos do art. 36

O art. 36(1) exige consulta prévia à autoridade de controle quando uma DPIA indica que o tratamento resultaria em alto risco na ausência de medidas tomadas para mitigar o risco. O teste, portanto, não é se foram identificados riscos altos — foram identificados dois muito altos —, mas se permanece alto risco depois que as medidas da alínea (d) estão implementadas. Essa pergunta precisa ser respondida com honestidade para cada um dos dois.

R5, a cópia diária externa, podia ser corrigido por meios comuns — e foi corrigido. A camada de criptografia antes do envio está implementada desde 11/08/2026, os dados legados sem criptografia no fornecedor foram excluídos em 12/08/2026 e, desde 05/09/2026, a cópia é mantida em uma região europeia sob o Google Cloud Data Processing Addendum. Portanto, a questão do fundamento da transferência diária está respondida. Reclassificado em 17/09/2026, R5 está em médio. A condição da avaliação (remoção dos scripts antigos) foi cumprida em 16/10/2026; a reclassificação de R5 cabe ao controlador.

R1, categorias especiais no conteúdo da página, não pode ser integralmente corrigido. O sistema não consegue saber o que a página de um cliente apresenta, e nenhuma lógica de mascaramento muda isso. O que as medidas podem alcançar é uma inversão do padrão, para que o modo de falha passe a ser uma gravação pouco útil, e não ilícita, mais uma política contratual por setor e uma confirmação do cliente. Isso reduz substancialmente o risco. Não o elimina, porque um cliente ainda pode liberar o texto de uma página que, depois, passe a exibir algo sensível.

Quanto ao art. 36, a conclusão tem duas partes, que não podem ser fundidas em uma. Formalmente, a obrigação de consultar cabe ao controlador — o cliente que opera o site —, e não ao MousePlayer, que é o operador em relação aos dados de visitantes que apresentam alto risco. O MousePlayer não pode consultar no lugar de um cliente, e um cliente não pode delegar a decisão. O que o MousePlayer deve, nos termos do art. 28(3)(f), é fornecer ao cliente os fatos que lhe permitam tomá-la, finalidade das seções (a) e (c) deste documento.

Quanto ao mérito: a consulta prévia não é indicada se as medidas de 8.3 forem implementadas antes do lançamento em produção, porque o risco residual então fica abaixo do limite de que trata o art. 36. A consulta prévia é indicada em uma situação específica, e ela é uma decisão, e não um acidente: se o operador do sistema decidir não inverter o padrão do conteúdo da página enquanto continua a admitir clientes dos setores de saúde, jurídico, financeiro ou público. O risco residual então permanece alto por escolha, e o art. 36(1) se aplica nos seus termos. Uma segunda situação que constava aqui até 17/09/2026 — a continuidade da cópia diária externa sem um instrumento de transferência estabelecido — deixou de existir desde 05/09/2026 (R5).

Um outro ponto pertence a esta seção porque é fácil perdê-lo. O art. 36 não é uma penalidade, e consultar não é uma admissão. É o mecanismo que o Regulamento prevê exatamente para a situação em que este sistema se encontra — uma técnica realmente útil cujo risco residual depende de um fator que o operador do sistema não consegue controlar integralmente. Quando um controlador pretende continuar com alto risco residual, a consulta é a via lícita para fazê-lo.

10. Revisão, versão e aprovação

O art. 35(11) exige que o controlador revise se o tratamento é realizado de acordo com esta avaliação, pelo menos quando o risco mudar. Três eventos mudam materialmente o risco aqui, e cada um deveria desencadear uma nova realização, e não uma leitura: o primeiro cliente de um setor regulado; a primeira ativação da exportação para BigQuery ou de um webhook; e o momento em que os usuários finais monitorados ultrapassarem o limite registrado na seção 3.

A avaliação se baseia fundamentalmente em medições realizadas em 10/08/2026 e 11/08/2026 no sistema de desenvolvimento; foi aprovada em 17/08/2026 e atualizada desde então, mais recentemente em 16/10/2026, por uma conciliação com a situação técnica. Permanecem pendentes os marcadores nas seções 1, 3 e 4 e em R12, que somente o controlador pode preencher, e a reclassificação dos riscos cujas causas foram total ou parcialmente removidas desde o levantamento (R2, R3, R9, R10); a conclusão sobre o risco residual na seção 9 está condicionada às medidas ainda pendentes em 8.3.

Item	Registro
Controlador e operador	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Polônia — NIP PL7252266190 — office@mouseplayer.com
Encarregado da proteção de dados	Não designado. Veja a seção 3 para a análise do art. 37 e a recomendação.
Documentos relacionados	Registros das atividades de tratamento nos termos do art. 30(1) e do art. 30(2), as medidas técnicas e organizacionais, a lista de suboperadores, o acordo de tratamento de dados e as informações de privacidade
Base dos fatos	Código-fonte, esquema do banco de dados, contagens de linhas, lista de processos, valores de configuração e arquivos de log do sistema de desenvolvimento, 10/08/2026–11/08/2026, atualizados até 16/10/2026
Versão e data da aprovação	Aprovado por Lukas Wójcik, proprietário, em 17/08/2026. Não foi obtida orientação externa sobre proteção de dados. Revisada anualmente e a cada alteração do tratamento; as versões datadas são mantidas no controle de versões em ai/cms/. Acrescentado em 17/09/2026 por instrução do proprietário: R5 reclassificado (seções 5.4, 6, 7, 8.3 e 9). Acrescentado em 16/10/2026: conciliação com a situação técnica (cabeçalho, seções 1, 3, 4, 5, 7, 8 e 10); níveis de risco inalterados, reclassificação de R2, R3, R9 e R10 pelo controlador pendente. Acrescentado em 16/10/2026 (segunda revisão): prazos e duração do bloqueio automático como configurações em vez de números fixos, bases legais para solicitações de suporte e comentários, custódia das chaves e acessibilidade dos scripts antigos de backup (R5), prazo para informar o Cliente; níveis de risco inalterados, reclassificação de R5 pelo controlador pendente. Acrescentado em 16/10/2026 (terceira revisão): registrada a remoção dos scripts antigos de backup (R5), declarações sobre proteção de acesso ao banco de dados e Redis harmonizadas (R10); níveis de risco inalterados, reclassificação de R5 pelo controlador pendente.