Приложение готовится к запуску: команда завершает разработку, подключает аналитику, настраивает регистрацию и платный доступ. Для публикации нужна политика конфиденциальности. Но прежде чем писать документ, важно разобраться, какие данные получает само приложение, что собирают подключённые сервисы и какие сведения разработчик указывает в магазине.
Политика должна соответствовать устройству продукта. Если в документе написано, что данные не передаются третьим лицам, а встроенный сервис аналитики получает сведения об устройствах и действиях пользователей, возникает несоответствие. Одной заменой реквизитов в чужом шаблоне такую задачу не решить.
Юридическая практика «Софист» помогает подготовить политику конфиденциальности, необходимые согласия и уведомления для приложения. Если проекту нужна более широкая работа, готовим пользовательское соглашение и другие документы для запуска, консультируем по оплате и подпискам. Работаем в Казани и дистанционно с разработчиками из других регионов.
Когда стоит заняться документами приложения
Лучше подключить юриста, когда уже понятны основные функции продукта, но ещё можно изменить пользовательские сценарии без существенной переработки. Для начала работы подойдут описание приложения, макеты интерфейса или тестовая версия.
Обратиться за подготовкой или обновлением документов стоит, если:
- вы разрабатываете приложение и готовитесь к первой публикации;
- в продукте есть регистрация, личный кабинет, формы обратной связи или загрузка пользовательских материалов;
- подключены аналитика, реклама, авторизация через сторонние сервисы, уведомления или внешние API;
- планируются подписка, платные функции либо оплата на сайте с предоставлением доступа в приложении;
- приложение использует геолокацию, камеру, микрофон, контакты или другие данные устройства;
- добавляются ИИ-функции, при работе которых сведения могут попадать во внешние сервисы;
- магазин прислал замечания к политике или сведениям об обработке данных;
- действующая политика подготовлена давно и больше не соответствует продукту.
Отсутствие формы с именем и телефоном ещё не означает, что приложение не обрабатывает сведения о пользователях. Нужно учитывать идентификаторы, диагностические данные и работу встроенных сторонних компонентов.
Что требуют App Store и Google Play
Оба магазина требуют политику конфиденциальности. При этом обязанности разработчика включают и раскрытие сведений о данных в соответствующих разделах магазина.
| Что проверяем | App Store | Google Play |
|---|---|---|
| Доступность политики | Ссылка в App Store Connect и доступное размещение внутри приложения | Ссылка в Play Console и ссылка или текст политики внутри приложения |
| Сведения о данных | Информация в разделе App Privacy | Информация в разделе «Безопасность данных» — Data safety |
| Сторонние компоненты | Учитываются практики подключённых SDK и других партнёров | Учитывается обработка данных встроенными сторонними библиотеками и SDK |
| Удаление аккаунта | Если поддерживается создание аккаунта, нужно предусмотреть его удаление внутри приложения | Для приложений, подпадающих под требование об удалении аккаунтов, нужны способы направить запрос из приложения и через внешний веб-ресурс |
Даже если приложение не собирает данные, политика всё равно нужна. Но содержание документа должно описывать именно вашу ситуацию: какие операции происходят на устройстве, передаются ли сведения на сервер и что делают подключённые компоненты.
Мы сопоставляем юридические формулировки с предоставленной информацией о продукте. Если согласована помощь со сведениями для магазина, разбираем соответствующие вопросы вместе с командой. Технический специалист подтверждает фактическое поведение приложения и SDK, юрист помогает корректно отразить его в документах и раскрываемых сведениях.
Правила магазинов меняются и могут зависеть от функций приложения и территории распространения. При работе с конкретным проектом проверяем применимые требования: App Review Guidelines, App Privacy и правила Google Play о данных пользователей.
Почему шаблона политики может оказаться недостаточно
Хорошая политика отвечает на практические вопросы: кто обрабатывает данные, какие именно сведения получает, для чего использует, кому передаёт, сколько хранит и как пользователь может обратиться по поводу их обработки.
Готовый образец может не учитывать важные особенности продукта. Например, приложение работает без регистрации, но использует рекламный SDK. Или пользователь удаляет аккаунт, а связанные с ним сведения остаются у подрядчика. Или сайт принимает оплату, а приложение получает из единого личного кабинета информацию о доступе к подписке.
В этих ситуациях сначала нужно определить порядок работы, а затем описать его в политике и связанных документах. Если обнаруживается проблема в самом процессе, объясняем, какие изменения нужны разработчикам или владельцу продукта.
Также важно различать политику и согласие. Политика раскрывает порядок обработки данных. Согласие применяется там, где для обработки выбрано или требуется соответствующее правовое основание. Оно должно оформляться отдельно от других подтверждаемых пользователем документов и информации. Универсальная отметка «принимаю все условия» не решает все эти задачи.
Что входит в подготовку политики и согласий
Работу начинаем с изучения приложения и сведений от команды. Уточняем владельца продукта, аудиторию, функции, состав данных, подключённые сервисы, размещение серверов и порядок взаимодействия с пользователями.
По согласованной задаче готовим:
- Политику конфиденциальности. Описываем обработку данных с учётом функций приложения, привлечённых сервисов и применимых требований.
- Формы согласий на обработку персональных данных. Определяем, в каких пользовательских сценариях они нужны, и готовим соответствующие тексты.
- Согласие на получение рекламы. Если проект планирует рекламные сообщения, отдельно прорабатываем получение согласия и возможность отказаться от них.
- Необходимые дисклеймеры и уведомления. Учитываем назначение приложения и характер предоставляемой информации. Например, для продукта с ИИ-функциями может понадобиться объяснить ограничения использования сформированных ответов.
- Рекомендации по размещению и применению. Объясняем, где разместить документы, в какой момент показывать уведомления и как организовать подтверждение действий пользователя.
Состав зависит от приложения. Мы не добавляем документы ради количества и не предлагаем один набор для всех проектов. Дисклеймер также не заменяет выполнение обязательных требований и не освобождает владельца продукта от любой ответственности.
На выходе клиент получает документы в редактируемом формате и практические пояснения для команды. Если для применения документов нужно изменить экран регистрации, настройки рассылки или порядок удаления аккаунта, обозначаем соответствующие действия.
Когда лучше заказать комплексную подготовку приложения
Политику конфиденциальности часто заказывают вместе с пользовательским соглашением. Это связанные документы, которые регулируют разные вопросы.
Политика объясняет обработку данных. Пользовательское соглашение определяет условия использования продукта: предоставление доступа, права пользователя, допустимые действия, ограничения и основания прекращения использования. Для платной модели могут потребоваться оферта и условия подписки.
При комплексной подготовке мы рассматриваем эти вопросы вместе. Например, порядок удаления аккаунта должен согласовываться с условиями прекращения доступа, а описание платежей — с фактической моделью оплаты и обработки связанных данных.
В комплексное сопровождение по согласованному составу могут входить:
- пользовательское соглашение, при необходимости — оферта и условия подписки;
- политика конфиденциальности, формы согласий, дисклеймеры и уведомления;
- подготовка и подача необходимых уведомлений в Роскомнадзор;
- помощь с юридической частью сведений об обработке данных для магазинов;
- консультации по оформлению оплаты, продления и отмены подписок, возвратов и предоставления доступа;
- проверка согласованных пользовательских сценариев и рекомендации по их доработке.
Вопрос об уведомлении Роскомнадзора рассматриваем отдельно от публикации политики. Размещение документа в приложении само по себе не выполняет другие обязанности оператора персональных данных.
Оплата на сайте и доступ в приложении
При выборе платёжной модели нужно учитывать ограничения платёжных инструментов, территорию распространения, правила конкретного магазина и то, кто заключает договор с пользователем.
Если проект использует или планирует оплату на сайте с доступом через общий личный кабинет, помогаем оценить юридические условия такой модели. Прорабатываем предоставление доступа, срок подписки, продление, отказ от дальнейших списаний и возвраты. Затем согласуем эти условия с документами и пользовательским интерфейсом.
Допустимость выбранного способа оплаты и переходов из приложения оцениваем для конкретного продукта и рынка. Детали модели обсуждаем индивидуально.
Два формата работы и стоимость
| Формат | Состав и результат | Стоимость |
|---|---|---|
| Политика и согласия для приложения | Изучение предоставленных сведений о продукте, подготовка политики, необходимых согласий и дисклеймеров, рекомендации по размещению и применению | 20 000 рублей за согласованный базовый объём |
| Комплексная юридическая подготовка приложения к запуску | Согласованный комплект документов, включая пользовательское соглашение; необходимые уведомления, консультации по оплате и требованиям магазинов, проверка выбранных сценариев | Рассчитывается индивидуально после знакомства с проектом |
До заключения договора определяем перечень документов, языковые версии, объём проверки, помощь со сведениями для магазинов и порядок доработок. Если приложение предполагает сложную обработку данных или работу на нескольких рынках, предварительно оцениваем соответствующий объём.
Срок подготовки базового комплекта — обычно 3–5 рабочих дней после получения необходимых сведений и согласования задачи. Срок комплексной работы определяем с учётом готовности продукта, состава документов и участия команды в согласовании.
Документы для приложения не охватывают автоматически всю работу компании с персональными данными. Если нужно организовать также кадровые процессы, работу с подрядчиками и внутренние процедуры, подбираем отдельный объём юридического сопровождения по 152-ФЗ.
Как проходит работа с разработчиком
1. Знакомимся с продуктом. Вы присылаете описание, ссылку на приложение, тестовую сборку или макеты. Уточняем стадию разработки, аудиторию, рынки и предполагаемый срок запуска.
2. Собираем сведения о данных и функциях. Обсуждаем регистрацию, подключённые сервисы, серверы, оплату, коммуникации с пользователями и удаление аккаунта. При необходимости подключаем технического специалиста вашей команды.
3. Согласовываем решения и готовим документы. Определяем, какие условия и процессы нужно закрепить, разрабатываем тексты. Обнаруженные вопросы, влияющие на подготовку документов, выносим на обсуждение.
4. Объясняем внедрение. Передаём документы и рекомендации. Команда размещает их и реализует необходимые действия в интерфейсе. Объём повторной проверки и помощи с замечаниями магазина фиксируем в договоре.
Для подготовки документов обычно достаточно описания архитектуры, перечня сервисов, ответов разработчика и демонстрации пользовательских сценариев. Передавать нам исходный код всего приложения или выгружать реальные персональные данные пользователей для такой работы обычно не требуется.
Если приложение уже работает: когда нужен аудит
Если продукт давно запущен, использует несколько внешних сервисов, менял серверы или содержит документы, не соответствующие фактической работе, разумно начать с юридического аудита сайта, сервиса и приложения.
В ходе аудита проверяем обработку персональных данных, вопросы локализации и возможной трансграничной передачи, выявляем нарушения и даём практические рекомендации по устранению. Это помогает понять, достаточно ли обновить документы или нужны изменения в организации обработки данных.
Для проекта на стадии разработки основной задачей обычно становится подготовка юридической основы к запуску. Аудит может быть полезен и до релиза, если ключевые технические решения уже приняты и их нужно проверить. Подход выбираем по состоянию продукта и задаче команды.
Как защитить права на приложение и его название
Отдельная задача запуска — оформление прав на код, интерфейс, дизайн и другие результаты разработки. Важно понимать, какие права компания получила от сотрудников, фрилансеров и студии, какими документами это подтверждается и какие сторонние компоненты использованы в продукте.
В рамках услуг по интеллектуальной собственности помогаем оформить отношения с разработчиками и использование результатов их работы. При необходимости сопровождаем регистрацию программы для ЭВМ в Роспатенте и регистрацию названия или логотипа как товарного знака.
Авторские права на программу возникают в силу её создания. Добровольная регистрация программы и оформление прав от разработчиков решают разные задачи. Товарный знак, в свою очередь, предназначен для охраны обозначения продукта.
Эти услуги согласовываем отдельно от подготовки политики и документов для пользователей.
Почему разработчики обращаются в «Софист»
Юридическая практика «Софист» работает с 2016 года. Сопровождаем ИТ-компании, стартапы и цифровые проекты, работаем с договорами, интеллектуальной собственностью и персональными данными. Это позволяет рассматривать документы приложения вместе с моделью предоставления доступа, монетизацией и работой команды.
Проект ведёт Василий Кустов, юрист. До начала работы согласовываем задачу, ожидаемый результат, стоимость и сроки. Объясняем рекомендации так, чтобы владелец продукта и разработчики понимали, какие действия им нужно выполнить.
Пример практики: данные в ИИ-продукте
В одном из проектов к нам обратился ИИ-стартап, использовавший зарубежный AI-сервис. Мы изучили модель обработки данных, подготовили документы по предварительному обезличиванию, актуализировали политику и связанные локальные документы, дали рекомендации по внедрению выбранного подхода.
Этот пример показывает связь юридической работы с устройством цифрового продукта: содержание политики зависит от того, как обрабатываются данные. Конкретную модель обезличивания и её применимость нужно оценивать отдельно для каждого проекта. Подробнее — в кейсе об обезличивании данных для ИИ-стартапа.
Другие примеры работы представлены в разделе кейсов, сведения о практике и благодарственные письма — на странице «О нас».
Отзывы клиентов
Что закрепляем в договоре
Фиксируем состав документов, объём анализа, сроки, стоимость, порядок согласования и доработок. Согласовываем условия конфиденциальности предоставленных материалов и пределы дальнейшего сопровождения.
Отвечаем за выполнение согласованной юридической работы. Решение о публикации принимает магазин, а фактическое соответствие приложения зависит также от реализации рекомендаций и поведения подключённых компонентов. Поэтому не обещаем одобрение модерации или отсутствие любых претензий независимо от обстоятельств.
Частые вопросы
Нужна ли политика, если приложение не собирает имя и телефон?
Да, правила App Store и Google Play требуют политику и для приложений без сбора таких данных. Дополнительно нужно разобраться с техническими сведениями, аналитикой и SDK: обработка может происходить без отдельной формы ввода.
Можно ли использовать политику с сайта компании?
Иногда можно подготовить единый документ для сайта и приложения. Но сначала нужно сопоставить их функции, данные и сервисы. Политика сайта с формой обратной связи может не описывать обработку данных мобильным приложением.
Можно ли начать работу до завершения разработки?
Да. Мы можем работать по описанию продукта, макетам и сведениям от команды. Перед размещением документы нужно сопоставить с окончательными функциями приложения, особенно если в ходе разработки изменились регистрация, аналитика или модель оплаты.
Вы готовите пользовательское соглашение вместе с политикой?
Да. В комплексной подготовке согласуем условия использования, обработку данных, необходимые согласия и уведомления. Для платных функций дополнительно рассматриваем условия оплаты и подписки.
Поможете, если магазин уже прислал замечания?
Да. Для оценки понадобятся текст замечаний, действующие документы и информация о приложении. После изучения определим, нужны ли правки политики, сведений в магазине или пользовательского сценария. Объём помощи согласуем до начала работы.
Можно ли одной политикой решить вопрос зарубежных серверов и сервисов?
Нет. Описание передачи данных само по себе не подтверждает допустимость выбранной архитектуры. Необходимо отдельно оценить применимые требования к локализации и трансграничной передаче. При необходимости предложим аудит соответствующих процессов.
Нужно ли обновлять документы после публикации?
Да, если меняются функции, цели обработки, состав данных, подключённые сервисы, владелец продукта или применимые требования. При изменении практик обработки нужно также проверить актуальность сведений в магазинах. Регулярные юридические задачи можно включить в согласованный объём сопровождения ИТ-компании.