Registro das Atividades de Tratamento (art. 30 do GDPR)

1. Como ler este registro

Este é um documento interno de responsabilização nos termos do art. 30 do GDPR. Não é um aviso de privacidade, não foi redigido para informar os titulares dos dados, embora seja publicado, nem para causar boa impressão. Sua única função é permitir que uma autoridade de controle — ou a próxima pessoa que precise responder a uma pergunta — veja o que é efetivamente tratado, onde fica e por quanto tempo permanece.

Três regras orientaram a redação. Primeira: uma afirmação só é feita quando sustentada por código, esquema ou medição. Quando falta uma informação, um marcador identifica a lacuna, em vez de uma frase plausível. Uma lacuna honesta resiste a uma auditoria; uma suposição bem redigida, não. Segunda: quando o código documenta sua própria fundamentação, ela é citada com arquivo e linha, para que um leitor posterior possa verificá-la, em vez de confiar neste documento. Terceira: a retenção é declarada duas vezes — uma para as tabelas abrangidas pela limpeza diária, outra para as que ela não abrange. Um registro que alega um prazo de exclusão válido para metade das tabelas é pior do que um que identifica a lacuna, porque é precisamente a lacuna que será verificada.

2. A entidade e por que este registro tem duas partes

Campo	Registro
Entidade jurídica	LW IT Solutions Company Lukas Wójcik
Endereço	al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Polônia
Identificação fiscal	NIP: PL7252266190
Contato	office@mouseplayer.com (nenhum número de telefone publicado)
Produto	MousePlayer — reprodução de sessões, mapas de calor, análise comportamental
Representante nos termos do art. 27	Não se aplica. A entidade está estabelecida na União (Polônia).
Encarregado da proteção de dados	Nenhum designado. Veja a seção 9 para a avaliação nos termos do art. 37.

O MousePlayer ocupa duas posições diferentes perante dois grupos diferentes de pessoas, e misturá-las produz um registro inútil para ambos. Para os dados dos VISITANTES dos sites dos clientes, o MousePlayer é operador e o cliente é controlador — aplica-se o art. 30(2). Para os dados dos próprios CLIENTES do MousePlayer (contas, faturamento, suporte, logs de acesso ao portal), o MousePlayer é controlador — aplica-se o art. 30(1).

Isso não é uma conveniência de redação. A distinção já está implementada no código e tem uma consequência técnica diferente para cada parte: class/Server.class.php:416 declara "REGEL B ... Hier sind wir AUFTRAGSVERARBEITER", e as linhas 421-425 separam "Regel A (volle Adresse) fuer DIREKTE Zugriffe auf die eigene Anwendung" da Regra B (truncada) para dados de visitantes. O endereço IP de um visitante é truncado em class/Server.class.php:432-435; o endereço IP de um usuário cliente é armazenado na íntegra. Portanto, o sistema já se comporta como se este registro existisse.

• Parte A (seção 3) — art. 30(2): vinte e duas atividades de tratamento (A.1 a A.22) realizadas em nome de controladores.
• Parte B (seção 5) — art. 30(1): oito atividades de tratamento (B.1 a B.8) realizadas sob a responsabilidade do próprio MousePlayer.
• As seções 6 a 8 são comuns às duas partes: retenção, tomada de decisões automatizada e descrição geral das medidas técnicas e organizacionais.
• A seção 10 lista as lacunas cuja existência foi comprovada. Um registro é um instrumento de trabalho, e não um certificado.

3. Parte A — art. 30(2): atividades realizadas em nome de controladores

A.0 Partes

Campo	Registro
Operador	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Polônia. office@mouseplayer.com
Controladores	Os clientes que operam os sites nos quais a tag do MousePlayer (www/mp.js) está instalada. Cada controlador é identificado no sistema por projects.channelid; os dados de contato ficam em users e workspaces, e a participação e a função, em workspace_users. Medido na instância de desenvolvimento: 7 projetos, 4 contas de clientes, funções 4 owner / 1 admin / 1 viewer.
Lista de controladores que faz fé	Mantida no sistema, sem duplicação aqui. A lista é gerada, e não transcrita: na área administrativa, em “Registro das Atividades de Tratamento (art. 30)”, um botão a produz sob demanda como CSV — por espaço de trabalho, o proprietário com nome, e-mail, empresa, endereço, identificação de IVA, plano e os domínios envolvidos. Responsável pela produção: Lukas Wójcik, proprietário; ela é extraída a cada revisão deste registro, isto é, anualmente e a cada alteração do tratamento. Cada consulta aparece no log de alterações (export_controllers). Uma lista transcrita aqui seria um segundo lugar para a mesma verdade e ficaria desatualizada a cada novo cliente, sem que ninguém percebesse. (decisão do controlador, 17/08/2026)
Representante do operador	Não se aplica (estabelecido na Polônia).
Encarregado da proteção de dados	Nenhum designado — veja a seção 9.
Medidas técnicas e organizacionais	A seção 8 se aplica a todas as atividades da Parte A e não é repetida em cada atividade.

A.1 Reprodução de sessões — captura de eventos comportamentais

Campo	Registro
Origem dos eventos	Duas vias. (1) O navegador do visitante por www/mp.js, no qual a máquina de estados mpEinw impõe tecnicamente o consentimento. mp.js transmite por HTTPS para o nginx, no qual o TLS termina: normalmente pelo WebSocket em /mp_wss/; se o WebSocket nunca se conectar, desde 11/10/2026 por um túnel HTTP em /mp_wst, ao qual se aplicam as mesmas verificações do servidor WebSocket (consentimento, detecção de bots, origem, cota); capturas grandes de página, desde 07/10/2026, como envio HTTP em /mp_dom com acesso assinado e com prazo limitado (mantidas no Redis por até 120 segundos, depois processadas como uma captura comum). O ponto de medição /mp_wsfail só conta conexões WebSocket malsucedidas por projeto, motivo, família do navegador e tipo de dispositivo, sem ID de visitante; ali, o endereço IP só é convertido em hash e mantido por no máximo uma hora para desduplicação. (2) No servidor, por www/api/capi_ingest.php, de um sistema operado pelo cliente; essa via exige assinatura (HMAC-SHA256 sobre data e hora e corpo, janela de cinco minutos) e uma declaração explícita por transmissão de que existe consentimento — sem ela, a requisição é rejeitada com 403. O MousePlayer não consegue verificar tecnicamente o consentimento nessa via; o cliente, como controlador, o garante (seção 2 do Acordo de Tratamento de Dados). A via pode ser ativada por site_settings.capi_ingest_aktiv; estava desativada até 18/08/2026 e está ativada desde então. Além disso, existe uma prévia de um SDK para aplicativo nativo (Android) com sua própria via de recebimento (www/api/native_ingest.php, tabelas mp_native_apps e mp_native_sessions); existe somente na instância de desenvolvimento e está desativada (native_preview_enabled = 0; em 16/10/2026, nenhuma sessão armazenada).
Finalidade	Gravar o comportamento dos visitantes dos sites dos clientes — movimentos do mouse, cliques, rolagem, toques, mudanças de aba — para que o cliente possa reproduzir e analisar a sessão.
Categorias de titulares dos dados	Visitantes dos sites dos clientes do MousePlayer.
Categorias de dados pessoais	Coordenadas de movimento, deslocamento temporal, posição de rolagem, altura do documento; tipo de evento; dimensões da área visível e da tela; identificadores de sessão e visualização de página. Distribuição medida dos eventos: move 100934, mutation 66153, scroll 28214, tab_focus 6185, resize 2590, screen_info 2034, pageview 2031, click 1863, input 599, input_mode 425, k 407, tap 401. Em visitor_sessions adicionalmente: referência de origem, parâmetros UTM, ID de clique de uma rede de publicidade com seu tipo, caminho de entrada, canal de tráfego, sinalizador de navegador no aplicativo, identificador do navegador (agente de usuário), sinalizador de bot com motivo, qualidade da sessão e, desde 26/09/2026, um escore de atrito com motivos (friction_score, friction_gruende). A distribuição de eventos acima foi medida em 10/08/2026.
Onde são armazenados	mouse_events (event_id, pageview_id, event_type, time_offset_ms, x, y, scroll_y, scroll_x, doc_height, target_selector) — 225892 linhas, 322,6 MB, a maior tabela do esquema. session_pageviews (pageview_id, session_id, tab_id, url, viewport_width, viewport_height, start_time, start_time_ms, end_time, page_title). visitor_sessions (session_id, channelid, screen_width, screen_height, start_time, end_time, duration_seconds, is_active, device_type). mouse_events_analytik (id, erfasst_am, pageview_id, channelid, event_type, time_offset_ms, x, y, target_selector) — 11812 linhas: uma cópia reduzida dos eventos CLICK e de contexto, da qual a camada de cliques do mapa de calor faz a leitura. Ela é indicada separadamente porque sua retenção difere da de mouse_events — esses são transferidos para o arquivo após 7 dias, a cópia permanece e, portanto, mantém o mapa de cliques por todo o histórico. A partir dela, é construído um agregado diário toda noite, mp_hm_klick_tag com mp_hm_ansicht_tag (desde 07/10/2026): por dia, endereço, tipo de dispositivo, classe de tela, alvo e célula de 8 px, somente uma contagem, sem sessão, ID de visitante ou visualização de página. O mapa de cliques o usa para dias cujas sessões já não existem. A exclusão de sessões individuais ou pessoas não o altera, porque nenhuma linha pode ser atribuída a uma pessoa. Desde outubro de 2026, adicionalmente mp_aufnahme_quittung: por mensagem recebida, um identificador e um status; para uma mensagem que não pode ser processada, também seu conteúdo bruto e o motivo. As linhas são excluídas após 7 dias (srv/db_worker.php). Contagens de linhas desta entrada sem data: em 10/08/2026.
Base legal (determinada pelo controlador)	Consentimento. Fundamentado em ai/migrations/018_consent.sql: a gravação é observação comportamental (Considerando 24 do GDPR) e acesso ao equipamento terminal (parágrafo 25 TDDDG); exige consentimento, e o interesse legítimo não a sustenta. Todos os 7 projetos estão definidos como projects.consent_mode='required'. Aplicação no servidor em class/Server.class.php:977-1004; interruptor geral site_settings.consent_gate_active=1.
Categorias de destinatários	(a) O respectivo cliente — membros do espaço de trabalho com função owner, admin ou viewer. (b) Qualquer pessoa que tenha um link de compartilhamento, SEM login: /s/<40-hex-token> é mapeado para player.php?share=..., tabela session_shares. (c) Opcionalmente, o cliente por REST API v1 com sua própria chave de API, somente em um nível pago; em 16/10/2026, não existe nenhuma chave de API. (d) Opcionalmente, os agentes de IA do cliente pelo servidor MCP (/mcp): acesso de leitura com uma chave de leitura da REST API, a ser ativado separadamente por projeto (projects.mcp_active, desativado por padrão); estão disponíveis projetos, indicadores, listas de sessões com link de reprodução, sessões individuais com visualizações de página e eventos, páginas, sinais de frustração e metas — não a captura da página. Em 16/10/2026, não ativado para nenhum projeto. (e) O cliente como arquivo: exportação CSV da lista de sessões e das respostas a pesquisas pela sua interface, com limite (csv_export_max_zeilen); cada exportação é registrada no log de alterações (csv_export).
Transferência para país terceiro	Nenhuma no caminho da gravação. Não foi encontrada chamada de saída; a resolução geográfica usa arquivos locais do MaxMind. Veja a seção 4.
Retenção	Dependente do nível, imposta pela limpeza diária em srv/db_worker.php (seção 6.1), pela cadeia de exclusão mp_sitzungen_loeschen(): free 7 dias, small 30, business 90, enterprise conforme o nível acordado (padrão 365). Sessões reconhecidas como automatizadas (bot) têm prazos próprios, menores: sua gravação (captura de página e eventos) é esvaziada quando retention_bot_recording_days transcorre (prazo em dias: 1), e a linha da sessão, com tudo o que está vinculado a ela, é excluída quando retention_bot_session_days transcorre (prazo em dias: 14); ambos são configuráveis na área administrativa, e 0 desativa o prazo separado, aplicando-se então o prazo do nível. Após 7 dias, os eventos saem de mouse_events para arquivos comprimidos por sessão (srv/cron_archiv.php); compartilham o prazo da sua sessão, são excluídos com ela e, desde 06/10/2026, fazem parte do backup diário (seção 4). Se um cliente exclui um projeto, um espaço de trabalho ou sua conta, ou se uma exclusão por endereço IP ou visitante é acionada, desde 07/10/2026 os dados são primeiro arquivados — ocultos, sem novas gravações, restauráveis — e definitivamente excluídos após no máximo 30 dias (seção 6.2, mp_loesch_archiv).

A.2 Captura do conteúdo da página — captura do DOM e alterações do DOM

Campo	Registro
Finalidade	Gravar o conteúdo da página para que a sessão possa ser reproduzida conforme vista pelo visitante.
Categorias de titulares dos dados	Visitantes dos sites dos clientes; e, indiretamente, toda pessoa cujos dados a própria página do cliente exiba — por exemplo, uma confirmação de pedido com endereço postal.
Categorias de dados pessoais	O HTML completo da página visitada, incluindo texto, URLs de imagens e metadados, conforme renderizado pelo navegador, sem scripts e com o mascaramento descrito em A.3. Além disso, fragmentos HTML serializados de cada alteração posterior do DOM, armazenados no campo target_selector dos eventos de alteração. Desde 30/09/2026, adicionalmente: conteúdo das raízes shadow abertas dos componentes web com suas folhas de estilo (raízes shadow fechadas não são gravadas); elementos canvas como imagem estática na captura e, quando mudam, continuamente como imagem (no máximo uma vez por ciclo de um segundo, com limite por visualização de página; não em áreas mascaradas nem para elementos canvas contendo imagens de outra origem); iframes da mesma origem com seu conteúdo e, desde 02/10/2026, as interações dentro deles (ponteiro, cliques, entradas, rolagem); iframes de outra origem somente como marcador de posição sem conteúdo.
Onde são armazenados	session_pageviews.payload_blob (longtext), armazenado comprimido desde 14/08/2026 (prefixo MPZ1:, gzip, Base64); em 16/10/2026, todas as linhas preenchidas usam esse formato. session_pageviews.has_recording é uma coluna comum, e não gerada: o worker a define ao gravar a captura e a redefine ao esvaziá-la; o mesmo vale para hat_interaktion, hat_scroll e scroll_max_y. mouse_events.target_selector onde event_type='mutation', incluindo o conteúdo de raízes shadow, canvas e iframes; após 7 dias nos arquivos (A.1). session_pageviews.html_path existe, mas, em 16/10/2026, não está definido em nenhuma linha.
Base legal (determinada pelo controlador)	Consentimento, como em A.1.
Categorias de destinatários	O cliente, por www/player.php, www/ajax_get_events.php e www/player_theatre.php. Qualquer pessoa que tenha um link de compartilhamento. NÃO pela REST API — www/api/v1_session_detail.php:25 registra a exclusão deliberada do payload de reprodução.
Transferência para país terceiro	Nenhuma no caminho da gravação.
Retenção	Como em A.1: com a sessão pela limpeza diária e mp_sitzungen_loeschen(); para sessões reconhecidas como bots, a captura é esvaziada após o prazo de A.1 (retention_bot_recording_days, prazo em dias: 1). Veja a seção 6.
Nota sobre o âmbito do mascaramento	O mascaramento se aplica somente DENTRO das regiões marcadas como data-mp-mask ou .mp-masked (www/mp.js:3934-3970). Todo o restante do HTML da página é armazenado sem alterações. Portanto, tudo o que a própria página do cliente renderiza está na gravação, e nenhuma configuração de mascaramento o alcança.

A.3 Captura de entradas em formulários

Campo	Registro
Finalidade	Gravar entradas em formulários, caractere por caractere, para que a interação com um formulário possa ser reproduzida.
Categorias de titulares dos dados	Visitantes dos sites dos clientes.
Categorias de dados pessoais	Valores de entrada dos elementos input, textarea e select — totalmente mascarados, parcialmente mascarados ou em texto claro, conforme o nível de mascaramento. O estado de caixas de seleção e botões de opção (true/false), que NUNCA é mascarado (www/mp.js:4810-4811). A categoria do campo derivada por classifyFieldName() (www/mp.js:4657-4674): email, password, phone, payment, address, name, search, coupon, quantity, other.
Onde são armazenados	mouse_events.target_selector onde event_type='input', formato {"t":"<data-mp-id>","v":"<value>"} — 599 linhas.
Base legal (determinada pelo controlador)	Consentimento, como em A.1.
Categorias de destinatários	O cliente (player); qualquer pessoa que tenha um link de compartilhamento.
Transferência para país terceiro	Nenhuma no caminho da gravação.
Retenção	Nenhum prazo próprio; como em A.1, com a sessão (prazo do nível; para bots, os prazos de A.1), após 7 dias nos arquivos.
Salvaguardas em vigor	Patamar mínimo obrigatório para senhas e dados de pagamento, independentemente do nível (www/mp.js:4831-4837). Mascaramento completo no nível 0 (www/mp.js:4818-4819). Todos os 7 projetos estão definidos como projects.smart_masking=0, que é a configuração MAIS RIGOROSA, apesar do rótulo.
Constatação sobre dados legados	Em 10/08/2026, 173 linhas em mouse_events continham entradas em texto claro NÃO MASCARADAS de 2026-07-21 a 2026-07-27, incluindo nomes de pessoas; as linhas daquele dia em diante estão mascaradas. Em 16/10/2026, não resta nenhuma entrada sem mascaramento em mouse_events (medido com a mesma consulta). As linhas afetadas foram excluídas em 17/08/2026 (avaliação de impacto, R2), isto é, antes da introdução dos arquivos em 18/08/2026; portanto, não podem estar nos arquivos nem no backup que os inclui desde 06/10/2026. As cópias criptografadas daquela época no Google Drive foram excluídas em 06/09/2026; não se conhece backup remanescente anterior a 17/08/2026, mas sua ausência não foi verificada em detalhe.

A.4 Reconhecimento do visitante entre sessões

Campo	Registro
Finalidade	Reconhecer um visitante entre sessões e visualizações de página.
Categorias de titulares dos dados	Visitantes dos sites dos clientes.
Categorias de dados pessoais	Identificador pseudônimo de visitante, gerado e mantido no localStorage do visitante em 'mp_visitor_id' (www/mp.js:5056-5059). Um identificador em claro definido pelo cliente — ID de login ou número de cliente — por MousePlayer.setUserId() (www/mp.js:4909-4913, localStorage 'mp_user_id') e automaticamente pelo caminho 'uid' do dataLayer (www/mp.js:3585-3637). Apelido e nome do navegador por visitante, mantidos ENTRE projetos (UNIQUE sobre visitor_id).
Onde são armazenados	visitor_sessions.visitor_id (varchar 64), custom_user_id (varchar 128, índice próprio idx_custom_user_id), nickname_key. visitor_nicknames (visitor_id, nickname_key, browser_name, city, created_at) — 329 linhas; a coluna city está vazia em todas as 329. consent_events.visitor_id.
Base legal (determinada pelo controlador)	Consentimento, como em A.1.
Categorias de destinatários	O cliente. Por custom_user_id, o cruzamento com os registros de clientes do próprio cliente é um uso expressamente pretendido.
Transferência para país terceiro	Nenhuma no caminho da gravação.
Retenção	Com a última sessão do visitante. mp_sitzungen_loeschen() (srv/db_worker.php) verifica após cada exclusão se resta alguma sessão daquele visitante e, caso contrário, remove o apelido; a via de exclusão no player faz o mesmo. A limpeza diária por nível chama a mesma função, portanto um registro órfão já não pode surgir. Não existe prazo separado, nem é necessário: a entrada nunca sobrevive às sessões que identifica.

A.5 Dados de rede e localização aproximada

