Какие юридические документы нужны сайту или приложению бизнеса: полный разбор по функциям

Чтобы понять, какие документы нужны для сайта, сначала запишите, что на нем может сделать пользователь: оставить заявку, откликнуться на вакансию, оплатить заказ, создать аккаунт, загрузить файл, опубликовать отзыв или получить результат цифрового сервиса. От этих действий зависят документы, сведения на странице, внутренние решения и доказательства. Один и тот же домен может принадлежать одному лицу, собирать данные в интересах другого, продавать товар третьего и принимать оплату через четвертого участника. Поэтому универсального комплекта нет. Статья поможет последовательно определить применимые документы и заметить вопросы, которые требуют отдельной проверки.

Время чтения21 мин

АвторАнна Воронцова, старший юрист

СтатусОбновлено 26 мая 2026 г.

Поможем с Вашей задачей

Подготовим решение под факты Вашей задачи и объясним, как им пользоваться.

Заказать услугу

Коротко

Любому проекту нужно определить владельца сайта и показать достаточные сведения о нем. Для продаж потребителю набор информации шире.
Если сайт или приложение обрабатывает персональные данные, проверьте политику, основание для каждой цели, обязанность уведомить Роскомнадзор и связанные внутренние меры (ст. 6, ч. 2 ст. 18.1 и ст. 22 Закона №152-ФЗ). Согласие требуется не для любой обработки: сначала определяется применимое основание из статьи 6 (ст. 6 Закона №152-ФЗ).
Оферта регулирует сделку, пользовательское соглашение - функции и правила цифрового взаимодействия. Они могут использоваться вместе или быть объединены, если роли и условия остаются понятными.
Уведомление о cookie, ссылка в футере или один чекбокс не устраняют противоречия между текстом, интерфейсом, CRM, платежами и фактическими действиями команды.
Для интернет-магазина, SaaS, платформы и ИИ-продукта набор документов и проверок отличается. Отдельные статьи подробнее разберут эти модели, а необходимые исходные сведения приведены уже здесь.

Сначала составьте карту участников и их функций

Название компании в футере не всегда позволяет понять, кто управляет доменом, кто определяет цели обработки данных и с кем пользователь заключает договор. Перед подготовкой документов составьте карту участников.

Владелец сайта или приложения

Это лицо, которое определяет размещение информации и управляет цифровым ресурсом. Часть 2 статьи 10 Закона №149-ФЗ обязывает владельца сайта разместить наименование, место нахождения и адрес, а также электронную почту для предусмотренных законом обращений. Само владение доменным именем у регистратора является важным фактом, но не всегда исчерпывает вопрос о фактическом владельце ресурса.

Оператор персональных данных

Оператор по пункту 2 статьи 3 Закона №152-ФЗ определяет цели, состав данных и действия с ними. Им может быть владелец сайта, продавец, работодатель или несколько лиц совместно. Подрядчик, который обрабатывает данные строго по поручению оператора, только из-за этого не становится оператором в отношении целей, которые определил заказчик (ч. 3 ст. 6 Закона №152-ФЗ).

Продавец или исполнитель в отношениях с клиентом

Это сторона договора с покупателем или заказчиком. В потребительской сделке продавец или исполнитель предоставляет обязательную информацию о себе, товаре, работе или услуге и исполняет применимые обязанности по договору (ст. 8-10 Закона РФ «О защите прав потребителей»). Логотип бренда, домен и получатель денег могут указывать на разных участников, поэтому сторона должна быть понятна до заказа.

Получатель оплаты

Деньги может принимать сам продавец, платежный агент, агрегатор или иное лицо. Платежная форма не должна создавать ложное впечатление, что технический получатель платежа является продавцом. В оферте, заказе и чеке нужно согласованно показать роли и основание приема денег.

Обладатель информации и правообладатель продукта

Контент, программный код, товарный знак и пользовательские материалы могут принадлежать разным лицам. Пользователь должен понимать, кто разрешает использовать сервис, кому он предоставляет право разместить свой контент и куда направлять жалобу о нарушении прав.

Практический вывод: не указывайте одно лицо во всех ролях только ради простоты текста. Сначала зафиксируйте, кто фактически управляет ресурсом, определяет цели обработки, заключает договор, получает оплату и распоряжается контентом. Затем ясно объясните различия пользователю. Иначе политика может назвать одного оператора, оферта - другого исполнителя, а чек - третьего получателя платежа.

Какие реквизиты размещать: две позиции

В вопросе о реквизитах нужно разделить минимальное требование к владельцу сайта и расширенную информацию, необходимую в конкретной деятельности.

Узкая позиция: обязательный минимум владельца

Часть 2 статьи 10 Закона №149-ФЗ прямо называет наименование, место нахождения и адрес владельца сайта, а также адрес электронной почты. Из этой нормы самой по себе не следует универсальная обязанность каждого сайта публиковать ИНН, ОГРН, банковские реквизиты и телефон.

Этот подход не освобождает от требований специальных законов. Он лишь не добавляет к статье 10 сведения, которых в ней нет (ст. 10 Закона №149-ФЗ). Ограничиваться этим минимумом опасно, если сайт одновременно продает товары, оказывает регулируемую услугу или создает впечатление, что пользователь уже взаимодействует с определенным исполнителем.

Расширенная позиция: достаточная идентификация и специальные сведения

Для потребительского сценария применяются статьи 8-10 Закона РФ «О защите прав потребителей»: до заключения договора покупатель получает необходимую и достоверную информацию об исполнителе, режиме работы, товаре или услуге. Для дистанционной продажи дополнительно действует статья 26.1. В регулируемых отраслях состав обязательных сведений проверяется по специальным нормам для конкретной деятельности.

Компания может дополнительно указать ИНН, ОГРН или ОГРНИП, телефон, почтовый адрес и реквизиты для претензий. Это помогает однозначно определить сторону, но не превращает добровольно расширенный набор в одинаковую обязанность для всех сайтов.

ООО «Ромашка»: домен зарегистрирован на учредителя, сайт ведет ООО, товар продает ИП-партнер, а оплату принимает агрегатор. Публикация только реквизитов ООО не отвечает, с кем покупатель заключает договор. На странице заказа нужно развести владельца ресурса, продавца и технического участника платежа.

Индивидуальный предприниматель (ИП) и самозанятый

ИП указывает себя как сторону договора и не маскирует деятельность только названием бренда. Самозанятый также должен быть идентифицируемым исполнителем, если продает собственную работу или услугу. Для него отдельно проверяют допустимость вида деятельности, отсутствие посреднической модели там, где она запрещена специальным режимом, и обязанность сформировать и передать чек плательщика НПД по статье 14 Закона №422-ФЗ. Чек можно сформировать не только непосредственно в приложении «Мой налог», но и предусмотренным законом способом через уполномоченную площадку или кредитную организацию.

Краткое правило одно: статус влияет на реквизиты, налоговый документ и допустимую модель, но не отменяет требования честно назвать сторону сделки и оператора данных.

Карта документов по функциям

Ниже приведено не описание готового пакета, а дерево выбора. Для каждой функции нужно согласовать публичный текст, интерфейс, внутреннее действие и доказательство.

Проект только публикует информацию

Проверьте владельца, обязательные отраслевые сведения, права на тексты и изображения, аналитику, карты, встроенные видео и технические журналы. Если нет форм, аккаунта, оплаты и сторонних идентификаторов, согласие и договорные документы могут не понадобиться.

Пользователь оставляет заявку или пишет в чат

