Evaluación de Impacto relativa a la Protección de Datos (art. 35 del RGPD)

Este documento se publica en varios idiomas. En caso de discrepancia entre las versiones lingüísticas, la versión polaca es vinculante.

Versión 1.1 · Última actualización: 23 de octubre de 2026

1. De qué trata esto y qué es esta página

Esta página es la evaluación de impacto relativa a la protección de datos (EIPD) de formexposed conforme al art. 35 del RGPD. Primero responde a la pregunta preliminar de si se requiere una EIPD, para cada operación de tratamiento por separado, no para el servicio en su conjunto. Cuando la respuesta es sí, realiza la evaluación conforme al art. 35, apartado 7, letras a) a d): una descripción sistemática, necesidad y proporcionalidad, los riesgos para los interesados y las medidas para afrontarlos. A continuación se presentan el riesgo residual, la cuestión de la consulta previa conforme al art. 36 y las reglas de revisión.

El art. 35 no exige que se publique una EIPD. La publicamos por dos motivos. Primero, los Clientes que utilizan la verificación de entrega o el escaneo detrás del inicio de sesión necesitan para su propia evaluación hechos que solo nosotros conocemos; en cualquier caso, les debemos estos hechos como encargados del tratamiento (art. 28, apartado 3, letra f), del RGPD). Segundo, nuestro rastreador verifica sitios web cuyos operadores no nos conocen. Deben poder leer qué riesgos vemos para ellos y para las personas de sus páginas y qué hacemos al respecto.

Naturaleza jurídica. Esta EIPD es documentación del responsable del tratamiento conforme al art. 35 del RGPD que publicamos voluntariamente. No forma parte de ningún contrato ni constituye declaración, garantía o acuerdo sobre la calidad frente a Clientes o terceros. Los servicios y garantías que debemos a los Clientes se rigen por las Condiciones del Servicio, el Acuerdo de Tratamiento de Datos y sus anexos; respecto de estas obligaciones, prevalecen sobre esta página. La página describe la situación a la fecha de esta versión. Las calificaciones y evaluaciones de riesgos son nuestra propia opinión y no anticipan ninguna valoración jurídica de una autoridad de control o un tribunal; las medidas descritas como «previstas» son intenciones sin fecha comprometida. Para los Clientes, la página es una base para su propia evaluación, no asesoramiento jurídico.

Esta es la primera versión de la evaluación de umbral. Examina, operación por operación de tratamiento, si se requiere una EIPD y registra el resultado en la sección 3.5.

Cada afirmación de hecho está sujeta al mismo principio que en nuestros otros documentos legales: medido, no meramente previsto. Lo respaldado por el código o la base de datos se indica aquí con su referencia de fuente. Lo que no pudo respaldarse se marca como «no verificado». Lo meramente previsto se denomina «previsto». Identificamos abiertamente los puntos pendientes, junto con la medida prevista; una EIPD que solo enumera fortalezas no ayuda a las personas a las que concierne.

Términos: un operador es quien opera un sitio web verificado. Un Cliente tiene una cuenta en formexposed. Un visitante es quien utiliza el sitio web de un Cliente, por ejemplo, su formulario de contacto. Una referencia de fuente significa un archivo, función o ajuste en el código fuente, contrastado con el estado del sistema de desarrollo del 11 de octubre de 2026.

Deliberadamente establecemos un límite a la transparencia: los puntos pendientes de seguridad de nuestros propios servidores solo se describen en términos generales (R13). Indicamos el riesgo y su nivel, pero no la vía hacia una vulnerabilidad específica; proporcionaremos los detalles a una autoridad de control previa solicitud.

2. Roles: quién tiene la obligación y respecto de qué

El art. 35 impone la obligación al responsable del tratamiento. formexposed es responsable del tratamiento para algunas operaciones, encargado para sus Clientes para otras y ninguna de las dos cosas para los datos que nuestro plugin de WordPress y nuestra extensión de TYPO3 almacenan en el sitio web de un Cliente. La respuesta a casi todas las preguntas de este documento depende del rol sobre el que se pregunte. La asignación sigue la Política de Privacidad y el Acuerdo de Tratamiento de Datos.

Operación de tratamiento	Rol de formexposed	Quién tiene la obligación del art. 35
Verificación de sitios web de terceros sin instrucciones de su operador: verificación gratuita, verificación de clientes potenciales para agencias, estudio	Responsable del tratamiento	formexposed
Verificación de dominios en la cuenta del Cliente: monitoreo, envíos de prueba activos, recorridos con navegador, archivos expuestos, pulso de formularios	Responsable del tratamiento de los datos de cuenta y verificación del Cliente; encargado para datos personales de terceros visibles en el sitio web verificado del Cliente; mientras un dominio no esté verificado, responsable del tratamiento como en la verificación gratuita	formexposed para su propia parte; el Cliente para los datos de terceros en su sitio web
Escaneo detrás del inicio de sesión con cuenta de prueba	Encargado del tratamiento: las credenciales y el contenido detrás del inicio de sesión pertenecen al sitio web del Cliente	El Cliente; formexposed ayuda
Verificación de entrega con copia de control	Encargado del tratamiento	El Cliente; formexposed ayuda
Protección colectiva: lista compartida de dominios de enlaces de spam bloqueado	Responsable del tratamiento: combinamos las comunicaciones de muchos sitios web, elaboramos la lista y la distribuimos	formexposed
Cuentas de cliente, inicio de sesión, registros, soporte, envío de correo, pagos, registros probatorios	Responsable del tratamiento	formexposed
Portal de clientes e informe mensual a suscriptores de una agencia	Encargado del tratamiento	La agencia
Datos que el plugin y la extensión almacenan en el sitio web del Cliente (cuarentena, rescate de correos, consultas almacenadas)	Ninguna de las dos: los datos nunca salen del sitio web	El operador del sitio web

Esto lleva a una distinción que indicamos expresamente porque a menudo se interpreta mal en ambos sentidos. Cuando formexposed es responsable del tratamiento, realizamos la evaluación nosotros mismos y asumimos su resultado. Cuando somos encargados, no podemos realizar la evaluación del Cliente en su lugar, decidir por él sobre su necesidad ni consultar a la autoridad de control conforme al art. 36 en su nombre. Lo que podemos y debemos hacer allí es proporcionarle todo lo que necesita: la descripción de la letra a), los hechos medidos sobre los riesgos de la letra c) y una lista honesta del estado de las medidas de la letra d). Para la verificación de entrega y el escaneo detrás del inicio de sesión, esta página es exactamente eso.

Un Cliente que adopta sin cambios las secciones sobre la verificación de entrega como su propia EIPD no ha realizado una. Si la copia de control está justificada para sus formularios, si cabe esperar categorías especiales de datos personales en ellos y cómo informa a sus visitantes son cuestiones que solo él puede decidir. La sección 11 resume lo que debe aclararse para este fin.

3. Evaluación de umbral: ¿se requiere una EIPD?

3.1 Art. 35, apartado 1, y art. 35, apartado 3

El art. 35, apartado 1, exige una EIPD cuando es probable que un tipo de tratamiento, en particular si utiliza nuevas tecnologías, teniendo en cuenta la naturaleza, el alcance, el contexto y los fines del tratamiento, entrañe un alto riesgo para los derechos y libertades de las personas físicas. El art. 35, apartado 3, menciona tres casos en los que esto ocurre en particular. Ninguno de los tres se ajusta a formexposed, y esto debe razonarse en lugar de afirmarse:

Letra a): una evaluación sistemática y exhaustiva de aspectos personales relativos a personas físicas que se base en un tratamiento automatizado y sobre cuya base se tomen decisiones que produzcan efectos jurídicos o les afecten significativamente de modo similar. Evaluamos formularios y sitios web, no aspectos personales de las personas. El servicio no toma ninguna decisión con efectos jurídicos sobre ninguna persona. Lo más cercano es la protección colectiva: los mensajes que contienen un enlace a un dominio incluido en la lista terminan en la cuarentena de los sitios web conectados. Es una consecuencia automatizada para el mensaje, no una evaluación exhaustiva de una persona; la tratamos bajo el criterio «Evaluación o puntuación» en la sección 3.3.
Letra b): tratamiento a gran escala de categorías especiales conforme al art. 9 o de datos relativos a infracciones penales conforme al art. 10. No está previsto ni implementado. Sin embargo, esos datos pueden llegarnos por una vía: en la copia de control de mensajes auténticos de visitantes en la verificación de entrega. Esto depende del caso concreto y no es a gran escala en el sentido de esta disposición; no obstante, se tiene en cuenta en la evaluación de riesgos (R1).
Letra c): observación sistemática a gran escala de una zona de acceso público. Esto significa la observación física de lugares, no la recuperación de páginas web públicas. Citar esta disposición como fundamento para un rastreador de sitios web sería incorrecto.

Por tanto, la vía correcta es el propio art. 35, apartado 1, aplicado mediante los nueve criterios de las Directrices del Grupo de Trabajo del Artículo 29 sobre la Evaluación de Impacto relativa a la Protección de Datos (WP248 rev.01, refrendadas por el Comité Europeo de Protección de Datos) y la lista de la autoridad de control polaca conforme al art. 35, apartado 4 (sección 3.4).

3.2 Los nueve criterios de las directrices WP248

Las directrices mencionan nueve características que indican un probable alto riesgo. Como regla orientativa, una operación de tratamiento que cumpla dos de ellas requerirá en la mayoría de los casos una EIPD. Un responsable del tratamiento puede llegar a otra conclusión en un caso concreto, pero debe entonces motivarla y documentarla. A la inversa, un solo criterio puede bastar. En esta página utilizamos las siguientes etiquetas breves:

C1 – Evaluación o puntuación, incluida la elaboración de perfiles y la predicción, por ejemplo, del rendimiento laboral, la situación económica, la confiabilidad o el comportamiento.
C2 – Toma de decisiones automatizadas con efectos jurídicos o efectos significativos similares.
C3 – Observación sistemática, es decir, tratamiento utilizado para observar, monitorear o controlar a los interesados, también mediante redes. Las directrices justifican expresamente este criterio por el hecho de que los interesados a menudo desconocen quién recopila sus datos y con qué finalidad.
C4 – Datos sensibles o de naturaleza muy personal: categorías especiales conforme a los arts. 9 y 10, pero también datos cuya divulgación afecte significativamente a la vida diaria, incluidas comunicaciones electrónicas cuya confidencialidad debe protegerse.
C5 – Datos tratados a gran escala, medida según el número de interesados, el volumen y la variedad de datos, la duración y el alcance geográfico.
C6 – Cotejo o combinación de conjuntos de datos procedentes de distintas operaciones de tratamiento o de distintos responsables, de una forma que los interesados no esperarían.
C7 – Datos relativos a interesados vulnerables, por ejemplo, empleados, menores, pacientes u otras personas en una situación de desequilibrio de poder.
C8 – Uso innovador o aplicación de nuevas soluciones tecnológicas u organizativas; en la práctica de supervisión, el uso de inteligencia artificial se considera habitualmente comprendido en este criterio.
C9 – Tratamiento que impide a los interesados ejercer un derecho o utilizar un servicio o un contrato.

Calificamos cada criterio como «cumplido», «caso límite» o «no cumplido» y fundamentamos la calificación a partir del código. Un caso límite no cuenta como cumplido en el total, pero se menciona en el resultado; cuando varios casos límite apuntan en la misma dirección, incluimos la operación de tratamiento en la evaluación.

3.3 Evaluación por operación de tratamiento

P1 – Verificación gratuita sin cuenta (verificación de cualquier sitio web de terceros a solicitud)

Cualquier persona puede ingresar un dominio en la página de inicio. El rastreador recupera entonces como máximo ocho páginas públicas de ese sitio web, lee los formularios, toma capturas de pantalla y genera un informe que puede ver cualquiera que conozca su enlace aleatorio. El operador del sitio web no se entera de ello salvo que detecte el identificador del rastreador en sus registros.

C1 – caso límite. El informe valora la protección de un formulario con un nivel («Expuesto», «Parcialmente protegido», «Protegido») y una puntuación. Para una sociedad de responsabilidad limitada, esto no concierne a una persona física. Para empresarios individuales y profesionales independientes, el dominio puede atribuirse a la persona y el nivel dice entonces algo sobre el cuidado aplicado en su actividad profesional. Sin embargo, lo que se evalúa es una configuración técnica, no el comportamiento ni las características de una persona. Lo tratamos como caso límite.
C2 – no cumplido. No se decide nada respecto del operador. Respecto de la persona que solicita la verificación, se aplican límites por dirección IP y sesión (cfg/check_lib.php); una verificación rechazada no tiene un efecto significativo.
C3 – no cumplido. Es una recuperación individual a solicitud, como máximo una vez por dominio y semana (cfg/check_lib.php, ajuste fc_domain_days = 7). No se observa a personas. Sin embargo, está presente la circunstancia que las directrices citan para justificar C3: los interesados no saben nada del tratamiento. Se tiene en cuenta en la evaluación de riesgos (R5).
C4 – no cumplido. Lo que se almacena es la estructura del formulario y los hallazgos, no los valores ingresados (scanner/src/crawl.js almacena solo la longitud de un valor para campos visibles). El escáner lee el inicio de los campos ocultos rellenados previamente (hasta 24 caracteres) y de los atributos de datos (hasta 60 caracteres) solo durante la verificación para detectar tokens y marcas de tiempo; no se almacenan. Las capturas de pantalla pueden mostrar personas y nombres de forma incidental; el sitio web de un consultorio médico muestra su especialidad en la imagen. Son datos profesionales públicos, no datos de salud de una persona concreta.
C5 – caso límite. El límite diario es de 200 verificaciones aceptadas (fc_daily_cap), es decir, aritméticamente hasta unos 73,000 sitios web al año. Solo surgen unos pocos datos personales por sitio web y la duración es corta (30 días). Medido en el sistema de desarrollo, hay 2 verificaciones anónimas en el conjunto de datos. No se cumple hoy; es un caso límite considerando la capacidad diseñada.
C6 – no cumplido. Además de recuperar las páginas, el servicio consulta la antigüedad del dominio mediante el servicio RDAP rdap.org (solo se transmite el nombre de dominio; solo se almacena la fecha de registro, en caché) y resuelve DNS. Son detalles técnicos sobre el dominio, no una combinación de conjuntos de datos sobre personas.
C7 – no cumplido.
C8 – cumplido, de forma débil. Un navegador automatizado verifica las páginas y un modelo de lenguaje en nuestro propio servidor clasifica formularios que las reglas no reconocen (scanner/src/classify.js). El modelo ve el título de la página, la dirección, las etiquetas de campos y hasta 400 caracteres de texto del formulario. Nunca puede hacer que un formulario quede «autorizado para envío».
C9 – no cumplido.

