Avaliação de Impacto sobre a Proteção de Dados (Art. 35 do RGPD)

Este documento é publicado em vários idiomas. Em caso de divergência entre as versões, a versão em polonês é vinculante.

Versão 1.1 · Última atualização: 23 de outubro de 2026

1. Do que se trata e o que é esta página

Esta página é a avaliação de impacto sobre a proteção de dados (AIPD) de formexposed nos termos do Art. 35 do RGPD. Ela primeiro responde à questão preliminar de se uma AIPD é necessária – separadamente para cada operação de tratamento, não para o serviço como um todo. Quando a resposta é sim, realiza a avaliação nos termos do Art. 35(7)(a) a (d): uma descrição sistemática, necessidade e proporcionalidade, os riscos para os titulares dos dados e as medidas para enfrentá-los. Em seguida, trata do risco residual, da questão da consulta prévia nos termos do Art. 36 e das regras de revisão.

O Art. 35 não exige a publicação de uma AIPD. Nós a publicamos por dois motivos. Primeiro, Clientes que usam a verificação de entrega ou a verificação de áreas protegidas por login precisam, para sua própria avaliação, de fatos que só nós conhecemos; devemos fornecer esses fatos a eles como operador de qualquer forma (Art. 28(3)(f) do RGPD). Segundo, nosso rastreador verifica sites cujos operadores não nos conhecem. Eles devem poder ler quais riscos vemos para eles e para as pessoas nas suas páginas e o que fazemos a respeito.

Natureza jurídica. Esta AIPD é documentação do controlador nos termos do Art. 35 do RGPD, que publicamos voluntariamente. Não faz parte de nenhum contrato e não constitui nenhuma declaração, garantia ou acordo sobre qualidade perante Clientes ou terceiros. Quais serviços e salvaguardas devemos aos Clientes é regido pelos Termos de Serviço, pelo Acordo de Tratamento de Dados e por seus anexos; quanto a essas obrigações, eles prevalecem sobre esta página. A página descreve a situação na data desta versão. As classificações e avaliações de risco são nossa própria visão e não antecipam qualquer avaliação jurídica por uma autoridade de controle ou um tribunal; medidas descritas como “planejadas” são intenções sem uma data assumida como compromisso. Para Clientes, a página é uma base para sua própria avaliação, não orientação jurídica.

Esta é a primeira versão da avaliação dos critérios de obrigatoriedade. Ela examina, operação de tratamento por operação de tratamento, se uma AIPD é necessária e registra o resultado na seção 3.5.

Toda afirmação factual está sujeita ao mesmo princípio dos nossos outros documentos legais: medido, não apenas pretendido. O que é comprovado no código ou no banco de dados é indicado aqui com a referência à fonte. O que não pôde ser comprovado é marcado como “não verificado”. O que está apenas planejado é chamado de “planejado”. Declaramos os pontos pendentes abertamente, junto com a medida planejada; uma AIPD que lista apenas pontos fortes não ajuda as pessoas a que se refere.

Termos: um operador de site é quem opera um site verificado. Um Cliente tem uma conta em formexposed. Um visitante é quem usa o site de um Cliente, por exemplo, seu formulário de contato. Uma referência à fonte significa um arquivo, função ou configuração no código-fonte, medido em relação ao estado do sistema de desenvolvimento em 11 de outubro de 2026.

Deliberadamente, traçamos um limite para a transparência: pontos pendentes na segurança dos nossos próprios servidores são descritos apenas em termos gerais (R13). Indicamos o risco e seu nível, mas não o caminho até uma vulnerabilidade específica; forneceremos os detalhes a uma autoridade de controle mediante solicitação.

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

O Art. 35 atribui a obrigação ao controlador. formexposed é o controlador de algumas operações de tratamento, operador para seus Clientes em outras e nenhum dos dois para os dados que nosso plugin WordPress e nossa extensão TYPO3 armazenam no site de um Cliente. A resposta a quase toda pergunta neste documento depende do papel ao qual a pergunta se refere. A distribuição segue a Política de Privacidade e o Acordo de Tratamento de Dados.

Operação de tratamento	Papel de formexposed	Quem tem a obrigação nos termos do Art. 35
Verificação de sites de terceiros sem instruções do seu operador: verificação gratuita, verificação de potencial cliente para agências, estudo	Controlador	formexposed
Verificação de domínios na conta do Cliente: monitoramento, envios de teste ativos, fluxos de navegação, arquivos expostos, verificação de disponibilidade do formulário	Controlador da conta e dos dados de verificação do Cliente; operador dos dados pessoais de terceiros visíveis no site verificado do Cliente; enquanto um domínio não for verificado, controlador como na verificação gratuita	formexposed pela sua própria parte; o Cliente pelos dados de terceiros no seu site
Verificação de áreas protegidas por login com uma conta de teste	Operador: as credenciais e o conteúdo da área protegida por login pertencem ao site do Cliente	O Cliente; formexposed auxilia
Verificação de entrega com cópia de controle	Operador	O Cliente; formexposed auxilia
Proteção coletiva: lista compartilhada de domínios de links de spam bloqueado	Controlador: combinamos os relatos de muitos sites, compilamos a lista e a distribuímos	formexposed
Contas de clientes, login, registros, suporte, envio de e-mails, pagamentos, registros de comprovação	Controlador	formexposed
Portal de clientes e relatório mensal aos assinantes de uma agência	Operador	A agência
Dados que o plugin e a extensão armazenam no site do Cliente (quarentena, rede de segurança, consultas armazenadas)	Nenhum dos dois: os dados nunca saem do site	O operador do site

Disso resulta uma distinção que declaramos expressamente, pois costuma ser interpretada incorretamente nos dois sentidos. Quando formexposed é o controlador, realizamos a avaliação por conta própria e assumimos seu resultado. Quando somos operador, não podemos realizar a avaliação do Cliente em seu lugar, decidir por ele a questão da necessidade nem consultar a autoridade de controle nos termos do Art. 36 em seu nome. O que podemos e devemos fazer nesses casos é fornecer tudo de que ele precisa: a descrição da alínea (a), os fatos medidos sobre os riscos da alínea (c) e uma lista honesta do estado das medidas da alínea (d). Para a verificação de entrega e a verificação de áreas protegidas por login, esta página é exatamente isso.

Um Cliente que adota sem alterações as seções sobre a verificação de entrega como sua própria AIPD não realizou uma. Se a cópia de controle é justificada para seus formulários, se categorias especiais de dados pessoais são esperadas neles e como ele informa seus visitantes são questões que só ele pode decidir. A seção 11 resume o que precisa ser esclarecido para essa finalidade.

3. Avaliação dos critérios de obrigatoriedade: uma AIPD é necessária?

3.1 Art. 35(1) e Art. 35(3)

O Art. 35(1) exige uma AIPD quando um tipo de tratamento, em particular usando novas tecnologias, levando em conta a natureza, o escopo, o contexto e as finalidades do tratamento, provavelmente resultar em alto risco para os direitos e liberdades das pessoas físicas. O Art. 35(3) indica três casos em que isso ocorre em particular. Nenhum dos três se enquadra em formexposed, e isso deve ser fundamentado em vez de apenas afirmado:

Alínea (a) – uma avaliação sistemática e abrangente de aspectos pessoais relativos a pessoas físicas, baseada em tratamento automatizado e na qual se baseiem decisões que produzam efeitos jurídicos ou as afetem de maneira igualmente significativa. Avaliamos formulários e sites, não aspectos pessoais de pessoas. O serviço não toma nenhuma decisão com efeito jurídico sobre uma pessoa. O que mais se aproxima disso é a proteção coletiva: mensagens contendo um link para um domínio listado vão para a quarentena nos sites conectados. Essa é uma consequência automatizada para a mensagem, não uma avaliação abrangente de uma pessoa; tratamos disso no critério “Avaliação ou pontuação” da seção 3.3.
Alínea (b) – tratamento em larga escala de categorias especiais nos termos do Art. 9 ou de dados relativos a infrações penais nos termos do Art. 10. Não é pretendido nem foi desenvolvido. Ainda assim, esses dados podem chegar a nós por uma via: na cópia de controle de mensagens reais de visitantes na verificação de entrega. Isso depende do caso individual e não é de larga escala na acepção desta disposição; no entanto, é levado em conta na avaliação de risco (R1).
Alínea (c) – monitoramento sistemático de uma área publicamente acessível em larga escala. Isso significa a observação física de locais, não a obtenção de páginas web públicas. Seria incorreto citar essa disposição como fundamento para um rastreador de sites.

Portanto, o caminho correto é o próprio Art. 35(1), aplicado pelos nove critérios das Diretrizes sobre Avaliação de Impacto sobre a Proteção de Dados do Grupo de Trabalho do Artigo 29 (WP248 rev.01, endossadas pelo Comitê Europeu para a Proteção de Dados) e pela lista da autoridade de controle polonesa nos termos do Art. 35(4) (seção 3.4).

3.2 Os nove critérios das diretrizes WP248

As diretrizes indicam nove características que apontam para um provável alto risco. Como regra prática, uma operação de tratamento que atenda a duas delas exigirá, na maioria dos casos, uma AIPD. Um controlador pode chegar a uma conclusão diferente em um caso individual, mas deve então fundamentá-la e documentá-la. Por outro lado, um único critério pode bastar. Nesta página, usamos os seguintes rótulos curtos:

C1 – Avaliação ou pontuação, incluindo definição de perfis e previsão, por exemplo, de desempenho no trabalho, situação econômica, confiabilidade ou comportamento.
C2 – Decisões automatizadas com efeito jurídico ou impacto significativo semelhante.
C3 – Monitoramento sistemático, ou seja, tratamento usado para observar, monitorar ou controlar titulares de dados, inclusive por redes. As diretrizes justificam expressamente esse critério pelo fato de os titulares frequentemente não saberem quem está coletando seus dados e para qual finalidade.
C4 – Dados sensíveis ou de natureza altamente pessoal: categorias especiais nos termos dos Art. 9 e 10, mas também dados cuja divulgação afete significativamente a vida cotidiana, incluindo comunicações eletrônicas cuja confidencialidade deva ser protegida.
C5 – Dados tratados em larga escala, medida pelo número de titulares de dados, volume e variedade dos dados, duração e extensão geográfica.
C6 – Comparação ou combinação de conjuntos de dados originados de diferentes operações de tratamento ou de diferentes controladores, de uma forma que os titulares não esperariam.
C7 – Dados relativos a titulares vulneráveis, por exemplo, empregados, crianças, pacientes ou outras pessoas em uma relação de desequilíbrio de poder.
C8 – Uso inovador ou aplicação de novas soluções tecnológicas ou organizacionais; na prática das autoridades de controle, o uso de inteligência artificial é regularmente considerado abrangido por esse critério.
C9 – Tratamento que impede titulares de dados de exercer um direito ou usar um serviço ou contrato.

Classificamos cada critério como “atendido”, “limítrofe” ou “não atendido” e fundamentamos a classificação a partir do código. Um caso limítrofe não conta como atendido no total, mas é indicado no resultado; quando vários casos limítrofes apontam na mesma direção, incluímos a operação de tratamento na avaliação.

3.3 Avaliação por operação de tratamento

P1 – Verificação gratuita sem uma conta (verificação de qualquer site de terceiro mediante solicitação)

Qualquer pessoa pode informar um domínio na página inicial. O rastreador então obtém no máximo oito páginas públicas desse site, lê os formulários, faz capturas de tela e produz um relatório que qualquer pessoa que conheça seu link aleatório pode ver. O operador do site não fica sabendo disso, salvo se perceber o identificador do rastreador nos seus registros.

C1 – limítrofe. O relatório avalia a proteção de um formulário com um nível (“Exposto”, “Parcialmente protegido”, “Protegido”) e uma pontuação. Para uma sociedade limitada, isso não diz respeito a uma pessoa física. Para empresários individuais e profissionais autônomos, o domínio pode ser atribuído à pessoa, e o nível então diz algo sobre o cuidado tomado na sua atividade profissional. No entanto, o que é avaliado é uma configuração técnica, não o comportamento ou as características de uma pessoa. Tratamos isso como limítrofe.
C2 – não atendido. Nada é decidido em relação ao operador. Em relação à pessoa que solicita a verificação, aplicam-se limites por endereço IP e sessão (cfg/check_lib.php); uma verificação rejeitada não tem efeito significativo.
C3 – não atendido. É uma obtenção individual mediante solicitação, no máximo uma vez por domínio e semana (cfg/check_lib.php, configuração fc_domain_days = 7). Nenhuma pessoa é observada. No entanto, a circunstância que as diretrizes citam para justificar C3 – os titulares nada sabem sobre o tratamento – está presente. Ela é levada em conta na avaliação de risco (R5).
C4 – não atendido. O que é armazenado é a estrutura do formulário e as constatações, não os valores inseridos (scanner/src/crawl.js armazena apenas o comprimento de um valor para campos visíveis). O verificador lê o início dos campos ocultos preenchidos previamente (até 24 caracteres) e dos atributos de dados (até 60 caracteres) apenas durante a verificação, para detectar tokens e registros de tempo; eles não são armazenados. As capturas de tela podem mostrar incidentalmente pessoas e nomes; o site de um consultório médico mostra sua especialidade na imagem. Esses são dados profissionais públicos, não dados de saúde de uma pessoa específica.
C5 – limítrofe. O limite diário é de 200 verificações aceitas (fc_daily_cap), ou seja, aritmeticamente até cerca de 73.000 sites por ano. Apenas poucos dados pessoais surgem por site, e a duração é curta (30 dias). Medido no sistema de desenvolvimento, há 2 verificações anônimas no conjunto de dados. Não atendido hoje; limítrofe considerando a capacidade projetada.
C6 – não atendido. Além de obter as páginas, o serviço consulta a idade do domínio pelo serviço RDAP rdap.org (apenas o nome do domínio é transmitido; apenas a data de registro é armazenada, em cache) e resolve DNS. Esses são detalhes técnicos sobre o domínio, não uma combinação de conjuntos de dados sobre pessoas.
C7 – não atendido.
C8 – atendido, de forma fraca. Um navegador automatizado verifica as páginas, e um modelo de linguagem em nosso próprio servidor classifica os formulários que as regras não reconhecem (scanner/src/classify.js). O modelo vê o título da página, o endereço, os rótulos dos campos e até 400 caracteres do texto do formulário. Nunca pode tornar um formulário “apto para envio”.
C9 – não atendido.

