El EDPB pone precio al scraping para IA: si entrenas con datos de la web, ya estás en terreno GDPR de alto riesgo

Raspar datos personales de internet nunca fue un juego inocente. Ahora el Comité Europeo de Protección de Datos lo ha dejado por escrito con bastante más detalle del que muchas empresas querrían leer: si tu organización recoge datos personales de la web mediante scraping, necesita una base jurídica del artículo 6 del GDPR, debe respetar los principios del artículo 5 y tiene que demostrar —con documentación, no con fe— por qué ese tratamiento es lícito, necesario y proporcionado.

No es un matiz menor. Durante años, parte del mercado tecnológico ha tratado el scraping como si fuese una cuestión técnica o contractual: si la web es pública, se recoge; si el bot no rompe nada, adelante. El problema es que el GDPR no funciona así. Que un dato sea accesible online no lo convierte en un recurso libre de obligaciones. Sigue siendo un dato personal si identifica o hace identificable a una persona física, y su reutilización exige pasar por el mismo examen jurídico que cualquier otro tratamiento.

Eso es, en esencia, lo que subraya el EDPB en sus directrices sobre tratamiento de datos personales mediante tecnologías blockchain y, más recientemente y de forma específica, en su trabajo sobre scraping de datos personales accesibles públicamente. La idea central no es nueva, pero sí la forma en que se aterriza: el acceso público no equivale a disponibilidad irrestricta; la escala importa; el impacto sobre los derechos y libertades de los afectados importa; y la organización que decide recolectar esos datos tiene que poder explicar qué recoge, para qué, con qué límites y con qué salvaguardas.

Lo que cambia no es la teoría. Es el nivel de detalle exigible

Conviene separar ruido de sustancia. El EDPB no ha inventado una prohibición general del scraping. Tampoco ha dicho que todo uso de datos públicos sea ilícito. Lo que hace es algo más incómodo para el mercado: aplicar de forma estricta principios ya conocidos del GDPR a una práctica que demasiadas compañías habían normalizado sin gobernanza real.

La arquitectura jurídica es la de siempre, solo que aquí deja menos espacio para la improvisación. El responsable del tratamiento tiene que cumplir con el artículo 5 del GDPR —licitud, lealtad y transparencia; limitación de la finalidad; minimización de datos; exactitud; limitación del plazo de conservación; integridad y confidencialidad— y apoyarse en una base del artículo 6. Si además aparecen categorías especiales de datos, entra en juego el artículo 9. Si el tratamiento puede entrañar un alto riesgo para los derechos y libertades de las personas físicas, el artículo 35 obliga a valorar la necesidad de una evaluación de impacto.

Aquí está el punto que muchas lecturas superficiales pasan por alto: el EDPB no necesita bautizar formalmente el scraping como una categoría autónoma de “alto riesgo” para que el análisis sea exigente. Le basta con recordar que los tratamientos a gran escala, la agregación de datos accesibles públicamente y su posible efecto sobre los interesados pueden activar obligaciones reforzadas. Jurídicamente, eso es más relevante que un titular aparatoso.

“Está en internet” no es una base jurídica

Este sigue siendo el malentendido favorito del ecosistema digital. El hecho de que un perfil, un comentario, una fotografía o una biografía profesional estén disponibles online no crea por sí solo una base de licitud. El artículo 6 del GDPR exige una base concreta: consentimiento, ejecución de un contrato, obligación legal, intereses vitales, misión de interés público o interés legítimo. El scraping no disfruta de una excepción propia. Nunca la tuvo.

Eso obliga a una disciplina bastante menos glamourosa que el relato de “datos públicos para innovación”. Si la empresa invoca interés legítimo, tiene que hacer el test completo: identificar el interés perseguido, acreditar la necesidad del tratamiento y ponderarlo frente a los derechos y libertades de los afectados. No basta con declarar que el dato ya era visible. Tampoco basta con presumir que el interesado “debía esperar” esa reutilización. El artículo 5.1.a del GDPR exige lealtad y transparencia; el 5.1.b, limitación de la finalidad; el 5.1.c, minimización. Son tres filtros que, juntos, complican mucho los proyectos de recolección indiscriminada.