Определите цель и основание обработки, оператора, получателей, срок хранения и способ информирования. Политика описывает обработку, а согласие используется только тогда, когда оно выбрано правовым основанием. Внутри компании нужно определить, кто получает заявку, что с ней делает и когда удаляет лишние данные.

Кандидат откликается на вакансию

Резюме может содержать контакты, историю работы, фотографию и дополнительные сведения. Нужны отдельная понятная цель, срок рассмотрения, правила кадрового резерва, получатели и удаление. Данные отклика не следует незаметно переносить в маркетинговую базу.

Пользователь оформляет и оплачивает заказ

Появляются продавец, предмет, цена, момент заключения договора, подтверждение заказа, исполнение, возврат, чек и данные платежа. Условия оферты, ущемляющие установленные законом права потребителя, недопустимы и ничтожны (ст. 16 Закона РФ «О защите прав потребителей»).

Есть аккаунт, подписка или цифровой доступ

Нужно описать регистрацию, тариф, срок доступа, регулярность списания, изменение условий, блокировку, удаление аккаунта и судьбу данных. Оферта и пользовательское соглашение решают разные задачи, хотя иногда могут быть объединены.

Пользователь загружает или публикует материалы

Нужны правила допустимого контента, права на техническое использование, жалобы, модерация, удаление и публикация персональных данных. Закрытый файл и публичный отзыв требуют разных решений.

Работают аналитика, реклама, CRM и подрядчики

Определите, куда данные передаются из браузера и кто их получает. Проверьте поручение обработки, иностранные элементы, локализацию, сроки хранения, рекламное согласие и момент загрузки необязательных инструментов.

Продукт ранжирует, рекомендует или принимает автоматизированные решения

Помимо политики и пользовательских условий проверьте статью 10.2-2 Закона №149-ФЗ о рекомендательных технологиях и статью 16 Закона №152-ФЗ об исключительно автоматизированных решениях, затрагивающих права и законные интересы человека.

Публичные документы и сведения

Публичные документы нужны не для количества файлов в футере. Каждый документ отвечает на свой вопрос и должен быть доступен до юридически значимого действия.

Сведения о владельце и стороне сделки

Отвечают, кто распространяет информацию, кто продает или оказывает услугу и куда обращаться. Не заменяются логотипом, доменом или названием платежной формы.

Политика обработки персональных данных

Часть 2 статьи 18.1 Закона №152-ФЗ требует опубликовать политику в отношении обработки персональных данных и сведения о реализуемых требованиях к защите, а также обеспечить доступ к ним на страницах, где собираются данные. Чтобы политика действительно описывала обработку, в ней следует отразить применимые категории субъектов и данных, цели, основания, операции, сроки, получателей и права человека.

Это практические требования к содержанию документа, а не дословный перечень из части 2 статьи 18.1 (ч. 2 ст. 18.1 Закона №152-ФЗ). Политика не является согласием и сама по себе не создает правового основания для обработки (ст. 6 и ст. 9 Закона №152-ФЗ).

Согласие на обработку персональных данных

Часть 1 статьи 9 Закона №152-ФЗ требует, чтобы согласие было конкретным, предметным, информированным, сознательным и однозначным. С 1 сентября 2025 года Федеральный закон №156-ФЗ требует оформлять его отдельно от иных документов, которые человек подписывает или подтверждает. Это правило не означает, что согласие требуется для любой цели: сначала проверяются основания части 1 статьи 6 Закона №152-ФЗ.

Согласие на распространение

Статья 10.1 Закона №152-ФЗ регулирует отдельное согласие на данные, разрешенные для распространения. Оно может потребоваться для открытого отзыва с именем и фото, профиля исполнителя, кейса, фотографии сотрудника или иной публикации. Обычное согласие на обработку не следует автоматически считать разрешением сделать данные общедоступными.

Оферта или иные договорные условия

Статья 435, статья 437 и пункт 1 статьи 438 Гражданского кодекса РФ (ГК РФ) связывают оферту с достаточно определенным предложением и акцептом. Текст должен позволять установить сторону, предмет и существенные условия, а интерфейс - ясно показывать действие, которое означает полное и безоговорочное принятие. Страница с ценой не всегда является офертой, а документ с названием «оферта» не становится ею без нужного содержания.

Пользовательское соглашение

Регулирует аккаунт, цифровые функции, допустимое использование, контент, модерацию, блокировку и прекращение доступа. Оно не обязательно для любой визитки. Если все взаимодействие сводится к простой продаже, применимые правила иногда можно согласованно включить в оферту.

Информация о cookies и внешних технологиях

Объясняет, какие категории технологий используются, зачем, кем и как ими управлять. Универсальную надпись и дизайн баннера нельзя выбирать без правовой оценки конкретных технологий: решение зависит от данных, целей, получателей и момента запуска скриптов.

Сведения о рекомендательных технологиях

Если сервис использует информационную систему, которая на основе сбора, систематизации и анализа предпочтений предоставляет информацию, нужно проверить статью 10.2-2 Закона №149-ФЗ. Владелец ресурса размещает сведения о применении технологии, правилах ее работы, используемых процессах и способах сбора сведений, а также контакт для юридически значимых сообщений.

РКН, локализация и иностранные сервисы

Политика на сайте не заменяет уведомление Роскомнадзора (ч. 2 ст. 18.1 и ст. 22 Закона №152-ФЗ) и не устраняет расхождение с фактическим сбором, хранением и передачей данных. Документ, уведомление и работу систем нужно проверять отдельно.

Общее уведомление Роскомнадзора

По части 1 статьи 22 Закона №152-ФЗ оператор до начала обработки уведомляет Роскомнадзор. Часть 2 содержит исключения, но после изменений закона они узкие и не должны применяться автоматически только потому, что бизнес небольшой (ч. 2 ст. 22 Закона №152-ФЗ). В уведомлении указываются цели, категории субъектов и данных, основания, действия, меры, место базы и иные предусмотренные частью 3 сведения (ч. 3 ст. 22 Закона №152-ФЗ).

Если меняются цели, категории, место базы или другие заявленные сведения, оператор проверяет обязанность сообщить об изменении (ч. 7 ст. 22 Закона №152-ФЗ). Сайт, политика и реестр Роскомнадзора должны одинаково описывать фактическую обработку.

Локализация первичного сбора

Часть 5 статьи 18 Закона №152-ФЗ запрещает при сборе персональных данных граждан России, в том числе через интернет, использовать для записи, систематизации, накопления, хранения, уточнения и извлечения базы за пределами России, кроме предусмотренных законом случаев. С 1 июля 2025 года Федеральный закон №23-ФЗ усилил формулировку: первичный сбор нельзя организовывать через иностранную базу с последующим копированием в Россию.

На практике нужно проверить, куда форма, чат, SDK или платежный виджет записывает данные в первую очередь. Российская CRM не решает проблему, если до нее данные уже попали иностранному сервису.

Трансграничная передача

Части 3-4 статьи 12 Закона №152-ФЗ требуют до начала трансграничной передачи направить отдельное уведомление. До подачи оператор собирает сведения об иностранном получателе, правовом регулировании государства, мерах защиты и условиях прекращения обработки. Это уведомление не заменяет общее уведомление по статье 22 Закона №152-ФЗ.

Для передачи в государства, обеспечивающие адекватную защиту прав субъектов, и в иные государства действуют разные процедурные режимы. Нельзя делать вывод только по стране сервера: нужно установить получателя, сторону договора, способ передачи данных и лиц, которые получают к ним доступ.

