El EDPB acaba de redactar una especificación para scrapers
Las autoridades de protección de datos de Europa han hablado mucho sobre los modelos de IA. Hasta este verano, nada de eso le indicaba a un ingeniero qué debe hacer un scraper antes de realizar la petición de su primera página.
Las Directrices 03/2026 sobre web scraping en el contexto de la IA generativa cambiaron eso. El Comité Europeo de Protección de Datos adoptó el borrador el 7 de julio de 2026, y su consulta pública cierra el 30 de octubre de 2026. Sobre el papel, el alcance es estrecho: empresas privadas que extraen datos personales para entrenar o ajustar modelos de IA generativa. En la práctica, es la descripción más detallada que un regulador ha publicado sobre cómo se construye un trabajo de scraping defendible, desde los criterios que defines antes del primer request hasta la marca de tiempo en el último registro.
Nuestra lectura, tras revisar las 23 páginas: al borrador no le importa qué herramientas utilizas. Le importa si puedes decir qué recopilaste, desde dónde y cuándo. Los scrapers que puedan responder a eso en una sola consulta estarán bien. Los rastreos abiertos tendrán dificultades con casi cada párrafo.
(Aviso legal: Esto no es asesoramiento jurídico. En primer lugar, nos referimos a un borrador, y somos ingenieros leyéndolo por lo que implica a nivel de código).
Dirigido o no dirigido es la línea que importa
El párrafo 8 divide el scraping en dos tipos según cuán específica y restrictiva sea la recopilación, "y no por las herramientas técnicas utilizadas". El scraping dirigido sigue criterios de recopilación: un dominio, un idioma, un tema. El scraping no dirigido es un crawler que sigue cada enlace que encuentra. La preocupación del Comité es concreta: a medida que la cola crece, el responsable "tiene un conocimiento limitado de qué datos personales se recopilan y procesan".
Esa división se mantiene en el resto del texto. La minimización de datos te pide "definir criterios de recopilación precisos" y ejecutar un "proceso de mapeo e inventario de datos" antes de iniciar la recopilación (párrafo 37). La prueba de necesidad bajo el interés legítimo señala que restringir los criterios, "en lugar de extraer una amplia parte de internet", puede ser precisamente lo que hace que el tratamiento sea necesario (párrafo 52). La transparencia exige una lista publicada de fuentes, idealmente con nombres de dominio, URL y fechas de recopilación (párrafos 30 y 31).
Un rastreador de precios con una lista fija de páginas de productos en una docena de dominios comerciales puede generar cada uno de esos artefactos a partir de su archivo de configuración. Un rastreo en anchura no puede hacerlo. La crítica del borrador por parte de Privacy World describe bien esta tensión: las obligaciones están redactadas para un responsable que sabe lo que recopila, justo después de que el Comité admita que un rastreo no dirigido puede contener datos personales que no es capaz de inventariar.
Qué significa esto: si extraes mediante scraping cualquier dato vinculado a personas (reseñas con nombres de usuario, anuncios con el nombre y teléfono de un agente, hilos de foros), tus criterios de recolección son ahora un artefacto de cumplimiento normativo. Consérvalos en control de versiones junto al scraper, no en la cabeza de alguien.
El "no" de un sitio ahora cuenta en tu contra
Esta es la parte que más alterará los pipelines. El borrador enumera las medidas técnicas que demuestran que un sitio se opone claramente al scraping: robots.txt, ai.txt, "autenticación de robots para ver contenido" y comprobaciones que "imponen una acción que solo puede ser realizada por un ser humano" (párrafo 37). Su recomendación para datos de entrenamiento es dejar esos sitios fuera.
Las mismas señales reaparecen en la prueba de ponderación. Cuando los usuarios saben que un sitio utiliza estas medidas y se extrae información de todos modos, el borrador señala que es menos probable que esperen dicho tratamiento (párrafo 64). El ejemplo 5 lo detalla: una plataforma con una exclusión en robots.txt, una comprobación exclusiva para humanos y una prohibición explícita de entrenamiento de IA implica que sus usuarios "no pueden esperar razonablemente" que terceros extraigan sus datos con ese propósito. Y lo contrario no aplica. La ausencia de un robots.txt no constituye consentimiento (párrafo 45).
La CNIL de Francia llegó primero a este punto. Su ficha temática sobre interés legítimo y web scraping, publicada originalmente en junio de 2025, indica que el tratamiento "no puede entrar dentro de las expectativas razonables de los interesados" cuando el responsable del tratamiento no excluye sitios que se oponen mediante robots.txt o una comprobación exclusiva para humanos.
Dos elementos menos evidentes figuran entre las medidas mitigadoras (párrafo 66c). Uno excluye los datos personales que solo son visibles tras iniciar sesión. El otro abarca sitios que devuelven una salida distinta al User-Agent de un scraper frente a la de un navegador estándar, "en particular cuando el servicio de scraping recibe más datos" de los que vería una persona. Si tu scraper consume una API interna más completa que lo mostrado en la página, se refieren exactamente a este caso.
Analizamos la vertiente procesable por máquinas de esto (extensiones de robots.txt, agentes firmados, señales de contenido) en Search, Agent, Training: The Web's New Bot Rules, y a los editores que prefieren cobrar antes que bloquear en Pay-Per-Crawl Is Splitting the Web in Two. El borrador del EDPB es la primera vez que un regulador trata estas señales como evidencia de las expectativas de los usuarios.
Qué significa esto: registra el estado de robots.txt (y ai.txt, cuando el sitio disponga de él) por dominio en el momento de la recolección, junto a los datos. Si alguien pregunta dentro de un año por qué una fuente terminó en un conjunto de entrenamiento, "estaba permitido el día que lo descargamos" solo servirá como respuesta si lo dejaste por escrito.
El scraper puede ser el encargado del tratamiento
La sección 3.2.1 es breve y fácil de pasar por alto. No debería serlo, en especial si creas scrapers para clientes. Si generas un conjunto de datos de entrenamiento en nombre del desarrollador "según sus instrucciones documentadas", tú puedes ser el encargado del tratamiento y el desarrollador el responsable (párrafo 18). Si tú y el cliente definen juntos los criterios de recopilación, pueden ser corresponsables del tratamiento (párrafo 20, Ejemplo 1). Si extrajiste un conjunto de datos por tu cuenta y otra persona lo reutiliza, cada uno responde por su propio tratamiento (párrafo 19).
La columna de IAPP de Brian Hengesbaugh sobre el borrador destaca el aspecto comercial. Cuando un contrato designa al proveedor como encargado del tratamiento, el cliente asume la carga de cumplimiento que describe la guía, y las obligaciones directas del propio proveedor "podrían ser más limitadas y menos tranquilizadoras de lo que se pensaba". Esto aplica en ambos sentidos. Un cliente no puede delegar el cumplimiento en el freelancer que escribió el scraper, y un freelancer que improvisa la lista de fuentes puede terminar siendo responsable del tratamiento por accidente.
Qué deberían cambiar los equipos de datos ahora mismo
La mayor parte del scraping comercial no se ve afectada por esto. Los precios, niveles de stock, especificaciones de productos y horarios por lo general no son datos personales, por lo que el GDPR no los alcanza. El borrador indica de forma explícita que en un conjunto de datos "mixto" se aplica a la parte personal (párrafo 13). Por lo tanto, una publicación con el nombre del vendedor o una reseña con un nombre de usuario incluye esa parte dentro del alcance.
Para los jobs que sí recopilan información sobre personas, así se traducen los requisitos del borrador a un pipeline:
| El borrador solicita | En tu pipeline |
|---|---|
| Criterios de recopilación | Patrones de URL por job |
| Filtrado basado en sintaxis | Descarte con regex durante el parseo |
| Registros con marca temporal | fetched_at en cada fila |
| Una lista de fuentes | Dominios en la configuración |
| Respeto a las exclusiones (opt-outs) | Estado de robots.txt registrado en logs |
Dos de esas filas merecen más que una celda de tabla.
Filtra en el momento del parseo, no en un job de limpieza semanas después. El párrafo 38 menciona expresiones regulares para formatos como números de seguridad social y de teléfono, aplicadas durante la recopilación. Los datos que nunca almacenaste son datos que nunca tendrás que justificar, y el párrafo 60 es contundente sobre por qué esto importa para la IA: una vez entrenado un modelo, los datos personales "no se pueden eliminar con facilidad" de él.
Conserva la URL de origen y la hora de obtención en cada registro. El párrafo 42 solicita marcas temporales por precisión, pero esos mismos dos campos responden a cualquier pregunta posterior sobre el origen de un dato. Las normas sobre datos de entrenamiento ya se estaban endureciendo con la Ley de IA (escribimos sobre eso en abril), y no dejan de plantear esa misma duda.
Si desarrollas para clientes, debes poner las instrucciones por escrito: fuentes, campos, exclusiones. El borrador considera que las instrucciones documentadas son lo que te define como encargado del tratamiento en lugar de corresponsable, y una especificación de una sola página evita disputas de roles en el futuro.
Qué sucede después del 30 de octubre
El texto final cambiará, y el cambio más importante podría venir de Bruselas y no de la Junta. El 21 de octubre de 2026, el Consejo acordó su posición negociadora sobre el paquete Digital Omnibus, que modificaría el GDPR. Según el informe de la IAPP sobre el mandato, los estados miembros añadieron "aclaraciones sobre la base jurídica para el tratamiento de datos personales y la necesidad de mantener salvaguardas adecuadas" para los datos de entrenamiento de IA. Las negociaciones con el Parlamento Europeo son el siguiente paso. Independientemente de la redacción final, los estados miembros quieren mantener las salvaguardas, lo que apunta a una prueba de sopesamiento muy similar a la de este borrador.
Creemos que la distinción entre recolección dirigida y no dirigida sobrevivirá a ambos procesos, porque es la única parte del borrador enfocada en la ingeniería y no en el derecho. Un regulador no leerá el código de tu crawler. Puede pedirte los criterios de recolección, tu lista de fuentes y tus marcas de tiempo, y un equipo capaz de entregar eso esa misma tarde deja muy poco margen para la discusión.
Por tanto, la próxima pregunta que un regulador de privacidad le haga a un scraper no será "cómo funciona", sino más bien: "qué se le ordenó recolectar".