La legalidad del web scraping en 2026: precedentes judiciales, GDPR, 152-FZ y prácticas

Introducción: por qué es importante para los negocios entender el marco legal del web scraping en 2026

El web scraping ha pasado de ser una herramienta para ingenieros a convertirse en una disciplina clave en la gestión de datos. En 2026, su legalidad está determinada no solo por tecnologías, sino también por las sutilezas del derecho internacional: precedentes judiciales en EE.UU., la aplicación del GDPR en Europa, las regulaciones rusas (152-FZ) y la postura de Roskomnadzor. Como resultado, una misma acción puede ser legal en una jurisdicción, permitida con condiciones en otra y arriesgada en una tercera. Esta guía te ayudará a navegar con confianza en el marco legal, a construir cumplimiento "desde el diseño", minimizar riesgos y extraer el máximo valor de los datos abiertos, sin conflictos con reguladores y titulares de derechos.

¿Qué obtendrás? Una comprensión sistemática de las categorías legales de datos; un resumen actualizado de los precedentes (incluido el caso hiQ vs LinkedIn en los últimos años), la práctica de los reguladores europeos y los tribunales rusos; marcos claros para evaluar la legalidad; instrucciones paso a paso para establecer procesos; listas de verificación; herramientas; casos reales y errores comunes. Hablamos en un lenguaje sencillo, pero con profundidad profesional, para que puedas implementar las prácticas correctas desde hoy.

Nota importante: este material proporciona información legal general y recomendaciones analíticas. No es un asesoramiento legal y no crea relaciones cliente-abogado. Consulta a un abogado familiarizado con tu industria y jurisdicciones antes de tomar decisiones.

Fundamentos: qué es el web scraping y cómo el derecho ve los datos

Términos clave y su significado legal

• Web scraping — extracción automatizada de datos de páginas HTML o APIs de acceso público. Legalmente significativo: modo de acceso (público/restringido), existencia de barreras técnicas, condiciones de uso.
• Datos abiertos — información accesible sin barreras para la lectura humana. Importante: la "apertura" no anula derechos de autor, derechos conexos, derechos sobre bases de datos y requisitos sobre datos personales.
• Datos personales (DP) — en la UE/EEE según el GDPR, cualquier información relacionada con una persona identificada o identificable. En Rusia, según el 152-FZ, cualquier información relacionada con un ciudadano ruso determinado directa o indirectamente.
• DP públicamente disponibles — en la UE: datos personales publicados por el sujeto o una tercera parte; siguen siendo DP bajo un conjunto completo de requisitos legales. En Rusia: después de las enmiendas de 2021, se requiere un consentimiento separado para la difusión; la publicación no implica uso libre.
• Condiciones de uso (ToS) — disposiciones contractuales del sitio web o API. Su incumplimiento conlleva consecuencias civiles y, en algunas jurisdicciones, puede estar relacionado con normas sobre acceso improcedente, si se evaden medidas técnicas.
• robots.txt — archivo con recomendaciones para robots web. Reglas técnicas de indexación y navegación. En la mayoría de los ordenamientos jurídicos no tiene fuerza legal en sí mismo, pero ignorarlo puede incrementar riesgos (demuestra mala fe).
• API vs HTML — acceso a través de API generalmente está licenciado y formalizado, mientras que el scraping de HTML se orienta a la publicidad de la interfaz. Desde el punto de vista legal, el API es preferible, pero más estricto en restricciones contractuales.

Ejes legales principales de evaluación

• Jurisdicción: dónde te encuentras, servidores, usuarios y sujetos de datos.
• Tipo de datos: personales/no personales; secretos comerciales; derechos de autor y derechos conexos; derechos sobre bases de datos (en la UE).
• Método de acceso: página pública sin registro vs con inicio de sesión, sortear CAPTCHAs y muros de pago, uso de sesiones.
• Objetivo del procesamiento: periodismo, investigación, compatibilidad, competencia, análisis comercial, seguridad.
• Volumen y frecuencia: "razonable" extracción de elementos individuales vs copia sistemática de una parte sustancial de la base.