Перечислите формы, виджеты, SDK, аналитику, CRM, рассылку, облако и поддержку.
Для каждого сервиса определите данные и момент первой записи.
Определите оператора, цель обработки и лицо, которое обрабатывает данные по поручению оператора.
Установите юридическое лицо иностранного получателя, государство его нахождения и страны, из которых возможен доступ к данным.
Сверьте цель с основанием обработки и текстом политики.
Проверьте общее уведомление РКН, локализацию и отдельное уведомление о трансграничной передаче.
Зафиксируйте, что меняется при отключении сервиса или переносе данных.

Практика: Второй кассационный суд общей юрисдикции в постановлении от 26 декабря 2022 года по делу №16-9987/2022 оставил в силе выводы по сервису Speedtest. Суд учитывал не только регистрационные сведения, но и информацию о сетевой активности, идентификаторы устройств и cookies в совокупности с другими данными сервиса. Это дело подтверждает значимость фактического состава данных и локализации, но не доказывает, что любой cookie любого сайта всегда является персональными данными.

Формы, чат, вакансии, аккаунт и загрузка файлов

Персональные данные появляются не только в поле «телефон». Свободный комментарий, переписка, резюме, история заказов, файл и технический идентификатор могут относиться к определенному или определяемому человеку и поэтому подпадать под определение персональных данных (п. 1 ст. 3 Закона №152-ФЗ). Для каждой точки сбора нужен отдельный ответ на пять вопросов: кто, что, зачем, куда и на какой срок.

Форма заявки

Для первичной цели обратного звонка может быть достаточно имени или удобного обращения и контакта. Если форма просит дату рождения, паспорт или должность, компания должна объяснить, зачем эти данные нужны именно сейчас. Избыточное поле нельзя оправдать тем, что оно может пригодиться позднее: часть 5 статьи 5 Закона №152-ФЗ требует соответствия содержания и объема данных заявленным целям.

Сначала определите назначение формы. Пункт 5 части 1 статьи 6 Закона №152-ФЗ допускает обработку, необходимую для заключения договора по инициативе человека или исполнения договора, поэтому отдельное согласие для такой цели нужно не всегда. Согласие можно выбрать как самостоятельное основание, только если воля человека действительно свободна, цель описана отдельно и оператор готов выполнить требования, связанные с отзывом согласия (ч. 1 и 2 ст. 9 Закона №152-ФЗ). Оно не является автоматически более надежным вариантом: запрос расчета под будущую сделку, обратный звонок и подписка на новости имеют разные цели и могут требовать разных оснований.

Ставить обязательную галочку у любой формы не нужно. Важно письменно определить цель, применимое основание, минимальные поля, срок и дальнейшее использование данных. Если после ответа контакт остается в маркетинговой базе, для этой новой цели требуется отдельная проверка.

Онлайн-чат и мессенджер

В чате человек может сообщить больше, чем просит форма. Владелец проекта должен знать, кто предоставляет виджет, где хранится история, передаются ли вложения за рубеж, может ли оператор поддержки выгрузить переписку и как исполняется запрос об удалении.

Переход в сторонний мессенджер не снимает ответственность за действия самой компании. Если сотрудник просит прислать документ, сведения становятся частью бизнес-процесса. Пользователю не нужен длинный текст перед каждым сообщением, но политика и внутренний порядок должны честно описывать канал.

Вакансии и кадровый резерв

Отклик на вакансию обрабатывается для рассмотрения кандидата. Пункт 5 части 1 статьи 6 Закона №152-ФЗ может применяться к действиям по заключению договора по инициативе человека. Однако для хранения резюме после закрытия вакансии, передачи другим компаниям группы или включения в длительный кадровый резерв нужно отдельно определить цель, основание и срок обработки (ст. 5 и ст. 6 Закона №152-ФЗ).

Объем данных формы должен соответствовать заявленной цели первичного отбора (ч. 5 ст. 5 Закона №152-ФЗ). Особенно внимательно проверяйте необходимость фотографий, сведений о здоровье, семейном положении и документов; сведения о здоровье относятся к специальным категориям персональных данных (ст. 10 Закона №152-ФЗ). До оффера запрашивайте только сведения, необходимые для первичного отбора, если закон или характер работы не требует иного.

Аккаунт и история действий

В личном кабинете рядом хранятся профиль, заказы, платежи, обращения, настройки и журналы. Нужно определить обязательные и необязательные поля, сроки хранения после закрытия аккаунта, восстановление доступа, выгрузку данных и отличие удаления профиля от прекращения договора.

Обещание «удалим все сразу» может быть невыполнимым, если часть сведений продолжает обрабатываться для другой определенной цели и на самостоятельном правовом основании (ст. 5 и ст. 6 Закона №152-ФЗ). Корректнее заранее разделить данные, удаляемые по запросу, и записи, которые на ином основании сохраняются в течение ограниченного срока.

Загрузка файлов

Файл способен содержать паспорт, договор, медицинские сведения, коммерческую тайну или данные третьего лица. До загрузки стоит обозначить допустимый тип материалов и цель, ограничить доступ и срок, предусмотреть удаление ошибочно загруженного файла. Закрытый файл нельзя делать общедоступным только на основании обычного согласия на обработку: распространение персональных данных регулируется отдельно (ст. 10.1 Закона №152-ФЗ).

Для каждой точки ввода проверьте:

Кто определил цель;
Какое лицо названо оператором;
Зачем нужно каждое поле;
Можно ли решить задачу меньшим объемом;
Куда данные записываются первым действием;
Какие подрядчики и сотрудники получают данные;
Что происходит после завершения цели;
Что видит пользователь до отправки;
Какая версия текста и какое событие сохраняются.

Cookies, аналитика, реклама и подрядчики

Под общим названием cookies скрываются технически разные записи: языковая настройка, сессия входа, корзина, идентификатор аналитики, рекламный профиль. Закон №152-ФЗ не называет любой cookie отдельной категорией, поэтому вывод строится по определению персональных данных из пункта 1 статьи 3: можно ли прямо или косвенно отнести сведения к определенному или определяемому человеку.

Позиция 1: идентификатор и события являются персональными данными

Эта позиция обоснованнее, если идентификатор связан с аккаунтом, контактами, устройством, рекламным профилем или позволяет выделить пользователя в сочетании с другими сведениями. Тогда проверяются цель, основание, получатели, политика, локализация и передача.

Консервативное решение - не загружать необязательную аналитику и рекламные пиксели до явного выбора пользователя. Оно уменьшает риск спорной квалификации, но требует технической реализации, а не только баннера.

Позиция 2: конкретная техническая запись не определяет человека

Такой вывод возможен для строго необходимой настройки или краткоживущей технической сессии, которую владелец и подрядчики не могут разумно связать с человеком. Одного названия cookie недостаточно: нужно документировать состав, срок, назначение и отсутствие связи с другими наборами. Слово «обезличенный» здесь не применяется автоматически: юридическое обезличивание требует отдельной проверки способа обработки и возможности обратного соотнесения данных.

При этом поставщик сервиса может располагать дополнительными идентификаторами, которых не видит владелец сайта. Поэтому условия и техническое описание подрядчика проверяются вместе с сетевыми запросами страницы.

Баннер есть, но скрипты уже загрузились

Передача начинается еще до выбора пользователя. Чтобы этого избежать, необязательные инструменты блокируют до его действия, а технически необходимые записи проверяют отдельно. Текст поверх уже начавшейся передачи не отменяет ее.

Политика говорит «третьим лицам не передаем», но работает CRM

