Jeden pracownik, jeden robak, cały pipeline

Drogą do Suno była maszyna jednej osoby. Haker zainfekował pojedynczego pracownika robakiem, który przejął dane logowania do GitHuba i do usług chmurowych firmy, a stamtąd dotarł do systemów, które miały znaczenie. To, co wyszło na zewnątrz, nie było bazą klientów w zwykłym sensie, choć ujawnione zostały setki tysięcy rekordów klientów, w tym adresy e-mail i numery telefonów, wraz z informacjami płatniczymi Stripe. To, co wyszło, to kod źródłowy z lat 2023 i 2024: skrypty, które zbudowały model, i komentarze, które inżynierowie zostawiali sobie nawzajem podczas budowania.

To jest współczesny kształt wycieku i zasługuje na to, by rozumieć go jako kategorię, a nie incydent. Nikt nie zaatakował produktu Suno. Nikt nie znalazł luki w modelu. Ktoś przejął konto programisty, a dane logowania programisty otwierają repozytorium, repozytorium zaś jest miejscem, w którym firma trzyma najbardziej szczery zapis tego, co naprawdę zrobiła. Twój program bezpieczeństwa traktuje zapewne kod źródłowy jako własność intelektualną chronioną przed konkurencją. Droższa interpretacja mówi, że kod źródłowy jest bieżącym zapisem twoich decyzji, spisanym przez ludzi, którzy zakładali, że jedynymi czytelnikami będą koledzy z zespołu.

Relacja Suno o czasie zdarzeń to część, która powinna zaniepokoić każdego, kto prowadzi proces obsługi incydentów. Firma mówi, że włamanie miało miejsce w listopadzie 2025 roku, że zostało szybko opanowane i że żadne wrażliwe dane osobowe nie zostały naruszone. Przyjmij to za dobrą monetę, a i tak nic to nie zmienia w wyniku, ponieważ materiał wypłynął w lipcu 2026 roku, mniej więcej osiem miesięcy później, na biurku dziennikarza. Opanowanie opisuje to, co zrobiłeś napastnikowi. Nie mówi nic o kalendarzu osoby, która trzyma kopię, a to ona wybiera datę publikacji, nie ty.

Liczby, które przechowywał kod

Szczegółowość jest tym, co odróżnia tę historię od każdej wcześniejszej opowieści o danych treningowych AI. Komentarz w jednym z plików wymienia zaciągane źródła: genius_hq, youtube_music, freesound, jamendo, imp, deezer, ytm_tagged. Plik o nazwie youtube_music odnotowuje wchłonięcie 2 013 545 klipów muzycznych. Inny zestaw komentarzy wylicza zbiory danych według czasu trwania: 113 879 godzin youtube_music, 152 162 godziny ytm_tagged, 62 117 godzin pond5_music, 19 514 godzin materiału z International Music Score Library Project, 17 615 godzin genius_hq, 12 287 godzin deezer, 3 726 godzin jamendo, 410 godzin freesound i 103 godziny musescore_lyrics. Kod opisuje też filtrowanie, które usuwało to, co nie było muzyką, a podcasty zaciągano przez kanały RSS.

Przeczytaj te liczby jak inżynier, a są przyziemne. Przeczytaj je jak prawnik, a są spisem inwentarzowym. Do tej pory spór o to, co pochłonęły muzyczne systemy AI, toczył się w przymiotnikach. Posiadacze praw mówili o ogromnych ilościach. Firmy mówiły o publicznie dostępnym materiale. Oba zdania są niefalsyfikowalne w użyteczny sposób, co odpowiadało wszystkim, bo o abstrakcję można spierać się latami. O liczbę nie można. Deezer nie jest mglistym zakątkiem otwartego internetu; to nazwany europejski serwis z katalogiem i regulaminem, a kod mówi: 12 287 godzin.

Jest też kwestia tego, w jaki sposób sięgano po ten materiał. Doniesienia wskazują, że Suno mogło korzystać z usług proxy, aby pobierać muzykę z YouTube, w tym wersje acapella utworów, czyli wyodrębnione ścieżki wokalne, których chciałby model, a na które słuchacz nie natknąłby się mimochodem. Proxy to zwyczajna inżynierska odpowiedź na limity zapytań i blokady. Jest to znacznie mniej zwyczajny fakt, gdy pytanie przed sądem brzmi, czy dostęp był autoryzowany, ponieważ proxy istnieje po to, by zapytanie wyglądało, jakby przyszło skądinąd.

Suno nie przyłapano na kłamstwie, co jest gorsze

Oświadczenie firmy po wycieku nie jest odwołaniem wcześniejszych słów. Suno stwierdziło, że - jak podawało w publicznych dokumentach i ujawnieniach - jego modele były trenowane na publicznie dostępnych plikach muzycznych i powiązanych metadanych dostępnych w serwisach osób trzecich w otwartym internecie. Zestaw to zdanie z kodem, a sprzeczności nie ma. YouTube Music jest w otwartym internecie. Tak samo Deezer, tak samo Genius, tak samo Jamendo. Firma mówiła wcześniej, że trenowała na zasadniczo wszystkich plikach muzycznych o rozsądnej jakości dostępnych w otwartym internecie, i argumentowała, że stanowi to fair use. Wszystko, co pokazuje kod, jest spójne ze wszystkim, co firma powiedziała.