De hecho, el principio de responsabilidad proactiva del artículo 5.2 hace algo bastante menos épico y bastante más exigente que repartir culpas retóricas: obliga al responsable a poder demostrar el cumplimiento. Dicho de otra forma, quien decide scrapear no puede refugiarse en vaguedades sobre la disponibilidad pública del dato. Tiene que documentar su base jurídica, su necesidad, sus límites y sus medidas de mitigación. Eso no significa afirmar, en términos absolutos, que “toda la carga” recaiga “por completo” sobre quien hace scraping; significa algo más preciso y verificable: el GDPR exige al responsable rendición de cuentas demostrable.

La escala no convierte una práctica en ilegal. Sí cambia la evaluación

El scraping puntual y delimitado no plantea el mismo problema que la recolección masiva, persistente y automatizada de perfiles, publicaciones, imágenes o historiales profesionales. El EDPB insiste en un punto que el mercado conoce de sobra pero suele aparcar: la escala altera el impacto. Cuando una organización agrega datos dispersos de múltiples fuentes, construye inferencias, enriquece perfiles o reutiliza la información para fines distintos de aquellos para los que el usuario la publicó, el riesgo para los derechos y libertades de los interesados crece. Y con él, el nivel de control exigible.

Eso encaja de forma natural con el artículo 35 del GDPR sobre evaluaciones de impacto. El Reglamento no dice que todo scraping requiera una DPIA de forma automática. Lo que sí dice es que la DPIA procede cuando un tipo de tratamiento, en particular si utiliza nuevas tecnologías y teniendo en cuenta su naturaleza, alcance, contexto o fines, es probable que entrañe un alto riesgo para los derechos y libertades de las personas físicas. Si el proyecto implica gran escala, combinación de fuentes, perfilado o reutilización intensiva de datos accesibles públicamente, la pregunta no es si la DPIA “queda bonita” en la carpeta de compliance. La pregunta es si puedes justificar seriamente no hacerla.

Y aquí suele aparecer la ironía regulatoria de siempre: muchas empresas consideran sofisticadísimo construir el sistema técnico de extracción, pero tratan como un estorbo casi ornamental el análisis de necesidad, proporcionalidad y minimización. Luego se sorprenden cuando el regulador mira el expediente y descubre que el robot sabía recorrer medio internet, pero nadie había definido con precisión qué categorías de datos podían recogerse y cuáles debían quedar fuera.

El EDPB aprieta antes de la recogida, no solo después

Uno de los elementos más útiles del enfoque del EDPB es que desplaza la conversación hacia el diseño previo del tratamiento. No se trata solo de limpiar datos una vez aspirados. Se trata de evitar recoger lo que no deberías haber tocado desde el principio. Esa lógica encaja directamente con la protección de datos desde el diseño y por defecto del artículo 25 del GDPR.

En las medidas previas a la recogida que sí pueden respaldarse con el material disponible, el EDPB apunta a varias líneas claras: valorar si puede recurrirse a datos sintéticos en lugar de datos personales reales; definir criterios precisos de recogida; mapear e inventariar los datos que se pretenden tratar; y aplicar filtros para excluir determinadas categorías de datos. No son sugerencias cosméticas. Son decisiones de arquitectura.

Ese enfoque importa por dos razones. La primera es jurídica: la minimización del artículo 5.1.c no se cumple diciendo, a posteriori, que ya borrarás lo innecesario. La segunda es operativa: cada dato innecesario que entra en el sistema aumenta superficie de riesgo, complejidad de gobernanza y coste de respuesta si luego hay que atender derechos de acceso, supresión u oposición en virtud de los artículos 15, 17 y 21.

Lo interesante es que estas medidas previas desmontan uno de los argumentos defensivos más habituales del sector: “recogemos mucho porque luego ya afinaremos el modelo o el análisis”. Desde la lógica del GDPR, eso suena menos a optimización y más a exceso de captura. Si no puedes justificar por qué necesitas esa amplitud desde el inicio, el problema no se arregla después con una capa de limpieza.

Qué puede decirse con seguridad sobre las medidas posteriores

