Web scraping, formularios y terceros: el elefante legal de tu web (más allá de las cookies)

En los dos primeros post de esta serie nos hemos movido en terreno “clásico”: cookies, píxeles, consent banners y patrones oscuros.
En este tercero miramos a un riesgo que muchas organizaciones siguen infravalorando: la captura masiva de datos (web scraping), los formularios y todo el ecosistema de terceros que vive detrás de una web o app.

Desde la óptica GRC (Gobierno, Riesgo y Cumplimiento), este es el punto donde el front-end bonito se convierte en un posible incidente regulatorio serio.

1. Web scraping: “si los datos son públicos, no pasa nada”… ¿seguro?

Muchas estrategias digitales se apoyan en scrapers para:

• recopilar perfiles de redes sociales,
• monitorizar precios y competidores,
• enriquecer bases de datos comerciales,
• alimentar modelos de IA con datos “públicos”.

El mensaje de las autoridades ya no deja lugar a dudas:

“Datos accesibles públicamente ≠ datos libres de derechos”.

La declaración conjunta sobre data scraping y protección de la privacidad, firmada por 12 autoridades (ICO y otras DPAs de todo el mundo), subraya que el scraping masivo de datos personales de redes sociales y webs puede constituir una violación de protección de datos y, en muchos casos, un data breach que debe notificarse.
Joint Statement on Data Scraping, GPA/ICO

El mensaje es simple y demoledor: aunque el dato esté visible, el RGPD sigue aplicando y hay que respetar principios como licitud, minimización, transparencia, limitación de la finalidad y seguridad (art. 5 y 6 RGPD).

Un buen resumen práctico de esta lógica lo recoge el análisis “Data Scraping + Personal Data = Data Protection Rules Apply”, que recuerda que casi todo scraping de datos personales implica tratamiento sometido a RGPD, con necesidad de base jurídica, información y, en muchos casos, EIPD.
William Fry, Data Scraping + Personal Data = Data Protection Rules Apply

2. El giro de tuerca: las directrices de la autoridad neerlandesa (AP)

Si hablamos de señales fuertes para el mercado, pocas son tan claras como las “Guidelines for scraping by private individuals and private organisations” de la autoridad de protección de datos neerlandesa (AP).

El mensaje de la AP es casi de eslogan:

“Scraping by private parties and individuals is almost never allowed”.

AP – Guidelines for scraping by private individuals and private organisations

Puntos clave desde la perspectiva GRC:

• El RGPD normalmente aplica al scraping, incluso si los datos son públicos.
• La base jurídica de interés legítimo solo será válida en supuestos muy concretos (p. ej. seguridad, integridad de sistemas, casos limitados de análisis de reputación), pero no para construir perfiles comerciales masivos o enriquecer CRM sin expectativas razonables del interesado.
  Netherlands AP – Data scraping guidelines overview
• El scraping a gran escala suele exigir evaluación de impacto (EIPD) antes de poner el tratamiento en marcha.
• La AP insiste en revisar:
  • quién publicó el dato (la persona o un tercero),
  • las expectativas razonables del interesado,
  • los términos de uso del sitio de origen,
  • las consecuencias del scraping para los derechos de las personas.
    Arnold & Porter – Data scraping guidelines summary

Para una mirada más académica y crítica, es muy útil el análisis sobre scraping y reconocimiento facial de F. Lala, que conecta estas prácticas con los principios de privacidad desde el diseño (art. 25 RGPD).
Lala, Data collection via web scraping: privacy and facial recognition

3. Formularios, analítica y “herramientas inocentes” que no lo son

Más allá del scraping activo, el stack típico de una web/app moderna puede comprometer gravemente la posición del responsable del tratamiento:

• Formularios de contacto, lead magnets, newsletters y pruebas gratuitas conectados a CRM externos.
• Scripts de analítica web (p. ej. Google Analytics u otras suites sofisticadas).
• CDNs de fuentes y librerías (Google Fonts, icon packs, frameworks).
• Herramientas de session replay, heatmaps, A/B testing y grabación de pantalla.
• Widgets de chat, chatbots, plugins sociales y sistemas de login federado.
• Soluciones de marketing automation y retargeting con perfiles muy granulares.

Desde el prisma GRC:

• Gobernanza:

  • ¿Existe un inventario claro de todas las herramientas y scripts que se cargan?
  • ¿Quién aprueba su uso (marketing, TI, DPO, comité de riesgos)?

