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

Este documento é publicado em várias línguas. Em caso de divergência entre as versões linguísticas, prevalece a versão polaca.

Versão 1.0 · Última atualização: 16 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. Começa por responder à questão prévia de saber se uma AIPD é sequer necessária – para cada operação de tratamento separadamente, não para o serviço no seu conjunto. Quando a resposta é afirmativa, realiza a avaliação nos termos do Art. 35(7)(a) a (d): uma descrição sistemática, a necessidade e a proporcionalidade, os riscos para os titulares dos dados e as medidas para lhes fazer face. Seguem-se o risco residual, a questão da consulta prévia nos termos do Art. 36 e as regras de revisão.

O Art. 35 não exige que uma AIPD seja publicada. Publicamo-la por duas razões. Em primeiro lugar, os Clientes que utilizam a verificação de entrega ou a análise atrás do início de sessão precisam, para a sua própria avaliação, de factos que só nós conhecemos; enquanto subcontratante, devemos-lhes estes factos em qualquer caso (Art. 28(3)(f) do RGPD). Em segundo lugar, o nosso crawler verifica sítios web cujos operadores não nos conhecem. Estes devem poder ler que riscos vemos para eles e para as pessoas presentes nas suas páginas, e o que fazemos a esse respeito.

Natureza jurídica. Esta AIPD é documentação do responsável pelo tratamento nos termos do Art. 35 do RGPD, que publicamos voluntariamente. Não faz parte de nenhum contrato e não constitui qualquer declaração, garantia ou acordo de qualidade perante Clientes ou terceiros. Os serviços e as garantias que devemos aos Clientes regem-se pelos Termos de Serviço, pelo Acordo de Tratamento de Dados e pelos respetivos anexos; no que respeita a estas obrigações, estes prevalecem sobre esta página. A página descreve a situação à data desta versão. As classificações de risco e as avaliações são a nossa própria opinião e não antecipam qualquer apreciação jurídica por parte de uma autoridade de controlo ou de um tribunal; as medidas descritas como “previstas” são intenções sem data vinculativa. Para os Clientes, a página é uma base para a sua própria avaliação, não aconselhamento jurídico.

Esta é a primeira versão da avaliação de limiar. Examina, operação de tratamento a operação de tratamento, se é necessária uma AIPD, e regista o resultado na secção 3.5.

Cada afirmação de facto está sujeita ao mesmo princípio que nos nossos outros documentos jurídicos: medido, não pretendido. O que está comprovado no código ou na base de dados é aqui indicado com a respetiva referência de origem. O que não pôde ser comprovado é assinalado como “não verificado”. O que está apenas previsto é designado “previsto”. Indicamos abertamente os pontos em aberto, juntamente com a medida prevista; uma AIPD que enumere apenas pontos fortes não ajuda as pessoas a quem diz respeito.

Termos: um operador é quem gere um sítio web verificado. Um Cliente tem uma conta em formexposed. Um visitante é quem utiliza o sítio web de um Cliente, por exemplo o seu formulário de contacto. Uma referência de origem designa um ficheiro, uma função ou uma definição no código-fonte, medido face ao estado do sistema de desenvolvimento em 11 de outubro de 2026.

Traçamos deliberadamente um limite à transparência: os pontos em aberto na proteção dos nossos próprios servidores só são descritos em termos gerais (R13). Indicamos o risco e o seu nível, mas não o caminho até uma vulnerabilidade concreta; forneceremos os pormenores a uma autoridade de controlo mediante pedido.

2. Funções: quem tem a obrigação, e relativamente a quê

O Art. 35 impõe a obrigação ao responsável pelo tratamento. formexposed é responsável pelo tratamento em algumas operações de tratamento, subcontratante dos seus Clientes noutras, e nenhuma das duas coisas relativamente aos dados que o nosso plugin para WordPress e a nossa extensão para TYPO3 guardam no sítio web de um Cliente. A resposta a quase todas as questões deste documento depende da função relativamente à qual a questão é colocada. A repartição segue a Política de Privacidade e o Acordo de Tratamento de Dados.

Operação de tratamento	Função de formexposed	Quem tem a obrigação nos termos do Art. 35
Verificação de sítios web de terceiros sem instruções do respetivo operador: verificação gratuita, verificação de potenciais clientes para agências, estudo	Responsável pelo tratamento	formexposed
Verificação de domínios na conta do Cliente: monitorização, submissões de teste ativas, percursos de navegador, ficheiros expostos, pulso do formulário	Responsável pelo tratamento quanto aos dados de conta e de verificação do Cliente; subcontratante quanto aos dados pessoais de terceiros visíveis no sítio web verificado do Cliente; enquanto um domínio não estiver verificado, responsável pelo tratamento tal como na verificação gratuita	formexposed quanto à sua própria parte; o Cliente quanto aos dados de terceiros no seu sítio web
Análise atrás do início de sessão com uma conta de teste	Subcontratante: as credenciais e o conteúdo atrás do início de sessão pertencem ao sítio web do Cliente	O Cliente; formexposed presta assistência
Verificação de entrega com cópia de controlo	Subcontratante	O Cliente; formexposed presta assistência
Proteção em enxame: lista partilhada de domínios de ligações provenientes de spam bloqueado	Responsável pelo tratamento: combinamos as comunicações de muitos sítios web, compilamos a lista e distribuímo-la	formexposed
Contas de Clientes, início de sessão, registos, suporte, envio de e-mails, pagamentos, registos de prova	Responsável pelo tratamento	formexposed
Portal de clientes e relatório mensal para os subscritores de uma agência	Subcontratante	A agência
Dados que o plugin e a extensão guardam no sítio web do Cliente (quarentena, rede de segurança, pedidos guardados)	Nenhuma: os dados nunca saem do sítio web	O operador do sítio web

Daqui resulta uma distinção que indicamos expressamente, porque é muitas vezes mal entendida em ambos os sentidos. Quando formexposed é o responsável pelo tratamento, realizamos nós próprios a avaliação e assumimos o seu resultado. Quando somos subcontratantes, 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 controlo nos termos do Art. 36 em seu nome. O que podemos e devemos fazer nesse caso é fornecer-lhe tudo aquilo de que necessita: a descrição nos termos da alínea (a), os factos medidos sobre os riscos nos termos da alínea (c) e uma lista honesta do estado das medidas nos termos da alínea (d). Para a verificação de entrega e a análise atrás do início de sessão, esta página é exatamente isso.

Um Cliente que adote sem alterações as secções relativas à verificação de entrega como a sua própria AIPD não realizou nenhuma. Saber se a cópia de controlo se justifica para os seus formulários, se aí são de esperar categorias especiais de dados pessoais e como informa os seus visitantes são questões que só ele pode decidir. A secção 11 resume o que é necessário esclarecer para esse efeito.

3. Avaliação de limiar: é necessária uma AIPD?

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

O Art. 35(1) exige uma AIPD quando um certo tipo de tratamento, em particular que utilize novas tecnologias, e tendo em conta a sua natureza, âmbito, contexto e finalidades, for suscetível de implicar um elevado risco para os direitos e liberdades das pessoas singulares. O Art. 35(3) indica três casos em que tal sucede em particular. Nenhum dos três se aplica a formexposed, e isso deve ser fundamentado em vez de simplesmente afirmado:

• Alínea (a) – uma avaliação sistemática e completa dos aspetos pessoais relacionados com pessoas singulares, baseada no tratamento automatizado, sendo com base nela adotadas decisões que produzem efeitos jurídicos ou que as afetem significativamente de forma similar. Avaliamos formulários e sítios web, não aspetos pessoais de pessoas. O serviço não toma qualquer decisão com efeitos jurídicos sobre nenhuma pessoa. O que mais se aproxima disso é a proteção em enxame: as mensagens que contêm uma ligação para um domínio incluído na lista vão parar à quarentena nos sítios web ligados. Trata-se de uma consequência automatizada para a mensagem, não de uma avaliação completa de uma pessoa; tratamo-la no critério “Avaliação ou classificação” na secção 3.3.
• Alínea (b) – operações de tratamento em grande escala de categorias especiais nos termos do Art. 9 ou de dados relacionados com condenações penais e infrações nos termos do Art. 10. Não pretendido nem implementado. Tais dados podem, no entanto, chegar até nós por uma via: na cópia de controlo de mensagens reais de visitantes na verificação de entrega. Isso depende do caso concreto e não é em grande escala na aceção desta disposição; é, contudo, tido em conta na avaliação de riscos (R1).
• Alínea (c) – controlo sistemático de zonas acessíveis ao público em grande escala. Refere-se à observação física de locais, não à consulta de páginas web públicas. Invocar esta disposição como fundamento para um crawler de sítios web seria incorreto.

A via correta é, por conseguinte, o próprio Art. 35(1), aplicado através dos nove critérios das Orientações relativas à Avaliação de Impacto sobre a Proteção de Dados do Grupo de Trabalho do Artigo 29.º (WP248 rev.01, aprovadas pelo Comité Europeu para a Proteção de Dados), e a lista da autoridade de controlo polaca nos termos do Art. 35(4) (secção 3.4).

3.2 Os nove critérios das orientações WP248

As orientações indicam nove características que apontam para um provável risco elevado. Como regra prática, uma operação de tratamento que preencha dois deles exigirá, na maioria dos casos, uma AIPD. Um responsável pelo tratamento pode chegar a uma conclusão diferente num caso concreto, mas deve então fundamentá-la e documentá-la. Inversamente, um único critério pode ser suficiente. Nesta página utilizamos as seguintes designações abreviadas:

1. C1 – Avaliação ou classificação, incluindo a definição de perfis e a previsão, por exemplo do desempenho profissional, da situação económica, da fiabilidade ou do comportamento.
2. C2 – Decisões automatizadas que produzam efeitos jurídicos ou afetem significativamente de modo similar.
3. C3 – Controlo sistemático, ou seja, tratamento utilizado para observar, monitorizar ou controlar os titulares dos dados, incluindo através de redes. As orientações justificam expressamente este critério com o facto de os titulares dos dados muitas vezes não saberem quem recolhe os seus dados e para que finalidade.
4. C4 – Dados sensíveis ou dados de natureza altamente pessoal: categorias especiais nos termos dos Art. 9 e 10, mas também dados cuja divulgação afete significativamente a vida quotidiana, incluindo comunicações eletrónicas cuja confidencialidade deva ser protegida.
5. C5 – Dados tratados em grande escala, medidos pelo número de titulares dos dados, pelo volume e variedade de dados, pela duração e pela extensão geográfica.
6. C6 – Estabelecer correspondências ou combinar conjuntos de dados provenientes de diferentes operações de tratamento ou de diferentes responsáveis pelo tratamento, de uma forma que os titulares dos dados não esperariam.
7. C7 – Dados relativos a titulares de dados vulneráveis, por exemplo trabalhadores, crianças, doentes ou outras pessoas numa situação de desequilíbrio de poder.
8. C8 – Utilização inovadora ou aplicação de novas soluções tecnológicas ou organizacionais; na prática das autoridades de controlo, a utilização de inteligência artificial é regularmente considerada abrangida por este critério.
9. C9 – Tratamento que impede os titulares dos dados de exercer um direito ou de utilizar um serviço ou um contrato.

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

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

P1 – Verificação gratuita sem conta (verificação de qualquer sítio web de terceiros a pedido)

Qualquer pessoa pode introduzir um domínio na página inicial. O crawler consulta então, no máximo, oito páginas públicas desse sítio web, lê os formulários, faz capturas de ecrã e produz um relatório que qualquer pessoa que conheça a respetiva ligação aleatória pode ver. O operador do sítio web não toma conhecimento disto, a menos que repare no identificador do crawler nos seus registos.