Resultado provisional P1: un criterio de forma débil (C8), dos casos límite (C1, C5). Sin obligación conforme a la regla orientativa. Como ambos casos límite apuntan en la misma dirección y los interesados no saben nada del tratamiento, incluimos P1 en la evaluación.

P2 – Verificación de clientes potenciales para agencias

Una agencia del plan Business con su propia marca configurada puede solicitar una verificación pasiva del sitio web de un cliente potencial. Recibe un hallazgo breve bajo su marca y un informe detallado y comparte el enlace por sí misma (cfg/akquise_lib.php). No contactamos a nadie.

C1 – caso límite, más fuerte que para P1. El hallazgo breve está destinado expresamente a «abrir la puerta a la primera conversación». La evaluación del sitio web se convierte así en la base para dirigirse comercialmente a una persona.
C5 – no cumplido. Como máximo 30 verificaciones por agencia y mes (prospect_monthly), eliminadas después de 90 días.
C8 – cumplido, de forma débil (la misma tecnología que P1).
Los demás criterios – no cumplidos. El hallazgo se presenta con la marca de la agencia, pero no se vincula con otros datos sobre el operador.

Resultado provisional P2: sin obligación conforme a la regla orientativa; incluido por los mismos motivos que P1 y porque la finalidad —captación de clientes— conlleva un riesgo propio (R6).

P3 – Estudio «Índice de Seguridad de Formularios»

Para un estudio, se verifica pasivamente una lista de sitios web, con un límite de como máximo cinco trabajos abiertos por ejecución del proceso de estado, que se ejecuta cada cinco minutos (cfg/studie_lib.php). Solo se publican totales y segmentos solo a partir de 20 sitios web con formulario (study_min_segment, cfg/studie_lib.php). Los datos sin procesar se eliminan al publicar (cfg/studie_lib.php).

C5 – caso límite, cumplido para listas grandes. El tamaño de la lista no está limitado en el código; la limitación permite aritméticamente más de mil verificaciones al día. Un estudio de un mercado nacional abarca miles de sitios web, muchos de ellos operados por empresarios individuales. A partir de ese tamaño, consideramos cumplido el criterio.
C8 – cumplido, de forma débil.
C1 – no cumplido. Aunque se valora el sitio web individual, solo se publica el total; la valoración no sirve para hacer una afirmación sobre el operador individual.
Los demás criterios – no cumplidos.

Resultado provisional P3: para estudios del tamaño diseñado, dos criterios (C5, C8). Por tanto, el estudio alcanza el umbral; formexposed realiza la evaluación como responsable del tratamiento. Medido en el sistema de desarrollo, hasta ahora no se ha creado ningún estudio.

P4 – Verificación de dominios en la cuenta del Cliente

El Cliente solicita verificaciones periódicas de los dominios de su cuenta. Una vez que ha demostrado que tiene derecho a ejercer control sobre el dominio, se agregan envíos de prueba activos (como máximo cinco por verificación), la búsqueda de archivos expuestos y recorridos con navegador configurados.

C3 – no cumplido. La verificación es programada y periódica, pero se refiere al propio sitio web del Cliente y se realiza a su solicitud, no para observar personas.
C4 – caso límite, no. La búsqueda de archivos expuestos lee como máximo los primeros 8 KB de rutas como /backup.sql o un registro de depuración para determinar a partir del contenido si el archivo está realmente expuesto (cfg/dateien_lib.php). Un extracto de ese tipo puede contener datos de formularios ingresados por visitantes. Se comprueba solo en memoria y nunca se almacena; lo que se almacena es la ruta, el tipo y la gravedad.
C8 – cumplido, de forma débil.
Los demás criterios – no cumplidos.

Etapa de plan de acción agregada. Los informes de pago elegibles pueden contener texto orientativo generado localmente a partir de hallazgos seleccionados y metadatos del escaneo. Se almacena con la verificación y se muestra con un aviso de IA; los hallazgos individuales siguen siendo la referencia vinculante. No modifica automáticamente sitios web ni toma decisiones con efectos jurídicos o de importancia similar sobre personas. El uso de un modelo de lenguaje por sí solo no determina si se requiere una EIPD independiente. Sus datos de entrada, destinatarios, escala y riesgos residuales deben evaluarse con la verificación subyacente, incluida la posible repetición de datos personales procedentes de URL o notas y recomendaciones incorrectas en un informe que puede compartirse mediante enlace. Las secciones 7 a 9 siguientes incluyen esta etapa; este complemento factual no afirma ninguna medición en producción completada, aprobación del propietario ni nueva calificación del riesgo residual.

Resultado provisional P4: La verificación técnica subyacente no alcanza el umbral según los hechos descritos anteriormente. La etapa orientativa local agregada no establece por sí sola una obligación independiente, pero el resultado anterior del umbral no sustituye el examen de sus datos de entrada reales, escala, destinatarios y efectos. Se incluye porque los envíos de prueba activos y la verificación de archivos dependen de una prueba que nunca se renueva (R7).

P5 – Escaneo detrás del inicio de sesión

Para un dominio verificado, el Cliente puede almacenar una cuenta de prueba de su sitio web. El escáner inicia sesión con ella y lee los formularios de hasta cinco páginas especificadas del área de miembros (cfg/login_lib.php, scanner/src/login.js).

C4 – caso límite. Las credenciales no son datos de naturaleza muy personal en el sentido de las directrices, pero su uso indebido abre el área de miembros. Según el sitio web, detrás de un inicio de sesión puede haber contenido confidencial, por ejemplo, en un portal de miembros o pacientes. Esto depende del Cliente, no de nosotros.
C8 – no cumplido. Los inicios de sesión automatizados son habituales en los servicios de monitoreo.
Los demás criterios – no cumplidos.

Resultado provisional P5: sin obligación conforme a la regla orientativa. Para los Clientes cuya área de miembros muestra contenido confidencial, esto puede cambiar; la decisión les corresponde entonces a ellos. Se incluye por los riesgos de seguridad (R8).

P6 – Verificación de entrega con copia de control

El Cliente incluye una dirección de control de formexposed como copia oculta en la configuración de correo de su formulario. Como resultado, cada correo del formulario también llega a nuestro buzón de control: tanto nuestro mensaje de prueba como cada mensaje auténtico de un visitante. Una recuperación automatizada lee los encabezados y los primeros 8 KB, asigna el correo, evalúa SPF, DKIM y DMARC y lo elimina (cfg/zustellung_lib.php).

C4 – cumplido. Lo que escriben los visitantes en un formulario de contacto es comunicación electrónica a una empresa con contenido arbitrario. En el sitio web de un consultorio médico, un despacho jurídico, un servicio de asesoramiento o una escuela cabe esperar datos del art. 9 o sobre menores. Las directrices mencionan expresamente las comunicaciones electrónicas confidenciales bajo este criterio.
C3 – caso límite, más bien cumplido. Cada mensaje se copia de forma planificada y continua y se evalúa automáticamente, sin que el remitente lo note. La finalidad es verificar la ruta de correo, no observar personas. Sin embargo, la circunstancia con la que las directrices justifican el criterio —los interesados no saben quién recibe sus datos— está plenamente presente mientras el Cliente no informe a sus visitantes.
C7 – según el Cliente. Pacientes, clientes de despachos jurídicos, solicitantes de empleo, padres y alumnos suelen encontrarse en una relación de dependencia frente al destinatario de su mensaje.
C5 – caso límite, no. No es a gran escala para el Cliente individual. En formexposed, las copias de muchos Clientes convergen en un buzón; esto aumenta la importancia de una violación de seguridad, no el número por responsable del tratamiento.
Los demás criterios – no cumplidos. La asignación al dominio y a la prueba no es un cotejo de conjuntos de datos sobre personas; la tecnología no es nueva.

Resultado provisional P6: C4 cumplido, C3 como caso límite y más bien cumplido, C7 cumplido para muchos Clientes típicos. En la configuración típica, por tanto, se cumplen dos o más criterios. Se requiere una EIPD, como obligación del Cliente, que es responsable del tratamiento. Las secciones 6 a 11 le proporcionan los hechos para ello.

P7 – Protección colectiva

Los sitios web de WordPress conectados comunican una vez al día los dominios de enlaces de mensajes que su capa de protección ha detenido. Un dominio que aparece en al menos tres sitios web distintos con al menos cinco coincidencias dentro de siete días se incorpora a una lista compartida; la lista se devuelve a todos los sitios web conectados, que entonces colocan en cuarentena los mensajes con enlaces a ese dominio (cfg/swarm_lib.php).

C6 – cumplido. Se combinan comunicaciones de muchos sitios web mutuamente independientes, es decir, de distintos responsables del tratamiento, y se devuelven a todos ellos como lista compartida.
C1 – cumplido, en la medida en que un dominio pueda atribuirse a una persona física. La lista es una clasificación como fuente de spam. Las directrices mencionan la comprobación contra una base de datos compartida de fraude como ejemplo de este criterio. La mayoría de los dominios de una lista de este tipo pertenecen a empresas o son dominios desechables; sin embargo, el dominio de una persona puede terminar en ella, correctamente o mediante comunicaciones falsas introducidas deliberadamente.
C9 – caso límite. Un mensaje con un enlace incluido en la lista no llega al destinatario de inmediato, sino que permanece en su cuarentena hasta que lo libera. No se pierde.
C2 – no cumplido. La cuarentena es una consecuencia automatizada para un mensaje, sin efecto jurídico y con liberación humana por el destinatario.
Los demás criterios – no cumplidos. Las redes IP están desactivadas (swarm_ip_enabled = 0, cfg/swarm_lib.php).

Resultado provisional P7: dos criterios (C6, C1) y un caso límite (C9). Se alcanza el umbral; formexposed realiza la evaluación como responsable del tratamiento. Con las redes IP activadas, C1 y C6 se cumplirían sin restricciones; activarlas requiere una nueva versión de esta evaluación (sección 12). Medido en el sistema de desarrollo, no hay comunicaciones ni entradas en la lista.

P8 – Cuentas de cliente, inicio de sesión, registros, soporte, correo electrónico, pagos

C1 y C9 – no cumplidos. El comportamiento llamativo en la verificación gratuita genera una nota con la dirección IP (cfg/check_lib.php) y, cuando corresponde, el rechazo de verificaciones adicionales. Es prevención del abuso con poco efecto, no una evaluación de aspectos personales.
Los demás criterios – no cumplidos. Son los datos habituales de un servicio para empresas.

Resultado provisional P8: no se requiere una EIPD. Las operaciones de tratamiento se describen en el Registro de Actividades de Tratamiento.

P9 – Cifras del plugin, errores de campos, grabador, insignia, portal de clientes, «Fix it for me»

El plugin y la extensión transmiten cifras diarias, el inventario de plugins y categorías de errores, y el plugin de WordPress transmite además dominios de enlaces para la protección colectiva (activada de forma predeterminada) (P7), ningún contenido, direcciones, nombres ni direcciones IP de visitantes; el grabador conserva selectores durante como máximo 15 minutos en el navegador del administrador. Ningún criterio cumplido.
Al cargarse, la insignia transfiere los datos de conexión habituales al registro del servidor web, sin cookie. Ningún criterio cumplido.
El portal de clientes trata direcciones de correo electrónico de suscriptores con doble confirmación por cuenta de la agencia. Ningún criterio cumplido.
«Fix it for me» hace que un modelo de lenguaje en nuestro propio servidor reescriba código de formulario pegado; el código no se almacena. C8 de forma débil, nada más.

Resultado provisional P9: no se requiere una EIPD.

3.4 La lista de la autoridad de control polaca conforme al art. 35, apartado 4

La autoridad competente es el Presidente de la Oficina de Protección de Datos Personales (Prezes Urzędu Ochrony Danych Osobowych, UODO). El Presidente publicó la lista de los tipos de operaciones de tratamiento que requieren una EIPD en la comunicación del 17 de junio 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, posición 666). La lista asigna sus entradas a los criterios de las directrices WP248, da ejemplos y es expresamente no exhaustiva; no sustituye la evaluación conforme al art. 35, apartado 1.

Según nuestra lectura, los siguientes tipos de tratamiento de la lista se corresponden en lo sustancial con operaciones de tratamiento de formexposed:

Tipo de tratamiento según la lista (parafraseado)	Criterio asignado	Operación de tratamiento en formexposed	Evaluación
Comparación, evaluación o inferencia basada en el análisis de datos de distintas fuentes	C6	P7 Protección colectiva	aplica
Evaluación o puntuación, incluida la elaboración de perfiles	C1	P7 Protección colectiva; P1 y P2 como casos límite	aplica a P7
Tratamiento de categorías especiales de datos personales	C4	P6 Verificación de entrega	aplica según el Cliente
Uso innovador o aplicación de soluciones tecnológicas	C8	P1 a P4 (modelo de lenguaje para clasificación)	aplica de forma débil
Tratamiento a gran escala	C5	P3 Estudio	aplica a listas grandes
Observación sistemática de lugares accesibles públicamente, incluido el reconocimiento de características	C3	–	no aplica: se refiere a lugares, no a sitios web

Esta asignación es una lectura, no una cita; el texto de las entradas debe contrastarse con ella en la revisión jurídica. Confirma el resultado de la sección 3.3, pero no lo modifica. Hasta donde sabemos, UODO no ha publicado una lista conforme al art. 35, apartado 5: operaciones de tratamiento para las que no se requiere una EIPD.

3.5 Resultado de la evaluación de umbral

Operación de tratamiento	Cumplidos	Casos límite	Resultado
P1 Verificación gratuita	C8 (débil)	C1, C5	no obligatoria; incluida
P2 Verificación de clientes potenciales	C8 (débil)	C1	no obligatoria; incluida
P3 Estudio	C8 (débil), C5 para listas grandes	–	requerida (obligación de formexposed)
P4 Verificación de dominios del Cliente	C8 (débil)	C4 (verificación de archivos)	no obligatoria; incluida
P5 Escaneo detrás del inicio de sesión	–	C4	no obligatoria; incluida; para el Cliente, según el contenido
P6 Verificación de entrega	C4; C7 según el Cliente	C3 (más bien cumplido), C5	requerida (obligación del Cliente; esta página ayuda conforme al art. 28, apartado 3, letra f))
P7 Protección colectiva	C6, C1	C9	requerida (obligación de formexposed)
P8 Cuentas, registros, soporte, pagos	–	–	no requerida
P9 Cifras del plugin, insignia, portal, «Fix it for me»	C8 (débil, solo «Fix it for me»)	–	no requerida

