Безопасность данных при работе с нейросетями: 152-ФЗ, утечки, политика для сотрудников

Светлана Костылева · 22 июля 2026 г.

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

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

Три реальных риска

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

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

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

Что требует 152-ФЗ

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

На практике это означает четыре вещи:

• Основание обработки. Согласие субъекта или другое законное основание, зафиксированное документально.
• Цель и минимизация. В обработку уходит только то, что нужно для задачи. Полная выгрузка базы «на всякий случай» — типовое нарушение.
• Разграничение доступа и журналирование. Видно, кто и когда обращался к данным.
• Локализация. Персональные данные россиян должны храниться в базах на территории России.

Отдельная тема — уведомление Роскомнадзора и внутренние документы оператора. Это организационная часть, она решается юристом, а не подрядчиком по разработке.

Облачные модели против локальных

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

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

Российские сервисы (GigaChat, YandexGPT) — компромисс: данные остаются в российской юрисдикции, а порог входа ниже, чем у локального развёртывания.

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

Политика использования ИИ: минимальный чек-лист

Документ на одну страницу, который снимает большую часть рисков. Что в нём должно быть:

• Список разрешённых сервисов. Всё остальное — запрещено по умолчанию.
• Что нельзя отправлять никогда. Персональные данные клиентов и сотрудников, договоры, финансовые показатели, учётные данные, медицинская информация.
• Что можно. Обезличенные и публичные тексты, шаблоны, черновики без конкретики.
• Правило обезличивания. Имена, телефоны и номера договоров заменяются на плейсхолдеры до отправки.
• Проверка результата. Ответ модели — черновик, а не готовый документ. Ответственность за отправленное клиенту остаётся на сотруднике.
• Кто отвечает на вопросы. Конкретный человек, к которому идут с «а можно ли вот это».

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

Как это решается в проектах

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

Тот же подход мы применяем к собственным продуктам: «Умный цикл» работает с данными 1С, CRM и медицинских систем, поэтому требования 152-ФЗ там учтены в архитектуре.

Что спросить у подрядчика до начала работ

Пять вопросов, ответы на которые стоит получить письменно.

• Где физически хранятся данные и в какой юрисдикции находится сервер.
• Какие данные покидают наш контур и на каком основании.
• Как разграничен доступ и ведётся ли журнал обращений к данным.
• Что происходит с данными после завершения проекта: удаляются, передаются, остаются у подрядчика.
• Подписывается ли NDA до передачи данных, а не после.

Отсутствие внятного ответа на любой из них — достаточная причина не передавать данные до выяснения.

Если инцидент всё-таки случился

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

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

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