Um funcionário, um worm, todo o pipeline

A via de entrada na Suno foi a máquina de uma única pessoa. Um hacker infetou um funcionário individual com um worm que recolheu credenciais do GitHub e dos serviços de nuvem da empresa, e a partir daí chegou aos sistemas que interessavam. O que saiu não foi uma base de dados de clientes no sentido habitual, embora tenham ficado expostos centenas de milhares de registos de clientes, incluindo endereços de correio eletrónico e números de telefone, além de informação de pagamento da Stripe. O que saiu foi o código-fonte de 2023 e 2024: os scripts que construíram o modelo e os comentários que os programadores deixaram uns para os outros enquanto o construíam.

Esta é a forma moderna de uma fuga de dados e merece ser entendida como categoria e não como incidente isolado. Ninguém atacou o produto da Suno. Ninguém encontrou uma falha no modelo. Alguém comprometeu um programador, e as credenciais de um programador abrem o repositório, e o repositório é onde uma empresa guarda o relato mais franco daquilo que realmente fez. O seu programa de segurança trata provavelmente o código-fonte como propriedade intelectual a proteger da concorrência. A leitura mais cara é a de que o código-fonte é um registo contemporâneo das suas decisões, escrito por pessoas que assumiram que os únicos leitores seriam colegas.

O relato da Suno sobre a cronologia é a parte que deveria inquietar quem gere um processo de resposta a incidentes. A empresa diz que a intrusão ocorreu em novembro de 2025, que foi rapidamente contida e que nenhuma informação pessoal sensível foi comprometida. Dê isso por bom e nada muda quanto ao resultado, porque o material veio ao de cima em julho de 2026, cerca de oito meses depois, na secretária de um jornalista. A contenção descreve o que fez ao atacante. Nada diz sobre o calendário de quem ficou com a cópia, e a data de publicação é escolhida por essa pessoa, não por si.

Os números que o código andava a guardar

É a especificidade que torna este caso diferente de todas as histórias anteriores sobre dados de treino de IA. Um comentário num ficheiro lista as fontes que estavam a ser puxadas: genius_hq, youtube_music, freesound, jamendo, imp, deezer, ytm_tagged. Um ficheiro chamado youtube_music regista a ingestão de 2.013.545 clipes de música. Outro conjunto de comentários enumera os conjuntos de dados por duração: 113.879 horas de youtube_music, 152.162 horas de ytm_tagged, 62.117 horas de pond5_music, 19.514 horas de material do 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 e 103 horas de musescore_lyrics. O código descreve também a filtragem para retirar o que não era música, e os podcasts foram obtidos através de feeds RSS.

Leia estes números como os leria um engenheiro e são banais. Leia-os como os leria um advogado e são um inventário. Até agora, a discussão sobre o que os sistemas de música por IA consumiram foi conduzida em adjetivos. Os titulares de direitos falavam em quantidades vastas. As empresas falavam em material publicamente disponível. Ambas as afirmações são infalsificáveis de uma forma útil, o que convinha a toda a gente, porque uma abstração pode ser discutida durante anos. Um número não pode. A Deezer não é um canto vago da Internet aberta, é um serviço europeu com nome, catálogo e condições, e o código diz 12.287 horas.

Há ainda a questão de como o material foi alcançado. As notícias indicam que a Suno poderá ter usado serviços de proxy para puxar música do YouTube, incluindo versões acapella das canções, que são as faixas vocais isoladas que um modelo quereria e que um ouvinte não encontraria por acaso. O recurso a proxies é uma resposta de engenharia banal a limites de pedidos e a bloqueios. É um facto consideravelmente menos banal quando a pergunta diante de um tribunal é se o acesso estava autorizado, porque um proxy existe para fazer um pedido parecer vindo de um sítio de onde não veio.

A Suno não foi apanhada a mentir, e isso é pior

A declaração da empresa depois da fuga não é uma retratação. A Suno afirmou que, tal como já declarou em documentos e divulgações públicas, os seus modelos foram treinados com ficheiros de música publicamente disponíveis e metadados relacionados, acessíveis em sítios de terceiros na Internet aberta. Confronte essa frase com o código e não há contradição. O YouTube Music está na Internet aberta. A Deezer também está, tal como o Genius e o Jamendo. A empresa já tinha dito que treinou com essencialmente todos os ficheiros de música de qualidade razoável acessíveis na Internet aberta, e defendeu que isso constitui fair use, a doutrina norte-americana. Tudo o que o código mostra é coerente com tudo o que a empresa disse.