Campo	Registro
Finalidade	Determinar a rede e a localização aproximada do visitante e determinar a região para a verificação de consentimento.
Categorias de titulares dos dados	Visitantes dos sites dos clientes.
Categorias de dados pessoais	Endereço IP (truncado no caminho da gravação, veja abaixo), código de país de dois caracteres, cidade (determinada a partir do endereço truncado, e não do completo), número ASN e nome do provedor, código de região.
Onde são armazenados	visitor_sessions.ip_address (varchar 45), country, city, asn_number, asn_org, region_code. ip_lifetime_stats (ip_address, first_seen, total_conns, total_msgs, total_traffic, total_uptime_sec) — 446 linhas.
Base legal (determinada pelo controlador)	Consentimento para a gravação. A determinação do país é deliberadamente realizada no servidor, para que nenhum terceiro seja contatado antes de existir consentimento (class/Server.class.php:941-944).
Categorias de destinatários	Nenhum destinatário externo. A resolução geográfica usa arquivos LOCAIS do MaxMind em cfg/maxmind/ (GeoLite2-City e GeoLite2-ASN; lidos em class/IP2CityLite.class.php e class/Server.class.php), que srv/geoip_update.sh baixa regularmente do MaxMind; nenhum dado de visitante é transmitido no processo. Os valores resolvidos são armazenados em visitor_sessions e visíveis ao cliente como o restante do registro da sessão.
Transferência para país terceiro	Nenhuma. Nenhuma chamada de saída no caminho da gravação.
Truncamento	O servidor WebSocket (class/Server.class.php, regra B) substitui o último octeto IPv4 por 'xxx' e o último grupo IPv6 por ':xxxx', imediatamente após determinar o endereço da conexão (atrás do nginx, de X-Forwarded-For, confiável somente a partir do par local) e, portanto, antes de qualquer consumidor. O endereço completo existe apenas transitoriamente na memória do servidor WebSocket, em contadores Redis que expiram após alguns segundos e — para endereços que acionam um bloqueio automático — durante o bloqueio (24 h) no Redis (mp_autoban:); a instância Redis grava seus dados em disco para persistência (AOF). Em 16/10/2026, nenhuma linha em visitor_sessions ou ip_lifetime_stats contém um endereço não truncado.
Retenção e constatação sobre dados legados	365 dias a partir de first_seen para ip_lifetime_stats, imposto pela execução diária em srv/db_worker.php; o valor fica em site_settings sob retention_ip_stats_days e é configurável na área administrativa. visitor_sessions está abrangido pela limpeza por nível. A constatação sobre dados legados está encerrada: medido em 17/08/2026, 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 (s_mptest_form_) — não são endereços de visitantes.

A.6 Registros de consentimento

Campo	Registro
Finalidade	Demonstrar o consentimento e cada alteração nele (art. 7(1) do GDPR).
Categorias de titulares dos dados	Visitantes dos sites dos clientes.
Categorias de dados pessoais	Estado (GRANTED, GRANTED_LATE, withdrawn, region_exempt), origem, data e hora; nome e versão da CMP; SHA-256 da string TC — deliberadamente não a própria string; sinal GPC; código de região; versão da configuração do projeto.
Onde são armazenados	consent_events (id, session_id, channelid, visitor_id, consent_state, consent_source, cmp_name, cmp_version, tcf_hash, gpc_signal, region_code, consent_config_version, occurred_at, created_at) — 120 linhas. visitor_sessions.consent_state, consent_source, consent_ts, cmp_name, cmp_version, tcf_hash, gpc_signal, region_code, consent_config_version, recording_offset_ms.
Base legal	Obrigação de demonstração, fundamentada em ai/migrations/018_consent.sql: o ônus de provar consentimento válido é do controlador, e sem log não há o que apresentar em uma disputa.
Categorias de destinatários	O cliente.
Transferência para país terceiro	Nenhuma.
Retenção	730 dias, contados a partir de the withdrawal. Tanto o prazo quanto o marco inicial ficam em site_settings (consent_evidence_days, consent_evidence_anchor) e são configuráveis na área administrativa; impostos pela execução diária em srv/db_worker.php. Na exclusão da sessão, a prova continua sem ser excluída, mas é despersonalizada: deve permanecer comprovável que uma decisão foi tomada (art. 5(2)), mas não é necessário saber quem a tomou. Somente registros aos quais nenhuma sessão ainda faz referência são excluídos — enquanto a gravação existir, sua prova deve existir, ou a gravação ficaria sem autorização.
Qualidade dos dados	671 de 706 sessões contêm consent_source='testdata' com consent_ts IS NULL, definido por ai/devdata/001_altsitzungen_markieren.sql. NÃO são provas genuínas de consentimento. Registros genuínos: 27 (api), 5 (gcm), 2 GRANTED_LATE (api), 1 withdrawn (gcm).
Exclusão na revogação	Opcional e desativada em todos os lugares: projects.consent_delete_on_withdraw=0 para todos os 7 projetos, avaliada em srv/db_worker.php:1067-1070. Portanto, uma revogação interrompe novas gravações, mas não exclui nada.

A.7 Eventos personalizados, sinais de frustração e erros de JavaScript

Campo	Registro
Finalidade	Gravar eventos definidos pelo cliente, sinais de frustração e erros de JavaScript que ocorram na página do cliente.
Categorias de titulares dos dados	Visitantes dos sites dos clientes.
Categorias de dados pessoais	Nome do evento — medido: dead_click 355, gtm.scrollDepth 290, rage_click 52, text_copied 26, text_selected 26, error_detected 22, consent_status 19, consented_ready 17, consented_update 8, mouse_thrashing 5, add_to_cart 3. Valores dos parâmetros — target 407, tag 386, desc 274, count 57, length 52, snippet 22, message 22, type 19, filename 9, lineno 9, masked_area 4, price 1, currency 1, item_id 1. Dois deles contêm mais do que o nome sugere: 'snippet' em text_copied e text_selected é o texto da página que o visitante selecionou ou copiou; 'filename' contém URLs completas e foi encontrado com um endereço moz-extension://, que é um identificador de extensão do navegador específico do dispositivo.
Onde são armazenados	session_custom_events (event_id, session_id, pageview_id, event_name, created_at) — 823 linhas. session_custom_event_params (param_id, event_id, param_key, param_string_value, param_int_value, param_float_value) — 1264 linhas.
Base legal (determinada pelo controlador)	Consentimento, como em A.1.
Categorias de destinatários	O cliente. Opcionalmente, por webhook para uma URL livremente escolhida pelo cliente — veja a seção 4.
Transferência para país terceiro	Pelo webhook, o destino é indeterminado e, portanto, potencialmente um país terceiro. Atualmente inativo: projects.webhook_active=0 e webhook_url NULL para todos os 7 projetos.
Retenção	Com a sessão pela limpeza diária e mp_sitzungen_loeschen() (prazo do nível; para bots, os prazos de A.1); session_custom_event_params está vinculado a session_custom_events por FOREIGN KEY ON DELETE CASCADE. Eventos de console, rede e Web Vitals em mouse_events como em A.1; mp_cwv é excluído com sua visualização de página (limpeza a cada hora).
Mensagens de console e requisições de rede (desde 30/09/2026)	O que a página escreve no console do navegador (o nível é definido pelo operador do site; padrão: erros e avisos) e requisições feitas pela página que falhem ou demorem mais que um limite configurado: método, endereço, código de status e duração. Nunca cabeçalhos nem o corpo de uma requisição ou resposta, nunca o conteúdo de objetos registrados, somente seu tipo. Os textos passam por um filtro antes do envio (endereços de e-mail, endereços IP, sequências longas de dígitos, tokens de acesso); os endereços perdem os valores dos parâmetros com nomes sensíveis. Requisições ao próprio MousePlayer não são capturadas. Armazenados como um evento de mouse em mouse_events (event_type con ou net), com a mesma retenção e cadeia de exclusão da gravação (A.1); exibidos no player junto à linha do tempo.
Tempos de carregamento e resposta (Web Vitals, desde 02/10/2026)	A rapidez com que a página carrega e reage para o visitante, medida no navegador por visualização de página: Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, First Contentful Paint e Time to First Byte. Além disso, uma descrição curta do maior elemento visível e do elemento da interação mais lenta, como em um clique (tipo, identificador, texto visível; em áreas mascaradas, somente o tipo). Nenhuma entrada, nenhum conteúdo de requisição. Armazenados como um evento de mouse em mouse_events (event_type cwv) e por visualização de página em mp_cwv, com a mesma retenção e cadeia de exclusão da gravação (A.1); exibidos na aba Web Vitals e no cabeçalho do player.

A.8 Características derivadas e linhas do tempo de sessões geradas por máquina

Campo	Registro
Finalidade	Derivar características por sessão e protocolos textuais gerados por máquina — pontuação de atipicidade e atenção.
Categorias de titulares dos dados	Visitantes dos sites dos clientes.
Categorias de dados pessoais	Vetor de características: duração, quantidade de páginas, profundidade de rolagem / mediana / inversões, pausas, eficiência do percurso, velocidade máxima, cliques de raiva e mortos, toques, zoom, origem e campanha, tempo de permanência por função do elemento (role_dwell_json), comportamento das abas. Avaliações: engagement_score (0-255), session_quality, is_bot. Uma linha do tempo da sessão em texto corrido — exemplo: 't=0.0 landing / src=(direct) kanal=direct attr=direct mode=unknown motion=unavailable viewport=1699x935 / t=2.0 session ende'.
Onde são armazenados	ai_session_features — 4043 linhas (uma linha por sessão E builder_version, portanto uma sessão aparece uma vez por versão). ai_timelines (timeline_id, session_id, channelid, builder_version, input_mode, line_count, char_count, pageviews, duration_s, text como mediumtext, built_at) — 3203 linhas, 5,5 MB. mp_session_ziel (channelid, session_id, goal_id, tag, ziel_fp, gebaut_am) — 628 linhas: qual sessão atingiu qual meta, calculado uma vez em vez de a cada requisição. ziel_fp é a impressão digital da regra da meta; quando o controlador a altera, o mapeamento é reconstruído, em vez de silenciosamente reutilizado. mp_hm_tag (channelid, tag, url_md5, url, titel, ansichten, engagiert) e mp_hm_tag_stand (channelid, tag, berechnet_am), desde 24/09/2026 (migração 148): para cada projeto, dia e endereço de página, a quantidade de visualizações de página e de visualizações engajadas, que alimenta a lista de mapas de calor de páginas. Somente contagens e endereços — nenhum identificador de visitante ou sessão; a quantidade de visitantes por endereço ainda é contada a partir das próprias sessões.
Base legal	Não documentada no código. Derivada da gravação e, portanto, abrangida indiretamente pelo consentimento obtido para ela. Instrução: surge com o cadastro do Cliente e é executada assim que ele instala o script no seu site e os visitantes são gravados (declaração do controlador, 17/08/2026). Derivar características, linhas do tempo e níveis de valor faz parte do serviço contratado. Duas partes são diferenciadas. Os níveis de valor são definidos pelo Cliente no seu próprio projeto; cada alteração é registrada (log_audit, save_wertregeln). Os resumos escritos pelo modelo de linguagem funcionavam até 17/08/2026 somente a partir de uma configuração global na área administrativa — o Cliente não tinha influência sobre ela, portanto não se baseavam na sua instrução. Desde a migração 041, projects.ki_texte_aktiv também decide, ativado por padrão; o Cliente pode desativá-lo a qualquer momento na aba de configurações, e cada alteração aparece como ki_texte_changed no log de alterações. O interruptor não é a instrução, mas o meio de limitá-la: ativado por padrão significa que o Cliente não o ativou, apenas deixou de desativá-lo.
Categorias de destinatários	O cliente (cfg/project_ai_overview.php).
Transferência para país terceiro	Nenhuma. As frases geradas são formuladas pelo modelo de linguagem no nosso próprio hardware em Łódź (seção 4); nada é enviado a um serviço externo de IA.
Retenção	Com a sessão. ai_session_features e ai_timelines fazem parte de mp_sitzungen_loeschen() (srv/db_worker.php) desde 12/08/2026 e, portanto, são removidos tanto na exclusão explícita quanto pela limpeza diária por nível. Esta célula antes dizia o contrário; aquela era a situação anterior à alteração. A pontuação por visitante e dia derivada deles (ai_visitor_value) e os textos gerados (ai_insights) também têm um prazo próprio — veja a seção 6.2.

A.9 Colaboração na reprodução — comentários e links de compartilhamento

Campo	Registro
Finalidade	Comentar uma reprodução em um marcador temporal e compartilhar uma reprodução por link.
Categorias de titulares dos dados	Usuários clientes (os autores) e, indiretamente, os visitantes gravados.
Categorias de dados pessoais	Texto do comentário (até 2000 caracteres), deslocamento temporal, autor. Token de compartilhamento (40 caracteres hexadecimais), criador, expiração, revogação, quantidade de acessos, último acesso.
Onde são armazenados	session_comments (comment_id, channelid, session_id, user_id, time_offset_ms, body, created_at, updated_at) — 12 linhas. session_shares (share_id, channelid, session_id, token, created_by, expires_at, revoked_at, last_seen, view_count, created_at) — 9 linhas.
Base legal	Não documentada no código. Instrução: o Cliente permite expressamente o compartilhamento, inclusive fora da sua própria organização, e assume a responsabilidade por ele (decisão do controlador, 17/08/2026). A instrução é documentada pelo próprio ato: o link é criado por um membro autorizado do espaço de trabalho do Cliente, e sua criação é registrada (log_audit, ação create_share; revogação como revoke_share). O MousePlayer fornece a função; a escolha dos destinatários e a licitude da divulgação cabem ao Cliente. Limites técnicos: cada link expira — 7 dias por padrão, no máximo 90 — e pode ser revogado a qualquer momento.
Categorias de destinatários	Qualquer pessoa que tenha um link de compartilhamento, SEM login (www/.htaccess:77). Tokens inventados, expirados e revogados retornam a mesma resposta, portanto não é possível sondar tokens para obter informações.
Transferência para país terceiro	Indeterminada por concepção — um link pode ser encaminhado a qualquer lugar. Essa é uma propriedade da funcionalidade, e não um incidente.
Retenção	Com a sessão: session_comments e session_shares fazem parte de mp_sitzungen_loeschen() desde 12/08/2026 e são excluídos com a sessão. Independentemente disso, os links de compartilhamento têm duração máxima própria: session_shares.expires_at é NOT NULL, mp_share_erstellen() (cfg/lib.php) usa 7 dias por padrão e limita a 90. A aplicação não pode criar um link ilimitado. Depois que um link expira ou é revogado, a limpeza diária exclui sua linha 90 dias depois; os acessos em share_views são excluídos com ela pela chave estrangeira (B.6).

A.10 Visualização ao vivo — assistir a uma sessão enquanto acontece

Campo	Registro
Finalidade	Observação de uma sessão em andamento em tempo real: lista ao vivo dos visitantes presentes, modo seguir com uma captura espelhada da página, posição transmitida do ponteiro e, desde 16/08/2026, estado reconstruído de passagem do ponteiro (:hover).
Categorias de titulares dos dados	Visitantes dos sites dos Clientes (observados), usuários clientes (observadores).
Categorias de dados pessoais	As mesmas categorias de A.1 e A.2 — posições do ponteiro e da rolagem, cliques, eventos de entrada, captura da página e suas alterações —, mas no momento em que surgem. Além disso, o identificador da sessão, para que o observador acompanhe a sessão correta.
Onde são armazenados	Não armazenados. O fluxo passa pelo servidor WebSocket (class/Server.class.php) e é encaminhado dentro do processo aos observadores conectados. O token de acesso é mantido na tabela do banco de dados live_tokens (identificador, projeto, ID de usuário, quando aplicável a sessão acompanhada, horário da última confirmação). Desde 17/09/2026, o player de uma sessão em andamento também se conecta a esse fluxo com seu próprio acesso (identificador com o prefixo pl_, vinculado à sessão acompanhada), para exibir seus eventos sem demora. A gravação da mesma sessão é criada independentemente por A.1 e A.2.
Base legal	Instrução: a observação é iniciada por um membro autorizado do espaço de trabalho do Cliente; o acesso ocorre por um token com prazo limitado em live_tokens vinculado ao seu ID de usuário. O usuário final não é notificado separadamente no momento da observação (decisão do controlador, 17/08/2026). A notificação ocorre previamente: pelo consentimento que antecede qualquer gravação e pela política de privacidade, que, desde 17/08/2026, declara expressamente que uma sessão em andamento pode ser acompanhada em tempo real. Até então, ela mencionava a visualização ao vivo somente como funcionalidade em uma lista — portanto, a decisão se baseava em uma frase que ainda não existia.
Categorias de destinatários	O Cliente, limitado aos membros autorizados do espaço de trabalho.
Transferência para país terceiro	Nenhuma.
Retenção	O próprio fluxo não é armazenado. O servidor WebSocket remove uma linha em live_tokens após o encerramento da visualização, com um curto período de carência para recarregar; um acesso que deixa de ser confirmado perde seu efeito após pouco tempo e é limpo posteriormente.

Esta entrada estava ausente do registro até 17/08/2026. Deve ser mantida separada de A.1 e A.2, embora os mesmos dados circulem: ali são reproduzidos depois; aqui, uma pessoa observa no momento em que o visitante age. Essa simultaneidade é precisamente a característica que o art. 35(3) enfatiza ao definir o monitoramento sistemático, e a DPIA fundamenta nela sua própria necessidade.

A.11 Log de entrega das integrações

Campo	Registro
Finalidade	Prova e diagnóstico das transmissões listadas em 4.1. Sem isso, o controlador não consegue saber se uma ponte funciona — uma falha seria silenciosa do seu lado.
Categorias de titulares dos dados	Visitantes dos sites dos clientes, na medida em que o controlador tenha definido um ID de cliente para eles. Sem ID definido, a entrada não contém referência pessoal.
Categorias de dados pessoais	Data e hora, tipo de ponte, um identificador (o ID de cliente fornecido pelo controlador por setUserId, a rede de publicidade ou o nome do evento), sucesso ou falha, duração em milissegundos, número da tentativa e o texto de resposta ou erro do destinatário. Esse texto pode conter um ID de registro do sistema de terceiros. Nenhum dado comportamental, nenhum conteúdo de página, nenhum endereço IP.
Onde são armazenados	Redis, chave mp_webhook_log:<channelid>. As últimas 25 entradas por projeto; as mais antigas saem por lTrim. Não no banco de dados e, portanto, não no backup diário.
Base legal (determinada pelo controlador)	Como em A.1. A entrada só passa a existir se o controlador ativou uma ponte — é o registro da execução da sua própria instrução.
Categorias de destinatários	O controlador, pelas configurações do projeto (aba Integrações). Nenhuma divulgação posterior.
Transferência para país terceiro	Nenhuma. A entrada não sai do nosso próprio servidor.
Retenção	30 dias. Definida como expiração no Redis ao gravar; também limitada a 25 entradas por projeto. Expira por conta própria e não precisa de execução de eliminação. O número fica em site_settings.retention_intlog_days e é ajustável na área administrativa.

A.12 Perfis comportamentais — agrupamento automatizado de visitas