Resultado respecto del art. 35, apartado 1: Se requiere una EIPD para operaciones de tratamiento individuales de formexposed. Se requiere para la protección colectiva y para los estudios del tamaño diseñado, y formexposed la realiza como responsable del tratamiento. Para la verificación de entrega se requiere en la configuración típica, pero como obligación del Cliente; formexposed proporciona la base. Para las demás verificaciones de sitios web propios y de terceros no es obligatoria. Aun así las incluimos porque utilizan la misma tecnología, porque varios casos límite apuntan en la misma dirección y porque los interesados —operadores sin cuenta y personas en páginas verificadas— no saben nada del tratamiento. No se requiere evaluación para cuentas, registros, soporte y pagos.

Por tanto, las secciones 6 a 10 se aplican a P1 a P7. Cuando una afirmación se aplica solo a una de estas operaciones de tratamiento, se indica como tal.

4. Delegado de protección de datos: la evaluación conforme al art. 37

No se ha designado delegado de protección de datos. El art. 37, apartado 1, obliga por igual al responsable y al encargado del tratamiento; por tanto, la cuestión nos corresponde a nosotros. Los tres casos legales:

Art. 37, apartado 1	Condición	Resultado
letra a)	Autoridad u organismo público	No aplica; LW IT Solutions Company Lukas Wójcik es una empresa individual privada.
letra b)	Las actividades principales consisten en operaciones de tratamiento que requieren observación habitual y sistemática de interesados a gran escala	La actividad principal es la verificación y el monitoreo de sitios web y formularios, de manera habitual y sistemática. Sin embargo, no se monitorea a personas: el rastreador no observa comportamientos y la verificación de entrega evalúa los correos únicamente para la entrega y la autenticidad. No cumplido.
letra c)	Las actividades principales consisten en el tratamiento a gran escala de datos de los arts. 9 o 10	No por diseño. Pueden llegarnos categorías especiales mediante la copia de control de la verificación de entrega; esto es incidental, no una actividad principal. No cumplido.

Por tanto, según nuestra evaluación, no existe obligación de designarlo. Si el derecho polaco exige una designación adicional conforme al art. 37, apartado 4, es una cuestión pendiente para la revisión jurídica. Como no se ha designado delegado de protección de datos, no se aplica el asesoramiento del art. 35, apartado 2. Si la revisión jurídica determina que existe una obligación de designarlo, se solicitará el asesoramiento del delegado que se designe antes de aprobar esta evaluación (sección 12). La persona de contacto para preguntas sobre esta evaluación es el propietario en contact@lukaswojcik.com.

5. Método, fuentes y límites de esta versión

Los hechos de este documento provienen del código fuente de la aplicación y del escáner, del esquema de la base de datos y de los recuentos de filas y la configuración del sistema de desarrollo, medidos el 11 de octubre de 2026. Se accedió a la base de datos y los servidores en modo de solo lectura. Cuando una medición contradice una intención —incluida una afirmación de nuestros propios documentos legales—, informamos de la medición. No aplicamos códigos de conducta aprobados conforme al art. 40, cuyo cumplimiento tendría que tenerse en cuenta conforme al art. 35, apartado 8.

Se midió el sistema de desarrollo. El servicio aún no se ha lanzado. Por tanto, las cifras son pequeñas y en parte producto de las pruebas: 112 verificaciones, 110 de ellas sin dominio de un Cliente; 432 capturas de pantalla; 2 dominios, 1 de ellos verificado; ninguna verificación de entrega activada; ninguna cuenta de prueba almacenada para el escaneo detrás del inicio de sesión; ningún estudio; ninguna comunicación en la protección colectiva. Las mediciones deben repetirse antes del lanzamiento y a intervalos regulares después.
No se midieron en esta versión y deben agregarse antes de la aprobación: la configuración del sistema de producción, incluido si está configurado el buzón de control y cómo, y si el par de claves para el escaneo detrás del inicio de sesión está configurado allí; si el software del modelo de lenguaje registra solicitudes; el estado de la administración del servidor (R13); el contrato con el proveedor de servicios de correo electrónico.
No pudo medirse cuántos mensajes auténticos de visitantes pasarán por la copia de control y de qué sectores procederán los Clientes. Ambos factores determinan la importancia de R1 y R2 y deben establecerse después del lanzamiento.
Las referencias de fuente apuntan a archivos y funciones del código fuente del sistema de desarrollo. Lo decisivo es la función descrita, no su ubicación en el archivo.

Este documento es un borrador. Aún no ha sido aprobado por el responsable del tratamiento (sección 12), y dos de sus conclusiones —la evaluación de escala para P1 y P3 y la importancia de la verificación de entrega— dependen de cifras que solo existirán después del lanzamiento.

6. (a) Descripción sistemática de las operaciones de tratamiento y sus fines

6.1 Cómo está estructurado el sistema de verificación

formexposed funciona en sus propios servidores en Polonia, sin proveedor externo de alojamiento: un servidor web con la aplicación y la base de datos y un servidor de escaneo con el servicio de verificación y un modelo de lenguaje local, ambos en la misma red interna. Una verificación se desarrolla así:

La aplicación crea un trabajo en la base de datos, sujeto a los límites y bloqueos establecidos en la sección 6.3.
El servicio de verificación del servidor de escaneo recupera el trabajo, comprueba por segunda vez la lista de bloqueo, los nombres de host y, para las verificaciones anónimas, la antigüedad del dominio, e inicia un contenedor aislado exactamente para este trabajo: red propia con reglas de filtrado propias, sin privilegios especiales, sistema de archivos de solo lectura, límites de memoria y procesos y un límite de tiempo (scanner/src/worker.js).
Dentro del contenedor, un navegador automatizado recupera como máximo ocho páginas públicas, primero la página de inicio y después, preferentemente, páginas de contacto, aviso legal y soporte. Previamente lee robots.txt; una exclusión para FormExposedBot o para todos los rastreadores que abarque la página de inicio termina la verificación, al igual que un robots.txt inaccesible o un error del servidor al recuperarlo (scanner/src/net.js). Las prohibiciones para subrutas individuales no se observan por separado. El pulso de formularios, la recuperación de la prueba, la herramienta de encabezados y la búsqueda de archivos expuestos no leen robots.txt. Además de las ocho páginas, hay hasta tres páginas con un clic en «Rechazar» en el banner de cookies, hasta tres páginas en vista de celular, pruebas activas para dominios verificados y hasta cinco páginas detrás de un inicio de sesión; las páginas se cargan sucesivamente, no en paralelo. Cada solicitud del navegador —incluidas redirecciones y contenido incorporado— pasa por un filtro que rechaza redes privadas y otros puertos.
El contenedor escribe un resultado y las capturas de pantalla en un directorio temporal. El servicio de verificación transmite el resultado y las imágenes a la aplicación mediante la red interna y elimina el directorio temporal, incluso después de un error (scanner/src/worker.js).
La aplicación procesa el resultado, lo compara con la verificación anterior para dominios de Clientes e informa de los cambios a los destinos configurados por el Cliente.

6.2 Qué almacena el rastreador y qué no

Elemento	Qué se almacena	Qué no se almacena	Referencia de fuente
Páginas	Dirección, estado HTTP, encabezados, Política de Seguridad de Contenido, hosts de terceros solicitados (como máximo 120)	Contenido de la página como texto o HTML	`scanner/src/crawl.js`
Campos de formularios	Tipo, nombre, etiqueta, marcador de posición, campo obligatorio, visibilidad, longitud de un valor existente	Valores de campos; para los campos ocultos, los primeros 24 caracteres del valor solo se leen durante la verificación (para detectar tokens)	`scanner/src/crawl.js`
Direcciones de destinatarios en el formulario	solo el dominio	la dirección	`scanner/src/crawl.js`
Scripts	Inventario con suma de comprobación; direcciones y texto inicial sin identificadores de cuenta de servicios publicitarios y analíticos	Identificadores de cuenta y de píxeles	`scanner/src/crawl.js`
Herramientas que observan los datos ingresados	qué píxeles publicitarios y herramientas de grabación se cargan antes y después de hacer clic en «Rechazar» en el banner de cookies y si enmascaran los datos ingresados	Identificadores de las cuentas en estos servicios	`scanner/src/mitleser.js`, `scanner/src/einwilligung.js`
Texto del formulario	hasta 400 caracteres se envían al modelo de lenguaje local si las reglas no reconocen el tipo	Divulgación a terceros; almacenamiento del texto	`scanner/src/classify.js`
Capturas de pantalla (rastreador)	área visible de la primera página; para cada formulario visible, una imagen del elemento del formulario	–	`scanner/src/crawl.js`
Capturas de pantalla (verificación activa)	Imagen de la página de respuesta al envío de prueba; además, estado, dirección de destino, título y los primeros 300 caracteres de su texto	–	`scanner/src/active.js`
Capturas de pantalla (recorridos con navegador)	Imagen del formulario con campos de entrada cubiertos en negro, comprimida, como máximo 32 KB	Datos ingresados	`scanner/src/browser.js`
Detrás del inicio de sesión	como para los campos de formularios anteriores	Capturas de pantalla, cookies, enlaces	`scanner/src/login.js`

Estos elementos no contienen datos personales por diseño, pero sí de forma incidental: el nombre de una persona de contacto junto al formulario, una fotografía del equipo en la página de inicio, un número de teléfono en una etiqueta, el dominio de correo de una persona, un nombre en un marcador de posición. Detrás del inicio de sesión se agregan datos de la cuenta de prueba y, según el sitio web, de otros usuarios.

6.3 Quién inicia una verificación y qué se aplica entonces

Desencadenante	Nivel de confianza en el trabajo	Envíos de prueba	Resultado accesible mediante	Eliminación
Alguien ingresa un dominio en la página de inicio (verificación gratuita)	anonymous	no	Informe bajo un enlace aleatorio	30 días, incluidas imágenes (`cfg/check_lib.php`)
Plugin o extensión sin cuenta	plugin	no	Informe bajo un enlace aleatorio	30 días
Agencia para un cliente potencial	registered	no	Hallazgo breve e informe bajo un enlace aleatorio	90 días (`cfg/akquise_lib.php`)
Cliente, dominio sin prueba	registered	no	Cuenta; informe bajo un enlace aleatorio	13 meses, se conserva la última verificación
Cliente, dominio con prueba	verified	sí, como máximo cinco por verificación	Cuenta; informe bajo un enlace aleatorio	13 meses, se conserva la última verificación (`cfg/fristen_lib.php`)
Estudio	internal	no	solo totales después de la publicación	al publicar; sin publicación, sin límite de tiempo (R4)
Verificación interna desde la línea de comandos por el proveedor	internal; para nuestros propios dominios de prueba y demostración también «verified»	no; con el nivel «verified», sí (solo nuestros propios dominios de prueba y demostración)	solo interno	sin límite de tiempo (R4)

Varias capas preceden a la verificación gratuita (cfg/check_lib.php): una detención de emergencia; reCAPTCHA; el mismo dominio como máximo una vez en siete días (después se muestra el informe existente); límites por dirección IP, por sesión (como valor hash, nunca el propio identificador de sesión) y para todo el servicio por día; la lista de bloqueo de exclusión y robots.txt; la comprobación de que el dominio apunte a direcciones públicas; y un bloqueo para dominios muy recientes o de antigüedad desconocida. Las anomalías —muchos dominios distintos desde una dirección IP, muchas solicitudes en poco tiempo— se anotan con la dirección IP y generan una señal sin contenido (cfg/check_lib.php).

6.4 Verificación de dominios en la cuenta del Cliente

El Cliente demuestra que tiene derecho a ejercer control sobre un dominio: mediante un registro DNS, una metaetiqueta, un archivo o mediante nuestro plugin (cfg/verify_lib.php). Solo entonces el dominio se trata como verificado. El programador de monitoreo planifica verificaciones periódicas solo para dominios activos, monitoreados y verificados (cfg/monitor_lib.php).

Los envíos de prueba activos están sujetos a dos controles: la aplicación establece el modo activo para los Clientes solo para dominios verificados (para nuestros propios dominios de prueba y demostración, el proveedor puede crear una verificación con el nivel «verified» mediante una herramienta interna de línea de comandos), y el servicio de verificación vuelve a comprobar el nivel de confianza y la detención de emergencia fc_active_enabled (scanner/src/worker.js). Solo puede enviarse un formulario que las reglas reconozcan con alta certeza como formulario de contacto general, que no tenga campos obligatorios para datos personales reales y cuyo dominio no parezca una autoridad pública, institución educativa, clínica, consultorio médico, policía o tribunal (scanner/src/classify.js). El modelo de lenguaje no puede autorizar el envío de un formulario (scanner/src/classify.js). Se realizan como máximo cinco envíos por verificación (fc_active_max_posts), claramente identificados, con el remitente dummy@formexposed.com, una dirección bajo .invalid para probar la validación del correo electrónico y una línea de encabezado adicional inocua para detectar inyección de encabezados (scanner/src/active.js).
Los recorridos con navegador verifican recorridos de formularios configurados en un navegador hasta el punto justo anterior al envío. Solo se permiten solicitudes GET y HEAD; todo lo demás se aborta, al igual que las direcciones que contienen palabras para cerrar sesión, eliminar, comprar o pagar (scanner/src/browser.js). Para la verificación, los campos obligatorios se rellenan con valores inventados que nunca salen del navegador.
Los archivos expuestos se buscan semanalmente, solo para dominios verificados, con como máximo una recuperación por ruta, como máximo 8 KB y sin almacenar nunca el contenido (cfg/dateien_lib.php).
Una segunda prueba independiente está preparada y desactivada de forma predeterminada (browser_probe_enabled = 0). Si se activara, recibiría solo el dominio, la dirección, el selector, los pasos y la elección de navegador, nunca credenciales, capturas de pantalla ni datos de visitantes (cfg/formular_probe_lib.php).

6.5 Escaneo detrás del inicio de sesión