Profundización: marcos legales globales y tendencias

EE.UU.: caso hiQ vs LinkedIn y posiciones relacionadas

El caso hiQ vs LinkedIn ha establecido el tono del debate en torno al scraping de perfiles públicos durante años. A finales de 2024, los tribunales han reafirmado: el acceso a páginas públicas sin evadir autenticación no constituye por sí mismo acceso "no autorizado" según la ley estadounidense sobre fraude informático (CFAA), especialmente después de la sentencia del caso Van Buren. Sin embargo, existen otros mecanismos legales: reclamos contractuales bajo ToS, protección de bases de datos y contenidos, competencia desleal, trespass to chattels y otras teorías. Varios disputas importantes han terminado en acuerdos y/o aclaraciones de prácticas de plataformas. En 2025-2026, las empresas deberán estar atentas a cualquier nuevo giro en casos similares en tribunales federales, pero por ahora la línea fundamental para las páginas públicas permanece: el CFAA se aplica con cautela, sin extenderse a "solo lectura" de lo que está disponible al público.

Conclusión práctica: en EE.UU., el scraping de páginas públicas sin eludir autenticación no equivale a un ataque criminal informático. Sin embargo, infringir ToS e ignorar protocolos oficiales (incluyendo robots.txt) puede aumentar los riesgos civiles y llevar a la corte, especialmente en casos de copias masivas o parasitismo comercial.

UE/EEE: GDPR, ePrivacy y derechos sobre bases de datos

• GDPR: cualquier dato personal de fuentes públicas sigue siendo DP. Se requiere una base legal (frecuentemente, "interés legítimo"), información según el artículo 14 (o justificación de la excepción), minimización, plazos de retención, seguridad y mecanismos para los derechos de los sujetos. Los reguladores (por ejemplo, CNIL, DPC irlandés y otros) han subrayado repetidamente: "la publicidad" no significa "sin control". La falta de cumplimiento de los principios puede llevar a multas significativas, como lo demuestran las investigaciones sobre filtraciones masivas y scraping que han resultado en agregación no autorizada de perfiles.
• Decisiones de reguladores: las agencias de supervisión europeas han impuesto multas significativas por insuficiente protección contra scraping (como una manifestación de insuficiencia de medidas de "privacy by design" en los operadores que publican datos), así como por el procesamiento ilegal posterior por parte de scraper. La práctica de servicios que forman perfiles biométricos y de comportamiento basados en imágenes públicas y páginas demuestra una postura estricta hacia el procesamiento poco transparente y la falta de base legal.
• Derecho sui generis sobre bases de datos (Directiva 96/9/CE): prohíbe la extracción o reutilización de una parte sustancial de una base y la extracción sistemática de partes no sustanciales, si causa daño. Casos clave del Tribunal de la UE subrayan que metabuscadores y clones de bases que reproducen el valor económico de la fuente están bajo prohibición. Esto es crítico para proyectos que construyen productos en el "reflejo" de bases ajenas.

Rusia: 152-FZ y postura de Roskomnadzor

En Rusia, cualquier información sobre una persona identificable es datos personales. Las enmiendas de 2021 han endurecido el régimen de "DP públicos": se requiere un consentimiento separado para su difusión con posibilidad de establecer condiciones de acceso. Un agregador que reúne tales datos se convierte en operador de DP con todas las obligaciones: objetivos, bases legales, notificación a Roskomnadzor (en los casos previstos), localización (242-FZ), derechos de los sujetos, seguridad.

La práctica judicial y supervisión en Rusia se basan en el hecho de que la mera colocación de información en internet no otorga una "licencia libre". El scraping ilegal de datos personales y su publicación por agregadores llevan a demandas por protección de la vida privada, decisiones de Roskomnadzor y multas administrativas. Para datos no personales, las cuestiones clave son derechos de autor, secretos comerciales y competencia desleal. El incumplimiento de limitaciones técnicas y la violación de la protección entran bajo normas penales sobre acceso improcedente a información informática.