• Riesgo:

  • ¿Se ha valorado el riesgo de cada integración (incluidas las transferencias internacionales)?
  • ¿Se ha tenido en cuenta la jurisprudencia europea sobre transferencias a EE. UU. tras Schrems II y los requisitos del nuevo Data Privacy Framework?

• Cumplimiento:

  • ¿Se firmaron contratos de encargado (art. 28 RGPD) con todos los terceros que tratan datos?
  • ¿Se ha informado al usuario con transparencia real (art. 13 y 14 RGPD), no solo con un texto genérico?

En la práctica, muchos de estos riesgos se materializan conjuntamente: formularios + analítica + scraping posterior de redes sociales para enriquecer perfiles con datos “públicos”. Desde la lógica de las autoridades, esto es un cóctel perfecto para una investigación.

4. Lecciones clave para responsables, DPOs y desarrolladores

A partir de las posiciones de las autoridades (GPA/ICO, AP neerlandesa) y la literatura reciente, se pueden extraer algunas lecciones muy operativas:

1. “Público” no significa “libre”:
   Si el dato identifica (o es identificable), el RGPD aplica. El scraping masivo, sin base jurídica sólida y sin información al interesado, es terreno de alto riesgo regulatorio.
   Joint Statement on Data Scraping, GPA/ICO
2. El interés legítimo no es un cajón desastre:
   La AP limita su uso a intereses protegidos legalmente, no puramente comerciales, y exige un test de proporcionalidad robusto.
   AP – Guidelines for scraping
3. Scraping + enriquecimiento de perfiles = casi siempre EIPD:
   Especialmente si se trata de scraping a gran escala, combinación de fuentes, perfilado o toma de decisiones con efectos relevantes sobre las personas.
   William Fry – Data Scraping + Personal Data = Data Protection Rules Apply
4. Los desarrolladores también “juegan en RGPD”, les guste o no:
   Elegir librerías, SDKs y servicios externos sin revisar condiciones, transferencias o configuraciones de privacidad puede convertir a la organización (y en algunos casos a la propia empresa de desarrollo) en corresponsable del tratamiento.
5. Documentar es tan importante como configurar bien:
   Si mañana entra un requerimiento de la autoridad, necesitas enseñar:
   • análisis de base jurídica,
   • EIPD (donde aplique),
   • contratos con terceros,
   • decisiones técnicas sobre minimización y limitación de finalidad (art. 25 RGPD).

5. Checklist rápido GRC para webs y apps (especial foco en scraping y terceros)

Para ir bajando esto a práctica, una mini lista de verificación que se puede integrar en el modelo de control interno:

1. Mapa técnico-jurídico del sitio/aplicación

   • Inventario de scripts, SDKs, APIs y terceros cargados en cada plantilla.
   • Identificación de qué datos personales recoge cada uno, con qué finalidad y a dónde se envían.

2. Política de uso de scraping y fuentes externas

   • ¿Se permite el uso de scraping en la organización? ¿En qué casos?
   • ¿Quién debe autorizarlo (jurídico + DPO + negocio)?
   • ¿Está prohibido el scraping de redes sociales para fines comerciales sin análisis previo?

3. Criterios para seleccionar herramientas de analítica y marketing

   • Configuraciones por defecto respetuosas (privacy by default).
   • Preferencia por soluciones con hosting y soporte jurídico compatibles con RGPD.
   • Transferencias internacionales analizadas y documentadas.

4. Procedimiento de EIPD y revisiones periódicas

   • Umbrales claros para gatillar una EIPD (p. ej. scraping a gran escala, perfilado intensivo, uso de IA entrenada con datos externos).
   • Revisiones periódicas de las herramientas integradas: lo que era aceptable hace dos años puede no serlo hoy.

5. Formación específica a desarrolladores y equipos de marketing

   • No solo RGPD “genérico”: sesiones centradas en casos reales de sanciones por scraping y malas integraciones técnicas.
   • Lenguaje práctico: qué puedo hacer, qué no y cómo justificarlo.

Cierre

En GRCx3 entendemos la web y las apps como un espacio donde confluyen:

• decisiones técnicas,
• estrategias de negocio,
• y un marco regulatorio internacional cada vez más exigente.

Este tercer post cierra el primer bloque dedicado a la “capa web” de la privacidad: cookies, patrones oscuros, scraping, formularios y terceros.

En los siguientes bloques entraremos en chatbots, decisiones automatizadas y auditoría de sistemas de IA, siempre con la misma lógica: conectar práctica tecnológica, riesgo real y cumplimiento normativo con referencias sólidas y actuales.