Requisitos previos: la función está configurada, el dominio está verificado y el Cliente tiene un plan de pago y es propietario o administrador del espacio de trabajo (cfg/login_lib.php); confirma que la cuenta es una cuenta de prueba con los menores derechos posibles (cfg/login_lib.php).

El nombre de usuario y la contraseña se cifran de inmediato en el servidor web con la clave pública del servidor de escaneo: una clave de un solo uso por registro (X25519), derivación de clave (HKDF-SHA256), AES-256-GCM, vinculados al dominio (cfg/login_lib.php). Solo el servicio de verificación del servidor de escaneo tiene la clave privada (scanner/src/geheim.js). Quien tenga el servidor web, la base de datos o una copia de seguridad solo tiene texto cifrado.
La interfaz solo muestra el primer carácter y la longitud del nombre de usuario (cfg/login_lib.php). Las credenciales nunca se muestran, nunca se registran en los registros ni se proporcionan mediante la API.
Para una verificación, la aplicación adjunta el texto cifrado al trabajo. El servicio de verificación lo descifra, borra de inmediato el campo del trabajo y transmite las credenciales al contenedor solo mediante la entrada estándar, nunca como argumentos de línea de comandos (scanner/src/worker.js). Los restos en trabajos abortados se borran mediante el proceso de estado después de una hora (cfg/login_lib.php).
Dentro del contenedor, el navegador inicia sesión. Aborta si la página de inicio de sesión redirige a otro host, si el formulario de inicio de sesión incluye un CAPTCHA (no eludimos CAPTCHA) o si sigue visible un campo de contraseña después del envío (scanner/src/login.js). Después borra el campo de contraseña de la memoria de la página y olvida las credenciales (scanner/src/login.js).
Lee como máximo cinco páginas del mismo dominio especificadas por el Cliente. Se bloquean las direcciones que contienen palabras para cerrar sesión, eliminar, quitar o cancelar (scanner/src/login.js). No se envía nada detrás del inicio de sesión, no se toman capturas de pantalla y las cookies y enlaces no pasan al resultado (scanner/src/login.js).
La eliminación es definitiva: el texto cifrado se sobrescribe con datos aleatorios de la misma longitud, la fila se elimina y los trabajos pendientes se borran (cfg/login_lib.php). Cuando se elimina el dominio, la fila desaparece automáticamente mediante una clave foránea.

6.6 Verificación de entrega

La verificación de entrega responde si un correo electrónico del formulario de contacto llega realmente y evalúa sus características de autenticidad. Es opcional, está desactivada de forma predeterminada y requiere un buzón de control configurado (cfg/zustellung_lib.php).

Si el Cliente la activa, el dominio recibe una etiqueta aleatoria. El Cliente incluye la dirección de control con esta etiqueta como copia oculta en su formulario.
A partir de entonces, cada correo del formulario también llega al buzón de control: nuestros envíos de prueba identificados y todos los mensajes auténticos de visitantes. Los correos van directamente al buzón en Namecheap, Inc. (Private Email), Phoenix, Arizona, USA —solo llegan si los registros MX de nuestro dominio apuntan allí; mediante reenvío, por ejemplo en el registrador de dominios Namecheap, Inc., no llegan al buzón— y permanecen allí hasta que se recuperan.
El proceso de estado recupera el buzón cada cinco minutos (srv/cron_status.php). Para cada correo electrónico, lee los encabezados y, como máximo, los primeros 8 KB del texto, sin marcarlos como leídos (cfg/zustellung_lib.php).
A partir de los encabezados determina la etiqueta y, por tanto, el dominio, y a partir del texto, cuando corresponde, el identificador de nuestra prueba (cfg/zustellung_lib.php). Se almacenan la hora, el dominio y, cuando corresponde, el identificador de prueba (cfg/zustellung_lib.php), durante 180 días (cfg/zustellung_lib.php).
A partir de los encabezados evalúa SPF, DKIM y DMARC y almacena el resultado con el dominio: los resultados de la verificación, el dominio de la dirección del remitente, los dominios de las firmas y la dirección del servidor de correo de envío (cfg/zustellung_lib.php). Si el resultado empeora, se envía al Cliente una sola vez una alerta que puede mencionar el dominio del remitente (cfg/zustellung_lib.php).
Después marca cada correo recuperado para su eliminación, incluido uno que no pudo asignarse a ningún dominio, y lo elimina del buzón al final de la ejecución (cfg/zustellung_lib.php). Si la ejecución se aborta antes, los correos permanecen hasta la siguiente ejecución correcta.
Solo la copia de exactamente la prueba en cuestión cuenta como prueba de entrega (cfg/zustellung_lib.php). Si no llega dentro de tres horas (delivery_wait_h), el servicio informa «Falta la entrega».

El texto de mensajes auténticos nunca se escribe en la base de datos, ni tampoco la dirección del visitante. Sin embargo, ambos se leen: la recuperación carga en memoria los primeros 8 KB de cada correo para buscar el identificador de prueba.

6.7 Protección colectiva

La capa de protección del plugin de WordPress detiene un mensaje como spam y cuenta los dominios de los enlaces que contiene. Una vez al día, el plugin nos comunica estos dominios con su número de coincidencias, como máximo 60 al día; sin direcciones, sin texto ni direcciones IP (cfg/swarm_lib.php).
Una vez al día elaboramos la lista a partir de ello: un dominio se incluye si ha sido comunicado dentro de siete días por al menos tres sitios web distintos y con al menos cinco coincidencias (swarm_min_sites, swarm_window_days, cfg/swarm_lib.php). Los grandes servicios de una lista fija de excepciones y los dominios de nuestros Clientes, en ambos casos incluidos los subdominios, nunca entran en la lista (cfg/swarm_lib.php).
La lista se envía a todos los sitios web conectados con la respuesta al informe diario. Su capa de protección coloca los mensajes con enlaces a dominios de la lista en la cuarentena, no en la papelera.
Lo que deja de aparecer en la nueva lista sale de ella; las comunicaciones se eliminan después de 30 días (cfg/swarm_lib.php).
Las redes IP (/24 o /48) están preparadas, pero desactivadas hasta que se complete la revisión jurídica (cfg/swarm_lib.php).

6.8 Uso de inteligencia artificial

Un modelo de lenguaje funciona en nuestro propio servidor de escaneo, no con un proveedor de IA. Se utiliza en tres lugares: en el servicio de verificación clasifica formularios cuyo tipo no reconocen las reglas; al hacerlo, ve el título de la página, la dirección de la página, las etiquetas de los botones de envío, los tipos, nombres, etiquetas y marcadores de posición de los campos y hasta 400 caracteres de texto del formulario (scanner/src/classify.js). Solo se le consulta si las reglas devuelven «desconocido»; los formularios clasificados de este modo nunca se envían y no cuentan para la puntuación ni el dictamen. La puntuación, el dictamen, la prevención del abuso, la protección colectiva y las reglas de spam son reglas fijas, no IA. En «Fix it for me», reescribe código de formulario pegado; el código no se almacena. Para verificaciones elegibles de dominios en cuentas de pago, también genera un plan de acción priorizado a partir del nombre de host, el resultado global y la puntuación, el CMS, el tipo de formulario pertinente y la dirección de la página, cualquier plugin identificado y hallazgos seleccionados fallidos o no concluyentes. La solicitud se almacena temporalmente en la cola interna de trabajos y se elimina después de su recogida o de la limpieza programada de entradas con más de una hora de antigüedad. El texto generado, el idioma, el estado y la marca de tiempo se conservan con el resultado del escaneo bajo sus reglas de conservación. El informe identifica el plan como resumen de IA y establece los hallazgos individuales como referencia vinculante; el plan no modifica el sitio web ni el resultado del escaneo. El modelo no toma decisiones sobre personas. Más información en la página Reglamento de IA de la UE: Cómo utiliza formexposed la IA.

6.9 Bases jurídicas

Operación de tratamiento	Base jurídica
P1 Verificación gratuita: verificación del dominio solicitado; límites y prevención del abuso	respecto de la persona solicitante, art. 6, apartado 1, letra b); respecto del operador y las personas representadas, art. 6, apartado 1, letra f); prevención del abuso, art. 6, apartado 1, letra f)
P2 Verificación de clientes potenciales	Art. 6, apartado 1, letra f) (interés legítimo de la agencia y de formexposed)
P3 Estudio	Art. 6, apartado 1, letra f)
P4 Verificación de dominios del Cliente	Art. 6, apartado 1, letra b), respecto del Cliente; para datos de terceros en su sitio web, las instrucciones del Cliente conforme al art. 28
P5 Escaneo detrás del inicio de sesión	Instrucciones del Cliente conforme al art. 28; base jurídica del Cliente
P6 Verificación de entrega	Instrucciones del Cliente conforme al art. 28; base jurídica del Cliente (en nuestro texto sugerido para Clientes, art. 6, apartado 1, letra f))
P7 Protección colectiva	Art. 6, apartado 1, letra f) (defensa conjunta contra el spam en muchos sitios web)

Nuestro interés legítimo en P1 a P3 consiste en mostrar a los operadores y sus prestadores de servicios las debilidades de sus formularios antes de que se exploten para spam o abuso y en prestar el servicio. Los datos proceden de fuentes accesibles públicamente. La ponderación de intereses se establece en la sección 7; si el art. 6, apartado 1, letra f), permite verificar sitios web de terceros a solicitud es una cuestión pendiente para la revisión jurídica.

6.10 Destinatarios y transferencias a terceros países

Destinatario	Qué	Operación de tratamiento	Estado
Nadie fuera de formexposed	Resultados de verificaciones, capturas de pantalla, clasificación por el modelo de lenguaje	P1–P5	El servicio de verificación y el modelo de lenguaje funcionan en nuestros propios servidores; en la ruta de verificación del rastreador no se encontró ninguna llamada a terceros salvo al propio sitio web verificado, a los servicios cuyo contenido incorpora (como con cualquier visitante) y al servicio RDAP rdap.org para la antigüedad del dominio (solo el nombre de dominio); las vigilancias de monitoreo se enumeran en la siguiente fila
Cualquier persona que conozca el enlace	Informe con hallazgos y capturas de pantalla	P1, P2, P4	enlace aleatorio de 128 bits (`cfg/check_lib.php`), páginas con `noindex` (`www/report.php`)
Servicios consultados por el monitoreo de un dominio del Cliente	Listas de bloqueo DNS (SpamCop, PSBL, Mailspike, SURBL): dominios y direcciones IP de servidores, sin datos de visitantes; Google Web Risk solo si está configurado: la dirección de la página de inicio; autoridades de sellado de tiempo Certum y DigiCert: solo un valor hash del registro de evidencias; RDAP mediante el registro de IANA: solo el nombre de dominio; páginas de estado de proveedores: no se transmite nada; wpvulnerability.net: identificador de un plugin (sin versión) o tema y la versión de WordPress	P4	en uso; detalles en el Registro de Actividades de Tratamiento y en la página Subencargados del Tratamiento
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Copias de control, incluidos mensajes auténticos de visitantes	P6	Contrato aún no celebrado; lugar de tratamiento y mecanismo de transferencia aún por examinar
Namecheap, Inc. (USA)	Registrador y DNS; hasta que se configure el buzón, reenvío de correos generales a direcciones de nuestro dominio, no de las copias de control (estas solo llegan al buzón mediante registros MX que apunten directamente a él)	– (sin copias de control)	Mecanismo de transferencia por examinar
Canales de alerta elegidos por el Cliente (correo electrónico, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	Evento, dominio, enlace; para la verificación de autenticidad, el dominio del remitente si no pertenece al sitio web	P4, P6	destino elegido por el Cliente; en parte fuera de la UE. Enviamos los mensajes de Telegram mediante nuestro bot; el mecanismo de transferencia para ello es una cuestión pendiente para la revisión jurídica
Todos los sitios web conectados	Lista de dominios de enlaces	P7	mediante la respuesta al plugin
Segunda prueba	Dominio, dirección del formulario, selector, pasos	P4	desactivada

6.11 Conservación, medida, no meramente prevista

La eliminación se realiza principalmente por la noche a las 03:00 en el proceso de estado (srv/cron_status.php, cfg/fristen_lib.php); las comunicaciones de protección colectiva y las filas de clientes potenciales se eliminan diariamente a partir de las 04:00; las asignaciones de la verificación de entrega, en cada recuperación; los informes anónimos y de clientes potenciales se eliminan mediante su fecha de vencimiento (cfg/check_lib.php). Las capturas de pantalla se eliminan del disco junto con su escaneo (cfg/fristen_lib.php).

Datos	Plazo según el código	Referencia de fuente	Hallazgo
Verificación gratuita incluidas imágenes	30 días	`cfg/check_lib.php`	efectivo
Verificación de clientes potenciales incluidas imágenes	90 días	`cfg/akquise_lib.php`; `srv/cron_status.php` (filas de clientes potenciales)	efectivo
Verificaciones de un dominio del Cliente	13 meses; la última se conserva mientras exista el dominio	`cfg/fristen_lib.php`	efectivo
Resultados de recorridos con navegador incluidas imágenes cubiertas en negro	13 meses	`cfg/fristen_lib.php`	efectivo
Datos de un dominio eliminado	de inmediato; datos huérfanos por la noche	`cfg/fristen_lib.php` (`fe_domain_loeschen()`, `fe_fristen_lauf()`)	efectivo, incluidos el inventario de scripts y los cambios de scripts, que no tienen un plazo de conservación propio adicional (véase el Registro de Actividades de Tratamiento)
Estudio: datos sin procesar incluidas imágenes	al publicar	`cfg/studie_lib.php`	sin publicación, sin límite de tiempo; la lista de hosts verificados permanece sin límite de tiempo incluso después de la publicación
Verificaciones internas sin dominio y sin informe	ninguno	–	sin eliminación; medido: 85 verificaciones con 369 imágenes desde el 22 de septiembre de 2026 (R4)
Asignaciones de la verificación de entrega	180 días	`cfg/zustellung_lib.php`	efectivo
Resultado de la verificación de autenticidad con el dominio	hasta el siguiente resultado o la eliminación del dominio	`cfg/zustellung_lib.php`	sobrescrito, sin límite temporal
Copias de control en el buzón	hasta la siguiente recuperación correcta (intervalo de cinco minutos)	`cfg/zustellung_lib.php`	copias y copias de seguridad en el proveedor del buzón no verificadas
Credenciales para el escaneo detrás del inicio de sesión	hasta la eliminación por el Cliente o del dominio; en el trabajo, como máximo hasta el final de la ejecución; restos después de una hora	`cfg/login_lib.php`	efectivo; en copias de seguridad solo como texto cifrado durante hasta 14 días
Comunicaciones en la protección colectiva	30 días	`cfg/swarm_lib.php`	efectivo
Límites de la verificación gratuita (IP, país, hash de sesión)	7 días	`srv/cron_status.php`	efectivo
Notas de comportamiento llamativo con dirección IP	90 días después de la resolución	`srv/cron_status.php`	notas no resueltas sin límite de tiempo; medido: 3 notas, todas resueltas
Dirección IP, país y navegador relativos a una exclusión	12 meses; la exclusión permanece	`cfg/fristen_lib.php`	efectivo
Copias de seguridad de la base de datos	14 días	`cfg/backup_lib.php`	efectivo; actualmente las copias de seguridad se almacenan en la misma ubicación que la base de datos y no están cifradas por separado; se prevé una copia cifrada en una segunda ubicación (R13)

7. (b) Evaluación de la necesidad y proporcionalidad

El criterio son las finalidades indicadas: mostrar a los operadores si sus formularios están protegidos contra el spam y el abuso (P1 a P5), comprobar si los correos de formularios llegan y parecen auténticos (P6) y defenderse conjuntamente contra el spam en muchos sitios web (P7). Estas finalidades son legítimas. La pregunta del art. 35, apartado 7, letra b), es más precisa: ¿es necesario este tratamiento con esta profundidad para la finalidad y es proporcionada la injerencia respecto del beneficio?