• C1 – caso-limite. O relatório classifica a proteção de um formulário com um nível (“Exposto”, “Parcialmente protegido”, “Protegido”) e uma pontuação. No caso de uma sociedade por quotas, isto não diz respeito a uma pessoa singular. No caso de empresários em nome individual e trabalhadores independentes, o domínio pode ser atribuído à pessoa, e o nível diz então algo sobre o cuidado posto na sua atividade profissional. O que é avaliado, porém, é uma configuração técnica, não o comportamento ou as características de uma pessoa. Tratamos isto como caso-limite.
• C2 – não preenchido. Nada é decidido em relação ao operador. Em relação à pessoa que pede a verificação, aplicam-se limites por endereço IP e sessão (cfg/check_lib.php); uma verificação rejeitada não tem efeitos significativos.
• C3 – não preenchido. Trata-se de uma consulta única a pedido, no máximo uma vez por domínio e por semana (cfg/check_lib.php, definição fc_domain_days = 7). Nenhuma pessoa é observada. A circunstância que as orientações invocam para justificar o C3 – os titulares dos dados nada sabem do tratamento – está, no entanto, presente. É tida em conta na avaliação de riscos (R5).
• C4 – não preenchido. O que é guardado é a estrutura do formulário e as constatações, não os valores introduzidos (scanner/src/crawl.js guarda apenas o comprimento de um valor nos campos visíveis). O scanner lê o início de campos ocultos pré-preenchidos (até 24 caracteres) e de atributos de dados (até 60 caracteres) apenas durante a verificação, para detetar tokens e marcas temporais; não são guardados. As capturas de ecrã podem mostrar acidentalmente pessoas e nomes; o sítio web de um consultório médico mostra na imagem a sua especialidade. Trata-se de dados profissionais públicos, não de dados de saúde de uma pessoa concreta.
• C5 – caso-limite. O limite diário é de 200 verificações aceites (fc_daily_cap), ou seja, aritmeticamente até cerca de 73 000 sítios web por ano. Por sítio web surgem apenas alguns dados pessoais, e a duração é curta (30 dias). Medido no sistema de desenvolvimento, existem 2 verificações anónimas no conjunto de dados. Hoje não preenchido; caso-limite tendo em conta a capacidade prevista.
• C6 – não preenchido. Além de consultar as páginas, o serviço consulta a idade do domínio através do serviço RDAP rdap.org (é transmitido apenas o nome de domínio; é guardada apenas a data de registo, em cache) e resolve o DNS. Trata-se de dados técnicos sobre o domínio, não de uma combinação de conjuntos de dados sobre pessoas.
• C7 – não preenchido.
• C8 – preenchido, de forma fraca. Um navegador automatizado verifica as páginas, e um modelo de linguagem no 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, as etiquetas dos campos e até 400 caracteres de texto do formulário. Nunca pode tornar um formulário “submetível”.
• C9 – não preenchido.

Resultado intermédio P1: um critério de forma fraca (C8), dois casos-limite (C1, C5). Nenhuma obrigação segundo a regra prática. Como ambos os casos-limite apontam no mesmo sentido e os titulares dos dados nada sabem do tratamento, incluímos o P1 na avaliação.

P2 – Verificação de potenciais clientes para agências

Uma agência no plano Business com marca própria configurada pode mandar verificar passivamente o sítio web de um potencial cliente. Recebe uma constatação breve com a sua marca e um relatório detalhado, e transmite ela própria a ligação (cfg/akquise_lib.php). Não contactamos ninguém.

• C1 – caso-limite, mais forte do que no P1. A constatação breve destina-se expressamente a “abrir a porta à primeira conversa”. A avaliação do sítio web torna-se assim a base para abordar comercialmente uma pessoa.
• C5 – não preenchido. No máximo 30 verificações por agência e por mês (prospect_monthly), eliminadas após 90 dias.
• C8 – preenchido, de forma fraca (a mesma tecnologia que no P1).
• Outros critérios – não preenchidos. A constatação é apresentada com a marca da agência, mas não é associada a outros dados sobre o operador.

Resultado intermédio P2: nenhuma obrigação segundo a regra prática; incluído pelas mesmas razões que o P1 e porque a finalidade – a angariação de clientes – comporta um risco próprio (R6).

P3 – Estudo “Form Security Index”

Para um estudo, uma lista de sítios web é verificada passivamente, com limitação a no máximo cinco tarefas em aberto por execução do processo de estado, que corre a cada cinco minutos (cfg/studie_lib.php). Só são publicados totais, e segmentos apenas a partir de 20 sítios web com formulário (study_min_segment, cfg/studie_lib.php). Os dados brutos são eliminados aquando da publicação (cfg/studie_lib.php).

• C5 – caso-limite, preenchido para listas grandes. O tamanho da lista não está limitado no código; a limitação permite aritmeticamente mais de mil verificações por dia. Um estudo de um mercado nacional abrange milhares de sítios web, muitos deles geridos por empresários em nome individual. A partir de tal dimensão, consideramos o critério preenchido.
• C8 – preenchido, de forma fraca.
• C1 – não preenchido. Embora o sítio web individual seja classificado, só é publicado o total; a classificação não serve para fazer uma afirmação sobre o operador individual.
• Outros critérios – não preenchidos.

Resultado intermédio P3: para estudos da dimensão prevista, dois critérios (C5, C8). O estudo atinge, por conseguinte, o limiar; formexposed realiza a avaliação enquanto responsável pelo tratamento. Medido no sistema de desenvolvimento, ainda não foi criado nenhum estudo.

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

O Cliente manda verificar regularmente os domínios da sua conta. Depois de ter provado que tem o direito de controlar o domínio, acrescem as submissões de teste ativas (no máximo cinco por verificação), a pesquisa de ficheiros expostos e os percursos de navegador configurados.

• C3 – não preenchido. A verificação é agendada e recorrente, mas diz respeito ao próprio sítio web do Cliente e é realizada a seu pedido, não para observar pessoas.
• C4 – caso-limite, não. A pesquisa de ficheiros expostos lê no máximo os primeiros 8 KB de caminhos como /backup.sql ou um registo de depuração, para determinar pelo conteúdo se o ficheiro está realmente exposto (cfg/dateien_lib.php). Tal excerto pode conter dados introduzidos por visitantes em formulários. É verificado apenas em memória e nunca guardado; o que é guardado é o caminho, o tipo e a gravidade.
• C8 – preenchido, de forma fraca.
• Outros critérios – não preenchidos.

Resultado intermédio P4: nenhuma obrigação. Incluído porque as submissões de teste ativas e a verificação de ficheiros dependem de uma prova que nunca é renovada (R7).

P5 – Análise atrás do início de sessão

Para um domínio verificado, o Cliente pode guardar uma conta de teste para o seu sítio web. O scanner inicia sessão com ela e lê os formulários em até cinco páginas indicadas da área de membros (cfg/login_lib.php, scanner/src/login.js).

• C4 – caso-limite. As credenciais não são dados de natureza altamente pessoal na aceção das orientações, mas a sua utilização abusiva abre a área de membros. Consoante o sítio web, pode haver conteúdo confidencial atrás de um início de sessão, por exemplo num portal de membros ou de doentes. Isso depende do Cliente, não de nós.
• C8 – não preenchido. Os inícios de sessão automatizados são comuns em serviços de monitorização.
• Outros critérios – não preenchidos.

Resultado intermédio P5: nenhuma obrigação segundo a regra prática. Para Clientes cuja área de membros mostre conteúdo confidencial, isto pode mudar; a decisão cabe-lhes então a eles. Incluído devido aos riscos de segurança (R8).

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

O Cliente introduz um endereço de controlo de formexposed como cópia oculta nas definições de correio do seu formulário. Em consequência, cada e-mail do formulário segue também para a nossa caixa de correio de controlo – tanto a nossa mensagem de teste como cada mensagem real de um visitante. Uma recolha automatizada lê os cabeçalhos e os primeiros 8 KB, faz a correspondência do e-mail, avalia SPF, DKIM e DMARC e elimina-o (cfg/zustellung_lib.php).

• C4 – preenchido. O que os visitantes escrevem num formulário de contacto é uma comunicação eletrónica dirigida a uma empresa, com conteúdo arbitrário. No sítio web de um consultório médico, de um escritório de advogados, de um serviço de aconselhamento ou de uma escola, são de esperar dados abrangidos pelo Art. 9 ou dados sobre crianças. As orientações referem expressamente as comunicações eletrónicas confidenciais neste critério.
• C3 – caso-limite, tendencialmente preenchido. Cada mensagem é copiada de forma planeada e contínua e avaliada automaticamente, sem que o remetente se aperceba. A finalidade é verificar a via de correio, não observar pessoas. No entanto, a circunstância com que as orientações justificam o critério – os titulares dos dados não sabem quem recebe os seus dados – está plenamente presente enquanto o Cliente não informar os seus visitantes.
• C7 – consoante o Cliente. Doentes, clientes de escritórios de advogados, candidatos a emprego, pais e alunos encontram-se frequentemente numa relação de dependência face ao destinatário da sua mensagem.
• C5 – caso-limite, não. Não é em grande escala para o Cliente individual. Em formexposed, as cópias de muitos Clientes convergem numa única caixa de correio; isso aumenta o peso de uma violação, não o número por responsável pelo tratamento.
• Outros critérios – não preenchidos. A correspondência com o domínio e o teste não constitui um cruzamento de conjuntos de dados sobre pessoas; a tecnologia não é nova.

Resultado intermédio P6: C4 preenchido, C3 caso-limite e tendencialmente preenchido, C7 preenchido para muitos Clientes típicos. Na constelação típica, estão portanto preenchidos dois ou mais critérios. É necessária uma AIPD – como obrigação do Cliente, que é o responsável pelo tratamento. As secções 6 a 11 fornecem-lhe os factos para esse efeito.

P7 – Proteção em enxame

Os sítios web WordPress ligados comunicam uma vez por dia os domínios das ligações contidas em mensagens que a sua camada de proteção travou. Um domínio que surja em pelo menos três sítios web diferentes com pelo menos cinco ocorrências em sete dias é colocado numa lista partilhada; a lista é devolvida a todos os sítios web ligados, que passam então a colocar em quarentena as mensagens com ligações para esse domínio (cfg/swarm_lib.php).

• C6 – preenchido. As comunicações de muitos sítios web independentes entre si, ou seja, de diferentes responsáveis pelo tratamento, são combinadas e devolvidas a todos eles como lista partilhada.
• C1 – preenchido, na medida em que um domínio possa ser atribuído a uma pessoa singular. A lista é uma classificação como fonte de spam. As orientações indicam a consulta de uma base de dados partilhada de fraudes como exemplo deste critério. A maioria dos domínios numa lista deste tipo pertence a empresas ou são domínios descartáveis; no entanto, o domínio de um particular pode acabar nela, com razão ou através de falsas comunicações deliberadamente introduzidas.
• C9 – caso-limite. Uma mensagem com uma ligação incluída na lista não chega de imediato ao destinatário, ficando na sua quarentena até que este a liberte. Não se perde.
• C2 – não preenchido. A quarentena é uma consequência automatizada para uma mensagem, sem efeitos jurídicos e com libertação humana pelo destinatário.
• Outros critérios – não preenchidos. As redes IP estão desativadas (swarm_ip_enabled = 0, cfg/swarm_lib.php).

Resultado intermédio P7: dois critérios (C6, C1) e um caso-limite (C9). O limiar é atingido; formexposed realiza a avaliação enquanto responsável pelo tratamento. Com as redes IP ativadas, o C1 e o C6 ficariam preenchidos sem restrições; a sua ativação exige uma nova versão desta avaliação (secção 12). Medido no sistema de desenvolvimento, não existem comunicações nem entradas na lista.

P8 – Contas de Clientes, início de sessão, registos, suporte, e-mail, pagamentos

• C1 e C9 – não preenchidos. Um comportamento anómalo na verificação gratuita leva a uma anotação com o endereço IP (cfg/check_lib.php) e, se for caso disso, à rejeição de novas verificações. Trata-se de prevenção de abusos com efeitos reduzidos, não de uma avaliação de aspetos pessoais.
• Outros critérios – não preenchidos. Trata-se dos dados habituais de um serviço destinado a empresas.

Resultado intermédio P8: não é necessária AIPD. As operações de tratamento estão descritas nos Registos das Atividades de Tratamento.

P9 – Indicadores do plugin, erros de campos, gravador, selo, portal de clientes, “Fix it for me”

• O plugin e a extensão transmitem indicadores diários, o inventário de plugins e categorias de erros, e o plugin para WordPress transmite adicionalmente domínios de ligações para a proteção em enxame (ativada por defeito) (P7), sem conteúdos, endereços, nomes ou IPs de visitantes; o gravador mantém seletores durante no máximo 15 minutos no navegador do administrador. Nenhum critério preenchido.
• Quando carregado, o selo transfere os dados de ligação habituais para o registo do servidor web, sem cookie. Nenhum critério preenchido.
• O portal de clientes trata os endereços de e-mail dos subscritores com dupla confirmação por conta da agência. Nenhum critério preenchido.
• O “Fix it for me” manda reescrever código de formulário colado por um modelo de linguagem no nosso próprio servidor; o código não é guardado. C8 de forma fraca, nada mais.

Resultado intermédio P9: não é necessária AIPD.

3.4 A lista da autoridade de controlo polaca nos termos do Art. 35(4)