Campo	Registro
Finalidade	Agrupamento automatizado das VISITAS gravadas segundo seu percurso, para que o controlador não precise examinar uma sessão após outra, mas veja grupos — e possa reproduzir uma visita típica por grupo. Paralelamente, sequências recorrentes de páginas e eventos dentro da janela de cálculo.
Categorias de titulares dos dados	Visitantes dos sites dos clientes. O que é agrupado são VISITAS, e não pessoas: a mesma pessoa com duas visitas pode ficar em dois grupos, e a interface usa essa redação. Não é calculado um perfil por PESSOA — isso exigiria o identificador de cliente fornecido por setUserId, e 0 de 4226 sessões têm um (medido em 27/08/2026).
Categorias de dados pessoais	Nenhuma categoria nova. O vetor de características de A.8, reduzido às sete características com preenchimento acima de 90 %: duração, quantidade de páginas, pontuação de atenção, pausas, cliques de raiva, cliques mortos, mudanças de aba. Derivados delas: a qual grupo uma sessão pertence e sua distância do centro do grupo. Por grupo, adicionalmente o ID de sessão da visita mais típica e da menos típica, para que ambas possam ser reproduzidas. Para as sequências: a cadeia de padrões de caminhos e nomes de eventos e até três IDs de sessão como exemplos. Nenhum conteúdo de página, nenhum endereço IP, nenhuma entrada de formulário.
Onde são armazenados	mp_profile — uma linha por canal e grupo (tamanho, participação, centro, indicadores, nome calculado, nome atribuído pelo próprio cliente, representante, caso atípico); 15 linhas. mp_profil_sitzung — sessão para grupo mais distância; 4226 linhas. mp_sequenzmuster — cadeia, suporte, lift, até três exemplos; 115 linhas. Os três são DERIVAÇÕES: podem ser perdidos e recalculados a qualquer momento e não contêm nenhum dado bruto que não exista também em outro lugar. Desde 06/09/2026, mp_profil_sitzung também contém a chave da pessoa (person_key, migração 112): uma cópia da chave de A.4 (ID de cliente, caso contrário ID de visitante), que a execução dos perfis atualiza diariamente; a lista de visitantes recorrentes é calculada a partir dela. Contagens de linhas desta entrada: em 27/08/2026.
Base legal	Como em A.8. Derivados da gravação e, portanto, sustentados indiretamente pelo consentimento obtido para ela. Instrução: parte do serviço contratado; surge com o cadastro do cliente e é executada assim que os visitantes são gravados. Dois limites merecem ser indicados. O agrupamento é CALCULADO, e não gerado: a qual grupo uma visita pertence é decidido por k-means sobre as sete características em ai/profile.py, e os nomes dos grupos vêm da posição relativa do centro, e não de um texto. Quando um modelo de linguagem escreve uma frase sobre um grupo, recebe somente os números do GRUPO — percentuais e médias —, nunca um ID de sessão ou visitante, e o mesmo verificador de A.8 rejeita qualquer número que não esteja entre esses valores. Não existe, porém, interruptor por projeto: profile_aktiv é uma configuração global do operador do sistema, e a seleção por projeto de seções de IA (projects.ki_module) não abrange esta aba. Registrado como lacuna na seção 10.
Categorias de destinatários	O cliente, pela aba Perfis Comportamentais (cfg/project_profiles.php). Nenhuma transferência a terceiros: a participação em grupos não entra em nenhuma das pontes de 4.1. Verificado por uma busca de profil_key em cfg/, srv/, www/ e class/ — ocorre somente na via de leitura e no player, nem em www/mp.js nem em class/Server.class.php, portanto também nunca chega ao navegador do visitante.
Transferências para países terceiros	Nenhuma. O cálculo ocorre na mesma máquina (ai/profile.py, iniciado por srv/ai_worker.php). A frase opcional por grupo é formulada pelo modelo de linguagem em uma das nossas próprias máquinas com placa de vídeo na mesma rede local (veja a seção 4), que obtém somente os números do grupo, por HTTPS. Nada é enviado a um serviço externo de IA.
Retenção	Com a sessão: mp_profil_sitzung faz parte de mp_sitzungen_loeschen(). Além disso, 180 dias, contados do INÍCIO DA SESSÃO, e não do horário do cálculo — a execução diária o atualiza a cada passagem, portanto um prazo vinculado a ele nunca expiraria, sem que ninguém percebesse. Linhas cuja sessão já não existe são removidas sem prazo algum, porque qualquer prazo recai sobre uma linha que já desapareceu. O número fica em site_settings.retention_profile_days, é ajustável na área administrativa e elevado a pelo menos a janela de cálculo, para que a execução de exclusão não remova o que a execução dos perfis gravou no mesmo dia. mp_profile é eliminado assim que não resta atribuição alguma para ele, na mesma execução noturna — por isso esta declaração vem depois das duas acima. mp_sequenzmuster é eliminado após 180 dias sem novo cálculo e imediatamente quando seu canal já não tem nenhuma sessão. Nesse caso, o marco inicial É o horário do cálculo, corretamente: diferentemente de uma atribuição, um padrão descreve a janela ATUAL e é reescrito integralmente por canal a cada execução, portanto um horário recente realmente significa „descreve os dados de hoje“.

A.13 Nome personalizado de um visitante — atribuído pelo controlador

Campo	Registro
Finalidade	O controlador dá a um visitante individual um nome próprio para reconhecê-lo em listas e gravações. O nome substitui o apelido gerado de A.4 em todos os lugares em que apareceria. A ocasião é o caso de suporte: „este é o cliente que ligou“.
Categorias de titulares dos dados	Visitantes dos sites dos clientes — especificamente, indivíduos escolhidos pelo controlador. Diferentemente de A.1 a A.12, esse tratamento não surge por conta própria quando alguém abre a página; exige uma entrada deliberada. Sem essa entrada, não existe linha: em 28/08/2026, 0 de 3830 visitantes têm nome próprio.
Categorias de dados pessoais	TEXTO LIVRE de no máximo 64 caracteres, mais horário e conta de usuário da atribuição. A referência é o identificador de visitante de A.4. O conteúdo não é prescrito nem verificado — pode ser um número de contrato, um apelido ou um nome em claro junto com um departamento. Isso distingue este tratamento de todos os demais da Parte A: ali, os dados vêm do visitante ou são calculados do seu comportamento; aqui, o controlador os digita. Indicado como lacuna na seção 10.
Onde são armazenados	visitor_nicknames.custom_label, label_set_at, label_set_by (migração 093) — a mesma linha que já contém o apelido gerado, uma por visitante, 3830 linhas. Deliberadamente, não em tabela própria: o nome substitui exatamente o apelido armazenado ali, está vinculado à mesma chave e, portanto, é eliminado com ela sem ação adicional. Uma tabela separada seria um quinto lugar na cadeia de exclusão, que poderia ser esquecido.
Base legal	Instrução do controlador (art. 28(3)(a)), dada pela própria entrada — nenhuma tarefa nem configuração padrão cria um nome. Se existe base legal para o conteúdo inserido, o MousePlayer não consegue julgar: o controlador escolhe o texto e conhece o contexto de onde ele é extraído. A dica no campo de entrada indica, portanto, a finalidade („somente sua equipe vê este nome“), e não apenas o campo.
Categorias de destinatários	O cliente, nas suas próprias listas e no player. Nenhuma divulgação a terceiros: o campo não entra em nenhuma das pontes de 4.1 — verificado por busca de custom_label em cfg/, srv/, www/ e class/; não aparece nem em www/mp.js nem em class/Server.class.php e, portanto, também nunca chega ao navegador do visitante. O link de compartilhamento (B.6) deliberadamente NÃO o mostra, mas mostra o apelido gerado: transmitir um link que não exige login compartilha uma gravação, e não a identidade por trás dela. A mesma consideração de www/selbstauskunft.php.
Transferências para países terceiros	Nenhuma. O campo sai do banco de dados somente para a interface do cliente autenticado.
Retenção	Com a última sessão do visitante, como a linha em que fica: mp_sitzungen_loeschen() remove essa linha assim que não existe mais sessão para esse identificador de visitante — em ambas as vias, a execução diária de exclusão e a exclusão da conta. Nenhum prazo de calendário próprio, intencionalmente: um prazo sobre o nome significaria excluí-lo enquanto o visitante ainda está presente e sendo gravado. O controlador pode removê-lo a qualquer momento; um campo vazio o exclui, e o apelido gerado volta a valer.

A.14 Importação do Google Analytics 4 — números e sessões da própria conta do controlador

Campo	Registro
Finalidade	O controlador manda buscar dados da sua própria conta do Google Analytics 4 para o MousePlayer. Duas vias, cada uma ativada separadamente: a Data API retorna somente totais diários e responde à questão da cobertura — o GA4 conta 3.000 sessões em um dia, o MousePlayer gravou 40, e, sem esse número de referência, a diferença não pode ser explicada nem sequer percebida. A importação do BigQuery lê a exportação bruta da propriedade e armazena sessões individuais do GA4 com seus eventos, permitindo ver o que aconteceu durante uma visita que o MousePlayer não conseguiu gravar.
Categorias de titulares dos dados	Visitantes dos sites dos clientes — as mesmas pessoas de A.1, apenas observadas por um segundo sistema de medição. O que distingue isso de A.1 a A.13 é a origem: esses dados não foram coletados aqui. Já estão na conta Google do controlador, e o MousePlayer os busca. A via Data API, além disso, não diz respeito a nenhuma pessoa individual; retorna somente totais diários.
Categorias de dados pessoais	Para a via Data API: nenhuma — quatro números por dia (sessões, usuários, visualizações de página, sessões engajadas), sem qualquer referência pessoal. Para a via BigQuery, por sessão GA4: o identificador pseudônimo user_pseudo_id, isto é, o ID de cliente do cookie _ga; início, fim e duração; quantidade de eventos e visualizações de página; caminho de entrada; categoria de dispositivo e país; mais origem, mídia e campanha. Além disso, por nome de evento, um contador, a última data e hora e, quando o GA4 informa um, um valor somado. Nenhum endereço IP, nenhuma captura de página, nenhum movimento do mouse — o GA4 não contém nenhum deles, e nenhum é gerado. Portanto, uma sessão importada nunca pode ser reproduzida.
Onde são armazenados	ga4_daily, ga4_sessions e ga4_events (migração 097) — três tabelas SEPARADAS. Deliberadamente, não em visitor_sessions, session_pageviews ou session_custom_events. Isso não é organização por capricho: essas três tabelas não têm coluna que indique a origem de uma linha, porque tudo nelas foi medido aqui. Uma linha importada seria indistinguível de uma medida e, com isso, o significado de cada número derivado mudaria silenciosamente — os perfis comportamentais de A.12, a valoração por visitante, a análise de atrito. Por isso, a importação fica ao lado dos dados medidos, como ai_visitor_value e mp_profile já ficam.
Base legal	Instrução do controlador (art. 28(3)(a)), dada ao ativar a respectiva via e fornecer uma conta de serviço dedicada. A coleta original no Google é responsabilidade do controlador, e não do MousePlayer: aconteceu antes de qualquer busca aqui e não pode ser verificada posteriormente. Ainda assim, existe uma barreira técnica — somente linhas contendo um user_pseudo_id são importadas. Quando o consentimento é negado, o GA4 envia hits sem cookies no Consent Mode, e eles não o contêm; são excluídos mecanicamente, e não com base em uma garantia. Isso é um indício, e não uma prova, e está registrado assim entre as lacunas da seção 10.
Categorias de destinatários	Nenhum novo. A via BUSCA, não entrega: nenhum dado de visitante sai da nossa infraestrutura. O destinatário é o cliente, na sua própria interface. O Google aparece aqui não como destinatário, mas como FONTE — de uma conta que o controlador opera e cujo conteúdo determina.
Transferência para país terceiro	Nenhuma transferência de dados de visitantes. A requisição vai para analyticsdata.googleapis.com e para o BigQuery; o que é transmitido é a credencial da conta de serviço e o texto da consulta, e não dados de visitantes. Os dados fluem na direção oposta. Onde os dados GA4 ficam no Google e sob quais salvaguardas depende da própria conta do controlador e é matéria do seu contrato com o Google, não deste registro.
Retenção	180 dias, contados do dia que a linha DESCREVE (ga4_daily.tag, ga4_sessions.start_time), e não do momento da importação. Este é atualizado a cada execução, porque o GA4 preenche dados retroativamente por até 48 horas, e os mesmos dias são buscados novamente; um prazo vinculado a ele nunca expiraria. Imposto pela execução diária em srv/db_worker.php, eventos antes das respectivas sessões. Uma solicitação de eliminação do art. 17 também os abrange desde 01/09/2026, na medida em que a linha possa ser atribuída pelo identificador de cliente; a execução de exclusão por nível NÃO — os dados GA4 seguem seu próprio relógio, e um cliente no nível gratuito, de outro modo, os perderia após 7 em vez de 180 dias. Com o projeto, são excluídos em qualquer caso, incluindo as linhas que nunca pertenceram a uma das nossas sessões. O que isso não alcança está apresentado na seção 10.

A.15 Previsão de saída e a oferta que pode acionar

Campo	Registro
Finalidade	Estimar, a partir dos primeiros segundos de uma visita, a probabilidade de o visitante sair em breve sem uma segunda visualização de página. O controlador pode vincular uma oferta a essa estimativa, exibida ao visitante no SEU site. Diferentemente de A.8 a A.14, esse tratamento não termina em uma análise para o cliente, mas repercute no visitante — por isso tem entrada própria, em vez de ser um subitem de A.8. Além disso, o controlador pode solicitar propostas de texto e design dessa oferta: um modelo de linguagem os redige a partir do contexto do seu site. Uma proposta nunca entra em operação por conta própria; só é adotada, parte por parte, pelo controlador.
Categorias de titulares dos dados	Visitantes dos sites dos clientes, e somente na PRIMEIRA visualização de página de uma sessão: uma visualização posterior já não é uma chegada e não recebe pontuação. Nada disso funciona sem consentimento — a pontuação fica após a mesma barreira da gravação.
Categorias de dados pessoais	Dezesseis características medidas da visita atual, todas formadas no navegador: dispositivo (celular sim/não), visitante recorrente, clique pago, mecanismo de busca, rede social, entrada na página inicial, profundidade do caminho da página de entrada, horário noturno, quantidade de movimentos do mouse, eventos de rolagem e clique na janela, segundos até a primeira entrada, posição mais profunda de rolagem como percentual da página, quantidade de inversões de rolagem, se a aba perdeu o foco e se não houve entrada alguma. Delas resulta UM percentual e até três motivos em linguagem simples. Nenhum conteúdo, nenhuma coordenada, nenhum valor de campo. O marcador mp_seen_before no armazenamento local do navegador registra que o visitante já esteve aqui; mp_offer_<date> conta quantas vezes uma oferta foi exibida a ele hoje. A proposta de oferta não acrescenta informações sobre visitantes individuais, mas sobre o site: título, descrição, cabeçalhos e navegação de no máximo dez capturas de página, os no máximo 40 endereços que visitantes humanos abriram pelo menos cinco vezes em 30 dias, a participação dos idiomas das páginas e as cores, o arredondamento dos cantos e a fonte do fundo da página e do botão mais frequente, medidos no navegador. Para isso, o idioma é registrado por visualização de página (o atributo lang da página). Endereços e cabeçalhos podem conter tudo o que o próprio site apresenta (veja A.17).
Onde são armazenados	O MODELO em projects.exit_modell (migração 100) — pesos, médias, desvios, qualidade e horário do treinamento; não contém dados pessoais, apenas números sobre a população. O RESULTADO por visita como evento em session_custom_events: exit_risk com o percentual e os motivos, mais exit_offer_shown, exit_offer_click e exit_offer_dismiss quando uma oferta foi exibida. O valor mais recente também é mantido transitoriamente no registro da conexão do servidor WebSocket (Redis, mp_websockets), para que a visualização ao vivo possa exibi-lo; desaparece com a conexão. A proposta de oferta é armazenada em projects.exit_offer_vorschlag (migração 114), as medições de design como as últimas 60 por canal no Redis (mp_design:<channel>), o idioma da página em session_pageviews.lang. Para a formulação, o contexto passa por ai_ki_queue para nossas próprias máquinas que executam o modelo de linguagem (seção 4).
Base legal	Instrução do controlador. O treinamento é por projeto e somente sobre as sessões do próprio projeto, pelo menos 200; abaixo disso, nenhum modelo é criado. O consentimento do visitante abrange a gravação de onde vêm as características — a mesma base de A.8. Somente o controlador decide se uma oferta é exibida; para essa exibição no seu site, ele é o controlador, e não nós.
Categorias de destinatários	O cliente na sua interface. O percentual e os motivos também chegam ao NAVEGADOR DO VISITANTE — são formados ali, em vez de enviados para lá — e estão disponíveis ao código do próprio controlador por MousePlayer.on('exit_risk') e pela camada de dados. Uma oferta que apareça então é vista pelo próprio visitante. Uma proposta de oferta é vista somente pelo controlador na sua interface; só chega ao site depois que ele a adota. Nada é enviado a terceiros.
Transferência para país terceiro	Nenhuma. O treinamento e a pontuação ocorrem na infraestrutura em Łódź ou no navegador do visitante. A proposta de oferta é formulada pelo modelo de linguagem no nosso próprio hardware em Łódź (seção 4); nada é enviado a um serviço externo de IA.
Retenção	Os eventos compartilham a retenção da sessão à qual pertencem (A.7) e são excluídos com ela. O modelo é sobrescrito a cada execução; não existe histórico. Os dois marcadores ficam no armazenamento local do visitante: mp_seen_before sem expiração até ele limpá-lo ou revogar seu consentimento, mp_offer_<date> somente para o dia atual (mp.js remove entradas mais antigas na próxima vez em que define uma). Além disso, mp_design_sent no armazenamento de sessão da aba registra que o design já foi medido. Na revogação, mp.js remove os três. A proposta de oferta permanece até uma nova substituí-la; as medições de design expiram no Redis após 30 dias; o idioma da página compartilha a retenção da sua visualização de página.

A.16 Indicador de perda para visitantes recorrentes

Campo	Registro
Finalidade	Estimar, a partir das visitas anteriores da mesma pessoa, se ela está se afastando, para que o controlador possa reagir. Diferentemente de A.15, esta avaliação não considera a visita atual, mas o histórico.
Categorias de titulares dos dados	Visitantes recorrentes dos sites dos clientes com pelo menos 2 sessões. Quem veio uma vez não recebe linha. A chave é a pessoa no sentido de A.4 — o identificador de cliente definido pelo controlador; caso contrário, o identificador de visitante.
Categorias de dados pessoais	Um valor de risco entre 0 e 1, até quatro motivos em linguagem simples de uma lista fixa (queda do engajamento, visitas curtas, atrito, atraso; uma compra nas últimas duas visitas reduz o valor), quantidade de visitas e horário da última. Nenhum conteúdo, nenhuma coordenada. Não é um modelo aprendido, mas quatro observações contáveis — cada uma consta na linha como motivo, de modo que um valor nunca aparece sem um.
Onde são armazenados	ai_churn (migração 100): channelid, person_key, visitor_id, risiko, gruende, sitzungen, letzte_sitzung, berechnet_am. Além disso, um hash Redis por canal, mp_churn:<channel>, que expira após dois dias, do qual o servidor WebSocket lê ao conectar; somente aqueles acima do limite são colocados ali.
Base legal	Instrução do controlador; as sessões subjacentes se baseiam no consentimento do visitante (A.1). Calculado por projeto, nunca entre clientes.
Categorias de destinatários	O cliente na sua interface. O valor também é enviado ao NAVEGADOR DO VISITANTE assim que ele conecta e fica disponível ao código do próprio controlador por MousePlayer.on('churn_risk'); ele pode vincular uma oferta a esse valor. Essa transferência ao dispositivo do próprio titular dos dados é a razão pela qual esta entrada está aqui, e não em A.8. Nada é enviado a terceiros.
Transferência para país terceiro	Nenhuma.
Retenção	A linha é reescrita para o canal a cada execução e é excluída com as sessões de onde vem. A entrada Redis expira por conta própria após dois dias.

A.17 Relatório resumido sobre um visitante

Campo	Registro
Finalidade	Reunir todas as visitas de UMA pessoa em um relatório legível: de onde veio, o que foi pago, onde encontrou dificuldades e se resultou em uma meta. Os resultados são calculados; um modelo de linguagem, no máximo, os reformula. Um relatório é solicitado pelo cliente para um visitante específico ou automaticamente para no máximo 5 visitantes por projeto e noite — escolhidos entre visitas pagas sem compra.
Categorias de titulares dos dados	Visitantes dos sites dos clientes para os quais existe mais de uma visita. A chave é a pessoa no sentido de A.4.
Categorias de dados pessoais	No máximo quatorze resultados calculados em forma textual: quantidade de visitas e páginas, período, dispositivos, origem incluindo campanha, compras e metas atingidas, os três maiores gargalos com seu caminho, a última sessão e os RÓTULOS dos elementos clicados (até cinco, 60 caracteres cada). Além disso, o texto gerado. Valores de campos de formulário não estão entre eles — nunca saem do navegador. Rótulos e caminhos, por outro lado, vêm do que o próprio site do controlador apresenta e, portanto, podem conter um nome ou endereço quando ele os exibe ali ou os escreve na URL; registrado como lacuna na seção 10.
Onde são armazenados	ai_besucher_bericht (migração 100) com channelid, person_key, lang, os resultados, seu hash, o texto e o nome do modelo. Para a formulação, os RESULTADOS — e não a gravação — passam por ai_ki_queue para as máquinas que executam o modelo de linguagem (hardware próprio na mesma rede local, veja a seção 4). Cada relatório consome uma cota (ai_ki_kontingent por espaço de trabalho e mês, 3 no plano gratuito; caso contrário, 200).
Base legal	Instrução do controlador; as sessões subjacentes se baseiam no consentimento do visitante (A.1). O modelo de linguagem não é treinado nem modificado; somente formula.
Categorias de destinatários	O cliente na sua interface. O visitante não fica sabendo de nada — diferentemente de A.15 e A.16, nada aqui repercute sobre ele.
Transferência para país terceiro	Nenhuma. O modelo de linguagem funciona no nosso próprio hardware em Łódź (seção 4); nada é enviado a um serviço externo de IA.
Retenção	180 dias a partir da solicitação, impostos pela passagem de acompanhamento do processo de IA. Se a última sessão do visitante for eliminada antes, o relatório é eliminado com ela.

A.18 Autoatendimento de acesso do visitante e solicitação de eliminação