Componente	¿Necesario para la finalidad?	¿Proporcionado tal como está implementado?
Recuperación de unas cuantas páginas públicas, estructura de los formularios, medidas de protección detectadas	Sí. Sin ellas no hay hallazgo.	Sí. Como máximo ocho páginas (más las vistas de la sección 6.1), se respeta una prohibición de la página de inicio en robots.txt, sin valores de campos visibles, direcciones de destinatarios solo como dominio.
Captura de pantalla por formulario	Sí, como evidencia en el informe: el operador puede ver a qué formulario se refiere.	En gran medida. Los campos están vacíos porque el rastreador no escribe nada. Sin embargo, la imagen muestra el entorno del elemento del formulario sin cubrir nada en negro (R3).
Captura de pantalla de la página de inicio	No se requiere para el hallazgo en sí. Sirve para reconocer el sitio web verificado en el informe.	Solo de forma limitada; se prevé mayor minimización. Las páginas de inicio suelen mostrar personas: fotografías del equipo, personas de contacto, testimonios de clientes con nombres. Véanse R3 y la sección 9.3.
Lectura de los valores de campos ocultos (primeros 24 caracteres, solo durante la verificación)	Sí: a partir de ellos se detectan tokens y marcas de tiempo.	Sí. Solo se almacena el resultado de detección, no el valor, también detrás del inicio de sesión (R8).
Página de respuesta al envío de prueba (imagen y 300 caracteres de texto)	Sí, como evidencia de cómo respondió el formulario.	Sí. La respuesta se refiere a nuestro mensaje de prueba identificado como tal, sin datos personales.
Clasificación por el modelo de lenguaje	Útil, no necesaria: sin ella, más formularios permanecen «desconocidos».	Sí. Local, sin divulgación, sin derecho a realizar envíos.
Plan de acción local a partir de hallazgos seleccionados y metadatos del escaneo	Útil para priorizar las correcciones, no necesario para producir los hallazgos individuales.	Limitado a los metadatos existentes del escaneo y como máximo 18 hallazgos distintos fallidos o no concluyentes, sin capturas de pantalla ni valores ingresados en campos en el prompt. El plan es orientativo y se identifica como generado por IA; los hallazgos individuales siguen siendo la referencia vinculante. Las URL y las notas aún pueden contener datos personales, y el texto generado sigue la conservación del escaneo y el acceso mediante enlace que permite el acceso a quien lo tenga. Estos límites reducen la exposición, pero no demuestran la exactitud factual (R10).
Envíos de prueba activos	Sí. Si una protección funciona solo se hace evidente al probarla.	Sí, con límite e identificación. Sin embargo, el requisito previo —la prueba de control— nunca se renueva (R7).
Búsqueda de archivos expuestos	Sí para el Cliente, cuyos datos de formularios pueden estar expuestos allí.	Sí. Solo dominios verificados, como máximo 8 KB, contenido nunca almacenado.
Escaneo detrás del inicio de sesión	Sí para formularios del área de miembros que, de otro modo, quedarían sin verificar.	En gran medida. El cifrado y la eliminación están cuidadosamente implementados; sin embargo, el inicio de sesión acepta conexiones sin cifrar y certificados defectuosos (R8).
Copia de control de mensajes auténticos de visitantes	No para la prueba de entrega. Esta se basa únicamente en la copia de nuestra prueba (`cfg/zustellung_lib.php`). Los mensajes auténticos se incluyen porque una copia oculta en el formulario no distingue entre una prueba y un mensaje auténtico. Son útiles para la verificación de autenticidad (SPF, DKIM, DMARC) porque muestran la ruta real de envío.	En parte. El contenido no se almacena, pero se lee y permanece con el proveedor del buzón, cuyo contrato sigue pendiente, hasta su recuperación (R1, R2). Es técnicamente posible un diseño menos intrusivo: con nuestro plugin, la copia oculta podría limitarse a mensajes de prueba identificados como tales (sección 9.3).
Almacenamiento del dominio del remitente de mensajes auténticos	En parte: muestra si el formulario envía con la dirección del visitante como remitente (una causa frecuente de clasificación como spam).	De forma condicional. Para una persona con dominio propio, el dominio es un dato personal y se incluye en la alerta al Cliente y sus canales (R1).
Lista compartida de dominios de enlaces	Sí. Un enlace de spam que aparece en muchos sitios web al mismo tiempo es una señal fuerte de la que no dispone un solo sitio web.	Sí, con cantidades mínimas, excepciones y cuarentena en lugar de eliminación. Las redes IP no serían proporcionadas sin una nueva evaluación.
Datos sin procesar del estudio	Hasta la evaluación, sí.	Sin un plazo máximo, no (R4).
Informe bajo un enlace aleatorio	Sí. Compartir el informe —por ejemplo, con el prestador de servicios que mantiene el sitio web— es la finalidad de la verificación gratuita.	Sí. Enlace aleatorio de 128 bits, `noindex`, informe gratuito solo como extracto (`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`), eliminación después de 30 días.

Licitud. Para P1 a P3 y P7 nos basamos en el art. 6, apartado 1, letra f). A favor en la ponderación: los datos son públicos y se recuperan del mismo modo que lo hace cualquier visitante; no se envía nada; los datos personales son incidentales y de escasa entidad; los plazos son cortos; el operador puede excluir futuras verificaciones del rastreador mediante una prohibición de la página de inicio en robots.txt y cualquier verificación adicional mediante nuestra página de exclusión, de inmediato y sin prueba; el beneficio —un formulario protegido— también corresponde al operador y a sus visitantes. En contra: el operador no se entera de la verificación, el informe está destinado a terceros y, en el caso de empresarios individuales, evalúa a una persona. Consideramos que la ponderación es justificable mientras se mantengan las medidas de la sección 9.1; la confirmación jurídica está pendiente.

Información a los interesados (arts. 13 y 14). Informamos a los operadores y a las personas de las páginas verificadas mediante la página del rastreador, que se menciona en el identificador de cada recuperación, mediante la Política de Privacidad y mediante la página de exclusión. Informar individualmente a personas que aparecen de forma incidental en una captura de pantalla solo sería posible si las identificáramos, lo que constituiría una injerencia adicional y más grave. En esa medida nos basamos en el art. 14, apartado 5, letra b). El Cliente informa a los visitantes cuyos mensajes pasan por la copia de control; el Acuerdo de Tratamiento de Datos lo exige y proporcionamos un bloque de texto para ello.

Minimización de datos (art. 5, apartado 1, letra c)). Es visible en muchos lugares y está fundamentada en el código: sin valores de campos, direcciones de destinatarios solo como dominio, identificadores de cuenta en direcciones de scripts ocultos, sin contenido de la copia de control en la base de datos, sin capturas de pantalla detrás del inicio de sesión, solo dominios en la protección colectiva. En dos lugares es posible y está prevista una mayor minimización (sección 9.3): para la captura de pantalla de la página de inicio sin cubrir contenido y para el dominio del remitente de mensajes auténticos.

Limitación del plazo de conservación (art. 5, apartado 1, letra e)). Desde el 27 de septiembre de 2026, la ejecución nocturna cumple los plazos de la Política de Privacidad para datos de Clientes y borra datos restantes sin dominio asociado del periodo anterior (cfg/fristen_lib.php). Siguen abiertas dos vías sin límite de tiempo: verificaciones internas y estudios no publicados (R4).

Exactitud (art. 5, apartado 1, letra d)). Un hallazgo puede ser incorrecto: un formulario parece desprotegido porque la protección solo se carga después de una interacción o porque un firewall trató al rastreador de forma distinta que a un visitante. Para un operador cuyo sitio web se comparte públicamente como «Expuesto», esto es una cuestión de reputación. Por ello, el informe indica el método, muestra evidencias y señala los límites de una verificación desde el exterior.

Resultado sobre la proporcionalidad: La verificación de sitios web propios y de terceros es, tal como está implementada, esencialmente proporcionada. En tres lugares existe una necesidad de mejora que puede subsanarse por medios ordinarios y para la que se prevén medidas (sección 9.3): las capturas de pantalla de la página de inicio, las verificaciones internas sin límite de tiempo y el inicio de sesión sin cifrar para el escaneo detrás del inicio de sesión. La verificación de entrega es proporcionada para la copia de prueba y para la verificación de autenticidad; para mensajes auténticos de visitantes, solo lo es mientras no se almacene su contenido, la vía mediante el proveedor del buzón esté asegurada contractualmente y el Cliente informe a sus visitantes. Hoy falta el segundo de estos tres puntos.

8. (c) Evaluación de los riesgos para los derechos y libertades de los interesados

Se evalúa el riesgo para los interesados, no para formexposed. La probabilidad se califica como remota, posible, probable o materializada; «materializada» significa que el evento no es una previsión, sino un estado medido. La gravedad se califica como limitada, significativa, grave o muy grave, según lo que la persona pueda perder: la confidencialidad de su mensaje, el control de una cuenta, su reputación empresarial, la capacidad de ejercer un derecho. El nivel resulta de ambas y describe el estado actual con las medidas de la sección 9.1.

N.º	Riesgo	Operación de tratamiento	Probabilidad	Gravedad	Nivel
R1	Mensajes auténticos de visitantes en la copia de control, incluidas posibles categorías especiales	P6	Materializada una vez activada	Grave	Alto
R2	Ruta de la copia de control mediante el proveedor del buzón sin contrato celebrado y con un posible vínculo a un tercer país	P6	Probable mientras falte el contrato	Grave	Alto
R3	Capturas de pantalla de sitios web de terceros sin cubrir contenido	P1–P4	Probable	Limitada	Medio
R4	Datos de verificaciones y capturas de pantalla sin vía de eliminación	P3, verificaciones internas	Materializada	Significativa	Alto
R5	Verificación y valoración pública de sitios web de terceros sin conocimiento del operador; uso indebido como herramienta de reconocimiento	P1	Posible	Significativa	Medio
R6	Verificación de clientes potenciales como base para contactos no solicitados	P2	Probable	Limitada	Medio
R7	La prueba de control nunca se renueva	P4, P5	Posible	Significativa	Medio
R8	Credenciales y contenido en el escaneo detrás del inicio de sesión	P5	Posible	Grave	Medio; alto para cuentas reales
R9	Envíos de prueba activos y verificación de archivos en el sitio web del Cliente	P4	Remota	Significativa	Bajo
R10	Clasificación por un modelo de lenguaje	P1–P4	Remota	Limitada	Bajo
R11	Lista de bloqueo compartida a partir de comunicaciones de muchos sitios web	P7	Posible	Limitada	Bajo a medio; alto con redes IP
R12	Informes y capturas de pantalla bajo un enlace público	P1, P2, P4	Posible	Limitada	Bajo
R13	Debilidades de infraestructura: copias de seguridad, acceso al servidor, servidor de escaneo	todas	Posible	Grave	Alto
R14	Derechos de los interesados para personas que no nos conocen	P1–P6	Probable	Limitada	Bajo

R1 – Mensajes auténticos de visitantes en la copia de control

Este es el riesgo más grave del servicio y no surge de un error, sino del diseño. Una copia oculta en el formulario no distingue entre nuestro mensaje de prueba y el mensaje de un visitante. Si un Cliente activa la verificación de entrega, cada mensaje enviado mediante ese formulario llega a nuestro buzón de control (cfg/zustellung_lib.php). La recuperación lee los encabezados y los primeros 8 KB del texto en memoria para buscar nuestro identificador de prueba (cfg/zustellung_lib.php). Para un formulario de contacto ordinario, esto significa nombre, dirección de correo electrónico, número de teléfono y el mensaje completo.

Lo que escribe el visitante depende de él y el campo invita a incluir contenido personal: una solicitud de cita que describe síntomas a un consultorio médico, el relato de un litigio a un despacho jurídico, una solicitud de empleo, una consulta sobre un menor a una escuela. Nuestros documentos legales dicen que las copias «no deberían contener categorías especiales de datos personales». Esto es una petición al Cliente, no una medida de protección: ni él ni nosotros sabemos de antemano lo que escribirá un visitante.

Dos vías secundarias forman parte de esto. Primero, la verificación de autenticidad almacena el dominio de la dirección del remitente con el dominio (cfg/zustellung_lib.php). Si el formulario envía con la dirección del visitante como remitente, es el dominio del visitante: sin significado para un gran proveedor de correo, pero un dato personal para una persona con dominio propio. Este dominio también aparece en la alerta que se envía al Cliente y a los canales que ha elegido (cfg/zustellung_lib.php). Segundo, almacena la dirección del servidor de correo de envío (cfg/zustellung_lib.php); por regla general, es el servidor del sitio web, no el del visitante.