Robots.txt, ToS, API: cómo el derecho ve las señales técnicas y contractuales

• robots.txt: legalmente se interpreta más a menudo como una política técnica, no como prohibición en sentido estricto de la ley. Pero es importante como evidencia: ignorarlo puede mostrar intención de eludir reglas claras, y combinado con ToS y CAPTCHAs, aumenta las probabilidades de perder una disputa.
• ToS: en la UE, el incumplimiento de ToS es una cuestión contractual; en EE.UU., un riesgo de demandas civiles (contracto, ilícito). En Rusia — oferta pública / contrato de adhesión. Clave: ¿aceptaste ToS (acuerdo), cómo se comunicó y hay justificación de uso legítimo?
• API: los acuerdos de licencia y límites de tasa crean marcos legales claros. Ventajas: previsibilidad y calidad de datos. Desventajas: restricciones en volumen y objetivos. Intentos de eludir límites de API mediante scraping HTML o proxies a menudo aumentan riesgos.

Tendencias 2026

• Enfoque en el "deber de cuidado" de las plataformas: los reguladores aumentan las expectativas hacia los propietarios de sitios para prevenir scraping ilegal de datos personales y notificar a los usuarios sobre riesgos.
• Localización y soberanía de datos: más requisitos para almacenar copias de DP localmente y limitar la transferencia transfronteriza.
• Transparencia en la cadena de suministro de datos: desde la fuente hasta el consumidor — requiere fundamentos legales y contratos verificables.
• Ética y confianza: las empresas compiten no solo por el volumen de datos, sino también por la "ética" de su origen y procesamiento.

Práctica 1: Marco de evaluación legal del scraping de A a Z

Paso 1. Mapeo de datos y objetivos

1. Describe los objetivos del scraping: análisis de precios, investigaciones de mercado, objetivos científicos, control de calidad, monitoreo de riesgos.
2. Clasifica el tipo de datos: personales, metadatos, datos comerciales ordinarios (precios, SKU, horarios), elementos protegidos (biometría, identificadores financieros).
3. Evalúa la disponibilidad: página pública, si se necesita registro, si hay CAPTCHA, muro de pago, tokens.
4. Define jurisdicciones: dónde te encuentras, dónde está el servidor, dónde están los sujetos de datos, hacia dónde se transfieren los datos.

Paso 2. Selección de la base legal (GDPR) y régimen legal (Rusia)

• UE/EEE (GDPR): lo más común — "interés legítimo" (art. 6(1)(f)). Es necesario llevar a cabo una Evaluación de Interés Legítimo (LIA): describir el interés, necesidad del procesamiento, evaluar el equilibrio con los derechos de los sujetos, implementar medidas de protección (minimización, seudonimización, limitación de objetivos).
• Rusia (152-FZ): determina si no estás procesando datos personales. Si es así, se requiere una base legal: consentimiento, ley, contrato, otros fundamentos previstos. Para "DP públicos", verifica la existencia de consentimiento separado para la difusión y condiciones de acceso. Ten en cuenta la localización (242-FZ) y la notificación a Roskomnadzor si es necesario.

Paso 3. Transparencia y notificación

• GDPR art. 14: si los DP se recopilan sin el sujeto, se requiere información. Excepciones son posibles si proporcionar información es imposible o requiere esfuerzos desproporcionados; en ese caso, coloca información general pública sobre tu procesamiento, asegura facilidad en la realización de los derechos de los sujetos, documenta evaluación de proporcionalidad.
• Rusia: informa a los sujetos en el marco de tu política de DP; proporciona mecanismos para solicitar y eliminar. Para datos con restricciones de difusión, cumple con el régimen establecido por el sujeto.

Paso 4. Limpieza contractual

• Analiza ToS de la fuente: existe una prohibición de recolección automatizada, limitación de uso comercial, condiciones de licencia.
• Verifica posibilidades de API: si API está disponible y cubre las necesidades, normalmente es preferible.
• Evalúa el derecho sobre la base de datos (UE): hay riesgo de extraer una parte sustancial o reproducir sistemáticamente el contenido.