Resultado intermediário P1: um critério de forma fraca (C8), dois casos limítrofes (C1, C5). Sem obrigação segundo a regra prática. Como ambos os casos limítrofes apontam na mesma direção e os titulares nada sabem sobre o tratamento, incluímos P1 na avaliação.

P2 – Verificação de potencial cliente para agências

Uma agência no plano Business com sua própria marca configurada pode solicitar a verificação passiva do site de um potencial cliente. Ela recebe uma constatação breve sob sua marca e um relatório detalhado e encaminha o link por conta própria (cfg/akquise_lib.php). Não entramos em contato com ninguém.

C1 – limítrofe, mais forte do que para P1. A constatação breve é expressamente destinada a “abrir portas para a primeira conversa”. A avaliação do site torna-se, assim, a base para abordar uma pessoa comercialmente.
C5 – não atendido. No máximo 30 verificações por agência e mês (prospect_monthly), excluídas após 90 dias.
C8 – atendido, de forma fraca (a mesma tecnologia de P1).
Outros critérios – não atendidos. A constatação é apresentada com a marca da agência, mas não vinculada a outros dados sobre o operador.

Resultado intermediário P2: sem obrigação segundo a regra prática; incluído pelos mesmos motivos de P1 e porque a finalidade – aquisição de clientes – traz um risco próprio (R6).

P3 – Estudo “Índice de Segurança de Formulários”

Para um estudo, uma lista de sites é verificada passivamente, com limitação a no máximo cinco tarefas abertas por execução do processo de status, que ocorre a cada cinco minutos (cfg/studie_lib.php). Apenas totais são publicados, e segmentos apenas a partir de 20 sites com formulário (study_min_segment, cfg/studie_lib.php). Os dados brutos são excluídos na publicação (cfg/studie_lib.php).

C5 – limítrofe, atendido para listas grandes. O tamanho da lista não é limitado no código; a limitação de frequência permite aritmeticamente mais de mil verificações por dia. Um estudo de um mercado nacional abrange milhares de sites, muitos deles operados por empresários individuais. A partir desse porte, consideramos o critério atendido.
C8 – atendido, de forma fraca.
C1 – não atendido. Embora o site individual seja avaliado, apenas o total é publicado; a avaliação não serve para fazer uma afirmação sobre o operador individual.
Outros critérios – não atendidos.

Resultado intermediário P3: para estudos do porte projetado, dois critérios (C5, C8). Portanto, o estudo atinge o limiar; formexposed realiza a avaliação como controlador. Medido no sistema de desenvolvimento, nenhum estudo foi criado até agora.

P4 – Verificação de domínios na conta do Cliente

O Cliente solicita verificações regulares dos domínios na sua conta. Depois de comprovar que está autorizado a controlar o domínio, acrescentam-se envios de teste ativos (no máximo cinco por verificação), a busca por arquivos expostos e os fluxos de navegação configurados.

C3 – não atendido. A verificação é programada e recorrente, mas diz respeito ao próprio site do Cliente e é realizada a seu pedido, não para observar pessoas.
C4 – limítrofe, não. A busca por arquivos expostos lê no máximo os primeiros 8 KB de caminhos como /backup.sql ou um registro de depuração para determinar pelo conteúdo se o arquivo está realmente exposto (cfg/dateien_lib.php). Esse trecho pode conter valores de formulário inseridos por visitantes. Ele é verificado apenas na memória e nunca armazenado; o que é armazenado é o caminho, o tipo e a gravidade.
C8 – atendido, de forma fraca.
Outros critérios – não atendidos.

Etapa acrescentada do plano de ação. Relatórios pagos elegíveis podem conter texto consultivo gerado localmente com base em constatações selecionadas e metadados da verificação. Ele é armazenado com a verificação e exibido com um aviso de IA; as constatações individuais continuam sendo a referência determinante. Não altera sites automaticamente nem toma decisões sobre pessoas com efeito jurídico ou impacto significativo semelhante. O uso de um modelo de linguagem, por si só, não determina se uma AIPD separada é necessária. Suas entradas, destinatários, escala e riscos residuais precisam ser avaliados junto com a verificação subjacente, incluindo a possível repetição de dados pessoais de URLs ou notas e recomendações incorretas em um relatório compartilhável por link. As seções 7 a 9 abaixo incluem essa etapa; este adendo factual não afirma uma medição concluída em produção, aprovação do proprietário ou nova classificação de risco residual.

Resultado intermediário P4: A verificação técnica subjacente não atinge o limiar com base nos fatos descritos acima. A etapa consultiva local acrescentada não estabelece por si só uma obrigação separada, mas o resultado anterior sobre o limiar não substitui a consideração dos seus dados reais de entrada, escala, destinatários e efeitos. Incluída porque os envios de teste ativos e a verificação de arquivos dependem de uma comprovação que nunca é renovada (R7).

P5 – Verificação de áreas protegidas por login

Para um domínio verificado, o Cliente pode armazenar uma conta de teste do seu site. O verificador faz login com ela e lê os formulários em até cinco páginas especificadas da área de membros (cfg/login_lib.php, scanner/src/login.js).

C4 – limítrofe. Credenciais não são dados de natureza altamente pessoal na acepção das diretrizes, mas seu uso indevido abre a área de membros. Dependendo do site, conteúdo confidencial pode estar protegido por login, por exemplo, em um portal de membros ou pacientes. Isso depende do Cliente, não de nós.
C8 – não atendido. Logins automatizados são comuns em serviços de monitoramento.
Outros critérios – não atendidos.

Resultado intermediário P5: sem obrigação segundo a regra prática. Para Clientes cuja área de membros mostre conteúdo confidencial, isso pode mudar; nesse caso, a decisão cabe a eles. Incluído por causa dos riscos de segurança (R8).

P6 – Verificação de entrega com cópia de controle

O Cliente insere um endereço de controle de formexposed como cópia oculta nas configurações de e-mail do seu formulário. Como resultado, cada e-mail de formulário também vai para nossa caixa de e-mail de controle – nossa mensagem de teste assim como cada mensagem real de um visitante. Uma obtenção automatizada lê os cabeçalhos e os primeiros 8 KB, associa o e-mail, avalia SPF, DKIM e DMARC e o exclui (cfg/zustellung_lib.php).

C4 – atendido. O que os visitantes escrevem em um formulário de contato é comunicação eletrônica para uma empresa com conteúdo arbitrário. No site de um consultório médico, escritório de advocacia, serviço de aconselhamento ou escola, são esperados dados nos termos do Art. 9 ou sobre crianças. As diretrizes mencionam expressamente comunicações eletrônicas confidenciais nesse critério.
C3 – limítrofe, tendendo a atendido. Cada mensagem é copiada de forma planejada e contínua e avaliada automaticamente, sem que o remetente perceba. A finalidade é verificar a rota do e-mail, não observar pessoas. No entanto, a circunstância com que as diretrizes justificam o critério – os titulares não sabem quem recebe seus dados – está plenamente presente enquanto o Cliente não informar seus visitantes.
C7 – depende do Cliente. Pacientes, clientes de escritórios de advocacia, candidatos a emprego, pais e alunos frequentemente estão em uma relação de dependência em relação ao destinatário da sua mensagem.
C5 – limítrofe, não. Não é de larga escala para o Cliente individual. Em formexposed, as cópias de muitos Clientes convergem em uma caixa de e-mail; isso aumenta o peso de uma violação, não o número por controlador.
Outros critérios – não atendidos. A associação ao domínio e ao teste não é uma comparação de conjuntos de dados sobre pessoas; a tecnologia não é nova.

Resultado intermediário P6: C4 atendido, C3 limítrofe e tendendo a atendido, C7 atendido para muitos Clientes típicos. Portanto, na configuração típica, dois ou mais critérios são atendidos. Uma AIPD é necessária – como obrigação do Cliente, que é o controlador. As seções 6 a 11 fornecem os fatos para isso.

P7 – Proteção coletiva

Sites WordPress conectados informam uma vez por dia os domínios dos links de mensagens que sua camada de proteção interrompeu. Um domínio que aparece em pelo menos três sites diferentes com pelo menos cinco ocorrências em sete dias é colocado em uma lista compartilhada; a lista é enviada de volta a todos os sites conectados, que então colocam mensagens com links para esse domínio em quarentena (cfg/swarm_lib.php).

C6 – atendido. Relatos de muitos sites mutuamente independentes, ou seja, de diferentes controladores, são combinados e devolvidos a todos como uma lista compartilhada.
C1 – atendido, na medida em que um domínio possa ser atribuído a uma pessoa física. A lista é uma classificação como fonte de spam. As diretrizes citam a comparação com um banco de dados compartilhado de fraudes como exemplo desse critério. A maioria dos domínios em uma lista desse tipo pertence a empresas ou é descartável; no entanto, o domínio de uma pessoa pode acabar nela, corretamente ou por relatos falsos inseridos deliberadamente.
C9 – limítrofe. Uma mensagem com um link listado não chega imediatamente ao destinatário, mas permanece na sua quarentena até que ele a libere. Ela não é perdida.
C2 – não atendido. A quarentena é uma consequência automatizada para uma mensagem, sem efeito jurídico e com liberação humana pelo destinatário.
Outros critérios – não atendidos. As redes IP estão desativadas (swarm_ip_enabled = 0, cfg/swarm_lib.php).

Resultado intermediário P7: dois critérios (C6, C1) e um caso limítrofe (C9). O limiar é atingido; formexposed realiza a avaliação como controlador. Com redes IP ativadas, C1 e C6 seriam atendidos sem restrição; sua ativação exige uma nova versão desta avaliação (seção 12). Medido no sistema de desenvolvimento, não há relatos nem entradas na lista.

P8 – Contas de clientes, login, registros, suporte, e-mail, pagamentos

C1 e C9 – não atendidos. Comportamento suspeito na verificação gratuita leva a uma nota com o endereço IP (cfg/check_lib.php) e, quando aplicável, à rejeição de novas verificações. Isso é prevenção de abuso com pouco efeito, não uma avaliação de aspectos pessoais.
Outros critérios – não atendidos. Esses são os dados habituais de um serviço para empresas.

Resultado intermediário P8: nenhuma AIPD necessária. As operações de tratamento estão descritas no Registro das Atividades de Tratamento.

P9 – Números de plugins, erros de campos, gravador, selo, portal de clientes, “Fix it for me”

O plugin e a extensão transmitem números diários, o inventário de plugins e categorias de erros, e o plugin WordPress também transmite domínios de links para a proteção coletiva (ativada por padrão) (P7), sem conteúdo, endereços, nomes ou IPs de visitantes; o gravador mantém seletores por no máximo 15 minutos no navegador do administrador. Nenhum critério atendido.
Ao carregar, o selo transfere os dados habituais de conexão para o registro do servidor web, sem cookie. Nenhum critério atendido.
O portal de clientes trata os endereços de e-mail dos assinantes com dupla confirmação de adesão em nome da agência. Nenhum critério atendido.
“Fix it for me” solicita que um modelo de linguagem em nosso próprio servidor reescreva o código de formulário colado; o código não é armazenado. C8 de forma fraca, nada mais.

Resultado intermediário P9: nenhuma AIPD necessária.

3.4 A lista da autoridade de controle polonesa nos termos do Art. 35(4)

A autoridade competente é o Presidente do Órgão de Proteção de Dados Pessoais (Prezes Urzędu Ochrony Danych Osobowych, UODO). O Presidente publicou a lista dos tipos de operações de tratamento que exigem uma AIPD na comunicação de 17 de junho de 2019 (Komunikat Prezesa Urzędu Ochrony Danych Osobowych z dnia 17 czerwca 2019 r. w sprawie wykazu rodzajów operacji przetwarzania danych osobowych wymagających oceny skutków przetwarzania dla ich ochrony, Monitor Polski 2019, item 666). A lista relaciona suas entradas aos critérios das diretrizes WP248, fornece exemplos e é expressamente não exaustiva; não substitui a avaliação nos termos do Art. 35(1).

Na nossa leitura, os seguintes tipos de tratamento da lista correspondem, em substância, a operações de tratamento de formexposed:

Tipo de tratamento segundo a lista (parafraseado)	Critério atribuído	Operação de tratamento em formexposed	Avaliação
Comparação, avaliação ou inferência com base na análise de dados de diferentes fontes	C6	P7 Proteção coletiva	aplica-se
Avaliação ou pontuação, incluindo definição de perfis	C1	P7 Proteção coletiva; P1 e P2 como casos limítrofes	aplica-se a P7
Tratamento de categorias especiais de dados pessoais	C4	P6 Verificação de entrega	aplica-se conforme o Cliente
Uso inovador ou aplicação de soluções tecnológicas	C8	P1 a P4 (modelo de linguagem para classificação)	aplica-se de forma fraca
Tratamento em larga escala	C5	P3 Estudo	aplica-se a listas grandes
Monitoramento sistemático de locais publicamente acessíveis, inclusive com reconhecimento de características	C3	–	não se aplica: refere-se a locais, não a sites

Essa distribuição é uma leitura, não uma citação; a redação das entradas deve ser conferida em relação a ela na revisão jurídica. Ela confirma o resultado da seção 3.3, mas não o altera. Até onde sabemos, a UODO não publicou uma lista nos termos do Art. 35(5) – operações de tratamento para as quais não é necessária uma AIPD.

3.5 Resultado da avaliação dos critérios de obrigatoriedade