Probabilidad – materializada una vez activada. La cuestión no es si llegan mensajes auténticos, sino cuántos. Medido en el sistema de desarrollo, la función no está activada para ningún dominio. Gravedad – grave. La confidencialidad de un mensaje a una empresa importa a muchas personas y cabe esperar datos del art. 9 para algunos de los Clientes típicos. La gravedad se mitiga porque el contenido no pasa a la base de datos, permanece en el buzón solo brevemente y no lo lee ninguna persona en formexposed. Nivel – alto.

R2 – Ruta de la copia de control mediante el proveedor del buzón sin contrato celebrado

Antes de que nuestra recuperación vea una copia de control, esta se conserva en el buzón de Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. Solo llega allí si los registros MX de nuestro dominio apuntan directamente a este buzón; el reenvío en el registrador de dominios Namecheap, Inc. no es una estación de las copias de control (mediante reenvío no llegan al buzón). Para la estación que queda, los acuerdos contractuales siguen pendientes: no se ha celebrado el contrato con el proveedor del buzón, no se han establecido sus ubicaciones de almacenamiento, subencargados ni plazos de copias de seguridad y está pendiente si se requieren y aplican una decisión de adecuación o cláusulas contractuales tipo para su lugar de tratamiento. Para nuestros propios correos transaccionales, esto es una cuestión de diseño contractual. Para las copias de control es más grave: allí son datos que recibimos como encargados del tratamiento y cada prestador de servicios de la ruta es un subencargado por el que respondemos conforme al art. 28, apartado 4.

Además, «eliminado después de la recuperación» se aplica solo a nuestra vista del buzón. No se ha verificado si el proveedor conserva correos eliminados en sus propias copias de seguridad o en una papelera, ni durante cuánto tiempo. Si una recuperación se aborta, los correos permanecen hasta la siguiente ejecución correcta (cfg/zustellung_lib.php); si falla el proceso de estado, permanecen indefinidamente. Por último, proteger la propia recuperación es uno de los puntos que deben comprobarse en el sistema de producción antes del lanzamiento (sección 9.3).

Probabilidad – probable mientras falte el contrato: cada copia de control sigue esta ruta. Gravedad – grave, por los mismos motivos que R1. Nivel – alto. La lista de comprobación de configuración de la aplicación señala el buzón faltante como advertencia; no existe un bloqueo que impida la verificación de entrega sin un contrato documentado.

R3 – Capturas de pantalla de sitios web de terceros sin cubrir contenido

El rastreador toma una captura de pantalla del área visible de la primera página y una imagen del elemento del formulario de cada formulario visible (scanner/src/crawl.js). No se cubre nada en negro durante el proceso. Esto es distinto para los recorridos con navegador: allí los campos de entrada se enmascaran antes de la captura (scanner/src/browser.js). Por tanto, solo las imágenes de los recorridos con navegador están «limpias», no las del rastreador ni la imagen de la página de respuesta de una verificación activa.

Como el rastreador no escribe nada, los campos del formulario están vacíos. Sin embargo, la página de inicio de una pequeña empresa suele mostrar al propietario, al equipo, testimonios de clientes con nombres y fotografías o una ventana de chat con la imagen de un empleado. Todo esto es público; la captura lo convierte en una copia que se almacena con nosotros, aparece en el informe y puede compartirse mediante el enlace.

Probabilidad – probable. Se midieron 432 capturas de pantalla en el conjunto de datos del sistema de desarrollo. Gravedad – limitada: el contenido ya es público y los plazos de verificaciones sin cuenta son cortos. Nivel – medio, porque las personas representadas lo desconocen y la imagen de la página de inicio no es necesaria para el hallazgo.

R4 – Datos de verificaciones y capturas de pantalla sin vía de eliminación

La ejecución nocturna elimina verificaciones por dos vías: mediante la fecha de vencimiento de un informe (cfg/check_lib.php) y mediante el plazo de verificaciones de un dominio del Cliente (cfg/fristen_lib.php, solo para verificaciones con un dominio). Una verificación que no tiene ni informe ni dominio escapa a ambas vías. Son las verificaciones con el nivel de confianza «internal»: estudios y verificaciones que el proveedor crea desde la línea de comandos.

Los estudios eliminan sus datos sin procesar al publicar (cfg/studie_lib.php). Si un estudio nunca se publica —porque tiene muy pocos sitios web con formulario (cfg/studie_lib.php rechaza entonces la publicación) o porque se deja abandonado—, las verificaciones, formularios, hallazgos y capturas de pantalla permanecen sin límite de tiempo.
Las verificaciones internas desde la línea de comandos no tienen ninguna vía de eliminación. Medido el 11 de octubre de 2026: 85 verificaciones de este tipo de sitios web de terceros con 978 formularios y 369 capturas de pantalla, la más antigua del 22 de septiembre de 2026, ninguna con informe ni dominio.
Las notas sobre comportamiento llamativo en la verificación gratuita contienen la dirección IP y se eliminan 90 días después de resolverse (srv/cron_status.php). Una nota que nunca se resuelve permanece. Medido: tres notas, todas resueltas.

Probabilidad – materializada. Las 85 verificaciones no son un escenario, sino datos existentes. En el sistema de desarrollo son verificaciones de una prueba de campo; el mismo código se aplica en el sistema de producción. Gravedad – significativa: no existe plazo de conservación para estos datos. Respecto del principio de limitación del plazo de conservación (art. 5, apartado 1, letra e)), es un punto pendiente con una medida prevista (sección 9.3, prioridad «primero») y afecta precisamente a personas que no saben nada de la verificación. Las verificaciones internas se describen en el Registro de Actividades de Tratamiento; la Política de Privacidad aún no las menciona por separado (sección 9.4). Nivel – alto.

R5 – Verificación y valoración pública de sitios web de terceros sin conocimiento del operador

Cualquier persona puede solicitar la verificación de cualquier sitio web accesible públicamente, sin cuenta y sin ninguna relación con él. No se notifica al operador. El resultado es un informe que valora el sitio web como «Expuesto», «Parcialmente protegido» o «Protegido» y que puede ver cualquiera que tenga el enlace. Son concebibles dos consecuencias para los interesados. Un empresario individual recibe una valoración pública —aunque solo sea para los destinatarios del enlace— que puede ser un hallazgo falso. Y el informe muestra a un remitente de spam qué formulario puede rellenarse sin obstáculos.

Una serie de bloqueos contrarresta esto (cfg/check_lib.php): como máximo una verificación por dominio en siete días, después el mismo informe; límites por dirección IP y sesión; un límite diario para todo el servicio; sin verificaciones de dominios muy recientes, típicos del abuso; una nota y una señal para comportamientos llamativos; robots.txt y exclusión, comprobados dos veces (cfg/check_lib.php y en el servicio de verificación). El informe gratuito es un extracto: solo muestra los hallazgos básicos, no las evidencias de todos los detectores. Y no dice nada que un bot no pudiera descubrir por sí mismo en segundos: un formulario desprotegido es visible desde el exterior.

Probabilidad – posible. Gravedad – significativa para un empresario individual cuyo formulario sea atacado después de un informe o cuya valoración sea incorrecta. Nivel – medio.

R6 – Verificación de clientes potenciales como base para contactos no solicitados

En la interfaz, la verificación de clientes potenciales se describe como una forma de «abrir la puerta a la primera conversación». La agencia decide cómo utiliza el hallazgo breve; técnicamente, también puede enviarlo a un operador que no lo haya solicitado. No contactamos a nadie (cfg/akquise_lib.php) y las Condiciones del Servicio obligan a la agencia a cumplir las reglas sobre publicidad y captación. Sin embargo, un correo no solicitado con el hallazgo es mercadotecnia directa incluso entre empresas, que en Polonia (art. 398 de la Ley de Comunicaciones Electrónicas (Prawo komunikacji elektronicznej, PKE)) y en Alemania (§ 7, apartado 2, de la Ley alemana contra la Competencia Desleal (Gesetz gegen den unlauteren Wettbewerb, UWG)) requiere consentimiento previo. La interfaz no lo señala; los textos de la verificación de clientes potenciales solo hablan de «pasiva» y «lista de exclusión».

Probabilidad – probable, porque la función sirve para captar clientes y no podemos verificar si el destinatario ha consentido. Gravedad – limitada: para el operador es un correo publicitario molesto con una valoración de su sitio web. Nivel – medio. El riesgo está en la conducta de la agencia; como la función procede de nosotros, se prevé un aviso en la interfaz (sección 9.3).

R7 – La prueba de control nunca se renueva

Los envíos de prueba activos, la búsqueda de archivos expuestos y el escaneo detrás del inicio de sesión requieren que el Cliente haya demostrado que tiene derecho a ejercer control sobre el dominio. Esta prueba se comprueba una vez (cfg/verify_lib.php) y nunca más. No existe ninguna vía en el código mediante la cual un dominio pierda su prueba. Si el dominio cambia de propietario, una agencia termina su encargo o el operador elimina el registro DNS, las verificaciones continúan —hasta diariamente, con hasta cinco envíos de prueba y, cuando esté almacenado, con el inicio de sesión de una cuenta de prueba que el nuevo operador puede desconocer—. En cambio, lo que no es posible es transferir la prueba a otro host cambiando el nombre: el nombre de host de un dominio con prueba de control no puede cambiarse.

Probabilidad – posible: los cambios de dominio y de encargo son hechos cotidianos para las agencias. Gravedad – significativa para el nuevo operador y sus empleados, que reciben mensajes de prueba identificados como tales y cuyo sitio web se examina en busca de archivos expuestos sin su consentimiento. Nivel – medio. Los mensajes de prueba se explican por sí mismos y remiten a la página del rastreador y a la exclusión; la exclusión también funciona frente a las verificaciones de Clientes.

R8 – Credenciales y contenido en el escaneo detrás del inicio de sesión

El cifrado de las credenciales está cuidadosamente implementado: el servidor web ya no puede leerlas después de almacenarlas, la base de datos y la copia de seguridad solo contienen texto cifrado, el registro está vinculado a su dominio, las credenciales ingresan al contenedor solo mediante la entrada estándar y después se borran de la memoria (sección 6.5). Quedan dos carencias; un tercer punto se refiere solo a la lectura, no al almacenamiento.

Se permite el inicio de sesión sin cifrar. La comprobación de direcciones permite http además de https (cfg/login_lib.php, scanner/src/login.js). Si el Cliente ingresa una página de inicio de sesión con http, el nombre de usuario y la contraseña circulan por internet en texto claro con cada verificación.
Los errores de certificado no detienen el inicio de sesión. Actualmente, el inicio de sesión no se aborta cuando el certificado del sitio del Cliente es inválido (scanner/src/login.js). Por tanto, el certificado no protege plenamente las credenciales en su trayecto al sitio del Cliente. Se prevé abortar ante errores de certificado (sección 9.3, prioridad «primero»).
Los valores de campos ocultos detrás del inicio de sesión se leen, no se almacenan. El rastreador lee los primeros 24 caracteres del valor de campos ocultos (scanner/src/crawl.js) y la misma función de extracción se ejecuta detrás del inicio de sesión (scanner/src/login.js). Allí, los campos ocultos contienen con frecuencia un número de cuenta, un identificador de usuario o la dirección de correo electrónico de la cuenta con sesión iniciada; sin embargo, solo el nombre de campo, el tipo, la etiqueta y el resultado de detección pasan al mapa de campos y a los hallazgos.

A esto se agrega lo que el código no puede impedir: el Cliente confirma que utiliza una cuenta de prueba con los menores derechos posibles (cfg/login_lib.php), pero puede ingresar una cuenta real de administrador. Las páginas que lee entonces el escáner las determina el Cliente; las direcciones que contienen palabras para cerrar sesión y eliminar están bloqueadas, pero no otras acciones que un sitio web active mediante una solicitud simple.

Probabilidad – posible. Gravedad – grave si se ve afectada una cuenta con derechos amplios; el área de miembros con los datos de todos los usuarios queda entonces abierta. Nivel – medio para una cuenta de prueba con pocos derechos, alto para una cuenta real. Medido en el sistema de desarrollo, no hay ninguna cuenta de prueba almacenada.

R9 – Envíos de prueba activos y verificación de archivos en el sitio web del Cliente

Un envío de prueba llega a las personas que leen los correos de formularios del Cliente: sus empleados o un prestador de servicios. No contiene datos personales: el remitente es dummy@formexposed.com, el texto y el asunto están identificados como prueba e indican el identificador de verificación (scanner/src/active.js). El riesgo está en una clasificación incorrecta: si el escáner confundiera un formulario de solicitud, reserva o asesoramiento con uno de contacto, el mensaje de prueba terminaría en un proceso que tiene consecuencias. Lo contrarrestan las reglas estrictas de «autorizado para envío» (scanner/src/classify.js), el bloqueo de dominios de autoridades públicas, instituciones educativas, clínicas, consultorios médicos, policía y tribunales (scanner/src/classify.js) y la exclusión del modelo de lenguaje de esta decisión (scanner/src/classify.js). De la respuesta se almacenan el estado, la dirección de destino, el título, 300 caracteres de texto y una imagen; se refieren a nuestro mensaje de prueba.

La verificación de archivos lee como máximo 8 KB de rutas típicas. Si realmente hay un volcado de base de datos expuesto allí, estos 8 KB pueden contener datos de formularios ingresados por visitantes. Solo se comprueba en ellos una firma y se descartan (cfg/dateien_lib.php); lo que se almacena es la ruta, el tipo y la gravedad.

Probabilidad – remota. Gravedad – significativa. Nivel – bajo. Medido en el sistema de desarrollo, hay una verificación activa en el conjunto de datos, sin ningún envío aceptado.

R10 – Clasificación por un modelo de lenguaje

Para los formularios que las reglas no reconocen, el modelo de lenguaje recibe el título de la página, la dirección, los textos de botones, las descripciones de campos y hasta 400 caracteres de texto del formulario (scanner/src/classify.js). Esto puede incluir un nombre, por ejemplo, «Su persona de contacto: …». Funciona en nuestro propio servidor; en el código, no se envía nada a un tercero. No se ha verificado si el software del modelo registra solicitudes. Su resultado determina únicamente el tipo de formulario mostrado y no puede autorizar el envío de un formulario; una clasificación incorrecta lleva a un hallazgo peor, no a una acción.

Probabilidad – remota. Gravedad – limitada. Nivel – bajo.

R10 – Etapa adicional de plan de acción