Campo	Registro
Finalidade	Mostrar ao visitante o que está armazenado sobre ele e permitir que solicite a eliminação — assistência ao controlador com os direitos dos titulares dos dados nos termos do art. 28(3)(e) do GDPR. Acessível em /my-data, /meine-daten e /moje-dane.
Categorias de titulares dos dados	Visitantes dos sites dos clientes, e somente aqueles que fornecem seu próprio identificador. O controlador deve colocar o link; para seus visitantes, ele é o controlador, e o aviso do art. 13 deve constar na sua própria política.
Categorias de dados pessoais	São mostrados a quantidade, o período e os domínios das sessões — nenhuma gravação. O identificador é um token ao portador; quem conhece o de outra pessoa não deveria conseguir ver o comportamento de um desconhecido. Pelo mesmo motivo, a resposta permanece no DISPOSITIVO e não usa mp_person_sql() para reunir o que pertence a uma pessoa: a união divulgaria MAIS, e não menos. Da solicitação de eliminação, armazenamos o identificador, o horário da solicitação e o horário da execução.
Onde são armazenados	visitor_deletion_requests (visitor_id, requested_at, done_at) — 0 linhas. A própria página não armazena nada; lê. A solicitação é executada pelo worker pela mesma cadeia de exclusão acionada pelo controlador — uma segunda via de exclusão seria um segundo lugar para a mesma verdade.
Base legal	Art. 28(3)(e) do GDPR (assistência ao controlador) e sua instrução. O formato do identificador é verificado (^v_[a-z0-9]{9}_\d{13}$); qualquer outra coisa é recusada.
Categorias de destinatários	O próprio visitante. Nada é enviado ao cliente — ele só fica sabendo de uma solicitação de eliminação porque as sessões desaparecem.
Transferência para país terceiro	Nenhuma.
Retenção	A linha permanece como prova de que a eliminação ocorreu e de quando ocorreu. Não contém dados comportamentais. Quando um backup é restaurado, as solicitações registradas são executadas novamente antes de o sistema voltar à operação (cláusula 24.2 dos Termos de Serviço).

A.19 Revisão posterior da detecção de bots — decisões do operador do sistema como exemplos de aprendizagem

Campo	Registro
Finalidade	Sessões marcadas retroativamente como bots pela detecção de ondas são verificadas novamente por um monitor, e casos duvidosos são comunicados nos Logs Urgentes. O operador do sistema decide ali com um clique: Humano ou Bot. Cada decisão se torna um exemplo de aprendizagem a partir do qual os pesos dos sete sinais são recalculados — somente os pesos, e não o limite, e apenas a partir de uma quantidade mínima de decisões configurável na área administrativa (bot_revision_lern_min). Abaixo disso, aplicam-se valores fixos.
Categorias de titulares dos dados	Visitantes dos sites dos clientes cuja sessão foi comunicada como caso duvidoso e a pessoa que decidiu (equipe do cliente ou nossa).
Categorias de dados pessoais	Nenhum conteúdo de visitante. São armazenados o canal, o identificador da sessão, a decisão, a pontuação, os nomes dos sinais aplicáveis (por exemplo: identificador diverge da onda, referência de origem presente, endereço de uma rede privada) e o identificador de quem decidiu. O vetor de características faz parte do exemplo porque a própria sessão desaparece após seu prazo de retenção, e a aprendizagem ainda precisa dele.
Onde são armazenados	bot_review_labels (migração 140): uma linha por sessão; quem muda de ideia sobrescreve. É lido por cfg/bot_revision_lib.php. Sem a tabela, os monitores funcionam com pesos fixos.
Base legal	Instrução do controlador; A.1 se aplica às próprias sessões. O procedimento melhora a separação entre bots e humanos e, assim, a exatidão das análises (art. 5(1)(d) do GDPR). Nenhuma decisão sobre o visitante depende dele; uma liberação retira a marcação de uma sessão, nada mais.
Categorias de destinatários	Nenhum fora da interface; os exemplos são visíveis somente ao operador do sistema.
Transferência para país terceiro	Nenhuma.
Retenção	Padrão: nenhuma exclusão automática — um exemplo é pseudônimo e não contém conteúdo de visitante, e seu valor cresce com o acervo. O prazo pode ser definido em anos na área administrativa (retention_bot_labels_years, 0 = ilimitado); a partir de 1, o monitor de status (srv/cron_status.php) exclui linhas após essa quantidade de anos. Não participa de nenhuma cadeia de exclusão de sessões: quando a sessão desaparece, o exemplo permanece — intencional, mas registrado como lacuna na seção 10.

A.20 Rastreamento de elementos — cliques em elementos marcados da página

Campo	Registro
Finalidade	No assistente de elementos, o controlador marca elementos das suas páginas — individualmente ou como grupo de elementos semelhantes, por seletor CSS — e recebe cliques, sessões com clique, visitantes e taxa de cliques para cada marcação. A contagem é retroativa: srv/element_worker.php atribui cliques já gravados (A.1, mouse_events_analytik) ao elemento marcado na captura da sua própria visualização de página. Uma marcação também pode ser uma meta ou etapa de funil; suas ocorrências contam então como meta ou etapa atingida.
Categorias de titulares dos dados	Visitantes dos sites dos clientes cujos cliques foram gravados.
Categorias de dados pessoais	Um complemento da gravação de cliques (A.1), sem outra coleta nova: quando um visitante clica em um elemento que só apareceu após a captura (por exemplo, um menu aberto ou um pop-up), mp.js desde 27/09/2026 também envia sua estrutura — tag, classes, alguns atributos (role, type, name, caminho do link sem consulta, data-*), a posição entre elementos irmãos do mesmo tipo e o rótulo visível; em áreas mascaradas, somente tag e identificador. É armazenado com os eventos da visualização de página (A.1) e compartilha sua retenção. Para cada ocorrência, são armazenados: identificadores de canal, sessão e visualização de página, início da sessão, tipo de clique (click ou tap), rótulo visível do elemento atingido, extraído da captura — mascarado exatamente como consta na gravação — e, se o controlador escolher, o valor de um atributo desse elemento (por exemplo, data-id) para o detalhamento. Desde 27/09/2026, o worker de elementos mantém uma anotação dos cliques cujo alvo está ausente da captura e para os quais nenhuma estrutura foi enviada (cliques mais antigos): canal, identificador de sessão e visualização de página, horário e um hash do caminho da página e do rótulo — o próprio rótulo não é armazenado ali. A partir de cliques resolvidos, aprende, por marcação, qual rótulo em qual caminho de página corresponde à marcação (caminho, rótulo, dois contadores, nenhum vínculo com visitante). Quando todas as observações concordam, um clique anotado é atribuído como ocorrência — marcada como transferida — ou como não ocorrência. A própria marcação (nome, seletor, área da página) e os contadores diários de cobertura não contêm referência a visitante.
Onde são armazenados	mp_element_regeln, mp_element_klicks e mp_element_tag (migração 152), mp_element_offen e mp_element_muster (migração 155). Lidos por cfg/element_lib.php.
Base legal	Instrução do controlador (art. 28(3)(a) do GDPR), dada ao criar uma marcação; A.1 se aplica aos próprios cliques. A avaliação resume gravações existentes; o único acréscimo é a estrutura dos alvos de cliques criados após a captura (acima), que descreve o mesmo que a captura da página. Nenhuma decisão sobre o visitante depende dela.
Categorias de destinatários	Nenhum fora da interface enquanto a marcação é apenas avaliada. Se o controlador a usa como meta ou etapa de funil, as metas atingidas e os abandonos de funil seguem para as transmissões que ele ativou (4.1) — com o identificador da sessão, o nome da meta ou funil e o rótulo do elemento clicado, e somente para cliques não mais antigos que o definido na área administrativa (padrão de duas horas). Ocorrências mais antigas contam na interface, mas não são transmitidas.
Transferência para país terceiro	Nenhuma.
Retenção	Uma ocorrência é excluída com a sessão de onde vem: mp_element_klicks faz parte da cadeia de exclusão (mp_sitzungen_loeschen() em srv/db_worker.php), e o worker de elementos remove ocorrências cuja visualização de página já não existe a cada hora — portanto, também após vias de exclusão fora dessa cadeia, no máximo em uma hora. Cliques anotados (mp_element_offen) são excluídos com sua sessão pelas mesmas vias. Excluir uma marcação exclui suas ocorrências, contadores, anotações e padrões; os padrões não contêm vínculo com visitante e também são excluídos com uma alteração do seletor ou após um ano sem nova observação. Deliberadamente, não existe prazo separado: seria maior ou menor que o da gravação, e ambos seriam incorretos.

A.21 Pesquisas de feedback — uma pergunta ao visitante, a resposta junto à gravação

Campo	Registro
Finalidade	O controlador faz aos visitantes do seu site uma pergunta curta — probabilidade de recomendar de 0 a 10, cinco carinhas, sim/não ou uma escolha — e, se desejar, uma pergunta complementar em texto livre. A resposta é vinculada à visita para que ele possa assistir às gravações dos visitantes insatisfeitos. Pergunta, momento, participação de visitantes e idioma são definidos pelo controlador.
Categorias de titulares dos dados	Visitantes dos sites dos clientes aos quais uma pesquisa foi exibida — segundo uma amostra definida pelo controlador e no máximo uma vez por intervalo definido pelo controlador — e visitantes que abriram uma pesquisa por conta própria por um botão na borda da página; ali, o intervalo só começa com uma resposta. Somente o que o visitante insere é coletado: quem fecha a pergunta deixa apenas o fato de ela ter sido exibida e fechada.
Categorias de dados pessoais	A avaliação (um número ou a opção escolhida) com seu sentimento (negativo, neutro, positivo), horário e identificador de pesquisa como evento da visita (A.7): survey_shown, survey_answer e survey_dismiss. Para uma pergunta complementar, um TEXTO LIVRE de no máximo 500 caracteres com o idioma da página. Antes do envio, mp.js remove endereços de e-mail, endereços IP e números de telefone, e o worker faz isso uma segunda vez (mp_umfrage_text_filtern()); abaixo do campo, pede-se aos visitantes que não insiram dados pessoais. No navegador do visitante, mp_umfrage (localStorage) mantém, por pesquisa, o sorteio da amostra e o horário da última exibição; para o botão na borda da página, o horário da última resposta.
Onde são armazenados	A avaliação em session_custom_events e session_custom_event_params (A.7); o texto livre em mp_umfrage_text (migração 157) — deliberadamente separado: é a parte mais sensível de uma pesquisa e não pertence à tabela que webhooks e pontes leem. As próprias pesquisas, isto é, somente o texto do controlador, em projects.survey_json.
Base legal	Instrução do controlador (art. 28(3)(a) do GDPR), dada ao criar e ativar uma pesquisa. Responder é voluntário. Se existe base legal para a pergunta e a pergunta complementar e se são mencionadas no aviso de privacidade é responsabilidade do controlador; o bloco de texto para clientes indica a pesquisa como item separado. Nenhuma decisão relativa ao visitante depende dela.
Categorias de destinatários	O cliente, na visualização de resultados e no player. A avaliação é um evento personalizado e, portanto, segue para as transferências ativadas pelo controlador para esses eventos (4.1). O texto livre não segue para nenhuma ponte: mp_umfrage_text é lido somente por cfg/umfrage_lib.php.
Transferência para país terceiro	Nenhuma — exceto por uma transferência ativada pelo controlador (4.1), e ali somente a avaliação.
Retenção	Com a sessão: mp_umfrage_text faz parte de mp_sitzungen_loeschen(), da via de exclusão do player, mp_konto_loeschen() e da exclusão de projetos e espaços de trabalho no painel; a avaliação é excluída com session_custom_events. Deliberadamente, não existe prazo próprio — seria maior ou menor que o da gravação, e ambos seriam incorretos. A chave mp_umfrage no navegador é removida na revogação.

A.22 Busca de texto exibido — quais visitas tiveram determinado texto na página

Campo	Registro
Finalidade	O cliente encontra as visitas nas quais determinado texto estava na sua página — no carregamento ou exibido depois, como uma mensagem de erro, um aviso ou “Esgotado” — para assistir às gravações. A busca fica no explorador de usuários.
Categorias de titulares dos dados	Visitantes dos sites dos clientes cuja visita foi gravada (A.2) e não é reconhecida como automatizada.
Categorias de dados pessoais	Os trechos de texto presentes na captura e nas alterações da página (A.2), um por nó de texto, mais sua atribuição à visualização de página. O que é lido já foi gravado: áreas mascaradas e entradas de formulários já estão substituídas ali e não são encontradas. Se a própria página mostra dados pessoais (uma confirmação com nome e endereço), estão aqui também — como na gravação.
Onde são armazenados	mp_text_block (dicionário por projeto, cada trecho uma vez), mp_text_pv (qual visualização de página continha qual trecho) e mp_text_stand (qual visualização foi lida), migração 175. Preenchidos a cada dez minutos por srv/textsuche_lauf.php no nosso próprio servidor.
Base legal	Instrução do controlador (art. 28(3)(a) do GDPR): a busca torna acessível a mesma gravação contratada pelo controlador. Nenhuma decisão sobre o visitante depende dela.
Categorias de destinatários	O cliente, como filtro no explorador de usuários. Nenhuma transferência, nenhuma ponte.
Transferência para país terceiro	Nenhuma.
Retenção	30 dias a partir do início da visualização de página, menor que a gravação: depois disso, atribuição e estado são removidos, e um trecho de texto é removido com sua visualização mais recente. Se a sessão for excluída antes (prazo de retenção, solicitação de eliminação, exclusão no player, exclusão de projeto ou conta), a atribuição é excluída com ela — diretamente em mp_sitzungen_loeschen() e na exclusão do projeto; nas demais vias, no máximo após dez minutos, pela execução que remove atribuições sem visualização de página.

4. Parte A — destinatários, suboperadores e transferências para países terceiros

O próprio caminho da gravação não contém chamada de saída para terceiros. Isso foi estabelecido em 10/08/2026 por uma busca em cfg/, srv/, class/ e www/ (excluindo vendor e node_modules) por curl_init, curl_exec, file_get_contents com http, fsockopen e stream_context_create e por todos os literais https. A resolução geográfica usa arquivos locais do MaxMind, a folha de estilo da interface é servida como arquivo previamente gerado do nosso próprio servidor e as imagens de bandeiras vêm de /img/flags/. Desde 23/09/2026, o e-mail é enviado por SMTP pelo Namecheap Private Email (mail.privateemail.com, porta 465, TLS), com remetente office@mouseplayer.com; a função PHP mail() só seria usada se nenhum servidor SMTP estivesse configurado, o que não é o caso. Limite desta busca: os diretórios de fornecedores (Stripe SDK, Google Cloud SDK, PHPMailer, Symfony) não foram pesquisados — é ali que ficam os endpoints dos serviços indicados abaixo.

Destinatário	Papel e o que é transferido	Destino	Salvaguarda	Situação
Stripe	Processamento de pagamentos para contas de CLIENTES. E-mail, nome, endereço de faturamento e dados de pagamento dos clientes. www/billing_ajax.php:134 define a chave de API; as linhas 381 e 687 transmitem customer_email; a linha 48 define billing_address_collection='required'; a linha 54, customer_update para endereço e nome; as linhas 462/527/672 transmitem metadados. Canal de retorno www/api/webhook_stripe.php, tabela stripe_events. Nenhum dado de visitante.	EUA	Acordo de Tratamento de Dados aceito em 01/08/2026 como parte dos termos aceitos na abertura da conta (declaração do controlador). Parte contratante: Stripe Payments Europe, Ltd.; para transferências aos EUA, Stripe, Inc. Módulo 2 (controlador para operador). Isso decorre da distribuição de papéis, e não de uma consulta: o MousePlayer é controlador dos dados de conta e faturamento transmitidos; a Stripe é operador nessa parte. A própria versão aceita não foi examinada; se for diferente, prevalece.	Em 16/10/2026, não em operação: ambos os campos de chaves contêm chaves de teste, e nenhum pagamento real é processado.
VIES (Comissão Europeia)	Verificação de um número de identificação de IVA fornecido por um CLIENTE pela interface REST pública do VAT Information Exchange System (cfg/lib.php). São transmitidos código de país e número de IVA; a validade e, quando disponíveis, nome e endereço da empresa são retornados e armazenados com a conta (B.1). Nenhum dado de visitante.	UE	Órgão público da União; não é operador, nenhum contrato necessário. A consulta serve para verificar os dados fiscais do cliente.	Em uso assim que um cliente insere um número de IVA.
Telegram	Notificação de suporte. Até 11/08/2026 cfg/lib.php transmitia TODO o caso de suporte: situação do usuário, incluindo ID de usuário, endereço de e-mail, assunto, 'IP / Kraj' com o endereço IP NÃO TRUNCADO, URL de origem e texto completo da mensagem. Desde 11/08/2026 (commit 02846c2, cfg/lib.php), sai uma string fixa e nada mais: 'MousePlayer: es liegt eine neue Supportanfrage vor.' Nenhuma variável, nenhum parse_mode e, deliberadamente, nenhum número de caso nem link extraído da requisição. A própria solicitação continua armazenada sem alteração em support_requests — os dados já não saem, não desaparecem.	Fora da UE	Até 11/08/2026: nenhuma — o Telegram não oferece acordo de tratamento de dados para bots. Desde 11/08/2026, nenhum é necessário: a notificação não contém dados pessoais, portanto o Telegram não é operador nem destinatário. Decisão do proprietário de 11/08/2026: o canal permanece, a mensagem é reduzida a um simples sinal, o endereço IP é removido. 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 atributos são proibidos, e o texto precisa ser uma string entre aspas simples sem interpolação.	ATIVO, mas sem transmitir dados pessoais — neutralizado em 11/08/2026. TELEGRAM_BOT_TOKEN e TELEGRAM_CHAT_ID continuam definidos em .env; somente o sinal sai.
Google reCAPTCHA	Login, cadastro, formulário de suporte, página de faturamento. Verificação no servidor em www/login.php:31-45 e cfg/lib.php:6337 contra https://www.google.com/recaptcha/api/siteverify; no navegador em www/billing.php:1290.	EUA	O reCAPTCHA permanece em produção. Termos de tratamento de dados do Google aceitos em 01/08/2026 (declaração do controlador). Parte contratante: Google Ireland Limited; para transferências aos EUA, Google LLC. No sistema de desenvolvimento, o serviço está desativado (mp_recaptcha_aktiv() retorna !mp_ist_dev()); em produção, está ativado — ali, a transferência ocorre em cada ação de login, cadastro, senha e faturamento.	Inativo somente nesta instância: mp_recaptcha_aktiv() é definido em cfg/config.php:131-133 como !mp_ist_dev() e APP_ENV=dev. Ativo em produção.
Google BigQuery	Exportação noturna para o projeto GCP do PRÓPRIO cliente. srv/cron_integration_bigquery.php:95-100 seleciona session_id, channelid, visitor_id, custom_user_id, ip_address, country, referrer, user_agent, screen_width, screen_height, start_time, end_time, duration_seconds, device_type e os carrega como NDJSON em visitor_sessions_YYYYMMDD.	Região escolhida pelo cliente	O destino é o próprio projeto do cliente, portanto o cliente é o importador. A chave da conta de serviço é armazenada criptografada em projects.bigquery_sa_json (decrypt_sa_key, chave BIGQUERY_SA_AES_KEY de .env).	INATIVO. projects.bigquery_active=0 para todos os 7 projetos, bigquery_project_id NULL em todos, e o processo não está em execução.
Webhooks do cliente	srv/cron_integration_webhook.php:63-80. Corpo construído em srv/db_worker.php:1313-1323: timestamp, event_type, channel_id, session_id, um link direto do player 'https://<host>/player?id=...&session=...' e os parâmetros do evento. Formatação especial para Slack e Discord (mp_format_webhook_body, cfg/lib.php:5978).	Indeterminado — definido pelo cliente	O destino é escolhido pelo cliente e, portanto, está sob a responsabilidade do próprio controlador. Sim, o destino é registrado por Cliente (decisão do controlador, 17/08/2026). Já fica no projeto; o que falta é o registro de QUEM o definiu e quando. Desde 17/08/2026 cada alteração do destino do webhook aparece no log de alterações (log_audit, ação update_integrations, campo webhook_host). Somente o host é registrado, e não o endereço completo: um caminho de webhook frequentemente contém um segredo — Slack e Discord colocam a chave na URL —, e um log de alterações é o lugar errado para isso. Para a questão de para onde os dados de eventos saem da infraestrutura, o host basta.	INATIVO. projects.webhook_active=0 e webhook_url NULL para todos os 7 projetos. O processo despachante está em execução.
Meta (Conversions API)	Somente se o controlador ativar a ponte e armazenar seu próprio token de acesso. O que é transmitido são exclusivamente metas cumpridas do projeto em questão: nome da meta, data e hora, um identificador de evento derivado da sessão e da meta para desduplicação, valor e moeda quando definidos, mais os cookies _fbp e _fbc e a string do agente de usuário. Nome, endereço de e-mail, número de telefone e endereço IP não são transmitidos — de qualquer forma, o MousePlayer só contém um IP truncado, inútil para correspondência. O envio ocorre exclusivamente para sessões com consent_state = 'granted'; sem _fbp/_fbc a transmissão é inteiramente omitida, pois, sem uma chave de correspondência, não teria finalidade. Código: mp_capi_meta_ausloesen() e mp_capi_meta_zustellen() em cfg/lib.php, despacho por srv/cron_integration_webhook.php.	EUA	A Meta não é suboperador do MousePlayer. O MousePlayer realiza a transmissão segundo a instrução do controlador — essa instrução consiste em ativar a ponte e armazenar o token. O destinatário é a conta de publicidade do próprio controlador; a relação contratual com a Meta, incluindo as salvaguardas para transferência aos EUA, existe entre o controlador e a Meta, e não entre a Meta e o MousePlayer. A Meta trata os dados para suas próprias finalidades e, nessa medida, como controlador independente.	Ponte disponível desde 19/08/2026, ativada para nenhum projeto conforme fornecido.
HubSpot / Pipedrive	Somente se o controlador ativar a ponte e armazenar seu próprio token de API. É transmitido o identificador de cliente definido pelo próprio controlador (setUserId()), usado para localizar o contato, seguido de uma nota contendo a URL de reprodução da sessão. Nenhum dado comportamental, nenhum conteúdo de gravação. Se a busca não encontrar contato, a operação termina sem transmissão adicional. Código: mp_crm_kontakt_suchen() e mp_crm_notiz_anhaengen() em cfg/lib.php.	EUA (HubSpot), UE (Pipedrive)	Como na Meta: o destinatário é a conta CRM do próprio controlador, e a relação contratual existe entre ele e o fornecedor. O MousePlayer transmite segundo sua instrução.	Ponte disponível desde 19/08/2026, ativada para nenhum projeto conforme fornecido.
Google Cloud Storage (Varsóvia)	Cópia externa do backup diário. Documentada em OFFENE_PUNKTE.md, seção 3.3: 'mysqldump --all_databases' e 'tar /var/www/' — cada banco de dados e toda a árvore web, incluindo cada .env. Comprovação local de 653 MB de banco de dados e 678 MB de arquivos. Até 11/08/2026 o backup era executado diariamente às 02:00 e saía sem criptografia. Desde 11/08/2026 é criptografado no nosso próprio servidor antes da transferência (rclone crypt; nomes de arquivos e diretórios também são criptografados), e os dois arquivos de chaves ficam nesse mesmo servidor com modo 600 — o Google não os possui; desde então, a execução agendada ocorre às 03:00. A pasta de destino anterior, sem criptografia, que continha as cópias anteriores a 11/08/2026, foi excluída em 12/08/2026.	Polônia (UE) – bucket na região europe-central2 (Varsóvia), desde 05/09/2026. Até então, a cópia ficava em uma conta privada do Google Drive para a qual não é possível contratar uma região de dados; o destino precisava ser indicado como EUA / mundial.	Tratamento em nosso nome nos termos do Google Cloud Data Processing Addendum, aceito para o projeto Cloud; parte contratante Google Ireland Limited. Isso elimina o desvio declarado aqui de 17/08/2026 a 05/09/2026: esses termos não estão disponíveis para uma conta privada do Google, e os termos gerais de uso não estabelecem tratamento em nome de terceiro nos termos do art. 28 do GDPR. A cópia continua criptografada antes da transferência (rclone crypt, incluindo nomes de arquivos e diretórios), e as chaves ficam exclusivamente com o controlador — o Google vê blocos sem significado. Isso retira o conteúdo do Google, e não o papel.	ATIVO. Até 11/08/2026, sem criptografia e sem verificação no destino — a execução usava a configuração rclone de root, e o script não registrava nada em log. Desde 11/08/2026, criptografado; as execuções de 11/08/2026 (iniciada manualmente) e 12/08/2026 (agendada às 03:00) estão registradas e ambas passaram em uma verificação no destino (contagem de bytes do dump do banco de dados). Portanto, a operação diária está comprovada, e não apenas a primeira tentativa. O operador do sistema testou a descriptografia; não existe medição própria disso. A pasta de destino anterior, sem criptografia, foi excluída em 12/08/2026. Desde 05/09/2026, a cópia vai para o Google Cloud Storage em Varsóvia; as cópias antes mantidas na conta do Drive foram excluídas em 06/09/2026, após a verificação de uma restauração a partir do novo destino. Tipo de conta, região de dados e contrato estão, portanto, resolvidos. Desde 06/10/2026, o backup também contém o arquivo dos eventos de gravação transferidos para fora do banco (/mnt/mouseplayer-dev-archive, A.1); localmente, esse arquivo fica no mesmo disco do sistema, e somente a cópia criptografada fornece armazenamento em outro local. Testes de restauração a partir da cópia foram realizados em 05/09/2026 e 06/09/2026 e em 07/10/2026 (restauração completa dos dados). Backups diários são mantidos por 7 dias, backups semanais por 364 dias.
Namecheap	Registro de domínio, DNS autoritativo, encaminhamento de e-mails recebidos; desde 23/09/2026 também envio de e-mails pelo Namecheap Private Email. Dados de domínio; conteúdo e remetente de e-mails endereçados ao MousePlayer. Para e-mails enviados: nome, endereço de e-mail e conteúdo da mensagem ao titular da conta; para o aviso de login, também endereço IP, dispositivo e localização aproximada.	EUA	Data Processing Addendum aceito em 01/08/2026 (declaração do controlador); abrange as cláusulas contratuais padrão atuais. Os e-mails recebidos passam permanentemente pelo encaminhamento da Namecheap; nenhum outro provedor de caixa postal participa (decisão do controlador, 17/08/2026). Desde 23/09/2026, os e-mails enviados saem pelo serviço SMTP do Namecheap Private Email (TLS): avisos contratuais, avisos de conta, avisos de login e alertas dos monitores.	Em uso.
Let's Encrypt (ISRG)	Emissão e renovação de certificados TLS. Somente nomes de domínio.	EUA	Autoridade certificadora pública; não trata dados pessoais em nosso nome.	Em uso.
consented.eu	CMP nas páginas do PRÓPRIO MousePlayer, carregada no navegador do visitante: cfg/header.php:48 (stub.js) e linha 50 (cmp.js). Diz respeito aos visitantes de mouseplayer.com, e não à gravação nos clientes.	Local do tratamento: o mesmo servidor do MousePlayer (/var/www/html/ConsentedEU na mesma máquina, medido em 17/08/2026). Base contratual: não se aplica — consented.eu é operado pela mesma entidade jurídica (declaração do controlador). Não existe transferência a terceiro.	Não se aplica pelo mesmo motivo: nenhum terceiro, portanto nenhum acordo.	Em uso nas próprias páginas.

