Когда персональные данные становятся управленческим риском
Где лежат персональные данные, никто точно не знает
Мы привыкли обсуждать персональные данные как нечто «юридическое»: согласия, политики, ответственные лица. Формально — контур есть, документы подписаны, роли назначены. Но если смотреть со стороны ИT, быстро выясняется неприятное: реальные персональные данные живут совсем не там, где их описали на схемах.
Достаточно задать простой вопрос: сотрудники вообще понимают, что такое персональные данные? На практике связка «ФИО + телефон + почта + должность» часто не воспринимается как что-то чувствительное. Это «просто контакты»: в CRM, в Excel, в RACI-матрице, в переписке. Именно с этого момента данные начинают расползаться.
Копии появляются быстрее документов
Дальше — эффект масштаба. Классический контур ПДн в документах обычно ограничен несколькими системами: CRM, HR, иногда биллинг. В реальности же данные копируются и оседают в десятках мест: выгрузки для маркетинга, Excel-файлы в общих папках, вложения в почте, тестовые базы, демостенды, резервные копии. Каждая такая копия — это уже отдельная точка обработки, про которую никто не подумал.
Причина проста и системна:
юристы описывают процессы, о которых им рассказали; ИТ учитывает инфраструктуру, но не всегда понимает, что именно считать ПД; бизнес ускоряет запуск и обходит «лишние» ограничения.
В результате возникает параллельная реальность. В документах — аккуратная схема потоков данных. В инфраструктуре — десятки неучтенных маршрутов. Особенно наглядно это проявляется в маркетинге и операционных задачах.
Типичный пример — новогодние подарки клиентам. Менеджеры собирают ФИО, адреса и телефоны в общую таблицу. Таблица лежит в облачной папке с широким доступом. Затем маркетинг выгружает файл и передает его подрядчику для доставки. Формально — полезная бизнес-активность. Фактически — новый контур обработки ПДн, который нигде не описан: ни основания, ни сроков хранения, ни контроля доступа.
Другой кейс — розыгрыши и акции. Чтобы выбрать победителей, сотрудники выгружают данные из CRM, сортируют их в Excel, пересылают друг другу. Возникает цепочка копий: локальные файлы, почтовые вложения, временные списки. Где в этот момент находятся данные? Кто имеет к ним доступ? Ответа обычно нет.
Чем технологичнее компания, тем сложнее ситуация. Появляются BI-системы, где данные агрегируются, тестовые среды с копиями продакшн-баз, логи с пользовательскими действиями, записи звонков и экранов, обучающие датасеты для аналитики и AI. Эти системы необходимы бизнесу — но именно они чаще всего выпадают из поля зрения при учете ПДн.
Отдельная категория — «невидимые» хранилища: резервные копии, старые архивы, забытые базы, личные выгрузки сотрудников. Формально они не участвуют в процессе. Фактически — продолжают хранить персональные данные годами.
Инвентаризация должна видеть движение данных
Поэтому главный вопрос уже не в том, есть ли у компании учет ПДн. Вопрос в другом: насколько он отличается от реальности.
Начинать инвентаризацию с «переписи всех систем» — заведомо проигрышная стратегия. Это превращается в бесконечный аудит, который устаревает быстрее, чем завершается. Эффективно работает схема «объяснить, что есть ПДн — создать систему, в которую оунеры процессов приходят, если у них есть подозрение, что в их системах идет обработка, — приучить их обновлять информацию при изменении процессов». Это даст актуальную картину движения данных: где они впервые появляются, кто и зачем их копирует, какие промежуточные формы создаются по пути.
Потому что персональные данные в компании — это не статический актив. Это поток. И пока этот поток не виден целиком, любой «контур защиты» остается лишь аккуратно оформленной «бумагой».
ИИ просит данные, но отвечать будет компания
Игорь Бедеров, председатель совета по противодействию технологическим правонарушениям КС НСБ России
ИИ-сервисы быстро стали рабочим инструментом для анализа документов, переписки, клиентских обращений и внутренних баз. Но вместе с этим у компаний появился новый риск: персональные данные уходят в сценарии, которые не всегда описаны, согласованы и контролируются. Даже если эксперимент выглядит небольшим, для компании он может означать появление нового контура обработки ПДн.
Чаще всего «просто для эксперимента» в публичные и внутренние сервисы отправляют вовсе не тестовые массивы, а живые клиентские базы, CRM-выгрузки, переписку с контрагентами, сканы договоров, резюме кандидатов и финансовые документы. Отдельная категория — история взаимодействия с заказчиками из тикет-систем, когда сотрудник просит модель «перескажи суть претензии» и заодно отправляет туда полные паспортные данные, адреса и контактные номера, которые были в теле заявки. Популярный сценарий — прогнать через языковую модель массив должностных инструкций или служебных записок, даже не вычистив оттуда фамилии, оклады и оценки эффективности.
Новый ассистент, новый контур ПДн
Корпоративный ассистент, будь то чат-бот на базе внутренней LLM или RAG-система, почти никогда не является просто ИТ-проектом. Он автоматически становится самостоятельным контуром обработки персональных данных, потому что накапливает, индексирует, векторизует и, как правило, сохраняет запросы пользователей вместе с контекстом.
Даже если модель развернута на собственном сервере, данные проходят через новый набор компонентов: шина запросов, база векторных представлений, кэш, логи доступа. И на каждом из этих слоев персональные данные могут быть извлечены, неправомерно агрегированы или случайно раскрыты.
ИИ «видит» все, что ему передают, и помнит дольше, чем хотелось бы. Модель нельзя просто попросить «забыть», как человека, а техническая реализация права на удаление информации в генеративных архитектурах до сих пор остается сложной задачей.
С точки зрения 152-ФЗ это означает, что компании нужно заново определить цели обработки, назначить ответственных, провести оценку воздействия и, возможно, получить новые согласия. Не сделав этого, бизнес получает полноценный серый контур обработки, который, как правило, отлично виден при расследовании любого инцидента.
Когда поиск открывает лишнее
Ситуация с системами retrieval-augmented generation, которые подтягивают данные из внутренних источников, особенно показательна. Основная угроза здесь — наследование прав доступа без их проверки. Документы могут храниться в разных системах с разными грифами и политиками, но на этапе индексации эта разница часто стирается.
Когда аналитик задает вопрос модели, она может подмешать в ответ фрагмент из файла, к которому у этого конкретного пользователя в исходной системе доступа не было. Формально это инцидент конфиденциальности. Фактически — «эскалация привилегий» через поисковый контур, которую классические средства защиты пропускают.
Более того, если в индексе остались персональные данные, а модель обучена генерировать плавные ответы, она может начать пересказывать содержимое смежных документов, раскрывая то, что не предназначалось для общего обзора.
На реальных данных без правил не экспериментируют
До запуска любого ИИ-пилота, в котором предполагается использование реальных персональных данных, я бы ввел несколько жестких ограничений. Первое — запрет на загрузку производственных баз «как есть». Пилот обязан работать на синтетических или строго анонимизированных наборах, причем анонимизация должна проходить проверку на устойчивость к деанонимизации, а не просто замену имени на звездочки.
Второе — категорический запрет на передачу в модель специальных категорий персональных данных, включая сведения о здоровье, биометрию, политические взгляды, а также чувствительной финансовой информации без заключения юридической службы и выделенного контура обработки.
Третье — запрет на подключение модели к внешним API и облачным сервисам до тех пор, пока не будет проведена полноценная модель угроз и не настроено логирование всех запросов.
Четвертое — обязанность отключать сохранение истории и кэширование промтов для учетных записей, которые работают с реальными данными, если это технически возможно.
Пятое — временный мораторий на использование свободных корпоративных версий ИИ-ассистентов до тех пор, пока не проведено обучение сотрудников.
Для бизнеса такая «бытовая» передача данных в ИИ-сервисы уже сейчас оборачивается репутационными потерями и риском оборотных штрафов, а с учетом трансграничного характера многих моделей — еще и претензиями зарубежных регуляторов. Для граждан это означает, что их данные начинают циркулировать в контурах, о которых они никогда не получали уведомления, и могут всплыть в абсолютно неожиданном контексте. Для государства — новый виток теневого профилирования, где дата-сеты, сформированные в корпоративных ИИ-системах, становятся товаром.
Согласие есть, но риск остался, или когда шаблоны не работают
Евгений Царев, управляющий RTM Group
Для многих руководителей и ИТ-директоров комплаенс в сфере персональных данных (ПДн) — что-то вроде оберега. Повесили на сайт политику конфиденциальности, внедрили галочку «Согласен на обработку», собрали подписи с сотрудников — и можно спать спокойно. Знакомая ситуация? А сейчас расскажем, почему оберег не всегда работает.
Проблемы с Роскомнадзором и судами возникают не потому, что нет бумажки. Они случаются, если компания собирает тонны лишней информации, путает цели ее использования или годами не обновляет документы. Здесь разберем главные иллюзии безопасности и «красные флаги», о которых важно помнить операторам ПДн.
Иллюзия 1. Возьмем согласие на всякий случай
Бизнес любит запасаться бумажками, а в сфере ПДн часто исходит из принципа «чем больше согласий мы соберем, тем безопаснее». Это серьезная ошибка. Согласно ст. 6 152-ФЗ, согласие нужно только тогда, когда иные основания неприменимы для данной цели.
Что это означает на практике? В качестве примера возьмем оформление командировки. Организация проезда и проживания — это прямая обязанность работодателя по Трудовому кодексу (ст. 168 ТК РФ). Данные передаются в рамках исполнения договора. Но кадры упорно берут с сотрудника отдельное согласие «на всякий случай». В итоге лишняя бумага из средства защиты превращается в повод для штрафа за некорректно выбранное правовое основание.
Иллюзия 2. Если есть согласие, лучше собрать максимум данных
Даже абсолютно добровольное согласие не дает права нарушать принцип минимизации данных. Если для покупки авиабилета сотруднику нужны только ФИО и паспорт, а в кадровой анкете «на всякий» требуют СНИЛС, ИНН, контакты супруга, знак зодиака и размер одежды для будущего мерча — нарушается закон. Обработка избыточных данных нелегальна по умолчанию, подпись человека ее не легализует.
Иллюзия 3. Одно согласие работает для всех
То же самое касается передачи данных третьим лицам. Отель или транспортная компания не начнут законно обрабатывать данные вашего сотрудника только потому, что он подписал вам согласие. Между вашей компанией и контрагентом должен быть договор поручения обработки. Без него вы автоматически становитесь виновными в незаконном распространении ПДн.
Шаблонные документы по ПДн, скачанные из Интернета или составленные юристом общего профиля пять лет назад, не работают. Реальная безопасность — это прозрачная архитектура данных, жесткая минимизация сбора и четкие договоры с теми, кому вы эти данные доверяете.
Даже если все настроено и работает отлично, периодически стоит проводить проверку. Чтобы понять, что документы устарели и не соответствуют реальности, нужно искать конкретные «красные флаги». Ниже предлагаем рабочий чек-лист. Эта таблица поможет провести быструю проверку. Утвердительный ответ на любой из вопросов — сигнал того, что имеется нарушение, которое необходимо как можно скорее устранить.
ПДн в госсекторе. Ответственность на стыке систем
В условиях обмена информации между бизнес-структурами граница ответственности видна почти физически. Есть компания-оператор, есть ее периметр, есть служба, которая этот периметр охраняет. Всю информацию собрали для понятной цели, положили в свою систему, открыли доступ своим сотрудникам — и когда что-то идет не так, понятно, с кого спрашивать.
Когда говорим о государственном секторе, эта ясность исчезает, и исчезает она по объективной причине: здесь персональные данные гражданина почти никогда не живут внутри одной системы и одного ведомства благодаря архитектуре ЕПГУ.
Госуслуга как маршрут данных
Если речь заходит о ЕПГУ, то сразу считаем, что типовая услуга — это маршрут. Заявление уходит с портала в ведомственную ГИС, по дороге через СМЭВ обращается к базе смежного органа за проверкой сведений, личность подтверждается в ЕСИА, документы принимает МФЦ, а инфраструктуру под всем этим сопровождает подрядчик. На каждом участке — свой режим обработки, свой администратор, своя нормативная рамка. И ключевой риск возникает не там, где данные обрабатываются, а там, где они передаются от одного участника к другому.
Закон описывает конструкцию ясно: по части 3 статьи 6 152-ФЗ оператор вправе поручить обработку другому лицу, и тогда по части 5 той же статьи перед гражданином за действия обработчика отвечает оператор, а обработчик отвечает уже перед оператором. На бумаге стройно. На стыке систем — рассыпается. Ведомство-источник считает, что отвечает только за корректность выгрузки. Получатель полагает, что раз данные пришли по регламенту, ответственность осталась на источнике. Подрядчик уверен, что обслуживает инфраструктуру, а не содержание баз. МФЦ принимает обращение, но дальнейшую судьбу сведений не контролирует. В результате каждый отвечает за свой фрагмент — а за сквозной маршрут не отвечает никто.
Роли меняются быстрее договоров
В межведомственном процессе роли подвижны: одно и то же ведомство в одной цепочке — оператор, в другой — обработчик по поручению, в третьей — оператор публичного сервиса. Подрядчик технически видит данные, но юридически оформлен как лицо, действующее по поручению, — и качество этого поручения определяет все. А часть 3 статьи 6 требует, чтобы в поручении были явно зафиксированы перечень операций, цели, обязанность конфиденциальности и требования к защите по статье 19. На практике именно эти формулировки часто прописаны общо — и тогда зона ответственности обработчика юридически размыта именно в тот момент, когда она нужна.
Чтобы мы все забыли проблему работы с ПДн, уверен, что надо грамотно проектировать системы. А начать просто с обычного правила — перед любой работой будь добр спроектировать систему и описать модели угроз к ней. Управляемость на стыках не достигается реакцией постфактум. Она проектируется. Для госсектора это означает несколько обязательных элементов.
Первое — карта движения данных: где сведения возникают, через какие ГИС и интеграции проходят, где задерживаются, где покидают периметр. Без этой карты любое распределение ответственности — декларация.
Второе — явная фиксация ролей по каждому потоку: кто оператор, кто обработчик, кто отвечает за актуальность, кто за корректность обмена. И это не разовое описание, а поддерживаемая в актуальном состоянии модель.
Третье — управление доступами как сквозной процесс, а не набор настроек внутри каждой системы по отдельности, с обязательным учетом подрядчиков и сервисных учетных записей, про которые забывают чаще всего.
Четвертое — журналирование на каждом узле обмена. При разборе инцидента это разница между восстановленным маршрутом данных и спором о том, на чьей стороне произошел сбой. Для государственных информационных систем это не пожелание: аттестация ИСПДн обязательна, а регистрация событий — часть доказательной базы.
Пятое — согласованный между участниками порядок реагирования. Закон отводит оператору 24 часа на уведомление Роскомнадзора об инциденте — и в этот срок не должно выясняться, кто кого извещает и кто координирует расследование, когда в процессе заняты сразу несколько ведомств.
Сначала проект, потом обмен данными
Радует, что теперь у всех нас есть не только «пряник», но и реальный «кнут». После вступления в силу поправок ФЗ № 420-ФЗ ответственность по статье 13.11 КоАП измеряется уже не десятками тысяч рублей, а миллионами, а при повторных утечках — оборотными штрафами до 3% годовой выручки. И платит по общему правилу оператор — независимо от того, на чьем именно участке маршрута данные утекли.
Поэтому вывод, к которому я прихожу и повторяю при каждом удобном случае, простой. Нам надо заимствовать принципы работы строителей: сначала проект, потом монтаж и контроль на всех этапах реализации. Когда у тебя все описано, то все поддается правилу: «Защитить можно только то, чье движение ты видишь и чьих ответственных знаешь по имени — до того, как что-то пошло не так, а не после».