Указанное в политике утверждение противоречит фактам. Нужно определить роль получателя, включить в договор применимые условия поручения по части 3 статьи 6 Закона №152-ФЗ и обновить политику. Сам договор с подрядчиком не устраняет избыточный доступ или передачу данных за рубеж.

Аналитика используется для рекламы

Статистика посещений и создание рекламной аудитории являются разными целями. Их нельзя автоматически объединять словом «аналитика». Для рекламы отдельно проверяются согласие, статья 18 Закона №38-ФЗ и настройки рекламной платформы.

Подрядчик меняет сервис или страну хранения

Публичный документ быстро устаревает, если компания не отслеживает изменения у поставщика. В договоре и рабочем реестре полезно указать, при каких изменениях нужен пересмотр, а в политике не обещать неизменную инфраструктуру, которую бизнес не контролирует.

Рекламные сообщения и сервисные уведомления

Часть 1 статьи 18 Закона №38-ФЗ допускает рекламу по сетям электросвязи только при предварительном согласии адресата. Рекламораспространитель должен доказать получение согласия и прекратить сообщения по требованию человека. Если без рекламы обычная заявка или покупка работают самостоятельно, рекламный выбор следует отделить от основной операции, чтобы согласие оставалось свободным и конкретным (ч. 1 ст. 9 Закона №152-ФЗ).

Подтверждение заказа, предупреждение о безопасности и сообщение о состоянии оплаченной услуги не становятся рекламой только из-за канала доставки. Но если сервисное письмо одновременно продвигает другие товары, программы или тарифы, квалификация меняется. Полезно разделить операционные и рекламные шаблоны, цели и списки получателей.

Самостоятельно проверьте четыре факта: кто является отправителем, какой канал используется, что именно получает человек и как он может отказаться. Чтобы подтвердить согласие на рекламу, сохраняйте форму, версию текста, дату, сведения об адресате и последующий отзыв.

Продажа через сайт: B2C, B2B, оплата и чек

Сделка начинается не с файла оферты, а с предложения и действий сторон. Проследите всю последовательность: карточка товара или тарифа, корзина, данные заказа, кнопка, оплата, подтверждение, исполнение, возврат и претензия.

B2C: покупатель является потребителем

Статьи 8-10 Закона о защите прав потребителей и его статья 26.1 требуют до заключения дистанционного договора предоставить необходимую информацию о продавце, товаре или услуге, цене, приобретении, доставке, сроке службы или годности, гарантиях и порядке отказа в применимой части. Оферта удобна для фиксации условий, но права потребителя возникают из закона и не исчезают из-за отсутствия нужного пункта.

В потребительском сценарии нельзя скрывать регулярное списание, платный период после пробного доступа, существенные ограничения услуги или результата либо фактического исполнителя (ст. 8-10 и ст. 16 Закона РФ «О защите прав потребителей»). Кнопка должна соответствовать действию: пользователь понимает, оформляет ли он заявку, заключает договор или сразу оплачивает заказ.

B2B: покупатель действует как бизнес

Закон о защите прав потребителей не применяется к организации (преамбула Закона РФ «О защите прав потребителей»). К гражданину или ИП он применяется только при покупке для личных, семейных, домашних и иных нужд, не связанных с предпринимательской деятельностью (преамбула того же закона). В B2B-договоре стороны могут по своему усмотрению согласовать приемку, ответственность, сроки предъявления претензий и условия договорного отказа, если содержание конкретного условия не предписано законом; свобода договора не отменяет запрет злоупотребления правом (п. 4 ст. 421 и ст. 10 ГК РФ).

Публичная оферта возможна и в B2B. Для сложного проекта с техническим заданием, этапами, правами на результат и индивидуальной ценой чаще подходит отдельный договор или рамочная оферта с заказом, который конкретизирует условия.

Акцепт и доказательства

Пункт 1 статьи 438 ГК РФ требует полного и безоговорочного акцепта. Пункт 3 допускает акцепт действиями по выполнению условий оферты, включая оплату (п. 3 ст. 438 ГК РФ). Но в споре нужно доказать, какую редакцию видел пользователь и какое действие относилось именно к ней.

В деле №А12-34919/2015 суды признали договор заключенным, поскольку заказчик зарегистрировался, направил заявку, отметил согласие с условиями и перечислил деньги. Практический вывод состоит не в том, что галочка решает все, а в том, что суд оценил совокупность идентификации, доступного текста, действия и оплаты.

Подтверждение заказа

После оформления дистанционного заказа покупатель должен получить подтверждение, позволяющее идентифицировать заказ и его условия. Это следует, в частности, из действующих Правил продажи товаров по договору розничной купли-продажи №2463. Сообщение полезно связывать с продавцом, составом, суммой, способом исполнения и номером заказа. Оно не заменяет кассовый чек и не должно противоречить оферте.

Касса и электронный чек

Пункты 1 и 2 статьи 1.2 Закона №54-ФЗ устанавливают общее правило применения контрольно-кассовой техники (ККТ) организациями и ИП при расчетах и регулируют выдачу или направление кассового чека, если закон не предусматривает исключение. При интернет-расчете для направления электронного чека заранее получают телефон или электронную почту либо используют иной предусмотренный законом способ.

Платежное уведомление банка, письмо «заказ оплачен» и кассовый чек выполняют разные функции. Если деньги получает агент или агрегатор, в документах и чеке проверяют реквизиты, признаки агента и лицо, за которое принимается платеж. Для плательщика НПД действует специальный чек приложения «Мой налог», а не обычная ККТ, если соблюдены условия режима.

Что требует отдельной проверки: касса, маркировка, лицензирование и специальные требования к отдельным товарам зависят от деятельности. Эта последовательность помогает провести первичную проверку, но перед запуском платежей нужно учесть именно Ваш товар, статус продавца и способ расчета.

Интернет-магазин: продажа, оплата, возвраты и данные

Интернет-магазину нужен не фиксированный набор документов, а согласованные условия продажи и порядок работы с данными. Минимальная проверка начинается с продавца, ассортимента, покупателя и последовательности оформления заказа.

Сначала определите модель продаж. Если магазин продает гражданам собственные товары, основой будут потребительская дистанционная продажа, данные заказа, касса и возврат. Если покупатели действуют только как бизнес, важнее согласовать заказ, приемку, документы и ответственность. В смешанной модели нужно различать B2C и B2B до акцепта. Если на одном сайте продают независимые партнеры, дополнительно возникает платформенная или агентская модель: одна оферта обычного магазина ее не описывает.

Статья 26.1 Закона о защите прав потребителей регулирует дистанционный способ продажи потребителю, но не заменяет анализ конкретного товара, продавца и момента заключения договора.

С 1 сентября 2026 года начинают действовать новые Правила продажи товаров, утвержденные Постановлением Правительства РФ №657. На дату проверки они еще не применяются. Интернет-магазину перед этой датой нужно повторно проверить сведения о продавце и способах направления претензий, порядок дистанционного заказа и возврата, а также специальные правила для отдельных категорий товаров. Будущие требования нельзя выдавать за уже действующие, но откладывать подготовку до первого спора также не стоит.

Условия продажи

До оформления заказа покупателю должны быть понятны продавец, товар, цена, оплата, доставка, момент заключения договора, подтверждение, отказ и возврат. Оферта является распространенным способом собрать условия, но информация в каталоге, корзине и письме также должна ей соответствовать.

Персональные данные заказа

Имя, телефон, адрес и состав заказа могут быть необходимы для заключения и исполнения договора. Это подтверждает возможность применить пункт 5 части 1 статьи 6 без отдельного согласия для самой покупки (п. 5 ч. 1 ст. 6 Закона №152-ФЗ). Для рекламы, профилирования или длительного хранения сверх этой цели проверяется отдельное основание.