4.1 Destinatários ativados pelo controlador

A tabela acima lista destinatários contratados pelo próprio MousePlayer. Ao lado deles, existem pontes que o controlador ativa e para as quais armazena suas próprias credenciais. Não são suboperadores do MousePlayer; a relação contratual existe entre o controlador e o destinatário, incluindo as salvaguardas para países terceiros. São indicadas categorias, e não fornecedores — quais fornecedores estão disponíveis em cada categoria muda com as funcionalidades; a seleção nas configurações do projeto é o que rege. Cada transmissão é acionada no servidor por srv/cron_integration_webhook.php; o resultado é registrado no log de entrega (A.11).

Categoria	O que sai	O que aciona
Webhook para um endereço livremente escolhido	Nome do evento, ID de canal e sessão, URL de reprodução, parâmetros do evento. Assinado com HMAC-SHA256 sobre data e hora e corpo.	um evento ao qual o controlador se inscreveu
Sistema de relacionamento com clientes (CRM)	O ID de cliente que o próprio controlador definiu para o visitante, mais a URL de reprodução, anexados como nota a um contato existente. Se não existir contato, nenhum é criado.	fim de sessão com ID de cliente definido
Central de atendimento e tickets	O mesmo item como nota interna no ticket aberto mais recente do remetente. Se não houver ticket aberto, nada acontece.	fim de sessão com ID de cliente definido
Marketing por e-mail e de ciclo de vida	ID de cliente, nome do evento e URL de reprodução como evento no sistema do controlador.	fim de sessão com ID de cliente definido
Redes de publicidade (Conversions API)	O ID de clique do cookie da própria rede de publicidade, nome do evento, valor e moeda. Nome, endereço de e-mail, número de telefone e endereço IP não são transmitidos.	uma meta cumprida quando houve consentimento
Armazenamento de objetos e planilhas	ID de cliente, data e hora e URL de reprodução como objeto ou linha no armazenamento do próprio controlador.	fim de sessão com ID de cliente definido
Rastreamento de problemas e tarefas	Título e descrição de um item que contém a URL de reprodução.	um sinal de frustração ou um erro de JavaScript
Agentes de IA do controlador pelo servidor MCP	Somente leitura: projetos, indicadores, listas de sessões com link de reprodução, sessões individuais com visualizações de página e eventos, páginas, sinais de frustração e metas — não a captura da página. A autenticação usa uma chave de leitura da REST API do controlador.	uma consulta pelo agente, somente quando o acesso está ativado para o projeto (projects.mcp_active) e em um nível pago

Transferência para país terceiro: indeterminada. O controlador escolhe o destino e o fornecedor; a salvaguarda nos termos do Capítulo V do GDPR cabe, portanto, a ele. Em nenhum caso são transmitidos o conteúdo da página gravada, a trajetória do mouse ou o texto de formulários — as pontes carregam identificadores e nomes de eventos, e não a reprodução.

5. Parte B — art. 30(1): atividades realizadas como controlador

Controlador para tudo nesta parte: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Lodz, Polônia, office@mouseplayer.com. Nenhum representante necessário (estabelecido na União). Nenhum encarregado da proteção de dados designado — seção 9. Medidas técnicas e organizacionais: seção 8.

B.1 Contas de clientes, espaços de trabalho e faturamento

Campo	Registro
Finalidade	Operar as contas dos próprios clientes do MousePlayer, a participação em espaços de trabalho e o faturamento.
Categorias de titulares dos dados	Usuários clientes. Medido: 4 contas; workspace_users 4 owner, 1 admin, 1 viewer.
Categorias de dados pessoais	E-mail, e-mail normalizado, nome e sobrenome, tipo de negócio, tipo de conta (empresarial ou consumidor, customer_type), idioma, tema. Dados da empresa: nome e endereço, país e número de identificação de IVA, juntamente com resultado, horário e origem da verificação, e nome e endereço segundo o VIES. Logo da empresa (nome do arquivo e horário; o próprio arquivo fora do diretório web). Hash de senha, tokens de verificação e redefinição, expiração da redefinição. Login de dois fatores (TOTP, migração 132): segredo criptografado, último intervalo temporal usado, horário da configuração e hashes dos códigos de recuperação. Interruptor da notificação de login (login_alert, B.7). Identificador do dispositivo (device_id), sinalizador de suspeita is_suspicious. Último endereço IP COMPLETO, país, cidade, número ASN e organização ASN. Dados de faturamento: nível, moeda, ID de cliente Stripe, assinatura Stripe, período de faturamento, status, cancelamento ao fim do período. Horário de um aviso de inatividade. Histórico de IP por usuário.
Onde são armazenados	users (user_id, email, normalized_email, device_id, password_hash, first_name, last_name, business_type, customer_type, status, lang, verify_token, reset_token, reset_expires, is_superadmin, is_suspicious, new_email, email_verify_token, last_country, last_city, last_asn_number, last_asn_org, last_ip, created_at, last_login, subscription_tier, stripe_customer_id, stripe_subscription_id, billing_period_end, billing_status, retention_grace_until, retention_grace_days). user_ip_history (user_id, ip_address, asn_number, asn_org, last_seen) — 5 linhas, 0 delas truncadas. workspace_users (workspace_id, user_id, role); workspace_invites (token, workspace_id, email, role, invited_by, created_at). Adicionalmente indicados em users nesta versão: company_name, company_street, company_postcode, company_city, company_country, vat_country, vat_number, vat_valid, vat_checked_at, vat_source, vat_name, vat_address, company_logo, company_logo_at, login_alert, totp_secret, totp_enabled_at, totp_last_step, totp_recovery, theme_mode, cancel_at_period_end, inactive_warned_at, sessions_revoked_at. Contagens de linhas desta entrada: em 10/08/2026.
Base legal	Não documentada no código. Art. 6(1)(b) para execução do contrato (conta, espaço de trabalho, faturamento) e art. 6(1)(c) para a retenção legal de faturas (decisão do controlador, 17/08/2026). O prazo está indicado na linha de retenção.
Categorias de destinatários	Stripe (faturamento, veja a seção 4). VIES da Comissão Europeia (verificação do número de IVA, seção 4). Namecheap Private Email como serviço de envio de e-mails ao titular da conta: confirmação de conta, redefinição de senha, convites, notificação de login, aviso antes da exclusão por inatividade, aviso de alteração dos documentos contratuais, relatório semanal, respostas de suporte (seção 4). Membros do mesmo espaço de trabalho veem nome, endereço de e-mail e função dos demais membros, assim como o tipo de conta do espaço de trabalho, isto é, do seu proprietário (cláusula 6.6 dos Termos de Serviço), e o logo da empresa do proprietário; uma pessoa convidada vê esse logo pelo link do convite enquanto o convite está aberto.
Transferência para país terceiro	Stripe (EUA) e Namecheap (EUA); partes contratantes e salvaguardas na seção 4. O VIES está localizado na União.
Retenção	Integralmente quando a conta termina — e ela termina mesmo sem ação do proprietário. Se o proprietário aciona a exclusão nas configurações da conta, mp_konto_loeschung_ausfuehren() (cfg/lib.php) limpa, entre outros, user_ip_history, live_tokens, login_sessions, remember_tokens, report_subscriptions, os contadores da cota de gravação, api_keys, workspace_invites, workspace_users, workspaces e users; audit_logs, bot_review_labels e as entradas em mp_loesch_archiv são despersonalizados. Desde 07/10/2026 (migração 189), essa via primeiro arquiva: a conta é suspensa, os logins são revogados, seus próprios espaços de trabalho e projetos são ocultados e deixam de ser gravados; o que pode ser restaurado fica em mp_loesch_archiv. Após 30 dias – ou imediatamente, se o proprietário assim escolher – o db_worker elimina definitivamente pela cadeia indicada acima e depois conta se resta alguma coisa. Uma conta eliminada definitivamente não deixa identificador nem nome no arquivo. Se o proprietário permanece inativo, a execução diária avisa após 24 meses sem login e exclui 30 dias depois, pela mesma cadeia. O relógio começa no último login ou no cadastro de uma conta nunca usada. A exclusão só ocorre após um aviso que tenha sido entregue; se o envio falhar, o prazo nunca começa. Ambos os valores ficam em site_settings e são configuráveis na área administrativa. Faturas e os registros contábeis associados são mantidos por cinco anos, contados do final do ano civil em que venceu o prazo de pagamento do tributo (declaração do controlador, 17/08/2026: "5 lat, licząc od końca roku kalendarzowego, w którym upłynął termin płatności podatku"). Portanto, os dados de faturas estão isentos da exclusão da conta; os demais campos são excluídos com a conta. Desde 16/10/2026 somente contas no nível gratuito são avisadas e excluídas por inatividade: nível próprio free e nenhuma participação em espaço de trabalho cujo proprietário esteja em nível pago. Essa exclusão não arquiva primeiro, mas exclui diretamente pela cadeia indicada acima. O logo da empresa é excluído com a conta, como última etapa da exclusão.
Logo da empresa (desde 07/10/2026)	O cliente pode enviar um logo nas configurações (PNG, JPEG, WebP). O que é armazenado não é o arquivo recebido, mas uma imagem redesenhada no servidor, fora do diretório web (daten/firmenlogos/, migração 184). É visível à própria conta, ao superadministrador, aos membros dos espaços de trabalho pertencentes à conta e às pessoas convidadas pelo link do convite enquanto ele está aberto; todas as outras requisições recebem a mesma resposta de um logo ausente.
Exportação da conta (art. 15(3), art. 20 do GDPR)	Após inserir sua senha, o titular da conta pode baixar nas configurações um arquivo ZIP contendo os dados da sua conta como JSON e o logo da empresa. As tabelas são determinadas a partir do esquema (colunas que fazem referência à conta); segredos como hash de senha, tokens e segredo TOTP são omitidos. Tentativas malsucedidas são contadas no log de alterações e bloqueiam a exportação após cinco tentativas em 15 minutos. O arquivo é criado somente como arquivo temporário para entrega.
Outros dados da conta (em 16/10/2026)	legal_acceptances: aceitação dos documentos contratuais (incluindo o aviso de arrependimento e a solicitação de início imediato) e avisos entregues de alterações, cada um com conta, endereço IP completo, identificador de navegador, idioma, somas de verificação das versões e origem da entrada; a aceitação mais recente (não os avisos) de uma conta existente é mantida enquanto a conta existir, para que se possa demonstrar qual versão um cliente atual aceitou (desde 16/10/2026); aceitações anteriores, avisos e linhas de contas excluídas são excluídos 730 dias após a respectiva aceitação ou aviso (enquadramento da base legal para retenção após o fim da conta pendente com o controlador). report_subscriptions: assinatura do relatório semanal com token de cancelamento da inscrição e último envio; excluída com a conta. workspace_transfers: transferência de um espaço de trabalho para um endereço de e-mail com token e expiração; excluída com o espaço de trabalho. mp_dashboards: painéis próprios de uma conta por projeto; excluídos com a conta ou projeto. SSO Enterprise (sso_providers, sso_identities, sso_requests, sso_assertions, sso_policies, migrações 187 e 188): configuração criptografada do provedor de identidade escolhido pelo proprietário do espaço de trabalho; por conta, somente um hash do identificador no provedor; requisições de login válidas por cinco minutos; o servidor chama os endpoints desse provedor, sendo o destinatário o provedor escolhido pelo cliente. Em 16/10/2026, nenhum espaço de trabalho tem provedor configurado. Cota de gravação (mp_aufnahme_monat, mp_aufnahme_sitzung, migração 178): contadores por proprietário e mês, por sessão somente um hash do identificador de projeto e sessão; uma execução diária exclui os hashes dos meses anteriores, os contadores são excluídos com a conta.

B.2 Logs de acesso, segurança e auditoria do portal

Campo	Registro
Finalidade	Registro de acesso, segurança e alterações do próprio portal do MousePlayer.
Categorias de titulares dos dados	Visitantes e usuários de mouseplayer.com e www.mouseplayer.com.
Categorias de dados pessoais	Endereço IP COMPLETO, agente de usuário, caminho completo da requisição, país, cidade, tipo de dispositivo, sistema operacional, navegador, ASN. Eventos de segurança com IP parcialmente truncado: WSS_CONNECT 1261, url_excluded 71, consent_blocked 24. Log de alterações: usuário, espaço de trabalho, ação, alvo, detalhes como JSON, IP.
Onde são armazenados	mouseplayer_logs (log_id, ip_address, user_agent, page_url, created_at, country_code, asn_number, asn_org, city, device_type, os_name, browser_name) — em 10/08/2026, 36409 linhas, 8,5 MB, sem valores de IP truncados. Desde 17/08/2026, log_mouseplayer_traffic() (cfg/lib.php) coloca apenas uma linha bruta por requisição na fila Redis queue:traffic_logs; resolução GeoIP e ASN, classificação de navegador e dispositivo e gravação — incluindo users.last_ip e os campos de localização da conta — são realizados pelo db_worker. O endereço é determinado por getBestClientIP(); cabeçalhos só são considerados confiáveis quando a conexão vem do nginx anterior. security_access_logs (id, ip_address, user_agent, event_type, details, created_at) — em 10/08/2026, 1354 linhas, 350 delas truncadas. audit_logs (log_id, user_id, workspace_id, action, target_id, details, ip_address, created_at) — em 10/08/2026, 666 linhas, não truncadas. banned_ips (ip_address, scope, reason, banned_at, expires_at).
Base legal	Não documentada no código. A única fundamentação registrada é o comentário em class/Server.class.php:421-425, que distingue a Regra A (endereço completo, para acesso DIRETO à nossa própria aplicação) da Regra B (truncado, para dados de visitantes). Isso explica a decisão de concepção, mas não constitui base legal. Art. 6(1)(f). Finalidade: defesa contra abusos e responsabilização (confirmado pelo controlador, 17/08/2026). Ponderação: sem logs, não é possível detectar um ataque nem estabelecer depois quem fez uma alteração. Não existe meio menos intrusivo que alcance o mesmo — um log anonimizado perde precisamente a atribuição em questão. A interferência é limitada pelos prazos (72 horas para o log de segurança, 60 dias para o log de acesso, 60 dias para o log de alterações) e pelo fato de os logs tratarem somente do acesso à própria aplicação, e não dos visitantes gravados. Os afetados são usuários clientes que usam o serviço deliberadamente e esperam que suas ações administrativas sejam registradas.
Categorias de destinatários	O próprio MousePlayer. audit_logs também é visível ao superadministrador (www/admin.php).
Transferência para país terceiro	Nenhuma.
Retenção	mouseplayer_logs: 60 dias. security_access_logs: 72 horas. banned_ips: na expiração de expires_at; entradas definidas manualmente sem expiração permanecem até o operador do sistema suspendê-las. audit_logs: 60 dias, novo desde 17/08/2026. user_ip_history: 90 dias a partir da última vez em que um endereço foi visto, novo desde 24/09/2026; no máximo até a exclusão da conta. Todos os valores ficam em site_settings e são configuráveis na área administrativa. O log de alterações sobreviver ao log de segurança é deliberado: o log de acesso responde quem esteve ali; o log de alterações responde quem alterou algo. Este último é o registro de responsabilização nos termos do art. 5(2) e precisa sobreviver a uma disputa que só surja meses depois.

