El 8 de julio de 2026 el Comité Europeo de Protección de Datos (EDPB, o CEPD en español) adoptó tres documentos que tocan directamente a cualquiera que construya o compre inteligencia artificial en Europa: unas directrices sobre anonimización, otras sobre web scraping en el contexto de la IA generativa y la versión final de las directrices sobre blockchain.
Antes de seguir, el matiz que la mitad de los titulares de esta semana se ha saltado: las dos primeras son borradores en consulta pública hasta el 30 de octubre de 2026. No obligan a nada todavía. Se pueden alegar. Y precisamente por eso merece la pena leerlas ahora, cuando aún hay margen para adaptar la arquitectura sin prisas y para decidir qué firmas con tu proveedor de IA.
Esta es la lectura de un CTO, no la de un despacho: qué cambia para quien tiene datos en producción, qué preguntas hay que hacer y qué debería estar escrito en el contrato.
Qué adoptó exactamente el EDPB el 8 de julio de 2026
Tres documentos con estatus jurídico distinto, y confundirlos es el primer error.
| Documento | Contenido | Estado a 15 de julio de 2026 |
|---|---|---|
| Directrices 02/2026 sobre anonimización | Cuándo un dato deja realmente de ser personal | Borrador. Consulta pública hasta el 30 de octubre de 2026 |
| Directrices 03/2026 sobre web scraping en el contexto de la IA generativa | Base jurídica del scraping y tratamiento de categorías especiales | Borrador. Consulta pública hasta el 30 de octubre de 2026 |
| Directrices sobre tratamiento de datos personales mediante blockchain | Cadenas de bloques y RGPD | Versión final adoptada |
Las directrices sobre blockchain se desarrollaron con liderazgo de la AEPD, que lo comunicó en nota propia el 9 de julio de 2026. Es la única de las tres que ya es texto definitivo.
Nadie está incumpliendo las Directrices 02/2026 ni las 03/2026 hoy. Son proyectos sometidos a consulta pública y su redacción puede cambiar antes de la versión final. Si alguien te dice que "el EDPB ya obliga a X", está vendiendo urgencia, no rigor. Lo que sí sabemos es hacia dónde apunta el criterio del regulador, y eso vale para planificar.
Fuente primaria: nota del EDPB de 8 de julio de 2026.
Por qué un borrador importa si tienes IA en producción
Tres razones prácticas, y ninguna es "por si acaso":
1. Es la mejor señal disponible del criterio de las autoridades. Las agencias nacionales —la AEPD incluida— participan en la elaboración. Cuando llegue una inspección en 2027, el marco mental del inspector ya estará formado por este texto, aunque la versión final difiera en los detalles.
2. Hay ventana de alegaciones hasta el 30 de octubre. Si tu negocio depende de un tratamiento que estas directrices ponen en cuestión, es ahora cuando se argumenta, directamente o vía asociación sectorial. Después toca cumplir, no discutir.
3. Los contratos que firmas hoy duran más que la consulta. Un acuerdo a tres años firmado en julio de 2026 seguirá vigente cuando el texto sea definitivo. Si no incluyes hoy las cláusulas adecuadas, en 2027 tu única palanca será renegociar desde una posición débil.
Hilo 1: la anonimización deja de ser una casilla que se marca
Qué sustituyen estas directrices
El marco de referencia hasta ahora era el Dictamen 05/2014 sobre técnicas de anonimización del Grupo de Trabajo del Artículo 29, predecesor del EDPB. Un documento anterior al propio RGPD, a los transformers y a la idea de entrenar un modelo con medio internet. Las Directrices 02/2026 están destinadas a sustituirlo.
Su test sigue siendo un buen esquema mental, y conviene recordarlo porque mucha gente que dice "anonimizamos" solo ha resuelto el primero de los tres riesgos:
| Riesgo | Pregunta que hay que responder | Ejemplo de fallo típico |
|---|---|---|
| Singularización (singling out) | ¿Se puede aislar a un individuo concreto dentro del conjunto? | Un único cliente de Cangas del Narcea en una tabla por municipio |
| Vinculabilidad (linkability) | ¿Se pueden cruzar dos registros del mismo sujeto entre datasets? | Un hash del DNI que se mantiene estable entre dos exportaciones |
| Inferencia | ¿Se puede deducir un atributo del sujeto con alta probabilidad? | Todos los registros de un grupo comparten el mismo diagnóstico |
Si tu proceso de "anonimización" consiste en borrar la columna nombre y dejar la de código_postal, fecha_nacimiento y sexo, no has superado ninguno de los tres. Es una combinación clásica que reidentifica a un porcentaje muy alto de una población.
Seudonimizar no es anonimizar. Sustituir el identificador por un token reversible —o por un hash cuya tabla de correspondencia conservas— es seudonimización (art. 4.5 RGPD): sigue siendo dato personal y sigue bajo el RGPD completo. La anonimización real es irreversible y saca al dato del ámbito del Reglamento. La diferencia no es de grado, es de régimen jurídico.
El cambio de fondo: la identificabilidad es relativa
Aquí está la novedad de calado. Las directrices incorporan jurisprudencia reciente del TJUE, en particular el asunto C-413/23 P, EDPS c. JUR (SRB), de 4 de septiembre de 2025, para consolidar un enfoque relativo de la identificabilidad.
Traducido a lenguaje de ingeniería: la pregunta "¿este dataset es anónimo?" está mal formulada. La pregunta correcta es "¿este dataset es anónimo para quién?". El mismo conjunto de datos puede ser dato personal para quien conserva la clave de reidentificación y anónimo para un tercero que no dispone de medios razonablemente utilizables para revertirlo.
Esto encaja con lo que el RGPD ya decía en su considerando 26: hay que valorar los medios que razonablemente puedan ser utilizados para identificar, atendiendo a coste, tiempo y tecnología disponible. Lo que aportan las directrices es método para aplicarlo en serio.
Las consecuencias prácticas son concretas:
- La anonimización deja de ser una propiedad del fichero y pasa a serlo del fichero en un contexto. Cambia el destinatario, cambia el análisis.
- Ese análisis hay que documentarlo. No basta con afirmar que el dato es anónimo: hay que poder enseñar el razonamiento, las técnicas aplicadas, los datasets auxiliares considerados y por qué la reidentificación no es razonablemente probable para ese receptor.
- El análisis caduca. Un dataset que publicaste como anónimo hace cinco años puede haber dejado de serlo porque hoy existe una base auxiliar que entonces no existía.
El corolario que más duele a los equipos de datos: si conservas la tabla de correspondencia, el dataset no es anónimo para ti, por mucho que lo sea para el tercero al que se lo cedes. Muchas arquitecturas de "data lake anonimizado" son en realidad data lakes seudonimizados con una clave guardada dos VPC más allá.
Qué protege y qué no protege cada técnica
Resumen honesto de lo que cada familia de técnicas resuelve:
| Técnica | Qué mitiga | Qué no resuelve |
|---|---|---|
| Supresión de identificadores directos | Identificación trivial | Singularización por cuasi-identificadores |
| Hash / tokenización con clave conservada | Lectura casual del identificador | Nada: sigue siendo seudonimización |
| Generalización y agregación (k-anonimato) | Singularización si k es suficiente | Inferencia si el grupo es homogéneo |
| Adición de ruido / aleatorización | Precisión de un registro individual | Ataques por promediado sobre consultas repetidas |
| Privacidad diferencial con presupuesto acotado | Es la garantía formal más sólida disponible | Nada si el presupuesto de privacidad se agota sin control |
| Datos sintéticos | Depende enteramente de cómo se generen | Un generador sobreajustado memoriza y reproduce registros reales |
Los datos sintéticos merecen aviso propio, porque en 2026 se venden como bala de plata. Un generador entrenado sobre datos personales no produce automáticamente datos anónimos: si sobreajusta, memoriza y puede reproducir registros del conjunto original. Sin una evaluación explícita del riesgo de memorización, "sintético" es una etiqueta de marketing, no una garantía jurídica.
Esto conecta con lo que el EDPB ya apuntaba en su Dictamen 28/2024 sobre protección de datos en los modelos de IA: un modelo entrenado con datos personales no puede considerarse anónimo por defecto. Hay que evaluar caso por caso la probabilidad de extraer datos personales del propio modelo, sea por regurgitación o por ataques dirigidos. Que los pesos sean números no convierte al modelo en un objeto neutro.
Prueba de realidad para tu equipo de datos: coge el dataset que llamáis "anonimizado" y encarga a alguien de fuera del proyecto que intente reidentificar cinco registros usando solo fuentes públicas y los datasets que vuestra propia empresa ya tiene. Documenta el intento, tenga éxito o no. Ese informe vale más ante una inspección que cualquier declaración de intenciones, y es exactamente el tipo de evidencia que el enfoque relativo exige.
Hilo 2: web scraping, o de dónde salieron los datos de tu proveedor
"Es público" no es una base jurídica
El segundo borrador aborda el raspado masivo de la web para desarrollar y entrenar sistemas de IA. El punto de partida no es nuevo, pero conviene decirlo sin rodeos: que un dato esté accesible públicamente en internet no lo saca del RGPD. Tu perfil de LinkedIn, tus reseñas y tu ficha en el colegio profesional son datos personales publicados, no datos personales renunciados.
El scraping para entrenar un modelo es un tratamiento de datos personales y necesita, como cualquier otro: base jurídica, información al interesado, minimización, plazos de conservación y respeto a los derechos del art. 15 y siguientes.
El interés legítimo y el test en tres pasos
El consentimiento es inviable para un corpus de millones de páginas, así que el debate se juega en el interés legítimo (art. 6.1.f RGPD). El marco vigente aquí es el Dictamen 28/2024 del EDPB, que ordena el análisis en tres pasos. No es un formalismo: es el guion exacto que tu proveedor debe poder recitar.
- Identificación del interés legítimo. Tiene que ser lícito, real, actual y articulado con precisión. "Mejorar nuestros modelos" no lo está; "desarrollar un asistente conversacional para atención al cliente en español" empieza a estarlo.
- Necesidad. ¿Es el tratamiento necesario para ese fin, y no existe vía menos invasiva? Aquí cae mucho scraping indiscriminado: raspar dominios completos cuando el fin se lograba con un subconjunto acotado no supera el test de minimización.
- Ponderación. Equilibrio entre ese interés y los derechos del interesado, atendiendo a sus expectativas razonables. Quien publicó una reseña de un restaurante en 2019 no esperaba razonablemente que acabase en el corpus de un modelo comercial.
En la ponderación pesan mucho las medidas mitigadoras: excluir dominios sensibles, respetar robots.txt y señales de exclusión, filtrar identificadores directos antes de entrenar, no raspar sitios cuyo público principal sean menores, ofrecer un mecanismo real de oposición y aplicar filtros de salida contra la regurgitación. Un proveedor que no pueda enumerar las suyas es un proveedor que no ha hecho el test.
El punto duro: categorías especiales del art. 9
Aquí está el riesgo real para quien compra IA.
El art. 9 RGPD prohíbe en principio tratar datos que revelen origen étnico o racial, opiniones políticas, convicciones religiosas o filosóficas, afiliación sindical, datos genéticos, biométricos con fines identificativos, de salud o relativos a la vida y orientación sexuales. La prohibición se levanta solo con una de las excepciones tasadas del art. 9.2.
La excepción que todo el mundo invoca para el scraping es la del art. 9.2.e): datos "manifiestamente hechos públicos por el interesado". Y es mucho más estrecha de lo que suena. El TJUE ya la interpretó de forma restrictiva en GC y otros (C-136/17): exige que el interesado haya tenido la intención de hacer accesibles esos datos al público en general, de forma explícita y mediante una acción afirmativa clara.
Aplicado al raspado masivo, esto significa que no se puede presumir de forma genérica y automatizada. Un crawler no sabe si el autor de un post quiso publicarlo urbi et orbi o simplemente no entendió la configuración de privacidad. Y hay dos trampas adicionales:
- Los datos del art. 9 aparecen por inferencia, no solo por declaración. Un texto que menciona una peregrinación, un tratamiento médico, una manifestación o una pareja del mismo sexo puede constituir dato de categoría especial aunque ninguna columna se llame "religión" ni "salud".
- Los datos de terceros. Si alguien publica algo sobre la salud de un familiar, ese familiar no ha hecho nada manifiestamente público. La excepción no le alcanza.
La consecuencia operativa para quien compra IA: si tu proveedor entrenó con un corpus raspado sin filtrado previo de categorías especiales, hay un riesgo jurídico aguas arriba que no controlas y que tampoco desaparece porque tú solo seas el usuario final. Documenta lo que preguntaste y lo que te respondieron: eso es lo que te separa de la responsabilidad por elección negligente de proveedor.
Checklist: qué preguntarle a un proveedor de IA antes de firmar
Esta es la parte accionable. Diez preguntas, con lo que debería responder alguien serio y la señal de alarma correspondiente.
| # | Pregunta | Respuesta aceptable | Señal de alarma |
|---|---|---|---|
| 1 | ¿Con qué datos se entrenó el modelo base que usáis? | Fuentes identificadas por categoría, con documentación | "Es información propietaria" sin más |
| 2 | ¿Hubo web scraping en el corpus? ¿De qué tipo de fuentes? | Sí/no claro, con criterios de selección y exclusión | Evasivas o "eso lo hizo el proveedor del modelo" |
| 3 | ¿Cuál es vuestra base jurídica y dónde está el test de interés legítimo? | Documento de análisis en tres pasos, por escrito | "Interés legítimo" como respuesta de una palabra |
| 4 | ¿Qué medidas mitigadoras aplicasteis en el scraping? | Lista concreta: robots.txt, exclusiones, filtrado, opt-out | Ninguna, o solo "cumplimos el RGPD" |
| 5 | ¿Filtrasteis categorías especiales del art. 9 antes de entrenar? | Pipeline de filtrado descrito y evaluado | Silencio, o apelar al art. 9.2.e) sin matices |
| 6 | ¿Mis datos de uso entrenan o reentrenan vuestros modelos? | No por defecto, y contractualmente garantizado | Sí, o "puede desactivarse" sin decir cómo |
| 7 | ¿Dónde se procesan mis datos y hay transferencias fuera del EEE? | Región concreta y mecanismo de transferencia si aplica | "En la nube" |
| 8 | ¿Qué habéis hecho para evaluar la memorización y regurgitación? | Evaluación documentada y filtros de salida | Nunca lo han medido |
| 9 | ¿Cómo atendéis los derechos de acceso, supresión y oposición? | Procedimiento y plazos, incluido qué pasa con el modelo ya entrenado | "El modelo no puede modificarse" como punto final |
| 10 | ¿Qué pasa si las directrices finales de 2026 os obligan a cambiar algo? | Compromiso de adecuación y de informar al cliente | No se lo han planteado |
Un apunte sobre la pregunta 9, la que más fricción genera: es cierto que no se puede "desentrenar" un modelo borrando el registro de una persona. Pero eso no anula el derecho. Hay medidas intermedias —filtros de salida, bloqueo de generación sobre determinados sujetos, exclusión en el siguiente ciclo de entrenamiento, supresión en el corpus y en los sistemas RAG— y un proveedor serio las tiene previstas. Que la solución perfecta no exista no convierte la inacción en respuesta válida.
Cláusulas que deberían estar en el contrato
Más allá del anexo estándar de encargado de tratamiento (art. 28 RGPD), pide por escrito:
- Declaración sobre la procedencia de los datos de entrenamiento, con manifestación expresa sobre el uso de scraping y sobre categorías especiales.
- Prohibición de usar tus datos —inputs y outputs— para entrenar modelos, salvo autorización expresa, separada y revocable.
- Localización del tratamiento y mecanismo de transferencia internacional si sale del EEE.
- Obligación de asistencia en el ejercicio de derechos de los interesados, con plazos concretos.
- Indemnidad frente a reclamaciones de terceros derivadas de la ilicitud del corpus de entrenamiento. Es la cláusula que más se negocia y la que mejor revela cuánta confianza tiene el proveedor en su propio pipeline.
- Cláusula de adecuación regulatoria: compromiso de adaptarse a la versión final de las directrices y de notificarte los cambios materiales.
- Derecho de auditoría o, como mínimo, de acceso a la documentación de cumplimiento. Lo necesitarás también para tus obligaciones bajo el AI Act.
Si tu sistema cae además en alguna categoría de riesgo del Reglamento (UE) 2024/1689, estas cláusulas se solapan con las que ya deberías estar exigiendo: lo desarrollamos en la checklist del AI Act europeo.
Qué hacer entre hoy y el 30 de octubre de 2026
Un plan de tres meses y medio, en orden de rentabilidad:
1. Inventario de datos personales en tus flujos de IA. Qué entra en los prompts, qué se guarda en los logs, qué hay en la base vectorial del RAG. La mayoría de las sorpresas están en los logs, no en la base de datos.
2. Auditoría de tus "datasets anónimos". Localiza todos los conjuntos que tratáis como anónimos, aplica el test de los tres riesgos y reclasifica los que en realidad están seudonimizados. Es un ejercicio de una semana con impacto directo sobre el registro de actividades.
3. Cuestionario a proveedores. Envía las diez preguntas de arriba a cada proveedor de IA que tengas y guarda las respuestas por escrito, incluidas las malas: la ausencia de respuesta también es información, y es tu prueba de diligencia.
4. Decide qué alegas. Si algo del borrador te afecta de forma sustancial, la consulta está abierta hasta el 30 de octubre.
5. Revisa la arquitectura donde el riesgo sea alto. Cuando el dato es sensible y el volumen sostenido, el análisis suele terminar en procesamiento dentro del propio perímetro. Ese cálculo lo desarrollamos en cómo desplegar IA sin enviar datos fuera de la UE.
Si al 30 de octubre tienes inventario, datasets reclasificados y respuestas por escrito de tus proveedores, la versión final de las directrices —salga como salga— será para ti un ejercicio de ajuste, no de reconstrucción. Ese es todo el objetivo: llegar a la norma definitiva con los deberes ya hechos.
Lo que de verdad ha cambiado
Ninguna obligación nueva entró en vigor el 8 de julio. Lo que cambió es el listón implícito: la anonimización deja de ser una etiqueta y pasa a ser un análisis contextual documentado, y el scraping deja de ampararse en el "es público" para tener que demostrar un test de interés legítimo con medidas mitigadoras reales y un tratamiento específico de las categorías especiales.
Para quien construye IA en Europa, la lectura es tranquilizadora si ha hecho las cosas con orden e incómoda si ha ido rápido. Para quien la compra, la conclusión es más simple: el riesgo de cumplimiento de tu proveedor acaba siendo tu riesgo operativo. La diferencia entre las dos posiciones se decide en el contrato, y todavía estamos a tiempo de escribirlo bien.
Aviso legal: este artículo es informativo y refleja el estado de los documentos del EDPB a 15 de julio de 2026, cuando las directrices sobre anonimización y sobre web scraping son borradores en consulta pública. No sustituye al asesoramiento jurídico personalizado.
¿Necesitas ordenar la parte técnica?
En Lin-ia ayudamos a empresas españolas con el lado de ingeniería de todo esto: inventario de datos en flujos de IA, revisión honesta de qué está anonimizado y qué solo lo parece, filtrado de datos personales antes del entrenamiento o del RAG, trazabilidad y despliegues dentro de la UE. No hacemos asesoría jurídica: hacemos que la arquitectura sostenga lo que tu asesor jurídico tiene que firmar.
Si quieres una revisión técnica de tus flujos antes de que las directrices sean definitivas, escríbenos a info@lin-ia.es.
Lecturas relacionadas: IA on-premise sin enviar datos fuera de la UE, AI Act europeo: checklist y cómo validar un caso de uso de IA en 4 semanas.