Участники исполнения

Платежный провайдер, служба доставки, CRM, колл-центр и продавец получают разные данные. В политике и договорах нужно определить, где данные передаются самостоятельному получателю, где обрабатываются по поручению и где участник преследует собственную цель.

Отзывы и фотографии

Публикация отзыва с именем, фотографией или профилем может быть распространением персональных данных (ст. 10.1 Закона №152-ФЗ). Отдельно определяются право использовать сам текст и медиа, согласие на публикацию данных, срок и снятие материала (ст. 10.1 Закона №152-ФЗ и ст. 1227 ГК РФ).

Чек и подтверждение

Покупатель получает подтверждение, по которому можно идентифицировать заказ, и кассовый чек, если этого требует выбранный способ расчета. Возврат денег, отмена заказа и корректировка чека должны соответствовать договорным условиям.

Самостоятельная проверка магазина

Сделайте тестовый заказ как новый покупатель. Сохраните страницы до оплаты, письмо, чек, статус доставки и путь возврата. Затем сравните продавца, цену, товар, сроки и ссылки во всех точках.

Если данные расходятся, не начинайте с переписывания одного файла. Зафиксируйте, как должен проходить заказ, исправьте карточку, корзину, порядок оплаты, письмо и внутренний процесс, а затем приведите к ним оферту и документы по данным. Старую редакцию и тестовый заказ сохраните: они помогают установить, что видел покупатель до изменения.

Отдельная проверка нужна для маркируемых, лицензируемых и иных регулируемых товаров, нескольких продавцов, цифрового результата, подписки, индивидуального изготовления и сложной доставки. В этих случаях базовый комплект остается полезной картой, но не дает готового ответа по отраслевой обязанности или конкретному возврату.

SaaS и мобильное приложение: доступ, подписка и данные

В этом разделе под SaaS-проектом понимается сервис, который предоставляет продолжающийся доступ к функциям, а не выполняет одну разовую задачу. Пользователь хранит данные, приглашает участников, подключает интеграции и зависит от доступности сервиса. Поэтому одного описания тарифа недостаточно.

Сначала определите, что именно продает сервис. Лицензия определяет разрешенные способы использования программы (ст. 1235 ГК РФ), услуга - действия или деятельность исполнителя (ст. 779 ГК РФ), абонентская модель - обязанность предоставить исполнение по требованию в пределах периода, а смешанный договор соединяет элементы нескольких договоров (п. 3 ст. 421 ГК РФ). Статья 429.4 ГК РФ регулирует абонентский договор, но название «подписка» само по себе не отвечает, за что взимается плата.

Договорная модель

Определите, что получает пользователь: лицензию, услугу, доступ или смешанный результат. Условия должны согласованно определять тариф, срок, ограничения, оплату, автопродление, изменение цены, прекращение и выгрузку данных.

Аккаунт и участники

Разделите роли владельца рабочего пространства, приглашенных пользователей и плательщика. Для B2B-сервиса компания может быть заказчиком, а сотрудники - пользователями. Их действия, доступ и удаление не должны смешиваться с правами плательщика.

Доступность и изменения

Не нужно обещать абсолютную бесперебойность. Следует описать, как компания сообщает о плановых работах и существенных изменениях функций, оказывает поддержку и прекращает работу продукта. Компания должна заранее определить действия, которые позволят выполнить опубликованный порядок.

Интеграции и данные

Для API, облака, аналитики и внешней модели проверяются получатели, поручение обработки, локализация, трансграничная передача, отключение интеграции и удаление переданных данных. Пользователь должен понимать, какие данные уходят подключенному им сервису и какие - поставщику SaaS.

Прекращение и экспорт

До оплаты стоит определить, как остановить будущие списания, сколько сохраняется доступ, можно ли выгрузить данные и когда они удаляются. Удаление аккаунта не всегда равно немедленному уничтожению всех учетных и договорных записей.

Для приложения действуют те же российские правовые вопросы, что и для сайта: данные, договор, реклама, аккаунт, платежи и доказательства. Системное разрешение устройства показывает технический выбор, но не заменяет анализ цели и основания обработки.

До запуска проверьте четыре основных факта: кто является стороной, что входит в тариф, когда начинается период и есть ли автопродление. Отдельно установите, как останавливаются будущие списания, что происходит с данными после отказа, кто получает данные через интеграции и какая версия условий связывается с оплатой. Для B2C отдельно проверяются информация об услуге, недопустимые односторонние условия и право на отказ; для B2B - полномочия администратора, приемка, SLA и поручение обработки.

Если сервис уже работает, сначала сохраните действующие тарифы, интерфейс и журнал акцепта. Затем выберите целевую модель и меняйте условия только на будущее с понятным уведомлением. Попытка новой редакцией оправдать прежнее списание или прежнюю обработку данных не исправляет прошлое событие.

Отдельная проверка нужна, если сервис работает с несовершеннолетними, медицинскими или финансовыми данными, постоянно передает сведения в иностранное облако, автоматически принимает решения, влияющие на права человека, либо от его доступности зависит работа бизнеса. Здесь нужно проверить применимые нормы, порядок обработки данных и обязательства поставщика.

Платформа и маркетплейс: роли, расчеты и модерация

Платформа соединяет несколько групп, поэтому один текст «для пользователя» может скрыть существенные различия. Сначала определите роли и договоры между участниками, затем готовьте документы.

Для одной типовой операции ответьте: чье предложение видит пользователь, с кем он заключает договор, кто определяет цену, кто принимает деньги, кто исполняет обязательство и кто рассматривает претензию. Если ответы относятся к разным лицам, документы и интерфейс должны показывать это до оплаты. Пункт 1 статьи 1005 ГК РФ различает действия агента от своего имени и от имени принципала; от этого зависит сторона отношений с третьим лицом.

Покупатель или заказчик

Должен понимать, у кого приобретает товар или услугу, кому платит, кто отвечает за исполнение и куда обращаться. Платформа может быть продавцом, агентом, информационным посредником или сочетать роли в разных операциях.

Продавец или исполнитель на платформе

Для него нужны условия допуска, комиссии, расчетов, размещения карточек, качества, документов, возвратов, претензий и прекращения доступа. Платформа не должна обещать покупателю то, что договор с партнером не позволяет исполнить.

Платформа

Определяет правила регистрации, ранжирования, модерации, блокировки, отзывов, споров и использования инфраструктуры. Если она собирает данные для собственных целей и по поручению партнеров, в документах нужно отдельно описать ее роль для каждой цели.

Оплата и исполнение

Проверьте, кто принимает деньги, формирует чек, перечисляет средства партнеру, удерживает комиссию и возвращает деньги. Нельзя считать платежного участника продавцом только из-за его названия в выписке.

Ранжирование и рекомендации

Если выдача персонализируется по предпочтениям, проверяется статья 10.2-2 Закона №149-ФЗ (ст. 10.2-2 Закона №149-ФЗ). Правила не должны раскрывать защищенную технологию целиком, но пользователь получает предусмотренные законом сведения о применении рекомендаций.

Закон №289-ФЗ о платформенной экономике вступает в силу 1 октября 2026 года (Федеральный закон №289-ФЗ). На дату правовой проверки он еще не действует. Проектам, подпадающим под его предмет, нужно заранее проверить статус посреднической цифровой платформы, отношения с партнерами и переходные действия, не описывая будущие обязанности как уже действующие.