B.3 Solicitações de suporte

Campo	Registro
Finalidade	Receber e tratar solicitações de suporte. Desde 30/09/2026, isso inclui solicitar a tradução de uma mensagem e a preparação de uma resposta preliminar por um modelo de linguagem no nosso próprio hardware; uma pessoa revisa cada versão preliminar e a envia.
Categorias de titulares dos dados	Pessoas que fazem uma solicitação, autenticadas ou não.
Categorias de dados pessoais	Endereço de e-mail, assunto, texto livre da mensagem. Endereço IP COMPLETO — REMOTE_ADDR, sobrescrito com HTTP_X_FORWARDED_FOR, sem truncamento. Agente de usuário, URL de origem. O campo de código de país é lido do cabeçalho HTTP_CF_IPCOUNTRY; como não existe Cloudflare à frente, sempre contém o valor alternativo XX ou nada.
Onde são armazenados	support_requests (id, user_id, channelid, email, reason, message, status, ip_address, user_agent, source_url, country_code, created_at). Desde 30/09/2026, também mp_support_ki: uma linha por tarefa (tradução, versão preliminar, tradução da nossa própria versão preliminar), com o texto preparado para o modelo, o resultado, o nome do modelo e a duração; vinculada à solicitação por chave estrangeira.
Base legal	Art. 6(1)(b) quando quem pergunta é cliente e a solicitação diz respeito à execução do contrato; caso contrário, art. 6(1)(f). O endereço IP completo se baseia no mesmo fundamento: serve para defender o canal de suporte contra abusos. Envios em massa ou repetidos, ameaças e outros prejuízos não podem ser detectados nem interrompidos sem ele, e um endereço truncado não permite essa distinção. Decisão do controlador, 17/08/2026.
Categorias de destinatários	Até 11/08/2026: Telegram. cfg/lib.php enviava situação do usuário, endereço de e-mail, assunto, endereço IP NÃO TRUNCADO com país, URL de origem e texto completo da mensagem para api.telegram.org. Desde 11/08/2026: nenhum. Tudo o que chega a api.telegram.org é a string fixa 'MousePlayer: es liegt eine neue Supportanfrage vor.', sem variável alguma; portanto, o Telegram não recebe dados pessoais e não é destinatário. A própria solicitação permanece sem alteração em support_requests. Modelo de linguagem (desde 30/09/2026): nenhum. Funciona nas nossas próprias máquinas com placa de vídeo, na mesma rede local e no mesmo local do servidor; elas obtêm a tarefa por HTTPS, cada requisição assinada com seu próprio segredo. Recebem o texto da mensagem, o assunto, se a pessoa que pergunta tem conta e o caminho da página de origem – endereços de e-mail e sequências de seis ou mais dígitos são substituídos previamente (mp_supki_saeubern() em cfg/support_ki_lib.php); na nossa própria versão preliminar, somente endereços de e-mail. Não o endereço IP, não o endereço de e-mail de quem pergunta. Nenhum serviço externo de IA, nem mesmo como alternativa em caso de falha.
Transferência para país terceiro	Até 11/08/2026: Telegram, fora da UE; nenhum acordo de tratamento de dados está disponível para bots — veja a seção 4. Desde 11/08/2026: nenhuma. A notificação para api.telegram.org já não contém dados pessoais, portanto não ocorre transferência a país terceiro. O canal continua existindo como simples sinal — veja a seção 4.
Decisão automatizada	Nenhuma. O modelo apenas propõe texto; nada é enviado automaticamente – uma pessoa lê a versão preliminar, altera o necessário e a envia. Não é decisão nos termos do art. 22 do GDPR.
Retenção	730 dias, impostos pela execução diária em srv/db_worker.php; o valor fica em site_settings sob retention_evidence_days e é configurável na área administrativa. Na exclusão da conta, a solicitação permanece, mas perde seu vínculo com a conta (user_id se torna NULL); a política de privacidade declara isso expressamente. Linhas em mp_support_ki são excluídas com sua solicitação (ON DELETE CASCADE, migração 168), em todas as vias de exclusão.

B.4 Aceitação pelo cliente das regras regionais de gravação

Campo	Registro
Finalidade	Comprovar a aceitação pelo cliente das regras regionais de gravação — uma declaração contratual.
Categorias de titulares dos dados	Usuários clientes.
Categorias de dados pessoais	ID de usuário, e-mail, regiões, versão do texto, soma de verificação do texto, idioma. Endereço IP COMPLETO e agente de usuário — deliberadamente; o motivo está registrado em ai/migrations/018_consent.sql: trata-se da aceitação de um contrato por um parceiro comercial, e não de dados de visitantes.
Onde são armazenados	consent_region_acceptances (id, channelid, workspace_id, user_id, user_email, regions, text_version, text_checksum, text_lang, ip_address, user_agent, accepted_at) — 0 linhas.
Base legal	Prova de uma declaração contratual, conforme fundamentado no cabeçalho da migração.
Categorias de destinatários	O próprio MousePlayer.
Transferência para país terceiro	Nenhuma.
Retenção	730 dias a partir da aceitação — o mesmo prazo dos outros registros de consentimento com termos (support_requests, legal_acceptances; para legal_acceptances, a aceitação mais recente de uma conta existente é mantida além disso, veja B.1), porque respondem à mesma pergunta: quem concordou com o quê e quando. O valor fica em site_settings sob retention_evidence_days; imposto pela execução diária em srv/db_worker.php.

B.5 Visitantes do nosso próprio site

Campo	Registro
Finalidade	Operação do próprio mouseplayer.com: diálogo de consentimento, defesa contra acesso automatizado, demonstração da página inicial e logs do servidor web.
Categorias de titulares dos dados	Visitantes de mouseplayer.com.
Categorias de dados pessoais	Endereço IP — não truncado nos logs do servidor —, horário, endereço solicitado, código de status, identificação do navegador. Para a demonstração, adicionalmente posições do ponteiro e dos cliques, um identificador de sessão atribuído aleatoriamente e o país derivado do endereço. Para reCAPTCHA, o endereço mais características de dispositivo e comportamento.
Onde são armazenados	Logs de acesso do nginx (/var/log/nginx/) e Apache, ambos com o endereço completo, logrotate diário com 14 rotações. Desde 16/08/2026, o nginx é a primeira camada que vê o endereço de um visitante; o Apache fica atrás dele no loopback e o recebe pelo protocolo PROXY ou X-Forwarded-For. Os dados da demonstração não são armazenados, apenas encaminhados no momento.
Base legal	Demonstração: consentimento, art. 6(1)(a) — a barreira está implementada desde 17/08/2026. reCAPTCHA e logs do servidor: interesse legítimo, art. 6(1)(f). Art. 6(1)(f). Finalidade: defesa contra abusos e responsabilização (confirmado pelo controlador, 17/08/2026). reCAPTCHA: sem proteção contra acesso automatizado, as páginas de login, cadastro, formulário de suporte e faturamento ficam expostas a ataques. O meio menos intrusivo — um simples limite de taxa — também está implementado desde 17/08/2026, mas não substitui integralmente a pontuação. Logs do servidor: o endereço não truncado é necessário para atribuir acessos repetidos ou em massa ao mesmo remetente; um endereço truncado não permite essa distinção. A interferência é limitada pelo prazo de 14 dias e pelo fato de os logs não serem combinados com outros dados.
Categorias de destinatários	Google Ireland Limited (reCAPTCHA) e consented.eu (diálogo de consentimento). Para a demonstração, também os outros visitantes que têm a página inicial aberta no mesmo momento — veem o ponteiro e o país, e não o endereço.
Transferência para país terceiro	Estados Unidos pelo reCAPTCHA; base e data da aceitação, veja a seção 4.
Retenção	Logs do servidor, 14 dias. A demonstração não armazena nada.

Esta entrada estava ausente até 17/08/2026, embora a seção 4 já indicasse o diálogo de consentimento e reCAPTCHA como destinatários — o tratamento correspondente não aparecia em lugar algum. A política de privacidade pública foi ampliada no mesmo dia para abranger o mesmo assunto (sua seção 10); os dois textos devem ser lidos em confronto.

B.6 Acessos a um link de compartilhamento

Campo	Registro
Finalidade	Comprovar com qual frequência e de onde um link de compartilhamento foi usado. Esse link abre uma gravação completa sem login; sem esse log, não é possível estabelecer depois com qual frequência foi usado ou se saiu do círculo pretendido.
Categorias de titulares dos dados	Pessoas que abrem um link de compartilhamento — geralmente a equipe do Cliente ou destinatários escolhidos por ele. Não os visitantes gravados; são pessoas diferentes.
Categorias de dados pessoais	Endereço IP de quem acessa (não truncado), identificação do navegador, horário, identificador do link.
Onde são armazenados	share_views (migração 043), vinculado a session_shares por uma chave estrangeira com ON DELETE CASCADE.
Base legal	Art. 6(1)(f). Finalidade: defesa contra abusos — um link sem login é precisamente o tipo de endereço que é encaminhado. Ponderação: não existe meio menos intrusivo: um endereço truncado não permite responder se dois acessos vêm do mesmo lugar e, sem ele, o encaminhamento não pode ser detectado nem comprovado. A interferência é estritamente limitada — não afeta a pessoa gravada, mas quem acessa, e a linha é eliminada com o link. Os afetados são pessoas que abrem um link para a gravação de outra pessoa e precisam contar com o registro desse acesso. (decisão do controlador, 17/08/2026)
Categorias de destinatários	Nenhum. O log não sai do nosso próprio banco de dados.
Transferência para país terceiro	Nenhuma.
Retenção	Com o link. Quando ele expira ou é revogado, o log é excluído com ele pela chave estrangeira. Um link dura no máximo 90 dias, 7 por padrão — a aplicação não pode criar um mais longo.

A linha ser eliminada com o link não é uma conveniência aqui, mas metade da base legal: um log que sobrevive ao link já não tem finalidade que o sustente.

B.7 Logins ativos e sua revogação

Campo	Registro
Finalidade	Mostrar ao titular da conta onde sua conta está conectada e permitir que encerre um dispositivo ou todos os outros. Sem essa lista, um login sequestrado não pode ser detectado nem encerrado: até 28/08/2026, uma alteração de senha invalidava somente os cookies de “manter o login”, enquanto as sessões em andamento continuavam como arquivos — medidos em 24 a 54 minutos.
Categorias de titulares dos dados	Titulares e membros de uma conta de cliente. Não os visitantes gravados; são duas pessoas diferentes.
Categorias de dados pessoais	Endereço IP (não truncado), agente de usuário e, derivados dele, navegador, sistema operacional e tipo de dispositivo, localização aproximada (cidade e país) pelo endereço, horário do login e da última atividade. O próprio identificador da sessão não é armazenado, somente seu hash SHA-256. Ao lado dele, uma impressão digital do dispositivo — um hash de navegador, sistema operacional, tipo de dispositivo e faixa do endereço (/24 ou /48, nunca o endereço completo), pela qual um dispositivo já conhecido é reconhecido.
Onde são armazenados	login_sessions (migração 094), vinculado por remember_selector a remember_tokens (migração 037).
Base legal	Art. 6(1)(b) em conjunto com o art. 32. Finalidade: segurança da conta — este tratamento é a medida técnica, e não um subproduto dela. Ponderação: não existe meio menos intrusivo. Um endereço truncado falha precisamente na pergunta para a qual a lista existe (“fui eu?”), e, sem navegador e localização, não é possível distinguir uma linha de outra. Os dados surgem em cada login de qualquer forma; a novidade é somente que se tornam visíveis e revogáveis. São visíveis apenas ao titular da conta.
Categorias de destinatários	Nenhum. A lista não sai do nosso próprio banco de dados.
Transferência para país terceiro	Nenhuma.
Retenção	90 dias a partir da última atividade, e integralmente quando a conta termina. Contados da última atividade, e não da criação: um dispositivo conectado há meses, mas usado ontem, é um login atual e pertence à lista.

Desde 28/08/2026, os mesmos dados também produzem um aviso ao titular da conta quando sua conta é aberta de um dispositivo que não apareceu antes. Vai para o endereço cadastrado do próprio titular dos dados e para ninguém mais; nenhum destinatário nos termos do art. 4(9) é acrescentado. Qualquer conta pode desativá-lo nas configurações sem perder a própria lista — o padrão é ativado, porque um aviso de segurança que primeiro precisa ser ativado deixa de alcançar precisamente quem precisa dele. A impressão digital se baseia deliberadamente na faixa do endereço, e não no endereço completo: uma residência recebe outro IP na reconexão noturna e, com o endereço completo, chegaria um aviso toda manhã — o sinal seria inútil, assim como o aviso.

Duas decisões aqui precisam de explicação. O que é armazenado é o hash do identificador da sessão, nunca o próprio identificador: caso contrário, um dump do banco de dados entregaria cookies de sessão válidos, e um dump nas mãos erradas é precisamente o caso contra o qual essa tabela foi construída. E uma linha revogada não é excluída, mas marcada como revogada — uma linha excluída seria uma sessão desconhecida para a verificação executada em cada requisição, e uma desconhecida pode ser gravada de novo. A revogação teria anulado a si mesma.

B.8 Alertas operacionais e e-mails retidos (urgent_logs)

Campo	Registro
Finalidade	Alertas operacionais para o superadministrador: falhas detectadas pelos monitores em srv/cron_status.php, casos duvidosos da revisão de bots (A.19), a critério do superadministrador anomalias de um projeto em vez de e-mail e e-mails de saída retidos por uma lista de bloqueio. O bloqueio impede o envio de e-mails a endereços próprios listados ou a domínios reservados de teste e exemplo; o e-mail retido é armazenado aqui para manter rastreável o que teria sido enviado.
Categorias de titulares dos dados	Usuários clientes e outros destinatários de um e-mail retido; indiretamente, visitantes cujo ID de sessão aparece em um alerta de revisão de bots.
Categorias de dados pessoais	Origem, assunto, texto do alerta, horários de criação, última repetição, resolução e envio de e-mail. Para um e-mail retido, o endereço do destinatário e o texto completo do e-mail em texto claro — conforme seu tipo, por exemplo nome e endereço de e-mail e, para uma notificação de login, também endereço IP, dispositivo e localização aproximada.
Onde são armazenados	urgent_logs (id, quelle, betreff, meldung, erstellt_am, zuletzt_am, erledigt_am, mail_status, mail_am, stoerung_beendet_am).
Base legal	Art. 6(1)(f). Finalidade: segurança operacional e rastreabilidade do envio de e-mails. Os alertas são acessíveis somente ao superadministrador e excluídos em um prazo definido após a resolução.
Categorias de destinatários	O superadministrador. Alertas de falha também são enviados por e-mail ao endereço de alerta do operador do sistema (pelo Namecheap Private Email, seção 4); um e-mail retido não vai para ninguém.
Transferência para país terceiro	Nenhuma; para envio ao endereço de alerta, veja Namecheap na seção 4.
Retenção	Uma linha permanece até ser resolvida — pelo monitor quando a falha desaparece ou manualmente; um e-mail retido nunca é resolvido automaticamente. O monitor de status exclui linhas resolvidas 180 dias após a resolução (site_settings.retention_urgent_days, configurável na área administrativa, pelo menos 7 dias).

6. Retenção — o que a limpeza diária abrange e o que não abrange

Existe exclusão automática e, desde 17/08/2026, ela abrange todas as tabelas com dados pessoais, por prazo próprio ou pela cadeia de exclusão da sessão. Seu núcleo fica em srv/db_worker.php no bloco marcado DAILY DATA PRUNING e é executado dentro do processo worker permanentemente em execução uma vez por dia civil (controlado por $lastPurgeDate). Os prazos para sessões bot (a cada hora), a exclusão definitiva de entradas arquivadas (a cada 30 segundos) e as solicitações de exclusão do autoacesso às informações têm ciclos próprios no mesmo processo. Desde 07/10/2026, tarefas agendadas são executadas a partir de /etc/cron.d/mouseplayer por srv/cron_run.sh com um bloqueio por tarefa, entre elas transferir eventos para o arquivo (a cada hora) e manter o índice de texto (a cada dez minutos); o agregado diário do mapa de cliques é construído à noite.

Prova da execução (em 16/10/2026): o log do worker registra a execução diária todos os dias, mais recentemente em 16/10/2026 às 00:00:11, concluída dez segundos depois, e o prazo horário para sessões bot com sessões e linhas excluídas (por exemplo, às 10:00:18 do mesmo dia, 478 sessões com 3294 linhas). Até esse dia, o prazo do nível não tinha o que excluir: os projetos com sessões mais antigas estão no nível enterprise (365 dias), e as sessões mais antigas do nível gratuito são mais novas que seu prazo. Se uma execução agendada falha ou não ocorre é verificado pelo monitor de cron em srv/cron_status.php, que comunica nos Logs Urgentes (B.8) e por e-mail.

6.1 Abrangidos pela limpeza diária

Tabela	Gatilho e prazo	Evidência
mouseplayer_logs	Mais antigos que 60 dias (site_settings.log_retention_days)	srv/db_worker.php, DAILY DATA PRUNING
security_access_logs	Mais antigos que 72 horas (site_settings.security_log_retention_hours)	srv/db_worker.php, DAILY DATA PRUNING
banned_ips	expires_at está no passado; entradas sem expires_at permanecem até serem suspensas pelo operador do sistema	srv/db_worker.php, DAILY DATA PRUNING
visitor_sessions e tudo vinculado a ela (mouse_events, session_pageviews, session_custom_events com parâmetros e as demais tabelas da cadeia de exclusão)	Por sessão, depois que o prazo do nível expira: free 7 dias, small 30, business 90, enterprise IFNULL(enterprise_custom_tiers.retention_days, 365). Caso especial free + is_suspicious = 24 horas. Período de carência após mudança para plano inferior por GREATEST(...) com users.retention_grace_until e retention_grace_days. Excluídos por mp_sitzungen_loeschen().	srv/db_worker.php, DAILY DATA PRUNING
payload_blob e mouse_events de sessões bot	A gravação de uma sessão reconhecida como bot é esvaziada quando o prazo transcorre (site_settings.retention_bot_recording_days, prazo em dias: 1; 0 desativa)	srv/db_worker.php, a cada hora
visitor_sessions de sessões bot com tudo vinculado a elas	14 dias após o início da sessão (site_settings.retention_bot_session_days, pelo menos 8; 0 = nenhum prazo separado)	srv/db_worker.php, a cada hora, mp_sitzungen_loeschen()
mouse_events → arquivos	transferidos para arquivos comprimidos por sessão após 7 dias; os arquivos são excluídos com sua sessão	srv/cron_archiv.php (a cada hora), mp_sitzungen_loeschen()

6.2 O que também está abrangido desde 17/08/2026

Esta seção antes listava treze tabelas sem prazo algum. Isso está resolvido. Cinco tabelas fazem parte da cadeia compartilhada de exclusão mp_sitzungen_loeschen() desde 12/08/2026, outras seis receberam prazo próprio em 17/08/2026 e duas não estavam na lista: a pontuação por visitante e dia e os textos gerados a partir dela.

Os números da tabela abaixo não são transcrições. São lidos de site_settings quando esta página é servida — da mesma linha lida pela limpeza — e são configuráveis na área administrativa. Um número transcrito seria um segundo lugar para a mesma verdade, e os dois acabariam divergindo.

