Как разработчик сервиса ЭДО проверил законность обмена ПДн с банками и застройщиками и зафиксировал правильные правила игры

Клиент — российский разработчик программного обеспечения: сервис электронного документооборота (ЭДО), который встраивается в процессы партнеров и помогает им обмениваться документами с клиентами в цифровом виде. Для таких продуктов характерны две особенности.

Первая — сервис часто работает не сам по себе, а как часть экосистемы: интеграции с банками, застройщиками и другими организациями, где есть свои ИТ‑контуры, роли и юридические модели обработки данных.

Вторая — подписание документов почти всегда затрагивает персональные данные, в документах и метаданных часто присутствуют сведения о физических лицах (например, данные клиентов, сотрудников, представителей контрагентов). Поэтому вопрос «как именно происходит обмен ПДн» быстро выходит за рамки техники и упирается в правовые основания, распределение ролей и корректность договорного оформления.

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

Клиент обратился с практическим вопросом: при предоставлении функционала сервиса происходит обмен персональными данными с партнерами (банками, застройщиками). Требовалось понять, есть ли нарушение в существующем сценарии взаимодействия, и при необходимости — как снизить риски.

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

Отдельная особенность проекта — архитектура системы клиента. В сложных системах один и тот же продуктовый сценарий может включать несколько контуров обработки: веб‑часть, API‑интеграции, очереди сообщений, хранилища, логирование. Юридически это важно, потому что «где и как обрабатываются данные» влияет на выводы о составе участников, основаниях передачи, обязанностях по обеспечению безопасности и объеме договорных условий.

Риск неверной квалификации отношений с партнёрами: «оператор-оператор» vs «поручение обработки».

В обмене данными с банками и застройщиками возможны разные модели.

— Если партнер получает данные для своих целей и сам определяет, что и зачем он делает, это ближе к модели «оператор-оператор». Тогда критичны законные основания передачи и корректное информирование субъектов о том, кому и для чего передаются данные (ст. 6 и ст. 18 152‑ФЗ).

— Если партнёр обрабатывает данные по заданию клиента, в его интересах и без собственных целей, это ближе к «поручению обработки» (п. 3 ст. 6 152‑ФЗ). Тогда ключевой документ — поручение или договор, где должны быть зафиксированы перечень действий с ПДн, цели, обязанность соблюдать конфиденциальность и требования к защите (ст. 6 и ст. 19 152‑ФЗ).

Ошибка в квалификации сама по себе не выглядит «технической», но на практике приводит к тому, что документы не покрывают реальную схему. Это повышает риск претензий по ст. 13.11 КоАП РФ: регулятор оценивает не декларацию, а фактическую модель.

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

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

В экосистемных интеграциях часто появляется цепочка: один партнёр привлекает другого, либо внутри партнёра есть внешние ИТ‑провайдеры. Даже если клиент не управляет всей цепочкой технически, ему важно понимать, на каком основании данные уходят дальше и как это отражено в договорной модели.

С точки зрения 152‑ФЗ это затрагивает принципы законности и минимизации (ст. 5), а также требования к договорному оформлению поручений и обеспечению мер защиты (ст. 6 и ст. 19). Если цепочка не описана, возникает риск неконтролируемого расширения круга лиц, имеющих доступ к ПДн.

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

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

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

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

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

Задача этого этапа — снять неопределенность и описать схему так, чтобы ее можно было сопоставить с требованиями 152‑ФЗ. В подобных проектах критично отделять «обмен документами» от «обмена персональными данными»: юридически значение имеют именно операции с ПДн и цели этих операций.

На основании собранной информации подготовили заключение, в котором:

— описали ключевые риски существующего сценария взаимодействия;

— показали, какие варианты правовой настройки возможны в зависимости от роли партнеров: оператор-оператор или поручение обработки;

— предложили меры митигации, которые снижают регуляторные риски без «ломки» бизнес‑логики сервиса.

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

Работы по сути оформили правила игры для партнерского обмена ПДн.

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

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

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

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

Проект дал клиенту то, что обычно ценнее любых частных правок: определенность.

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

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

В‑третьих, снизились регуляторные риски. В контексте усиления ответственности по ст. 13.11 КоАП РФ устойчивость достигается не количеством документов, а тем, что фактическая схема обмена и ее правовое оформление не расходятся.

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

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

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