Paso 5. DPIA y medidas de protección

• Si el riesgo es alto (DP masivos, perfiles, grupos vulnerables) — realiza un DPIA: amenazas, medidas, riesgo residual, plan de minimización.
• Implementa minimización: recoge solo los campos necesarios, almacena lo menos posible, elimina según un horario.
• Controla transferencias transfronterizas: UE — cláusulas contractuales estándar y evaluación del país de destino.

Paso 6. Registros y procedimientos operativos

• RoPA (registro de tratamientos): objetivos, categorías de datos, destinatarios, plazos de retención, medidas de seguridad.
• Procedimientos DSR (solicitudes de sujetos): acceso, eliminación, oposición al procesamiento.
• Gestión de incidentes: política de notificación de violaciones, comunicación interna, plan de respuesta.

Conclusión: matriz de toma de decisiones

Resume todo en un "mapa de riesgos": tipo de datos × método de acceso × jurisdicciones × objetivo. Zona verde: públicos no DP, API, licencia explícita. Amarilla: DP públicos con LIA, notificación, minimización. Roja: eludir barreras, copia sistemática de base, categoría especial de DP.

Práctica 2: Diseño técnico y ética del scraping

Principios de "privacy & compliance by design"

• Respeto hacia la fuente: sigue robots.txt como política base; si algo está prohibido, evalúa los fundamentos legales y medidas auxiliares o busca fuentes alternativas.
• Limitación de tasa y carga: establece restricciones de solicitudes, utiliza caché y períodos de "sueño"; revisa las horas pico para no interrumpir el funcionamiento del recurso.
• Identifícate: User-Agent claro, correo electrónico de contacto para quejas; esto reduce el riesgo de escaladas.
• Calidad de datos: verifica validez, almacena hashes y fecha de scraping; documenta la fuente para auditoría.
• Minimización: no recojas campos sensibles sin necesidad; aplica seudonimización.
• Seguridad: cifrado en almacenamiento y tránsito, control de acceso, registro, identificadores encriptados para trazabilidad.

Implementación paso a paso

1. Escaneo: auditoría de robots.txt y ToS, mapa de URL y patrones de datos, evaluación de CAPTCHA y dinámica de la página.
2. Plan de solicitudes: límite de frecuencia, ventanas de tiempo, reintentos con retraso exponencial, caché a nivel de resultado.
3. Extracción: parsing con esquema explícito, omitir campos que no están en el objetivo.
4. Limpieza: filtrado, normalización, eliminación de campos personales obvios cuando falta base legal.
5. Almacenamiento: segmentación por fuentes, duración de datos, políticas de eliminación.
6. Control: monitoreo de errores, 4xx/5xx, retroalimentación a la fuente en caso de fallos.

Normas éticas

• No causes carga que interrumpa el funcionamiento normal del sitio.
• No evadas barreras técnicas de acceso ni imites el comportamiento de usuarios reales sin autorización.
• Respeta las solicitudes de exclusión y eliminación de datos.
• Considera los intereses de los sujetos de datos, incluso si hay una base legal formal.

Práctica 3: Estrategia jurídico-contractual: ToS, licencias, API

Modelo "negocia o limita"

• Primera opción — API: si cubre los objetivos comerciales, formaliza el acceso. Ventajas: previsibilidad, SLA, certidumbre legal. Desventajas: límites y costos.
• Licencia de contenido: si utilizas datos sistemáticamente de un sitio externo, considera un acuerdo de licencia. Es más barato que ir a juicio si los datos son críticos.
• Scraping consciente de ToS: si las ToS prohíben bots, verifica la posibilidad de autorización por escrito, programas de bajo volumen, colaboración.

Verificación de derechos sobre base y contenido

• UE: evalúa si estás extrayendo "parte sustancial" de la base o reproduciendo su valor económico. Solicitudes regulares que replican la base son arriesgadas.
• Derechos de autor: textos, imágenes, estructuras de página; citación y uso legítimo son limitados.

Marco de análisis precontractual