Operação de tratamento	Atendidos	Limítrofes	Resultado
P1 Verificação gratuita	C8 (fraco)	C1, C5	não obrigatória; incluída
P2 Verificação de potencial cliente	C8 (fraco)	C1	não obrigatória; incluída
P3 Estudo	C8 (fraco), C5 para listas grandes	–	necessária (obrigação de formexposed)
P4 Verificação de domínios do Cliente	C8 (fraco)	C4 (verificação de arquivos)	não obrigatória; incluída
P5 Verificação de áreas protegidas por login	–	C4	não obrigatória; incluída; para o Cliente, depende do conteúdo
P6 Verificação de entrega	C4; C7 depende do Cliente	C3 (tende a atendido), C5	necessária (obrigação do Cliente; esta página auxilia nos termos do Art. 28(3)(f))
P7 Proteção coletiva	C6, C1	C9	necessária (obrigação de formexposed)
P8 Contas, registros, suporte, pagamentos	–	–	não necessária
P9 Números de plugins, selo, portal, “Fix it for me”	C8 (fraco, apenas “Fix it for me”)	–	não necessária

Resultado sobre o Art. 35(1): Uma AIPD é necessária para operações de tratamento individuais de formexposed. É necessária para a proteção coletiva e para estudos do porte projetado, e formexposed a realiza como controlador. Para a verificação de entrega, é necessária na configuração típica, mas como obrigação do Cliente; formexposed fornece a base. Para as outras verificações de sites de terceiros e próprios, não é obrigatória. Ainda assim, nós as incluímos porque usam a mesma tecnologia, porque vários casos limítrofes apontam na mesma direção e porque os titulares dos dados – operadores sem uma conta e pessoas nas páginas verificadas – nada sabem sobre o tratamento. Não é necessária avaliação para contas, registros, suporte e pagamentos.

Portanto, as seções 6 a 10 aplicam-se a P1 a P7. Quando uma afirmação se aplica apenas a uma dessas operações de tratamento, isso é indicado.

4. Encarregado da proteção de dados: a avaliação nos termos do Art. 37

Nenhum encarregado da proteção de dados foi designado. O Art. 37(1) vincula tanto o controlador quanto o operador; portanto, a questão é nossa. Os três casos legais:

Art. 37(1)	Condição	Resultado
alínea (a)	Autoridade ou organismo público	Não se aplica; LW IT Solutions Company Lukas Wójcik é uma empresa individual privada.
alínea (b)	As atividades principais consistem em operações de tratamento que exijam monitoramento regular e sistemático dos titulares de dados em larga escala	A atividade principal é verificar e monitorar sites e formulários, de forma regular e sistemática. No entanto, nenhuma pessoa é monitorada: o rastreador não observa comportamento, e a verificação de entrega avalia e-mails apenas quanto à entrega e autenticidade. Não atendida.
alínea (c)	As atividades principais consistem no tratamento em larga escala de dados nos termos dos Art. 9 ou 10	Não está previsto no projeto. Categorias especiais podem chegar a nós pela cópia de controle da verificação de entrega; isso é incidental, não uma atividade principal. Não atendida.

Portanto, segundo nossa avaliação, não há obrigação de designar um. Se a legislação polonesa exige uma designação além disso nos termos do Art. 37(4) é uma questão pendente para a revisão jurídica. Como nenhum encarregado da proteção de dados foi designado, não se aplica o aconselhamento nos termos do Art. 35(2). Se a revisão jurídica concluir que há obrigação de designação, o aconselhamento do encarregado então designado será solicitado antes da aprovação desta avaliação (seção 12). O contato para dúvidas sobre esta avaliação é o proprietário em contact@lukaswojcik.com.

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

Os fatos deste documento vêm do código-fonte da aplicação e do verificador, do esquema do banco de dados e de contagens de linhas e configurações do sistema de desenvolvimento, medidos em 11 de outubro de 2026. O banco de dados e os servidores foram acessados somente para leitura. Quando uma medição contradiz uma intenção – inclusive uma afirmação nos nossos próprios documentos legais – informamos a medição. Não aplicamos códigos de conduta aprovados nos termos do Art. 40, cujo cumprimento teria de ser levado em conta nos termos do Art. 35(8).

O sistema de desenvolvimento foi medido. O serviço ainda não foi lançado. Portanto, os números são pequenos e parcialmente artefatos de testes: 112 verificações, 110 delas sem domínio de Cliente; 432 capturas de tela; 2 domínios, 1 deles verificado; nenhuma verificação de entrega ativada; nenhuma conta de teste armazenada para a verificação de áreas protegidas por login; nenhum estudo; nenhum relato na proteção coletiva. As medições devem ser repetidas antes do lançamento e em intervalos regulares depois dele.
Não medidos nesta versão e a acrescentar antes da aprovação são: a configuração do sistema de produção, incluindo se e como a caixa de e-mail de controle está configurada e se o par de chaves para a verificação de áreas protegidas por login está configurado lá; se o software do modelo de linguagem registra solicitações; o estado da administração dos servidores (R13); o contrato com o prestador de serviços de e-mail.
Não foi possível medir quantas mensagens reais de visitantes passarão pela cópia de controle e de quais setores virão os Clientes. Ambos determinam o peso de R1 e R2 e devem ser apurados após o lançamento.
As referências às fontes apontam para arquivos e funções no código-fonte do sistema de desenvolvimento. O decisivo é a função descrita, não sua localização no arquivo.

Este documento é um rascunho. Ainda não foi aprovado pelo controlador (seção 12), e duas das suas conclusões – a avaliação da escala para P1 e P3 e o peso da verificação de entrega – dependem de números que só existirão após o lançamento.

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

6.1 Como o sistema de verificação é estruturado

formexposed é executado em seus próprios servidores na Polônia, sem um provedor externo de hospedagem: um servidor web com a aplicação e o banco de dados e um servidor de verificação com o serviço de verificação e um modelo de linguagem local, ambos na mesma rede interna. Uma verificação ocorre da seguinte forma:

A aplicação cria uma tarefa no banco de dados – sujeita aos limites e bloqueios da seção 6.3.
O serviço de verificação no servidor de verificação obtém a tarefa, confere a lista de bloqueio, os nomes de hosts e, para verificações anônimas, a idade do domínio uma segunda vez, e inicia um contêiner isolado exatamente para essa tarefa: rede própria com regras próprias de filtragem, sem privilégios especiais, sistema de arquivos somente de leitura, limites de memória e processos e limite de tempo (scanner/src/worker.js).
Dentro do contêiner, um navegador automatizado obtém no máximo oito páginas públicas, primeiro a página inicial e depois, preferencialmente, páginas de contato, informações legais e suporte. Antes, lê o robots.txt; uma exclusão para FormExposedBot ou para todos os rastreadores que abranja a página inicial encerra a verificação, assim como um robots.txt inacessível ou um erro de servidor na obtenção (scanner/src/net.js). Proibições para subcaminhos individuais não são observadas separadamente. A verificação de disponibilidade do formulário, a obtenção da comprovação, a ferramenta de cabeçalhos e a busca por arquivos expostos não leem o robots.txt. Além das oito páginas, há até três páginas com um clique em “Rejeitar” no banner de cookies, até três páginas em visualização de celular, sondagens ativas para domínios verificados e até cinco páginas protegidas por login; as páginas são carregadas uma após a outra, não em paralelo. Cada solicitação do navegador – incluindo redirecionamentos e conteúdo incorporado – passa por um filtro que rejeita redes privadas e outras portas.
O contêiner grava um resultado e as capturas de tela em um diretório temporário. O serviço de verificação transmite o resultado e as imagens à aplicação pela rede interna e exclui o diretório temporário, mesmo após um erro (scanner/src/worker.js).
A aplicação processa o resultado, compara-o com a verificação anterior para domínios de Clientes e informa alterações aos destinos configurados pelo Cliente.

6.2 O que o rastreador armazena – e o que não armazena

Item	O que é armazenado	O que não é armazenado	Referência à fonte
Páginas	Endereço, status HTTP, cabeçalhos, Política de Segurança de Conteúdo, hosts de terceiros solicitados (no máximo 120)	Conteúdo da página como texto ou HTML	`scanner/src/crawl.js`
Campos de formulário	Tipo, nome, rótulo, texto de orientação, campo obrigatório, visibilidade, comprimento de um valor existente	Valores de campos; para campos ocultos, os primeiros 24 caracteres do valor são apenas lidos durante a verificação (para detectar tokens)	`scanner/src/crawl.js`
Endereços de destinatários no formulário	apenas o domínio	o endereço	`scanner/src/crawl.js`
Scripts	Inventário com soma de verificação; endereços e texto inicial sem identificadores de contas de serviços de publicidade e análise	Identificadores de contas e pixels	`scanner/src/crawl.js`
Serviços que acompanham o preenchimento	quais pixels de publicidade e ferramentas de gravação carregam antes e depois do clique em “Rejeitar” no banner de cookies e se mascaram os valores inseridos	Identificadores das contas nesses serviços	`scanner/src/mitleser.js`, `scanner/src/einwilligung.js`
Texto do formulário	até 400 caracteres vão para o modelo de linguagem local se as regras não reconhecerem o tipo	Divulgação a terceiros; armazenamento do texto	`scanner/src/classify.js`
Capturas de tela (rastreador)	área visível da primeira página; para cada formulário visível, uma imagem do elemento do formulário	–	`scanner/src/crawl.js`
Capturas de tela (verificação ativa)	Imagem da página de resposta ao envio de teste; adicionalmente, status, endereço de destino, título e os primeiros 300 caracteres do seu texto	–	`scanner/src/active.js`
Capturas de tela (fluxos de navegação)	Imagem do formulário com campos de entrada cobertos em preto, compactada, no máximo 32 KB	Valores inseridos	`scanner/src/browser.js`
Área protegida por login	como para os campos de formulário acima	Capturas de tela, cookies, links	`scanner/src/login.js`

Esses itens não contêm dados pessoais por concepção, mas os contêm incidentalmente: o nome de uma pessoa de contato ao lado do formulário, uma foto da equipe na página inicial, um telefone em um rótulo, o domínio de e-mail de uma pessoa, um nome em um texto de orientação. Na área protegida por login, acrescentam-se dados da conta de teste e, dependendo do site, de outros usuários.

6.3 Quem aciona uma verificação e o que então se aplica

Acionamento	Nível de confiança na tarefa	Envios de teste	Resultado acessível por	Exclusão
Alguém informa um domínio na página inicial (verificação gratuita)	anonymous	não	Relatório sob um link aleatório	30 dias, incluindo imagens (`cfg/check_lib.php`)
Plugin ou extensão sem uma conta	plugin	não	Relatório sob um link aleatório	30 dias
Agência para um potencial cliente	registered	não	Constatação breve e relatório sob um link aleatório	90 dias (`cfg/akquise_lib.php`)
Cliente, domínio sem comprovação	registered	não	Conta; relatório sob um link aleatório	13 meses, a última verificação é mantida
Cliente, domínio com comprovação	verified	sim, no máximo cinco por verificação	Conta; relatório sob um link aleatório	13 meses, a última verificação é mantida (`cfg/fristen_lib.php`)
Estudo	internal	não	apenas totais após a publicação	na publicação; sem publicação, sem limite de tempo (R4)
Verificação interna pela linha de comando pelo prestador	internal; para nossos próprios domínios de teste e demonstração, também “verified”	não; com o nível “verified”, sim (apenas nossos próprios domínios de teste e demonstração)	apenas interno	sem limite de tempo (R4)

Várias camadas precedem a verificação gratuita (cfg/check_lib.php): uma parada de emergência; reCAPTCHA; o mesmo domínio no máximo uma vez em sete dias (depois disso, o relatório existente é mostrado); limites por endereço IP, por sessão (como valor de hash, nunca o próprio identificador de sessão) e para todo o serviço por dia; a lista de bloqueio do opt-out e o robots.txt; a conferência de que o domínio aponta para endereços públicos; e um bloqueio de domínios muito novos ou desconhecidos. Anomalias – muitos domínios diferentes de um endereço IP, muitas solicitações em pouco tempo – são anotadas com o endereço IP e acionam um sinal sem conteúdo (cfg/check_lib.php).

6.4 Verificação de domínios na conta do Cliente

O Cliente comprova que está autorizado a controlar um domínio: por registro DNS, metatag, arquivo ou pelo nosso plugin (cfg/verify_lib.php). Só então o domínio é tratado como verificado. O agendador de monitoramento programa verificações regulares apenas para domínios ativos, monitorados e verificados (cfg/monitor_lib.php).

Os envios de teste ativos estão vinculados a duas barreiras: a aplicação define o modo ativo para Clientes apenas em domínios verificados (para nossos próprios domínios de teste e demonstração, o prestador pode criar uma verificação com o nível “verified” por uma ferramenta interna de linha de comando), e o serviço de verificação confere novamente o nível de confiança e a parada de emergência fc_active_enabled (scanner/src/worker.js). Só pode ser enviado um formulário que as regras reconheçam com alto grau de certeza como formulário de contato geral, que não tenha campos obrigatórios para dados pessoais reais e cujo domínio não pareça ser de autoridade pública, instituição de ensino, clínica, consultório médico, polícia ou tribunal (scanner/src/classify.js). O modelo de linguagem não pode tornar um formulário apto para envio (scanner/src/classify.js). No máximo cinco envios são realizados por verificação (fc_active_max_posts), claramente identificados, com o remetente dummy@formexposed.com, um endereço sob .invalid para testar a validação de e-mail e uma linha adicional de cabeçalho inofensiva para detectar injeção de cabeçalhos (scanner/src/active.js).
Os fluxos de navegação verificam fluxos de formulário configurados em um navegador até o momento imediatamente anterior ao envio. Apenas solicitações GET e HEAD são permitidas; todo o restante é interrompido, assim como endereços contendo palavras para sair, excluir, comprar ou pagar (scanner/src/browser.js). Para a verificação, os campos obrigatórios são preenchidos com valores inventados que nunca saem do navegador.
Arquivos expostos são procurados semanalmente, apenas em domínios verificados, com no máximo uma obtenção por caminho, no máximo 8 KB e conteúdo nunca armazenado (cfg/dateien_lib.php).
Uma segunda sonda independente foi preparada e fica desativada por padrão (browser_probe_enabled = 0). Se ativada, receberia apenas domínio, endereço, seletor, etapas e escolha de navegador, nunca credenciais, capturas de tela ou dados de visitantes (cfg/formular_probe_lib.php).