Para los informes de pago elegibles, el mismo modelo local también genera pasos orientativos a partir de hallazgos seleccionados y metadatos del escaneo. A diferencia de la clasificación, la salida es un resumen en lenguaje natural que se conserva con el escaneo. Los nombres de host, las direcciones de páginas y las notas pueden contener datos personales que el modelo podría repetir. Una recomendación incorrecta puede llevar a un lector a debilitar la protección o realizar un cambio innecesario; compartir un enlace de informe puede revelar datos personales repetidos a otro destinatario. El código no ejecuta automáticamente la recomendación, no modifica la puntuación ni el dictamen ni comprueba la exactitud factual del texto. Limita la longitud de entrada y salida, identifica el resumen como generado por IA e indica que los hallazgos individuales son la referencia vinculante. Estos son controles, no pruebas de que las recomendaciones sean correctas o de que el informe sea anónimo. La calificación anterior de probabilidad y gravedad para la clasificación no califica por sí sola esta etapa de generación agregada; su riesgo residual debe evaluarse con los datos y el uso reales de la verificación subyacente.

R11 – Lista de bloqueo compartida a partir de comunicaciones de muchos sitios web

Un dominio en la lista hace que los mensajes con enlaces a él terminen en la cuarentena de todos los sitios web conectados. Si el dominio pertenece a una persona —un profesional de oficio, un fotógrafo, un blog—, sus mensajes con un enlace a su propio sitio web llegan tarde a los destinatarios. Un dominio de este tipo puede entrar en la lista porque remitentes de spam lo utilicen indebidamente o porque alguien envíe deliberadamente mensajes que fallen y lo contengan a varios sitios web.

Lo contrarrestan (cfg/swarm_lib.php): un mínimo de tres sitios web distintos y cinco coincidencias dentro de siete días; excepciones fijas para grandes servicios; nunca los dominios de nuestros Clientes; eliminación manual mediante una herramienta en el servidor; cuarentena en lugar de eliminación; la lista se reconstruye diariamente y lo que deja de comunicarse sale de ella. Los afectados no pueden ver la lista y no tienen una vía propia para exigir su eliminación, salvo a través de nosotros.

Probabilidad – posible. Gravedad – limitada, porque no se pierde nada y el destinatario puede liberar el mensaje. Nivel – bajo a medio. Con las redes IP activadas, se verían afectadas redes de proveedores enteros, las direcciones IP son datos personales y la gravedad aumentaría a significativa: alto.

R12 – Informes y capturas de pantalla bajo un enlace público

Puede accederse a los informes de la verificación gratuita, la verificación de clientes potenciales y las verificaciones de dominios de Clientes sin iniciar sesión mediante un enlace aleatorio. El enlace contiene 128 bits de aleatoriedad y no puede adivinarse (cfg/check_lib.php). Las páginas llevan noindex, la aplicación envía una política de referencia que solo transmite el origen (www/.htaccess) y las capturas de pantalla solo se entregan junto con el informe al que pertenecen; otro número de imagen devuelve «no encontrado» (www/shot.php). El riesgo no es criptográfico, sino humano: un enlace se comparte, se copia en un ticket, se comparte en un chat. Quien lo abre solo queda registrado en el registro de acceso a páginas como cualquier visita (60 días), en el que el propio enlace solo aparece enmascarado; no existe una lista de lectores por informe.

Probabilidad – posible. Gravedad – limitada, porque el informe solo muestra información pública y vence después de 30 o 90 días, respectivamente; los informes de dominios de Clientes permanecen accesibles mientras exista la verificación (13 meses, la última durante más tiempo). Nivel – bajo.

R13 – Debilidades de infraestructura

Los siguientes puntos se enumeran como pendientes en nuestro paquete interno de revisión y no se disimulan aquí. Los describimos con la precisión que los Clientes necesitan para su propia evaluación, pero no con tanta precisión que la descripción indique el camino a un atacante; proporcionaremos los detalles a una autoridad de control previa solicitud.

Las copias de seguridad de la base de datos se almacenan actualmente en la misma ubicación que la base de datos y no están cifradas por separado; se prevé una copia cifrada en una segunda ubicación (cfg/backup_lib.php). Hasta entonces, no protegen contra la pérdida de la ubicación y quien obtiene la base de datos también obtiene las copias de seguridad. Las credenciales para el escaneo detrás del inicio de sesión solo están contenidas en ellas como texto cifrado.
Sin cifrado de la base de datos en reposo. Las excepciones son los campos cifrados individualmente (credenciales de las cuentas de prueba, secreto de dos factores).
Las conexiones dentro de nuestra red interna no están cifradas en su totalidad.
Administración del servidor. La seguridad del acceso administrativo a nuestros servidores aún no cumple el nivel que pretendemos para la operación; el refuerzo de la administración del servidor continúa.
Entorno de verificación. El servidor de escaneo abre sitios web de terceros en un navegador. Los contenedores de verificación están aislados: red propia, sin privilegios especiales, solo lectura, limitados (scanner/src/worker.js). Se sigue reforzando la separación entre el entorno de verificación y las demás partes del servicio (sección 9.3).

Probabilidad – posible. Gravedad – grave, porque en una emergencia todo se vería afectado a la vez. Nivel – alto. Los puntos individuales pueden subsanarse por medios ordinarios (sección 9.3).

R14 – Derechos de los interesados para personas que no nos conocen

Quien aparece de forma incidental en una captura de pantalla o cuyo mensaje pasó por una copia de control normalmente no sabe que existimos. Incluso si lo sabe, no tiene una clave para «sus» datos: no los almacenamos por persona, sino por dominio y verificación. Solo podemos responder a una solicitud de acceso conforme al art. 15 si la persona indica el dominio; entonces podemos revisar las verificaciones e imágenes existentes. Para mensajes auténticos de visitantes no hay nada que facilitar porque no los almacenamos, salvo el dominio del remitente de R1. La exclusión solo funciona para operadores de un dominio, no para las personas representadas; para ellas queda la vía de contact@lukaswojcik.com.

Probabilidad – probable como situación estructural. Gravedad – limitada, porque los datos tienen corta duración y no están organizados por persona. Nivel – bajo.

9. (d) Medidas para afrontar los riesgos

Cada medida lleva un estado y los estados no son decorativos. Implementada hoy – verificada significa: leída en el código del sistema de desarrollo y, cuando es posible, medida contra la base de datos. Parcial significa: el mecanismo existe, pero aún no logra plenamente su finalidad. Prevista significa: propuesta por esta evaluación y no implementada; el propietario decide si se implementa y cuándo. Aún por determinar son procedimientos y decisiones que ningún código sustituye. Una EIPD que presenta medidas previstas como implementadas pierde su valor precisamente en la situación en que se necesita.

9.1 Implementadas hoy – verificadas

Medida	Qué aborda	Referencia de fuente
El rastreador lee robots.txt antes de cada verificación; una exclusión que abarque la página de inicio, un robots.txt inaccesible o un error del servidor termina la verificación (las subrutas no se observan individualmente; el pulso, la recuperación de la prueba, la herramienta de encabezados y la búsqueda de archivos no lo leen)	R5, licitud	`scanner/src/net.js`
Exclusión sin prueba, efectiva de inmediato, para el dominio y su variante con www, para verificaciones anónimas, clientes potenciales, estudios y verificaciones de Clientes (el monitoreo en curso termina con la siguiente verificación programada); comprobada dos veces (aplicación y servicio de verificación); solo nosotros la levantamos previa solicitud con prueba	R5, R7, art. 21	`cfg/check_lib.php`; `cfg/akquise_lib.php`; `cfg/studie_lib.php`; `scanner/src/worker.js`
Verificación gratuita: detención de emergencia, reCAPTCHA, una verificación por dominio y semana, límites por dirección IP y sesión, límite diario, sin dominios nuevos, solo direcciones públicas, nota y señal sin contenido en caso de anomalías	R5	`cfg/check_lib.php`
Para los límites, la sesión solo se almacena como valor hash, nunca el identificador de sesión	Minimización	`cfg/check_lib.php`
Sin valores de campos (el inicio de los campos ocultos y los atributos de datos solo se lee durante la verificación, sección 6.2); direcciones de destinatarios solo como dominio; identificadores de cuenta en direcciones de scripts ocultos	Minimización	`scanner/src/crawl.js`
El informe gratuito es un extracto: solo hallazgos básicos, sin evidencias de todos los detectores	R5	`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`
Informes bajo un enlace aleatorio de 128 bits, `noindex`, imágenes solo para su propio informe, fuera del directorio web público; el enlace aparece en el registro de acceso a páginas solo enmascarado	R12	`cfg/check_lib.php`; `www/report.php`; `www/shot.php`
Eliminación: informes anónimos después de 30 días, clientes potenciales después de 90 días, verificaciones de Clientes después de 13 meses (la última por dominio se conserva mientras exista el dominio), datos de un dominio eliminado de inmediato (véanse excepciones en la sección 6.11), imágenes junto con ellos en cada caso	Limitación del plazo de conservación	`cfg/check_lib.php`; `cfg/fristen_lib.php`
Estudio: publicación solo como total, segmentos solo a partir de 20 sitios web con formulario, datos sin procesar eliminados al publicar	R4 en parte, P3	`cfg/studie_lib.php`
Contenedores de verificación: red aislada propia, sin privilegios especiales, solo lectura, límites de memoria y procesos, límite de tiempo; filtro contra destinos privados para cada solicitud, service workers bloqueados y conexiones WebSocket cerradas para que nada eluda el filtro; solicitudes del servidor web solo en puertos web y únicamente a la dirección pública exacta comprobada previamente	R13	`scanner/src/worker.js`; `scanner/src/net.js`
Verificación activa para Clientes solo para un dominio verificado (internamente también para nuestros propios dominios de prueba y demostración) y con la detención de emergencia activada, comprobada dos veces; como máximo cinco envíos; solo formularios de contacto claramente reconocidos sin datos personales obligatorios; sin dominios de autoridades públicas, instituciones educativas, clínicas, consultorios médicos, policía o tribunales; el modelo de lenguaje no puede autorizar nada; mensaje de prueba sin datos personales, identificado como tal, con referencia a la página del rastreador y a la exclusión	R9	`scanner/src/worker.js`; `scanner/src/classify.js`; `scanner/src/active.js`
Recorridos con navegador: solo GET y HEAD, direcciones peligrosas bloqueadas, valores inventados que no salen del navegador, imágenes con campos de entrada cubiertos en negro	R3 (para estas imágenes), R9	`scanner/src/browser.js`
Verificación de archivos: solo dominios verificados, una recuperación por ruta, como máximo 8 KB, contenido nunca almacenado	R9	`cfg/dateien_lib.php`
Segunda prueba: desactivada de forma predeterminada; recibiría solo una lista fija de elementos inocuos, firmados	Destinatarios	`cfg/formular_probe_lib.php`
Escaneo detrás del inicio de sesión: solo dominio verificado, plan de pago, propietario o administrador, confirmación de «cuenta de prueba»; cifrado con la clave pública del servidor de escaneo, vinculado al dominio; credenciales nunca mostradas, registradas ni proporcionadas mediante la API; transmisión solo por entrada estándar; campo del trabajo borrado de inmediato, restos después de una hora; sin capturas de pantalla, sin envíos, sin direcciones de cierre de sesión o eliminación, aborto ante CAPTCHA; eliminación definitiva con sobrescritura	R8	`cfg/login_lib.php`; `scanner/src/login.js`; `scanner/src/geheim.js`; `scanner/src/worker.js`
Verificación de entrega: desactivada de forma predeterminada; la recuperación solo lee encabezados y 8 KB, sin marca de leído; contenido y dirección del visitante nunca en la base de datos; cada correo recuperado se elimina, incluidos los no asignables; asignaciones eliminadas después de 180 días; prueba solo mediante la copia de exactamente esta prueba	R1, R2	`cfg/zustellung_lib.php`
Protección colectiva: solo dominios, redes IP desactivadas; cantidades mínimas; excepciones para grandes servicios y dominios de Clientes; cuarentena en lugar de eliminación; lista reconstruida diariamente; comunicaciones eliminadas después de 30 días	R11	`cfg/swarm_lib.php`
Modelo de lenguaje en nuestro propio servidor, sin derecho a realizar envíos	R10	`scanner/src/classify.js`
Plan de acción: generación local a partir de hallazgos seleccionados, sin capturas de pantalla ni valores ingresados en campos en su prompt; número de hallazgos y longitud de notas limitados; texto plano depurado con longitud limitada; aviso visible de IA, hallazgos individuales como referencia vinculante; sin cambios automáticos en el sitio web ni decisiones sobre puntuación o dictamen	R10 en parte; siguen siendo posibles consejos incorrectos y datos personales incidentales	`cfg/plan_lib.php`; `www/report.php`
Las señales mediante Telegram contienen solo una frase fija sin variables	Destinatarios	`cfg/check_lib.php`
Prueba semanal de restauración de la copia de seguridad, con alerta ante fallas	Disponibilidad	`cfg/backup_lib.php`; `srv/cron_status.php`

9.2 Parciales – implementadas, pero aún sin lograr su finalidad

Medida	Por qué aún no es plenamente eficaz
Capturas de pantalla «limpias»	Solo se cubre contenido en negro en las imágenes de recorridos con navegador. No en las imágenes del rastreador —página de inicio y elementos de formularios— ni en la imagen de la página de respuesta de una verificación activa (R3).
Plazos para datos de verificaciones	Efectivos para verificaciones anónimas, de clientes potenciales y de Clientes; no para verificaciones internas ni estudios no publicados; notas de anomalías no resueltas sin límite de tiempo (R4).
Eliminación de las copias de control	Efectiva en nuestra vista del buzón. Si la ejecución se aborta, los correos permanecen; no se ha verificado lo que conserva el proveedor del buzón en sus propias copias de seguridad (R2).
Protección de credenciales en el escaneo detrás del inicio de sesión	Fuerte en reposo y en el servicio de verificación; no en el trayecto al sitio web: se permite `http` y se ignoran errores de certificado (R8).
Prueba de control	Se comprueba una vez y después se aplica para siempre; sin embargo, el nombre de host de un dominio con prueba de control no puede cambiarse, para que la prueba no se transfiera a otro host (R7).
Información a los interesados	Implementada para operadores mediante la página del rastreador, el identificador, la Política de Privacidad y la exclusión; para visitantes en la verificación de entrega, depende de que el Cliente adopte el bloque de texto; la aplicación no lo comprueba.
Petición a los Clientes de no incluir categorías especiales en la copia de control	Indicada en los documentos legales, pero sin respaldo técnico: durante la configuración, la aplicación no pregunta por el tipo de sitio web ni advierte sobre dominios que parezcan de salud, derecho o educación (R1).

