🍏Как Apple чуть не потеряла своё яблоко. И при чём тут The Beatles
Большинство людей думают: конфликт товарных знаков — это когда кто-то нагло копирует логотип. На самом деле самые интересные споры возникают там, где сходство неочевидно.
Предыстория
В 1968 году The Beatles основали лейбл Apple Corps — с логотипом в виде яблока (зелёного, разрезанного пополам с обратной стороны).
В 1977 году Стив Джобс регистрирует Apple Computer — тоже с яблоком, только надкусанным.
Первый иск Apple Corps подала почти сразу (в 1978). Стороны урегулировали спор за $80 000: Apple Computer обязалась никогда не заходить в музыкальный бизнес.
Почему это важно для IT
В 1989 году Apple выпускает компьютер с MIDI-синтезатором и музыкальными функциями. Apple Corps снова идёт в суд. Новое соглашение уже за $26,5 млн.
Условие то же: Apple Computer держится подальше от музыки.
А потом наступил 2001 год и появился iTunes.
Третий раунд
Apple Corps подаёт третий иск — теперь уже за iTunes Store и iPod. Аргумент: продажа музыки = музыкальный бизнес = нарушение соглашения.
Apple (компьютерная) возражает: мы дистрибьютор, а не лейбл. Мы не производим музыку, мы только передаём данные.
Английский суд в 2006 году встал на сторону Apple Computer: передача музыкальных данных — это работа с данными, а не музыкальный бизнес в традиционном смысле.
Через год, в 2007, стороны наконец договорились окончательно: Apple Inc. выкупила все права на товарный знак «Apple» у Apple Corps за нераскрытую сумму (по слухам $500 млн) и лицензировала обратно лейблу право использовать его для своих нужд.
Что здесь поучительно для IT-бизнеса
⭕ Смежные классы МКТУ — не защита. Apple Corps регистрировалась в классе музыки, Apple Computer — в классе электроники, но когда рынки сошлись, знаки столкнулись.
⭕ Соглашение «не заходить в отрасль» работает ровно до тех пор, пока отрасли не размываются. В 1977 году никто не мог представить, что компьютерная компания будет продавать песни.
⭕ Смешение происходит не только визуально. Здесь оба знака — яблоко, но конфликт был про ассоциацию потребителя: если я вижу Apple и слышу музыку, чей это бренд?
⭕ Покупка прав дешевле долгих судов. 30 лет споров, три иска, сотни миллионов долларов и всё равно закончилось дорогостоящей сделкой.
Большинство людей думают: конфликт товарных знаков — это когда кто-то нагло копирует логотип. На самом деле самые интересные споры возникают там, где сходство неочевидно.
Предыстория
В 1968 году The Beatles основали лейбл Apple Corps — с логотипом в виде яблока (зелёного, разрезанного пополам с обратной стороны).
В 1977 году Стив Джобс регистрирует Apple Computer — тоже с яблоком, только надкусанным.
Первый иск Apple Corps подала почти сразу (в 1978). Стороны урегулировали спор за $80 000: Apple Computer обязалась никогда не заходить в музыкальный бизнес.
Почему это важно для IT
В 1989 году Apple выпускает компьютер с MIDI-синтезатором и музыкальными функциями. Apple Corps снова идёт в суд. Новое соглашение уже за $26,5 млн.
Условие то же: Apple Computer держится подальше от музыки.
А потом наступил 2001 год и появился iTunes.
Третий раунд
Apple Corps подаёт третий иск — теперь уже за iTunes Store и iPod. Аргумент: продажа музыки = музыкальный бизнес = нарушение соглашения.
Apple (компьютерная) возражает: мы дистрибьютор, а не лейбл. Мы не производим музыку, мы только передаём данные.
Английский суд в 2006 году встал на сторону Apple Computer: передача музыкальных данных — это работа с данными, а не музыкальный бизнес в традиционном смысле.
Через год, в 2007, стороны наконец договорились окончательно: Apple Inc. выкупила все права на товарный знак «Apple» у Apple Corps за нераскрытую сумму (по слухам $500 млн) и лицензировала обратно лейблу право использовать его для своих нужд.
Что здесь поучительно для IT-бизнеса
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Telegram-бот тоже собирает персональные данные
Многие относятся к Telegram-ботам проще, чем к сайту или приложению, но с точки зрения персональных данных бот часто работает как полноценная форма сбора данных.
Он может получать:
❤️ имя и username пользователя;
❤️ номер телефона;
❤️ email;
❤️ город;
❤️ заказ или заявку;
❤️ ответы на анкету;
❤️ историю переписки;
❤️ данные из CRM, если бот к ней подключён.
И риски обычно проявляются в том, что никто не описал, что именно он собирает и куда это дальше уходит.
Частые ошибки:
➡️ В боте собирают данные, но нет согласия на обработку персональных данных.
➡️ Пользователю не показывают политику обработки данных.
➡️ Данные уходят в CRM, Google Sheets, рассылочный сервис или подрядчику, но это нигде не отражено.
➡️ Доступ к заявкам есть у всех администраторов подряд.
➡️ Бот хранит переписку и заявки дольше, чем это реально нужно.
➡️ Через бота запускают рекламные рассылки без отдельного согласия.
➡️ Никто не понимает, кто оператор персональных данных: владелец бизнеса, разработчик, маркетолог или подрядчик.
Главная мысль: если бот помогает бизнесу собирать заявки, записывать клиентов, проводить опросы, выдавать доступ к продукту или делать рассылки — это уже не часть системы обработки персональных данных.
Что стоит проверить перед запуском:
⭕ какие данные бот собирает;
⭕ зачем они нужны;
⭕ где они хранятся;
⭕ кто имеет к ним доступ;
⭕ куда они передаются;
⭕ есть ли согласие, политика и корректные тексты в интерфейсе;
⭕ не используется ли бот для рекламы без отдельного согласия.
Telegram-бот может быть удобным инструментом, но юридически он не становится «невидимым» только потому, что находится внутри мессенджера.
Если бы каждый раз при записи куда-либо через бот или сайт, я предлагала свои юридические услуги, я бы озолотилась)))
Многие относятся к Telegram-ботам проще, чем к сайту или приложению, но с точки зрения персональных данных бот часто работает как полноценная форма сбора данных.
Он может получать:
И риски обычно проявляются в том, что никто не описал, что именно он собирает и куда это дальше уходит.
Частые ошибки:
Главная мысль: если бот помогает бизнесу собирать заявки, записывать клиентов, проводить опросы, выдавать доступ к продукту или делать рассылки — это уже не часть системы обработки персональных данных.
Что стоит проверить перед запуском:
Telegram-бот может быть удобным инструментом, но юридически он не становится «невидимым» только потому, что находится внутри мессенджера.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Рекламные рассылки без согласия: в чём риск для бизнеса
Одна из частых ошибок бизнеса в рассылках — путать три разные вещи:
▶ человек оставил контакт для заявки;
▶ человек согласился на обработку персональных данных;
▶ человек согласился получать рекламу.
Это не одно и то же.
Если клиент оставил номер, чтобы ему перезвонили по заказу, это ещё не значит, что через неделю ему можно отправить SMS: «Только сегодня скидка 20%».
Если он указал email для получения чека или доступа к курсу, это не значит, что он автоматически подписался на акции, подборки и спец. предложения.
По закону рекламные сообщения по email, SMS, телефону, мессенджерам и другим каналам связи можно направлять только при предварительном согласии адресата. И если возникнет спор, доказывать наличие такого согласия придётся бизнесу.
Где обычно появляются риски:
❤️ На сайте стоит один чекбокс «согласен с политикой», а потом человеку отправляют рекламу.
❤️ Чекбокс на рассылку уже заранее проставлен.
❤️ В форме написано «информационные сообщения», а по факту приходят акции и промокоды.
❤️ Согласие спрятано где-то внутри пользовательского соглашения.
❤️ Бизнес не может доказать, кто, когда и на что именно согласился.
❤️ Нет понятного способа отписаться.
❤️ Рассылку делает подрядчик, но документы и доступ к базе не оформлены.
Что должно быть в согласии на рекламную рассылку:
⭕ кто будет отправлять рекламу;
⭕ по каким каналам: email, SMS, звонки, мессенджеры, push;
⭕ на какой контакт пользователь даёт согласие;
⭕ какие сообщения он будет получать: акции, предложения, новости продуктов;
⭕ как можно отказаться от рассылки;
⭕ дата, время, источник и версия текста согласия, чтобы потом можно было это подтвердить.
Главное правило простое:
➖ контакт для услуги — используем для услуги;
➖ хотим отправлять рекламу — получаем отдельное понятное согласие;
➖ человек отказался — прекращаем рассылку.
Рассылка может быть отличным маркетинговым инструментом, но только если бизнес соблюдает закон: согласие на обработку персональных данных и согласие на рекламу — это не одна и та же галочка.
Одна из частых ошибок бизнеса в рассылках — путать три разные вещи:
Это не одно и то же.
Если клиент оставил номер, чтобы ему перезвонили по заказу, это ещё не значит, что через неделю ему можно отправить SMS: «Только сегодня скидка 20%».
Если он указал email для получения чека или доступа к курсу, это не значит, что он автоматически подписался на акции, подборки и спец. предложения.
По закону рекламные сообщения по email, SMS, телефону, мессенджерам и другим каналам связи можно направлять только при предварительном согласии адресата. И если возникнет спор, доказывать наличие такого согласия придётся бизнесу.
Где обычно появляются риски:
Что должно быть в согласии на рекламную рассылку:
Главное правило простое:
Рассылка может быть отличным маркетинговым инструментом, но только если бизнес соблюдает закон: согласие на обработку персональных данных и согласие на рекламу — это не одна и та же галочка.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Скидка за рекламную рассылку, законно ли это с точки зрения Верховного Суда?
Свежая позиция ВС РФ по делу № А07-5689/2025:бизнес может предложить скидку в обмен на согласие получать рекламную рассылку.
Суть дела была такая: на сайте Sela проходила акция с «колесом фортуны». Чтобы разыграть скидку, пользователь вводил email и ставил галочку о согласии на получение рекламной рассылки. Без этой галочки участие в акции было невозможно.
УФАС и три судебные инстанции решили, что такое согласие нельзя считать добровольным: человек хотел получить скидку, а не рекламу.
Верховный Суд с этим не согласился и указал: закон не запрещает ситуацию, когда пользователь даёт согласие на рекламу в обмен на выгоду, например, скидку. Главное, чтобы у человека сохранялась возможность купить товар на общих условиях, без участия в акции и без согласия на рассылку.
То есть логика такая: хотите обычную покупку — покупаете без рассылки; хотите индивидуальную скидку — можете согласиться на рекламную рассылку.
Это не означает, что теперь можно просто прятать согласие где угодно. В этом деле для суда было важно, что:
🤍 согласие было дано до отправки рекламы;
🤍 пользователь сам поставил галочку;
🤍 речь шла именно о рекламной рассылке;
🤍 формулировка не была спрятана только в политике конфиденциальности;
🤍 условия были размещены рядом с механикой акции;
🤍 от рассылки можно было отказаться;
🤍 у бизнеса была возможность подтвердить факт согласия.
❤️ Практический вывод для бизнеса: механика «скидка за подписку» допустима, но интерфейс и текст согласия должны быть аккуратными.
Не стоит использовать заранее проставленные галочки, размытые формулировки вроде «информационные сообщения» или прятать согласие на рекламу внутри общих документов.
❤️ И главный вывод: добровольность согласия не исчезает только потому, что пользователь получает за него бонус. Однако бизнес должен доказать, что человек понимал, на что именно соглашается.
Свежая позиция ВС РФ по делу № А07-5689/2025:
Суть дела была такая: на сайте Sela проходила акция с «колесом фортуны». Чтобы разыграть скидку, пользователь вводил email и ставил галочку о согласии на получение рекламной рассылки. Без этой галочки участие в акции было невозможно.
УФАС и три судебные инстанции решили, что такое согласие нельзя считать добровольным: человек хотел получить скидку, а не рекламу.
Верховный Суд с этим не согласился и указал: закон не запрещает ситуацию, когда пользователь даёт согласие на рекламу в обмен на выгоду, например, скидку. Главное, чтобы у человека сохранялась возможность купить товар на общих условиях, без участия в акции и без согласия на рассылку.
То есть логика такая: хотите обычную покупку — покупаете без рассылки; хотите индивидуальную скидку — можете согласиться на рекламную рассылку.
Это не означает, что теперь можно просто прятать согласие где угодно. В этом деле для суда было важно, что:
Не стоит использовать заранее проставленные галочки, размытые формулировки вроде «информационные сообщения» или прятать согласие на рекламу внутри общих документов.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥1
Чужой товарный знак в URL: всегда ли нарушение?
Неделя постов будет посвящена свежим актам ВС РФ и КС РФ по тематике моего канала.
Сегодня поговорим об интересном споре про товарный знак в адресной строке сайта.
Ситуация была такая: компания раньше использовала товарный знак по лицензии. Потом договор закончился, знак из видимого контента сайта убрали, но он остался в URL отдельных страниц.
Правообладатель посчитал это нарушением и потребовал компенсацию. Нижестоящие суды поддержали его: раз товарный знак остался на сайте, значит было использование.
Верховный Суд подошёл не так формально.
ВС РФ указал: само по себе упоминание товарного знака в URL ещё не означает автоматического нарушения исключительного права.
Нужно смотреть, для чего фактически использовалось обозначение:
▶ помогало ли оно продвигать товары или услуги ответчика;
▶ создавало ли у потребителя впечатление связи с правообладателем;
▶ были ли на спорных страницах предложения товаров или услуг со спорным обозначением;
▶ мог ли пользователь найти эти страницы по товарному знаку;
▶ было ли обозначение частью видимого контента сайта или осталось техническим следом после прежнего законного использования.
То есть ключевой вопрос: «Используется ли товарный знак в URL как средство индивидуализации и есть ли риск смешения?»
Это важная позиция для бизнеса, который меняет бренд, прекращает лицензию, закрывает старые товарные линейки или обновляет сайт.
Конечно, мы не делаем вывод, что теперь можно спокойно оставлять чужие знаки в URL.
❌ Вывод более аккуратный: не каждое техническое упоминание товарного знака является нарушением. Однако если URL помогает перетягивать трафик, продвигать свои товары или создавать ассоциацию с чужим брендом, риск остаётся.
❌ Практический совет простой: после прекращения лицензии, ребрендинга или смены партнёра стоит проверять не только тексты и картинки на сайте, но и URL, метатеги, старые страницы, редиректы и поисковую выдачу. Потому что иногда спор начинается не с логотипа на главной странице, а с маленького слова в адресной строке.
Источник: Определение ВС РФ от 03.07.2025 № 304-ЭС25-1782 по делу № А45-25305/2023.
Неделя постов будет посвящена свежим актам ВС РФ и КС РФ по тематике моего канала.
Сегодня поговорим об интересном споре про товарный знак в адресной строке сайта.
Ситуация была такая: компания раньше использовала товарный знак по лицензии. Потом договор закончился, знак из видимого контента сайта убрали, но он остался в URL отдельных страниц.
Правообладатель посчитал это нарушением и потребовал компенсацию. Нижестоящие суды поддержали его: раз товарный знак остался на сайте, значит было использование.
Верховный Суд подошёл не так формально.
ВС РФ указал: само по себе упоминание товарного знака в URL ещё не означает автоматического нарушения исключительного права.
Нужно смотреть, для чего фактически использовалось обозначение:
То есть ключевой вопрос: «Используется ли товарный знак в URL как средство индивидуализации и есть ли риск смешения?»
Это важная позиция для бизнеса, который меняет бренд, прекращает лицензию, закрывает старые товарные линейки или обновляет сайт.
Конечно, мы не делаем вывод, что теперь можно спокойно оставлять чужие знаки в URL.
Источник: Определение ВС РФ от 03.07.2025 № 304-ЭС25-1782 по делу № А45-25305/2023.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Иностранный бренд из «недружественной» страны: можно ли защищать товарный знак в РФ?
ВС РФ разобрал важный спор о защите иностранного товарного знака.
Ситуация была такая: правообладатель из Германии владел товарным знаком COSMO. Российский истец (сначала лицензиат, потом цессионарий) требовал компенсацию с продавца на Ozon, который, по его мнению, продавал товар с обозначением COSMA, сходным до степени смешения.
Первая инстанция взыскала компенсацию, но апелляция и Суд по интеллектуальным правам отказали: правообладатель связан с Германией, а Германия входит в перечень «недружественных» государств. Суды также увидели в схеме отношений признаки обхода специального порядка расчетов по Указу № 322.
Верховный Суд с таким подходом не согласился и напомнил: в России гарантируется равная защита исключительных прав независимо от гражданства, места регистрации или места ведения деятельности правообладателя.
То есть сам по себе факт, что бренд принадлежит компании из «недружественной» юрисдикции, не означает, что его товарный знак больше нельзя защищать в России.
Что должны были проверить суды:
➖ действительно ли применяется специальный порядок расчетов по Указу № 322;
➖ подпадает ли правообладатель под исключения из этого порядка;
➖ продолжает ли компания работать на российском рынке;
➖ поставляет ли оригинальную продукцию в РФ;
исполняет ли свои договоры с российскими контрагентами;
➖ есть ли реальный обход закона, а не просто подозрение из-за иностранной юрисдикции.
Практический вывод: иностранный товарный знак не становится свободным только потому, что правообладатель зарегистрирован в недружественной стране, но для правообладателей и лицензиатов теперь особенно важно собирать доказательства добросовестности: действующие договоры, поставки оригинальной продукции, исполнение обязательств, присутствие на российском рынке.
И важная оговорка: ВС РФ не поставил точку в споре по существу, а отправил дело на новое рассмотрение, но ориентир понятен: отказать в защите товарного знака только из-за иностранной юрисдикции нельзя.
Источник: Определение ВС РФ от 16.06.2026 № 305-ЭС26-1899 по делу № А40-218859/2024.
ВС РФ разобрал важный спор о защите иностранного товарного знака.
Ситуация была такая: правообладатель из Германии владел товарным знаком COSMO. Российский истец (сначала лицензиат, потом цессионарий) требовал компенсацию с продавца на Ozon, который, по его мнению, продавал товар с обозначением COSMA, сходным до степени смешения.
Первая инстанция взыскала компенсацию, но апелляция и Суд по интеллектуальным правам отказали: правообладатель связан с Германией, а Германия входит в перечень «недружественных» государств. Суды также увидели в схеме отношений признаки обхода специального порядка расчетов по Указу № 322.
Верховный Суд с таким подходом не согласился и напомнил: в России гарантируется равная защита исключительных прав независимо от гражданства, места регистрации или места ведения деятельности правообладателя.
То есть сам по себе факт, что бренд принадлежит компании из «недружественной» юрисдикции, не означает, что его товарный знак больше нельзя защищать в России.
Что должны были проверить суды:
исполняет ли свои договоры с российскими контрагентами;
Практический вывод: иностранный товарный знак не становится свободным только потому, что правообладатель зарегистрирован в недружественной стране, но для правообладателей и лицензиатов теперь особенно важно собирать доказательства добросовестности: действующие договоры, поставки оригинальной продукции, исполнение обязательств, присутствие на российском рынке.
И важная оговорка: ВС РФ не поставил точку в споре по существу, а отправил дело на новое рассмотрение, но ориентир понятен: отказать в защите товарного знака только из-за иностранной юрисдикции нельзя.
Источник: Определение ВС РФ от 16.06.2026 № 305-ЭС26-1899 по делу № А40-218859/2024.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥2
Маркетплейс не всегда может спрятаться за статус информационного посредника
КС РФ вынес важное постановление по делу «Мир Хобби» об ответственности маркетплейсов за нарушения интеллектуальных прав продавцами.
Суть спора: правообладатель обнаружил на маркетплейсе контрафактные копии настольной игры. В игре использовались охраняемые объекты: иллюстрации и дизайн коробки.
Правообладатель обратился к владельцу площадки, но спорные товары, по его позиции, продолжали продаваться. В суде маркетплейс ссылался на то, что он не продавец, а информационный посредник: только предоставляет площадку для размещения товаров.
Раньше такая логика часто работала:
«товар разместил продавец, значит с него и спрашивайте».
КС РФ высказал позицию: сам по себе маркетплейс действительно может быть информационным посредником. То, что он дополнительно помогает с оплатой, доставкой, хранением или выдачей товара, автоматически не лишает его этого статуса.
Однако если правообладатель направил обоснованную претензию, маркетплейс не может просто переслать её продавцу и ждать, чем всё закончится. Он должен принять необходимые меры: как правило, приостановить размещение информации о спорном товаре на время, пока правообладатель обращается в суд или получает обеспечительные меры.
Для маркетплейса особенно рискованны ситуации, когда:
➖ нарушение выглядит очевидным;
➖ товар сильно дешевле оригинала;
➖ используется обозначение, похожее на известный бренд;
➖ продавец уже раньше нарушал права на те же объекты;
➖ площадка сама продвигает или рекламирует конкретный спорный товар;
➖ маркетплейс игнорирует судебный запрос о данных продавца, объемах продаж или поставках.
При этом КС сохранил баланс: маркетплейс не обязан заранее проверять каждый товар на все возможные нарушения интеллектуальных прав. И если претензия правообладателя окажется необоснованной, продавец или маркетплейс смогут требовать убытки.
➡️ Главный вывод: маркетплейс больше не может занимать полностью пассивную позицию.
Если площадка получила нормальную претензию от правообладателя, ей нужно не просто «передать обращение продавцу», а показать реальную реакцию: проверить документы, запросить объяснения, временно ограничить спорную карточку, сохранить данные и не допустить повторного нарушения тем же продавцом.
Для правообладателей это тоже важный сигнал: претензии на маркетплейсы должны быть не эмоциональными, а доказательными. Нужно сразу показывать права на объект, ссылку на конкретную карточку и признаки нарушения.
Дело «Мир Хобби» должно быть пересмотрено с учётом позиции КС РФ.
Источник: Постановление КС РФ от 16.06.2026 № 39-П по делу ООО «Мир Хобби».
КС РФ вынес важное постановление по делу «Мир Хобби» об ответственности маркетплейсов за нарушения интеллектуальных прав продавцами.
Суть спора: правообладатель обнаружил на маркетплейсе контрафактные копии настольной игры. В игре использовались охраняемые объекты: иллюстрации и дизайн коробки.
Правообладатель обратился к владельцу площадки, но спорные товары, по его позиции, продолжали продаваться. В суде маркетплейс ссылался на то, что он не продавец, а информационный посредник: только предоставляет площадку для размещения товаров.
Раньше такая логика часто работала:
«товар разместил продавец, значит с него и спрашивайте».
КС РФ высказал позицию: сам по себе маркетплейс действительно может быть информационным посредником. То, что он дополнительно помогает с оплатой, доставкой, хранением или выдачей товара, автоматически не лишает его этого статуса.
Однако если правообладатель направил обоснованную претензию, маркетплейс не может просто переслать её продавцу и ждать, чем всё закончится. Он должен принять необходимые меры: как правило, приостановить размещение информации о спорном товаре на время, пока правообладатель обращается в суд или получает обеспечительные меры.
Для маркетплейса особенно рискованны ситуации, когда:
При этом КС сохранил баланс: маркетплейс не обязан заранее проверять каждый товар на все возможные нарушения интеллектуальных прав. И если претензия правообладателя окажется необоснованной, продавец или маркетплейс смогут требовать убытки.
Если площадка получила нормальную претензию от правообладателя, ей нужно не просто «передать обращение продавцу», а показать реальную реакцию: проверить документы, запросить объяснения, временно ограничить спорную карточку, сохранить данные и не допустить повторного нарушения тем же продавцом.
Для правообладателей это тоже важный сигнал: претензии на маркетплейсы должны быть не эмоциональными, а доказательными. Нужно сразу показывать права на объект, ссылку на конкретную карточку и признаки нарушения.
Дело «Мир Хобби» должно быть пересмотрено с учётом позиции КС РФ.
Источник: Постановление КС РФ от 16.06.2026 № 39-П по делу ООО «Мир Хобби».
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
ИИ против авторского права: можно ли обучаться на чужом творчестве?
В России обсуждают законопроект об искусственном интеллекте и один из самых спорных пунктов касается авторских прав.
Сейчас в российском праве по общему правилу у автора или правообладателя есть исключительное право на произведение. Если кто-то хочет использовать книгу, музыку, изображение, фотографию, текст или ПО, обычно нужно согласие правообладателя, если нет специального исключения в законе.
По новому законопроекту использование информации из произведений и объектов смежных прав для обучения суверенных и национальных больших моделей ИИ не будет считаться нарушением при соблюдении условий: например, если у разработчика есть правомерно полученный экземпляр произведения или объект был доведён до всеобщего сведения и доступен для анализа без технических ограничений.
Если проще: контент потенциально смогут использовать для обучения ИИ без отдельного согласия автора.
Для разработчиков это звучит логично: большой модели нужны большие данные. Для авторов это звучит иначе: «моё произведение взяли, на нём обучили коммерческую технологию, а меня даже не спросили».
И это не только российский спор.
В США сейчас нет единого ответа «можно» или «нельзя». Там всё крутится вокруг доктрины fair use. AI-компании придерживаются позиции: обучение модели - это трансформативное использование. Правообладатели считают: нет, это массовое копирование чужого труда для коммерческого продукта.
Именно вокруг этого идут громкие процессы, включая спор The New York Times против OpenAI и Microsoft. Бюро авторского права США в своём отчёте сформулировало осторожно: некоторые случаи обучения ИИ могут быть fair use, а некоторые - нет. Всё зависит от источника данных, цели использования, коммерческого эффекта и того, конкурирует ли результат с оригинальными произведениями.
В Европе подход более формализованный. Там есть режим text and data mining: анализ текстов и данных возможен, но правообладатель может заранее запретить такое использование через opt-out.
AI Act добавляет обязанность для провайдеров больших моделей соблюдать авторское право и раскрывать достаточно подробную информацию о контенте, использованном для обучения.
Однако и в Европе спор не закрыт. Европарламент в марте 2026 года отдельно говорил о прозрачности, лицензировании, справедливом вознаграждении и праве авторов не допускать свои произведения к обучению ИИ.
Похожая дискуссия идёт и в Великобритании. Там идея разрешить обучение ИИ на контенте по модели opt-out вызвала жёсткую реакцию творческой индустрии. Против выступали, в том числе, Пол Маккартни, Элтон Джон, Dua Lipa, Coldplay и другие представители индустрии творчества.
В России тоже уже появилась публичная реакция: Илья Резник обратился с предложением закрепить выплату вознаграждения авторам, чьи произведения используются для обучения ИИ.
ИИ в России, конечно, нужен. Вопрос в том, можно ли развивать ИИ так, чтобы человеческое творчество не превратилось в бесплатное сырьё для технологических компаний?
Пока речь именно о законопроекте, а не о действующей норме, но дискуссия уже показывает главное: авторское право всё чаще будет спорить не с пиратскими сайтами, а с обучающими датасетами.
В России обсуждают законопроект об искусственном интеллекте и один из самых спорных пунктов касается авторских прав.
Сейчас в российском праве по общему правилу у автора или правообладателя есть исключительное право на произведение. Если кто-то хочет использовать книгу, музыку, изображение, фотографию, текст или ПО, обычно нужно согласие правообладателя, если нет специального исключения в законе.
По новому законопроекту использование информации из произведений и объектов смежных прав для обучения суверенных и национальных больших моделей ИИ не будет считаться нарушением при соблюдении условий: например, если у разработчика есть правомерно полученный экземпляр произведения или объект был доведён до всеобщего сведения и доступен для анализа без технических ограничений.
Если проще: контент потенциально смогут использовать для обучения ИИ без отдельного согласия автора.
Для разработчиков это звучит логично: большой модели нужны большие данные. Для авторов это звучит иначе: «моё произведение взяли, на нём обучили коммерческую технологию, а меня даже не спросили».
И это не только российский спор.
В США сейчас нет единого ответа «можно» или «нельзя». Там всё крутится вокруг доктрины fair use. AI-компании придерживаются позиции: обучение модели - это трансформативное использование. Правообладатели считают: нет, это массовое копирование чужого труда для коммерческого продукта.
Именно вокруг этого идут громкие процессы, включая спор The New York Times против OpenAI и Microsoft. Бюро авторского права США в своём отчёте сформулировало осторожно: некоторые случаи обучения ИИ могут быть fair use, а некоторые - нет. Всё зависит от источника данных, цели использования, коммерческого эффекта и того, конкурирует ли результат с оригинальными произведениями.
В Европе подход более формализованный. Там есть режим text and data mining: анализ текстов и данных возможен, но правообладатель может заранее запретить такое использование через opt-out.
AI Act добавляет обязанность для провайдеров больших моделей соблюдать авторское право и раскрывать достаточно подробную информацию о контенте, использованном для обучения.
Однако и в Европе спор не закрыт. Европарламент в марте 2026 года отдельно говорил о прозрачности, лицензировании, справедливом вознаграждении и праве авторов не допускать свои произведения к обучению ИИ.
Похожая дискуссия идёт и в Великобритании. Там идея разрешить обучение ИИ на контенте по модели opt-out вызвала жёсткую реакцию творческой индустрии. Против выступали, в том числе, Пол Маккартни, Элтон Джон, Dua Lipa, Coldplay и другие представители индустрии творчества.
В России тоже уже появилась публичная реакция: Илья Резник обратился с предложением закрепить выплату вознаграждения авторам, чьи произведения используются для обучения ИИ.
ИИ в России, конечно, нужен. Вопрос в том, можно ли развивать ИИ так, чтобы человеческое творчество не превратилось в бесплатное сырьё для технологических компаний?
Пока речь именно о законопроекте, а не о действующей норме, но дискуссия уже показывает главное: авторское право всё чаще будет спорить не с пиратскими сайтами, а с обучающими датасетами.
🔥3
Мое мнение: ИИ vs авторские права
Если говорить о том, какая модель мне кажется более справедливой для России, я бы не поддерживала вариант «можно всё, что лежит в открытом доступе».
Открытый интернет - это не общественное достояние. Если автор выложил текст, фотографию, музыку или иллюстрацию в сеть, это не значит, что он согласился бесплатно передать свой труд для обучения коммерческих ИИ-моделей.
Мне ближе смешанная модель.
Для науки, исследований, архивов, образовательных и некоммерческих задач можно обсуждать специальные исключения. Там действительно важен доступ к данным, и не всегда разумно требовать индивидуальный договор на каждое произведение.
Однако если речь идёт о больших моделях, которые потом используются как коммерческий продукт, мне кажется справедливым вводить не свободное использование, а систему лицензирования и вознаграждения.
Это не обязательно должен быть договор с каждым автором вручную. Можно обсуждать коллективные лицензии, реестры правообладателей, отраслевые соглашения, компенсационные фонды, прозрачные тарифы. При этом принцип должен быть понятный: если технология получает ценность из человеческого творчества, автор не должен исчезать из этой цепочки.
Отдельно для России я бы закрепила три вещи:
🌸 запрет использовать пиратские базы и контент, полученный с обходом технических ограничений;
🌸 обязанность раскрывать хотя бы категории и источники обучающих данных;
🌸 право автора запретить использование своих произведений для обучения ИИ понятным и реально работающим способом.
Поэтому мне ближе не чистый opt-out (как в Европе), где бремя контроля фактически перекладывается на автора, а модель: для коммерческого обучения - лицензия или вознаграждение; для общественно полезных некоммерческих целей - узкие исключения; для всех случаев - прозрачность источников.
Источники для отсылок: законопроект № 1271570-8, ст. 10; ст. 1229 и 1270 ГК РФ; Directive (EU) 2019/790, ст. 3-4; EU AI Act, ст. 53; U.S. Copyright Office Report on Generative AI Training, May 2025; позиция Европарламента от 10.03.2026; GOV.UK Report on Copyright and AI от 18.03.2026; публикация ТАСС об обращении Ильи Резника.
Если говорить о том, какая модель мне кажется более справедливой для России, я бы не поддерживала вариант «можно всё, что лежит в открытом доступе».
Открытый интернет - это не общественное достояние. Если автор выложил текст, фотографию, музыку или иллюстрацию в сеть, это не значит, что он согласился бесплатно передать свой труд для обучения коммерческих ИИ-моделей.
Мне ближе смешанная модель.
Для науки, исследований, архивов, образовательных и некоммерческих задач можно обсуждать специальные исключения. Там действительно важен доступ к данным, и не всегда разумно требовать индивидуальный договор на каждое произведение.
Однако если речь идёт о больших моделях, которые потом используются как коммерческий продукт, мне кажется справедливым вводить не свободное использование, а систему лицензирования и вознаграждения.
Это не обязательно должен быть договор с каждым автором вручную. Можно обсуждать коллективные лицензии, реестры правообладателей, отраслевые соглашения, компенсационные фонды, прозрачные тарифы. При этом принцип должен быть понятный: если технология получает ценность из человеческого творчества, автор не должен исчезать из этой цепочки.
Отдельно для России я бы закрепила три вещи:
Поэтому мне ближе не чистый opt-out (как в Европе), где бремя контроля фактически перекладывается на автора, а модель: для коммерческого обучения - лицензия или вознаграждение; для общественно полезных некоммерческих целей - узкие исключения; для всех случаев - прозрачность источников.
Источники для отсылок: законопроект № 1271570-8, ст. 10; ст. 1229 и 1270 ГК РФ; Directive (EU) 2019/790, ст. 3-4; EU AI Act, ст. 53; U.S. Copyright Office Report on Generative AI Training, May 2025; позиция Европарламента от 10.03.2026; GOV.UK Report on Copyright and AI от 18.03.2026; публикация ТАСС об обращении Ильи Резника.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Невозврат аванса: когда это законно, а когда нет
Аванс - это не подарок и не «компенсация за потраченное время».
Если подрядчик, исполнитель или продавец получил предоплату, но не выполнил встречное обязательство, после расторжения договора он не может просто оставить деньги себе.
В общем виде логика такая: нет работы, услуги или товара - нет основания удерживать аванс. Именно это часто квалифицируется как неосновательное обогащение: деньги получены, а встречного предоставления нет.
Однако есть исключения. Аванс могут не вернуть полностью или частично, если:
❤️ Работы реально выполнены, услуги оказаны, товар передан
Тогда возвращается не весь аванс, а только неотработанная часть.
❤️ Заказчик сам отказался от договора, когда подрядчик уже начал работу
По подряду заказчик может отказаться от договора, но должен оплатить фактически выполненную часть и в отдельных случаях возместить убытки подрядчика.
❤️ У исполнителя были доказанные расходы
Например, он закупил материалы, привлёк специалистов, понёс затраты именно под этот договор, но расходы нужно подтверждать, а не просто писать: «мы уже начали подготовку».
❤️ Есть встречный долг заказчика
Например, заказчик должен оплатить другую часть работ, неустойку или убытки. Тогда возможен зачёт, если для него есть правовое основание.
❤️ Это был не аванс, а задаток или обеспечительный платёж
Слова в договоре имеют значение. Если платёж оформлен как задаток, при нарушении со стороны давшего задаток он может остаться у другой стороны, но просто назвать аванс «невозвратным» недостаточно.
❤️ Стороны отдельно договорились о последствиях расторжения
Например, в соглашении о расторжении прямо указали, какая сумма возвращается, а какая остаётся как компенсация, но такое условие тоже должно быть добросовестным и объяснимым (за фактически выполненную работу, понесённые расходы, убытки). Формула «аванс не возвращается ни при каких условиях», особенно если исполнитель ничего не сделал, не сработает в суде. Особенно, в ситуации, когда аванс заплатил потребитель❗
⭐ Главный вывод: невозврат неотработанного аванса без встречного предоставления и без доказанных оснований - незаконен.
Для бизнеса практический совет простой:
если хотите удержать аванс - готовьте доказательства, за что именно он удерживается: акты, переписку, расчёты, расходы, убытки, заявление о зачёте. Если хотите вернуть аванс - фиксируйте отказ от договора, требование о возврате денег и отсутствие результата со стороны контрагента.
ВС РФ в определении от 04.08.2022 № 306-ЭС22-8161 по делу № А57-10033/2021 как раз напомнил: если работы не выполнены, а договор расторгнут, неотработанный аванс подлежит возврату.
Аванс - это не подарок и не «компенсация за потраченное время».
Если подрядчик, исполнитель или продавец получил предоплату, но не выполнил встречное обязательство, после расторжения договора он не может просто оставить деньги себе.
В общем виде логика такая: нет работы, услуги или товара - нет основания удерживать аванс. Именно это часто квалифицируется как неосновательное обогащение: деньги получены, а встречного предоставления нет.
Однако есть исключения. Аванс могут не вернуть полностью или частично, если:
Тогда возвращается не весь аванс, а только неотработанная часть.
По подряду заказчик может отказаться от договора, но должен оплатить фактически выполненную часть и в отдельных случаях возместить убытки подрядчика.
Например, он закупил материалы, привлёк специалистов, понёс затраты именно под этот договор, но расходы нужно подтверждать, а не просто писать: «мы уже начали подготовку».
Например, заказчик должен оплатить другую часть работ, неустойку или убытки. Тогда возможен зачёт, если для него есть правовое основание.
Слова в договоре имеют значение. Если платёж оформлен как задаток, при нарушении со стороны давшего задаток он может остаться у другой стороны, но просто назвать аванс «невозвратным» недостаточно.
Например, в соглашении о расторжении прямо указали, какая сумма возвращается, а какая остаётся как компенсация, но такое условие тоже должно быть добросовестным и объяснимым (за фактически выполненную работу, понесённые расходы, убытки). Формула «аванс не возвращается ни при каких условиях», особенно если исполнитель ничего не сделал, не сработает в суде. Особенно, в ситуации, когда аванс заплатил потребитель
Для бизнеса практический совет простой:
если хотите удержать аванс - готовьте доказательства, за что именно он удерживается: акты, переписку, расчёты, расходы, убытки, заявление о зачёте. Если хотите вернуть аванс - фиксируйте отказ от договора, требование о возврате денег и отсутствие результата со стороны контрагента.
ВС РФ в определении от 04.08.2022 № 306-ЭС22-8161 по делу № А57-10033/2021 как раз напомнил: если работы не выполнены, а договор расторгнут, неотработанный аванс подлежит возврату.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
Возвраты за онлайн-курсы и консультации: что можно прописать заранее
Фраза «деньги не возвращаются» в оферте не работает как волшебная защита.
Если клиент - потребитель, он вправе отказаться от услуги в любое время. Исполнитель при этом может удержать не всё, а только стоимость уже оказанных услуг и подтверждённые фактические расходы.
Хорошая оферта всё равно очень важна. Она помогает заранее объяснить, за что именно платит клиент и как считается возврат.
Что стоит прописать:
📎 Из чего состоит продукт
Не просто «онлайн-курс», а конкретно:
❤️ доступ к урокам;
❤️ вебинары;
❤️ записи;
❤️ домашние задания;
❤️ проверка куратором;
❤️ чат;
❤️ личные консультации;
❤️ сертификат;
❤️ материалы.
Чем понятнее состав услуги, тем проще потом считать, что уже оказано, а что нет.
📎 Этапы и стоимость каждого этапа
Например:
❤️ модуль 1 - 20% цены;
❤️ модуль 2 - 30%;
❤️ модуль 3 - 30%;
❤️ финальная консультация - 20%.
Тогда при возврате не нужно спорить на эмоциях. Видно, какая часть курса уже предоставлена, а какая ещё нет.
📎 Когда услуга считается оказанной
❤️ Для консультации это обычно момент её проведения.
❤️ Для курса сложнее. Можно прописать, что услуга по модулю считается оказанной после открытия доступа к материалам и наступления даты соответствующего этапа.
Важно: одна фраза «доступ открыт - услуга оказана полностью» не всегда спасает, если по факту клиент покупал не просто записи, а обучение с сопровождением, проверками и обратной связью.
📎 Порядок отмены и переноса консультаций
Например:
❤️ за сколько часов можно перенести встречу;
❤️ сколько переносов допускается;
❤️ что происходит при неявке клиента;
❤️ как фиксируется факт оказания консультации.
Условия должны быть разумными. Полное удержание оплаты за любую неявку без учёта обстоятельств может вызвать спор.
📎 Какие расходы исполнитель вправе удержать
Фактические расходы - это не абстрактное «мы потратили время команды».
Их нужно подтвердить: платёжками, договорами, актами, расходами, которые связаны именно с исполнением услуги для этого клиента.
📎 Как подать заявление на возврат
Стоит заранее прописать:
❤️ куда писать;
❤️ какие данные указать;
❤️ в какой срок рассматривается заявление;
❤️ как возвращаются деньги;
❤️ как считается сумма возврата.
📎 Что лучше не писать:
«Оплата не возвращается ни при каких обстоятельствах».
Для потребителей такая формулировка рискованна. Она не отменяет право отказаться от услуги.
Гораздо лучше честно прописать механику:
❤️ если услуга не началась - возвращается почти вся сумма;
❤️ если часть курса уже пройдена - удерживается стоимость оказанной части;
❤️ если были подтверждённые расходы - они вычитаются;
❤️ если услуга оказана полностью - возврат не производится.
Главный вывод: задача оферты - сделать возвраты понятными, предсказуемыми и доказуемыми.
Фраза «деньги не возвращаются» в оферте не работает как волшебная защита.
Если клиент - потребитель, он вправе отказаться от услуги в любое время. Исполнитель при этом может удержать не всё, а только стоимость уже оказанных услуг и подтверждённые фактические расходы.
Хорошая оферта всё равно очень важна. Она помогает заранее объяснить, за что именно платит клиент и как считается возврат.
Что стоит прописать:
Не просто «онлайн-курс», а конкретно:
Чем понятнее состав услуги, тем проще потом считать, что уже оказано, а что нет.
Например:
Тогда при возврате не нужно спорить на эмоциях. Видно, какая часть курса уже предоставлена, а какая ещё нет.
Важно: одна фраза «доступ открыт - услуга оказана полностью» не всегда спасает, если по факту клиент покупал не просто записи, а обучение с сопровождением, проверками и обратной связью.
Например:
Условия должны быть разумными. Полное удержание оплаты за любую неявку без учёта обстоятельств может вызвать спор.
Фактические расходы - это не абстрактное «мы потратили время команды».
Их нужно подтвердить: платёжками, договорами, актами, расходами, которые связаны именно с исполнением услуги для этого клиента.
Стоит заранее прописать:
«Оплата не возвращается ни при каких обстоятельствах».
Для потребителей такая формулировка рискованна. Она не отменяет право отказаться от услуги.
Гораздо лучше честно прописать механику:
Главный вывод: задача оферты - сделать возвраты понятными, предсказуемыми и доказуемыми.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Отзывы клиентов: когда нужно согласие, а когда достаточно обезличить
Отзыв клиента - отличный маркетинговый инструмент, но не каждый отзыв можно просто взять и выложить в Telegram, на сайт или в рекламу.
Главная ошибка думать, что если человек написал вам приятное сообщение, значит он автоматически согласился на публичную публикацию.
Когда лучше получить согласие
Согласие нужно, если вы хотите опубликовать отзыв с данными, по которым человека можно узнать:
🔹 имя и фамилия;
🔹 фото или аватар;
🔹 username, телефон, email;
🔹 должность и компания;
🔹 скрин переписки;
🔹 голосовое, видео, фото клиента;
🔹 детали заказа, адрес, сумма, личные обстоятельства;
🔹 отзыв в рекламе, на лендинге или в презентации.
Особенно аккуратно со скринами. На них часто видно больше, чем кажется: имя, аватар, дату, контекст переписки, номер заказа, часть личной истории.
Лучше прямо спросить:
«Можно ли опубликовать ваш отзыв в Telegram? Указать имя или оставить анонимно? Фото/аватар скрыть?». И сохранить ответ.
Когда достаточно обезличить
Если вы не хотите получать отдельное согласие, отзыв можно использовать в обезличенном виде.
Например:
«Клиент из сферы онлайн-образования отметил, что после проверки оферты стало понятнее, как оформлять возвраты». Конечно же, такие отзывы никому не интересны и не кажутся настоящими.
Что нужно убрать:
🔹 ФИО;
🔹 фото и аватар;
🔹 username;
🔹 телефон и email;
🔹 название компании, если по нему легко понять человека;
🔹 адрес, номер заказа, суммы;
🔹 редкие детали, по которым клиента можно вычислить;
🔹 фрагменты личной переписки, не относящиеся к отзыву.
Важно: обезличивание - это не просто замазать фамилию. Если по сочетанию деталей всё равно понятно, кто это, значит риск остаётся.
Например:
«основательница единственной школы керамики в городе N» - без имени, но человека легко узнать.
Что лучше прописать заранее
В форме обратной связи, договоре или анкете можно добавить отдельное согласие на использование отзыва:
🤍 где можно публиковать отзыв: сайт, Telegram, соцсети, презентации;
🤍 в каком виде: текст, скрин, видео;
🤍 можно ли указывать имя, фото, компанию;
🤍 можно ли использовать отзыв в рекламе;
🤍 как человек может отозвать согласие.
Простое правило:
если отзыв можно связать с конкретным человеком - берём согласие; если согласия нет - обезличиваем так, чтобы человека нельзя было узнать.
Отзыв клиента - отличный маркетинговый инструмент, но не каждый отзыв можно просто взять и выложить в Telegram, на сайт или в рекламу.
Главная ошибка думать, что если человек написал вам приятное сообщение, значит он автоматически согласился на публичную публикацию.
Когда лучше получить согласие
Согласие нужно, если вы хотите опубликовать отзыв с данными, по которым человека можно узнать:
Особенно аккуратно со скринами. На них часто видно больше, чем кажется: имя, аватар, дату, контекст переписки, номер заказа, часть личной истории.
Лучше прямо спросить:
«Можно ли опубликовать ваш отзыв в Telegram? Указать имя или оставить анонимно? Фото/аватар скрыть?». И сохранить ответ.
Когда достаточно обезличить
Если вы не хотите получать отдельное согласие, отзыв можно использовать в обезличенном виде.
Например:
«Клиент из сферы онлайн-образования отметил, что после проверки оферты стало понятнее, как оформлять возвраты». Конечно же, такие отзывы никому не интересны и не кажутся настоящими.
Что нужно убрать:
Важно: обезличивание - это не просто замазать фамилию. Если по сочетанию деталей всё равно понятно, кто это, значит риск остаётся.
Например:
«основательница единственной школы керамики в городе N» - без имени, но человека легко узнать.
Что лучше прописать заранее
В форме обратной связи, договоре или анкете можно добавить отдельное согласие на использование отзыва:
Простое правило:
если отзыв можно связать с конкретным человеком - берём согласие; если согласия нет - обезличиваем так, чтобы человека нельзя было узнать.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Публичная оферта: какие условия суд может не принять
Оферта помогает заключить договор онлайн: на сайте, в приложении, в личном кабинете, через оплату. Тем не менее если условие нарушает права потребителя, суд может признать его недействительным или просто не применить.
Что чаще всего попадает в зону риска?
➡️ «Деньги не возвращаются»
Обсуждали ранее, но все равно скажу пару слов.
Такое условие особенно любят онлайн-школы, сервисы, консультанты, фотографы, бьюти-мастера, косметологи.
Однако потребитель вправе отказаться от услуги. Исполнитель может удержать только стоимость уже оказанной части и подтверждённые фактические расходы.
ВС РФ в деле № 72-КГ23-1-К8 разобрал спор по онлайн-обучению: в оферте было указано, что при отказе в определённый период возвращается только 8% оплаты. ВС РФ обозначил: суд должен смотреть не на формулу в оферте, а на то, какие услуги реально оказаны и какие расходы исполнитель доказал.
➡️ «Открыли доступ - значит услуга оказана полностью»
Для онлайн-курсов это тоже рискованная формулировка.
В деле № 5-КГ25-18-К2 клиент оплатил курс, получил доступ к личному кабинету, но прошёл только часть уроков и ссылался на низкое качество материалов. В оферте было написано, что услуги считаются оказанными с момента предоставления доступа.
ВС РФ указал: этого недостаточно. Нужно исследовать объём и качество услуг, а не просто ссылаться на факт открытия личного кабинета.
➡️ «Продавец может отменить заказ, если товара нет»
Если клиент оформил заказ и оплатил товар, договор уже может считаться заключённым.
ВС РФ в деле № 49-КГ22-28-К6 указал: продавец не вправе включать в публичную оферту условие, по которому он может в одностороннем порядке отменить оформленный заказ. Само по себе отсутствие товара на складе ещё не всегда доказывает невозможность исполнения.
После заключения договора выбор должен быть у покупателя: ждать товар, согласовать замену или отказаться от договора и получить деньги. Продавец не может автоматически подменить своё обязательство передать оплаченный товар возвратом денег только потому, что товар закончился.
➡️ «Цена может измениться после заказа»
Если интернет-магазин указал товар, цену, клиент оформил заказ и оплатил его, продавец не может потом сказать: «Извините, цена была ошибочной, доплатите».
В деле № 16-КГ23-6-К4 ВС РФ отметил: цена фиксируется в момент оформления заказа. Чтобы сослаться на техническую ошибку, продавцу нужно доказать, что покупатель действительно злоупотребил правом и должен был очевидно понимать ошибочность цены. Например, нельзя купить айфон за 15 000 вместо 150 000.
➡️ «Все споры только в суде по месту нахождения компании»
Потребителя нельзя просто отправить судиться в другой город, потому что так написано в типовой форме.
В деле № 18-КГ23-18-К4 ВС РФ указал: потребитель вправе обращаться в суд по месту своего жительства, если спор связан с защитой прав потребителей.
❤️ Главный вывод:
Хорошей оферте нужна детальность и правомерность условий:
❤️ когда договор считается заключённым;
❤️ что именно получает клиент;
❤️ как считается возврат;
❤️ какие расходы может удержать исполнитель;
❤️ когда услуга считается оказанной;
❤️ какие права остаются у потребителя.
Оферта должна защищать бизнес, но если она построена на ущемлении прав клиента, в суде она может сработать против самого бизнеса.
Оферта помогает заключить договор онлайн: на сайте, в приложении, в личном кабинете, через оплату. Тем не менее если условие нарушает права потребителя, суд может признать его недействительным или просто не применить.
Что чаще всего попадает в зону риска?
Обсуждали ранее, но все равно скажу пару слов.
Такое условие особенно любят онлайн-школы, сервисы, консультанты, фотографы, бьюти-мастера, косметологи.
Однако потребитель вправе отказаться от услуги. Исполнитель может удержать только стоимость уже оказанной части и подтверждённые фактические расходы.
ВС РФ в деле № 72-КГ23-1-К8 разобрал спор по онлайн-обучению: в оферте было указано, что при отказе в определённый период возвращается только 8% оплаты. ВС РФ обозначил: суд должен смотреть не на формулу в оферте, а на то, какие услуги реально оказаны и какие расходы исполнитель доказал.
Для онлайн-курсов это тоже рискованная формулировка.
В деле № 5-КГ25-18-К2 клиент оплатил курс, получил доступ к личному кабинету, но прошёл только часть уроков и ссылался на низкое качество материалов. В оферте было написано, что услуги считаются оказанными с момента предоставления доступа.
ВС РФ указал: этого недостаточно. Нужно исследовать объём и качество услуг, а не просто ссылаться на факт открытия личного кабинета.
Если клиент оформил заказ и оплатил товар, договор уже может считаться заключённым.
ВС РФ в деле № 49-КГ22-28-К6 указал: продавец не вправе включать в публичную оферту условие, по которому он может в одностороннем порядке отменить оформленный заказ. Само по себе отсутствие товара на складе ещё не всегда доказывает невозможность исполнения.
После заключения договора выбор должен быть у покупателя: ждать товар, согласовать замену или отказаться от договора и получить деньги. Продавец не может автоматически подменить своё обязательство передать оплаченный товар возвратом денег только потому, что товар закончился.
Если интернет-магазин указал товар, цену, клиент оформил заказ и оплатил его, продавец не может потом сказать: «Извините, цена была ошибочной, доплатите».
В деле № 16-КГ23-6-К4 ВС РФ отметил: цена фиксируется в момент оформления заказа. Чтобы сослаться на техническую ошибку, продавцу нужно доказать, что покупатель действительно злоупотребил правом и должен был очевидно понимать ошибочность цены. Например, нельзя купить айфон за 15 000 вместо 150 000.
Потребителя нельзя просто отправить судиться в другой город, потому что так написано в типовой форме.
В деле № 18-КГ23-18-К4 ВС РФ указал: потребитель вправе обращаться в суд по месту своего жительства, если спор связан с защитой прав потребителей.
Хорошей оферте нужна детальность и правомерность условий:
Оферта должна защищать бизнес, но если она построена на ущемлении прав клиента, в суде она может сработать против самого бизнеса.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Договор с разработчиком: 7 пунктов, которые нужно проверить до оплаты
Оплата разработчику сама по себе не означает, что вы получили всё, что нужно для проекта.
Можно заплатить за сайт, приложение или бота, получить ссылку, доступ в админку и даже акт, а потом выяснить, что исходники не переданы, права оформлены неправильно, подрядчик может использовать код повторно, а доработки стоят как новый проект.
Что стоит проверить до оплаты?
🤍 Что именно разрабатывают
Не «сайт» или «приложение», а конкретно: страницы, функции, личный кабинет, интеграции, админка, дизайн, тексты, API, документация. Чем подробнее ТЗ, тем меньше споров в стиле «мы думали, что это входит».
🤍 Кому принадлежат права
В договоре должно быть прямо написано, что исключительные права на результат переходят заказчику или заказчику предоставляется лицензия. Если этого нет, потом может оказаться, что вы получили только фактический доступ, а не юридическое право использовать продукт как хотите.
Даже если исключительные права на созданный по заказу результат переходят заказчику, по ст. 1296 ГК РФ у исполнителя по умолчанию может сохраняться право использовать этот результат для собственных нужд на условиях безвозмездной простой неисключительной лицензии. Если заказчику важна максимальная эксклюзивность, это право лучше прямо исключить в договоре.
🤍 Когда переходят права
Лучше прописать момент: после полной оплаты, после подписания акта, после передачи результата или иной понятный момент. Иначе можно спорить: деньги уже ушли, а права ещё нет.
🤍 Что с исходниками
Доступ к сайту и исходный код - не одно и то же. В договоре стоит отдельно указать, что передаётся: репозиторий, макеты, дизайн-файлы, база данных, документация, логины, ключи, инструкции.
🤍 Можно ли использовать чужие библиотеки, шаблоны и open source
Разработчик может взять готовые решения. Это нормально, но заказчик должен понимать, какие лицензии там используются и нет ли ограничений для коммерческого проекта.
🤍 Как принимается результат
Нужен порядок проверки: срок на тестирование, список критериев, что считается багом, как фиксируются замечания, сколько времени даётся на исправление. Иначе акт могут подписать, а дальше любые правки станут «дополнительной работой».
🤍 Что происходит после запуска
Важно заранее договориться про гарантийный срок, исправление ошибок, поддержку, доступы, перенос проекта, удаление копий и конфиденциальность.
❤️ Главный вывод: договор с разработчиком должен отвечать не только на вопрос «сколько стоит», но и на вопрос «что именно я получаю после оплаты?»
Идеальная формула для заказчика:
результат передан, права оформлены, исходники получены, доступы у вас, порядок доработок понятен.
Если хотя бы одного элемента нет, проект вроде бы запущен, но юридически и технически вы всё ещё зависите от подрядчика.
Оплата разработчику сама по себе не означает, что вы получили всё, что нужно для проекта.
Можно заплатить за сайт, приложение или бота, получить ссылку, доступ в админку и даже акт, а потом выяснить, что исходники не переданы, права оформлены неправильно, подрядчик может использовать код повторно, а доработки стоят как новый проект.
Что стоит проверить до оплаты?
Не «сайт» или «приложение», а конкретно: страницы, функции, личный кабинет, интеграции, админка, дизайн, тексты, API, документация. Чем подробнее ТЗ, тем меньше споров в стиле «мы думали, что это входит».
В договоре должно быть прямо написано, что исключительные права на результат переходят заказчику или заказчику предоставляется лицензия. Если этого нет, потом может оказаться, что вы получили только фактический доступ, а не юридическое право использовать продукт как хотите.
Даже если исключительные права на созданный по заказу результат переходят заказчику, по ст. 1296 ГК РФ у исполнителя по умолчанию может сохраняться право использовать этот результат для собственных нужд на условиях безвозмездной простой неисключительной лицензии. Если заказчику важна максимальная эксклюзивность, это право лучше прямо исключить в договоре.
Лучше прописать момент: после полной оплаты, после подписания акта, после передачи результата или иной понятный момент. Иначе можно спорить: деньги уже ушли, а права ещё нет.
Доступ к сайту и исходный код - не одно и то же. В договоре стоит отдельно указать, что передаётся: репозиторий, макеты, дизайн-файлы, база данных, документация, логины, ключи, инструкции.
Разработчик может взять готовые решения. Это нормально, но заказчик должен понимать, какие лицензии там используются и нет ли ограничений для коммерческого проекта.
Нужен порядок проверки: срок на тестирование, список критериев, что считается багом, как фиксируются замечания, сколько времени даётся на исправление. Иначе акт могут подписать, а дальше любые правки станут «дополнительной работой».
Важно заранее договориться про гарантийный срок, исправление ошибок, поддержку, доступы, перенос проекта, удаление копий и конфиденциальность.
Идеальная формула для заказчика:
результат передан, права оформлены, исходники получены, доступы у вас, порядок доработок понятен.
Если хотя бы одного элемента нет, проект вроде бы запущен, но юридически и технически вы всё ещё зависите от подрядчика.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Договор с блогером: что прописать, чтобы реклама не стала проблемой
Реклама у блогера юридически это цепочка: рекламодатель, блогер, площадка, ОРД, ЕРИР, маркировка, отчётность, статистика. И если что-то пошло не так, перекладывание ответственности на блогера не всегда спасает бизнес.
Что обязательно стоит прописать в договоре?
💌 Что именно размещается
Не просто «рекламная интеграция», а формат: пост, сторис, видео, закреп, ссылка, промокод, обзор, распаковка, конкурс.
Плюс: дата, время, срок размещения, площадка и ссылка на аккаунт.
💌 Кто отвечает за маркировку рекламы
В договоре нужно прямо указать, кто получает erid, кто работает с ОРД, кто передаёт данные в ЕРИР и кто следит, чтобы в публикации были:
«Реклама» + данные рекламодателя + идентификатор рекламы.
Лучше не оставлять это «по умолчанию».
💌 Кто передаёт отчётность после публикации
Маркировка - это не только получить токен до размещения. После публикации ещё передаются сведения об исполнении договора и статистика.
Поэтому в договоре стоит указать, кто и в какие сроки передаёт статистику, скриншоты, ссылки, акты, данные о показах.
💌 Кто платит рекламный сбор, если он применим
С 2025 года действуют обязательные отчисления с доходов от интернет-рекламы (с некоторыми исключениями). Поэтому в договоре лучше отдельно прописать, кто несёт соответствующие расходы и включены ли они в цену размещения.
💌 Согласование текста и креатива
Блогер может говорить «своим языком», но бизнесу важно заранее согласовать ключевые формулировки.
Особенно если реклама касается медицины, БАДов, финансов, образования, детских товаров, скидок, гарантий результата. Одна фраза вроде «точно вылечит», «гарантированный доход» или «лучший на рынке» может создать отдельный риск.
💌 Запрет на скрытую рекламу
Не стоит маскировать рекламную интеграцию под «просто личную рекомендацию», если блогер получает оплату или иной встречный бонус за продвижение.
Нативный формат сам по себе не отменяет рекламный характер материала.
Практика уже показывает, что «это просто обзор» не всегда работает. Например, в деле Аси Сивоконевой Омское УФАС признало рекламой ролик с распаковкой косметики, а суд поддержал эту позицию. Блогер ссылалась на то, что купила товары сама и не заключала договор с брендом, но суд посмотрел на содержание: крупный план товаров, узнаваемые бренды, положительная оценка и призыв купить. Поэтому нативный формат сам по себе не спасает. Если публикация фактически формирует интерес к товару и подталкивает к покупке, её могут квалифицировать как рекламу.
💌 Права на контент
Если бизнес хочет потом использовать видео блогера у себя на сайте, в Telegram, в рекламе или презентации, это нужно отдельно прописать.
Иначе блогер разместил пост у себя - а дальше использовать его лицо, голос, фото, текст или видео в других материалах может быть нельзя.
💌 Последствия ошибок
Стоит заранее определить:
🤍 кто исправляет публикацию;
🤍 в какой срок блогер обязан добавить маркировку или удалить пост;
🤍 кто несёт штрафы, если нарушение произошло по его вине;
🤍 можно ли удержать оплату;
🤍 что делать, если пост удалён раньше срока.
Главный вывод: договор с блогером должен описывать не только денежные вопросы, но и весь юридический маршрут рекламы.
Реклама у блогера юридически это цепочка: рекламодатель, блогер, площадка, ОРД, ЕРИР, маркировка, отчётность, статистика. И если что-то пошло не так, перекладывание ответственности на блогера не всегда спасает бизнес.
Что обязательно стоит прописать в договоре?
Не просто «рекламная интеграция», а формат: пост, сторис, видео, закреп, ссылка, промокод, обзор, распаковка, конкурс.
Плюс: дата, время, срок размещения, площадка и ссылка на аккаунт.
В договоре нужно прямо указать, кто получает erid, кто работает с ОРД, кто передаёт данные в ЕРИР и кто следит, чтобы в публикации были:
«Реклама» + данные рекламодателя + идентификатор рекламы.
Лучше не оставлять это «по умолчанию».
Маркировка - это не только получить токен до размещения. После публикации ещё передаются сведения об исполнении договора и статистика.
Поэтому в договоре стоит указать, кто и в какие сроки передаёт статистику, скриншоты, ссылки, акты, данные о показах.
С 2025 года действуют обязательные отчисления с доходов от интернет-рекламы (с некоторыми исключениями). Поэтому в договоре лучше отдельно прописать, кто несёт соответствующие расходы и включены ли они в цену размещения.
Блогер может говорить «своим языком», но бизнесу важно заранее согласовать ключевые формулировки.
Особенно если реклама касается медицины, БАДов, финансов, образования, детских товаров, скидок, гарантий результата. Одна фраза вроде «точно вылечит», «гарантированный доход» или «лучший на рынке» может создать отдельный риск.
Не стоит маскировать рекламную интеграцию под «просто личную рекомендацию», если блогер получает оплату или иной встречный бонус за продвижение.
Нативный формат сам по себе не отменяет рекламный характер материала.
Практика уже показывает, что «это просто обзор» не всегда работает. Например, в деле Аси Сивоконевой Омское УФАС признало рекламой ролик с распаковкой косметики, а суд поддержал эту позицию. Блогер ссылалась на то, что купила товары сама и не заключала договор с брендом, но суд посмотрел на содержание: крупный план товаров, узнаваемые бренды, положительная оценка и призыв купить. Поэтому нативный формат сам по себе не спасает. Если публикация фактически формирует интерес к товару и подталкивает к покупке, её могут квалифицировать как рекламу.
Если бизнес хочет потом использовать видео блогера у себя на сайте, в Telegram, в рекламе или презентации, это нужно отдельно прописать.
Иначе блогер разместил пост у себя - а дальше использовать его лицо, голос, фото, текст или видео в других материалах может быть нельзя.
Стоит заранее определить:
Главный вывод: договор с блогером должен описывать не только денежные вопросы, но и весь юридический маршрут рекламы.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Cookie и аналитика: когда баннер нужен, а когда это просто декорация
Cookie-баннер часто ставят по принципу: «у всех есть, пусть и у нас будет». Сам по себе баннер ничего не решает. Особенно если он просто сообщает: «Мы используем cookies. Продолжая пользоваться сайтом, вы соглашаетесь».
Такой баннер может выглядеть солидно, но юридически быть почти декорацией.
В России нет отдельного «закона о cookie», как в Европе. Но cookie, IP-адрес, идентификатор устройства, данные из Яндекс.Метрики, пикселей и других аналитических сервисов могут быть персональными данными, если по ним можно прямо или косвенно определить пользователя.
Когда баннер действительно нужен? Если сайт использует:
❌ аналитику поведения пользователей;
❌ рекламные пиксели и ретаргетинг;
❌ сквозную аналитику;
❌ персонализацию контента;
❌ идентификаторы пользователя;
❌ передачу данных сторонним сервисам;
❌ cookie не только для технической работы сайта.
Например, если у вас стоят Яндекс.Метрика, VK Pixel, Google Analytics, call tracking или рекламные кабинеты, лучше не ограничиваться фразой «мы используем cookies».
Что должно быть нормально сделано:
❌ В политике обработки персональных данных описаны cookie и аналитика.
❌ Указано, какие данные собираются: IP, cookie ID, сведения об устройстве, действия на сайте.
❌ Понятно, зачем они собираются: аналитика, улучшение сайта, реклама, ретаргетинг.
❌ Указано, кому данные могут передаваться: сервисы аналитики, рекламные платформы, подрядчики.
❌ Пользователь может понять, на что именно он соглашается.
Для необязательных cookie лучше дать выбор: принять, отказаться или настроить.
Когда баннер может быть лишним?
Если сайт использует только технические cookie, которые нужны для работы сайта: например, сохранить корзину, авторизацию, язык интерфейса или сессию пользователя.
Однако даже здесь важно смотреть, что именно хранится в cookie. Если там лежит идентификатор пользователя, токен, связка с аккаунтом или данные, позволяющие отслеживать поведение, это уже не просто «техническая мелочь».
Правило: если сайт отслеживает поведение пользователей и передаёт данные в сервисы аналитики или рекламы, нужно не просто повесить уведомление, а настроить всю цепочку: политика, согласие, выбор пользователя, перечень сервисов, уведомление в РКН и порядок отключения необязательных cookie.
Cookie-баннер часто ставят по принципу: «у всех есть, пусть и у нас будет». Сам по себе баннер ничего не решает. Особенно если он просто сообщает: «Мы используем cookies. Продолжая пользоваться сайтом, вы соглашаетесь».
Такой баннер может выглядеть солидно, но юридически быть почти декорацией.
В России нет отдельного «закона о cookie», как в Европе. Но cookie, IP-адрес, идентификатор устройства, данные из Яндекс.Метрики, пикселей и других аналитических сервисов могут быть персональными данными, если по ним можно прямо или косвенно определить пользователя.
Когда баннер действительно нужен? Если сайт использует:
Например, если у вас стоят Яндекс.Метрика, VK Pixel, Google Analytics, call tracking или рекламные кабинеты, лучше не ограничиваться фразой «мы используем cookies».
Что должно быть нормально сделано:
Для необязательных cookie лучше дать выбор: принять, отказаться или настроить.
Когда баннер может быть лишним?
Если сайт использует только технические cookie, которые нужны для работы сайта: например, сохранить корзину, авторизацию, язык интерфейса или сессию пользователя.
Однако даже здесь важно смотреть, что именно хранится в cookie. Если там лежит идентификатор пользователя, токен, связка с аккаунтом или данные, позволяющие отслеживать поведение, это уже не просто «техническая мелочь».
Правило: если сайт отслеживает поведение пользователей и передаёт данные в сервисы аналитики или рекламы, нужно не просто повесить уведомление, а настроить всю цепочку: политика, согласие, выбор пользователя, перечень сервисов, уведомление в РКН и порядок отключения необязательных cookie.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Можно ли копировать структуру чужого курса, сайта или приложения?
Короткий ответ:идею - можно, конкретную реализацию - нельзя.
Авторское право не защищает сами идеи, методы, концепции, принципы, процессы и способы решения задач. Поэтому нельзя запретить конкуренту сделать:
🪐 курс на ту же тему;
🪐 сайт с похожими разделами;
🪐 приложение с похожей логикой;
🪐 воронку «заявка - оплата - личный кабинет»;
🪐 модульную структуру обучения.
Риск появляется, когда копируют не идею, а форму.
Например, с курсом нельзя просто взять чужие:
🪐 названия уроков один в один;
🪐 тексты, презентации, чек-листы;
🪐 домашние задания;
🪐 примеры и кейсы;
🪐 структуру модулей с тем же порядком и формулировками;
🪐 визуальное оформление материалов;
🪐 видео, иллюстрации, схемы.
С сайтом и приложением похожая логика.
Сам по себе личный кабинет, корзина, каталог, квиз или форма заявки - не чья-то монополия, но если скопировать тексты, дизайн, интерфейс, иконки, карточки, расположение блоков, код, изображения и общий внешний вид так, что пользователь может спутать один продукт с другим, это уже риск.
Есть ещё отдельная история - недобросовестная конкуренция. Даже если спор не идеально ложится в авторское право, слишком похожее оформление продукта, сайта или сервиса может создать смешение с конкурентом.
В общем, можно вдохновляться логикой, но нельзя копировать узнаваемую форму.
Как безопаснее делать:
➗ Изучить чужой продукт как референс, но не переносить структуру «раздел в раздел».
➗ Писать свои тексты, названия уроков, задания и примеры.
➗ Делать собственный дизайн и визуальную систему.
➗ Не копировать код, макеты, презентации и базу материалов.
➗ Проверить, не создаёт ли продукт ощущение «это почти тот же бренд».
➗ Сохранять черновики и историю разработки, чтобы показать самостоятельное создание.
Короткий ответ:
Авторское право не защищает сами идеи, методы, концепции, принципы, процессы и способы решения задач. Поэтому нельзя запретить конкуренту сделать:
Риск появляется, когда копируют не идею, а форму.
Например, с курсом нельзя просто взять чужие:
С сайтом и приложением похожая логика.
Сам по себе личный кабинет, корзина, каталог, квиз или форма заявки - не чья-то монополия, но если скопировать тексты, дизайн, интерфейс, иконки, карточки, расположение блоков, код, изображения и общий внешний вид так, что пользователь может спутать один продукт с другим, это уже риск.
Есть ещё отдельная история - недобросовестная конкуренция. Даже если спор не идеально ложится в авторское право, слишком похожее оформление продукта, сайта или сервиса может создать смешение с конкурентом.
В общем, можно вдохновляться логикой, но нельзя копировать узнаваемую форму.
Как безопаснее делать:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥3👏1
Health tech: почему данные о здоровье нельзя обрабатывать как обычные персональные данные
Health tech-проекты часто выглядят как обычный IT-сервис: приложение, бот, личный кабинет, трекер, форма записи, чат со специалистом, но юридически всё меняется в момент, когда проект начинает работать с данными о здоровье.
Это могут быть не только диагнозы и результаты анализов. К чувствительным данным относятся, например:
❤️ симптомы;
❤️ лекарства;
❤️ аллергии;
❤️ давление, пульс, сахар;
❤️ беременность;
❤️ менструальный цикл;
❤️ вес в связке с медицинскими целями;
❤️ история обращений;
❤️ результаты обследований;
❤️ переписка с врачом или психологом.
Данные о состоянии здоровья - специальная категория персональных данных. А если сервис связан с оказанием медицинской помощи, добавляется ещё и режим врачебной тайны.
Где обычно риски?
▶ Собирают больше, чем нужно
Например, для записи на консультацию достаточно имени и телефона, но форма дополнительно просит диагноз, анализы и подробную историю болезни.
▶ Согласие слишком общее
Фраза «согласен на обработку персональных данных» не всегда подходит для данных о здоровье.
Нужно отдельно и понятно объяснить: какие именно медицинские или околомедицинские данные собираются, зачем, кто их увидит, кому они могут передаваться и как долго хранятся.
▶ Подрядчики видят лишнее
Разработчики, CRM, колл-центр, облако, аналитика, техподдержка, маркетологи - все они могут получить доступ к чувствительным данным.
И здесь вопрос не только в договоре. Важно технически ограничить доступ: кому действительно нужно видеть диагноз или анкету пациента, а кому достаточно номера заявки.
▶ Аналитика собирает то, что не должна
Иногда медицинские данные случайно утекают в события аналитики: название симптома в URL, диагноз в названии формы, данные анкеты в метках событий.
В России есть показательный пример - дело Гемотеста. После утечки данных клиентов в 2022 году суд оштрафовал лабораторию по ст. 13.11 КоАП РФ. В утекших данных были не только обычные сведения о клиентах, но и информация об оказанных медицинских услугах. Ссылка на хакерскую атаку не спасла оператора: суд указал, что оператор не обеспечил конфиденциальность данных.
Примечательно, что я тоже обнаружила мои слитые ПД, но это было в 2025 году. Написала в Гемотест - они ответили отпиской, впрочем, как и Роскомнадзор. Учитывая их практику нарушений, для меня странно, что не было проведено тщательное расследование хотя бы гос. органом, если не самой лабораторией. А со стороны Гемотеста странно, что не удосужились организовать грамотную защиту данных.
За рубежом health tech-практика жёстче, чем в России. В США FTC разбирала дела Flo Health, GoodRx, BetterHelp, а недавно - Hims & Hers. Общий сюжет похожий: сервисы обещали пользователям приватность, но данные о здоровье или обращении за медицинскими/психологическими услугами попадали в рекламные платформы вроде Meta, Google, Snap через пиксели, SDK или другие инструменты аналитики.
▶ Обезличивание считают волшебной таблеткой
Если данные можно обратно связать с пользователем через аккаунт, номер телефона, device ID или историю действий, это не полноценное обезличивание. Просто убрать ФИО из медицинской анкеты часто недостаточно.
▶ Нет понятного срока хранения
Health tech-проекты любят хранить всё: анкеты, переписки, файлы, назначения, записи консультаций. Однако должен быть понятный ответ: зачем мы это храним, сколько, кто имеет доступ и что делаем, если пользователь просит удалить данные.
На самом деле, этим грешат и крупные клиники. Куда бы я не пришла - везде неправильно составлены документы, связанные с персональными данными. Приходится от руки подписывать им недостающие данные. Другой вопрос - будут ли они действительно удалять мои данные через три месяца, как я этого требую 🙂
Главный вывод:
в health tech юридическая работа начинается не с политики на сайте, а с карты данных.
Нужно сначала понять:
🔹 какие данные собираем;
🔹 какие из них относятся к здоровью;
🔹 кто оператор;
🔹 кто имеет доступ;
🔹 где данные хранятся;
🔹 куда передаются;
🔹 какие согласия нужны;
🔹 какие меры безопасности реально настроены.
Health tech-проекты часто выглядят как обычный IT-сервис: приложение, бот, личный кабинет, трекер, форма записи, чат со специалистом, но юридически всё меняется в момент, когда проект начинает работать с данными о здоровье.
Это могут быть не только диагнозы и результаты анализов. К чувствительным данным относятся, например:
Данные о состоянии здоровья - специальная категория персональных данных. А если сервис связан с оказанием медицинской помощи, добавляется ещё и режим врачебной тайны.
Где обычно риски?
Например, для записи на консультацию достаточно имени и телефона, но форма дополнительно просит диагноз, анализы и подробную историю болезни.
Фраза «согласен на обработку персональных данных» не всегда подходит для данных о здоровье.
Нужно отдельно и понятно объяснить: какие именно медицинские или околомедицинские данные собираются, зачем, кто их увидит, кому они могут передаваться и как долго хранятся.
Разработчики, CRM, колл-центр, облако, аналитика, техподдержка, маркетологи - все они могут получить доступ к чувствительным данным.
И здесь вопрос не только в договоре. Важно технически ограничить доступ: кому действительно нужно видеть диагноз или анкету пациента, а кому достаточно номера заявки.
Иногда медицинские данные случайно утекают в события аналитики: название симптома в URL, диагноз в названии формы, данные анкеты в метках событий.
В России есть показательный пример - дело Гемотеста. После утечки данных клиентов в 2022 году суд оштрафовал лабораторию по ст. 13.11 КоАП РФ. В утекших данных были не только обычные сведения о клиентах, но и информация об оказанных медицинских услугах. Ссылка на хакерскую атаку не спасла оператора: суд указал, что оператор не обеспечил конфиденциальность данных.
Примечательно, что я тоже обнаружила мои слитые ПД, но это было в 2025 году. Написала в Гемотест - они ответили отпиской, впрочем, как и Роскомнадзор. Учитывая их практику нарушений, для меня странно, что не было проведено тщательное расследование хотя бы гос. органом, если не самой лабораторией. А со стороны Гемотеста странно, что не удосужились организовать грамотную защиту данных.
За рубежом health tech-практика жёстче, чем в России. В США FTC разбирала дела Flo Health, GoodRx, BetterHelp, а недавно - Hims & Hers. Общий сюжет похожий: сервисы обещали пользователям приватность, но данные о здоровье или обращении за медицинскими/психологическими услугами попадали в рекламные платформы вроде Meta, Google, Snap через пиксели, SDK или другие инструменты аналитики.
Если данные можно обратно связать с пользователем через аккаунт, номер телефона, device ID или историю действий, это не полноценное обезличивание. Просто убрать ФИО из медицинской анкеты часто недостаточно.
Health tech-проекты любят хранить всё: анкеты, переписки, файлы, назначения, записи консультаций. Однако должен быть понятный ответ: зачем мы это храним, сколько, кто имеет доступ и что делаем, если пользователь просит удалить данные.
На самом деле, этим грешат и крупные клиники. Куда бы я не пришла - везде неправильно составлены документы, связанные с персональными данными. Приходится от руки подписывать им недостающие данные. Другой вопрос - будут ли они действительно удалять мои данные через три месяца, как я этого требую 🙂
Главный вывод:
в health tech юридическая работа начинается не с политики на сайте, а с карты данных.
Нужно сначала понять:
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥2👏1
Юридический чек-лист для разработчика (часть 1)
Юридические риски на сайте или приложении часто появляются ещё на этапе выбора хостинга, CRM, аналитики, чата, AI-сервиса и логики хранения данных.
Предлагаю вам пять пунктов, которые стоит обсудить с клиентом до разработки.
1. Где будет база с персональными данными
Если проект собирает персональные данные граждан РФ, сначала нужно продумать локализацию: запись, хранение и основная работа с такой базой должны быть организованы на территории России (как минимум первично). Например, можно рассмотреть Selectel, Yandex Cloud, VK Cloud, Timeweb Cloud, Cloud. ru и другие российские инфраструктурные решения.
После этого отдельно проверяем, передаются ли данные за пределы РФ: например, в аналитику, CRM, email-сервис, AI API, сервис пуш-уведомлений, карты или облачную инфраструктуру. Если такая передача есть, клиенту важно заранее сказать, что это может быть трансграничная передача персональных данных и по ней может потребоваться отдельное уведомление Роскомнадзора.
Поэтому зарубежные сервисы вроде Vercel, Firebase, AWS, Google Cloud, Azure, Hetzner или DigitalOcean лучше не выбирать как первое и единственное место хранения персональных данных граждан РФ. Сначала нужно обеспечить локализацию базы в России, а уже потом оценивать, какие зарубежные сервисы можно подключать и на каких условиях.
2. Какие документы понадобятся на сайте или в приложении
До релиза лучше сразу понять, нужны ли клиенту:
🤍 политика обработки персональных данных;
🤍 оферта или пользовательское соглашение;
🤍 согласие на обработку персональных данных;
🤍 согласие на рекламную рассылку;
🤍 условия оплаты, возврата и подписки;
🤍 cookie-баннер и описание аналитики.
Соответственно, необходимо их интегрировать в сайт, включая чекбоксы. Как должны оформляться чекбоксы написала тут.
Главное: документы должны совпадать с реальным функционалом. Нельзя бездумно копировать у конкурентов или крупных игроков рынка, для вашего сайта/приложения это может оказаться некорректным.
3. Какие сторонние сервисы подключаются
Когда разработчик подключает CRM, аналитику, чат, рассылку, AI-сервис или Sentry, данные часто уходят не только в базу клиента, но и во внешний сервис.
Например, CRM вроде Bitrix24 или amoCRM может получать заявки и контакты пользователей; рассылочные сервисы вроде UniSender, Mindbox или Mailchimp — email, телефон; аналитика вроде Яндекс Метрики, Google Analytics, Amplitude или Firebase — события пользователя; AI-сервисы вроде GigaChat, YandexGPT, OpenAI API или Claude — текст запроса; сервисы ошибок вроде Sentry или Rollbar — технические логи, в которые иногда случайно попадают персональные данные.
Поэтому до подключения сервиса разработчику стоит проверить три вещи:
🤍 какие именно данные туда передаются;
🤍 разрешают ли условия сервиса передавать такие данные;
🤍 отражена ли такая передача в документах клиента: политике, согласии, оферте или пользовательском соглашении.
Если сервису достаточно обезличенного ID или события, что пользователь нажал кнопку, не нужно отправлять ФИО, телефон, email и весь текст заявки. Чем меньше лишних данных уходит во внешние сервисы, тем меньше юридических и технических рисков после релиза.
С AI-сервисами тоже нужно быть аккуратнее. Если приложение отправляет в модель жалобу пациента, текст договора, переписку пользователя, паспортные данные или данные клиента из CRM — это уже не просто «интеграция с нейросетью». Нужно проверять условия сервиса, режим хранения данных, обучение на запросах и возможность передачи персональных данных.
Иногда решением будет обезличить данные. Иногда — выбрать другой тариф или сервис. А иногда и вовсе не отправлять такие данные во внешний сервис.
Юридические риски на сайте или приложении часто появляются ещё на этапе выбора хостинга, CRM, аналитики, чата, AI-сервиса и логики хранения данных.
Предлагаю вам пять пунктов, которые стоит обсудить с клиентом до разработки.
1. Где будет база с персональными данными
Если проект собирает персональные данные граждан РФ, сначала нужно продумать локализацию: запись, хранение и основная работа с такой базой должны быть организованы на территории России (как минимум первично). Например, можно рассмотреть Selectel, Yandex Cloud, VK Cloud, Timeweb Cloud, Cloud. ru и другие российские инфраструктурные решения.
После этого отдельно проверяем, передаются ли данные за пределы РФ: например, в аналитику, CRM, email-сервис, AI API, сервис пуш-уведомлений, карты или облачную инфраструктуру. Если такая передача есть, клиенту важно заранее сказать, что это может быть трансграничная передача персональных данных и по ней может потребоваться отдельное уведомление Роскомнадзора.
Поэтому зарубежные сервисы вроде Vercel, Firebase, AWS, Google Cloud, Azure, Hetzner или DigitalOcean лучше не выбирать как первое и единственное место хранения персональных данных граждан РФ. Сначала нужно обеспечить локализацию базы в России, а уже потом оценивать, какие зарубежные сервисы можно подключать и на каких условиях.
2. Какие документы понадобятся на сайте или в приложении
До релиза лучше сразу понять, нужны ли клиенту:
Соответственно, необходимо их интегрировать в сайт, включая чекбоксы. Как должны оформляться чекбоксы написала тут.
Главное: документы должны совпадать с реальным функционалом. Нельзя бездумно копировать у конкурентов или крупных игроков рынка, для вашего сайта/приложения это может оказаться некорректным.
3. Какие сторонние сервисы подключаются
Когда разработчик подключает CRM, аналитику, чат, рассылку, AI-сервис или Sentry, данные часто уходят не только в базу клиента, но и во внешний сервис.
Например, CRM вроде Bitrix24 или amoCRM может получать заявки и контакты пользователей; рассылочные сервисы вроде UniSender, Mindbox или Mailchimp — email, телефон; аналитика вроде Яндекс Метрики, Google Analytics, Amplitude или Firebase — события пользователя; AI-сервисы вроде GigaChat, YandexGPT, OpenAI API или Claude — текст запроса; сервисы ошибок вроде Sentry или Rollbar — технические логи, в которые иногда случайно попадают персональные данные.
Поэтому до подключения сервиса разработчику стоит проверить три вещи:
Если сервису достаточно обезличенного ID или события, что пользователь нажал кнопку, не нужно отправлять ФИО, телефон, email и весь текст заявки. Чем меньше лишних данных уходит во внешние сервисы, тем меньше юридических и технических рисков после релиза.
С AI-сервисами тоже нужно быть аккуратнее. Если приложение отправляет в модель жалобу пациента, текст договора, переписку пользователя, паспортные данные или данные клиента из CRM — это уже не просто «интеграция с нейросетью». Нужно проверять условия сервиса, режим хранения данных, обучение на запросах и возможность передачи персональных данных.
Иногда решением будет обезличить данные. Иногда — выбрать другой тариф или сервис. А иногда и вовсе не отправлять такие данные во внешний сервис.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Юридический чек-лист для разработчика (часть 2)
4. Что будет с удалением данных
Нужно заранее понять:
❤️ что удаляется из основной базы;
❤️ что остается в логах;
❤️ что попадает в резервные копии;
❤️ как чистятся CRM, рассылки, чаты и аналитика;
❤️ какие данные нужно хранить по закону или договору;
❤️ кто и как обрабатывает запрос пользователя на удаление.
Эта информация далее понадобится юристу для подготовки политики обработки ПД и направления уведомления в РКН.
Отдельный лайфхак:не кладите персональные данные в URL. Email, телефон или ФИО в query-параметрах потом легко уезжают в логи, аналитику, пиксели и историю браузера.
5. Что понадобится клиенту для уведомления в Роскомнадзор
В форме уведомления в РКН множество технических сведений: какие данные собираются, где находится база, кому данные передаются, есть ли трансграничная передача, какие меры защиты применяются, какие сроки обработки.
Поэтому разработчику очень полезно вести простую таблицу по проекту:
❤️ какие данные собираем;
❤️ через какую форму или экран;
❤️ где храним;
❤️ в какие сервисы передаем;
❤️ в какой стране находится сервис;
❤️ кто контрагент по договору (важно знать точное юр. лицо, вплоть до адреса нахождения баз данных);
❤️ как долго храним;
❤️ как удаляем.
Это потом сильно помогает клиенту, юристу и самому разработчику, если проект нужно масштабировать или проходить проверку.
✈️ Главный вывод
Хороший разработчик не обязан знать все юридические тонкости, но всё же должен понимать, что выбор хостинга, CRM, аналитики, AI API, логов и бэкапов — это уже юридически значимые решения. Иногда один вопрос до старта проекта экономит клиенту месяцы переделок после релиза.
4. Что будет с удалением данных
Нужно заранее понять:
Эта информация далее понадобится юристу для подготовки политики обработки ПД и направления уведомления в РКН.
Отдельный лайфхак:
5. Что понадобится клиенту для уведомления в Роскомнадзор
В форме уведомления в РКН множество технических сведений: какие данные собираются, где находится база, кому данные передаются, есть ли трансграничная передача, какие меры защиты применяются, какие сроки обработки.
Поэтому разработчику очень полезно вести простую таблицу по проекту:
Это потом сильно помогает клиенту, юристу и самому разработчику, если проект нужно масштабировать или проходить проверку.
Хороший разработчик не обязан знать все юридические тонкости, но всё же должен понимать, что выбор хостинга, CRM, аналитики, AI API, логов и бэкапов — это уже юридически значимые решения. Иногда один вопрос до старта проекта экономит клиенту месяцы переделок после релиза.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3