Если интерфейс называет платформу посредником, но она сама назначает продавца, меняет цену, принимает решение по возврату или удерживает деньги без ясного основания, одного отказа от ответственности недостаточно. Зафиксируйте операцию, устраните расхождение между договором с партнером и тем, что видит и делает пользователь, отдельно опишите расчеты и порядок работы с претензиями.

Общие правила требуют дополнения, если платформа допускает физлиц-исполнителей, смешивает собственные и партнерские продажи, работает с регулируемыми товарами, пользовательским контентом или существенной зависимостью партнера от блокировки. Для будущих обязанностей по Закону №289-ФЗ нужен повторный контроль непосредственно перед 1 октября 2026 года и после вступления закона в силу.

ИИ-продукт: данные, права и ответственность

Для ИИ-функции не существует одного специального документа. Она меняет содержание пользовательских условий, политики, договоров с поставщиком модели и внутренних решений.

Перед подготовкой документов опишите пять вещей: что пользователь передает модели, кому фактически передаются запросы, сохраняются ли они и используются ли для улучшения, какой результат получает пользователь и какое действие бизнеса может последовать из результата. Эти ответы позволяют отличить обычный помощник от сервиса, который обрабатывает чувствительные данные или влияет на права человека.

Входные данные

Пользователь должен понимать, какие материалы можно загружать, вправе ли он передавать чужие документы, персональные данные и конфиденциальную информацию. Одного запрета недостаточно, если продукт фактически предлагает загрузить такие сведения: нужны технические и организационные меры.

Передача поставщику модели

Определите, получает ли внешний провайдер запросы, файлы, логи и обратную связь, использует ли их для обучения и где обрабатывает. Эти факты влияют на политику, поручение обработки, трансграничную передачу, содержание договора и сведения для пользователя.

Результат и права

Условия должны разумно распределить права на входные материалы и результат, не обещая пользователю право, которого сервис не может предоставить. Отдельно проверяются материалы третьих лиц, товарные знаки и повторное использование результата платформой.

Назначение и проверка результата

Вместо общей фразы об отсутствии ответственности объясните назначение инструмента, известные ограничения и ситуации, где требуется проверка человеком. Оговорка в пользовательских условиях не исправляет интерфейс, который представляет вероятностный результат как подтвержденный факт.

Автоматизированные решения

Часть 1 статьи 16 Закона №152-ФЗ запрещает принимать исключительно на основании автоматизированной обработки решения, порождающие юридические последствия или иным образом затрагивающие права и законные интересы, без письменного согласия либо иного основания федерального закона. Если система решает вопрос о доступе, цене, найме, кредите или иной значимой возможности, требуется отдельная квалификация.

Одного согласия недостаточно для всей процедуры. Части 3-4 статьи 16 Закона №152-ФЗ требуют объяснить порядок принятия решения и возможные юридические последствия, предоставить человеку возможность возразить, разъяснить способ защиты прав и рассмотреть возражение в течение 30 дней. На практике бизнесу нужны понятное уведомление, рабочий канал для возражений, сотрудник с полномочием пересмотреть результат и журнал действий. Добавление формальной фразы в пользовательское соглашение не заменяет эту процедуру.

Обучение на пользовательских материалах

Согласие с условиями сервиса не должно скрывать самостоятельную цель обучения. Нужно проверить право на материалы, персональные данные, возможность отказа, срок и влияние удаления аккаунта. Если данные не используются для обучения, это должно совпадать с настройками провайдера и журналами.

На дату проверки нет одного универсального российского закона, который полностью определяет документы любого ИИ-продукта. Отдельные законопроекты и отраслевые правила меняются, поэтому перед публикацией и запуском проверяется действующий статус норм.

Самостоятельно можно проверить источники входных данных, настройки хранения и обучения у поставщика, перечень запрещенных загрузок, человеческую проверку результата, права на пользовательский контент, порядок жалобы и блокировки, версии условий и фактическое удаление. Если обещание в политике расходится с настройкой API, сначала меняют фактическую схему обработки или текст обещания, а не добавляют еще один дисклеймер.

Статья 16 Закона №152-ФЗ отдельно регулирует исключительно автоматизированные решения, затрагивающие права и законные интересы. Отдельный анализ необходим для найма, кредита, страхования, медицины, образования, биометрии, специальных категорий данных, deepfake и обучения на большом массиве чужих материалов. Общая статья помогает заметить обстоятельства, требующие отдельной проверки, но не заменяет правовую оценку конкретной модели и отрасли.

Аккаунт, пользовательский контент, отзывы и кейсы

Когда человек использует аккаунт или публикует материалы, одних правил продажи недостаточно. Нужно описать не только запреты, но и процедуры, которые можно применить на практике.

Регистрация и безопасность аккаунта

Условия определяют, кто может создать аккаунт, как подтверждается контакт, можно ли передавать доступ, что происходит при компрометации и как восстанавливается учетная запись. Если аккаунт корпоративный, отдельно учитываются полномочия администратора организации и права обычного пользователя.

Блокировка и прекращение доступа

Основания блокировки должны быть связаны с нарушением, безопасностью, оплатой или иным понятным событием. Формула «можем заблокировать в любое время без причины» плохо объясняет услугу и может конфликтовать с оплаченным доступом. Нужно определить последствия для тарифа, данных и пользовательских материалов.

Права на пользовательский контент

Для работы функции сервису может быть достаточно разрешения хранить, технически воспроизводить, преобразовывать формат и показывать материал, а не отчуждения всех прав. Объем права, территория, срок и возможность прекращения должны соответствовать назначению продукта.

Если пользователь публикует чужое произведение, нужны заверение о наличии прав, канал жалобы и процедура ограничения доступа. Одной фразы о полной ответственности пользователя недостаточно, если платформа игнорирует обоснованные обращения.

Закрытый файл и публичная публикация

Загрузка документа в личный кабинет сама по себе не означает разрешение показать его другим: открытая публикация персональных данных и использование охраняемого материала требуют самостоятельного основания (ст. 10.1 Закона №152-ФЗ и ст. 1227 ГК РФ). Для публичного профиля, портфолио или отзыва отдельно проверяются права на материал и распространение персональных данных. Настройка видимости должна соответствовать обещанию в интерфейсе.

Отзывы и кейсы бизнеса

Для текста отзыва важно право на использование самого текста. Для имени, должности, фотографии и сведений о проекте дополнительно проверяются персональные данные, конфиденциальность и согласие на распространение. Удаление публичной карточки не всегда требует уничтожить договорную переписку, но эти сведения должны храниться отдельно.

Сам факт выполнения работы не передает исполнителю право публиковать охраняемые материалы или персональные данные клиента (ст. 1227 ГК РФ и ст. 10.1 Закона №152-ФЗ). Сначала определите, какие факты раскрываются, кому принадлежат изображения и можно ли идентифицировать людей или контрагента. Обобщенный обезличенный пример снижает риск, но обезличивание должно быть фактическим, а не формальным удалением фамилии.

Жалобы и модерация

Пользователю нужен доступный канал, а компании - критерии рассмотрения и техническая возможность ограничить конкретный материал. Подробная внутренняя инструкция не публикуется, но внешний порядок не должен обещать действие, которое никто не выполняет.

Непосредственно связанные внутренние документы

Публичная статья не должна превращаться в руководство по внутреннему делопроизводству. Но необходимые внутренние действия нужно перечислить: без них публичные обещания останутся только текстом в футере.

Локальные акты об обработке данных