Aquí conviene ser precisos y no adornar más de la cuenta. El material disponible confirma el énfasis del EDPB en controles preventivos antes de la recogida, pero no permite verificar con el mismo grado de seguridad todas las medidas post-recogida que a menudo se atribuyen a estas directrices en resúmenes de terceros. Por eso, la conclusión prudente es esta: una vez recogidos los datos, siguen aplicando de lleno los principios del artículo 5 del GDPR y las obligaciones generales de seguridad del artículo 32, pero no conviene presentar como textual o confirmada por la fuente concreta una lista cerrada de técnicas posteriores si el extracto suministrado no las acredita expresamente.

Dicho eso, el marco jurídico sí ofrece un contorno operativo sólido. Si una organización ya ha recogido datos personales, tendrá que gestionar retención, exactitud, seguridad, acceso interno, segregación y respuesta a derechos. Si maneja categorías especiales o datos obtenidos incidentalmente que no eran necesarios para la finalidad declarada, el problema no desaparece por el mero hecho de haberlos capturado “sin querer”. El artículo 5.1.c sobre minimización y el 5.1.e sobre limitación del plazo de conservación siguen ahí, recordando una verdad poco popular: recolectar primero y pensar después es una mala estrategia regulatoria.

La transparencia es donde muchos proyectos se rompen

Buena parte del debate público sobre scraping gira alrededor de la licitud de la recogida. Pero, en la práctica, el frente más incómodo suele ser otro: cómo cumples con los deberes de información de los artículos 13 y 14 del GDPR cuando los datos no se obtienen directamente del interesado, se agregan desde múltiples fuentes y se reutilizan para fines que el afectado probablemente no anticipaba.

El artículo 14 es especialmente relevante en estos escenarios. Exige informar al interesado, entre otras cosas, de la identidad del responsable, las finalidades, las categorías de datos, los destinatarios, la base jurídica y el plazo de conservación, cuando los datos no se han obtenido de él. Existen excepciones, sí. Pero apoyarse de forma automática en que informar sería “imposible” o “exigiría esfuerzos desproporcionados” es una tentación que los reguladores suelen examinar con bastante escepticismo. Y con razón. Si el modelo de negocio depende estructuralmente de recolectar datos de personas a las que nunca vas a informar, la pregunta regulatoria no es trivial: quizá el problema no sea el artículo 14; quizá sea el propio diseño del tratamiento.

Esto conecta con una tensión que el sector tecnológico lleva años intentando esquivar. Cuanto más ambicioso y opaco es el scraping, más difícil se vuelve explicar de manera comprensible qué haces con los datos y por qué. Y cuanto más difícil se vuelve explicarlo, peor encaja con la exigencia de transparencia del GDPR. No es una cuestión estética de política de privacidad. Es una prueba de estrés sobre la legitimidad real del proyecto.

Datos accesibles públicamente no significa datos descontextualizados

Hay otra idea de fondo que merece atención: el contexto original de publicación importa. Una persona puede publicar información en una red profesional para visibilidad laboral, en un foro para conversación temática o en una página local para un propósito muy específico. Extraer ese dato, combinarlo con otros y reutilizarlo para análisis, perfilado, enriquecimiento comercial o entrenamiento de sistemas altera el contexto y, a menudo, la expectativa razonable del interesado.

Ese salto contextual no convierte automáticamente el tratamiento en ilícito, pero sí endurece la ponderación. El interés legítimo del artículo 6.1.f no es un comodín capaz de absorber cualquier reutilización creativa de datos públicos. Requiere demostrar necesidad y equilibrio. Si la finalidad nueva es muy distinta de la original, si la escala es masiva o si la reutilización puede producir efectos adversos relevantes para el interesado, la defensa jurídica se complica.

El propio GDPR ofrece herramientas para hacer esta evaluación con seriedad. El artículo 6.4, aunque pensado para valorar la compatibilidad de finalidades cuando el tratamiento se basa en una finalidad inicial distinta, recuerda factores útiles: la relación entre finalidades, el contexto en que se recogieron los datos, la naturaleza de los datos, las posibles consecuencias para los interesados y la existencia de garantías adecuadas. No hace falta forzar el texto para ver el mensaje: el contexto de publicación no desaparece porque una herramienta automatizada sea capaz de recolectar el dato a gran velocidad.

Lo que el EDPB sí está diciendo al mercado de IA, sin necesidad de nombrarlo a cada línea