A autoridade competente é o Presidente do Gabinete 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 associa as suas entradas aos critérios das orientações WP248, dá exemplos e não é expressamente 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 (paráfrase)	Critério associado	Operação de tratamento em formexposed	Avaliação
Comparação, avaliação ou inferência com base na análise de dados provenientes de diferentes fontes	C6	P7 Proteção em enxame	aplica-se
Avaliação ou classificação, incluindo a definição de perfis	C1	P7 Proteção em enxame; P1 e P2 como casos-limite	aplica-se ao P7
Tratamento de categorias especiais de dados pessoais	C4	P6 Verificação de entrega	aplica-se consoante o Cliente
Utilização inovadora 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 grande escala	C5	P3 Estudo	aplica-se a listas grandes
Controlo sistemático de locais acessíveis ao público, incluindo com reconhecimento de características	C3	–	não se aplica: refere-se a locais, não a sítios web

Esta associação é uma leitura, não uma citação; a redação das entradas deve ser confrontada com ela na revisão jurídica. Confirma o resultado da secção 3.3, mas não o altera. Tanto quanto 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 de limiar

Operação de tratamento	Preenchido	Caso-limite	Resultado
P1 Verificação gratuita	C8 (fraco)	C1, C5	não obrigatória; incluída
P2 Verificação de potenciais clientes	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 de Clientes	C8 (fraco)	C4 (verificação de ficheiros)	não obrigatória; incluída
P5 Análise atrás do início de sessão	–	C4	não obrigatória; incluída; para o Cliente consoante o conteúdo
P6 Verificação de entrega	C4; C7 consoante o Cliente	C3 (tendencialmente preenchido), C5	necessária (obrigação do Cliente; esta página presta assistência nos termos do Art. 28(3)(f))
P7 Proteção em enxame	C6, C1	C9	necessária (obrigação de formexposed)
P8 Contas, registos, suporte, pagamentos	–	–	não necessária
P9 Indicadores do plugin, selo, portal, “Fix it for me”	C8 (fraco, apenas “Fix it for me”)	–	não necessária

Resultado quanto ao Art. 35(1): É necessária uma AIPD para determinadas operações de tratamento de formexposed. É necessária para a proteção em enxame e para estudos da dimensão prevista, e formexposed realiza-a enquanto responsável pelo tratamento. Para a verificação de entrega é necessária na constelação típica, mas como obrigação do Cliente; formexposed fornece a base. Para as restantes verificações de sítios web de terceiros e próprios não é obrigatória. Incluímo-las, no entanto, porque utilizam a mesma tecnologia, porque vários casos-limite apontam no mesmo sentido e porque os titulares dos dados – operadores sem conta e pessoas presentes nas páginas verificadas – nada sabem do tratamento. Não é necessária qualquer avaliação para contas, registos, suporte e pagamentos.

As secções 6 a 10 aplicam-se, por conseguinte, ao P1 a P7. Quando uma afirmação se aplica apenas a uma destas operações de tratamento, é assinalada como tal.

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

Não foi designado nenhum encarregado da proteção de dados. O Art. 37(1) vincula igualmente o responsável pelo tratamento e o subcontratante; a questão é, por conseguinte, nossa. Os três casos legais:

Art. 37(1)	Condição	Resultado
alínea (a)	Autoridade ou organismo público	Não aplicável; LW IT Solutions Company Lukas Wójcik é uma empresa privada em nome individual.
alínea (b)	As atividades principais consistem em operações de tratamento que exigem um controlo regular e sistemático dos titulares dos dados em grande escala	A atividade principal é a verificação e a monitorização de sítios web e formulários, de forma regular e sistemática. No entanto, nenhuma pessoa é controlada: o crawler não observa comportamentos, e a verificação de entrega avalia os e-mails apenas quanto à entrega e à autenticidade. Não preenchido.
alínea (c)	As atividades principais consistem em operações de tratamento em grande escala de dados nos termos dos Art. 9 ou 10	Não por conceção. Podem chegar até nós categorias especiais através da cópia de controlo da verificação de entrega; isso é acidental, não uma atividade principal. Não preenchido.

No nosso entender, não existe, por conseguinte, obrigação de designar um encarregado. Saber se a legislação polaca exige uma designação para além disso, nos termos do Art. 37(4), é uma questão em aberto para a revisão jurídica. Como não foi designado nenhum encarregado da proteção de dados, o parecer previsto no Art. 35(2) não se aplica. Se a revisão jurídica concluir que existe uma obrigação de designação, o parecer do encarregado da proteção de dados então designado será solicitado antes de esta avaliação ser aprovada (secção 12). A pessoa de contacto para questões sobre esta avaliação é o proprietário, através de contact@lukaswojcik.com.

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

Os factos deste documento provêm do código-fonte da aplicação e do scanner, do esquema da base de dados e de contagens de linhas e definições do sistema de desenvolvimento, medidos em 11 de outubro de 2026. A base de dados e os servidores foram acedidos apenas em modo de leitura. Quando uma medição contradiz uma intenção – incluindo uma afirmação nos nossos próprios documentos jurídicos – comunicamos a medição. Não aplicamos códigos de conduta aprovados nos termos do Art. 40, cujo cumprimento teria de ser tido em conta nos termos do Art. 35(8).

• Foi medido o sistema de desenvolvimento. O serviço ainda não foi lançado. Os números são, por isso, reduzidos e, em parte, artefactos de testes: 112 verificações, 110 das quais sem domínio de Cliente; 432 capturas de ecrã; 2 domínios, 1 dos quais verificado; nenhuma verificação de entrega ativada; nenhuma conta de teste guardada para a análise atrás do início de sessão; nenhum estudo; nenhuma comunicação na proteção em enxame. As medições devem ser repetidas antes do lançamento e, depois disso, a intervalos regulares.
• Não foram medidos nesta versão e devem ser acrescentados antes da aprovação: a configuração do sistema de produção, incluindo se e como a caixa de correio de controlo está configurada e se o par de chaves para a análise atrás do início de sessão está aí configurado; se o software do modelo de linguagem regista os pedidos; o estado da administração dos servidores (R13); o contrato com o prestador de serviços de correio eletrónico.
• Não foi possível medir quantas mensagens reais de visitantes passarão pela cópia de controlo e de que setores virão os Clientes. Ambos os fatores determinam o peso de R1 e R2 e devem ser apurados após o lançamento.
• As referências de origem remetem para ficheiros e funções no código-fonte do sistema de desenvolvimento. O que é determinante é a função descrita, não a sua localização no ficheiro.

Este documento é um projeto. Ainda não foi aprovado pelo responsável pelo tratamento (secção 12), e duas das suas conclusões – a avaliação da escala para o P1 e o 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 das finalidades

6.1 Como está estruturado o sistema de verificação

formexposed funciona em servidores próprios na Polónia, sem um fornecedor de alojamento externo: um servidor web com a aplicação e a base de dados, e um servidor de análise com o serviço de verificação e um modelo de linguagem local, ambos na mesma rede interna. Uma verificação decorre da seguinte forma:

1. A aplicação cria uma tarefa na base de dados – sujeita aos limites e bloqueios descritos na secção 6.3.
2. O serviço de verificação no servidor de análise vai buscar a tarefa, verifica uma segunda vez a lista de bloqueio, os nomes de anfitrião e, nas verificações anónimas, a idade do domínio, e inicia um contentor isolado exatamente para esta tarefa: rede própria com regras de filtragem próprias, sem privilégios especiais, sistema de ficheiros só de leitura, limites de memória e de processos, e um limite de tempo (scanner/src/worker.js).
3. Dentro do contentor, um navegador automatizado consulta no máximo oito páginas públicas, primeiro a página inicial, depois, preferencialmente, as páginas de contacto, ficha técnica e suporte. Antes disso lê o robots.txt; uma exclusão para FormExposedBot ou para todos os crawlers que abranja a página inicial termina a verificação, tal como um robots.txt inacessível ou um erro de servidor na consulta (scanner/src/net.js). As proibições relativas a subcaminhos individuais não são observadas separadamente. O pulso do formulário, a obtenção da prova, a ferramenta de cabeçalhos e a pesquisa de ficheiros expostos não leem o robots.txt. Para 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 vista de telemóvel, sondas ativas para domínios verificados e até cinco páginas atrás de um início de sessão; as páginas são carregadas umas após as outras, não em paralelo. Cada pedido do navegador – incluindo redirecionamentos e conteúdos incorporados – passa por um filtro que rejeita redes privadas e outras portas.
4. O contentor escreve um resultado e as capturas de ecrã num diretório temporário. O serviço de verificação passa o resultado e as imagens à aplicação através da rede interna e elimina o diretório temporário, mesmo após um erro (scanner/src/worker.js).
5. A aplicação processa o resultado, compara-o com a verificação anterior no caso de domínios de Clientes e comunica as alterações aos destinos configurados pelo Cliente.

6.2 O que o crawler guarda – e o que não guarda