1. Valor comercial de los datos y alternativas.
2. Volumen y frecuencia de acceso.
3. Régimen de los datos (DP/no DP), jurisdicciones, transferencias transfronterizas.
4. Modelos de licencia y costo de cumplimiento vs riesgo judicial.

Práctica 4: Infraestructura y proxies: cómo hacerlo legal y transparentemente

Orientaciones legales al utilizar proxies

• Objetivo: los proxies son aceptables para balancear tráfico, pruebas geográficas, resistencia y privacidad de la infraestructura, pero no para eludir restricciones de acceso o disfrazar violaciones a las ToS.
• Legalidad y consentimiento: utiliza solo proveedores que obtienen recursos y consentimientos de propietarios de IP de salida legalmente (especialmente en el caso de proxies móviles). Excluye botnets no autorizados y redes grises.
• Transparencia: documenta fuentes de IP, geografía, si has obtenido permiso para jurisdicciones específicas y cómo se manejan quejas.

Modelo operativo sin eludir prohibiciones

1. Política de proxies: documento que prohíbe el uso de proxies para eludir CAPTCHAs, muros de pago, autenticación y límites de tasa establecidos por el propietario del sitio.
2. Segmentación: divide los grupos de proxies para pruebas, producción y retroalimentación, para investigar incidentes.
3. Límites éticos: a nivel de código y puerta de enlace de proxies, establece un límite de frecuencia de solicitudes que sea inferior al promedio de un usuario y respeta ventanas de "silencio".
4. Registros: lleva registros (identificadores encriptados) para responder a reclamaciones y evitar abusos.
5. Registro de fuentes: para cada proveedor — contrato, jurisdicción, contacto, SLA por notificaciones de abuso.

Proxies móviles: cuándo es adecuado y cómo hacerlo seguro

• Casos de uso: pruebas geográficas de interfaces móviles, verificación de disponibilidad, medición de velocidad y calidad.
• Control de cumplimiento: auditoría de proveedores sobre la legalidad de fuentes de IP; aseguramientos por escrito sobre consentimiento de usuarios finales; procesos de respuesta a quejas.
• Medidas técnicas: listas blancas de dominios (a dónde se permiten solicitudes), limitación de velocidad, prohibición de enviar identificadores personales a través de proxies sin cifrado.

Esencial: los proxies son herramientas de ingeniería de red, no medios para eludir prohibiciones. Cualquier escenario "para eludir bloqueos y detección" aumenta el riesgo jurídico y va contra la ética.

Práctica 5: Documentación de procesos: haz el cumplimiento verificable

Artefactos para auditor/a y regulador

• Mapa de datos: fuentes, categorías de datos, campos, jurisdicciones, objetivos.
• RoPA: registro de procesamiento para cada objetivo; se actualiza con cambios.
• LIA: justificación de interés legítimo (UE), equilibrio con derechos de los sujetos, medidas de mitigación.
• DPIA: para escenarios de alto riesgo (perfilado masivo, datos sensibles).
• Políticas: política de scraping, política de proxies, política de almacenamiento y eliminación, política de respuesta a incidentes.
• Plantillas de notificaciones: página de transparencia (Art. 14), respuestas a DSR, procesos de revocación de consentimientos (Rusia: condiciones de difusión de DP).

Operationalización paso a paso

1. Designa a un responsable del proceso (Data Steward) y vinculación Legal × Engineering × Security.
2. Describe un pipeline end-to-end: recolección, procesamiento, almacenamiento, acceso, eliminación.
3. Establece KPI: tiempo de respuesta a DSR, proporción de campos minimizados, promedio de vida útil de datos, éxito de auditorías.
4. Realiza ejercicios de tabletop: escenario de queja de sujeto de datos, solicitud de regulador, reclamación de titular de derechos.
5. Implementa revisiones periódicas de ToS y robots.txt de fuentes clave.

Plantillas que debes tener