Conviene no atribuir a la fuente conexiones específicas que el extracto disponible no confirma. Si el documento que estamos analizando trata directrices del EDPB sobre scraping y GDPR, no corresponde cargarlo con referencias categóricas a DORA, NIS2 o al AI Act si ese respaldo no aparece en el material suministrado. Esa mezcla puede ser editorialmente tentadora, pero aquí toca precisión.

Ahora bien, incluso manteniéndonos estrictamente dentro del perímetro verificable, hay una lectura evidente para cualquier empresa que use datos accesibles públicamente en sistemas analíticos o de aprendizaje automático: el problema no empieza en el modelo; empieza en la licitud y gobernanza del dataset. Antes de discutir precisión, sesgo o rendimiento, toca responder preguntas más básicas. ¿Qué base jurídica ampara la recogida? ¿Qué categorías de datos entran? ¿Qué criterios de exclusión existen? ¿Cómo se respeta el principio de minimización? ¿Se ha evaluado el impacto sobre los interesados conforme al artículo 35? ¿Puede cumplirse con los artículos 13 o 14? Si esas preguntas no están resueltas, la sofisticación técnica del sistema sirve de poco como defensa regulatoria.

No hace falta adornarlo con siglas adicionales para entender la magnitud del asunto. El dataset deja de ser una cuestión puramente técnica y se convierte en una pieza central de accountability bajo GDPR. Y eso, para bastante industria, ya es suficientemente incómodo.

La minimización no es un consejo. Es una poda obligatoria

El principio del artículo 5.1.c merece una lectura menos ritual y más operativa. Minimizar no consiste en recoger “todo lo disponible” y luego declarar que solo usarás una parte. Minimizar significa limitar desde el diseño qué datos son adecuados, pertinentes y necesarios para la finalidad perseguida. La diferencia parece semántica, pero no lo es. Determina si tu arquitectura de scraping está pensada para cumplir o para rezar.

Por eso son tan relevantes las medidas previas que el material sí respalda: criterios concretos de recogida, mapeo e inventario de datos y filtros para excluir determinadas categorías. Eso obliga a las organizaciones a abandonar el enfoque de arrastre generalista. Si la finalidad es, por ejemplo, verificar información profesional muy concreta, costará justificar la captura de campos periféricos, comentarios, imágenes, metadatos adicionales o cualquier otro elemento que no sea estrictamente necesario.

También cambia la conversación interna entre legal, privacidad y producto. La pregunta útil ya no es “qué podemos scrapear”, sino “qué necesitamos exactamente para esta finalidad y cómo impedimos técnicamente capturar más de la cuenta”. Parece menos heroico. También es bastante más compatible con el GDPR.

La documentación deja de ser burocracia cuando llega una reclamación

Uno de los errores más caros en estos proyectos es creer que la gobernanza documental es una formalidad posterior. No lo es. Bajo el principio de responsabilidad proactiva del artículo 5.2 y las obligaciones de registro del artículo 30, la empresa tiene que poder reconstruir y explicar el tratamiento: categorías de datos, finalidades, base jurídica, fuentes, destinatarios, transferencias si las hay, plazos de conservación y medidas de seguridad.

Eso tiene consecuencias muy concretas. Si un interesado ejerce el derecho de acceso del artículo 15, la organización debería saber no solo que conserva datos suyos, sino qué datos, de dónde proceden y con qué lógica han sido utilizados. Si ejerce supresión conforme al artículo 17 o se opone en virtud del artículo 21, la empresa necesita localizar el dato y entender cómo fluye por sistemas, procesos y posibles reutilizaciones. El scraping masivo mal inventariado convierte el cumplimiento de derechos en una pesadilla operacional. Y cuando una práctica de tratamiento hace prácticamente imposible atender derechos de forma razonable, el regulador suele sospechar —con razón— que el problema está en el diseño, no en la bandeja de entrada del DPO.

No hay glamour en mantener inventarios precisos, criterios de exclusión bien definidos y trazabilidad de fuentes. Tampoco lo hay en responder requerimientos de una autoridad sin esa documentación. Entre ambas opciones, la menos fotogénica suele ser la inteligente.

Atención a las categorías especiales y a la recogida incidental

