La RIAA propone etiquetas para música con IA. Esto es lo que los distribuidores tienen que hacer antes de que lo haga el DSP.
Hoy el Wall Street Journal reportó que la RIAA, la IFPI, la Recording Academy, A2IM y la Human Artistry Campaign están presionando a Spotify, Apple Music y al resto de los DSPs para que peguen dos etiquetas a cada release: AI-generated y AI-assisted. Esto es un problema de distribuidor, no de DSP. Acá va el por qué.
Qué se propuso
Dos etiquetas visuales, pensadas para aparecer al lado del track en la UI del servicio de streaming:
La propuesta la coordinan la RIAA y la IFPI, con la Recording Academy, SAG-AFTRA, la Human Artistry Campaign y — dato clave — A2IM (la American Association of Independent Music) a bordo. Esto último importa: significa que el carril indie está alineado con los majors en este tema, no peleando contra ellos.
El estándar exacto de etiquetado, el campo DDEX específico, la fecha de entrada en vigor y el régimen de penalidades todavía no son públicos. Lo que sí está claro: las etiquetas se proponen como metadata obligatoria adjunta al momento de la entrega. Eso pone la carga de clasificación sobre quien envía el track — el distribuidor — no sobre el DSP.
Por qué esto cae sobre los distribuidores, no sobre los DSPs
Una lectura común de la noticia es "Spotify va a resolver esto". Es exactamente al revés. Los DSPs son la parte que exige la etiqueta; el distribuidor es la parte que la suministra, en el manifiesto DDEX, en el momento de la entrega. Si la etiqueta está mal o falta:
- Mejor caso: el DSP rebota el release, el distribuidor come el costo de reenvío, se rompen los SLAs de entrega.
- Caso intermedio: el DSP acepta el release bajo la etiqueta incorrecta, después lo reclasifica con su propia detección, y emite un strike contra el trust-score del distribuidor.
- Peor caso: el mislabeling repetido dispara la misma acción de enforcement que Spotify ya aplica al AI mass-uploading — retención de payouts, penalidades por track bajo la política anti-fraude 2024-2025 de Spotify, y auditorías de catálogo.
Los DSPs van a construir su propio detector de IA en cualquier caso. Todos los DSPs mayores ya lo están corriendo o están a punto. Eso no es buena noticia para los distribuidores — es mala. Significa que cada track mal etiquetado que un distribuidor envíe va a ser cazado y atribuido al distribuidor. El detector del DSP no es amigo del distribuidor; es su auditor.
Las etiquetas propuestas mueven la procedencia por IA de ser una preocupación editorial opcional a ser una pieza obligatoria de la metadata de entrega. Equivocarse en la entrega es un evento de cumplimiento, no una cuestión de gusto.
La clasificación que una capa pre-upload tiene que emitir
Para poder pegar la etiqueta correcta al momento de la entrega, el pipeline de ingesta del distribuidor necesita una función de decisión que corra antes de la generación del DDEX. Concretamente, para cada track entrante necesita tres salidas:
- Clase de procedencia — humano, AI-assisted (híbrido), o AI-generated. Este es el input directo al campo de etiqueta RIAA.
- Confianza + trazabilidad de auditoría — evidencia suficiente para defender la etiqueta si el DSP la disputa después. Si el detector del DSP no coincide con el del distribuidor, el distribuidor tiene que poder mostrar el veredicto del revisor, la versión del modelo y el score al momento de la entrega.
- Atribución (cuando sea posible) — Suno, Udio, MusicGen, otro. No es requerido por la propuesta RIAA, pero rápidamente se vuelve útil para la política interna del distribuidor: los modelos licenciados (Udio, ElevenLabs Music) pueden entregarse bajo etiqueta
AI-generated; los uploads Suno sin licencia son típicamente además fraude de copyright y no deberían enviarse en absoluto.
Este no es un problema nuevo inventado por la propuesta de la RIAA. Es la misma capa de detección que los clientes de DistroShield vienen corriendo en producción desde abril de 2026 — las etiquetas simplemente lo convierten en un requerimiento de cumplimiento en lugar de una preferencia operativa.
Lo que DistroShield ya emite
El modelo actual en producción (v9, deployado el 2026-06-23) es un clasificador primario de 4 clases más una etapa de atribución. Mapeado contra las etiquetas RIAA propuestas:
| Clase primaria DistroShield | Atribución | Etiqueta RIAA propuesta |
|---|---|---|
human | — | Sin etiqueta |
hybrid (derivado del ensemble) | — | ai AI-assisted |
licensed_ai | Udio, ElevenLabs, etc. | AI AI-generated |
suno_unlicensed | Suno | AI AI-generated (típicamente bloquear, no etiquetar) |
unknown_ai | MusicGen / otro / desconocido | AI AI-generated |
Métricas del test set para v9 tal como está deployado: recall de humano 98.31%, recall binario de IA 98.68%, F1 macro 0.92 entre las cuatro clases. La API devuelve la clase primaria, la confianza, señales por módulo y — cuando aplica — la identificación del generador por parte del modelo de atribución. Las tres piezas que necesita un distribuidor para pegar la etiqueta y defenderla después ya están en el payload de respuesta.
El único matiz que la propuesta de la RIAA no aborda (y que los distribuidores igual van a tener que decidir por su cuenta): los tracks de Suno sin licencia casi siempre son fraude de copyright, no solo procedencia por IA. Pegarles una etiqueta AI-generated no los blanquea como inventario entregable. La recomendación default de DistroShield para esa clase es block, no label. El detector de procedencia y el detector de fraude son la misma pasada de audio, pero responden preguntas distintas.
Qué cambia para nosotros
No mucho del lado técnico — la clasificación que ya emitimos es un superset de lo que necesita el esquema de dos etiquetas. Dos updates en el roadmap:
- Alinear el vocabulario. El campo
classificationde la API pública devuelve hoy valores comoaiyhybrid. Cuando la propuesta RIAA se solidifique en un estándar real con un campo DDEX definido, vamos a agregar un stringriaa_labelen la respuesta que devuelva exactamente"ai-generated","ai-assisted", onull, para que los distribuidores lo puedan meter directo al manifiesto de entrega sin capa de traducción. - Publicar el contrato de auditoría. Vamos a extender los docs para dejar por escrito qué campos de la respuesta de análisis son lo suficientemente estables como para referenciarlos en una disputa con un DSP — versión del modelo, scores, timestamps, IDs de veredictos de revisor. Si un DSP después impugna una etiqueta, el distribuidor debería poder entregar un JSON blob y cerrar el caso.
No planeamos cambiar la arquitectura del modelo en respuesta al anuncio. La decisión de procedencia de cuatro clases que el modelo ya toma es más granular de lo que el esquema de dos etiquetas requiere, y esa resolución extra importa para la distinción fraude-vs-etiqueta de arriba.
Si eres distribuidor y estás leyendo esto
Tres cosas que vale la pena hacer antes de que el estándar aterrice como campo obligatorio:
- Auditá tu exposición actual al mislabeling. Tomá una muestra de 100 de los últimos 1,000 tracks que entregaste. Pasalos por un detector. Cualquier track que el detector marque como IA donde tu DDEX decía humano es una liability de cumplimiento el día que el estándar se prenda. Ese número lo querés saber ahora, en silencio, no después.
- Definí la política de AI-assisted internamente. La propuesta no define un umbral para "se apoya en IA en algunas partes". Algunos de tus artistas usan stems masterizados por IA. Algunos usan coros generados por IA. Algunos usan auto-tune más algunos rellenos generados por IA. Todos estos van a necesitar una regla de la casa. Mejor escribirla una vez que responderla por release bajo presión del DSP.
- Elegí una capa pre-upload. La capa no tiene que ser nosotros — Audible Magic, Pex, o un modelo hecho en casa también sirven. Sí tiene que correr antes del generador DDEX, no después de la entrega. Ese es el punto entero de la propuesta RIAA moviendo la etiqueta a metadata.
Los DSPs van a construir sus propios detectores. Eso está dado. Los distribuidores que envíen la etiqueta correcta a la primera no van a escuchar sobre esto. Los que no, van a escuchar mucho.