Elemento	O que é guardado	O que não é guardado	Referência de origem
Páginas	Endereço, estado HTTP, cabeçalhos, Content Security Policy, anfitriões 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, etiqueta, placeholder, campo obrigatório, visibilidade, comprimento de um valor existente	Valores dos campos; nos campos ocultos, os primeiros 24 caracteres do valor só são lidos durante a verificação (para detetar 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 controlo; endereços e texto inicial sem identificadores de conta de serviços de publicidade e de análise	Identificadores de conta e de pixel	scanner/src/crawl.js
Escutas	que pixels publicitários e ferramentas de gravação são carregados antes e depois de se clicar em “Rejeitar” no banner de cookies, e se mascaram as introduções de dados	Identificadores das contas nesses serviços	scanner/src/mitleser.js, scanner/src/einwilligung.js
Texto do formulário	até 400 caracteres seguem 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 ecrã (crawler)	á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 ecrã (verificação ativa)	Imagem da página de resposta à submissão de teste; além disso, o estado, o endereço de destino, o título e os primeiros 300 caracteres do seu texto	–	scanner/src/active.js
Capturas de ecrã (percursos de navegador)	Imagem do formulário com os campos de introdução ocultados, comprimida, no máximo 32 KB	Dados introduzidos	scanner/src/browser.js
Atrás do início de sessão	como para os campos de formulário acima	Capturas de ecrã, cookies, ligações	scanner/src/login.js

Por conceção, estes elementos não contêm dados pessoais, mas contêm-nos acidentalmente: o nome de uma pessoa de contacto junto ao formulário, uma fotografia da equipa na página inicial, um número de telefone numa etiqueta, o domínio de e-mail de um particular, um nome num placeholder. Atrás do início de sessão, acrescem dados da conta de teste e, consoante o sítio web, de outros utilizadores.

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

Acionador	Nível de confiança na tarefa	Submissões de teste	Resultado acessível através de	Eliminação
Alguém introduz um domínio na página inicial (verificação gratuita)	anónimo	não	Relatório numa ligação aleatória	30 dias, incluindo imagens (cfg/check_lib.php)
Plugin ou extensão sem conta	plugin	não	Relatório numa ligação aleatória	30 dias
Agência para um potencial cliente	registado	não	Constatação breve e relatório numa ligação aleatória	90 dias (cfg/akquise_lib.php)
Cliente, domínio sem prova	registado	não	Conta; relatório numa ligação aleatória	13 meses, a última verificação é mantida
Cliente, domínio com prova	verificado	sim, no máximo cinco por verificação	Conta; relatório numa ligação aleatória	13 meses, a última verificação é mantida (cfg/fristen_lib.php)
Estudo	interno	não	apenas totais após a publicação	aquando da publicação; sem publicação, sem limite temporal (R4)
Verificação interna a partir da linha de comandos pelo prestador	interno; para os nossos próprios domínios de teste e de demonstração também “verificado”	não; com o nível “verificado” sim (apenas os nossos próprios domínios de teste e de demonstração)	apenas interno	sem limite temporal (R4)

A verificação gratuita é precedida de várias camadas (cfg/check_lib.php): uma paragem de emergência; reCAPTCHA; o mesmo domínio no máximo uma vez em sete dias (depois disso é mostrado o relatório existente); 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 do robots.txt; a verificação de que o domínio aponta para endereços públicos; e um bloqueio para domínios muito recentes ou desconhecidos. As anomalias – muitos domínios diferentes a partir de um endereço IP, muitos pedidos em pouco tempo – são anotadas com o endereço IP e desencadeiam um sinal sem conteúdo (cfg/check_lib.php).

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

O Cliente prova que tem o direito de controlar um domínio: através de registo DNS, meta tag, ficheiro ou do nosso plugin (cfg/verify_lib.php). Só então o domínio é tratado como verificado. O agendador da monitorização só planeia verificações regulares para domínios ativos, monitorizados e verificados (cfg/monitor_lib.php).

• As submissões de teste ativas estão sujeitas a duas barreiras: a aplicação só ativa o modo ativo para Clientes em domínios verificados (para os nossos próprios domínios de teste e de demonstração, o prestador pode criar uma verificação com o nível “verificado” através de uma ferramenta interna de linha de comandos), e o serviço de verificação volta a verificar o nível de confiança e a paragem de emergência fc_active_enabled (scanner/src/worker.js). Só pode ser submetido um formulário que as regras reconheçam com elevada certeza como formulário de contacto geral, que não tenha campos obrigatórios para dados pessoais reais e cujo domínio não pareça ser de uma 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 submetível (scanner/src/classify.js). São enviadas no máximo cinco submissões por verificação (fc_active_max_posts), claramente assinaladas, com o remetente dummy@formexposed.com, um endereço sob .invalid para testar a validação de e-mail e uma linha de cabeçalho adicional inofensiva para detetar injeção de cabeçalhos (scanner/src/active.js).
• Os percursos de navegador verificam percursos de formulário configurados num navegador até ao ponto imediatamente anterior à submissão. Só são permitidos pedidos GET e HEAD; tudo o resto é interrompido, tal como endereços que contenham palavras relativas a terminar sessão, eliminar, comprar ou pagar (scanner/src/browser.js). Para a verificação, os campos obrigatórios são preenchidos com valores fictícios que nunca saem do navegador.
• Os ficheiros expostos são procurados semanalmente, apenas em domínios verificados, com no máximo uma consulta por caminho, no máximo 8 KB, e o conteúdo nunca é guardado (cfg/dateien_lib.php).
• Uma segunda sonda independente foi preparada e está desativada por defeito (browser_probe_enabled = 0). Se fosse ativada, receberia apenas o domínio, o endereço, o seletor, os passos e a escolha do navegador, nunca credenciais, capturas de ecrã ou dados de visitantes (cfg/formular_probe_lib.php).

6.5 Análise atrás do início de sessão

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

1. O nome de utilizador e a palavra-passe são imediatamente cifrados no servidor web com a chave pública do servidor de análise: uma chave de utilização única por registo (X25519), derivação de chaves (HKDF-SHA256), AES-256-GCM, vinculada ao domínio (cfg/login_lib.php). Só o serviço de verificação no servidor de análise tem a chave privada (scanner/src/geheim.js). Quem tiver o servidor web, a base de dados ou uma cópia de segurança tem apenas texto cifrado.
2. A interface mostra apenas o primeiro carácter e o comprimento do nome de utilizador (cfg/login_lib.php). As credenciais nunca são apresentadas, nunca são registadas e nunca são devolvidas através da API.
3. Para uma verificação, a aplicação anexa o texto cifrado à tarefa. O serviço de verificação decifra-o, apaga imediatamente o campo na tarefa e passa as credenciais ao contentor apenas através da entrada padrão, nunca como argumentos da linha de comandos (scanner/src/worker.js). Os restos em tarefas interrompidas são apagados pelo processo de estado ao fim de uma hora (cfg/login_lib.php).
4. Dentro do contentor, o navegador inicia sessão. Interrompe se a página de início de sessão redirecionar para outro anfitrião, se o formulário de início de sessão tiver um CAPTCHA (não contornamos CAPTCHAs) ou se, após a submissão, um campo de palavra-passe continuar visível (scanner/src/login.js). Em seguida, apaga o campo de palavra-passe na memória da página e esquece as credenciais (scanner/src/login.js).
5. Lê no máximo cinco páginas do mesmo domínio indicadas pelo Cliente. Os endereços que contenham palavras relativas a terminar sessão, eliminar, remover ou cancelar são bloqueados (scanner/src/login.js). Nada é submetido atrás do início de sessão, não são feitas capturas de ecrã, e os cookies e as ligações não entram no resultado (scanner/src/login.js).
6. A eliminação é definitiva: o texto cifrado é substituído por dados aleatórios do mesmo comprimento, a linha é eliminada e as tarefas pendentes são limpas (cfg/login_lib.php). Quando o domínio é eliminado, a linha desaparece automaticamente através de uma chave estrangeira.

6.6 Verificação de entrega

A verificação de entrega responde à questão de saber se um e-mail do formulário de contacto chega realmente, e avalia as suas características de autenticidade. É facultativa, está desativada por defeito e exige que esteja configurada uma caixa de correio de controlo (cfg/zustellung_lib.php).

1. Se o Cliente a ativar, o domínio recebe uma etiqueta aleatória. O Cliente introduz o endereço de controlo com esta etiqueta como cópia oculta no seu formulário.
2. A partir daí, cada e-mail do formulário segue também para a caixa de correio de controlo: as nossas submissões de teste assinaladas e todas as mensagens reais de visitantes. Os e-mails seguem diretamente para a caixa de correio em Namecheap, Inc. (Private Email), Phoenix, Arizona, USA – só chegam se os registos MX do nosso domínio apontarem para lá; através de reencaminhamento, por exemplo no registador de domínios Namecheap, Inc., não chegam à caixa de correio – e aí permanecem até serem recolhidos.
3. O processo de estado recolhe a caixa de correio 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 os marcar como lidos (cfg/zustellung_lib.php).
4. A partir dos cabeçalhos determina a etiqueta e, assim, o domínio, e a partir do texto, se for caso disso, o identificador do nosso teste (cfg/zustellung_lib.php). São guardados a hora, o domínio e, se for caso disso, o identificador do teste (cfg/zustellung_lib.php), durante 180 dias (cfg/zustellung_lib.php).
5. A partir dos cabeçalhos avalia SPF, DKIM e DMARC e guarda o resultado associado ao domínio: os resultados da verificação, o domínio do endereço do remetente, os domínios das assinaturas e o endereço do servidor de correio emissor (cfg/zustellung_lib.php). Se o resultado piorar, é enviado uma vez ao Cliente um alerta que pode indicar o domínio do remetente (cfg/zustellung_lib.php).
6. Em seguida, marca cada e-mail recolhido para eliminação, incluindo os que não puderam ser associados a nenhum domínio, e remove-os da caixa de correio no final da execução (cfg/zustellung_lib.php). Se a execução for interrompida antes disso, os e-mails mantêm-se até à execução bem-sucedida seguinte.
7. Só a cópia exatamente do teste em causa conta como prova de entrega (cfg/zustellung_lib.php). Se não chegar no prazo de três horas (delivery_wait_h), o serviço comunica “Entrega em falta”.

O texto das mensagens reais nunca é escrito na base de dados, nem o endereço do visitante. Ambos são, no entanto, lidos: a recolha carrega para a memória os primeiros 8 KB de cada e-mail para procurar o identificador do teste.

6.7 Proteção em enxame

1. A camada de proteção do plugin para WordPress trava uma mensagem como spam e conta os domínios das ligações nela contidas. Uma vez por dia, o plugin comunica-nos esses domínios com o respetivo número de ocorrências, no máximo 60 por dia; sem endereços, sem texto, sem endereços IP (cfg/swarm_lib.php).
2. Uma vez por dia compilamos a lista a partir daí: um domínio é incluído se tiver sido comunicado em sete dias por pelo menos três sítios web 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 ambos os casos incluindo subdomínios, nunca entram na lista (cfg/swarm_lib.php).
3. A lista segue para todos os sítios web ligados com a resposta à comunicação diária. A sua camada de proteção coloca as mensagens com ligações para domínios incluídos na lista em quarentena, não no lixo.
4. O que deixar de constar da nova lista é retirado; as comunicações são eliminadas após 30 dias (cfg/swarm_lib.php).
5. As redes IP (/24 ou /48) foram preparadas, mas estão desativadas até à conclusão da revisão jurídica (cfg/swarm_lib.php).

6.8 Utilização de inteligência artificial

Um modelo de linguagem funciona no nosso próprio servidor de análise, não num fornecedor de IA. É utilizado em dois locais: no serviço de verificação, classifica formulários cujo tipo as regras não reconhecem; para tal, vê o título da página, o endereço da página, as etiquetas dos botões de submissão, os tipos de campos, nomes, etiquetas e placeholders, e até 400 caracteres de texto do formulário (scanner/src/classify.js). Só é consultado se as regras devolverem “desconhecido”; os formulários assim classificados nunca são submetidos e não contam para a pontuação nem para o veredito. A pontuação, o veredito, a prevenção de abusos, a proteção em enxame e as regras de spam são regras fixas, não IA. No “Fix it for me”, reescreve código de formulário colado; o código não é guardado. O modelo não toma decisões sobre pessoas. Mais informações na página Regulamento da UE sobre IA: como a formexposed utiliza a IA.

6.9 Fundamentos jurídicos

Operação de tratamento	Fundamento jurídico
P1 Verificação gratuita: verificação do domínio pedido; limites e prevenção de abusos	em relação à pessoa que faz o pedido, Art. 6(1)(b); em relação ao operador e às pessoas representadas, Art. 6(1)(f); prevenção de abusos, Art. 6(1)(f)
P2 Verificação de potenciais clientes	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 de Clientes	Art. 6(1)(b) em relação ao Cliente; para dados de terceiros no seu sítio web, as instruções do Cliente nos termos do Art. 28
P5 Análise atrás do início de sessão	Instruções do Cliente nos termos do Art. 28; o fundamento jurídico do Cliente
P6 Verificação de entrega	Instruções do Cliente nos termos do Art. 28; o fundamento jurídico do Cliente (na nossa proposta de texto para Clientes, Art. 6(1)(f))
P7 Proteção em enxame	Art. 6(1)(f) (defesa conjunta contra spam em muitos sítios web)

O nosso interesse legítimo no P1 a P3 consiste em mostrar aos operadores e aos seus prestadores de serviços as fragilidades dos seus formulários antes de serem exploradas para spam ou abuso, e em prestar o serviço. Os dados provêm de fontes acessíveis ao público. A ponderação de interesses consta da secção 7; saber se o Art. 6(1)(f) sustenta a verificação de sítios web de terceiros a pedido é uma questão em aberto 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	Estado
Ninguém fora de formexposed	Resultados de verificação, capturas de ecrã, classificação pelo modelo de linguagem	P1–P5	O serviço de verificação e o modelo de linguagem funcionam nos nossos próprios servidores; no percurso de verificação do crawler não foi encontrada qualquer chamada a terceiros além do próprio sítio web verificado, dos serviços cujo conteúdo este incorpora (como para qualquer visitante) e do serviço RDAP rdap.org para a idade do domínio (apenas o nome de domínio); as vigilâncias da monitorização constam da linha seguinte
Qualquer pessoa que conheça a ligação	Relatório com constatações e capturas de ecrã	P1, P2, P4	ligação aleatória com 128 bits (cfg/check_lib.php), páginas com noindex (www/report.php)
Serviços consultados pela monitorização de um domínio de 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 temporal Certum e DigiCert: apenas um valor de hash do registo de prova; RDAP através do registo da IANA: apenas o nome de domínio; páginas de estado dos fornecedores: nada é transmitido; wpvulnerability.net: identificador de um plugin (sem versão) ou tema e a versão do WordPress	P4	em utilização; pormenores nos Registos das Atividades de Tratamento e na página Subcontratantes
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Cópias de controlo, incluindo mensagens reais de visitantes	P6	Contrato ainda não celebrado; local de tratamento e mecanismo de transferência ainda por examinar
Namecheap, Inc. (EUA)	Registador e DNS; até a caixa de correio estar configurada, reencaminhamento de e-mails gerais para endereços do nosso domínio, não das cópias de controlo (estas só chegam à caixa de correio através de registos MX que apontem diretamente para ela)	– (sem cópias de controlo)	Mecanismo de transferência por examinar
Canais de alerta escolhidos pelo Cliente (e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	Evento, domínio, ligação; para a verificação de autenticidade, o domínio do remetente se não pertencer ao sítio web	P4, P6	destino escolhido pelo Cliente; em parte fora da UE. Enviamos as mensagens do Telegram através do nosso bot; o mecanismo de transferência para tal é uma questão em aberto para a revisão jurídica
Todos os sítios web ligados	Lista de domínios de ligações	P7	através da resposta ao plugin
Segunda sonda	Domínio, endereço do formulário, seletor, passos	P4	desativada

6.11 Conservação, medida, não pretendida

A eliminação ocorre sobretudo durante a noite, às 03:00, no processo de estado (srv/cron_status.php, cfg/fristen_lib.php); as comunicações da proteção em enxame e as linhas de potenciais clientes são eliminadas diariamente a partir das 04:00, as correspondências da verificação de entrega em cada recolha; os relatórios anónimos e de potenciais clientes são eliminados através da sua data de expiração (cfg/check_lib.php). As capturas de ecrã são eliminadas do disco juntamente com a respetiva análise (cfg/fristen_lib.php).

Dados	Prazo segundo o código	Referência de origem	Constatação
Verificação gratuita, incluindo imagens	30 dias	cfg/check_lib.php	eficaz
Verificação de potenciais clientes, incluindo imagens	90 dias	cfg/akquise_lib.php; srv/cron_status.php (linhas de potenciais clientes)	eficaz
Verificações de um domínio de Cliente	13 meses; a última é mantida enquanto o domínio existir	cfg/fristen_lib.php	eficaz
Resultados de percursos de navegador, incluindo imagens ocultadas	13 meses	cfg/fristen_lib.php	eficaz
Dados de um domínio eliminado	de imediato; órfãos durante a noite	cfg/fristen_lib.php (fe_domain_loeschen(), fe_fristen_lauf())	eficaz, incluindo o inventário de scripts e as alterações de scripts, que não têm prazo de conservação próprio para além disso (ver Registos das Atividades de Tratamento)
Estudo: dados brutos, incluindo imagens	aquando da publicação	cfg/studie_lib.php	sem publicação, sem limite temporal; a lista de anfitriões verificados mantém-se sem limite temporal mesmo após a publicação
Verificações internas sem domínio e sem relatório	nenhum	–	sem eliminação; medido: 85 verificações com 369 imagens desde 22 de setembro de 2026 (R4)
Correspondências da verificação de entrega	180 dias	cfg/zustellung_lib.php	eficaz
Resultado da verificação de autenticidade associado ao domínio	até ao resultado seguinte ou à eliminação do domínio	cfg/zustellung_lib.php	substituído, sem limite temporal
Cópias de controlo na caixa de correio	até à recolha bem-sucedida seguinte (intervalo de cinco minutos)	cfg/zustellung_lib.php	cópias e cópias de segurança no fornecedor da caixa de correio não verificadas
Credenciais para a análise atrás do início de sessão	até à eliminação pelo Cliente ou do domínio; na tarefa, no máximo até ao fim da execução, restos após uma hora	cfg/login_lib.php	eficaz; nas cópias de segurança apenas como texto cifrado durante até 14 dias
Comunicações na proteção em enxame	30 dias	cfg/swarm_lib.php	eficaz
Limites da verificação gratuita (IP, país, hash da sessão)	7 dias	srv/cron_status.php	eficaz
Anotações sobre comportamento anómalo com endereço IP	90 dias após a resolução	srv/cron_status.php	anotações não resolvidas sem limite temporal; medido: 3 anotações, todas resolvidas
Endereço IP, país, navegador relativos a um opt-out	12 meses; a exclusão mantém-se	cfg/fristen_lib.php	eficaz
Cópias de segurança da base de dados	14 dias	cfg/backup_lib.php	eficaz; as cópias de segurança estão atualmente guardadas no mesmo local que a base de dados e não estão cifradas separadamente; está prevista uma cópia cifrada num segundo local (R13)

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

O critério são as finalidades declaradas: mostrar aos operadores se os seus formulários estão protegidos contra spam e abusos (P1 a P5), verificar se os e-mails dos formulários chegam e parecem autênticos (P6) e defender conjuntamente contra spam em muitos sítios web (P7). Estas 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 ingerência é proporcional ao benefício?

Componente	Necessário para a finalidade?	Proporcional na forma implementada?
Consulta de algumas páginas públicas, estrutura dos formulários, medidas de proteção detetadas	Sim. Sem elas não há constatação.	Sim. No máximo oito páginas (mais as vistas da secçã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 ecrã por formulário	Sim, como prova no relatório: o operador pode ver de que formulário se trata.	Em grande medida. Os campos estão vazios porque o crawler não escreve nada. A imagem mostra, no entanto, as imediações do elemento do formulário sem ocultar nada (R3).
Captura de ecrã da página inicial	Não necessária para a constatação em si. Serve para reconhecer o sítio web verificado no relatório.	Apenas em medida limitada; está prevista uma maior minimização. As páginas iniciais mostram muitas vezes pessoas: fotografias da equipa, pessoas de contacto, testemunhos de clientes com nomes. Ver R3 e a secção 9.3.
Leitura dos valores de campos ocultos (primeiros 24 caracteres, apenas durante a verificação)	Sim: a partir deles são detetados tokens e marcas temporais.	Sim. Só é guardado o resultado da deteção, não o valor, também atrás do início de sessão (R8).
Página de resposta à submissão de teste (imagem e 300 caracteres de texto)	Sim, como prova de como o formulário respondeu.	Sim. A resposta diz respeito à nossa mensagem de teste assinalada, sem dados pessoais.
Classificação pelo modelo de linguagem	Útil, não necessária: sem ela, mais formulários ficam como “desconhecido”.	Sim. Local, sem divulgação, sem direito de submeter.
Submissões de teste ativas	Sim. Só ao testar se percebe se uma proteção funciona.	Sim, com limite máximo e marcação. A condição prévia – a prova de controlo – nunca é, no entanto, renovada (R7).
Pesquisa de ficheiros expostos	Sim para o Cliente, cujos dados de formulários podem estar aí expostos.	Sim. Apenas domínios verificados, no máximo 8 KB, o conteúdo nunca é guardado.
Análise atrás do início de sessão	Sim para formulários na área de membros que de outro modo ficariam por verificar.	Em grande medida. A cifragem e a eliminação estão cuidadosamente implementadas; o início de sessão aceita, no entanto, ligações não cifradas e certificados defeituosos (R8).
Cópia de controlo de mensagens reais de visitantes	Não para a prova de entrega. Esta assenta apenas na cópia do nosso teste (cfg/zustellung_lib.php). As mensagens reais vêm por arrasto, porque uma cópia oculta no formulário não distingue entre um teste e uma mensagem real. São úteis para a verificação de autenticidade (SPF, DKIM, DMARC), porque mostram a via de envio efetiva.	Em parte. O conteúdo não é guardado, mas é lido, e permanece no fornecedor da caixa de correio, cujo contrato está ainda em aberto, até à recolha (R1, R2). É tecnicamente possível uma conceção menos intrusiva: com o nosso plugin, a cópia oculta poderia ser limitada às mensagens de teste assinaladas (secção 9.3).
Armazenamento do domínio do remetente de mensagens reais	Em parte: mostra se o formulário envia com o endereço do visitante como remetente (causa frequente de classificação como spam).	Condicionalmente. No caso de um particular com domínio próprio, o domínio é um dado pessoal, e segue no alerta para o Cliente e os seus canais (R1).
Lista partilhada de domínios de ligações	Sim. Uma ligação de spam que surge em muitos sítios web ao mesmo tempo é um sinal forte de que um sítio web isolado não dispõe.	Sim, com números mínimos, exceções e quarentena em vez de eliminação. As redes IP não seriam proporcionais sem uma nova avaliação.
Dados brutos do estudo	Até à avaliação, sim.	Sem prazo máximo, não (R4).
Relatório numa ligação aleatória	Sim. Transmitir o relatório – por exemplo ao prestador de serviços que cuida do sítio web – é a finalidade da verificação gratuita.	Sim. Ligação aleatória com 128 bits, noindex, relatório gratuito apenas como excerto (cfg/check_lib.php, FE_FREE_DETEKTOREN), eliminação após 30 dias.

Licitude. Para o P1 a P3 e o P7 baseamo-nos no Art. 6(1)(f). A favor da ponderação: os dados são públicos e são consultados da mesma forma que qualquer visitante o faz; nada é submetido; os dados pessoais são acidentais e escassos; os prazos são curtos; o operador pode excluir novas verificações pelo crawler através de uma proibição da página inicial no robots.txt e qualquer nova verificação através da nossa página de opt-out, de imediato e sem prova; o benefício – um formulário protegido – reverte também para o operador e os seus visitantes. Contra: o operador não toma conhecimento da verificação, o relatório destina-se a terceiros e, no caso de empresários em nome individual, avalia uma pessoa. Consideramos a ponderação justificável enquanto se mantiverem as medidas da secção 9.1; a confirmação jurídica está pendente.

Informação aos titulares dos dados (Art. 13 e 14). Informamos os operadores e as pessoas presentes nas páginas verificadas através da página do crawler, que é indicada no identificador de cada consulta, através da Política de Privacidade e através da página de opt-out. Informar individualmente as pessoas que surgem acidentalmente numa captura de ecrã só seria possível se as identificássemos – o que constituiria uma ingerência adicional e mais grave. Nessa medida, baseamo-nos no Art. 14(5)(b). Os visitantes cujas mensagens passam pela cópia de controlo são informados pelo Cliente; o Acordo de Tratamento de Dados exige-o, e disponibilizamos um bloco de texto para o efeito.

Minimização dos dados (Art. 5(1)(c)). É visível em muitos locais e está fundamentada no código: sem valores de campos, endereços de destinatários apenas como domínio, identificadores de conta em endereços de scripts ocultados, sem conteúdo da cópia de controlo na base de dados, sem capturas de ecrã atrás do início de sessão, apenas domínios na proteção em enxame. Em dois locais é possível e está prevista uma maior minimização (secção 9.3): na captura de ecrã 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, o processo noturno cumpre os prazos da Política de Privacidade para os dados dos Clientes e apaga os dados remanescentes sem domínio associado do período anterior (cfg/fristen_lib.php). Mantêm-se em aberto duas vias sem limite temporal: as verificações internas e os 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 o crawler foi tratado por uma firewall de forma diferente de um visitante. Para um operador cujo sítio web circula publicamente como “Exposto”, trata-se de uma questão de reputação. O relatório indica, por isso, o método, mostra provas e assinala os limites de uma verificação a partir do exterior.

Resultado quanto à proporcionalidade: A verificação de sítios web de terceiros e próprios é, na forma implementada, essencialmente proporcional. Em três pontos há necessidade de melhoria que pode ser resolvida por meios comuns e para a qual estão previstas medidas (secção 9.3): as capturas de ecrã da página inicial, as verificações internas sem limite temporal e o início de sessão não cifrado na análise atrás do início de sessão. A verificação de entrega é proporcional quanto à cópia de teste e à verificação de autenticidade; quanto às mensagens reais de visitantes, só o é enquanto o seu conteúdo não for guardado, a via através do fornecedor da caixa de correio estiver contratualmente assegurada e o Cliente informar os seus visitantes. Hoje, falta o segundo destes três pontos.

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

O que é avaliado é o risco para os titulares dos 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 um estado medido. A gravidade é classificada como limitada, significativa, grave ou muito grave, consoante o que a pessoa possa perder: a confidencialidade da sua mensagem, o controlo sobre uma conta, a sua reputação profissional, a possibilidade de exercer um direito. O nível resulta de ambas e descreve o estado atual com as medidas da secção 9.1.

N.º	Risco	Operação de tratamento	Probabilidade	Gravidade	Nível
R1	Mensagens reais de visitantes na cópia de controlo, incluindo possíveis categorias especiais	P6	Concretizada uma vez ativada	Grave	Elevado
R2	Via da cópia de controlo através do fornecedor da caixa de correio sem contrato celebrado e com possível ligação a países terceiros	P6	Provável enquanto faltar o contrato	Grave	Elevado
R3	Capturas de ecrã de sítios web de terceiros sem ocultação	P1–P4	Provável	Limitada	Médio
R4	Dados de verificação e capturas de ecrã sem via de eliminação	P3, verificações internas	Concretizada	Significativa	Elevado
R5	Verificação e classificação pública de sítios web de terceiros sem o conhecimento do operador; utilização abusiva 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 prova de controlo nunca é renovada	P4, P5	Possível	Significativa	Médio
R8	Credenciais e conteúdos na análise atrás do início de sessão	P5	Possível	Grave	Médio; elevado para contas reais
R9	Submissões de teste ativas e verificação de ficheiros no sítio web do Cliente	P4	Remota	Significativa	Baixo
R10	Classificação por um modelo de linguagem	P1–P4	Remota	Limitada	Baixo
R11	Lista de bloqueio partilhada a partir de comunicações de muitos sítios web	P7	Possível	Limitada	Baixo a médio; elevado com redes IP
R12	Relatórios e capturas de ecrã numa ligação pública	P1, P2, P4	Possível	Limitada	Baixo
R13	Fragilidades de infraestrutura: cópias de segurança, acesso aos servidores, servidor de análise	todas	Possível	Grave	Elevado
R14	Direitos dos titulares dos dados para pessoas que não nos conhecem	P1–P6	Provável	Limitada	Baixo

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

Este é o risco mais grave do serviço, e resulta não de um erro, mas da conceção. Uma cópia oculta no formulário não distingue entre a nossa mensagem de teste e a mensagem de um visitante. Se um Cliente ativar a verificação de entrega, cada mensagem enviada através desse formulário chega à nossa caixa de correio de controlo (cfg/zustellung_lib.php). A recolha lê para a memória os cabeçalhos e os primeiros 8 KB do texto, para procurar o nosso identificador de teste (cfg/zustellung_lib.php). Num formulário de contacto comum, isso significa nome, endereço de e-mail, número de telefone e a mensagem completa.

O que o visitante escreve depende dele, e o campo convida a conteúdos pessoais: um pedido de consulta a um consultório médico com a descrição de sintomas, a exposição de um litígio a um escritório de advogados, uma candidatura a emprego, uma pergunta sobre uma criança a uma escola. Os nossos documentos jurídicos dizem que as cópias “não devem conter categorias especiais de dados pessoais”. Trata-se de um pedido ao Cliente, não de uma medida de proteção: nem ele nem nós sabemos de antemão o que um visitante vai escrever.

Há duas vias secundárias associadas a isto. Primeiro, a verificação de autenticidade guarda o domínio do endereço do remetente associado ao domínio (cfg/zustellung_lib.php). Se o formulário enviar com o endereço do visitante como remetente, este é o domínio do visitante – sem significado no caso de um grande fornecedor de correio, mas um dado pessoal no caso de um particular com domínio próprio. Este domínio surge também no alerta enviado ao Cliente e aos canais por ele escolhidos (cfg/zustellung_lib.php). Segundo, guarda o endereço do servidor de correio emissor (cfg/zustellung_lib.php); em regra, trata-se do servidor do sítio web, não do visitante.

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

R2 – Via da cópia de controlo através do fornecedor da caixa de correio sem contrato celebrado

Antes de a nossa recolha ver uma cópia de controlo, esta encontra-se na caixa de correio em Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. Só chega lá se os registos MX do nosso domínio apontarem diretamente para esta caixa de correio; o reencaminhamento no registador de domínios Namecheap, Inc. não é uma etapa das cópias de controlo (através de reencaminhamento, não chegam à caixa de correio). Para a etapa que resta, as disposições contratuais estão ainda em aberto: o contrato com o fornecedor da caixa de correio não foi celebrado, os seus locais de armazenamento, subcontratantes e prazos de cópias de segurança não foram apurados, e está em aberto se, para o seu local de tratamento, é necessária e aplicável uma decisão de adequação ou cláusulas contratuais-tipo. Para os nossos próprios e-mails transacionais, trata-se de uma questão de conceção contratual. Para as cópias de controlo é mais grave: aí trata-se de dados que recebemos enquanto subcontratante, e cada prestador de serviços ao longo da via é um subcontratante ulterior pelo qual respondemos nos termos do Art. 28(4).

Além disso, “eliminado após a recolha” aplica-se apenas à nossa vista da caixa de correio. Não foi verificado se o fornecedor mantém os e-mails eliminados nas suas próprias cópias de segurança ou num lixo, nem durante quanto tempo. Se uma recolha for interrompida, os e-mails mantêm-se até à execução bem-sucedida seguinte (cfg/zustellung_lib.php); se o processo de estado falhar, mantêm-se indefinidamente. Por último, a segurança da própria recolha é um dos pontos a verificar no sistema de produção antes do lançamento (secção 9.3).

Probabilidade – provável enquanto faltar o contrato: cada cópia de controlo segue esta via. Gravidade – grave, pelas mesmas razões que no R1. Nível – elevado. A lista de verificação de configuração da aplicação comunica a falta da caixa de correio como aviso; não existe nenhum bloqueio que impeça a verificação de entrega sem contrato documentado.

R3 – Capturas de ecrã de sítios web de terceiros sem ocultação

O crawler faz uma captura de ecrã 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 percursos de navegador é diferente: aí, os campos de introdução são mascarados antes da captura de ecrã (scanner/src/browser.js). Assim, só as imagens dos percursos de navegador são “limpas”, não as do crawler nem a imagem da página de resposta de uma verificação ativa.

Como o crawler não escreve nada, os campos do formulário estão vazios. No entanto, a página inicial de uma pequena empresa mostra frequentemente o proprietário, a equipa, testemunhos de clientes com nomes e fotografias, ou uma janela de chat com a imagem de um colaborador. Tudo isto é público; a captura de ecrã transforma-o numa cópia que é guardada por nós, surge no relatório e pode ser transmitida com a ligação.

Probabilidade – provável. Foram medidas 432 capturas de ecrã 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 representadas não têm conhecimento e a imagem da página inicial não é necessária para a constatação.

R4 – Dados de verificação e capturas de ecrã sem via de eliminação

O processo noturno elimina verificações por duas vias: através da data de expiração de um relatório (cfg/check_lib.php) e através do prazo para verificações de um domínio de Cliente (cfg/fristen_lib.php, apenas para verificações com domínio). Uma verificação que não tenha relatório nem domínio escapa a ambas as redes. Trata-se das verificações com o nível de confiança “interno”: estudos e verificações que o prestador cria a partir da linha de comandos.

• Os estudos eliminam os seus dados brutos aquando da publicação (cfg/studie_lib.php). Se um estudo nunca for publicado – porque tem demasiado poucos sítios web com formulário (cfg/studie_lib.php recusa então a publicação) ou porque fica esquecido – as verificações, formulários, constatações e capturas de ecrã mantêm-se sem limite temporal.
• As verificações internas a partir da linha de comandos não têm qualquer via de eliminação. Medido em 11 de outubro de 2026: 85 verificações deste tipo de sítios web de terceiros, com 978 formulários e 369 capturas de ecrã, a mais antiga de 22 de setembro de 2026, nenhuma com relatório ou domínio.
• As anotações sobre comportamento anómalo na verificação gratuita contêm o endereço IP e são eliminadas 90 dias após a sua resolução (srv/cron_status.php). Uma anotação que nunca seja resolvida mantém-se. Medido: três anotações, 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 aplica-se no sistema de produção. Gravidade – significativa: não existe prazo de conservação para estes dados. No que respeita ao princípio da limitação da conservação (Art. 5(1)(e)), trata-se de um ponto em aberto com uma medida prevista (secção 9.3, prioridade “primeira”), e afeta precisamente pessoas que nada sabem da verificação. As verificações internas estão descritas nos Registos das Atividades de Tratamento; a Política de Privacidade ainda não as menciona separadamente (secção 9.4). Nível – elevado.

R5 – Verificação e classificação pública de sítios web de terceiros sem o conhecimento do operador

Qualquer pessoa pode mandar verificar qualquer sítio web acessível ao público, sem conta e sem qualquer ligação a ele. O operador não é notificado. O resultado é um relatório que classifica o sítio web como “Exposto”, “Parcialmente protegido” ou “Protegido” e que qualquer pessoa com a ligação pode ver. São concebíveis duas consequências para os titulares dos dados. Um empresário em nome individual recebe publicamente uma classificação – ainda que apenas para os destinatários da ligação – que pode ser uma constatação errada. E o relatório mostra a um spammer que formulário pode ser preenchido sem obstáculos.

Contra isso existe uma série de bloqueios (cfg/check_lib.php): no máximo uma verificação por domínio em sete dias, depois disso o mesmo relatório; limites por endereço IP e sessão; um limite diário para todo o serviço; nenhuma verificação de domínios muito recentes, típicos de abusos; uma anotação e um sinal em caso de comportamento anómalo; robots.txt e opt-out, verificados duas vezes (cfg/check_lib.php e no serviço de verificação). O relatório gratuito é um excerto: mostra apenas as constatações básicas, não as provas de todos os detetores. E não diz nada que um bot não conseguisse descobrir sozinho em segundos – um formulário desprotegido é visível do exterior.

Probabilidade – possível. Gravidade – significativa para um empresário em nome individual cujo formulário seja visado após um relatório ou cuja classificaçã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 forma de “abrir a porta à primeira conversa”. A forma como a agência utiliza a constatação breve cabe à agência decidir; tecnicamente, pode também enviá-la a um operador que não a pediu. Não contactamos ninguém (cfg/akquise_lib.php), e os Termos de Serviço obrigam a agência a cumprir as regras sobre publicidade e prospeção comercial. Um e-mail não solicitado com a constatação é, no entanto, comercialização direta mesmo entre empresas, que na Polónia (Art. 398 da Lei das 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)) exige consentimento prévio. A interface não alerta para isto; os textos da verificação de potenciais clientes falam apenas de “passiva” e de “lista de opt-out”.

Probabilidade – provável, porque a função serve a angariação de clientes e não podemos verificar se o destinatário deu o seu consentimento. Gravidade – limitada: para o operador, é um e-mail de marketing incómodo com uma classificação do seu sítio web. Nível – médio. O risco reside na conduta da agência; como a função provém de nós, está previsto um aviso na interface (secção 9.3).

R7 – A prova de controlo nunca é renovada

As submissões de teste ativas, a pesquisa de ficheiros expostos e a análise atrás do início de sessão exigem que o Cliente tenha provado que tem o direito de controlar o domínio. Esta prova é verificada uma vez (cfg/verify_lib.php) e nunca mais. Não existe no código nenhuma via pela qual um domínio perca a sua prova. Se o domínio mudar de proprietário, se uma agência terminar o seu mandato ou se o operador remover o registo DNS, as verificações continuam – até diariamente, com até cinco submissões de teste e, se estiver guardado, com o início de sessão de uma conta de teste de que o novo operador pode não ter conhecimento. Em contrapartida, não é possível transferir a prova para outro anfitrião por mudança de nome: o nome de anfitrião de um domínio com prova de controlo não pode ser alterado.

Probabilidade – possível: as mudanças de domínio e de mandato são ocorrências quotidianas para as agências. Gravidade – significativa para o novo operador e os seus trabalhadores, que recebem mensagens de teste assinaladas e cujo sítio web é pesquisado em busca de ficheiros expostos sem o seu consentimento. Nível – médio. As mensagens de teste explicam-se a si próprias e remetem para a página do crawler e para o opt-out; o opt-out funciona também contra verificações por Clientes.

R8 – Credenciais e conteúdos na análise atrás do início de sessão

A cifragem das credenciais está cuidadosamente implementada: o servidor web deixa de as poder ler após o armazenamento, a base de dados e a cópia de segurança contêm apenas texto cifrado, o registo está vinculado ao seu domínio, as credenciais só entram no contentor através da entrada padrão e são depois apagadas da memória (secção 6.5). Restam duas lacunas; um terceiro ponto diz respeito apenas à leitura, não ao armazenamento.

• É permitido o início de sessão não cifrado. A verificação do endereço permite http a par de https (cfg/login_lib.php, scanner/src/login.js). Se o Cliente indicar uma página de início de sessão com http, o nome de utilizador e a palavra-passe circulam pela internet em texto simples em cada verificação.
• Os erros de certificado não interrompem o início de sessão. O início de sessão não é atualmente interrompido quando o certificado do sítio do Cliente é inválido (scanner/src/login.js). O certificado não protege, por isso, totalmente as credenciais no caminho até ao sítio do Cliente. Está prevista a interrupção em caso de erros de certificado (secção 9.3, prioridade “primeira”).
• Os valores de campos ocultos atrás do início de sessão são lidos, não guardados. O crawler 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 início de sessão (scanner/src/login.js). Aí, os campos ocultos contêm frequentemente um número de conta, um identificador de utilizador ou o endereço de e-mail da conta com sessão iniciada; no entanto, só o nome do campo, o tipo, a etiqueta e o resultado da deteção entram no mapa de campos e nas constatações.

A isto acresce o que o código não pode impedir: o Cliente confirma que está a utilizar uma conta de teste com o mínimo de direitos possível (cfg/login_lib.php), mas pode introduzir uma conta de administrador real. As páginas que o scanner lê são então determinadas pelo Cliente; os endereços que contenham palavras relativas a terminar sessão e eliminar são bloqueados, mas outras ações que um sítio web desencadeie através de um simples pedido não o são.

Probabilidade – possível. Gravidade – grave se for afetada uma conta com amplos direitos; a área de membros com os dados de todos os utilizadores fica então aberta. Nível – médio para uma conta de teste com poucos direitos, elevado para uma conta real. Medido no sistema de desenvolvimento, não está guardada nenhuma conta de teste.

R9 – Submissões de teste ativas e verificação de ficheiros no sítio web do Cliente

Uma submissão de teste chega às pessoas que leem os e-mails de formulário do Cliente – os seus trabalhadores ou um prestador de serviços. Não contém dados pessoais: o remetente é dummy@formexposed.com, o texto e o assunto estão assinalados e indicam o identificador da verificação (scanner/src/active.js). O risco reside numa classificação errada: se o scanner tomasse um formulário de candidatura, de reserva ou de aconselhamento por um formulário de contacto, a mensagem de teste iria parar a um processo com consequências. Contra isso existem as regras estritas para “submetível” (scanner/src/classify.js), o bloqueio para 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 desta decisão (scanner/src/classify.js). Da resposta são guardados o estado, o endereço de destino, o título, 300 caracteres de texto e uma imagem; dizem respeito à nossa mensagem de teste.

A verificação de ficheiros lê no máximo 8 KB de caminhos típicos. Se um dump de base de dados estiver realmente exposto aí, estes 8 KB podem conter dados introduzidos por visitantes em formulários. São apenas verificados quanto a uma assinatura e descartados (cfg/dateien_lib.php); o que é guardado é o caminho, o tipo e a gravidade.

Probabilidade – remota. Gravidade – significativa. Nível – baixo. Medido no sistema de desenvolvimento, existe uma verificação ativa no conjunto de dados, sem nenhuma submissão aceite.

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 de texto do formulário (scanner/src/classify.js). Isto pode incluir um nome, por exemplo “A sua pessoa de contacto: …”. Funciona no nosso próprio servidor; no código, nada segue para terceiros. Não foi verificado se o software do modelo regista os pedidos. O seu resultado determina apenas o tipo de formulário apresentado e não pode tornar um formulário submetível; uma classificação errada leva a uma constatação pior, não a uma ação.

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

R11 – Lista de bloqueio partilhada a partir de comunicações de muitos sítios web

Um domínio na lista faz com que as mensagens com ligações para ele vão parar à quarentena em todos os sítios web ligados. Se o domínio pertencer a um particular – um artesão, um fotógrafo, um blogue – as suas mensagens com uma ligação para o seu próprio sítio web chegam tarde aos destinatários. Um domínio deste tipo pode entrar na lista porque spammers o utilizam abusivamente, ou porque alguém envia deliberadamente a vários sítios web mensagens que falham a verificação e o contêm.

Contra isso existem (cfg/swarm_lib.php): um mínimo de três sítios web 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 através de uma ferramenta no servidor; quarentena em vez de eliminação; a lista é reconstruída diariamente, e o que deixar de ser comunicado é retirado. Os afetados não podem ver a lista e não dispõem de via própria para exigir a remoção, a não ser através de nós.

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

R12 – Relatórios e capturas de ecrã numa ligação pública

Os relatórios da verificação gratuita, da verificação de potenciais clientes e das verificações de domínios de Clientes podem ser consultados sem iniciar sessão numa ligação aleatória. A ligação contém 128 bits de aleatoriedade e não pode ser adivinhada (cfg/check_lib.php). As páginas têm noindex, a aplicação envia uma política de referência que transmite apenas a origem (www/.htaccess), e as capturas de ecrã só são entregues juntamente com o relatório a que pertencem; outro número de imagem devolve “não encontrado” (www/shot.php). O risco não é criptográfico, mas humano: uma ligação é transmitida, copiada para um ticket, partilhada num chat. Quem a abre só fica registado no registo de acessos a páginas, como qualquer visualização de página (60 dias), no qual a própria ligação surge apenas de forma mascarada; não existe uma lista de leitores por relatório.

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

R13 – Fragilidades de infraestrutura

Os pontos seguintes constam como em aberto no nosso dossiê de revisão interno e não são aqui atenuados. Descrevemo-los com a precisão de que os Clientes necessitam para a sua própria avaliação, mas não com tanta precisão que a descrição indique o caminho a um atacante; forneceremos os pormenores a uma autoridade de controlo mediante pedido.

• As cópias de segurança da base de dados estão atualmente guardadas no mesmo local que a base de dados e não estão cifradas separadamente; está prevista uma cópia cifrada num segundo local (cfg/backup_lib.php). Até lá, não protegem contra a perda do local, e quem obtiver a base de dados obtém também as cópias de segurança. As credenciais para a análise atrás do início de sessão só constam delas como texto cifrado.
• Sem cifragem da base de dados em repouso. As exceções são os campos cifrados individualmente (credenciais das contas de teste, segredo de dois fatores).
• As ligações dentro da nossa rede interna não são cifradas em toda a extensão.
• Administração dos servidores. A segurança do acesso administrativo aos nossos servidores ainda não cumpre o padrão que pretendemos para o funcionamento; o reforço da administração dos servidores prossegue.
• Ambiente de verificação. O servidor de análise abre sítios web de terceiros num navegador. Os contentores de verificação estão isolados – rede própria, sem privilégios especiais, só de leitura, limitados (scanner/src/worker.js). A separação entre o ambiente de verificação e as restantes partes do serviço está a ser reforçada (secção 9.3).

Probabilidade – possível. Gravidade – grave, porque, numa emergência, tudo seria afetado de uma só vez. Nível – elevado. Os pontos individuais podem ser resolvidos por meios comuns (secção 9.3).

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

Quem surge acidentalmente numa captura de ecrã ou cuja mensagem passou por uma cópia de controlo normalmente não sabe que existimos. Mesmo que saiba, não tem nenhuma chave para os “seus” dados: não os guardamos por pessoa, mas por domínio e verificação. Só podemos responder a um pedido de acesso nos termos do Art. 15 se a pessoa indicar o domínio; podemos então percorrer as verificações e imagens existentes. Quanto às mensagens reais de visitantes, não há nada a divulgar, porque não as guardamos – exceto o domínio do remetente referido no R1. O opt-out só funciona para operadores de um domínio, não para pessoas representadas; para estas, resta a via através de contact@lukaswojcik.com.

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

9. (d) Medidas para fazer face aos riscos

Cada medida tem um estado, e os estados não são decorativos. Implementado hoje – verificado significa: lido no código do sistema de desenvolvimento e, quando possível, medido face à base de dados. Parcial significa: o mecanismo existe, mas ainda não cumpre totalmente a sua finalidade. Previsto significa: proposto por esta avaliação e não implementado; se e quando, decide o proprietário. Ainda por determinar são procedimentos e decisões que nenhum código substitui. Uma AIPD que apresente medidas previstas como implementadas perde o seu valor precisamente na situação em que é necessária.

9.1 Implementado hoje – verificado

Medida	Aborda	Referência de origem
O robots.txt é lido pelo crawler antes de cada verificação; uma exclusão que abranja a página inicial, um robots.txt inacessível ou um erro de servidor terminam a verificação (os subcaminhos não são observados individualmente; o pulso, a obtenção da prova, a ferramenta de cabeçalhos e a pesquisa de ficheiros não o leem)	R5, licitude	scanner/src/net.js
Opt-out sem prova, com efeito imediato, para o domínio e a sua variante www, para verificações anónimas, potenciais clientes, estudos e verificações de Clientes (a monitorização em curso termina com a próxima verificação agendada); verificado duas vezes (aplicação e serviço de verificação); levantado apenas por nós, mediante pedido e com prova	R5, R7, Art. 21	cfg/check_lib.php; cfg/akquise_lib.php; cfg/studie_lib.php; scanner/src/worker.js
Verificação gratuita: paragem de emergência, reCAPTCHA, uma verificação por domínio e semana, limites por endereço IP e sessão, limite diário, nenhum domínio recente, apenas endereços públicos, anotação e sinal sem conteúdo em caso de anomalias	R5	cfg/check_lib.php
Para os limites, a sessão é guardada apenas como valor de hash, nunca o identificador de sessão	Minimização	cfg/check_lib.php
Sem valores de campos (os inícios de campos ocultos e de atributos de dados só são lidos durante a verificação, secção 6.2); endereços de destinatários apenas como domínio; identificadores de conta em endereços de scripts ocultados	Minimização	scanner/src/crawl.js
O relatório gratuito é um excerto: apenas constatações básicas, sem provas de todos os detetores	R5	cfg/check_lib.php, FE_FREE_DETEKTOREN
Relatórios numa ligação aleatória de 128 bits, noindex, imagens apenas para o próprio relatório, fora do diretório web público; a ligação só surge de forma mascarada no registo de acessos a páginas	R12	cfg/check_lib.php; www/report.php; www/shot.php
Eliminaçã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), os dados de um domínio eliminado de imediato (para as exceções, ver a secção 6.11), em cada caso juntamente com as imagens	Limitação da conservação	cfg/check_lib.php; cfg/fristen_lib.php
Estudo: publicação apenas como total, segmentos apenas a partir de 20 sítios web com formulário, dados brutos eliminados aquando da publicação	R4 em parte, P3	cfg/studie_lib.php
Contentores de verificação: rede própria isolada, sem privilégios especiais, só de leitura, limites de memória e de processos, limite de tempo; filtro contra destinos privados em cada pedido, service workers bloqueados e ligações WebSocket fechadas para que nada contorne o filtro; pedidos do servidor web apenas em portas web e apenas exatamente para o endereço público previamente verificado	R13	scanner/src/worker.js; scanner/src/net.js
Verificação ativa para Clientes apenas para um domínio verificado (internamente também para os nossos próprios domínios de teste e de demonstração) e com a paragem de emergência ativada, verificado duas vezes; no máximo cinco submissões; apenas formulários de contacto 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 libertar nada; mensagem de teste sem dados pessoais, assinalada, com referência à página do crawler e ao opt-out	R9	scanner/src/worker.js; scanner/src/classify.js; scanner/src/active.js
Percursos de navegador: apenas GET e HEAD, endereços perigosos bloqueados, valores fictícios não saem do navegador, imagens com campos de introdução ocultados	R3 (para estas imagens), R9	scanner/src/browser.js
Verificação de ficheiros: apenas domínios verificados, uma consulta por caminho, no máximo 8 KB, conteúdo nunca guardado	R9	cfg/dateien_lib.php
Segunda sonda: desativada por defeito; receberia apenas uma lista fixa de elementos inofensivos, assinada	Destinatários	cfg/formular_probe_lib.php
Análise atrás do início de sessão: apenas domínio verificado, plano pago, proprietário ou administrador, confirmação de “conta de teste”; cifragem com a chave pública do servidor de análise, vinculada ao domínio; credenciais nunca apresentadas, registadas ou devolvidas através da API; entrega apenas através da entrada padrão; campo na tarefa apagado de imediato, restos após uma hora; sem capturas de ecrã, sem submissões, sem endereços de terminar sessão ou de eliminação, interrupção perante CAPTCHA; eliminação definitiva com substituição	R8	cfg/login_lib.php; scanner/src/login.js; scanner/src/geheim.js; scanner/src/worker.js
Verificação de entrega: desativada por defeito; a recolha lê apenas os cabeçalhos e 8 KB, sem marca de leitura; conteúdo e endereço do visitante nunca na base de dados; cada e-mail recolhido é eliminado, incluindo os que não podem ser associados; correspondências eliminadas após 180 dias; prova apenas através da cópia exatamente deste teste	R1, R2	cfg/zustellung_lib.php
Proteção em enxame: apenas domínios, redes IP desativadas; números mínimos; exceções para grandes serviços e domínios de Clientes; quarentena em vez de eliminação; lista reconstruída diariamente; comunicações eliminadas após 30 dias	R11	cfg/swarm_lib.php
Modelo de linguagem no nosso próprio servidor, sem direito de submeter	R10	scanner/src/classify.js
Os sinais através do Telegram contêm apenas uma frase fixa sem variáveis	Destinatários	cfg/check_lib.php
Teste de restauro semanal da cópia de segurança, com alerta em caso de falha	Disponibilidade	cfg/backup_lib.php; srv/cron_status.php

9.2 Parcial – existente, mas ainda sem cumprir a sua finalidade

Medida	Porque ainda não é totalmente eficaz
Capturas de ecrã “limpas”	Só as imagens dos percursos de navegador são ocultadas. As imagens do crawler – página inicial e elementos de formulário – e a imagem da página de resposta de uma verificação ativa não o são (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; anotações de anomalias não resolvidas sem limite temporal (R4).
Eliminação das cópias de controlo	Eficaz na nossa vista da caixa de correio. Se a execução for interrompida, os e-mails mantêm-se; não foi verificado o que o fornecedor da caixa de correio mantém nas suas próprias cópias de segurança (R2).
Proteção das credenciais na análise atrás do início de sessão	Forte em repouso e no serviço de verificação; não no caminho até ao sítio web: http é permitido, os erros de certificado são ignorados (R8).
Prova de controlo	É verificada uma vez e aplica-se depois para sempre; o nome de anfitrião de um domínio com prova de controlo não pode, no entanto, ser alterado, para que a prova não passe para outro anfitrião (R7).
Informação aos titulares dos dados	Existente para os operadores através da página do crawler, do identificador, da Política de Privacidade e do opt-out; para os visitantes na verificação de entrega, depende de o Cliente adotar o bloco de texto; a aplicação não verifica isso.
Pedido aos Clientes para não colocarem categorias especiais na cópia de controlo	Indicado nos documentos jurídicos, mas sem apoio técnico: durante a configuração, a aplicação não pergunta pelo tipo de sítio web nem avisa perante domínios que pareçam relacionados com saúde, direito ou educação (R1).

9.3 Previsto – não implementado

Medida	Aborda	Prioridade
Via de eliminação para verificações internas: eliminar verificações sem domínio e sem relatório após um prazo fixo (proposta: 30 dias); eliminar os dados brutos de um estudo, o mais tardar, um prazo fixo após a sua conclusão, mesmo sem publicação (proposta: 90 dias); eliminar uma vez as 85 verificações existentes com 369 imagens	R4	Primeira
Ativar a verificação de entrega apenas quando o contrato com o fornecedor da caixa de correio tiver sido celebrado, os locais de armazenamento, os subcontratantes e os prazos das cópias de segurança tiverem sido documentados, o mecanismo de transferência para o fornecedor da caixa de correio tiver sido esclarecido e os registos MX do nosso domínio apontarem diretamente para a caixa de correio; até lá, manter a função bloqueada no sistema de produção	R2	Primeira
Verificar a segurança da recolha da caixa de correio no sistema de produção e documentá-la antes de a verificação de entrega ser ativada	R2	Primeira
Análise atrás do início de sessão apenas através de https e com certificado válido; rejeitar endereços http; erros de certificado no início de sessão como motivo de interrupção	R8	Primeira
Não guardar os valores de campos ocultos atrás do início de sessão (apenas nome, tipo e comprimento) – já implementado desta forma, sem passo adicional	R8	Concluído
Limitar a cópia de controlo a mensagens de teste quando o plugin ou a extensão estiverem em utilização: cópia oculta apenas para submissões com o nosso identificador de teste	R1	Alta
Não guardar o domínio do remetente de mensagens reais nem o incluir em alertas se não for o domínio do sítio web nem o de um serviço de envio conhecido; no alerta, em vez disso, “domínio de remetente externo”	R1	Alta
Aviso ao configurar a verificação de entrega para domínios que pareçam relacionados com saúde, direito, serviços sociais ou educação, com referência à AIPD própria do Cliente	R1	Alta
Renovar regularmente a prova de controlo (proposta: antes de cada verificação ativa, verificar se o registo DNS, a meta tag, o ficheiro ou a ligação do plugin continuam a existir; 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 do formulário (como hoje) e mascarar os campos de introdução como nos percursos de navegador	R3	Alta
Aviso na interface da verificação de potenciais clientes: enviar a constatação breve sem solicitação por e-mail ou telefone é comercialização direta mesmo entre empresas e exige consentimento prévio (Art. 398 da Lei polaca das Comunicações Eletrónicas; na Alemanha § 7(2) UWG, embora para chamadas a empresas baste o consentimento presumido)	R6	Alta
Infraestrutura: concluir o reforço da administração dos servidores; cópia cifrada da cópia de segurança num segundo local; cifrar as ligações na rede interna em toda a extensão; reforçar a separação entre o servidor de análise e a aplicação	R13	Alta
Prazo para anotações de anomalias não resolvidas (proposta: resolução no prazo de 30 dias, caso contrário eliminação do endereço IP)	R4	Média
Uma página ou um formulário através do qual alguém possa pedir a remoção de um domínio da proteção em enxame	R11, R14	Média
Antes de ativar as redes IP na proteção em enxame: uma nova versão desta avaliação	R11	Condição
Registar se o software do modelo de linguagem guarda os pedidos e, em caso afirmativo, desativar esses registos	R10	Baixa

9.4 Procedimentos e decisões ainda por determinar

Para além das salvaguardas técnicas, o Art. 35(7)(d) exige também procedimentos. Estão ainda pendentes:

• Violação de dados pessoais. Deteção: o proprietário, o alerta de erros da aplicação, comunicações através do ponto de comunicação de vulnerabilidades ou de contact@lukaswojcik.com. Decisão sobre a notificação à UODO no prazo de 72 horas (Art. 33(1)): o proprietário. Informação aos Clientes afetados enquanto responsáveis pelo tratamento: sem demora injustificada, se possível no prazo de 48 horas, conforme prometido no Acordo de Tratamento de Dados. Por determinar: uma descrição escrita do procedimento e um primeiro exercício; para a verificação de entrega, adicionalmente, a forma de apurar que Clientes são afetados por uma violação no fornecedor da caixa de correio.
• Setores. Por determinar: se a verificação de entrega é oferecida, oferecida com aviso ou excluída para sítios web das áreas da saúde, do direito, dos serviços sociais e da educação.
• Verificações internas. Por determinar: para que utiliza o prestador as verificações internas a partir da linha de comandos, quem as pode criar e durante quanto tempo se mantêm os seus resultados; e se, para além dos Registos das Atividades de Tratamento, devem ser mencionadas na Política de Privacidade.
• Estudos. Por determinar: quem compila as listas, a partir de que fontes, com que dimensão máxima, e uma verificação antes de cada estudo quanto ao cumprimento dos pressupostos desta avaliação.
• Opiniões dos titulares dos dados (Art. 35(9)). Não foram recolhidas para esta versão. O Art. 35(9) só exige que sejam recolhidas “se for adequado”; no nosso entender, não é atualmente o caso. Os operadores de sítios web verificados e os visitantes de sítios web de Clientes não dispõem de um canal próprio para nos contactar; dirigirmo-nos especificamente a eles seria, por si só, um novo tratamento dos seus dados, e o serviço ainda não foi lançado, pelo que ainda não existe um grupo de titulares de dados efetivos. Os seus interesses são tidos em conta indiretamente: através do robots.txt e do opt-out, dos prazos curtos e do facto de o conteúdo das cópias de controlo não ser guardado. Em cada revisão nos termos da secção 12, reconsideramos se a recolha das suas opiniões é adequada, por exemplo através de feedback na página do crawler ou dos Clientes da verificação de entrega.

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

O Art. 36(1) exige a consulta prévia da autoridade de controlo quando a AIPD indicar que o tratamento resultaria num elevado risco na ausência das medidas tomadas pelo responsável pelo tratamento para atenuar o risco. A questão não é, portanto, se foram identificados riscos elevados – foram quatro – mas se subsiste um risco elevado uma vez aplicadas as medidas.

Para as operações de tratamento em que formexposed é o responsável pelo tratamento (P1 a P4, P7), os riscos elevados R4 e R13 podem ser resolvidos por meios comuns: uma via de eliminação e uma limpeza dos dados existentes, uma cópia de segurança cifrada noutro local e o reforço de dois servidores. Com as medidas de 9.3, descem para baixo a médio. R3, R5, R6 e R7 estão em médio e descem para baixo com as medidas propostas. A proteção em enxame sem redes IP mantém-se em baixo a médio. A consulta prévia não é necessária para esta parte se as medidas assinaladas como “primeira” e “alta” forem implementadas antes do lançamento. Se alguma destas medidas não tiver sido implementada antes do lançamento, subsiste um risco elevado para a operação de tratamento em causa. Essa operação de tratamento só será então iniciada depois de a medida ter sido implementada, ou a UODO será previamente consultada nos termos do Art. 36(1).

Para a verificação de entrega (P6), a situação é diferente, por uma razão que nenhuma medida elimina totalmente: o que um visitante escreve depende dele. Com um contrato celebrado, recolha protegida, limitação a mensagens de teste quando possível e prescindindo do domínio do remetente, o R2 desce para baixo e o R1 para médio. Para Clientes cujos visitantes forneçam tipicamente dados abrangidos pelo Art. 9, o R1 pode, no entanto, continuar elevado. A obrigação de consulta cabe então ao Cliente enquanto responsável pelo tratamento, não a formexposed. A nossa recomendação a esses Clientes é que não configurem a cópia de controlo para o formulário de contacto geral, mas apenas para formulários sem conteúdo sensível, ou que prescindam da verificação de entrega.

Risco residual, dito com honestidade. Hoje, com as medidas de 9.1, quatro riscos estão em elevado: R1 e R2 (verificação de entrega), R4 (dados de verificação sem via de eliminação) e R13 (infraestrutura). Com as medidas de 9.3, R2, R4 e R13 descem para baixo a médio. O R1 mantém-se em médio e depende permanentemente de decisões tomadas pelos Clientes. Nenhum dos outros riscos fica acima de médio após as medidas.

O Art. 36 não é uma sanção, e consultar não é uma confissão. É a via que o Regulamento prevê para a situação em que um procedimento útil comporta um risco que o responsável pelo tratamento não controla totalmente. Um Cliente que pretenda utilizar a verificação de entrega para mensagens com dados de saúde encontrará aqui os factos para essa decisão.

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

Na verificação de entrega e na análise atrás do início de sessão, o Cliente é o responsável pelo tratamento. Esta página fornece-lhe a descrição (secções 6.5 e 6.6), os riscos na nossa perspetiva (R1, R2, R8) e o estado das medidas (secção 9). Só o Cliente pode responder às seguintes questões:

1. O que escrevem os meus visitantes? É de esperar que cheguem através do formulário dados sobre saúde, religião, origem, filiação sindical, orientação sexual, infrações penais ou sobre crianças? Nesse caso, é em regra necessária uma AIPD para a cópia de controlo, e a cópia de controlo para este formulário deve ser reconsiderada.
2. Preciso da cópia de controlo para todas as mensagens? Para provar que a nossa mensagem de teste chega, basta para essa mensagem. Quando o formulário o permita, defina a cópia oculta apenas para mensagens de teste.
3. Como informo os meus visitantes? O Acordo de Tratamento de Dados exige-o; o Texto de Política de Privacidade para o seu Sítio Web descreve a via da cópia e a nossa função.
4. Que fundamento jurídico tenho? A nossa proposta de texto indica o Art. 6(1)(f) (receção fiável de pedidos). Para dados abrangidos pelo Art. 9, este fundamento, por si só, não é suficiente.
5. Que canais de alerta escolho? Os alertas da verificação de autenticidade podem indicar o domínio do remetente. Quem enviar alertas para serviços de chat fora da UE transfere-o para lá.
6. Para a análise atrás do início de sessão: A conta de teste é realmente uma conta de teste com os direitos mínimos necessários? A página de início de sessão só é acessível através de https? A conta de teste vê dados de outros utilizadores? Se sim: em quais das páginas indicadas?
7. Quando elimino? A verificação de entrega e a conta de teste podem ser desativadas e eliminadas a qualquer momento; a conta de teste é então definitivamente substituída.

Outros documentos para a avaliação do Cliente: o Acordo de Tratamento de Dados, as medidas técnicas e organizativas, a lista de subcontratantes e os Registos das Atividades de Tratamento. Respondemos a questões sobre factos concretos através de 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 em conformidade com a AIPD, pelo menos quando haja uma alteração do risco. Revemos esta avaliação pelo menos anualmente e também antes de cada um dos seguintes eventos; cada um desencadeia uma nova medição, não apenas uma leitura:

• início do funcionamento 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 fornecedor da caixa de correio;
• ativação das redes IP na proteção em enxame;
• o primeiro estudo, e cada estudo com uma lista maior do que a anterior;
• ativação da segunda sonda ou de um novo destinatário no percurso de verificação;
• qualquer nova utilização do modelo de linguagem que vá além da classificação de formulários e do “Fix it for me”;
• qualquer alteração às capturas de ecrã, aos prazos ou às condições prévias para verificações ativas.

Elemento	Descrição
Responsável pelo tratamento	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 controlo 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 secção 4
Base dos factos	Código-fonte da aplicação e do serviço de verificação, esquema da base de dados, contagens de linhas e definições do sistema de desenvolvimento, medidos em 11 de outubro de 2026, apenas em modo de leitura
Documentos relacionados	Política de Privacidade, Acordo de Tratamento de Dados, Medidas Técnicas e Organizativas, Subcontratantes, Registos das Atividades de Tratamento, Regulamento da UE sobre IA, Utilização Aceitável e Abusos, FormExposedBot, Opt-out
Versão	1.0 de 11 de outubro de 2026, primeira versão
Revisões nos termos do Art. 35(11)	Ainda nenhuma (primeira versão). Cada revisão é aqui registada com data, motivo e resultado.
Aprovação	Ainda não aprovado. Aprovação pelo proprietário após a revisão jurídica e após uma decisão sobre as medidas da secção 9.3 e as questões da secção 9.4. Até ao momento, não foi solicitado aconselhamento externo em matéria de proteção de dados.

Uma observação final pertence ao documento e não a uma carta de acompanhamento. As partes de formexposed que mais avançam em domínios alheios – as submissões de teste e o início de sessão com credenciais de terceiros – são as construídas com mais cautela: duas barreiras, limites rígidos, cifragem que nos impede até a nós próprios de aceder. Os riscos desta avaliação situam-se sobretudo noutro lado: no que vem por arrasto – mensagens reais numa cópia oculta, pessoas numa captura de ecrã, verificações que já ninguém elimina. É um ponto de partida favorável, porque o acessório pode ser travado sem alterar o serviço.