• Plantilla LIA (forma corta: objetivo, necesidad, equilibrio, medidas, conclusión).
• Plantilla DPIA (registro de riesgos, probabilidades, impactos, contramedidas).
• Plantilla de respuesta a DSR (incluyendo identificación del solicitante, plazos, excepciones).
• Plantilla de solicitud de permiso para scraping a propietario del sitio (describiendo volumen, objetivos, frecuencia, contactos).

Práctica 6: Contenido y SI: cómo no cruzar la línea

Derechos de autor

• Qué está protegido: textos, fotografías, diseño, código; hechos en sí mismos — no, pero su selección y disposición pueden estar protegidos.
• Uso legítimo: es limitado, dependiendo de la jurisdicción; no cuentes con ello como estrategia principal.

Derecho sobre bases de datos (UE)

• Evita extracción sustancial y copia sistemática de partes no sustanciales que restauren el valor económico.
• Medidas técnicas: muestreo selectivo, agregación sin reconstruir la fuente, enlaces a la fuente original para verificación.

Secreto comercial y competencia desleal

• No extraigas secciones cerradas; no utilices secretos ajenos que se hayan hecho accesibles mediante el eludir barreras.
• No crees una ilusión de asociación o afiliación con la fuente si no existe.

Práctica 7: API vs HTML: cómo elegir y combinar

Cuándo es mejor usar API

• Existen necesidades sostenibles y procesos críticos bajo SLA.
• Requiere soporte legal y técnico.
• Es importante cumplir límites y licencias, así como recibir actualizaciones de esquemas.

Cuándo es apropiado HTML

• Los datos son simples, no personales, no hay API, y el acceso público es evidente.
• Se necesita una instantánea rápida del mercado.

Modelo híbrido

• El flujo principal — a través de API; HTML — como respaldo para validación y cierre de brechas, bajo estrictos límites y reglas éticas.

Errores comunes: qué NO hacer

• Ignorar ToS y robots.txt "porque técnicamente es posible".
• Recoger todo indiscriminadamente: violación del principio de minimización.
• Almacenar indefinidamente: falta de plazos de eliminación y actualización.
• Transferir datos a través de fronteras sin mecanismos legales.
• Falta de notificaciones y transparencia según el Art. 14 (UE) o requisitos del 152-FZ.
• Utilizar proxies dudosos, relacionados con botnets y violación de consentimientos de propietarios.
• Eludir CAPTCHAs y autenticación: alto riesgo legal y reputacional.

Herramientas y recursos: qué usar

Herramientas legales y de cumplimiento

• Generadores y plantillas LIA/DPIA y registros de tratamientos.
• Plataformas para gestión de DSR y auditoría.
• Sistemas data lineage y catálogos de datos para transparencia de fuentes.

Herramientas técnicas

• Frameworks de scraping que soportan limitación de tasa, reintentos y caching.
• Herramientas de anonimización y seudonimización.
• SIEM/registro, control de acceso, cifrado a nivel de base y canal de transporte.

Prácticas operacionales

• Revisiones periódicas de ToS y robots.txt de dominios clave.
• Listas de verificación internas antes de lanzar una nueva fuente.
• Capacitación del equipo en ética de scraping y principios de "minimización".

Casos y resultados: de la práctica empresarial

Caso 1: Monitoreo de precios sin DP

La empresa X vende electrónica. Objetivo — monitorear diariamente los precios de la competencia. Datos: nombres de productos, SKU, precio, disponibilidad. Acciones: análisis de ToS (sin prohibición de indexación; hay prohibiciones de copia masiva de contenido). Técnico: uso agresivo de caché, acceso sin registro, limitación de tasa de 0.1 RPS por dominio, ventanas nocturnas. Derecho: no DP; análisis de derechos sobre base (UE) — solo posiciones selectivas; no hay reconstrucción de base. Resultado: feed estable sin quejas, reducción de gastos de compra del 3.7%, sin incidentes durante 12 meses.

Caso 2: Agregador de vacantes (UE)

