Кодите или шкодите?
Рынок цифровых продуктов переживает расцвет.
Но стоит присмотреться — и почти из каждого начинают торчать персональные данные.
Вроде бы какая проблема? Уведомили Роскомнадзор — и поехали.
Когда доктор предложил мне создать цифровой продукт, одной из первых мыслей было: можно ли исключить из него персональные данные? Сведения о здоровье относятся к специальной категории и требуют особого режима обработки.
Не все продукты нужно устраивать именно так. Но модель работы с данными следует выбрать до того, как написан код.
«Разработчик» — профессия, а не роль в обработке персональных данных. Если вы только создали и передали программу без доступа к рабочим данным, сам факт разработки ещё не делает вас оператором.
Но если эксплуатируете сервис, храните сведения, видите их при сопровождении, подключаете внешние системы или используете данные для собственных целей, роль придётся определить.
Вы сами устанавливаете цели, состав данных и действия с ними? Или действуете по поручению оператора?
Назвать себя агентом, платформой или техническим посредником недостаточно. Важно, что вы делаете на самом деле.
У обработки должна быть конкретная, заранее определённая и законная цель. А сведений — ровно столько, сколько необходимо для её достижения.
Поэтому каждое поле должно выдерживать простой вопрос: что продукт не сможет сделать без него?
Ответ «вдруг пригодится для будущей аналитики» не подходит.
Определив цель и состав данных, можно проектировать их жизненный цикл:
источник → получение → использование → хранение → передача → прекращение обработки → уничтожение.
Отсюда следуют продуктовые решения: кто получает доступ, какие внешние сервисы подключены, где находятся базы и что происходит после достижения цели.
И только когда ответы встроены в продукт, их можно изложить в политике оператора: кто, что, зачем обрабатывает, кому передаёт и когда уничтожает.
Если порядок обратный, документы начинают описывать не спроектированный процесс, а желаемую версию реальности.
Политику можно скопировать у кого-то и положить на сайт. Согласие — поставить под формой регистрации. Но они не уберут лишние поля, не ограничат доступ, не изменят интеграции и не остановят передачу данных во внешний AI-сервис.
Бумажный пластырь архитектурный перелом не сращивает.
А последствия достанутся не только оператору.
Персональные данные — любая информация, прямо или косвенно относящаяся к определённому человеку. Иногда достаточно номера паспорта, но чаще человека определяет сочетание сведений.
Имя. Телефон. Адрес. Геолокация. Фотография. Сведения о здоровье. История покупок.
Вместе они образуют цифровой профиль, способный повлиять не только на частную жизнь, но и на деньги, репутацию и оценку финансовой состоятельности.
Мы боимся кредита от нашего имени и устанавливаем самозапреты. А затем отправляем фотографии паспортов в мессенджерах и загружаем документы в неизвестные формы, не спрашивая, кто находится на другой стороне, зачем ему эти сведения, кому они будут переданы и когда уничтожены.
Проверить уничтожение данных пользователь не сможет. Но из Правил он хотя бы должен понять, кому их передаёт и какие границы установил оператор.
При оценке двух разрабатываемых продуктов я попыталась восстановить эту модель по опубликованной информации.
Не смогла.
Осталось непонятно, кто, какие данные, зачем и по какой схеме обрабатывает.
А затем увидела сообщение о практически готовом продукте, к которому осталось «прикрутить 152-ФЗ».
Оно и заставило написать этот пост.
Если правовую модель данных осталось добавить после разработки, насколько готов сам продукт?
Создатели цифровых продуктов, когда вы проектируете работу с персональными данными — до разработки или после?
А вы читаете Правила перед тем, как передать сервису сведения о себе?