Tabela	Prazo	O que o impõe
ai_session_features	com a sessão	mp_sitzungen_loeschen()
ai_timelines	com a sessão	mp_sitzungen_loeschen()
session_comments	com a sessão	mp_sitzungen_loeschen()
session_shares	com a sessão; o próprio link expira após no máximo 90 dias, 7 por padrão; a linha de um link expirado ou revogado é excluída 90 dias depois, e os acessos em share_views são excluídos com ela	mp_sitzungen_loeschen(), mp_share_erstellen(), execução diária
visitor_nicknames	com a última sessão do visitante — desde 28/08/2026, também abrange o nome atribuído pelo controlador (A.13), que fica na mesma linha	mp_sitzungen_loeschen()
ai_visitor_value	60 dias a partir do dia pontuado; para Enterprise, a retenção do nível. Além disso, com o visitante assim que não resta nenhuma sessão dele	execução diária, mp_sitzungen_loeschen()
ai_insights (escopo “visitor”)	igualmente	execução diária, mp_sitzungen_loeschen()
consent_events	730 dias a partir de the withdrawal — nunca enquanto uma sessão ainda fizer referência a ele	execução diária
ip_lifetime_stats	365 dias a partir de first_seen	execução diária
audit_logs	60 dias	execução diária
support_requests	730 dias	execução diária
consent_region_acceptances	730 dias	execução diária
legal_acceptances	730 dias após a aceitação ou aviso; a aceitação mais recente de uma conta existente é mantida enquanto a conta existir (desde 16/10/2026)	execução diária
user_ip_history	90 dias a partir da última vez em que o endereço foi visto; no máximo até a exclusão da conta	execução diária
users (incluindo last_ip), workspace_users, workspace_invites	com a conta; sem login após 24 meses mais um prazo de aviso de 30 dias	mp_konto_loeschung_ausfuehren(), execução diária
heatmap_page_stats	não se aplica — a tabela foi removida em 18/08/2026 (migração 045)	—
mp_profil_sitzung	180 dias a partir do INÍCIO da sessão, pelo menos a janela de cálculo; sem prazo algum assim que a própria sessão desaparece	execução diária, mp_sitzungen_loeschen()
mp_profile, mp_sequenzmuster	mp_profile assim que não resta atribuição para ele; mp_sequenzmuster após 180 dias sem novo cálculo e imediatamente quando seu canal não tem mais sessão	execução diária
ga4_daily, ga4_sessions, ga4_events	180 dias a partir do dia descrito ou do início da sessão GA4, respectivamente — não do momento da importação (A.14)	execução diária
mp_hm_tag, mp_hm_tag_stand	nenhum prazo próprio: um dia armazenado é recalculado a partir das sessões ainda existentes no máximo 7 dias após seu último cálculo, na próxima abertura da lista; dias anteriores à sessão remanescente mais antiga do projeto são removidos nessa ocasião; tudo junto com o projeto (A.8)	ao abrir a lista de mapas de calor; mp_konto_loeschen()
mp_umfrage_text	com a sessão (A.21) — deliberadamente sem prazo próprio	mp_sitzungen_loeschen(), via de exclusão do player, mp_konto_loeschen()
mp_loesch_archiv, mp_loesch_archiv_sitzung	contas, espaços de trabalho e projetos arquivados e visitantes ou endereços IP arquivados (eliminação GDPR): no máximo 30 dias, depois eliminados definitivamente. Permanece um registro sem nome – para visitantes e endereços IP, um HMAC do identificador, para que a eliminação possa ser repetida após a restauração de um backup; para contas, nenhum identificador – que é removido após 730 dias	db_worker, a cada 30 segundos
mp_hm_klick_tag, mp_hm_ansicht_tag	730 dias a partir do dia que a linha descreve; imediatamente com o projeto. Nenhuma exclusão por pessoa: as linhas não contêm referência pessoal (A.1)	srv/hm_aggregat_lauf.php, mp_konto_loeschen()
mouse_events_analytik	com a visualização de página – desde 07/10/2026 também em cada via que exclui sessões individuais; antes disso, somente junto com o projeto inteiro (A.8)	mp_sitzungen_loeschen(), via de exclusão do player, mp_konto_loeschen()
login_sessions	90 dias a partir da última atividade; integralmente com a conta (B.7)	execução diária, exclusão da conta
share_views	com o link de compartilhamento, pela chave estrangeira com ON DELETE CASCADE (B.6)	chave estrangeira
ai_churn	reescrito por projeto a cada execução; excluído com as sessões das quais a linha deriva (A.16)	srv/ai_worker.php
ai_besucher_bericht	180 dias a partir da solicitação; antes com a última sessão do visitante (A.17)	execução de acompanhamento em srv/ai_worker.php
mp_cwv, mp_element_klicks, mp_element_offen	com a sessão ou visualização de página; linhas cuja visualização de página está ausente são removidas a cada hora (A.7, A.20)	mp_sitzungen_loeschen(), srv/cwv_nachtragen.php, srv/element_worker.php
mp_text_block, mp_text_pv, mp_text_stand	30 dias a partir do início da visualização de página; antes com a sessão (A.22)	srv/textsuche_lauf.php, mp_sitzungen_loeschen()
bot_review_labels	padrão: nenhuma exclusão automática; configurável em anos (retention_bot_labels_years) (A.19)	srv/cron_status.php
urgent_logs	180 dias após a resolução (site_settings.retention_urgent_days) (B.8)	srv/cron_status.php
mp_aufnahme_quittung	7 dias (A.1)	srv/db_worker.php
mp_native_apps, mp_native_sessions	até o prazo definido por sessão expirar ou até a revogação; a prévia está desativada e existe somente na instância de desenvolvimento (A.1)	cfg/native_store.php

Dois pontos medidos, e não presumidos. Primeiro, a execução diária realmente ocorre. Este documento chegou a dizer que nunca havia ocorrido; a execução de 17/08/2026 às 17:37:09 está registrada no log do worker. Não excluiu nada naquele dia porque ambos os projetos com sessões estão no nível Enterprise, e a sessão mais antiga tinha 27 dias — essa é a situação pretendida, e não uma falha. Segundo, o prazo da pontuação derivada é contado do dia que a linha descreve, e não de quando foi calculada. Na medição, 167 linhas tinham 28 dias descritos distintos, mas somente 6 horários de cálculo distintos, o mais recente poucos minutos antes: o pré-cálculo recalcula, e cada novo cálculo teria reiniciado um prazo vinculado a ele. Nunca teria expirado, sem que ninguém percebesse.

6.3 Constatações sobre a cadeia de exclusão (em 16/10/2026)

• A CADEIA FUNCIONA EM OPERAÇÃO. Em 10/08/2026, nunca havia sido executada, razão pela qual foi descrita aqui como não testada. Desde 17/09/2026, o prazo de sessões bot exclui a cada hora pela mesma cadeia de exclusão mp_sitzungen_loeschen() também usada pelo prazo do nível e por solicitações de exclusão; em 16/10/2026, por exemplo, 401 e 478 sessões por execução. O próprio prazo do nível não tinha o que excluir até esse dia (seção 6).
• PROJETOS EXCLUÍDOS. A seleção do prazo do nível ainda une visitor_sessions por INNER JOIN a projeto, espaço de trabalho e proprietário e não vê sessões sem projeto. No processo regular, porém, essa sessão já não surge: desde 07/10/2026, um projeto é primeiro arquivado e, na exclusão definitiva, removido com todas as suas sessões pela exclusão do canal (mp_kanaele_loeschen()). Em 16/10/2026, não existe sessão sem projeto.
• REGISTROS ÓRFÃOS. Tudo o que deriva de uma sessão faz parte da cadeia de exclusão ou tem prazo próprio (seção 6.2). Visualizações de página cuja sessão está ausente — por exemplo, após uma interrupção no meio de uma exclusão — são contadas uma vez por dia pelo monitor de status e removidas automaticamente com seus eventos assim que têm mais de dez minutos.
• A LIMPEZA DEPENDE DO WORKER EM EXECUÇÃO. Um worker parado também interrompe a exclusão. Desde 19/08/2026, os monitores comunicam falhas por e-mail; desde 23/09/2026, esse e-mail efetivamente sai por SMTP; desde 02/10/2026, uma máquina própria separada na mesma rede local verifica a cada minuto, de fora, se banco de dados, Redis, servidor WebSocket, processos permanentes e fila estão em ordem. Deve-se registrar que ActiveState=active não prova que o worker está vivo; a lista de processos é confiável.

Vias manuais de exclusão, para completar: o player (delete_session e delete_visitor, limitados a channelid, funções owner e admin) e mp_sitzungen_loeschen() em srv/db_worker.php. Uma revogação só exclui quando projects.consent_delete_on_withdraw está definido; em 16/10/2026, não está definido para nenhum projeto. Não existe ON DELETE CASCADE abaixo de visitor_sessions: a cadeia percorre manualmente todas as tabelas dependentes, e o ponto difícil é mouse_events, porque os eventos dependem de pageview_id, e não de session_id; desde 07/10/2026, também leva a cópia de cliques mouse_events_analytik junto.

Fora do banco de dados: os logs de acesso do nginx e Apache contêm endereços IP completos e são mantidos por 14 rotações diárias (logrotate). O Redis da instância de desenvolvimento escuta somente em 127.0.0.1 (porta 6381), tem acesso restrito e grava seus dados em disco para persistência (AOF e capturas RDB); as filas contêm o IP truncado, a URL completa e o payload do DOM até o worker coletá-los, e mp_autoban: contém o endereço completo de um remetente bloqueado durante o bloqueio (24 h). Os arquivos dos eventos transferidos para fora do banco ficam em /mnt/mouseplayer-dev-archive no mesmo disco do sistema e estão incluídos no backup desde 06/10/2026.

7. Tomada de decisões automatizada, definição de perfis e pontuação

Há pontuação e classificação. Não foi encontrada decisão que produza efeitos jurídicos relativos a um VISITANTE ou que o afete de modo igualmente significativo — nenhuma decisão de crédito, preço ou acesso e nenhuma divulgação das avaliações a alguém além do cliente. Segundo as evidências, o art. 22 não é acionado em relação a visitantes. Existem três consequências automatizadas, e duas merecem análise mais próxima do que um registro costuma oferecer. A terceira foi acrescentada em 02/09/2026 e é a única que repercute sobre o VISITANTE: a previsão de saída (A.15) ou o indicador de perda (A.16) podem levar a uma sobreposição no site do controlador. Ela só aparece se ele a ativar, seu conteúdo é dele e pode ser fechada. Disso não decorre efeito jurídico nem impacto igualmente significativo nos termos do art. 22(1) do GDPR — é um convite, e não uma decisão sobre preço, acesso ou capacidade de crédito. Ainda assim, pertence ao registro, porque aqui uma avaliação sai pela primeira vez do painel do cliente.

Mecanismo	O que faz	Onde
Pontuação de engajamento	Um inteiro pequeno construído com pontos por profundidade (duração, quantidade de páginas, profundidade de rolagem) e atipicidade (cliques de raiva e mortos, retornos, abas paralelas). Bots e sessões triviais recebem 0. Armazenado em ai_session_features.engagement_score (TINYINT UNSIGNED), índice idx_engagement. Efeito: ordenação da lista de recomendações no painel do cliente.	ai/features.py:33-70; cfg/project_ai_overview.php:126-136 e 150; cfg/project_live_users.php:190
Qualidade da sessão	Separa sessões em que quase nada aconteceu.	visitor_sessions.session_quality; srv/db_worker.php:706-780 e 1103-1140
Classificação de bots	Define visitor_sessions.is_bot e bot_reason (varchar 32), índice idx_is_bot. Observe que a verificação de bots em mp.js ocorre ANTES da barreira de consentimento.	srv/db_worker.php:963-1000
Detecção de frustração no navegador	Gera rage_click, dead_click e mouse_thrashing. Medido: dead_click 355, rage_click 52, mouse_thrashing 5. Em rage_click, o script também transmite um sinalizador a widgets de chat de terceiros presentes no navegador do VISITANTE — Intercom('update', {'mouseplayer_rage_click':'DETECTED_NOW'}) e LiveChatWidget.call('set_session_variables', ...). Essa é uma divulgação posterior automatizada de um julgamento comportamental a um terceiro sistema na página do cliente.	www/mp.js:5786 e 5793-5794
Log textual da sessão	Prosa gerada por máquina sobre o percurso da sessão, produzida por ai/build.py. Desde 12/08/2026, srv/ai_worker.php aciona a própria geração (com diretório de trabalho e PYTHONPATH); em 16/10/2026, funciona, e a linha do tempo mais recente é do mesmo dia. As mensagens de erro em ai_build.log vêm da chamada anterior, já removida, e foram gravadas pela última vez em 18/08/2026.	ai/build.py; srv/ai_worker.php; ai_timelines
is_suspicious no cadastro	Definido automaticamente no cadastro, usando device_id e o e-mail normalizado, entre outros sinais. Consequência: no nível gratuito, o prazo de retenção é reduzido a 24 horas.	www/register.php:159-191; srv/db_worker.php:824
Bloqueio automático	Mais de 15 conexões em 10 segundos, mais de 15 conexões simultâneas de um IP, mais de 50 mensagens por segundo e mensagens grandes demais (exceto captura grande de página) ou ilegíveis levam a um bloqueio de 24 h no servidor WebSocket (site_settings.autoban_stunden, 1 a 168), mantido no Redis (mp_autoban:) e registrado sem o endereço completo. À frente do servidor web, o fail2ban bloqueia um endereço por uma hora se ele atingir o limite de taxa do nginx mais de 100 vezes em um minuto (jail mp-nginx-429). Segundo o código em 16/10/2026, entradas em banned_ips agora são definidas somente pelo operador do sistema; entradas automáticas anteriores expiravam após 7 dias.	class/Server.class.php (autoBanIp); /etc/fail2ban/jail.d/mp-nginx-429.conf; /etc/nginx/conf.d/mouseplayer.conf
Perfis comportamentais — agrupamento de visitas (A.12)	k-means sobre sete características por sessão atribui cada visita que pode ser assistida a um de no máximo oito grupos e o nomeia a partir da posição relativa do centro do grupo. Sessões triviais e reconhecidas como bots são separadas previamente por regra e não são agrupadas. Efeito: uma EXIBIÇÃO — uma aba, um filtro e uma fila de reprodução. Nenhuma decisão depende disso.	ai/profile.py; cfg/project_profiles.php; mp_profil_sitzung
Escore de atrito e anomalias	Por sessão, um valor de 0 a 100 derivado de sinais ponderados de frustração e erro com motivos (desde 26/09/2026); ordena e filtra listas e pode acionar um webhook inscrito pelo cliente quando um limite é atingido. Uma vez por dia, o dia anterior de cada projeto é comparado às semanas anteriores (sessões, taxa de metas, participação com atrito ou erros de JavaScript, Web Vitals), e uma anomalia é comunicada — contagens do projeto, e não avaliação de visitantes individuais. Nenhuma decisão relativa ao visitante depende disso.	cfg/reibung_lib.php; cfg/anomalie_lib.php; visitor_sessions.friction_score; mp_anomalie

8. Medidas técnicas e organizacionais (art. 32) — descrição geral

Esta seção é a descrição geral exigida pelos arts. 30(1)(g) e 30(2)(d). Cada medida abaixo foi verificada no código ou na configuração; arquivo e linha são indicados para que um leitor possa verificar, em vez de confiar. As lacunas ao final desta seção também foram verificadas e são declaradas junto, porque uma descrição de TOM que lista somente o que existe é publicidade.

Área	Medida em vigor	Evidência
Criptografia de transporte	As conexões da internet são criptografadas com TLS: o TLS termina no nginx (192.168.20.2:443), e cada requisição HTTP é redirecionada para HTTPS. O servidor WebSocket escuta somente em 127.0.0.1:8081, sem TLS próprio, e só pode ser alcançado pelo nginx (caminho /mp_wss/); o mesmo vale para o túnel HTTP /mp_wst, o envio de capturas grandes de página /mp_dom e o ponto de medição /mp_wsfail, que funcionam por HTTPS. Dentro da nossa própria rede local no mesmo local, conexões com banco de dados e Redis funcionam sem criptografia (veja 8.1).	/etc/nginx/conf.d/mouseplayer.conf; srv/server.php (MP_WSS_BIND, MP_WSS_TLS); www/.htaccess
Minimização dos dados na coleta — IP	O endereço IP do visitante é truncado imediatamente após ser determinado e, portanto, antes de qualquer consumidor (último octeto IPv4, último grupo IPv6). Em 10/08/2026, 236 linhas legadas ainda continham endereços completos; em 16/10/2026, nenhuma linha em visitor_sessions ou ip_lifetime_stats contém endereço não truncado.	class/Server.class.php (regra B)
Minimização dos dados na captura — entradas de formulários	Mascaramento com patamar mínimo obrigatório: no nível 0, cada caractere é substituído; independentemente do nível, senhas e dados de pagamento sempre são substituídos (categorias password e payment, tipos password/email/tel/hidden, padrões de classe e nome card|cc|cvv|cvc|password|credit|social|pesel|nip). Todos os 7 projetos usam smart_masking=0.	www/mp.js:4818-4853
Minimização dos dados na captura — DOM	Dentro de data-mp-mask ou .mp-masked, cada caractere que não seja espaço em branco é substituído por '*', e todos os atributos fora de MASK_KEEP_ATTRS são definidos como '[FILTERED]'. Aplica-se também às alterações em andamento.	www/mp.js:3934-3970 e 4732-4768
Minimização dos dados na captura — nomes de campos	O name ou id bruto de um campo de entrada não é transmitido; somente a categoria classificada é enviada, porque, em muitas lojas, o nome bruto é descritivo o suficiente para identificar a pessoa.	www/mp.js:4653-4674
Aplicação do consentimento	Lista de exclusão de caminhos avaliada ANTES da barreira de consentimento, comparando o caminho, e não a URL completa (71 conexões bloqueadas). Aplicação no servidor como segunda rede de proteção: somente GRANTED, GRANTED_LATE ou uma isenção regional explícita passam; WITHDRAWN, país desconhecido e qualquer situação pouco clara levam a close(1008) (24 conexões bloqueadas). Interruptor geral site_settings.consent_gate_active=1.	class/Server.class.php:963-975 e 977-1004
Minimização da prova de consentimento	A string TC não é armazenada em texto claro; somente seu SHA-256 é mantido.	visitor_sessions.tcf_hash CHAR(64); ai/migrations/018_consent.sql
Segurança da aplicação	Tokens CSRF de random_bytes(32) comparados com hash_equals(). Cookie de sessão com httponly=true, samesite='Lax' e secure condicionado a HTTPS. Senhas armazenadas como hashes e verificadas com password_verify(). Instruções preparadas em todos os caminhos de escrita auditados. Limitação da taxa de login.	cfg/lib.php:118-132 e 110-112; www/login.php:60 e 28
Prevenção de abusos	Bloqueio automático e limite de conexões no WebSocket (contador Redis com expiração de 10 s; 15 conexões simultâneas por IP; bloqueio de 24 h no Redis, truncado no log). Limitação de taxa e limites de conexões por endereço no nginx para páginas e handshakes WebSocket. fail2ban com a jail mp-nginx-429: quem for rejeitado mais de 100 vezes em um minuto é bloqueado para HTTP e HTTPS por uma hora.	class/Server.class.php; /etc/nginx/conf.d/mouseplayer.conf; /etc/fail2ban/jail.d/mp-nginx-429.conf
Controle de acesso	Modelo de funções por espaço de trabalho (owner / admin / viewer). A exclusão no player é limitada a owner e admin, e cada exclusão também é restrita a channelid — descrito no código como o verdadeiro limite de segurança.	workspace_users.role; www/player.php:267 e 275-282
Registro de alterações	log_audit() registra usuário, espaço de trabalho, ação, alvo, detalhes e IP. 666 entradas, incluindo create_share, revoke_share, delete_comment, player_delete_*, firewall_auto_ban (24) e superadmin_*.	cfg/lib.php:2878-2890
Links de compartilhamento	channelid e session_id vêm exclusivamente do token; a string de consulta restante é SUBSTITUÍDA, e não ignorada; user_role permanece NULL, portanto exclusão e novo compartilhamento ficam indisponíveis no servidor, e não somente na interface; todos os três endpoints ficam restritos à sessão do token; tokens inventados, expirados e revogados retornam a mesma resposta.	www/share.php; www/.htaccess:77
Superfície da API	O payload completo de reprodução deliberadamente não faz parte da API pública.	www/api/v1_session_detail.php:25
Gerenciamento de chaves	A chave da conta de serviço do Google é armazenada criptografada em projects.bigquery_sa_json e descriptografada por decrypt_sa_key() com BIGQUERY_SA_AES_KEY de .env; a interface indica AES-256.	srv/cron_integration_bigquery.php:57; cfg/lib.php:993
Segredos fora do controle de versões	Confirmado no índice atual: .gitignore lista .env, e git ls-files encontra somente .env.example.	git ls-files
Exposição de rede	Somente as portas 80 e 443 pelo nginx são alcançáveis pela internet; não existe encaminhamento de portas para banco de dados ou Redis. O Redis da instância de desenvolvimento está vinculado somente a 127.0.0.1 (porta 6381); uma instância Redis mais antiga e compartilhada (porta 6379) também escuta na rede local. O MariaDB escuta em 127.0.0.1 e na rede local. Banco de dados e Redis têm acesso restrito e só são alcançáveis pela nossa própria rede local. Uma restrição adicional de acesso fica à frente de www.mouseplayer.com.	ss -ltn; configuração do Redis; www/.htaccess