Статья 18.1 Закона №152-ФЗ требует мер, включая назначение ответственного за организацию обработки, издание политики и локальных актов, внутренний контроль, оценку вреда и ознакомление работников. Состав зависит от оператора; одна публичная политика не заменяет внутренние документы.

Поручение обработки подрядчику

Часть 3 статьи 6 Закона №152-ФЗ требует определить в договоре с обработчиком перечень данных и операций, цели, конфиденциальность, безопасность, подтверждение мер и сообщение об инцидентах. Обычного пункта «соблюдать закон» недостаточно.

Обращения субъектов

Нужен рабочий порядок для доступа, уточнения, блокирования, уничтожения, отзыва согласия и возражения. В публичном документе указывается понятный канал, а внутри назначается лицо, которое может проверить данные во всех системах.

Сроки и прекращение обработки

Срок обработки персональных данных определяется целью и применимым основанием; после достижения цели обработка прекращается или данные уничтожаются, если иное не предусмотрено законом или договором (ч. 4 и 7 ст. 5 Закона №152-ФЗ). Во внутреннем реестре сопоставляют категории данных, системы и событие, после которого данные удаляются. Доступ должны получать только те лица, которым он действительно необходим.

Инциденты

Часть 3.1 статьи 21 Закона №152-ФЗ предусматривает уведомление Роскомнадзора об инциденте, повлекшем нарушение прав субъектов: первичное сообщение направляется в течение 24 часов, результаты внутреннего расследования - в течение 72 часов. Компания должна заранее назначить контактное лицо, определить способ фиксации инцидента и обеспечить возможность быстро установить затронутые системы и данные.

Реестр версий

Для политики, согласий, оферты и пользовательских условий фиксируются редакция, период действия, точки размещения и связанные изменения продукта. Это не обязательный публичный документ с установленным названием, а практический способ доказать, какой текст действовал.

Редкие случаи, которые меняют обычный ответ

Редкий случай не означает малозначимый. Он вынесен в отдельную вкладку, потому что требует специальной проверки и не должен перегружать описание обычного сайта.

Несовершеннолетние

У Закона №152-ФЗ нет одного универсального правила «с такого возраста ребенок всегда соглашается сам» для всех цифровых сценариев (ст. 9 Закона №152-ФЗ). Нужно учитывать дееспособность по ГК РФ, предмет сделки, возраст, роль законного представителя и характер данных (ст. 26 и ст. 28 ГК РФ).

Если продукт явно предназначен детям, заранее определяются регистрация, подтверждение полномочий представителя, платежи, публикация материалов и обращения. Обычное поле с датой рождения не доказывает возраст, а запрет в правилах не помогает, если дизайн целенаправленно привлекает детей.

Специальные категории данных

Статья 10 Закона №152-ФЗ отдельно регулирует сведения о расовой и национальной принадлежности, политических взглядах, религиозных или философских убеждениях, здоровье и интимной жизни. Их обработка по общему правилу запрещена, кроме перечисленных законом случаев.

Медицинская анкета, описание ограничения здоровья в вакансии или файл с диагнозом требуют отдельной проверки. Не просите такие сведения через обычную форму, если задача решается без них.

Биометрические данные

Статья 11 применяется, когда сведения характеризуют физиологические и биологические особенности и используются для установления личности (ст. 11 Закона №152-ФЗ). Фотография не становится биометрией только по формату файла: важна цель идентификации. Но обычная фотография все равно может быть персональными данными и публикацией.

Образование, медицина, финансы и иные регулируемые отрасли

Общий комплект не учитывает все специальные требования. В сфере образования проверяются лицензирование, сведения об организации и обучающихся; в медицине - медицинская тайна, специальные данные и телемедицинские ограничения; в финансах - специальный статус, идентификация, дистанционные каналы и требования Банка России. Отдельная проверка также нужна для маркированных товаров, алкоголя, связи и других регулируемых сфер.

Как связать документ, интерфейс, систему и действие команды

Требование должно быть понятно пользователю, а его действие - подтверждаться записью. Для каждого существенного действия сопоставьте четыре элемента.

Что сообщается

Цель формы, условия заказа, период подписки, правила публикации, способ прекращения или состав передачи данных.

Где это видно

Форма, экран тарифа, кнопка заказа, настройки аккаунта, карточка загрузки или доступная страница документа. Ссылка должна появиться до действия, а не после него.

Что записывает система

Идентификатор события, дата и время, пользователь или заказ, версия текста, выбранное действие и результат. IP-адрес сам по себе не доказывает волю, но может быть частью совокупности.

Кто исполняет последующее действие

Поддержка прекращает рассылку, бухгалтерия оформляет возврат, продуктовая команда закрывает доступ, ответственный обрабатывает запрос по данным. Одной публикации документа недостаточно, чтобы выполнить обещание.

Набор доказательств для ключевого действия:

Архив редакции документа;
Дата начала и окончания ее действия;
Адрес страницы и контекст формы;
Текст видимого действия;
Журнал события;
Связь с пользователем, аккаунтом или заказом;
Последующее подтверждение, чек или уведомление;
История отзыва, изменения или прекращения.

Снимок страницы показывает интерфейс, но не подтверждает действие определенного человека. Запись в базе показывает событие, но без архивной редакции не доказывает содержание условий. Вместе эти доказательства надежнее.

Четыре коротких кейса ООО «Ромашка»

Заявка и реклама

ООО «Ромашка» собирает телефон для расчета стоимости и сразу добавляет его в рекламную рассылку. Обработка заявки может опираться на действия по заключению договора, а последующая реклама требует самостоятельной цели и применимого согласия (п. 5 ч. 1 ст. 6 Закона №152-ФЗ и ч. 1 ст. 18 Закона №38-ФЗ). Компания отделяет необязательный рекламный выбор, фиксирует его версию и сохраняет возможность отказаться.

Магазин и другой получатель платежа

Товар продает ИП, сайт принадлежит ООО, а деньги принимает агрегатор. В карточке заказа пользователь видит продавца, в оферте описана роль ООО, а подтверждение и чек позволяют понять получателя денег. Роли не скрываются одним брендом.

SaaS и удаление аккаунта

Компания обещала удалить все данные сразу, хотя часть документов об оплате и исполнении может сохраняться для самостоятельной цели на основании закона или договора (ст. 5 и ст. 6 Закона №152-ФЗ). Она меняет формулировку: пользовательские файлы удаляются в установленный срок, а учетные и договорные записи сохраняются на другом основании в течение ограниченного срока.

ИИ и файл клиента

Пользователь загружает договор, который внешний поставщик модели может использовать для улучшения сервиса. ООО «Ромашка» не ограничивается запретом на конфиденциальные файлы: проверяет настройки провайдера, отключает обучение там, где это возможно, описывает передачу и дает пользователю понятный выбор материалов.

Самостоятельная проверка перед публикацией

Проводите проверку в чистом браузере от лица пользователя и отдельно сверяйте внутренние системы. Чек-лист не подтверждает полное соответствие, но выявляет основные противоречия.

Функции

Перечислены формы, чат, вакансии, аккаунт, загрузка, публикация, заказ, подписка и рассылка.
Для каждой функции понятен результат пользователя.
Будущая функция не описана как уже работающая.
Проверены неблагоприятные сценарии: ошибка, отмена, блокировка, отзыв и удаление.
Отдельно отмечены несовершеннолетние, специальные данные и регулируемая отрасль.

Лица и документы

