Un empleado, un gusano, toda la canalización
La vía de entrada a Suno fue la máquina de una sola persona. Un hacker infectó a un empleado concreto con un gusano que capturó credenciales de GitHub y de los servicios en la nube de la empresa, y desde ahí alcanzó los sistemas que importaban. Lo que salió no fue una base de datos de clientes en el sentido corriente, aunque quedaron expuestos cientos de miles de registros de clientes, incluidas direcciones de correo y números de teléfono, junto con información de pago de Stripe. Lo que salió fue el código fuente de 2023 y 2024: los scripts que construyeron el modelo, y los comentarios que los ingenieros se dejaron unos a otros mientras lo construían.
Esta es la forma moderna de una brecha y merece entenderse como una categoría y no como un incidente. Nadie atacó el producto de Suno. Nadie encontró un fallo en el modelo. Alguien comprometió a un desarrollador, y las credenciales de un desarrollador abren el repositorio, y el repositorio es donde una empresa guarda el relato más franco de lo que hizo en realidad. Su programa de seguridad probablemente trata el código fuente como propiedad intelectual que hay que proteger de la competencia. La lectura más cara es que el código fuente es un registro contemporáneo de sus decisiones, escrito por gente que daba por hecho que los únicos lectores serían sus compañeros.
El relato de Suno sobre los tiempos es la parte que debería inquietar a cualquiera que dirija un proceso de incidentes. La empresa dice que la intrusión se produjo en noviembre de 2025, que se contuvo con rapidez y que no se comprometió información personal sensible. Tómelo al pie de la letra y no cambia nada del resultado, porque el material salió a la luz en julio de 2026, unos ocho meses después, en la mesa de un periodista. La contención describe lo que usted hizo con el atacante. No dice nada sobre el calendario de quien tiene la copia, y la fecha de publicación la elige esa persona, no usted.
Los números que el código guardaba
La especificidad es lo que hace que esto sea distinto de cualquier historia anterior sobre datos de entrenamiento de IA. Un comentario en un archivo enumera las fuentes de las que se extrae: genius_hq, youtube_music, freesound, jamendo, imp, deezer, ytm_tagged. Un archivo llamado youtube_music registra la ingesta de 2.013.545 clips musicales. Otro conjunto de comentarios enumera los conjuntos de datos por duración: 113.879 horas de youtube_music, 152.162 horas de ytm_tagged, 62.117 horas de pond5_music, 19.514 horas de material del International Music Score Library Project, 17.615 horas de genius_hq, 12.287 horas de deezer, 3.726 horas de jamendo, 410 horas de freesound y 103 horas de musescore_lyrics. El código describe también un filtrado para descartar lo que no era música, y los podcasts se extrajeron mediante fuentes RSS.
Lea esas cifras como las leería un ingeniero y son mundanas. Léalas como las leería un abogado y son un inventario. Hasta ahora, la discusión sobre lo que consumieron los sistemas musicales de IA se ha conducido en adjetivos. Los titulares de derechos decían cantidades ingentes. Las empresas decían material disponible públicamente. Ambas afirmaciones son infalsables de una manera útil, lo que le convenía a todo el mundo, porque una abstracción puede discutirse durante años. Un número no puede. Deezer no es un rincón vago de la internet abierta; es un servicio europeo con nombre, catálogo y condiciones, y el código dice 12.287 horas.
Está también la cuestión de cómo se llegó al material. La información periodística indica que Suno pudo haber usado servicios de proxy para extraer música de YouTube, incluidas versiones a capela de canciones, que son las pistas vocales aisladas que un modelo querría y que un oyente no encontraría de forma casual. El uso de proxies es una respuesta de ingeniería corriente a los límites de tasa y a los bloqueos. Es un hecho considerablemente menos corriente cuando la pregunta ante un tribunal es si el acceso estaba autorizado, porque un proxy existe para que una petición parezca venir de donde no venía.
A Suno no la sorprendieron mintiendo, y eso es peor
El comunicado de la empresa tras la brecha no es una rectificación. Suno dijo que, como ha declarado en sus documentos públicos y divulgaciones, sus modelos se han entrenado con archivos de música disponibles públicamente y metadatos relacionados accesibles en sitios web de terceros en la internet abierta. Coteje esa frase con el código y no hay contradicción. YouTube Music está en la internet abierta. También lo está Deezer, también Genius, también Jamendo. La empresa ha dicho antes que entrenó con esencialmente todos los archivos de música de calidad razonable accesibles en la internet abierta, y ha sostenido que eso constituye fair use. Todo lo que muestra el código es coherente con todo lo que dijo la empresa.
Esa coherencia es el problema, no la defensa. La frase pública y el comentario privado describen el mismo acto a dos resoluciones distintas, y solo a una de ellas se la puede someter a contrainterrogatorio. Un juez no puede hacer gran cosa con archivos de música disponibles públicamente. Un juez puede hacer muchísimo con 2.013.545 clips y un libro mayor de horas fuente por fuente, porque eso convierte una cuestión de calificación en una cuestión de escala, y la escala es la base sobre la que se calcula la indemnización. La posición jurídica de Suno puede muy bien sobrevivir. Su posición negociadora acaba de cambiar, porque la otra parte ya no tiene que demostrar el tamaño de la cosa.
La historia comercial que rodea al caso muestra exactamente qué está en juego. Las discográficas demandaron a Suno por infracción de derechos de autor, y Warner Music Group se retiró posteriormente del procedimiento a cambio de un acuerdo de licencia. Esa es la señal reveladora. Esta disputa nunca se dirigía hacia un fallo de principio sobre aprendizaje automático y derechos de autor; se dirigía hacia un conjunto de licencias a un precio. Cada hecho que fija cuánto se tomó y a quién es un hecho que mueve ese precio, y una lista detallada con recuentos de horas es el documento que más mueve el precio de todo el asunto.
Su repositorio es un testigo
Generalice más allá de la industria musical, porque el mecanismo no tiene nada que ver con la música. Cualquier organización que entrene o afine un modelo tiene una canalización, y esa canalización tiene fuentes, y en algún sitio un ingeniero competente ha anotado cuáles son esas fuentes y cuánto vino de cada una, porque eso es lo que hacen los ingenieros competentes. Puede ser un comentario, el nombre de un conjunto de datos, un archivo de configuración, una fila en un manifiesto. En condiciones normales, esa documentación es señal de un sistema bien llevado. Bajo litigio, o bajo una brecha, es la declaración más clara disponible de lo que la organización ingirió, redactada por la propia organización, en un tono que ningún equipo de comunicación revisó jamás.
La distancia que importa está entre lo que sus abogados creen que hizo y lo que su repositorio registra que hizo. Esos dos relatos los escriben personas distintas, en momentos distintos, para públicos distintos, y solo uno de ellos se revisa antes de salir. El ingeniero que bautiza un bucket con el nombre del sitio del que se extrajo no está siendo temerario. Está siendo preciso, en un momento en el que nadie le dijo que la precisión se leería en voz alta. Si esos relatos se han separado en su propia empresa, una brecha es una de las varias formas de enterarse, y es aquella en la que se entera a la vez que todos los demás.
Nada de lo cual defiende escribir peores comentarios. Una cultura de ingeniería que esconde lo que hace de su propio repositorio produce sistemas que nadie puede auditar, y ese fallo cuesta más que cualquier demanda. El argumento es cerrar la distancia por el otro extremo: saber qué consumió su canalización, poder enunciarlo en los mismos términos en los que lo enuncia su código, y asegurarse de que la frase pública y el comentario privado describen el mismo acto a la misma resolución. Si lo hacen, una brecha es un incidente de seguridad. Si no, es una divulgación.
Qué hacer con esto antes de que acabe el trimestre
Escriba la procedencia de su modelo mientras siga siendo su documento. Para cada modelo que entrene, afine o encargue, registre de qué fuentes vinieron los datos, con qué autorización y aproximadamente cuánto de cada una. Si producir esa lista resulta difícil, esa dificultad es el hallazgo, y es mejor afrontarla ahora, en su propio tiempo, que durante la fase de exhibición de pruebas o en la bandeja de entrada de un periodista. Las organizaciones que manejen bien los próximos años son aquellas cuya respuesta a ¿con qué entrenó? es un documento y no un adjetivo.
Trate los equipos de los desarrolladores como las joyas de la corona, porque lo son. Suno perdió su canalización a través de las credenciales de GitHub y de los servicios en la nube de un solo empleado. El control que importa no es un perímetro más grande, sino el radio de impacto de un único desarrollador comprometido: autenticación resistente al phishing en la plataforma de código, credenciales de nube de vida corta en lugar de duraderas, y separación suficiente para que una máquina no abra todo el parque de sistemas. Ese trabajo no tiene glamour y no hay producto que comprar, y es la diferencia entre un incidente y un inventario.
Por último, deje de tratar la contención como un cierre. Suno contuvo una intrusión en noviembre de 2025 y leyó sobre su propio código fuente en julio de 2026. Cuando los datos salen, el reloj de la exposición no se para cuando se expulsa al intruso; se para cuando la copia no vale nada, y la copia no vale nada solo cuando los hechos que contiene ya no importan. Si ha tenido un incidente contenido pero en el que salieron datos, el estado honesto no es cerrado. Es pendiente, y la fecha de publicación la tiene otro.
Leer a continuación: TfL no pagó rescate y aun así perdió 29 millones | Un commit no es un registro de auditoría