9.3 Previstas – no implementadas

Medida	Qué aborda	Prioridad
Vía de eliminación para verificaciones internas: eliminar verificaciones sin dominio y sin informe después de un plazo fijo (propuesta: 30 días); eliminar los datos sin procesar de un estudio a más tardar un plazo fijo después de su finalización, incluso sin publicación (propuesta: 90 días); eliminar una vez las 85 verificaciones existentes con 369 imágenes	R4	Primero
Habilitar la verificación de entrega solo una vez celebrado el contrato con el proveedor del buzón, documentadas las ubicaciones de almacenamiento, los subencargados y los plazos de copias de seguridad, aclarado el mecanismo de transferencia para el proveedor del buzón y cuando los registros MX de nuestro dominio apunten directamente al buzón; hasta entonces, mantener la función bloqueada en el sistema de producción	R2	Primero
Comprobar la seguridad de la recuperación del buzón en el sistema de producción y documentarla antes de habilitar la verificación de entrega	R2	Primero
Escaneo detrás del inicio de sesión solo mediante `https` y con certificado válido; rechazar direcciones `http`; errores de certificado al iniciar sesión como motivo de aborto	R8	Primero
No almacenar valores de campos ocultos detrás del inicio de sesión (solo nombre, tipo y longitud): ya implementado así, sin pasos adicionales	R8	Hecho
Limitar la copia de control a mensajes de prueba cuando se utilice el plugin o la extensión: copia oculta solo para envíos con nuestro identificador de prueba	R1	Alta
No almacenar el dominio del remitente de mensajes auténticos ni escribirlo en alertas si no es el dominio del sitio web ni el de un servicio de envío conocido; en la alerta, «dominio de remitente ajeno» en su lugar	R1	Alta
Advertencia al configurar la verificación de entrega para dominios que parezcan de salud, derecho, servicios sociales o educación, con referencia a la propia EIPD del Cliente	R1	Alta
Renovar regularmente la prueba de control (propuesta: antes de cada verificación activa, comprobar si siguen existiendo el registro DNS, la metaetiqueta, el archivo o la conexión del plugin; de lo contrario, continuar de forma pasiva y notificar al Cliente)	R7	Alta
Dejar de fotografiar la página de inicio o hacerlo solo con imágenes y rostros cubiertos en negro; limitar las imágenes de formularios al elemento del formulario (como hoy) y enmascarar los campos de entrada como en los recorridos con navegador	R3	Alta
Aviso en la interfaz de la verificación de clientes potenciales: enviar el hallazgo breve sin que lo soliciten por correo electrónico o teléfono constituye mercadotecnia directa incluso entre empresas y requiere consentimiento previo (art. 398 de la Ley polaca de Comunicaciones Electrónicas; en Alemania, § 7, apartado 2, de la UWG, aunque para llamadas a empresas basta el consentimiento presunto)	R6	Alta
Infraestructura: completar el refuerzo de la administración del servidor; copia cifrada de la copia de seguridad en una segunda ubicación; cifrar las conexiones de la red interna en su totalidad; reforzar aún más la separación entre el servidor de escaneo y la aplicación	R13	Alta
Plazo para notas de anomalías no resueltas (propuesta: resolución dentro de 30 días; en caso contrario, eliminación de la dirección IP)	R4	Media
Una página o formulario mediante el que alguien pueda solicitar la eliminación de un dominio de la protección colectiva	R11, R14	Media
Antes de activar redes IP en la protección colectiva: una nueva versión de esta evaluación	R11	Condición
Registrar si el software del modelo de lenguaje almacena solicitudes y, de ser así, desactivar esos registros	R10	Baja

9.4 Procedimientos y decisiones aún por determinar

Además de garantías técnicas, el art. 35, apartado 7, letra d), también requiere procedimientos. Estos siguen pendientes:

Violación de seguridad de los datos personales. Detección: el propietario, la alerta de errores de la aplicación, notificaciones mediante el punto de notificación de vulnerabilidades o contact@lukaswojcik.com. Decisión sobre la notificación a UODO dentro de 72 horas (art. 33, apartado 1): el propietario. Información a los Clientes afectados como responsables del tratamiento: sin dilación indebida, de ser posible dentro de las 48 horas, según lo prometido en el Acuerdo de Tratamiento de Datos. Por determinar: una descripción escrita del procedimiento y un primer simulacro; para la verificación de entrega, además, cómo establecer qué Clientes se ven afectados por una violación de seguridad en el proveedor del buzón.
Sectores. Por determinar: si la verificación de entrega se ofrece, se ofrece con advertencia o se excluye para sitios web de salud, derecho, servicios sociales y educación.
Verificaciones internas. Por determinar: para qué utiliza el proveedor las verificaciones internas desde la línea de comandos, quién puede crearlas y cuánto tiempo permanecen sus resultados; y si, además de en el Registro de Actividades de Tratamiento, deben mencionarse en la Política de Privacidad.
Estudios. Por determinar: quién elabora listas, de qué fuentes, con qué tamaño máximo, y una comprobación antes de cada estudio de que cumpla los supuestos de esta evaluación.
Opinión de los interesados (art. 35, apartado 9). No se ha solicitado para esta versión. El art. 35, apartado 9, exige solicitarla solo «cuando proceda»; según nuestra evaluación, actualmente no procede aquí. Los operadores de sitios web verificados y los visitantes de sitios web de Clientes no tienen un canal propio hacia nosotros; contactarlos específicamente constituiría en sí un nuevo tratamiento de sus datos y el servicio aún no se ha lanzado, por lo que todavía no existe un grupo de interesados reales. Sus intereses se tienen en cuenta indirectamente: mediante robots.txt y exclusión, mediante los plazos cortos y mediante el hecho de que no se almacena el contenido de las copias de control. En cada revisión conforme a la sección 12 reconsideramos si procede solicitar su opinión, por ejemplo, mediante comentarios en la página del rastreador o de Clientes de la verificación de entrega.

10. Riesgo residual y consulta previa conforme al art. 36

El art. 36, apartado 1, exige consultar previamente a la autoridad de control cuando la EIPD indica que el tratamiento entrañaría un alto riesgo si el responsable no adopta medidas para mitigarlo. Por tanto, la cuestión no es si se identificaron riesgos altos —se identificaron cuatro—, sino si queda un alto riesgo una vez implementadas las medidas.

Para las operaciones de tratamiento de las que formexposed es responsable (P1 a P4, P7), los riesgos altos R4 y R13 pueden subsanarse por medios ordinarios: una vía de eliminación y una limpieza de los datos existentes, una copia de seguridad cifrada fuera de la ubicación y el refuerzo de dos servidores. Con las medidas de la sección 9.3, bajan a bajo o medio. R3, R5, R6 y R7 están en medio y bajan a bajo con las medidas propuestas. La protección colectiva sin redes IP permanece en bajo a medio. La consulta previa no está indicada para esta parte si las medidas marcadas como «primero» y «alta» se implementan antes del lanzamiento. Si alguna de estas medidas no se ha implementado antes del lanzamiento, queda un alto riesgo para la operación de tratamiento correspondiente. Esa operación solo se iniciará una vez implementada la medida, o se consultará primero a UODO conforme al art. 36, apartado 1.

Para la verificación de entrega (P6), la situación es distinta por un motivo que ninguna medida elimina por completo: lo que escribe un visitante depende de él. Con un contrato celebrado, recuperación protegida, limitación a mensajes de prueba cuando sea posible y renuncia al dominio del remitente, R2 baja a bajo y R1 a medio. Para Clientes cuyos visitantes proporcionan típicamente datos del art. 9, R1 puede, sin embargo, permanecer alto. La obligación de consultar corresponde entonces al Cliente como responsable del tratamiento, no a formexposed. Nuestra recomendación a esos Clientes es no configurar la copia de control para el formulario de contacto general, sino solo para formularios sin contenido sensible, o prescindir de la verificación de entrega.

Riesgo residual, declarado con honestidad. Hoy, con las medidas de la sección 9.1, cuatro riesgos están en alto: R1 y R2 (verificación de entrega), R4 (datos de verificaciones sin vía de eliminación) y R13 (infraestructura). Con las medidas de la sección 9.3, R2, R4 y R13 bajan a bajo o medio. R1 permanece en medio y depende permanentemente de decisiones tomadas por los Clientes. Ninguno de los demás riesgos supera el nivel medio después de las medidas.

El art. 36 no es una sanción y consultar no es una admisión. Es la vía que prevé el Reglamento para la situación en que un procedimiento útil conlleva un riesgo que el responsable del tratamiento no controla plenamente. Un Cliente que desee utilizar la verificación de entrega para mensajes con datos de salud encontrará aquí los hechos para esa decisión.

11. Qué necesitan los Clientes para su propia EIPD (art. 28, apartado 3, letra f))

Para la verificación de entrega y el escaneo detrás del inicio de sesión, el Cliente es responsable del tratamiento. Esta página le proporciona la descripción (secciones 6.5 y 6.6), los riesgos desde nuestra perspectiva (R1, R2, R8) y el estado de las medidas (sección 9). Solo el Cliente puede responder a las siguientes preguntas:

¿Qué escriben mis visitantes? ¿Cabe esperar que por el formulario lleguen datos sobre salud, religión, origen, afiliación sindical, orientación sexual, infracciones penales o sobre menores? Entonces, por regla general, se requiere una EIPD para la copia de control y debería reconsiderarse la copia de control para ese formulario.
¿Necesito la copia de control para todos los mensajes? Para demostrar que llega nuestro mensaje de prueba, basta con la copia de ese mensaje. Cuando el formulario lo permita, configure la copia oculta solo para mensajes de prueba.
¿Cómo informo a mis visitantes? El Acuerdo de Tratamiento de Datos lo exige; el Texto de Política de Privacidad para su Sitio Web describe la ruta de la copia y nuestro rol.
¿Qué base jurídica tengo? Nuestro texto sugerido menciona el art. 6, apartado 1, letra f) (recepción confiable de consultas). Para datos del art. 9, esta base por sí sola no es suficiente.
¿Qué canales de alerta elijo? Las alertas de la verificación de autenticidad pueden mencionar el dominio del remitente. Quien envía alertas a servicios de chat fuera de la UE lo transfiere allí.
Para el escaneo detrás del inicio de sesión: ¿Es la cuenta de prueba realmente una cuenta de prueba con los mínimos derechos necesarios? ¿Puede accederse a la página de inicio de sesión solo mediante https? ¿La cuenta de prueba ve datos de otros usuarios? Si es así, ¿en cuáles de las páginas especificadas?
¿Cuándo elimino? La verificación de entrega y la cuenta de prueba pueden desactivarse y eliminarse en cualquier momento; la cuenta de prueba se sobrescribe entonces permanentemente.

Otros documentos para la evaluación del Cliente: el Acuerdo de Tratamiento de Datos, las medidas técnicas y organizativas, la lista de subencargados del tratamiento y el Registro de Actividades de Tratamiento. Respondemos preguntas sobre hechos concretos en contact@lukaswojcik.com.

12. Revisión, versión y aprobación

El art. 35, apartado 11, exige una revisión para evaluar si el tratamiento se realiza de acuerdo con la EIPD, al menos cuando cambie el riesgo. Revisamos esta evaluación al menos anualmente y también antes de cada uno de los siguientes eventos; cada uno genera una nueva medición, no solo una lectura:

lanzamiento de la operación en producción, con cifras del sistema de producción en lugar del sistema de desarrollo;
primera activación de la verificación de entrega en el sistema de producción y celebración del contrato con el proveedor del buzón;
activación de redes IP en la protección colectiva;
el primer estudio y cada estudio con una lista más grande que la anterior;
activación de la segunda prueba o de un nuevo destinatario en la ruta de verificación;
cualquier nuevo uso del modelo de lenguaje que vaya más allá de los usos cubiertos por esta evaluación; el plan de acción priorizado en informes de pago es un uso agregado y requiere revisar la evaluación;
cualquier cambio en las capturas de pantalla, los plazos o los requisitos previos de las verificaciones activas.

Elemento	Entrada
Responsable del tratamiento	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland · NIP 7252266190 · contact@lukaswojcik.com
Autoridad de control competente	Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa, Poland
Delegado de protección de datos	No designado; evaluación conforme al art. 37 en la sección 4
Base de los hechos	Código fuente de la aplicación y del servicio de verificación, esquema de la base de datos, recuentos de filas y configuración del sistema de desarrollo, medidos el 11 de octubre de 2026, en modo de solo lectura
Documentos relacionados	Política de Privacidad, Acuerdo de Tratamiento de Datos, Medidas Técnicas y Organizativas, Subencargados del Tratamiento, Registro de Actividades de Tratamiento, Reglamento de IA de la UE, Uso Aceptable y Abuso, FormExposedBot, Exclusión
Versión	1.1 del 23 de octubre de 2026; complemento factual sobre la etapa local de plan de acción a la primera versión del 11 de octubre de 2026
Revisiones conforme al art. 35, apartado 11	23 de octubre de 2026: revisión del código fuente de la etapa local de plan de acción agregada. Se agregaron a las secciones correspondientes los datos de entrada, el almacenamiento, los roles, la salida orientativa y las garantías implementadas; no se afirma ninguna medición en producción completada ni nueva calificación del riesgo residual. Las mediciones anteriores del 11 de octubre de 2026 y el estado de aprobación siguiente permanecen sin cambios. Las revisiones adicionales se registran aquí con fecha, motivo y resultado.
Aprobación	Aún no aprobada. Aprobación por el propietario después de la revisión jurídica y de una decisión sobre las medidas de la sección 9.3 y las preguntas de la sección 9.4. Hasta ahora no se ha solicitado asesoramiento externo en protección de datos.

Una observación final corresponde al documento, no a una carta de presentación. Las partes de formexposed que más se adentran en dominios de otras personas —los envíos de prueba y el inicio de sesión con credenciales ajenas— están construidas con la mayor cautela: dos controles, límites estrictos, cifrado que incluso nos deja fuera a nosotros. Los riesgos de esta evaluación se encuentran principalmente en otra parte: en lo que se incluye de forma incidental, como mensajes auténticos en una copia oculta, personas en una captura de pantalla o verificaciones que ya nadie elimina. Es una posición de partida favorable, porque lo incidental puede detenerse sin cambiar el servicio.

¿Cómo podemos ayudarle?