É essa coerência que constitui o problema, não a defesa. A frase pública e o comentário privado descrevem o mesmo ato em duas resoluções diferentes, e só um deles pode ser sujeito a contrainterrogatório. Um juiz não pode fazer grande coisa com ficheiros de música publicamente disponíveis. Um juiz pode fazer muito com 2.013.545 clipes e um livro-razão de horas fonte a fonte, porque isso converte uma questão de caracterização numa questão de escala, e é a partir da escala que se calculam as indemnizações. A posição jurídica da Suno pode muito bem sobreviver. A sua posição negocial acaba de mudar, porque a outra parte já não tem de provar a dimensão da coisa.

A história comercial em torno do caso mostra exatamente o que está em jogo. As editoras discográficas processaram a Suno por violação de direitos de autor, e a Warner Music Group veio depois a retirar-se da ação em troca de um acordo de licenciamento. É esse o sinal revelador. Este diferendo nunca ia dar uma decisão de princípio sobre aprendizagem automática e direitos de autor, ia dar um conjunto de licenças a um preço. Cada facto que fixa quanto foi retirado e a quem é um facto que mexe nesse preço, e uma lista discriminada com contagens de horas é o documento com maior impacto no preço em todo o processo.

O seu repositório é uma testemunha

Generalize para além da indústria da música, porque o mecanismo nada tem que ver com música. Qualquer organização que treine ou afine um modelo tem um pipeline, e esse pipeline tem fontes, e algures um engenheiro competente escreveu quais são essas fontes e quanto veio de cada uma, porque é isso que os engenheiros competentes fazem. Pode ser um comentário, o nome de um conjunto de dados, um ficheiro de configuração, uma linha num manifesto. Em condições normais, essa documentação é sinal de um sistema bem gerido. Em litígio, ou perante uma fuga, é a descrição mais clara disponível daquilo que a organização ingeriu, escrita pela própria organização, num tom que nenhuma equipa de comunicação alguma vez reviu.

A distância que interessa é a que vai do que os seus advogados acreditam que fez até ao que o seu repositório regista que fez. Os dois relatos são escritos por pessoas diferentes, em momentos diferentes, para públicos diferentes, e só um deles é verificado antes de sair. O programador que dá a um bucket o nome do sítio de onde raspou os dados não está a ser imprudente. Está a ser preciso, num momento em que ninguém lhe disse que a precisão seria lida em voz alta. Se esses relatos se afastaram na sua própria empresa, uma fuga é uma das várias formas de o descobrir, e é aquela em que fica a saber ao mesmo tempo que toda a gente.

Nada disto é argumento para escrever piores comentários. Uma cultura de engenharia que esconde do próprio repositório aquilo que anda a fazer produz sistemas que ninguém consegue auditar, e essa falha custa mais do que qualquer processo judicial. O argumento é para fechar a distância pelo outro lado: saiba o que o seu pipeline consumiu, seja capaz de o declarar nos mesmos termos em que o seu código o declara, e garanta que a frase pública e o comentário privado descrevem o mesmo ato na mesma resolução. Se o fizerem, uma fuga é um incidente de segurança. Se não o fizerem, é uma divulgação.

O que fazer com isto antes de o trimestre acabar

Registe a proveniência do seu modelo enquanto o documento ainda é seu. Para cada modelo que treine, afine ou encomende, registe de que fontes vieram os dados, com que autoridade e, aproximadamente, quanto veio de cada uma. Se produzir essa lista for difícil, essa dificuldade é a conclusão, e é melhor enfrentá-la agora, ao seu próprio ritmo, do que durante a fase de discovery ou na caixa de entrada de um jornalista. As organizações que vão atravessar bem os próximos anos são aquelas cuja resposta à pergunta com que dados treinou é um documento e não um adjetivo.

Trate os postos de trabalho dos programadores como as joias da coroa, porque é isso que são. A Suno perdeu o pipeline através das credenciais de um funcionário para o GitHub e para os serviços de nuvem. O controlo que interessa não é um perímetro maior, é o raio de destruição de um único programador comprometido: autenticação resistente a phishing na plataforma de código, credenciais de nuvem de vida curta em vez de duradouras, e separação suficiente para que uma máquina não abra todo o parque de sistemas. É trabalho sem glamour e sem produto para comprar, e é a diferença entre um incidente e um inventário.

Por fim, deixe de tratar a contenção como encerramento. A Suno conteve uma intrusão em novembro de 2025 e leu sobre o seu próprio código-fonte em julho de 2026. Quando os dados saem, o relógio da exposição não para quando o intruso é expulso, para quando a cópia deixa de valer alguma coisa, e a cópia só deixa de valer quando os factos lá dentro já não importam. Se teve um incidente que foi contido mas em que os dados saíram, o estado honesto não é encerrado. É pendente, e a data de lançamento está nas mãos de outra pessoa.

Leia a seguir: A TfL não pagou resgate e perdeu na mesma 29 milhões  |  Um Commit Não É um Registo de Auditoria