6.5 Verificação de áreas protegidas por login

Pré-requisitos: a função está configurada, o domínio está verificado e o Cliente está em um plano pago e é proprietário ou administrador do espaço de trabalho (cfg/login_lib.php); ele confirma que a conta é uma conta de teste com o mínimo possível de direitos (cfg/login_lib.php).

O nome de usuário e a senha são imediatamente criptografados no servidor web com a chave pública do servidor de verificação: uma chave de uso único por registro (X25519), derivação de chave (HKDF-SHA256), AES-256-GCM, vinculados ao domínio (cfg/login_lib.php). Somente o serviço de verificação no servidor de verificação tem a chave privada (scanner/src/geheim.js). Quem tiver o servidor web, o banco de dados ou um backup terá apenas texto cifrado.
A interface mostra apenas o primeiro caractere e o comprimento do nome de usuário (cfg/login_lib.php). As credenciais nunca são exibidas, registradas nem disponibilizadas pela API.
Para uma verificação, a aplicação anexa o texto cifrado à tarefa. O serviço de verificação o descriptografa, apaga imediatamente o campo na tarefa e transmite as credenciais ao contêiner apenas pela entrada padrão, nunca como argumentos de linha de comando (scanner/src/worker.js). Restos em tarefas interrompidas são apagados pelo processo de status após uma hora (cfg/login_lib.php).
Dentro do contêiner, o navegador faz login. Ele interrompe se a página de login redirecionar para outro host, se o formulário de login tiver um CAPTCHA (não contornamos CAPTCHAs) ou se um campo de senha continuar visível após o envio (scanner/src/login.js). Em seguida, apaga o campo de senha na memória da página e descarta as credenciais (scanner/src/login.js).
Ele lê no máximo cinco páginas do mesmo domínio especificadas pelo Cliente. Endereços que contenham palavras para sair, excluir, remover ou cancelar são bloqueados (scanner/src/login.js). Nada é enviado na área protegida por login, nenhuma captura de tela é feita e cookies e links não vão para o resultado (scanner/src/login.js).
A exclusão é definitiva: o texto cifrado é sobrescrito com dados aleatórios de mesmo comprimento, a linha é excluída e as tarefas pendentes são limpas (cfg/login_lib.php). Quando o domínio é excluído, a linha desaparece automaticamente por uma chave estrangeira.

6.6 Verificação de entrega

A verificação de entrega responde se um e-mail do formulário de contato realmente chega e avalia seus recursos de autenticidade. É opcional, desativada por padrão e exige a configuração de uma caixa de e-mail de controle (cfg/zustellung_lib.php).

Se o Cliente a ativar, o domínio recebe uma etiqueta aleatória. O Cliente insere o endereço de controle com essa etiqueta como cópia oculta no seu formulário.
A partir daí, cada e-mail de formulário também vai para a caixa de e-mail de controle: nossos envios de teste identificados e todas as mensagens reais de visitantes. Os e-mails vão diretamente para a caixa de e-mail em Namecheap, Inc. (Private Email), Phoenix, Arizona, USA – só chegam se os registros MX do nosso domínio apontarem para lá; por encaminhamento, por exemplo, no registrador de domínios Namecheap, Inc., não chegam à caixa de e-mail – e permanecem ali até serem obtidos.
O processo de status obtém o conteúdo da caixa de e-mail a cada cinco minutos (srv/cron_status.php). Para cada e-mail, lê os cabeçalhos e no máximo os primeiros 8 KB do texto, sem marcá-lo como lido (cfg/zustellung_lib.php).
A partir dos cabeçalhos, determina a etiqueta e, assim, o domínio e, pelo texto, quando aplicável, o identificador do nosso teste (cfg/zustellung_lib.php). O que é armazenado é o horário, o domínio e, quando aplicável, o identificador do teste (cfg/zustellung_lib.php), por 180 dias (cfg/zustellung_lib.php).
A partir dos cabeçalhos, avalia SPF, DKIM e DMARC e armazena o resultado junto ao domínio: os resultados das verificações, o domínio do endereço do remetente, os domínios das assinaturas e o endereço do servidor de envio de e-mail (cfg/zustellung_lib.php). Se o resultado piorar, um alerta que pode mencionar o domínio do remetente é enviado uma vez ao Cliente (cfg/zustellung_lib.php).
Em seguida, marca cada e-mail obtido para exclusão, incluindo um que não pôde ser associado a nenhum domínio, e o remove da caixa de e-mail no fim da execução (cfg/zustellung_lib.php). Se a execução for interrompida antes disso, os e-mails permanecem até a próxima execução bem-sucedida.
Apenas a cópia do teste exato em questão conta como prova de entrega (cfg/zustellung_lib.php). Se ela não chegar em três horas (delivery_wait_h), o serviço informa “Entrega ausente”.

O texto das mensagens reais nunca é gravado no banco de dados, nem o endereço do visitante. Ainda assim, ambos são lidos: a obtenção carrega os primeiros 8 KB de cada e-mail na memória para procurar o identificador do teste.

6.7 Proteção coletiva

A camada de proteção do plugin WordPress interrompe uma mensagem como spam e conta os domínios dos links nela. Uma vez por dia, o plugin nos informa esses domínios com sua contagem de ocorrências, no máximo 60 por dia; sem endereços, sem texto, sem endereços IP (cfg/swarm_lib.php).
Uma vez por dia, compilamos a lista a partir disso: um domínio é colocado nela se tiver sido informado em sete dias por pelo menos três sites diferentes e com pelo menos cinco ocorrências (swarm_min_sites, swarm_window_days, cfg/swarm_lib.php). Grandes serviços de uma lista fixa de exceções e os domínios dos nossos Clientes, em cada caso incluindo subdomínios, nunca entram na lista (cfg/swarm_lib.php).
A lista vai para todos os sites conectados com a resposta ao informe diário. Sua camada de proteção coloca mensagens com links para domínios listados em quarentena, não na lixeira.
O que deixa de aparecer na nova lista sai dela; os relatos são excluídos após 30 dias (cfg/swarm_lib.php).
Redes IP (/24 ou /48) foram preparadas, mas ficam desativadas até a conclusão da revisão jurídica (cfg/swarm_lib.php).

6.8 Uso de inteligência artificial

Um modelo de linguagem é executado em nosso próprio servidor de verificação, não em um provedor de IA. É usado em três pontos: no serviço de verificação, classifica formulários cujo tipo as regras não reconhecem; nesse processo, vê o título da página, o endereço da página, os rótulos dos botões de envio, os tipos, nomes, rótulos e textos de orientação dos campos e até 400 caracteres do texto do formulário (scanner/src/classify.js). Só é consultado se as regras retornarem “desconhecido”; formulários classificados dessa forma nunca são enviados e não contam para a pontuação nem para a conclusão. Pontuação, conclusão, prevenção de abuso, proteção coletiva e regras de spam são regras fixas, não IA. Em “Fix it for me”, reescreve o código de formulário colado; o código não é armazenado. Para verificações elegíveis de domínios em contas pagas, também gera um plano de ação priorizado a partir do nome do host, do resultado geral e da pontuação, do CMS, do tipo de formulário relevante e do endereço da página, de eventuais plugins identificados e de constatações selecionadas com falha ou resultado incerto. A solicitação é armazenada temporariamente na fila interna de tarefas e excluída após a coleta ou a limpeza programada de entradas com mais de uma hora. O texto gerado, o idioma, o status e o registro de tempo são mantidos com o resultado da verificação sob suas regras de retenção. O relatório identifica o plano como um resumo de IA e torna as constatações individuais determinantes; o plano não altera o site nem o resultado da verificação. O modelo não toma decisões sobre pessoas. Saiba mais na página Regulamento de IA da UE: Como formexposed Usa IA.

6.9 Bases legais

Operação de tratamento	Base legal
P1 Verificação gratuita: verificação do domínio solicitado; limites e prevenção de abuso	em relação à pessoa solicitante, Art. 6(1)(b); em relação ao operador e às pessoas retratadas, Art. 6(1)(f); prevenção de abuso, Art. 6(1)(f)
P2 Verificação de potencial cliente	Art. 6(1)(f) (interesse legítimo da agência e de formexposed)
P3 Estudo	Art. 6(1)(f)
P4 Verificação de domínios do Cliente	Art. 6(1)(b) em relação ao Cliente; para dados de terceiros no seu site, instruções do Cliente nos termos do Art. 28
P5 Verificação de áreas protegidas por login	Instruções do Cliente nos termos do Art. 28; base legal do Cliente
P6 Verificação de entrega	Instruções do Cliente nos termos do Art. 28; base legal do Cliente (na nossa sugestão de texto para Clientes, Art. 6(1)(f))
P7 Proteção coletiva	Art. 6(1)(f) (defesa conjunta contra spam em muitos sites)

Nosso interesse legítimo em P1 a P3 está em mostrar aos operadores e aos seus prestadores de serviços os pontos fracos dos seus formulários antes que sejam explorados para spam ou abuso e em prestar o serviço. Os dados vêm de fontes publicamente acessíveis. A ponderação dos interesses está descrita na seção 7; se o Art. 6(1)(f) fundamenta a verificação de sites de terceiros mediante solicitação é uma questão pendente para a revisão jurídica.

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

