Нейромузыка, фиты и зарубежный дистрибьютор: как мы готовили документы для музыкального сервиса
Готовя документы по 152-ФЗ, мы разобрали путь релиза и нашли запрет дистрибьютора на музыку от ИИ, неочевидную передачу данных за рубеж и чужие данные в фитах.
В этой истории
Коротко о проекте
- Клиент
- Онлайн-сервис для музыкальных релизов, который готовился к запуску платных функций. Название сервиса и сведения о владельце не раскрываем.
- Как устроен сервис
- Артист создаёт трек с помощью нейросети и собирает релиз с обложкой и авторами. Сервис отправляет его дистрибьютору для публикации на стриминговых площадках и выплачивает артистам роялти.
- Задача
- Документы по 152-ФЗ, инструкция разработчику и уведомление в Роскомнадзор.
- Главная сложность
- Данные артистов уходили дальше сайта, поэтому кроме форм сервиса пришлось разбирать условия дистрибьютора.
- Результат
- Клиент отказался от дистрибьютора, который запрещал музыку от ИИ и принимал релизы за рубежом. Совместные треки перестроили под согласия соисполнителей. Документы подготовили под фактическую модель сервиса, черновик уведомления заполнили в личном кабинете Роскомнадзора.
Сайт уже работал на шаблонных документах, а впереди были подписка и выплаты артистам по паспортным данным. Документы мы подготовили, но самым полезным в проекте оказался разговор о дистрибьюторе, хотя в коммерческом предложении о нём не было ни слова.
Аудит: шаблоны и одна галочка на всё
В день обращения мы проверили сайт снаружи и в тот же вечер прислали отчёт. Картина была типичной для молодого сервиса. В документах не было сведений об операторе, сами тексты взяли из шаблонов. Cookie-баннер считал согласием простое продолжение работы с сайтом, а одна галочка в форме верификации одновременно принимала оферту и давала согласие на обработку данных. Уведомление в Роскомнадзор не подавалось.
Нашлась и забавная деталь. В форме стоял чекбокс согласия на трансграничную передачу, хотя по описанию клиента за рубеж ничего не уходило. Позже выяснилось, что передача всё-таки была, только в другом месте и по другой схеме, и галочкой её было не оформить.
Куда на самом деле уходят данные
Анкета показывает, какие данные есть у бизнеса, но почти ничего не говорит о том, куда они движутся. Поэтому дальше мы работали звонками. Оказалось, что вместе с треком дистрибьютору уходят обложка и авторы музыки и текста, иногда под настоящими именами. Для выплат роялти сервис будет запрашивать паспорт и статус самозанятого или ИП.
Про вход клиент сначала сказал, что сервис ничего не получает, потому что подтверждение идёт в окне внешнего сервиса авторизации. Мы попросили уточнить у разработчиков. От такого сервиса обычно приходят как минимум идентификатор пользователя и технические данные, а их тоже можно отнести к персональным.
| Какие данные | Откуда | Куда уходят |
|---|---|---|
| Учётная запись и данные для входа | Пользователь и сервис авторизации | Хранятся в сервисе, на российской инфраструктуре |
| Трек, псевдоним, обложка, авторы музыки и текста | Артист заполняет форму релиза | Дистрибьютору, а от него на площадки |
| Псевдоним соисполнителя, иногда имя, изображение, соцсети | Другой пользователь, который собирает релиз | Туда же, вместе с релизом |
| Паспорт, статус самозанятого или ИП, реквизиты | Отдельная форма выплат | Сервису для выплаты роялти |
Третья строка поначалу выглядела безобидно. К ней мы ещё вернёмся.
Условия дистрибьютора оказались важнее документов
Клиент назвал дистрибьютора, российскую компанию с публичной офертой, и мы прочитали её документы. Релизы эта компания не принимала вообще, она продавала подписку на доступ к зарубежной платформе. Аудио, обложки и имена артистов уходили прямо туда, а управляла платформой иностранная компания.
В условиях платформы нашлось кое-что серьёзнее вопросов о персональных данных: прямой запрет на музыку, созданную искусственным интеллектом, с автоматическим распознаванием и удалением без возврата денег. Для сервиса на нейромузыке это означало, что бизнес-модель упирается в правила партнёра. Мы написали клиенту в тот же вечер, хотя к нашим документам это отношения не имело.
- Артист создаёт трек в нейросети и собирает релиз
- Сервис загружает все релизы под одним своим аккаунтом
- Зарубежная платформа получает трек, обложку и имена артистов, запрещает музыку от ИИ
- Стриминговые площадки
На следующий день клиент получил записку с разбором. Первая проблема была деловой: сервис загружал бы релизы под своим аккаунтом и сам заверял бы платформу, что нейросетей в треках нет. При блокировке платформа удержала бы роялти всех артистов, и сервис остался бы им должен без источника выплат.
Вторая проблема касалась трансграничной передачи (пункт 11 статьи 3 закона № 152-ФЗ). До первой отправки релиза пришлось бы запросить сведения у иностранной компании и подать в Роскомнадзор отдельное уведомление (статья 12). Документы платформы к тому же называли получателем компании из разных стран, а от страны зависело, можно ли начинать передачу сразу после уведомления.
Клиент спорил, и это помогло
Клиент возразил, что договор у них с российской компанией, а площадкам сервис напрямую ничего не отправляет. Мы понимали, откуда вопрос: снаружи схема выглядит российской. Но для закона важно, кто фактически получает данные, и купленная в России подписка этого не меняет.
Решение нашлось быстро. У клиента уже были договорённости с полностью российским дистрибьютором, и мы поставили одно условие: новый партнёр должен сам принимать и публиковать релизы, без зарубежной платформы посередине. Тогда он становится самостоятельным оператором, и передачу на зарубежные площадки оформляет уже он. Обратный сценарий тоже был рабочим: передачу за рубеж можно оформить уведомлением, разрешения для неё не требуется. Просто это дольше.
- Артист загружает трек и собирает релиз
- Сервис передаёт только данные, нужные для дистрибуции
- Российский дистрибьютор сам принимает и публикует релиз
- Площадки в России и за рубежом передачу за рубеж оформляет дистрибьютор
Фиты: будничная функция с чужими данными
Сервис позволял добавить к релизу второго исполнителя. Его псевдоним, иногда имя, фото на обложке и ссылки на соцсети вписывает другой пользователь, а после публикации их видят все (пункт 5 статьи 3). Получается, сервис публикует данные человека, который с ним ни о чём не договаривался.
Сослаться на договор нельзя, соисполнитель оферту не принимал (пункт 5 части 1 статьи 6). Нужны отдельное согласие на распространение (статья 10.1) и согласие на использование изображения (статья 152.1 Гражданского кодекса). А ещё сервис обязан сообщить человеку, что получил его данные от другого пользователя (часть 3 статьи 18), хотя контактов соисполнителя у него нет.
Клиент признался, что считал фиты рутиной. Мы понимали, как это выглядит: юристы пришли за документами, а просят переделать функцию. Поэтому искали самый лёгкий вариант. В нейромузыке один человек часто создаёт двух артистов и выпускает фит между своими же карточками, а если оба артиста зарегистрированы в сервисе, вопрос о чужих данных снимается. От жёстких ограничений для обложек мы отказались сами: артист вправе поставить своё фото, и ломать привычную функцию ради редкого случая незачем. А чтобы схема работала, сверх согласованного списка добавили в комплект согласие на использование изображения.
- Автор собирает релиз и находит соисполнителя по псевдониму среди зарегистрированных пользователей. Чужой email или телефон вводить не нужно
- Соисполнитель получает приглашение видит релиз и перечень своих данных, которые попадут в публикацию
- Даёт согласие на распространение отдельной галочкой и только для этого релиза
- Если на обложке его изображение даёт ещё одно, отдельное согласие на его использование
- Релиз уходит дистрибьютору не раньше, чем получены все согласия
Сервис поменялся уже после сдачи
Вскоре после сдачи документов клиент сообщил, что музыку на сайте больше не генерируют: пользователи делают треки во внешних нейросетях, а сервис на время стал бесплатным.
Для документов здесь важно одно: уходят ли данные во внешние нейросети. Мы спросили, есть ли интеграция, передаётся ли что-то при переходе и есть ли в ссылке идентификатор пользователя. Оказалось, это обычная ссылка, а трек пользователь загружает сам. В инструкции мы всё равно закрепили, что любая интеграция появляется только после юридической проверки. Переписывать документы под бесплатную модель отсоветовали: при первом же платном тарифе их пришлось бы переделывать снова, а может, и менять уведомление.
Тогда же клиент спросил, нельзя ли объединить документы и обязательно ли ставить все галочки. Объединять согласия нельзя, общая галочка как раз была одной из проблем аудита. Но галочек меньше, чем кажется, потому что большинство согласий пользователь увидит только в той ситуации, к которой они относятся.
| Действие пользователя | Что он видит в интерфейсе |
|---|---|
| Первый заход на сайт | Cookie-баннер с равноценными кнопками «Принять» и «Отказаться», аналитика только после согласия |
| Регистрация | Пустые галочки «Мне исполнилось 18 лет» и принятие пользовательского соглашения |
| Оплата тарифа | Цена и условия до оплаты, принятие оферты, отдельная галочка на автопродление |
| Участие в чужом релизе | Согласие на распространение своих данных в этом релизе и, если нужно, на изображение |
| Получение роялти | Паспорт и реквизиты только в отдельной форме выплат |
| Любая форма с данными | Ссылка на политику рядом с формой, без отдельной галочки |
Уведомление мы заполнили черновиком прямо в личном кабинете Роскомнадзора. Клиенту осталось внести паспортные данные, подписать и отправить, пересылать паспорт нам не понадобилось.
Что изменилось для сервиса
| Что требовало решения | Что сделали |
|---|---|
| Шаблонные документы без сведений об операторе | Политика, оферта и пользовательское соглашение под фактическую модель сервиса |
| Одна галочка на оферту и согласие, cookie-баннер без отказа | Отдельное действие для каждого документа и согласия, баннер с кнопкой отказа |
| Дистрибьютор запрещал музыку от ИИ и принимал релизы за рубежом | Российский дистрибьютор, который сам принимает и публикует релизы |
| Соисполнителя мог вписать любой пользователь | Фиты только между карточками сервиса и согласия по каждому релизу |
| Уведомление в Роскомнадзор не подано | Черновик в личном кабинете, клиенту осталось подписать и отправить |
Самое ценное случилось до документов. Если бы мы проверили только сайт, сервис получил бы аккуратную политику и всё равно рисковал потерять аккаунт у дистрибьютора вместе с деньгами артистов.
Когда такой разбор нужен вашему сервису
Похожая проверка пригодится, если сервис передаёт пользовательский контент партнёру, работает с контентом от нейросетей или разрешает одному пользователю указывать данные другого. Начать стоит с одного релиза, заказа или заявки: проследите, кто получает данные после вашего сайта, и откройте условия этого получателя.
Материал описывает отдельный проект. Правовая оценка зависит от фактических процессов конкретного бизнеса.
Источники
- Статья 3 Федерального закона № 152-ФЗ: основные понятияПроверено: 12.10.2026
- Статья 6 Федерального закона № 152-ФЗ: условия обработки персональных данныхПроверено: 12.10.2026
- Статья 10.1 Федерального закона № 152-ФЗ: данные, разрешённые для распространенияПроверено: 12.10.2026
- Статья 12 Федерального закона № 152-ФЗ: трансграничная передача персональных данныхПроверено: 12.10.2026
- Статья 18 Федерального закона № 152-ФЗ: обязанности оператора при сборе персональных данныхПроверено: 12.10.2026
- Статья 152.1 Гражданского кодекса РФ: охрана изображения гражданинаПроверено: 12.10.2026