La empresa Y recopila vacantes de sitios de empleadores. Datos: títulos, descripciones, ubicaciones, a veces correos electrónicos de contacto de reclutadores (DP). Derecho: LIA, Art. 14 información a través de página pública y mecanismo de exclusión para direcciones de contacto, eliminación de direcciones al primer contacto, minimización (almacenamiento de correos en formato encriptado hasta contacto del empleador). Trabajo contractual: propuestas de licencias a grandes sitios donde ToS prohíben bots. Resultado: 10 acuerdos de asociación, mantenimiento de cumplimiento, ausencia de multas; crecimiento de cobertura de mercado del 18%.

Caso 3: Analista de marketing ruso

La empresa Z analiza perfiles públicos de ejecutores en plataformas de freelancers. Datos: apodo, portafolio, tarifas, reseñas; pueden incluir DP. Derecho ruso: determinación del operador de DP, notificación de actividades, localización de copias en Rusia, política de procesamiento; exclusión de índice a petición; recolección únicamente de campos públicos; exclusión de teléfonos y correos electrónicos (si no hay consentimiento explícito para la difusión). Resultado: producto jurídicamente limpio, ausencia de prescripciones, lealtad de las plataformas (intercambio de feeds).

FAQ: 10 preguntas clave

1. ¿Es legal hacer scraping de páginas sin iniciar sesión?

Si la página es pública y no se eluden barreras técnicas, en muchas jurisdicciones esto no se considera acceso ilegal. Pero siguen existiendo riesgos: violación de ToS, base de datos (UE), DP (GDPR/152-FZ). Verifica la base legal, minimización, notificación y respeta robots.txt.

2. ¿Cómo se relaciona el derecho con robots.txt?

Es una recomendación técnica, no una ley. Sin embargo, ignorarlo puede aumentar las pruebas de mala fe y violaciones de ToS. En la práctica de cumplimiento, robots.txt debe ser respetado por defecto.

3. ¿Se necesita una base legal según GDPR si los datos son públicos?

Sí. La publicidad no elimina los requisitos del GDPR. Normalmente, el interés legítimo con LIA es adecuado. Es obligatorio minimizar, asegurar transparencia (art. 14), plazos de almacenamiento y mecanismos para derechos de los sujetos.

4. ¿Qué ha cambiado en el caso hiQ vs LinkedIn hasta 2026?

A finales de 2024, la línea básica es: el scraping de páginas públicas sin evadir autenticación no es un delito bajo CFAA por sí mismo. Durante 2025-2026, presta atención a nuevas decisiones en disputas similares. No confíes en CFAA como "indulgencia": ToS, derechos de autor, bases de datos y otras normas siguen vigentes.

5. ¿Se pueden hacer scraping de correos electrónicos de contacto?

El riesgo es elevado, ya que son DP. Para la UE — LIA y notificación según Art. 14 o excepción, estricta minimización y objetivo. Para Rusia — fundamentos bajo 152-FZ y respeto a condiciones de difusión. En algunos casos, es mejor excluir los correos electrónicos de la recolección primaria.

6. ¿Qué hay de los proxies móviles?

Utiliza solo fuentes legales, no para evadir prohibiciones. Establece políticas, limita la velocidad, lleva registros y responde a quejas. Sortear CAPTCHAs/autenticaciones a través de proxies aumenta el riesgo de violaciones.

7. ¿Qué riesgos conlleva violar ToS?

Demandas civiles, bloqueos, posibles reclamaciones por competencia desleal y derechos de propiedad intelectual. En ciertos escenarios, el conjunto de acciones puede interpretarse como acceso improcedente.

8. ¿Es necesario notificar a Roskomnadzor?

Depende de la naturaleza del procesamiento de DP y fundamentos. Si eres operador de DP, verifica requisitos de notificación, localización y política. En caso de duda, realiza una auditoría con un especialista.

9. ¿Cómo cumplir con el Art. 14 si hay muchos sujetos?

Evalúa los "esfuerzos desproporcionados": si es aplicable, usa notificación pública, canales claros de exclusión y minimiza la cantidad de DP. Documenta la evaluación.

10. ¿Cómo evitar reclamaciones sobre bases de datos en la UE?