Destinatário	O quê	Operação de tratamento	Status
Ninguém fora de formexposed	Resultados de verificações, capturas de tela, classificação pelo modelo de linguagem	P1–P5	O serviço de verificação e o modelo de linguagem são executados em nossos próprios servidores; no percurso de verificação do rastreador, não foi encontrada nenhuma chamada a terceiros além do próprio site verificado, dos serviços cujo conteúdo ele incorpora (como com qualquer visitante) e do serviço RDAP rdap.org para a idade do domínio (apenas o nome do domínio); as verificações de monitoramento estão listados na linha seguinte
Qualquer pessoa que conheça o link	Relatório com constatações e capturas de tela	P1, P2, P4	link aleatório com 128 bits (`cfg/check_lib.php`), páginas com `noindex` (`www/report.php`)
Serviços consultados pelo monitoramento de um domínio do Cliente	Listas de bloqueio DNS (SpamCop, PSBL, Mailspike, SURBL): domínios e endereços IP de servidores, sem dados de visitantes; Google Web Risk apenas se configurado: o endereço da página inicial; autoridades de carimbo do tempo Certum e DigiCert: apenas um valor de hash do registro de evidências; RDAP pelo registro da IANA: apenas o nome do domínio; páginas de status dos provedores: nada é transmitido; wpvulnerability.net: identificador de um plugin (sem versão) ou tema e a versão do WordPress	P4	em uso; detalhes no Registro das Atividades de Tratamento e na página Suboperadores
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Cópias de controle incluindo mensagens reais de visitantes	P6	Contrato ainda não celebrado; local de tratamento e mecanismo de transferência ainda a examinar
Namecheap, Inc. (EUA)	Registrador e DNS; até a configuração da caixa de e-mail, encaminhamento de e-mails gerais para endereços do nosso domínio, não das cópias de controle (estas só chegam à caixa de e-mail por registros MX apontando diretamente para ela)	– (sem cópias de controle)	Mecanismo de transferência a examinar
Canais de alerta escolhidos pelo Cliente (e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	Evento, domínio, link; para a verificação de autenticidade, o domínio do remetente se não pertencer ao site	P4, P6	destino escolhido pelo Cliente; em parte fora da UE. Enviamos mensagens do Telegram pelo nosso bot; o mecanismo de transferência para isso é uma questão pendente para a revisão jurídica
Todos os sites conectados	Lista de domínios de links	P7	pela resposta ao plugin
Segunda sonda	Domínio, endereço do formulário, seletor, etapas	P4	desativada

6.11 Retenção, medida, não apenas pretendida

A exclusão ocorre principalmente à noite às 03:00 no processo de status (srv/cron_status.php, cfg/fristen_lib.php); os relatos de proteção coletiva e as linhas de potenciais clientes são excluídos diariamente a partir das 04:00, e as associações da verificação de entrega em cada obtenção; relatórios anônimos e de potenciais clientes são excluídos pela sua data de expiração (cfg/check_lib.php). As capturas de tela são excluídas do disco junto com sua verificação (cfg/fristen_lib.php).

Dados	Prazo segundo o código	Referência à fonte	Constatação
Verificação gratuita incluindo imagens	30 dias	`cfg/check_lib.php`	efetivo
Verificação de potencial cliente incluindo imagens	90 dias	`cfg/akquise_lib.php`; `srv/cron_status.php` (linhas de potenciais clientes)	efetivo
Verificações de um domínio do Cliente	13 meses; a última é mantida enquanto o domínio existir	`cfg/fristen_lib.php`	efetivo
Resultados de fluxos de navegação incluindo imagens com campos encobertos em preto	13 meses	`cfg/fristen_lib.php`	efetivo
Dados de um domínio excluído	imediatamente; órfãos à noite	`cfg/fristen_lib.php` (`fe_domain_loeschen()`, `fe_fristen_lauf()`)	efetivo, incluindo o inventário e as alterações de scripts, que não têm prazo de retenção próprio além disso (veja Registro das Atividades de Tratamento)
Estudo: dados brutos incluindo imagens	na publicação	`cfg/studie_lib.php`	sem publicação, sem limite de tempo; a lista de hosts verificados permanece sem limite de tempo mesmo após a publicação
Verificações internas sem um domínio e sem um relatório	nenhum	–	sem exclusão; medido: 85 verificações com 369 imagens desde 22 de setembro de 2026 (R4)
Associações da verificação de entrega	180 dias	`cfg/zustellung_lib.php`	efetivo
Resultado da verificação de autenticidade junto ao domínio	até o próximo resultado ou a exclusão do domínio	`cfg/zustellung_lib.php`	sobrescrito, não limitado no tempo
Cópias de controle na caixa de e-mail	até a próxima obtenção bem-sucedida (intervalo de cinco minutos)	`cfg/zustellung_lib.php`	cópias e backups no provedor da caixa de e-mail não verificados
Credenciais para a verificação de áreas protegidas por login	até a exclusão pelo Cliente ou do domínio; na tarefa, no máximo até o fim da execução, restos após uma hora	`cfg/login_lib.php`	efetivo; nos backups, apenas como texto cifrado por até 14 dias
Relatos na proteção coletiva	30 dias	`cfg/swarm_lib.php`	efetivo
Limites da verificação gratuita (IP, país, hash da sessão)	7 dias	`srv/cron_status.php`	efetivo
Notas sobre comportamento suspeito com endereço IP	90 dias após a resolução	`srv/cron_status.php`	notas não resolvidas sem limite de tempo; medido: 3 notas, todas resolvidas
Endereço IP, país e navegador relativos a um opt-out	12 meses; a exclusão permanece	`cfg/fristen_lib.php`	efetivo
Backups do banco de dados	14 dias	`cfg/backup_lib.php`	efetivo; atualmente, os backups são armazenados no mesmo local que o banco de dados e não são criptografados separadamente; uma cópia criptografada em um segundo local está planejada (R13)

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

O parâmetro são as finalidades indicadas: mostrar aos operadores se seus formulários estão protegidos contra spam e abuso (P1 a P5), verificar se os e-mails de formulário chegam e parecem autênticos (P6) e defender conjuntamente contra spam em muitos sites (P7). Essas finalidades são legítimas. A questão nos termos do Art. 35(7)(b) é mais restrita: este tratamento é necessário com esta profundidade para a finalidade, e a interferência é proporcional ao benefício?

Componente	Necessário para a finalidade?	Proporcional na forma implementada?
Obtenção de algumas páginas públicas, estrutura dos formulários, medidas de proteção detectadas	Sim. Sem elas, não há constatação.	Sim. No máximo oito páginas (além das visualizações da seção 6.1), uma proibição da página inicial no robots.txt é respeitada, sem valores de campos visíveis, endereços de destinatários apenas como domínio.
Captura de tela por formulário	Sim, como evidência no relatório: o operador pode ver de qual formulário se trata.	Em grande parte. Os campos estão vazios porque o rastreador não digita nada. No entanto, a imagem mostra o entorno do elemento do formulário sem encobrir nada (R3).
Captura de tela da página inicial	Não é necessária para a constatação em si. Serve para reconhecer o site verificado no relatório.	Apenas de forma limitada; mais minimização planejada. Páginas iniciais frequentemente mostram pessoas: fotos da equipe, pessoas de contato, depoimentos de clientes com nomes. Veja R3 e a seção 9.3.
Leitura dos valores de campos ocultos (primeiros 24 caracteres, apenas durante a verificação)	Sim: tokens e registros de tempo são detectados a partir deles.	Sim. Apenas o resultado da detecção é armazenado, não o valor, também em áreas protegidas por login (R8).
Página de resposta ao envio de teste (imagem e 300 caracteres de texto)	Sim, como evidência de como o formulário respondeu.	Sim. A resposta diz respeito à nossa mensagem de teste identificada, sem dados pessoais.
Classificação pelo modelo de linguagem	Útil, não necessária: sem ela, mais formulários permanecem “desconhecidos”.	Sim. Local, sem divulgação, sem o direito de enviar.
Plano de ação local a partir de constatações selecionadas e metadados da verificação	Útil para priorizar correções, não necessário para produzir as constatações individuais.	Limitado aos metadados de verificação existentes e a no máximo 18 constatações distintas com falha ou resultado incerto, sem capturas de tela nem valores inseridos em campos no prompt. O plano é consultivo e identificado como gerado por IA; as constatações individuais continuam sendo a referência determinante. URLs e notas ainda podem conter dados pessoais, e o texto gerado segue a retenção da verificação e o acesso por quem possui o link. Esses limites reduzem a exposição, mas não comprovam a exatidão factual (R10).
Envios de teste ativos	Sim. Se uma proteção funciona só fica claro quando ela é testada.	Sim, com limite e identificação. No entanto, o pré-requisito – a comprovação de controle – nunca é renovado (R7).
Busca por arquivos expostos	Sim para o Cliente, cujos dados de formulário podem estar expostos ali.	Sim. Apenas domínios verificados, no máximo 8 KB, conteúdo nunca armazenado.
Verificação de áreas protegidas por login	Sim para formulários na área de membros que, de outra forma, permaneceriam sem verificação.	Em grande parte. Criptografia e exclusão são implementadas com cuidado; no entanto, o login aceita conexões não criptografadas e certificados incorretos (R8).
Cópia de controle de mensagens reais de visitantes	Não para a comprovação de entrega. Ela se baseia apenas na cópia do nosso teste (`cfg/zustellung_lib.php`). As mensagens reais vêm junto porque uma cópia oculta no formulário não distingue entre teste e mensagem real. Elas são úteis para a verificação de autenticidade (SPF, DKIM, DMARC), pois mostram a rota real de envio.	Parcialmente. O conteúdo não é armazenado, mas é lido, e permanece no provedor da caixa de e-mail, cujo contrato ainda está pendente, até a obtenção (R1, R2). Uma concepção menos invasiva é tecnicamente possível: com nosso plugin, a cópia oculta poderia ser limitada a mensagens de teste identificadas (seção 9.3).
Armazenamento do domínio do remetente de mensagens reais	Parcialmente: mostra se o formulário envia com o endereço do visitante como remetente (uma causa frequente de classificação como spam).	Condicionalmente. Para uma pessoa com domínio próprio, o domínio é dado pessoal e vai no alerta ao Cliente e aos seus canais (R1).
Lista compartilhada de domínios de links	Sim. Um link de spam que aparece em muitos sites ao mesmo tempo é um sinal forte que um único site não tem.	Sim, com quantidades mínimas, exceções e quarentena em vez de exclusão. Redes IP não seriam proporcionais sem uma nova avaliação.
Dados brutos do estudo	Até a avaliação, sim.	Sem prazo máximo, não (R4).
Relatório sob um link aleatório	Sim. Transmitir o relatório – por exemplo, ao prestador de serviços que cuida do site – é a finalidade da verificação gratuita.	Sim. Link aleatório com 128 bits, `noindex`, relatório gratuito apenas como recorte (`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`), exclusão após 30 dias.

Licitude. Para P1 a P3 e P7, baseamo-nos no Art. 6(1)(f). A favor na ponderação: os dados são públicos e obtidos da mesma forma que qualquer visitante faz; nada é enviado; os dados pessoais são incidentais e reduzidos; os prazos são curtos; o operador pode excluir novas verificações pelo rastreador por uma proibição da página inicial no robots.txt e qualquer outra verificação pela nossa página de exclusão, imediatamente e sem comprovação; o benefício – um formulário protegido – também se estende ao operador e aos seus visitantes. Contra: o operador nada fica sabendo da verificação, o relatório destina-se a terceiros e, no caso de empresários individuais, avalia uma pessoa. Consideramos a ponderação justificável enquanto as medidas da seção 9.1 permanecerem em vigor; a confirmação jurídica está pendente.

Informação aos titulares de dados (Art. 13 e 14). Informamos os responsáveis pelos sites e as pessoas nas páginas verificadas por meio da página do rastreador, indicada no identificador de cada acesso, da Política de Privacidade e da página de exclusão das verificações. Informar individualmente as pessoas que aparecem incidentalmente em uma captura de tela só seria possível se as identificássemos — o que constituiria uma interferência adicional e mais grave. Nesse aspecto, baseamo-nos no Art. 14(5)(b). Os visitantes cujas mensagens passam pela cópia de controle são informados pelo Cliente; o Acordo de Tratamento de Dados exige isso, e fornecemos um bloco de texto para essa finalidade.

Minimização dos dados (Art. 5(1)(c)). Ela é visível em vários pontos e fundamentada no código: nenhum valor de campo, endereços de destinatários apenas como domínio, identificadores de conta ocultos nos endereços dos scripts, nenhum conteúdo da cópia de controle no banco de dados, nenhuma captura de tela atrás do login, apenas domínios na proteção coletiva. Em dois pontos, é possível e está prevista uma minimização adicional (seção 9.3): na captura de tela da página inicial sem ocultação e no domínio do remetente de mensagens reais.

Limitação da conservação (Art. 5(1)(e)). Desde 27 de setembro de 2026, a rotina noturna cumpre os prazos da Política de Privacidade para os dados dos Clientes e elimina dados remanescentes sem um domínio associado do período anterior a essa data (cfg/fristen_lib.php). Permanecem abertas duas vias sem limite de tempo: verificações internas e estudos não publicados (R4).

Exatidão (Art. 5(1)(d)). Uma constatação pode estar errada: um formulário parece desprotegido porque a proteção só é carregada após uma interação, ou um firewall tratou o rastreador de forma diferente de um visitante. Para o responsável por um site que é divulgado publicamente como “Exposed”, isso afeta sua reputação. Por isso, o relatório identifica o método, apresenta evidências e indica os limites de uma verificação externa.

Resultado quanto à proporcionalidade: A verificação de sites de terceiros e de sites próprios é, na forma implementada, essencialmente proporcional. Em três pontos, há necessidade de melhorias que podem ser realizadas por meios comuns e para as quais estão previstas medidas (seção 9.3): as capturas de tela da página inicial, as verificações internas sem limite de tempo e o login sem criptografia para a verificação atrás do login. A verificação de entrega é proporcional para a cópia de teste e para a verificação de autenticidade; no caso de mensagens reais de visitantes, isso só se aplica enquanto seu conteúdo não for armazenado, a via pelo provedor da caixa de correio estiver assegurada contratualmente e o Cliente informar seus visitantes. Atualmente, falta o segundo desses três pontos.

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

Avalia-se o risco para os titulares de dados, não para formexposed. A probabilidade é classificada como remota, possível, provável ou concretizada; “concretizada” significa que o evento não é uma previsão, mas uma situação medida. A gravidade é classificada como limitada, significativa, grave ou muito grave, conforme o que a pessoa pode perder: a confidencialidade de sua mensagem, o controle sobre uma conta, sua reputação comercial ou a possibilidade de exercer um direito. O nível resulta da combinação de ambas e descreve a situação atual com as medidas da seção 9.1.

Nº	Risco	Operação de tratamento	Probabilidade	Gravidade	Nível
R1	Mensagens reais de visitantes na cópia de controle, incluindo possíveis categorias especiais	P6	Concretizada assim que ativada	Grave	Alto
R2	Via da cópia de controle pelo provedor da caixa de correio sem contrato celebrado e com possível vínculo com país terceiro	P6	Provável enquanto faltar o contrato	Grave	Alto
R3	Capturas de tela de sites de terceiros sem ocultação	P1–P4	Provável	Limitada	Médio
R4	Dados de verificação e capturas de tela sem uma via de exclusão	P3, verificações internas	Concretizada	Significativa	Alto
R5	Verificação e avaliação pública de sites de terceiros sem o conhecimento do responsável; uso indevido como ferramenta de reconhecimento	P1	Possível	Significativa	Médio
R6	Verificação de potenciais clientes como base para abordagens não solicitadas	P2	Provável	Limitada	Médio
R7	A comprovação de controle nunca é renovada	P4, P5	Possível	Significativa	Médio
R8	Credenciais e conteúdo na verificação atrás do login	P5	Possível	Grave	Médio; alto para contas reais
R9	Envios de teste ativos e verificação de arquivos no site do Cliente	P4	Remota	Significativa	Baixo
R10	Classificação por um modelo de linguagem	P1–P4	Remota	Limitada	Baixo
R11	Lista de bloqueio compartilhada a partir de relatos de vários sites	P7	Possível	Limitada	Baixo a médio; alto com redes IP
R12	Relatórios e capturas de tela sob um link público	P1, P2, P4	Possível	Limitada	Baixo
R13	Fragilidades da infraestrutura: backups, acesso ao servidor, servidor de verificação	todas	Possível	Grave	Alto
R14	Direitos dos titulares de dados para pessoas que não nos conhecem	P1–P6	Provável	Limitada	Baixo

R1 – Mensagens reais de visitantes na cópia de controle

Este é o risco mais grave do serviço e decorre do próprio projeto, não de um erro. Uma cópia oculta no formulário não distingue nossa mensagem de teste da mensagem de um visitante. Se um Cliente ativar a verificação de entrega, toda mensagem enviada por esse formulário chegará à nossa caixa de correio de controle (cfg/zustellung_lib.php). A consulta lê os cabeçalhos e os primeiros 8 KB do texto na memória para procurar nosso identificador de teste (cfg/zustellung_lib.php). Em um formulário de contato comum, isso significa nome, endereço de e-mail, telefone e a mensagem completa.

O visitante decide o que escrever, e o campo convida a incluir conteúdo pessoal: um pedido de consulta com descrição de sintomas para um consultório médico, o relato de um litígio para um escritório de advocacia, uma candidatura a emprego, uma pergunta sobre uma criança para uma escola. Nossos documentos jurídicos dizem que as cópias “não devem conter categorias especiais de dados pessoais”. Isso é uma solicitação ao Cliente, não uma medida de proteção: nem ele nem nós sabemos antecipadamente o que um visitante escreverá.

Há duas vias secundárias relacionadas. Primeiro, a verificação de autenticidade armazena o domínio do endereço do remetente associado ao domínio (cfg/zustellung_lib.php). Se o formulário usar o endereço do visitante como remetente, trata-se do domínio do visitante — sem significado individual no caso de um grande provedor de e-mail, mas um dado pessoal para alguém com domínio próprio. Esse domínio também aparece no alerta enviado ao Cliente e aos canais escolhidos por ele (cfg/zustellung_lib.php). Segundo, ela armazena o endereço do servidor de e-mail remetente (cfg/zustellung_lib.php); em geral, é o servidor do site, não o do visitante.

Probabilidade – concretizada assim que ativada. A questão não é se chegam mensagens reais, mas quantas. Na medição no sistema de desenvolvimento, a função não está ativada para nenhum domínio. Gravidade – grave. A confidencialidade de uma mensagem enviada a uma empresa é importante para muitas pessoas, e dados abrangidos pelo Art. 9 são esperados para alguns dos Clientes típicos. A gravidade é atenuada pelo fato de o conteúdo não ir para o banco de dados, permanecer apenas brevemente na caixa de correio e não ser lido por nenhuma pessoa em formexposed. Nível – alto.

R2 – Via da cópia de controle pelo provedor da caixa de correio sem contrato celebrado

Antes de nossa consulta acessar uma cópia de controle, ela fica na caixa de correio em Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. Ela só chega lá se os registros MX do nosso domínio apontarem diretamente para essa caixa; o encaminhamento no registrador de domínio Namecheap, Inc. não é uma etapa das cópias de controle (por encaminhamento, elas não chegam à caixa de correio). Para a etapa restante, os acordos contratuais ainda estão em aberto: o contrato com o provedor da caixa de correio não foi celebrado, seus locais de armazenamento, suboperadores e prazos de backup não foram estabelecidos, e permanece em aberto se uma decisão de adequação ou cláusulas contratuais padrão são necessárias e aplicáveis ao seu local de tratamento. Para nossos próprios e-mails transacionais, isso é uma questão de estruturação contratual. Para as cópias de controle, é mais grave: nesse caso, são dados que recebemos como operador, e cada prestador de serviço ao longo da via é um suboperador pelo qual respondemos nos termos do Art. 28(4).

Além disso, “excluído após a consulta” se aplica apenas à nossa visão da caixa de correio. Não foi verificado se o provedor mantém e-mails excluídos em seus próprios backups ou em uma lixeira, nem por quanto tempo. Se uma consulta for interrompida, os e-mails permanecerão até a próxima execução bem-sucedida (cfg/zustellung_lib.php); se o processo de status falhar, permanecerão por tempo indeterminado. Por fim, a proteção da própria consulta é um dos pontos a verificar no sistema de produção antes do lançamento (seção 9.3).

Probabilidade – provável enquanto faltar o contrato: toda cópia de controle percorre essa via. Gravidade – grave, pelos mesmos motivos de R1. Nível – alto. A lista de configuração da aplicação indica a ausência da caixa de correio como um aviso; não há um bloqueio que impeça a verificação de entrega sem um contrato documentado.

R3 – Capturas de tela de sites de terceiros sem ocultação

O rastreador faz uma captura de tela da área visível da primeira página e uma imagem do elemento de formulário de cada formulário visível (scanner/src/crawl.js). Nada é ocultado nesse processo. Nos fluxos de navegação, isso é diferente: os campos de entrada são mascarados antes da captura de tela (scanner/src/browser.js). Assim, somente as imagens dos fluxos de navegação são “limpas”, não as do rastreador nem a imagem da página de resposta de uma verificação ativa.

Como o rastreador não digita nada, os campos do formulário ficam vazios. No entanto, a página inicial de uma pequena empresa frequentemente mostra seu proprietário, a equipe, depoimentos de clientes com nomes e fotos ou uma janela de chat com a foto de um funcionário. Tudo isso é público; a captura de tela transforma esse conteúdo em uma cópia que fica armazenada conosco, aparece no relatório e pode ser compartilhada pelo link.

Probabilidade – provável. Foram medidas 432 capturas de tela no conjunto de dados do sistema de desenvolvimento. Gravidade – limitada: o conteúdo já é público, e os prazos para verificações sem conta são curtos. Nível – médio, porque as pessoas retratadas não têm conhecimento disso e a imagem da página inicial não é necessária para a constatação.

R4 – Dados de verificação e capturas de tela sem uma via de exclusão

A rotina noturna exclui verificações por duas vias: pela data de expiração de um relatório (cfg/check_lib.php) e pelo prazo para verificações de um domínio do Cliente (cfg/fristen_lib.php, somente para verificações com um domínio). Uma verificação que não tenha relatório nem domínio escapa das duas vias. São as verificações com o nível de confiança “internal”: estudos e verificações que o prestador cria pela linha de comando.

Estudos excluem seus dados brutos na publicação (cfg/studie_lib.php). Se um estudo nunca for publicado — por ter poucos sites com formulário (cfg/studie_lib.php então recusa a publicação) ou por ser deixado de lado —, as verificações, os formulários, as constatações e as capturas de tela permanecem sem limite de tempo.
Verificações internas pela linha de comando não têm nenhuma via de exclusão. Medição em 11 de outubro de 2026: 85 verificações desse tipo em sites de terceiros, com 978 formulários e 369 capturas de tela, a mais antiga de 22 de setembro de 2026, nenhuma com relatório ou domínio.
Notas sobre comportamento suspeito na verificação gratuita contêm o endereço IP e são excluídas 90 dias após sua resolução (srv/cron_status.php). Uma nota que nunca é resolvida permanece. Medição: três notas, todas resolvidas.

Probabilidade – concretizada. As 85 verificações não são um cenário, mas dados existentes. No sistema de desenvolvimento, são verificações de um teste de campo; o mesmo código se aplica ao sistema de produção. Gravidade – significativa: não há prazo de conservação para esses dados. Em relação ao princípio da limitação da conservação (Art. 5(1)(e)), este é um ponto em aberto com uma medida prevista (seção 9.3, prioridade “primeiro”) e afeta justamente pessoas que nada sabem da verificação. As verificações internas são descritas no Registro das Atividades de Tratamento; a Política de Privacidade ainda não as identifica separadamente (seção 9.4). Nível – alto.

R5 – Verificação e avaliação pública de sites de terceiros sem o conhecimento do responsável

Qualquer pessoa pode solicitar a verificação de qualquer site acessível publicamente, sem conta e sem nenhum vínculo com ele. O responsável não é notificado. O resultado é um relatório que classifica o site como “Exposto”, “Parcialmente protegido” ou “Protegido” e que qualquer pessoa com o link pode ver. São concebíveis duas consequências para os titulares de dados. Um empresário individual recebe publicamente — ainda que apenas perante os destinatários do link — uma avaliação que pode decorrer de uma constatação incorreta. E o relatório mostra a um remetente de spam qual formulário pode ser preenchido sem obstáculos.

Uma série de bloqueios se contrapõe a isso (cfg/check_lib.php): no máximo uma verificação por domínio a cada sete dias, com o mesmo relatório depois disso; limites por endereço IP e sessão; um teto diário para todo o serviço; nenhuma verificação de domínios muito novos, típicos de abuso; uma nota e um sinal para comportamento suspeito; robots.txt e exclusão das verificações, conferidos duas vezes (cfg/check_lib.php e no serviço de verificação). O relatório gratuito é um extrato: mostra apenas as constatações básicas, não as evidências de todos os detectores. E não revela nada que um bot não pudesse descobrir sozinho em segundos — um formulário desprotegido é visível externamente.

Probabilidade – possível. Gravidade – significativa para um empresário individual cujo formulário seja visado após um relatório ou cuja avaliação esteja errada. Nível – médio.

R6 – Verificação de potenciais clientes como base para abordagens não solicitadas

Na interface, a verificação de potenciais clientes é descrita como uma “porta de entrada para a primeira conversa”. Cabe à agência decidir como usar a constatação resumida; tecnicamente, ela também pode enviá-la a um responsável por um site que não a solicitou. Não entramos em contato com ninguém (cfg/akquise_lib.php), e os Termos de Serviço obrigam a agência a cumprir as regras de publicidade e prospecção. No entanto, um e-mail não solicitado com a constatação constitui marketing direto mesmo entre empresas, o que exige consentimento prévio na Polônia (Art. 398 da Lei de Comunicações Eletrônicas (Prawo komunikacji elektronicznej, PKE)) e na Alemanha (§ 7(2) da Lei Alemã contra a Concorrência Desleal (Gesetz gegen den unlauteren Wettbewerb, UWG)). A interface não indica isso; os textos da verificação de potenciais clientes falam apenas em “passiva” e “lista de exclusão”.

Probabilidade – provável, porque a função serve à aquisição de clientes e não podemos verificar se o destinatário consentiu. Gravidade – limitada: para o responsável pelo site, trata-se de um e-mail de marketing incômodo com uma avaliação de seu site. Nível – médio. O risco está na conduta da agência; como a função é fornecida por nós, está previsto um aviso na interface (seção 9.3).

R7 – A comprovação de controle nunca é renovada

Os envios de teste ativos, a busca de arquivos expostos e a verificação atrás do login exigem que o Cliente tenha comprovado que tem o direito de controlar o domínio. Essa comprovação é verificada uma vez (cfg/verify_lib.php) e nunca mais. Não há no código uma via pela qual um domínio perca sua comprovação. Se o domínio mudar de proprietário, uma agência encerrar sua prestação de serviços ou o responsável remover o registro DNS, as verificações continuarão — até diariamente, com até cinco envios de teste e, quando armazenado, com o login de uma conta de teste que o novo responsável talvez desconheça. Por outro lado, não é possível transferir a comprovação para outro host por renomeação: o nome de host de um domínio com comprovação de controle não pode ser alterado.

Probabilidade – possível: mudanças de domínio e de prestação de serviços são ocorrências cotidianas para agências. Gravidade – significativa para o novo responsável e seus funcionários, que recebem mensagens de teste identificadas e cujo site é vasculhado em busca de arquivos expostos sem seu consentimento. Nível – médio. As mensagens de teste são autoexplicativas e indicam a página do rastreador e a exclusão das verificações; essa exclusão também impede verificações solicitadas por Clientes.

R8 – Credenciais e conteúdo na verificação atrás do login

A criptografia das credenciais foi cuidadosamente implementada: o servidor web já não consegue lê-las após o armazenamento, o banco de dados e o backup contêm apenas texto cifrado, o registro fica vinculado ao respectivo domínio, as credenciais entram no contêiner apenas pela entrada padrão e depois são apagadas da memória (seção 6.5). Restam duas lacunas; um terceiro ponto diz respeito apenas à leitura, não ao armazenamento.

O login sem criptografia é permitido. A verificação do endereço permite http além de https (cfg/login_lib.php, scanner/src/login.js). Se o Cliente inserir uma página de login com http, o nome de usuário e a senha trafegarão pela internet em texto simples a cada verificação.
Erros de certificado não interrompem o login. Atualmente, o login não é interrompido quando o certificado do site do Cliente é inválido (scanner/src/login.js). Portanto, o certificado não protege integralmente as credenciais no trajeto até o site do Cliente. Está prevista a interrupção em caso de erros de certificado (seção 9.3, prioridade “primeiro”).
Os valores de campos ocultos atrás do login são lidos, não armazenados. O rastreador lê os primeiros 24 caracteres do valor de campos ocultos (scanner/src/crawl.js), e a mesma função de extração é executada atrás do login (scanner/src/login.js). Nesse contexto, campos ocultos frequentemente contêm um número de conta, um identificador de usuário ou o endereço de e-mail da conta conectada; no entanto, somente o nome, o tipo e o rótulo do campo e o resultado da detecção chegam ao mapa de campos e às constatações.

Soma-se a isso o que o código não pode impedir: o Cliente confirma que usa uma conta de teste com o mínimo possível de permissões (cfg/login_lib.php), mas pode inserir uma conta real de administrador. As páginas que o verificador então lê são determinadas pelo Cliente; endereços com palavras de encerramento de sessão e exclusão são bloqueados, mas outras ações que um site desencadeia por uma simples requisição não são.

Probabilidade – possível. Gravidade – grave se uma conta com permissões amplas for afetada; nesse caso, a área de membros com os dados de todos os usuários fica aberta. Nível – médio para uma conta de teste com poucas permissões, alto para uma conta real. Na medição no sistema de desenvolvimento, nenhuma conta de teste está armazenada.

R9 – Envios de teste ativos e verificação de arquivos no site do Cliente

Um envio de teste chega às pessoas que leem os e-mails dos formulários do Cliente — seus funcionários ou um prestador de serviço. Ele não contém dados pessoais: o remetente é dummy@formexposed.com, o texto e o assunto são identificados como teste e indicam o identificador da verificação (scanner/src/active.js). O risco está em uma classificação incorreta: se o verificador confundir um formulário de candidatura, agendamento ou orientação com um formulário de contato, a mensagem de teste entrará em um processo que gera consequências. Contrapõem-se a isso as regras rigorosas para a condição de “apto para envio” (scanner/src/classify.js), o bloqueio de domínios de autoridades públicas, instituições de ensino, clínicas, consultórios médicos, polícia e tribunais (scanner/src/classify.js) e a exclusão do modelo de linguagem dessa decisão (scanner/src/classify.js). Da resposta, são armazenados o status, o endereço de destino, o título, 300 caracteres de texto e uma imagem; eles se referem à nossa mensagem de teste.

A verificação de arquivos lê no máximo 8 KB de caminhos típicos. Se houver de fato um dump de banco de dados exposto ali, esses 8 KB poderão conter entradas de formulários feitas por visitantes. Elas são apenas verificadas quanto a uma assinatura e descartadas (cfg/dateien_lib.php); são armazenados o caminho, o tipo e a gravidade.

Probabilidade – remota. Gravidade – significativa. Nível – baixo. Na medição no sistema de desenvolvimento, há uma verificação ativa no conjunto de dados, sem nenhum envio aceito.

R10 – Classificação por um modelo de linguagem

Para formulários que as regras não reconhecem, o modelo de linguagem recebe o título da página, o endereço, os textos dos botões, as descrições dos campos e até 400 caracteres do texto do formulário (scanner/src/classify.js). Isso pode incluir um nome, por exemplo, “Sua pessoa de contato: …”. Ele é executado em nosso próprio servidor; no código, nada é enviado a terceiros. Não foi verificado se o software do modelo registra as requisições em logs. Seu resultado determina apenas o tipo de formulário exibido e não pode tornar um formulário apto para envio; uma classificação incorreta leva a uma constatação pior, não a uma ação.

Probabilidade – remota. Gravidade – limitada. Nível – baixo.

R10 – Etapa adicional de plano de ação

Para relatórios pagos elegíveis, o mesmo modelo local também gera sugestões de medidas a partir de constatações selecionadas e metadados da verificação. Diferentemente da classificação, a saída é um resumo em linguagem natural mantido junto à verificação. Nomes de host, endereços de páginas e notas podem conter dados pessoais que o modelo pode repetir. Uma recomendação incorreta pode levar o leitor a enfraquecer a proteção ou fazer uma alteração desnecessária; compartilhar o link de um relatório pode revelar dados pessoais repetidos a outro destinatário. O código não executa automaticamente a recomendação, não altera a pontuação nem a conclusão e não verifica a exatidão factual do texto. Ele limita o tamanho da entrada e da saída, identifica o resumo como gerado por IA e informa que as constatações individuais são a referência válida. Essas são medidas de controle, não uma prova de que as recomendações estejam corretas ou de que o relatório seja anônimo. A avaliação anterior de probabilidade e gravidade para a classificação não avalia, por si só, essa etapa adicional de geração; seu risco residual deve ser avaliado com os dados e o uso reais da verificação subjacente.

R11 – Lista de bloqueio compartilhada a partir de relatos de vários sites

Um domínio na lista faz com que mensagens com links para ele sejam colocadas em quarentena em todos os sites conectados. Se o domínio pertencer a uma pessoa — um prestador de serviços, um fotógrafo, um blog —, suas mensagens com um link para seu próprio site chegarão atrasadas aos destinatários. Um domínio desse tipo pode entrar na lista porque remetentes de spam o usam indevidamente ou porque alguém envia deliberadamente mensagens que falham nas verificações, contendo esse domínio, a vários sites.

Contrapõem-se a isso (cfg/swarm_lib.php): um mínimo de três sites diferentes e cinco ocorrências em sete dias; exceções fixas para grandes serviços; nunca os domínios dos nossos Clientes; remoção manual por uma ferramenta no servidor; quarentena em vez de exclusão; a lista é reconstruída diariamente, e o que deixa de ser relatado sai dela. As pessoas afetadas não podem ver a lista e não têm uma via própria para exigir a remoção, exceto por nosso intermédio.

Probabilidade – possível. Gravidade – limitada, porque nada se perde e o destinatário pode liberar a mensagem. Nível – baixo a médio. Com redes IP ativadas, redes de provedores inteiros seriam afetadas, endereços IP são dados pessoais e a gravidade subiria para significativa: alto.

R12 – Relatórios e capturas de tela sob um link público

Relatórios da verificação gratuita, da verificação de potenciais clientes e das verificações de domínios dos Clientes podem ser acessados sem login por um link aleatório. O link contém 128 bits de aleatoriedade e não pode ser adivinhado (cfg/check_lib.php). As páginas contêm noindex, a aplicação envia uma política de referenciador que transmite apenas a origem (www/.htaccess), e as capturas de tela só são disponibilizadas junto ao relatório ao qual pertencem; outro número de imagem retorna “não encontrado” (www/shot.php). O risco não é criptográfico, mas humano: um link é encaminhado, copiado para um chamado, compartilhado em um chat. Quem o abre é registrado apenas no log de acesso à página, como em qualquer visualização de página (60 dias), no qual o próprio link aparece apenas de forma mascarada; não há uma lista de leitores por relatório.

Probabilidade – possível. Gravidade – limitada, porque o relatório mostra apenas informações públicas e expira após 30 ou 90 dias, respectivamente; relatórios de domínios dos Clientes permanecem acessíveis enquanto a verificação existir (13 meses, a última por mais tempo). Nível – baixo.

R13 – Fragilidades da infraestrutura

Os pontos a seguir constam como pendentes em nosso conjunto interno de documentos de revisão e não são minimizados aqui. Nós os descrevemos com a precisão necessária para a avaliação dos próprios Clientes, mas sem detalhá-los a ponto de indicar o caminho a um invasor; forneceremos os detalhes a uma autoridade de controle mediante solicitação.

Backups do banco de dados são atualmente armazenados no mesmo local que o banco e não são criptografados separadamente; está prevista uma cópia criptografada em um segundo local (cfg/backup_lib.php). Até lá, eles não protegem contra a perda do local, e quem obtiver o banco de dados também obterá os backups. As credenciais da verificação atrás do login estão contidas neles apenas como texto cifrado.
Sem criptografia do banco de dados em repouso. As exceções são os campos criptografados individualmente (credenciais das contas de teste, segredo de autenticação de dois fatores).
As conexões dentro de nossa rede interna não são criptografadas em todo o percurso.
Administração dos servidores. A segurança do acesso administrativo aos nossos servidores ainda não atende ao padrão que pretendemos para a operação; o reforço da segurança da administração dos servidores continua.
Ambiente de verificação. O servidor de verificação abre sites de terceiros em um navegador. Os contêineres de verificação são isolados — rede própria, sem privilégios especiais, somente leitura, com limites (scanner/src/worker.js). A separação entre o ambiente de verificação e as demais partes do serviço está sendo reforçada (seção 9.3).

Probabilidade – possível. Gravidade – grave, porque, em uma emergência, tudo seria afetado ao mesmo tempo. Nível – alto. Os pontos individuais podem ser corrigidos por meios comuns (seção 9.3).

R14 – Direitos dos titulares de dados para pessoas que não nos conhecem

Quem aparece incidentalmente em uma captura de tela ou cuja mensagem passou por uma cópia de controle geralmente não sabe que existimos. Mesmo que saiba, não tem uma chave para acessar “seus” dados: não os armazenamos por pessoa, mas por domínio e verificação. Só podemos responder a uma solicitação de acesso nos termos do Art. 15 se a pessoa indicar o domínio; então podemos examinar as verificações e imagens existentes. No caso de mensagens reais de visitantes, não há nada a informar, porque não as armazenamos — exceto pelo domínio do remetente de R1. A exclusão das verificações funciona apenas para os responsáveis por um domínio, não para as pessoas retratadas; para elas, resta o contato por contact@lukaswojcik.com.

Probabilidade – provável como situação estrutural. Gravidade – limitada, porque os dados têm vida curta e não são organizados por pessoa. Nível – baixo.

9. (d) Medidas para enfrentar os riscos

Cada medida tem um status, e os status não são decorativos. Implementada atualmente – verificada significa: lida no código do sistema de desenvolvimento e, quando possível, medida no banco de dados. Parcial significa: o mecanismo existe, mas ainda não cumpre integralmente sua finalidade. Prevista significa: proposta por esta avaliação e não implementada; cabe ao proprietário decidir se e quando será realizada. Ainda a definir são procedimentos e decisões que nenhum código substitui. Uma AIPD que apresenta medidas previstas como implementadas perde seu valor justamente na situação em que é necessária.

9.1 Implementadas atualmente – verificadas

Medida	Riscos ou aspectos tratados	Referência no código-fonte
robots.txt é lido pelo rastreador antes de cada verificação; uma exclusão que abranja a página inicial, um robots.txt inacessível ou um erro de servidor encerram a verificação (subcaminhos não são observados individualmente; a verificação de disponibilidade, a consulta de comprovação, a ferramenta de cabeçalhos e a busca de arquivos não o leem)	R5, licitude	`scanner/src/net.js`
Exclusão das verificações sem comprovação, com efeito imediato, para o domínio e sua variante www, para verificações anônimas, potenciais clientes, estudos e verificações de Clientes (o monitoramento em andamento termina na próxima verificação agendada); conferida duas vezes (aplicação e serviço de verificação); retirada somente por nós, mediante solicitação com comprovação	R5, R7, Art. 21	`cfg/check_lib.php`; `cfg/akquise_lib.php`; `cfg/studie_lib.php`; `scanner/src/worker.js`
Verificação gratuita: parada de emergência, reCAPTCHA, uma verificação por domínio e por semana, limites por endereço IP e sessão, teto diário, nenhum domínio novo, apenas endereços públicos, nota e sinal sem conteúdo em caso de anomalias	R5	`cfg/check_lib.php`
Para os limites, a sessão é armazenada apenas como valor de hash, nunca o identificador da sessão	Minimização	`cfg/check_lib.php`
Nenhum valor de campo (os trechos iniciais de campos ocultos e atributos de dados são apenas lidos durante a verificação, seção 6.2); endereços de destinatários apenas como domínio; identificadores de conta ocultos nos endereços dos scripts	Minimização	`scanner/src/crawl.js`
O relatório gratuito é um extrato: apenas constatações básicas, sem evidências de todos os detectores	R5	`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`
Relatórios sob um link aleatório de 128 bits, `noindex`, imagens apenas para o respectivo relatório, fora do diretório web público; o link aparece no log de acesso à página apenas de forma mascarada	R12	`cfg/check_lib.php`; `www/report.php`; `www/shot.php`
Exclusão: relatórios anônimos após 30 dias, potenciais clientes após 90 dias, verificações de Clientes após 13 meses (a última por domínio é mantida enquanto o domínio existir), dados de um domínio excluído imediatamente (exceções na seção 6.11), imagens sempre junto com os respectivos dados	Limitação da conservação	`cfg/check_lib.php`; `cfg/fristen_lib.php`
Estudo: publicação apenas como total agregado, segmentos somente a partir de 20 sites com formulário, dados brutos excluídos na publicação	R4 parcialmente, P3	`cfg/studie_lib.php`
Contêineres de verificação: rede isolada própria, sem privilégios especiais, somente leitura, limites de memória e processos, limite de tempo; filtro contra destinos privados em cada requisição, service workers bloqueados e conexões WebSocket fechadas para que nada contorne o filtro; requisições do servidor web apenas em portas web e somente para o endereço público exato verificado previamente	R13	`scanner/src/worker.js`; `scanner/src/net.js`
Verificação ativa para Clientes somente em domínio verificado (internamente também em nossos próprios domínios de teste e demonstração) e com a parada de emergência ativada, conferida duas vezes; no máximo cinco envios; apenas formulários de contato claramente reconhecidos sem dados pessoais obrigatórios; nenhum domínio de autoridades públicas, instituições de ensino, clínicas, consultórios médicos, polícia ou tribunais; o modelo de linguagem não pode autorizar nada; mensagem de teste sem dados pessoais, identificada, com referência à página do rastreador e à exclusão das verificações	R9	`scanner/src/worker.js`; `scanner/src/classify.js`; `scanner/src/active.js`
Fluxos de navegação: apenas GET e HEAD, endereços perigosos bloqueados, valores fictícios não saem do navegador, imagens com campos de entrada ocultados	R3 (para essas imagens), R9	`scanner/src/browser.js`
Verificação de arquivos: apenas domínios verificados, uma consulta por caminho, no máximo 8 KB, conteúdo nunca armazenado	R9	`cfg/dateien_lib.php`
Segunda sonda: desativada por padrão; receberia apenas uma lista fixa de itens inofensivos, assinada	Destinatários	`cfg/formular_probe_lib.php`
Verificação atrás do login: somente domínio verificado, plano pago, proprietário ou administrador, confirmação de “conta de teste”; criptografia com a chave pública do servidor de verificação, vinculada ao domínio; credenciais nunca exibidas, registradas em logs nem fornecidas pela API; transferência apenas pela entrada padrão; campo no trabalho apagado imediatamente, resíduos após uma hora; sem capturas de tela, sem envios, sem endereços de encerramento de sessão ou exclusão, interrupção em caso de CAPTCHA; exclusão final com sobrescrita	R8	`cfg/login_lib.php`; `scanner/src/login.js`; `scanner/src/geheim.js`; `scanner/src/worker.js`
Verificação de entrega: desativada por padrão; a consulta lê apenas cabeçalhos e 8 KB, sem marca de leitura; conteúdo e endereço do visitante nunca no banco de dados; todo e-mail consultado é excluído, inclusive os que não podem ser associados; associações excluídas após 180 dias; comprovação somente pela cópia exata desse teste	R1, R2	`cfg/zustellung_lib.php`
Proteção coletiva: apenas domínios, redes IP desativadas; quantidades mínimas; exceções para grandes serviços e domínios dos Clientes; quarentena em vez de exclusão; lista reconstruída diariamente; relatos excluídos após 30 dias	R11	`cfg/swarm_lib.php`
Modelo de linguagem em nosso próprio servidor, sem permissão para enviar	R10	`scanner/src/classify.js`
Plano de ação: geração local a partir de constatações selecionadas, sem capturas de tela nem valores digitados nos campos no prompt; quantidade de constatações e tamanho das notas limitados; texto simples limpo com tamanho limitado; aviso de IA visível, constatações individuais como referência válida; nenhuma alteração automática no site nem decisão sobre pontuação ou conclusão	R10 parcialmente; orientações incorretas e dados pessoais incidentais continuam possíveis	`cfg/plan_lib.php`; `www/report.php`
Sinais via Telegram contêm apenas uma frase fixa sem variáveis	Destinatários	`cfg/check_lib.php`
Teste semanal de restauração do backup, com alerta em caso de falha	Disponibilidade	`cfg/backup_lib.php`; `srv/cron_status.php`

9.2 Parciais – existentes, mas ainda sem cumprir sua finalidade

Medida	Por que ainda não é plenamente eficaz
Capturas de tela “limpas”	Somente as imagens dos fluxos de navegação têm conteúdo ocultado. As imagens do rastreador — página inicial e elementos de formulário — e a imagem da página de resposta de uma verificação ativa não têm (R3).
Prazos para dados de verificação	Eficazes para verificações anônimas, de potenciais clientes e de Clientes; não para verificações internas e estudos não publicados; notas de anomalia não resolvidas sem limite de tempo (R4).
Exclusão das cópias de controle	Eficaz em nossa visão da caixa de correio. Se a execução for interrompida, os e-mails permanecem; não foi verificado o que o provedor da caixa de correio mantém em seus próprios backups (R2).
Proteção das credenciais na verificação atrás do login	Forte em repouso e no serviço de verificação; não no trajeto até o site: `http` é permitido, erros de certificado são ignorados (R8).
Comprovação de controle	É verificada uma vez e depois vale para sempre; no entanto, o nome de host de um domínio com comprovação de controle não pode ser alterado, de modo que a comprovação não passe para outro host (R7).
Informação aos titulares de dados	Existente para os responsáveis pelos sites por meio da página do rastreador, do identificador, da Política de Privacidade e da exclusão das verificações; para visitantes na verificação de entrega, depende de o Cliente adotar o bloco de texto; a aplicação não verifica isso.
Solicitação aos Clientes para não incluir categorias especiais na cópia de controle	Declarada nos documentos jurídicos, mas sem suporte técnico: durante a configuração, a aplicação não pergunta sobre o tipo de site nem alerta sobre domínios que pareçam ser de saúde, direito ou educação (R1).

9.3 Previstas – não implementadas

Medida	Riscos tratados	Prioridade
Via de exclusão para verificações internas: excluir verificações sem domínio e sem relatório após um prazo fixo (proposta: 30 dias); excluir os dados brutos de um estudo, no máximo, após um prazo fixo contado de sua conclusão, mesmo sem publicação (proposta: 90 dias); excluir uma vez as 85 verificações existentes com 369 imagens	R4	Primeiro
Habilitar a verificação de entrega somente após a celebração do contrato com o provedor da caixa de correio, a documentação dos locais de armazenamento, suboperadores e prazos de backup, o esclarecimento do mecanismo de transferência para o provedor da caixa de correio e o apontamento direto dos registros MX do nosso domínio para a caixa de correio; até lá, manter a função bloqueada no sistema de produção	R2	Primeiro
Verificar a segurança da consulta à caixa de correio no sistema de produção e documentá-la antes de habilitar a verificação de entrega	R2	Primeiro
Verificação atrás do login somente por `https` e com certificado válido; rejeitar endereços `http`; tratar erros de certificado no login como motivo para interrupção	R8	Primeiro
Não armazenar valores de campos ocultos atrás do login (apenas nome, tipo e tamanho) — já implementado dessa forma, nenhuma etapa adicional	R8	Concluída
Limitar a cópia de controle a mensagens de teste onde o plugin ou a extensão estiver em uso: cópia oculta somente para envios com nosso identificador de teste	R1	Alta
Não armazenar o domínio do remetente de mensagens reais nem incluí-lo em alertas se ele não for o domínio do site nem o de um serviço de envio conhecido; no alerta, usar “domínio externo do remetente”	R1	Alta
Aviso ao configurar a verificação de entrega para domínios que pareçam ser de saúde, direito, assistência social ou educação, com referência à AIPD do próprio Cliente	R1	Alta
Renovar regularmente a comprovação de controle (proposta: antes de cada verificação ativa, conferir se o registro DNS, a meta tag, o arquivo ou a conexão do plugin ainda existem; caso contrário, continuar de forma passiva e notificar o Cliente)	R7	Alta
Deixar de fotografar a página inicial ou fazê-lo apenas com imagens e rostos ocultados; limitar as imagens de formulários ao elemento de formulário (como atualmente) e mascarar campos de entrada como nos fluxos de navegação	R3	Alta
Aviso na interface da verificação de potenciais clientes: enviar a constatação resumida sem solicitação por e-mail ou telefone constitui marketing direto mesmo entre empresas e exige consentimento prévio (Art. 398 da Lei Polonesa de Comunicações Eletrônicas; na Alemanha, § 7(2) UWG, embora o consentimento presumido seja suficiente para ligações a empresas)	R6	Alta
Infraestrutura: concluir o reforço da segurança da administração dos servidores; cópia criptografada do backup em um segundo local; criptografar as conexões em toda a rede interna; reforçar ainda mais a separação entre o servidor de verificação e a aplicação	R13	Alta
Prazo para notas de anomalia não resolvidas (proposta: resolução em 30 dias; caso contrário, exclusão do endereço IP)	R4	Média
Uma página ou formulário pelo qual alguém possa solicitar a remoção de um domínio da proteção coletiva	R11, R14	Média
Antes de ativar redes IP na proteção coletiva: uma nova versão desta avaliação	R11	Condição
Registrar se o software do modelo de linguagem armazena requisições e, em caso afirmativo, desativar esses logs	R10	Baixa

9.4 Procedimentos e decisões ainda a definir

Além de salvaguardas técnicas, o Art. 35(7)(d) também exige procedimentos. Estes ainda estão pendentes:

Violação de dados pessoais. Detecção: o proprietário, o alerta de erro da aplicação, relatos por nosso canal de comunicação de vulnerabilidades ou contact@lukaswojcik.com. Decisão sobre notificação à UODO em 72 horas (Art. 33(1)): o proprietário. Informação aos Clientes afetados como controladores: sem demora injustificada, se possível em 48 horas, conforme prometido no Acordo de Tratamento de Dados. A definir: uma descrição escrita do procedimento e um primeiro exercício; para a verificação de entrega, também como determinar quais Clientes são afetados por uma violação no provedor da caixa de correio.
Setores. A definir: se a verificação de entrega será oferecida, oferecida com um aviso ou excluída para sites de saúde, direito, assistência social e educação.
Verificações internas. A definir: para que o prestador usa verificações internas pela linha de comando, quem pode criá-las e por quanto tempo seus resultados permanecem; e se, além do Registro das Atividades de Tratamento, elas precisam ser identificadas na Política de Privacidade.
Estudos. A definir: quem compila as listas, de quais fontes, com qual tamanho máximo, e uma conferência antes de cada estudo para verificar se ele cumpre as premissas desta avaliação.
Opiniões dos titulares de dados (Art. 35(9)). Elas não foram solicitadas para esta versão. O Art. 35(9) exige que sejam solicitadas apenas “quando adequado”; em nossa avaliação, isso atualmente não se aplica aqui. Os responsáveis pelos sites verificados e os visitantes dos sites dos Clientes não têm um canal próprio conosco; abordá-los especificamente constituiria, por si só, um novo tratamento de seus dados, e o serviço ainda não foi lançado, portanto ainda não existe um grupo de titulares de dados efetivos. Seus interesses são considerados indiretamente: por meio de robots.txt e da exclusão das verificações, dos prazos curtos e do fato de o conteúdo das cópias de controle não ser armazenado. Em cada revisão nos termos da seção 12, reconsideramos se é adequado solicitar suas opiniões, por exemplo, por comentários na página do rastreador ou de Clientes da verificação de entrega.

10. Risco residual e consulta prévia nos termos do Art. 36

O Art. 36(1) exige consulta prévia à autoridade de controle quando a AIPD indicar que o tratamento resultaria em alto risco na ausência de medidas tomadas pelo controlador para atenuá-lo. Portanto, a questão não é se foram identificados riscos altos — foram quatro —, mas se um risco alto permanece depois que as medidas estão em vigor.

Para as operações de tratamento em que formexposed é o controlador (P1 a P4, P7), os riscos altos R4 e R13 podem ser corrigidos por meios comuns: uma via de exclusão e a limpeza dos dados existentes, um backup criptografado em outro local e o reforço da segurança de dois servidores. Com as medidas de 9.3, eles caem para baixo a médio. R3, R5, R6 e R7 estão em nível médio e caem para baixo com as medidas propostas. A proteção coletiva sem redes IP permanece em nível baixo a médio. A consulta prévia não é indicada para essa parte se as medidas marcadas como “primeiro” e “alta” forem implementadas antes do lançamento. Se alguma dessas medidas não tiver sido implementada antes do lançamento, permanecerá um risco alto para a operação de tratamento em questão. Essa operação de tratamento só será então iniciada após a implementação da medida, ou a UODO será previamente consultada nos termos do Art. 36(1).

Para a verificação de entrega (P6), a situação é diferente, por um motivo que nenhuma medida elimina completamente: cabe ao visitante decidir o que escrever. Com contrato celebrado, consulta protegida, limitação a mensagens de teste quando possível e dispensa do domínio do remetente, R2 cai para baixo e R1 para médio. Para Clientes cujos visitantes normalmente fornecem dados abrangidos pelo Art. 9, R1 pode, mesmo assim, permanecer alto. A obrigação de consulta cabe então ao Cliente como controlador, não a formexposed. Nossa recomendação a esses Clientes é não configurar a cópia de controle para o formulário de contato geral, mas apenas para formulários sem conteúdo sensível, ou dispensar a verificação de entrega.

Risco residual, declarado com honestidade. Atualmente, com as medidas de 9.1, quatro riscos estão em nível alto: R1 e R2 (verificação de entrega), R4 (dados de verificação sem uma via de exclusão) e R13 (infraestrutura). Com as medidas de 9.3, R2, R4 e R13 caem para baixo a médio. R1 permanece em nível médio e depende permanentemente das decisões dos Clientes. Nenhum dos outros riscos fica acima de médio após as medidas.

O Art. 36 não é uma penalidade, e consultar não é uma admissão de culpa. É a via que o Regulamento prevê para a situação em que um procedimento útil apresenta um risco que o controlador não domina integralmente. Um Cliente que deseje usar a verificação de entrega para mensagens com dados de saúde encontrará aqui os fatos para essa decisão.

11. O que os Clientes precisam para sua própria AIPD (Art. 28(3)(f))

Para a verificação de entrega e a verificação atrás do login, o Cliente é o controlador. Esta página fornece a ele a descrição (seções 6.5 e 6.6), os riscos de nossa perspectiva (R1, R2, R8) e o status das medidas (seção 9). Somente o Cliente pode responder às seguintes perguntas:

O que meus visitantes escrevem? É de se esperar que cheguem pelo formulário dados sobre saúde, religião, origem, filiação sindical, orientação sexual, infrações penais ou crianças? Nesse caso, uma AIPD para a cópia de controle é, em regra, necessária, e a cópia de controle para esse formulário deve ser reconsiderada.
Preciso da cópia de controle para todas as mensagens? Para comprovar que nossa mensagem de teste chega, basta a cópia dessa mensagem. Quando o formulário permitir, configure a cópia oculta apenas para mensagens de teste.
Como informo meus visitantes? O Acordo de Tratamento de Dados exige isso; o Texto de Política de Privacidade para Seu Site descreve a via da cópia e nosso papel.
Qual base legal tenho? Nosso texto sugerido indica o Art. 6(1)(f) (recebimento confiável de solicitações). Para dados abrangidos pelo Art. 9, essa base, sozinha, não é suficiente.
Quais canais de alerta escolho? Alertas da verificação de autenticidade podem indicar o domínio do remetente. Quem envia alertas a serviços de chat fora da UE transfere esse domínio para lá.
Para a verificação atrás do login: A conta de teste é realmente uma conta de teste com as permissões mínimas necessárias? A página de login só pode ser acessada por https? A conta de teste vê dados de outros usuários? Se sim: em quais das páginas especificadas?
Quando excluo? A verificação de entrega e a conta de teste podem ser desativadas e excluídas a qualquer momento; a conta de teste é então sobrescrita permanentemente.

Outros documentos para a avaliação do Cliente: o Acordo de Tratamento de Dados, as medidas técnicas e organizacionais, a lista de suboperadores e o Registro das Atividades de Tratamento. Respondemos a perguntas sobre fatos específicos em contact@lukaswojcik.com.

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

O Art. 35(11) exige uma revisão para avaliar se o tratamento é realizado de acordo com a AIPD, pelo menos quando houver uma alteração no risco. Revisamos esta avaliação pelo menos anualmente e também antes de cada um dos eventos a seguir; cada um desencadeia uma nova medição, não apenas uma leitura:

início da operação em produção, com números do sistema de produção em vez do sistema de desenvolvimento;
primeira ativação da verificação de entrega no sistema de produção e celebração do contrato com o provedor da caixa de correio;
ativação de redes IP na proteção coletiva;
o primeiro estudo e todo estudo com uma lista maior que a anterior;
ativação da segunda sonda ou de um novo destinatário na via de verificação;
qualquer novo uso do modelo de linguagem que vá além dos usos abrangidos por esta avaliação; o plano de ação priorizado em relatórios pagos é um uso adicional e exige a revisão da avaliação;
qualquer alteração nas capturas de tela, nos prazos ou nas condições prévias para verificações ativas.

Item	Registro
Controlador	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polônia · NIP 7252266190 · contact@lukaswojcik.com
Autoridade de controle competente	Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa, Polônia
Encarregado da proteção de dados	Não designado; avaliação nos termos do Art. 37 na seção 4
Base dos fatos	Código-fonte da aplicação e do serviço de verificação, esquema do banco de dados, contagens de registros e configurações do sistema de desenvolvimento, medidos em 11 de outubro de 2026, somente leitura
Documentos relacionados	Política de Privacidade, Acordo de Tratamento de Dados, Medidas Técnicas e Organizacionais, Suboperadores, Registro das Atividades de Tratamento, Regulamento de IA da UE, Uso Aceitável e Abuso, FormExposedBot, Exclusão das verificações
Versão	1.1 de 23 de outubro de 2026; adendo factual sobre a etapa local de plano de ação à primeira versão de 11 de outubro de 2026
Revisões nos termos do Art. 35(11)	23 de outubro de 2026: revisão do código-fonte da etapa local de plano de ação adicionada. Entradas, armazenamento, papéis, saída consultiva e salvaguardas implementadas foram acrescentados às seções correspondentes; não se afirma que tenha sido concluída uma medição em produção nem uma nova classificação do risco residual. As medições anteriores de 11 de outubro de 2026 e o status de aprovação abaixo permanecem inalterados. Outras revisões serão registradas aqui com data, motivo e resultado.
Aprovação	Ainda não aprovado. Aprovação pelo proprietário após revisão jurídica e após uma decisão sobre as medidas da seção 9.3 e as questões da seção 9.4. Até o momento, não foi solicitada consultoria externa em proteção de dados.

Uma observação final pertence ao documento, não a uma carta de apresentação. As partes de formexposed que mais adentram os domínios de outras pessoas — os envios de teste e o login com credenciais alheias — foram implementadas com o maior cuidado: duas barreiras, limites rígidos, criptografia que impede até nosso próprio acesso. Os riscos desta avaliação estão principalmente em outros lugares: no que vem incidentalmente — mensagens reais em uma cópia oculta, pessoas em uma captura de tela, verificações que ninguém mais exclui. Esse é um ponto de partida favorável, porque o incidental pode ser interrompido sem alterar o serviço.

Como podemos ajudar?