Разделены владелец сайта, оператор, продавец, получатель оплаты и правообладатель.
Реквизиты соответствуют минимальной и специальной обязанности.
Политика, согласия, оферта и пользовательское соглашение не подменяют друг друга.
Для открытых отзывов и профилей проверено распространение данных.
Для рекомендаций и автоматизированных решений проверены отдельные нормы.

Данные

Для каждого поля известны цель и основание.
Известно место первой записи данных.
Проверены CRM, аналитика, реклама, облако, чат и платежные сервисы.
Общее уведомление РКН совпадает с процессом.
Иностранные получатели и трансграничное уведомление проверены отдельно.

Сделка

До заказа понятны сторона, предмет, цена, срок и результат.
B2C и B2B не смешаны без объяснения.
Акцепт связан с доступной редакцией условий.
Подтверждение заказа и чек выполняют свои функции.
Подписку можно прекратить понятным способом, а последствия описаны.

Доказательства и исполнение

Ссылки видны до действия.
Сохраняются редакция и событие.
Пользователь, заказ и версия связаны.
Сотрудник может исполнить возврат, отзыв, удаление или жалобу.
Изменение продукта запускает проверку документов и уведомлений.

Когда нужен комплект, аудит или отдельный документ

Эти форматы решают разные задачи. Выбор зависит не от того, сколько файлов хотелось бы получить, а от того, насколько понятна фактическая работа проекта.

Комплект документов

Подходит, когда основные функции, роли и сервисы уже известны, но несколько публичных документов нужно подготовить согласованно. В результате бизнес получает применимые тексты, согласованные между собой, и подробную консультацию по размещению и обновлению.

Аудит работающего проекта

Нужен, когда формы, платежи, аналитика, CRM, подрядчики и передача данных уже работают, но неизвестно, совпадают ли они с опубликованными документами. Сначала проверяется фактическая последовательность действий и только затем определяется, какие тексты и процессы нужно изменить.

Отдельная услуга

Уместна, когда задача ограничена одним самостоятельным объектом: офертой, пользовательским соглашением, уведомлением, отдельным согласием или проверкой конкретного документа. Если содержание этого объекта зависит от того, как устроен проект и куда передаются данные, без предварительной диагностики узкая услуга может не решить исходную задачу.

Ключевые источники для проверки

Когда полезна помощь с комплектом

Если функции уже работают, но документы, формы и процессы создавались в разное время, мы подготовим комплект документов для сайта или приложения. Изучим доступный проект со стороны пользователя, разделим роли, сопоставим формы, данные, сделку и цифровые функции. В комплект войдут политика обработки персональных данных, необходимые согласия, публичная оферта, а при необходимости - пользовательское соглашение, памятка по размещению документов и одна согласованная редакция после Ваших замечаний.

Мы подробно проконсультируем по размещению, доказательствам и обновлению. Техническое внедрение и отдельные регистрационные действия не входят в комплект, но Вы получите согласованный набор текстов, понятную памятку для команды и ответы по подготовленным документам.

Проверьте, как Вы поняли тему

Квиз проверяет понимание статьи, но не дает юридической оценки проекту. Все ответы и объяснения доступны в исходном HTML. Контакты не собираются.

Частые вопросы

Какие документы нужны сайту без форм и оплаты?

Не всегда нужен полный набор. Разместите сведения о владельце и проверьте специальные требования к деятельности, права на контент, аналитику, карты, встроенные видео и другие технологии. Если данные не собираются и договор не заключается, согласие, оферта и пользовательское соглашение могут не понадобиться.

Нужно ли уведомлять Роскомнадзор небольшому бизнесу?

Обязанность по части 1 статьи 22 Закона №152-ФЗ проверяют до начала обработки; часть 2 устанавливает исключения. Размер бизнеса сам по себе не является универсальным исключением.

Можно ли объединить политику и согласие?

Политика и согласие выполняют разные функции: политика публикуется как описание подхода оператора к обработке, а согласие фиксирует волеизъявление по определенной цели (ч. 2 ст. 18.1 и ч. 1 ст. 9 Закона №152-ФЗ). С 1 сентября 2025 года часть 1 статьи 9 Закона №152-ФЗ требует оформлять согласие отдельно от иных подтверждаемых документов, поэтому при механическом объединении действие пользователя становится неясным.

Нужно ли согласие для оформления заказа?

Не всегда. Для данных, необходимых для заключения и исполнения договора, может применяться пункт 5 части 1 статьи 6 Закона №152-ФЗ. Реклама, профилирование и иные самостоятельные цели требуют отдельной проверки.

Достаточно ли ссылки в футере?

Для общей доступности она полезна, но не доказывает акцепт или согласие. Применимый текст показывается до соответствующего действия, а система связывает событие с действующей редакцией.

Всегда ли нужен cookie-баннер?

Единого формата для любого проекта нет. Сначала устанавливаются технологии, данные, цели, получатели и момент загрузки. После этого выбираются информирование, настройка технически необходимых записей и способ управления необязательными инструментами.

Нужна ли оферта B2B-сайту?

Не обязательно, но она может быть удобна для стандартных услуг или тарифов. Если объем, цена, этапы и права согласуются индивидуально, чаще используется отдельный договор или сочетание рамочных условий и заказа.

Какие документы нужны мобильному приложению?

Базовый ответ тот же, что для сайта: сведения о владельце, данные, договорная модель, аккаунт, платежи, реклама и доказательства. Дополнительно проверяются SDK, разрешения устройства, push-сообщения и сбор данных до регистрации.

Что делать, если домен, продавец и оператор принадлежат разным лицам?

Не скрывать различие. Для каждой цели и действия укажите соответствующую роль, а затем согласуйте политику, оферту, страницу заказа, платеж и чек. Пользователь должен понимать, кому передает данные и с кем заключает договор.

Можно ли взять готовый шаблон?

Шаблон помогает увидеть структуру, но не знает участников, сервисы, цели, тарифы и доказательства проекта. Сверяйте каждое положение с фактическим интерфейсом и процессом, удаляйте неприменимое и добавляйте пропущенные функции.

Ниже собраны первоисточники, которые подтверждают основные выводы статьи. Открывайте не только название закона, но и конкретную статью: требования различаются по функции сайта, цели обработки и модели сделки.

Статья 10 Закона №149-ФЗ - базовые сведения о владельце сайта; статья 10.2-2 - информирование и правила при применении рекомендательных технологий.
Статья 6 Закона №152-ФЗ - основания обработки и поручение подрядчику; статья 9 - требования к согласию.
Статья 12 Закона №152-ФЗ - трансграничная передача; часть 5 статьи 18 - локализация сбора данных граждан России.
Статья 18.1 Закона №152-ФЗ - внутренние меры; часть 3.1 статьи 21 - уведомление об инциденте; статья 22 - уведомление Роскомнадзора об обработке.
Статья 16 Закона №152-ФЗ - решения, основанные исключительно на автоматизированной обработке, объяснение последствий и работа с возражением человека.
Статья 26.1 Закона о защите прав потребителей - дистанционная продажа и отказ потребителя; статья 18 Закона о рекламе - предварительное согласие на рекламу по сетям электросвязи.
Статья 1.2 Закона №54-ФЗ - применение ККТ и направление кассового чека; статья 14 Закона №422-ФЗ - чек плательщика НПД.
Закон №289-ФЗ о платформенной экономике и новые Правила продажи товаров №657 - принятые акты с будущими на дату проверки требованиями. Их статус и дату вступления нужно проверить перед публикацией и повторно после начала действия.

Список намеренно не заменяет правовую проверку конкретного проекта. Он позволяет увидеть, из какой нормы следует каждый основной блок и где проверить актуальную редакцию перед запуском.