8.1 Medidas comprovadamente NÃO implementadas

• Sem criptografia em repouso. innodb_encrypt_tables, innodb_encrypt_log e innodb_encrypt_temporary_tables estão todos OFF, e não existe volume criptografado (lsblk mostra sda1 sem crypt).
• Sem TLS nas conexões de banco de dados. have_ssl=YES, mas ssl_cert, ssl_key e ssl_ca estão vazios. O MariaDB escuta em 127.0.0.1 e na rede local (192.168.20.2:3306); portanto, conexões da rede local funcionam sem criptografia. Têm acesso restrito e não podem ser alcançadas pela internet (sem encaminhamento de portas).
• Sem criptografia de transporte para o Redis. As conexões com Redis funcionam sem criptografia pela interface local ou na rede local; ambas as instâncias têm acesso restrito. A instância de desenvolvimento grava seus dados em disco para persistência (AOF), incluindo as filas com IP truncado, URL completa e payload do DOM e, durante o bloqueio (24 h), o endereço completo dos remetentes bloqueados.
• NENHUM LOG DE QUEM VISUALIZOU QUAL GRAVAÇÃO. audit_logs registra somente ações de escrita; uma chamada a player.php, ajax_get_events.php ou player_theatre.php não é registrada. Portanto, é impossível responder depois quem assistiu a uma determinada sessão.
• Os logs de acesso do Apache contêm endereços IP completos, mantidos por 14 dias.
• Os arquivos dos eventos de gravação transferidos para fora do banco ficam no mesmo disco do sistema e do banco de dados. Uma falha desse disco afeta ambos; somente a cópia criptografada do backup, que contém o arquivo desde 06/10/2026, fornece armazenamento em outro local.
• Todos os limites contra sobrecarga — nginx, fail2ban e bloqueio no servidor WebSocket — contam por endereço. Nada à frente da máquina ajuda contra um ataque distribuído a partir de muitos endereços: nenhuma CDN nem serviço de filtragem está à frente.
• Segurança física: o acesso é reservado exclusivamente ao controlador. A sala é trancada à chave e monitorada por vídeo; nenhuma outra pessoa — incluindo locadores ou serviços de limpeza — tem acesso (declaração do controlador, 17/08/2026). O endereço preciso é deliberadamente omitido aqui.
• Monitoramento e recuperação: desde 19/08/2026, os monitores em srv/cron_status.php comunicam falhas, pouco espaço em disco, backups ausentes e execuções agendadas malsucedidas nos Logs Urgentes (B.8) e por e-mail; desde 23/09/2026, esse e-mail efetivamente sai por SMTP. Desde 02/10/2026, uma máquina própria separada na mesma rede local verifica banco de dados, Redis, servidor WebSocket, processos permanentes e fila a cada minuto por um endpoint de integridade (www/health.php) e comunica uma falha; ela não consegue ver uma falha da própria conexão com a internet. Tempo objetivo de recuperação: no máximo 24 horas. Testes de restauração da cópia externa foram realizados em 05/09/2026 e 06/09/2026 e em 07/10/2026 (restauração completa dos dados); são previstos mensalmente (declaração do controlador, 17/08/2026). O disco USB de backup fica na mesma sala que o servidor — um único evento nesse local afeta, portanto, ambos; somente a cópia criptografada fornece armazenamento externo. Os dois arquivos de chaves são mantidos impressos em um cofre ao qual somente o controlador tem acesso e, assim, sobrevivem à perda da máquina.

9. Encarregado da proteção de dados — avaliação nos termos do art. 37 do GDPR

O art. 37(1) exige designação em três casos. O caso (a), autoridade ou órgão público, não se aplica. O caso (c), atividades principais consistentes no tratamento em larga escala de categorias especiais do art. 9 ou dados de condenações criminais do art. 10, não é satisfeito: nenhum dado de categoria especial é tratado intencionalmente. Isso não encerra a questão — conforme indicado em A.2, a captura do DOM armazena tudo o que a página do cliente renderiza, portanto dados de categorias especiais podem entrar incidentalmente em uma gravação em um site de saúde ou finanças. A captura incidental não é uma atividade principal consistente nesse tratamento, portanto o caso (c) não é acionado; mas a exposição é real e pertence à integração inicial dos clientes, em vez de ser descartada pela redação aqui.

O caso (b) é o relevante e tem dois elementos. O primeiro — atividades principais consistentes em tratamento que exige MONITORAMENTO REGULAR E SISTEMÁTICO de titulares dos dados — é satisfeito sem discussão. A reprodução de sessões é observação contínua e automatizada do comportamento individual; não é acessória ao negócio, É o negócio. Quem ler este registro e se sentir tentado a contestar o primeiro elemento deveria parar: ele é satisfeito, e contestá-lo desperdiça a credibilidade necessária para o segundo.

O segundo elemento é LARGA ESCALA, e é aqui que a resposta atualmente é negativa. As orientações do Grupo de Trabalho do Artigo 29 ponderam quatro fatores: quantidade de titulares dos dados, volume e variedade dos dados, duração ou permanência do tratamento e abrangência geográfica. Medido em 10/08/2026: 706 sessões de visitantes, 329 registros distintos de visitantes, 7 projetos, 4 contas de clientes. Quanto à quantidade de titulares, isso está muito longe de larga escala — e ainda são números da instância de desenvolvimento. Em 16/10/2026: 3514 IDs distintos de visitantes classificados como humanos nos últimos 30 dias em todos os projetos, ainda muito abaixo do limite da consequência 2.

Dois dos quatro fatores, porém, apontam na direção oposta, e o registro deveria dizê-lo, em vez de se apoiar no fator confortável. A VARIEDADE de dados por pessoa é excepcionalmente ampla: HTML completo da página, incluindo tudo o que ela exibe, entradas em formulários no nível de cada tecla, comportamento de movimentos e cliques, pontuação comportamental derivada e narrativa da sessão em prosa. A DURAÇÃO é longa: conforme o nível, as gravações permanecem por até 365 dias e no backup por até 364 dias além disso, embora existam prazos de exclusão aplicados a todas as tabelas desde agosto de 2026 (seção 6). Somente o número de pessoas mantém a avaliação abaixo do limite, e essa é precisamente a quantidade que o MousePlayer não controla: é definida pelo tráfego recebido pelo site de cada cliente. Um único cliente de comércio eletrônico de porte médio poderia, sozinho, levar o produto além desse limite, sem nenhuma decisão tomada aqui.

• Consequência 1 — registrar a avaliação com sua data. O art. 5(2) faz da responsabilização a obrigação; uma avaliação negativa nunca registrada é indistinguível de uma nunca realizada.
• Consequência 2 — definir o gatilho que a reabre. O gatilho sensato é a quantidade de visitantes monitorados por mês em todos os clientes, mais uma revisão a cada novo cliente de tamanho significativo. Limite e frequência: a avaliação do art. 37 é repetida assim que mais de 100000 usuários finais por mês são observados em todos os Clientes e, em qualquer caso, anualmente. Responsável: Lukas Wójcik, proprietário. (decisão do controlador, 17/08/2026) Implementado em 19/08/2026: a quantidade de usuários finais distintos observados nos últimos 30 dias é contada uma vez por dia pelo processo de monitoramento e comparada a esse limite e à data da última avaliação registrada; ultrapassar qualquer um gera aviso por e-mail. Limite e data são configurações, lidas da mesma linha citada por esta frase, para que o documento e a medição não possam divergir. Um gatilho que ninguém mede é uma nota, e não um controle – essa era a lacuna descrita por este parágrafo, que já não a descreve.
• Consequência 3 — verificar a legislação nacional. O art. 37(4) permite que a legislação da União ou de um Estado-Membro exija designação em outros casos. a preencher: confirmação de advogado polonês sobre se a legislação polonesa exige encarregado da proteção de dados em outros casos além do art. 37(1)
• Consequência 4 — a designação voluntária continua aberta. Se um DPO for designado voluntariamente, os arts. 37 a 39 se aplicam integralmente, incluindo publicação e comunicação dos dados de contato. Isso é uma decisão, e não um padrão.
• Consequência 5 — separada, mas próxima: uma avaliação de impacto sobre a proteção de dados do art. 35 muito provavelmente é exigida de cada CLIENTE como controlador, dado o monitoramento sistemático combinado com avaliação e pontuação. Como operador, o MousePlayer deve prestar assistência nos termos do art. 28(3)(f). Existe uma avaliação de impacto no nível do produto — a publicada em “Avaliação de impacto sobre a proteção de dados”. Uma cópia separada não é entregue aos Clientes (decisão do controlador, 17/08/2026). A assistência do art. 28(3)(f) é prestada mediante solicitação e se baseia nos documentos públicos: este registro, a avaliação de impacto publicada, as medidas técnicas e organizacionais e a lista de suboperadores.

10. Lacunas conhecidas

Tudo abaixo é comprovado, e não suspeitado. Esta seção existe porque um registro das atividades de tratamento é um instrumento de trabalho: o objetivo é permitir ver os itens pendentes, e não apresentar uma folha limpa. Os itens estão ordenados pelo quanto seriam mal vistos em uma auditoria, e não pela dificuldade de corrigi-los.

Lacuna	O que está comprovado	Por que importa
Endereços IP completos nos logs da nossa própria aplicação	Em 16/10/2026, os dados legados em visitor_sessions e ip_lifetime_stats estão truncados (em 10/08/2026, respectivamente 236 e 291 linhas não truncadas). mouseplayer_logs, audit_logs, user_ip_history, login_sessions, share_views e support_requests (parte B), assim como os logs de acesso do nginx e Apache, permanecem deliberadamente não truncados	Para a parte B, o endereço completo é justificado (B.2 a B.7) e limitado por prazos. Mesmo assim, está listado aqui porque essas tabelas entram em cada backup.
Dados legados com entradas de formulários em texto claro	Em 10/08/2026, 173 linhas em mouse_events com event_type='input' continham valores não mascarados de 2026-07-21 a 2026-07-27, incluindo nomes de pessoas. As linhas foram excluídas em 17/08/2026, antes da introdução dos arquivos em 18/08/2026; em 16/10/2026, nenhuma delas está em mouse_events	As linhas atuais estão mascaradas, portanto o controle funciona. Os valores antigos não podem estar no arquivo nem no backup atual; não se conhece backup anterior a 17/08/2026, mas sua ausência não foi verificada em detalhe.
Links de compartilhamento contornam inteiramente o login	/s/<40-hex-token> leva diretamente a player.php?share=<token>; o token é toda a barreira	O link pode ser repassado a qualquer pessoa, por isso a categoria de destinatários de A.1, A.2, A.3 e A.9 é, na prática, aberta. Isso é limitado pela duração máxima (7 dias por padrão, no máximo 90), revogação a qualquer momento e log de acesso (B.6).
Nenhum log de quem visualizou uma gravação	audit_logs registra somente ações de escrita; chamadas a player.php, ajax_get_events.php e player_theatre.php não são registradas	Após um incidente, é impossível estabelecer quem assistiu a qual sessão. Essa é a medida cuja ausência é mais difícil de explicar a uma autoridade de controle.
O servidor inteiro é copiado para fora do local todos os dias	srv/backup-crypt.sh faz backup de todos os bancos de dados e de toda a árvore web, incluindo cada .env, todos os dias e, desde 06/10/2026, também do arquivo de eventos de gravação; a cópia é criptografada no nosso próprio servidor antes da transferência (rclone crypt) e, desde 05/09/2026, armazenada em um bucket do Google Cloud Storage em Varsóvia, abrangida pelos termos de tratamento de dados do Google Cloud (seção 4)	O que sai das instalações todos os dias não é somente uma cópia das gravações de sessões, mas o servidor completo, com os segredos de produção de vários sistemas. A criptografia retira o conteúdo do Google, e não o âmbito. Se ambos os arquivos de chaves forem perdidos, o backup será irrecuperável; por isso, também são mantidos impressos no cofre (seção 8.1).
A chegada do backup é monitorada	Não comprovada até 11/08/2026. Desde então, a execução grava um log e verifica no destino; desde 19/08/2026, um monitor compara a última execução bem-sucedida com um prazo e comunica a ausência de execução nos Logs Urgentes e por e-mail	A lacuna desta linha está encerrada. Permanece listada para que seja rastreável que o backup funcionou sem comprovação até 11/08/2026.
Scripts antigos de backup	Os scripts antigos de backup foram removidos em 16/10/2026. Nenhum dos dois ainda era executado; desde 11/08/2026, o backup diário funciona por srv/backup-crypt.sh	A lacuna desta linha está encerrada. Permanece listada para que se possa rastrear que, até 11/08/2026, quem obtivesse a conta SSH pi teria root às 02:00.
Sem criptografia em repouso, sem TLS nas conexões de banco de dados e Redis	innodb_encrypt_* todos OFF, nenhum volume criptografado; ssl_cert/ssl_key/ssl_ca vazios, MariaDB também alcançável na rede local; Redis com acesso restrito, mas sem criptografia e com persistência em disco (AOF)	As gravações — incluindo o payload do DOM na fila Redis e os arquivos — são legíveis por qualquer pessoa com acesso ao sistema de arquivos; na rede local, as conexões de banco de dados funcionam em texto claro. Nenhuma dessas vias pode ser alcançada pela internet.
Parte dos registros de consentimento são dados de teste	Em 10/08/2026, 671 de 706 sessões continham consent_source='testdata' com consent_ts IS NULL, definido por ai/devdata/001_altsitzungen_markieren.sql; em 16/10/2026, ainda existem 566 sessões desse tipo	Para essas sessões, o log de consentimento não pode servir como prova. Esse é um artefato do sistema de desenvolvimento, mas a mesma consulta em produção precisaria da mesma verificação.
A revogação não exclui nada	Em 16/10/2026, projects.consent_delete_on_withdraw não está definido para nenhum projeto (avaliado no ramo consent_withdrawn em srv/db_worker.php)	A revogação interrompe novas gravações — como exige o art. 7(3) —, mas um cliente que presume que ela também exclui a gravação anterior está enganado. Essa distinção deve ser declarada na documentação voltada ao cliente.
Tudo aqui é medido na instância de desenvolvimento	APP_ENV=dev; o projeto de teste mpconsenttest01 e as massas de teste s_mptest_ estão incluídos nas contagens	A estrutura deste registro se transfere à produção; os números, não. A produção deve ser medida antes de se recorrer externamente a este registro.
A busca de chamadas de saída não foi exaustiva	cfg/, srv/, class/ e www/ foram pesquisados por curl_init, curl_exec, file_get_contents com http, fsockopen, stream_context_create e todos os literais https; diretórios de fornecedores não foram pesquisados	As árvores de fornecedores contêm os endpoints de Stripe, Google Cloud, PHPMailer e Symfony. Esses serviços estão indicados na seção 4, mas a afirmação 'não existe outra chamada de saída' é limitada pela busca.
Nenhum interruptor por projeto para os perfis comportamentais	profile_aktiv é uma configuração global do operador do sistema. mp_ki_module_katalog() em cfg/lib.php lista nove seções de IA selecionáveis, e nenhuma é a de perfis, portanto projects.ki_module não abrange esta aba; a entrada de navegação em www/project.php é incondicional. Medido em 27/08/2026.	Um cliente que não deseja o agrupamento das visitas dos seus visitantes não pode desativá-lo. Ele controla a gravação; a derivação dela, não. Todas as outras seções derivadas podem ser desmarcadas por projeto — esta é a exceção. A lacuna de retenção que constava aqui até 27/08/2026 está encerrada: mp_profile e mp_sequenzmuster agora têm prazos próprios, veja 6.2.
Uma solicitação de eliminação só alcança as sessões GA4 importadas quando a ponte de análise está ativada	Desde 01/09/2026, mp_sitzungen_loeschen() inclui ga4_sessions e ga4_events em uma solicitação do art. 17, vinculadas por ga4_sessions.user_pseudo_id = visitor_sessions.custom_user_id e limitadas ao canal. Esse vínculo só existe quando o cliente ativou a ponte de análise GA4 — ela grava ali o ID de cliente do cookie _ga. Se, em vez disso, ele preenche custom_user_id por setUserId() com um identificador próprio, não existe caminho algum de um visitante até sua linha importada. O caso é acompanhado como teste próprio (test_ga4_import.php, seção J), para que não seja esquecido.	Para esses clientes, a linha importada permanece após uma solicitação de eliminação até o prazo de A.14 removê-la. É pseudônima e não atribuível por nós — precisamente por isso, não pode ser excluída de forma direcionada. Uma via de exclusão pela própria propriedade GA4 é matéria do controlador que a opera.
O consentimento para linhas importadas não pode ser comprovado, apenas inferido	O que é importado é o que contém um user_pseudo_id; hits sem cookies sob consentimento negado não o contêm e são excluídos (A.14). Não existe para essas linhas registro comparável a consent_events — o GA4 não fornece na exportação um atributo de consentimento que possa ser armazenado aqui.	Para suas próprias gravações, o MousePlayer consegue mostrar por sessão em que se baseiam; para uma sessão importada, não. A barreira é mecânica e funciona, mas comprova somente que um cookie foi definido — não com o que o visitante concordou. A responsabilidade por isso é do controlador, que rege a coleta no Google.
O nome personalizado de visitante é texto livre não verificado	A.13, desde 28/08/2026. mp_besucher_label_setzen() trunca em 64 caracteres, remove quebras de linha e verifica se o visitante pertence ao projeto — nada verifica o CONTEÚDO, e não existe especificação de que tipo deveria ser.	O controlador pode escrever nele categorias especiais do art. 9 („Sr. X, cadeira de rodas“) sem barreira nem aviso. A responsabilidade pela conformidade é dele, e não do operador — mas um operador que oferece um campo de texto livre sem dizer nada a respeito criou a oportunidade. Uma verificação técnica não é possível: uma máquina não consegue distinguir um nome de um dado de saúde. O que seria possível é uma nota no campo.
Exemplos de revisão de bots sem prazo de exclusão	Um vetor de características pseudônimo por sessão decidida (bot_review_labels, A.19) permanece após a sessão enquanto nenhum prazo for definido. O padrão de retention_bot_labels_years é 0 (ilimitado); o operador do sistema pode defini-lo em anos.	Não são conteúdo de visitante, mas contêm o identificador da sessão. Definir ou não um prazo é decisão do operador do sistema.
O texto livre de uma pesquisa é filtrado apenas de forma aproximada	A.21, desde 27/09/2026. mp_umfrage_text_filtern() substitui endereços de e-mail, endereços IP e números de telefone, no navegador e novamente no worker. Não reconhece nomes, endereços postais, números de cliente nem informações de saúde.	Um visitante pode escrever qualquer coisa na pergunta complementar, incluindo categorias especiais do art. 9. A nota abaixo do campo pede que não o faça; não é uma trava. Como no nome de visitante atribuído pelo próprio controlador (A.13), o conteúdo não pode ser classificado de forma confiável por máquina.

11. Manutenção deste registro

Os arts. 30(1) e 30(2) exigem que o registro seja mantido por escrito e disponibilizado à autoridade de controle mediante solicitação. Isso torna necessárias duas coisas que não estão no próprio documento: alguém responsável por ele e um intervalo no qual seja conferido em relação ao sistema, e não à sua própria versão anterior.

• Responsável e intervalo de revisão: responsável: Lukas Wójcik, proprietário. Revisado anualmente e a cada alteração do tratamento. As versões datadas são mantidas no controle de versões em ai/cms/. (decisão do controlador, 17/08/2026)
• Eventos que obrigam a uma atualização independentemente do intervalo: novo suboperador ou alteração de destino; nova tabela com dados pessoais; alteração na cadeia de exclusão mp_sitzungen_loeschen() ou na limpeza diária em srv/db_worker.php; ativação da exportação para BigQuery ou de webhooks para qualquer cliente; alteração nos padrões de mascaramento; primeiro cliente cujo site exiba dados de categorias especiais.
• Método: cada número deste registro veio de uma medição em relação ao código, ao esquema ou ao banco de dados em uma data indicada. Uma revisão que apenas relê o texto não revisou nada — os números devem ser medidos novamente, e os marcadores devem ser preenchidos ou expressamente mantidos com um motivo.
• Este registro não substitui a lista de suboperadores, o documento de medidas técnicas e organizacionais, o acordo de tratamento de dados nem o aviso de privacidade. Quando esses documentos e este registro divergem, a discrepância é uma constatação, e não uma questão de formatação.