Ta spójność jest problemem, a nie linią obrony. Publiczne zdanie i prywatny komentarz opisują ten sam czyn w dwóch różnych rozdzielczościach, a przesłuchać można tylko jedno z nich. Sędzia niewiele może zrobić z publicznie dostępnymi plikami muzycznymi. Sędzia może zrobić bardzo wiele z 2 013 545 klipami i rejestrem godzin źródło po źródle, bo to zamienia pytanie o kwalifikację w pytanie o skalę, a to skala jest podstawą, od której oblicza się odszkodowania. Prawna pozycja Suno może się obronić. Jego pozycja negocjacyjna właśnie się zmieniła, bo druga strona nie musi już udowadniać rozmiaru tej rzeczy.

Handlowa historia wokół tej sprawy pokazuje dokładnie, o co toczy się gra. Wytwórnie płytowe pozwały Suno o naruszenie praw autorskich, a Warner Music Group następnie wycofał się z postępowania w zamian za umowę licencyjną. To jest ten zdradliwy sygnał. Ten spór nigdy nie zmierzał do pryncypialnego rozstrzygnięcia o uczeniu maszynowym i prawie autorskim; zmierzał do zestawu licencji za określoną cenę. Każdy fakt, który przypina, ile i komu zabrano, jest faktem przesuwającym tę cenę, a wyszczególniona lista z liczbami godzin jest najbardziej cenotwórczym dokumentem w całej sprawie.

Twoje repozytorium jest świadkiem

Uogólnij to poza branżę muzyczną, bo mechanizm nie ma z muzyką nic wspólnego. Każda organizacja trenująca lub dostrajająca model ma pipeline, ten pipeline ma źródła, a gdzieś kompetentny inżynier zapisał, jakie to źródła i ile pochodzi z każdego z nich, bo tak właśnie robią kompetentni inżynierowie. Może to być komentarz, nazwa zbioru danych, plik konfiguracyjny, wiersz w manifeście. W normalnych warunkach ta dokumentacja jest oznaką dobrze prowadzonego systemu. W sporze sądowym albo przy wycieku jest najczytelniejszym dostępnym oświadczeniem o tym, co organizacja wchłonęła, napisanym przez samą organizację, w tonie, którego żaden dział komunikacji nigdy nie przejrzał.

Luka, która ma znaczenie, jest między tym, co twoi prawnicy sądzą, że zrobiłeś, a tym, co twoje repozytorium zapisuje, że zrobiłeś. Te dwie relacje piszą różni ludzie, w różnym czasie, dla różnych odbiorców, a tylko jedna z nich jest sprawdzana, zanim wyjdzie na zewnątrz. Inżynier nazywający kubełek od serwisu, z którego go zescrapowano, nie jest lekkomyślny. Jest precyzyjny w chwili, gdy nikt mu nie powiedział, że ta precyzja zostanie odczytana na głos. Jeśli w twojej własnej firmie te relacje się rozjechały, wyciek jest jednym z kilku sposobów, by się o tym dowiedzieć, i tym jedynym, w którym dowiadujesz się w tym samym momencie co wszyscy.

Nic z tego nie przemawia za pisaniem gorszych komentarzy. Kultura inżynierska, która ukrywa przed własnym repozytorium to, co robi, produkuje systemy, których nikt nie może poddać audytowi, a ta porażka kosztuje więcej niż jakikolwiek pozew. Argument dotyczy zamknięcia luki od drugiej strony: wiedz, co pochłonął twój pipeline, umiej powiedzieć to tymi samymi słowami, którymi mówi to twój kod, i zadbaj o to, by publiczne zdanie i prywatny komentarz opisywały ten sam czyn w tej samej rozdzielczości. Jeśli tak jest, wyciek jest incydentem bezpieczeństwa. Jeśli nie, jest ujawnieniem.

Co z tym zrobić, zanim skończy się kwartał

Spisz pochodzenie danych swojego modelu, dopóki jest to jeszcze twój dokument. Dla każdego modelu, który trenujesz, dostrajasz albo zamawiasz, zapisz, z jakich źródeł pochodziły dane, na jakiej podstawie i mniej więcej ile z każdego. Jeśli sporządzenie takiej listy jest trudne, to właśnie ta trudność jest wnioskiem, i lepiej zmierzyć się z nią teraz, we własnym czasie, niż na etapie postępowania dowodowego albo w skrzynce dziennikarza. Organizacje, które dobrze przejdą przez najbliższe lata, to te, których odpowiedzią na pytanie "na czym trenowaliście" jest dokument, a nie przymiotnik.

Traktuj urządzenia programistów jak klejnoty koronne, bo nimi są. Suno straciło swój pipeline przez dane logowania jednego pracownika do GitHuba i usług chmurowych. Kontrolą, która ma znaczenie, nie jest większy perymetr, lecz zasięg rażenia jednego przejętego programisty: odporne na phishing uwierzytelnianie na platformie z kodem, krótkotrwałe poświadczenia chmurowe zamiast trwałych i taka separacja, żeby jedna maszyna nie otwierała całej infrastruktury. To mało efektowna praca, do której nie ma produktu do kupienia, i to ona jest różnicą między incydentem a spisem inwentarzowym.

Na koniec przestań traktować opanowanie jako zamknięcie sprawy. Suno opanowało włamanie w listopadzie 2025 roku i przeczytało o własnym kodzie źródłowym w lipcu 2026 roku. Kiedy dane wychodzą na zewnątrz, zegar ekspozycji nie zatrzymuje się w chwili wyrzucenia intruza; zatrzymuje się, gdy kopia staje się bezwartościowa, a kopia jest bezwartościowa dopiero wtedy, gdy fakty w środku przestają mieć znaczenie. Jeśli miałeś incydent, który został opanowany, ale dane wyszły, uczciwym statusem nie jest "zamknięty". Jest "w toku", a datę publikacji trzyma ktoś inny.

Czytaj dalej: TfL nie zapłaciło okupu, a i tak straciło 29 milionów  |  Jeden commit to nie ślad audytowy