El scraping automatizado tiene un defecto estructural: captura contexto además de contenido. Y ese contexto puede incluir datos especialmente sensibles aunque no fuesen el objetivo inicial del proyecto. El artículo 9 del GDPR prohíbe, con carácter general, el tratamiento de categorías especiales de datos personales salvo que concurra una de las excepciones previstas. Hablamos, entre otros, de datos que revelen origen racial o étnico, opiniones políticas, convicciones religiosas o filosóficas, afiliación sindical, datos genéticos, biométricos dirigidos a identificar de manera unívoca a una persona, datos relativos a la salud o a la vida sexual u orientación sexual.

Aquí conviene mantener disciplina factual. No podemos afirmar con apoyo estricto en el extracto disponible que el documento cite una sentencia concreta determinada como referencia para la recogida incidental o residual de categorías especiales si esa mención no aparece en el material suministrado. Lo verificable es otra cosa: si un sistema de scraping puede captar este tipo de datos, el análisis jurídico se vuelve notablemente más exigente y las medidas de exclusión previas ganan peso. Precisamente por eso el enfoque preventivo del EDPB resulta tan relevante. Cuanto más automatizada y amplia es la recogida, más difícil es garantizar que no entren datos que jamás debieron entrar.

La implicación práctica es directa. Si tu arquitectura no está diseñada para evitar o reducir al máximo esa captura incidental, el riesgo de incumplimiento no es teórico. Está embebido en el propio mecanismo de extracción.

Qué deberían hacer ahora las empresas que dependen del scraping

No hace falta dramatizar. Sí hace falta dejar de improvisar. Si una organización utiliza scraping de datos personales accesibles públicamente, tiene por delante una agenda bastante concreta.

• Revisar la base jurídica real: no la que aparece en una presentación interna, sino la que puede sostenerse conforme al artículo 6 del GDPR con un análisis documentado de necesidad y proporcionalidad.
• Acotar finalidades con precisión: si la finalidad está formulada con vaguedad estratégica, probablemente no sobrevivirá bien al test de limitación del artículo 5.1.b.
• Rediseñar la captura con lógica de minimización: criterios ex ante, inventario de categorías y filtros de exclusión antes de recolectar. No después.
• Evaluar si procede una DPIA: especialmente cuando haya gran escala, combinación de fuentes, perfilado o impacto potencial significativo sobre los interesados, conforme al artículo 35.
• Preparar el cumplimiento de transparencia y derechos: artículos 13, 14, 15, 17 y 21. Si no puedes explicar el tratamiento o atender derechos de forma operativa, tu modelo tiene una grieta de diseño.
• Documentar de verdad: registros del artículo 30, lógica de fuentes, categorías tratadas, criterios de exclusión, plazos de conservación y medidas de seguridad del artículo 32.

Esta lista no es revolucionaria. Precisamente por eso importa. El EDPB no está pidiendo magia. Está pidiendo que el scraping deje de vivir en ese limbo corporativo donde ingeniería avanza a toda velocidad y compliance llega después con una linterna.

La lección incómoda: la web pública no es una cantera sin dueño

El mensaje regulatorio de fondo es menos novedoso de lo que algunos titulares sugieren, pero más disruptivo para el negocio de lo que muchos querrían admitir. Durante años, la economía del dato ha operado con una ficción útil: que lo públicamente visible online era, si no libre de uso, al menos material de bajo rozamiento jurídico. El GDPR nunca avaló esa ficción. El EDPB ahora la estrecha con más claridad operativa.

El scraping de datos personales accesibles públicamente no desaparece. Lo que desaparece, o debería desaparecer, es la comodidad de tratarlo como una actividad neutra por defecto. Si la recogida es masiva, si las finalidades se amplían, si los datos se agregan y reutilizan de formas que el interesado no esperaba, la exigencia normativa sube. No por capricho del regulador, sino porque el impacto sobre las personas también sube.

Tu empresa puede seguir queriendo esos datos. La cuestión ya no es esa. La cuestión es si puede explicar, con artículos del GDPR en la mano y controles reales en producción, por qué debe recoger exactamente esos datos, por qué no necesita menos, cómo evita capturar lo que no toca y cómo respeta los derechos de las personas afectadas. Si esa explicación no existe, el problema no es de comunicación. Es de licitud.

Y esa, nos pongamos como nos pongamos, es una diferencia bastante más cara.