No extraigas una parte sustancial y no restablezcas el valor económico. Trabaja con muestreo, agregación, enlaces a la fuente original y, cuando sea posible, licencias.

Responsabilidad: multas, demandas, reputación

UE/EEE

• GDPR: hasta 20 millones de euros o 4% de la facturación global; ciertos casos de scraping masivo han llevado a multas significativas para operadores que no han protegido DP de extracciones ilegales, y para scrapers en caso de procesamiento ilegal posterior.
• Derechos de bases de datos: prohibiciones judiciales, compensaciones por daños, recuperación de beneficios.

EE.UU.

• Demandas civiles por violación de ToS, derechos de autor, competencia desleal, trespass to chattels; prohibiciones judiciales y compensaciones.

Rusia

• 152-FZ y Código Administrativo: multas administrativas por violaciones en el procesamiento de DP, órdenes de cumplimiento, restricciones a actividades de sitios/agregadores.
• Código Penal Ruso: por acceso improcedente a información informática al eludir protecciones.
• Demandas civiles: protección de honor, dignidad, vida privada, derechos de propiedad intelectual; compensaciones.

Reputación

Aún el scraping legal puede generar negatividad si falta transparencia. La comunicación proactiva, ética y mecanismos claros de exclusión reducen riesgos.

Listas de control y marcos listos

Lista de control pre-scraping

• Objetivo y conjunto mínimo de campos definidos.
• Revisadas ToS, robots.txt, existencia de API.
• Clasificados DP/no DP, jurisdicciones.
• Preparados LIA/DPIA si es necesario.
• Definidos plazos de almacenamiento y eliminación.
• Configuradas limitaciones de tasa y caching.
• Documentados mecanismos DSR y opt-out.

Marco de "4 cuadrantes"

• Datos: DP vs no DP.
• Acceso: público vs restringido.
• Derecho: UE/EE.UU./Rusia/otro.
• Objetivo: interés legítimo/investigación/periodismo/marketing.

Lista de control post-scraping

• Verificación de calidad, eliminación de campos innecesarios.
• Documentación de fuentes y fechas.
• Actualización de registros (RoPA), LIA/DPIA.
• Verificación de transferencias transfronterizas.
• Actualización de la página de transparencia y FAQ.

Qué seguir en 2025-2026

• Nuevas decisiones en disputas similares a hiQ vs LinkedIn, y enfoques de los tribunales hacia demandas combinadas (ToS + IP + competencia desleal).
• Decisiones de reguladores europeos (CNIL, DPC, etc.) sobre scraping masivo de DP, incluyendo requisitos de "privacy by design" para plataformas.
• Práctica rusa respecto a DP públicamente accesibles, localización y mandatos de Roskomnadzor; desarrollo de multas administrativas.
• Actualizaciones en ePrivacy y posibles aclaraciones de EDPB sobre la monitorización de fuentes públicas.

Conclusión: estrategia de scraping sostenible

El web scraping legal no es una serie de trucos, sino una disciplina sistemática en la intersección del derecho, la ingeniería y la ética. Las preguntas correctas son: ¿por qué necesitamos estos datos?, ¿podemos conformarnos con menos?, ¿qué diremos al sujeto de datos y al propietario de la fuente?, ¿cómo demostraremos nuestra buena fe dentro de un año? En 2026, ganará quien construya procesos "legalmente por defecto": respete robots.txt y ToS, elija API cuando sea posible, documente bases legales, minimice recolecciones, proteja datos y mantenga diálogos abiertos con fuentes y sujetos. Este enfoque reduce riesgos, acelera aprobaciones y fortalece la confianza — un recurso que es difícil de copiar e imposible de scrappear.

Próximos pasos: realiza una auditoría de fuentes actuales según listas de verificación; actualiza LIA/DPIA; implementa políticas de proxies y ética de scraping; crea una página de transparencia y procesos DSR; capacita al equipo y designa responsables; revisa periódicamente ToS de fuentes clave y sigue la práctica de los reguladores. El cumplimiento sostenible es una ventaja competitiva. Úsala.