Adobe demandada por entrenar IA con “libros pirateados”: por qué este caso asusta a cualquier empresa que use datasets “open”

INTELIGENCIA ARTIFICIAL · COPYRIGHT · DATASETS “OPEN”

Aviso rápido: esto no es asesoramiento legal. Es una guía práctica para entender el riesgo y reducirlo con ingeniería, trazabilidad y buen gobierno del dato.

1) Qué se acusa exactamente (y por qué no te salva decir “yo usé un dataset open”)

La demanda (en formato de acción colectiva) sostiene, en esencia, que Adobe entrenó una familia de modelos pequeños (SlimLM) usando un dataset que, por su genealogía, incluiría libros con copyright procedentes de una fuente conocida por “pirateo” (Books3). La acusación no se queda en “había cosas con copyright en Internet”: apunta a copiar, almacenar y usar obras completas como material de preentrenamiento sin autorización.

El detalle que hace temblar a cualquiera que entrene modelos con datos de terceros es el argumento de la cadena: si tu dataset es una derivación (aunque esté “limpiado” o “deduplicado”) y hereda material problemático, la responsabilidad puede alcanzarte igualmente.

Imagen: símbolo clásico de disputa legal y litigio por derechos de autor.

2) La ruta del “open”: cómo un libro acaba entrenando tu modelo sin que nadie lo “apruebe”

En IA, el riesgo rara vez entra por la puerta principal. Entra por la escalera de servicio: un dataset “con buena pinta”, una mezcla de fuentes, un repositorio popular, un “ya viene deduplicado”, un “lo usa todo el mundo”.

En este caso, la ruta que se suele mencionar es: Books3 (corpus de libros) → RedPajama (reconstrucción abierta de un gran dataset de entrenamiento) → SlimPajama (versión filtrada/deduplicada) → modelo. Y aquí está la trampa: cada paso intermedio puede mejorar calidad o eficiencia… sin resolver el derecho de uso del texto original.

Imagen: el tipo de contenido que parece “solo texto”… hasta que ese texto es una obra protegida.

3) Qué son Books3 y RedPajama (explicado sin humo)

Books3 es uno de esos nombres que, si trabajas con LLMs, te conviene reconocer como “bandera roja”. Se hizo famoso por ser un corpus enorme de libros (muchos contemporáneos) cuya procedencia se ha señalado repetidamente como incompatible con derechos de autor. ¿Por qué se usó tanto? Porque para un modelo de lenguaje, los libros son oro: estructura, estilo, vocabulario, narrativa, coherencia larga… justo lo que más cuesta aprender.

RedPajama, por su parte, nació como un intento de reconstruir (de forma abierta) un dataset de entrenamiento a gran escala. Mezcla fuentes web, repositorios, papers, etc. En varias discusiones técnicas se ha explicado que su subset “books” estaba ligado a Books3 y que, precisamente por problemas de copyright, partes se retiraron o marcaron como no disponibles.

Y luego llegó el siguiente paso típico en ingeniería de datos: “vale, ahora lo limpiamos”. Así aparecen datasets derivados (como SlimPajama) que prometen deduplicación, filtrado y eficiencia… pero que pueden seguir arrastrando el problema original si la fuente base ya estaba contaminada.

4) El punto que muchas empresas no quieren oír: la licencia del “contenedor” no es un escudo

Este es el malentendido más caro del mundo LLM: que un dataset esté publicado con una licencia “bonita” (Apache-2.0, MIT, etc.) significa, en el mejor de los casos, que el empaquetado y el trabajo de compilación se comparten bajo esa licencia. Pero no convierte en libre el contenido subyacente si ese contenido no tenía permiso.

Dicho a lo bruto: si alguien sube un ZIP “open-source” con 10.000 novelas modernas dentro, el ZIP puede ser “open”… pero las novelas siguen siendo de sus autores.

Por eso este caso asusta: porque el estándar de “debida diligencia” está subiendo. Y si tu defensa es “lo saqué de un repo popular”, te quedas desnudo.

5) Dónde se rompe el compliance en la práctica (los 5 fallos típicos)

La mayoría de equipos no “deciden” entrenar con material problemático. Les pasa por una combinación de prisa + complejidad + suposiciones. Si te suena alguno, estás a tiempo:

• Herencia ciega: “Dataset A” deriva de “Dataset B”, pero nadie documenta qué incluye B (ni si cambió de versión).
• Se confunde “open” con “autorizado”: repositorio público ≠ permiso de explotación.
• Solo se mira el modelo, no el dato: hay model cards, pero no “data cards” ni trazabilidad.
• Se subestima el embedding: “no guardo el libro, guardo vectores” (y aun así has reproducido y procesado la obra).
• Falta de registros: cuando llega la auditoría, nadie puede reconstruir “qué entró”, “cuándo” y “por qué”.

Si quieres una lista más amplia de riesgos operativos (privacidad, alucinaciones, fugas, etc.), te encaja leer también errores típicos al usar IA: alucinaciones y privacidad, porque el patrón es el mismo: confianza excesiva en lo “automático”.

6) Cómo auditar tu pipeline para no comerte un marrón legal

La auditoría no va de “ser perfecto”. Va de poder responder preguntas básicas con evidencia. Piensa en esto como un SBOM, pero de datos: una lista de materiales con procedencia, licencia, versión y riesgos.

Imagen: el pipeline clásico (ETL) aplicado a IA: lo importante es trazar qué entra, qué se transforma y qué acaba entrenando.

Paso 1: inventario brutalmente honesto

Haz una tabla (aunque sea fea) con: nombre del dataset, versión/commit, enlace de origen, fecha de descarga, hash, propietario, licencia declarada y “fuente real” (si la sabes). Si no la sabes, marca UNKNOWN. Esa palabra es oro: te obliga a actuar.

Paso 2: clasificación por riesgo (no por tamaño)

No todos los datos son iguales. En general, sube el riesgo cuando el contenido es: libros modernos, prensa, repositorios privados filtrados, material detrás de paywall, “scrapes” sin consentimiento, dumps sin licencia clara. Baja cuando es: dominio público, licencias explícitas permisivas, datos propios con contratos, o proveedores con garantías e indemnizaciones.

Paso 3: prueba de procedencia (data lineage)

Si usas datasets derivados (lo normal), exige poder reconstruir la genealogía: “esto viene de X, que viene de Y…”. Aquí es donde se te puede colar Books3: no lo has descargado, pero está dentro de una mezcla que luego alguien “limpió”.

Paso 4: controles técnicos (sí, también se puede filtrar)

No hay bala de plata, pero sí medidas útiles:

• Denylist de corpora problemáticos conocidos (y sus derivados) + verificación por hashes, nombres de splits y metadatos.
• Reglas heurísticas: patrones de ISBN, avisos “all rights reserved”, capítulos, índices, referencias editoriales (sirven para priorizar revisión).
• Deduplicación con trazas: deduplicar sin perder el “source_url/source_id” es como limpiar huellas: te deja indefenso.
• Muestreo forense: revisa muestras aleatorias por clase de riesgo (books/news/web), no solo “top tokens”.

Paso 5: gobernanza y documentación (lo que te salva cuando alguien pregunta)

Si mañana un cliente enterprise te pide garantías, no le sirve “confiamos en el repo”. Le sirve: política, proceso, evidencias y responsables. Aquí te encaja como un guante documentar el uso de IA en tu empresa: no por burocracia, sino porque el “papel” (bien hecho) es un mecanismo de supervivencia.

7) Plan rápido: “14 días para bajar el riesgo sin parar el mundo”

8) Las 7 preguntas que deberías poder contestar sin sudar

Si estás entrenando, fine-tuneando o incluso creando embeddings a escala, estas preguntas ya no son paranoia: son higiene profesional.

• ¿Qué datasets exactos (nombre + versión + hash) usé en cada entrenamiento?
• ¿Cuál es la procedencia original de cada corpus (no solo el repo donde lo descargué)?
• ¿Qué licencias aplican al contenido (y qué condiciones imponían)?
• ¿Qué partes son de alto riesgo (books/news/paywalls) y cómo las controlo?
• ¿Puedo demostrar que preservo trazabilidad en transformaciones (dedupe/cleaning)?
• ¿Qué le digo a un cliente si me pide garantías o indemnización?
• ¿Qué haría mañana si un autor afirma: “mi obra está en tu dataset”?