Внедрение ИИ и 152-ФЗ: безопасно ли для персональных данных

Да, внедрять ИИ безопасно с точки зрения 152-ФЗ — если выполнены три условия, которые чаще всего упускают именно в ИИ-проектах. Персональные данные граждан РФ хранятся в базах на территории России. Доступ разграничен по ролям на уровне системы, а обращения к данным пишутся в журнал. Порядок обработки закреплён в договоре с подрядчиком.

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

Опасение обычно звучит так: «мы дадим нейросети данные клиентов, и они куда-то утекут». Оно справедливо ровно в одном сценарии — когда сотрудники по своей инициативе копируют выгрузки из CRM в публичный чат-бот, а компания об этом не знает. Это не свойство ИИ как технологии, это отсутствие контура и регламента.

По 152-ФЗ оператором персональных данных является организация, которая определяет цели и состав обработки. Ответственность лежит на компании, а не на сотруднике, который «просто попробовал удобный сервис». Поэтому вопрос «безопасно ли» на практике превращается в другой: где проходит контур обработки, кто в нём участвует и что происходит с данными на каждом шаге. Отвечать на него нужно до внедрения, а не после.

Оговорка, которую честнее сделать сразу: это инженерный и организационный разбор, а не юридическая консультация. Мы описываем механизмы, которые обычно требуются в проектах с персональными данными, — техническую часть и то, что фиксируется на бумаге. Официальные материалы по 152-ФЗ публикует Роскомнадзор на pd.rkn.gov.ru, а правовую оценку конкретно вашей обработки лучше получить у юриста.

Требование локализации в 152-ФЗ формулируется так: сбор персональных данных граждан РФ ведётся с использованием баз данных, расположенных на территории России. Для ИИ-проекта это означает не строчку «сервер в РФ» на титульном слайде, а конкретный ответ по каждому месту, где текст с персональными данными может осесть.

Таких мест больше, чем кажется. Основная база очевидна. Но у ИИ-контура есть собственные хранилища: поисковый индекс с фрагментами документов, кэш ответов, очереди сообщений, журналы приложения, резервные копии, системы мониторинга. Если хотя бы одно из них развернуто «где придётся», аккуратность остальной схемы теряет смысл — копия данных всё равно оказалась вне контура.

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

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

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

Правильная последовательность выглядит так: сотрудник задаёт вопрос, система определяет его роль и права, в выборку попадают только разрешённые записи и фрагменты, и уже по ним модель формулирует ответ. Модель не «решает не показывать» — она физически не получает того, что человеку не положено видеть. Тот же принцип мы применяем в корпоративном AI-ассистенте: права проверяются на этапе поиска, до обращения к модели.

Второй слой нужен всегда, когда ИИ обращается к боевой базе, — даже если сценарий чисто читающий. Работает принцип «модель предлагает, валидатор решает»: запрос, который сформулировала модель, не уходит в базу напрямую, а проходит независимую проверку до выполнения. Именно валидатор и делает сценарий действительно read-only — пропускает только безопасное чтение из разрешённых таблиц и отсекает обращения к лишним данным и попытки подменить смысл запроса через формулировку вопроса. Наш собственный BI-агент — сейчас это демонстрационный контур на синтетических данных — читает данные и не меняет их, и всё равно устроен с такой проверкой.

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

Технически изоляцию надёжнее делать средствами СУБД, а не условиями в коде. В нашей медицинской информационной системе разделение данных разных организаций сделано через PostgreSQL RLS — row-level security на уровне самой базы. Разница принципиальная: забытый WHERE в одном запросе открывает чужие данные, а правило на уровне СУБД действует для всех запросов сразу, включая те, что напишут через год.

Если персональные данные обрабатывает не сама компания, а подрядчик или сторонний сервис, порядок обработки и требования к защите закрепляются в договоре — это поручение обработки. Ключевой момент: оператором остаётся ваша компания. Ответственность перед человеком, чьи данные обрабатываются, не переезжает к исполнителю вместе с задачей.

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

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

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

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

Наш опыт здесь — собственная медицинская информационная система. Мы разобрали работающий аналог: 1613 таблиц базы и 1029 роботов, и собрали на этой основе техническое задание воспроизведения на 1619 требований. Контур 152-ФЗ заложен в архитектуру с первого дня: согласия, аудит доступа, сроки хранения персональных данных пациентов. Изоляция данных разных организаций сделана через PostgreSQL RLS, то есть на уровне СУБД, а не проверкой в коде приложения.

Честно про статус: МИС — это MVP, рабочий прототип, а не коробочный релиз, который можно завтра развернуть в клинике. Мы называем это прямо, потому что разница между «мы такое проектировали и написали» и «у нас есть готовая коробка» существенная. Полезен здесь не сам продукт, а перенос подхода: изоляция на уровне базы, аудит доступа как часть системы, сроки хранения — заданное свойство, а не ручная процедура.

Если вы стоите перед выбором между обычной CRM и медицинской системой, есть отдельная статья журнала «CRM для клиники и МИС: что выбрать под 152-ФЗ» — там про то, где заканчиваются возможности универсальной CRM и почему часть медицинских сценариев в неё не укладывается. Отраслевые системы такого рода мы и делаем в рамках услуги «Отраслевые системы»: медицина, требования 152-ФЗ, работа нескольких организаций в одной системе.

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

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

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

Что посмотреть на сайте. Страница «Отраслевые системы» — про разработку систем под отрасль, где коробочных решений не хватает, с требованиями 152-ФЗ в архитектуре: согласия, журнал доступа, разграничение прав, хранение данных на серверах в РФ. Страница «Корпоративный AI-ассистент» — если задача в том, чтобы сотрудники получали ответы по внутренним документам, а не искали их по чатам. Страница «AI-стратегия и обучение» — если пока непонятно, с какой задачи вообще начинать.

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