Обучение нейросетей и закон в 2026 в РФ звучит как головная боль, а на практике превращается в рабочую схему: обезличили персональные данные, проверили по 152-ФЗ, спокойно отправили в облако и обучили модель. Я покажу, как это сделать без истерик, штрафов и бессонных ночей.
Время чтения: 12-14 минут
В начале 2026 я поймала себя на том, что обсуждаю одно и то же с разными клиентами: «Марина, а можно скормить нейросети клиентские базы, если мы соблюдаем 152-ФЗ?» Кофе остывает, в переписке летает слово «штраф», а по факту людям нужно не расплывчатое «можно-нельзя», а понятная схема, как обучать нейросети безопасно.
По методике white-data PROMAREN мы проверяем не только модели, но и путь данных: кто их собирал, на каком основании, как обезличивали и куда отправляли — в GigaChat, в Yandex Cloud или вообще в зарубежное облако. Тут я расскажу тот же путь, только без внутренних чек-листов, а человеческим языком: где закон реально кусается, а где его можно приручить.
Что такое 152-ФЗ, если смотреть глазами нейросетей
Три из пяти проектов, куда меня зовут «подружить» обучение нейросетей и закон, спотыкаются не о модели, а о том, что такое персональные данные и где их границы. 152-ФЗ — это не про запреты ради запретов, а про условия, при которых данные можно безопасно использовать для обучения.
Если совсем приземлить: 152-ФЗ — это закон «О персональных данных», который регулирует любую обработку информации о человеке, от ФИО и телефона до e-mail и IP-адреса. Для нейросетей это означает, что все, что вы скармливаете модели и где есть следы конкретного человека, попадает под этот закон и тянет за собой согласия, меры защиты и отчётность.
Что именно считается персональными данными для нейросетей
По состоянию на начало 2026 под персональными данными для обучения моделей попадает гораздо больше, чем «ФИО и паспорт». С точки зрения 152-ФЗ ПД — это любая информация, по которой прямо или косвенно можно идентифицировать человека, даже если там только логин или кусок e-mail.
В датасетах для нейросетей это обычно выглядит как: тексты переписок в поддержке, заявки с сайта, резюме, лог-файлы, где маячит IP и user-agent. Как только эти данные начинают использоваться для обучения или дообучения модели, вы автоматически оказываетесь в зоне регулирования 152-ФЗ и должны обосновать законность их обработки.
Это критично, потому что именно на этапе подготовки данных, а не в самой модели, чаще всего и возникают нарушения. По данным Роскомнадзора и разборов дел на consultant.ru, большая часть штрафов связана с отсутствием правовых оснований и защитных мер при автоматизированной обработке ПД, а не с самим фактом использования ИИ.
Если хочется глубже в первоисточник, текст закона можно посмотреть на consultant.ru или garant.ru — это спасает, когда нужно пробить спорный кейс, а юрист недоступен.
Какие риски несёт обучение моделей без учёта 152-ФЗ
В начале 2026 штрафы за нарушения при обработке ПД в автоматизированных системах доходят до 18-20 млн руб. для юрлиц по статье 13.11 КоАП. Но деньги — не единственная проблема: Роскомнадзор может ограничить обработку, а это означает остановку процессов, где завязана нейросеть, от поддержки до скоринга.
Сейчас работает простой, но неприятный сценарий: компания выгружает логи чатов, отправляет их в облачное API без обезличивания, обучает модель для поддержки, а через полгода приходит проверка и фиксирует, что ПД гуляют по внешним сервисам без оснований и договоров. Даже если утечки не было, формально состав есть.
По данным Минцифры и обзоров практики, опубликованных в 2025, регулятор особенно внимательно смотрит на истории, где ИИ обрабатывает чувствительные данные — здоровье, финансы, персональные условия договоров. И тут уже не работает аргумент «мы же просто обучали нейросеть».
Мне в PROMAREN приходилось разруливать ситуацию, когда компания обучила модель для анализа обращений клиентов, а потом обнаружила в логах API полные переписки с ФИО, картами лояльности и адресами. Разбор с юристами, срочная перестройка контура, локальное обезличивание — и только тогда стало безопасно двигаться дальше.
Как 152-ФЗ связывается с новым регулированием AI
Сейчас регулирование AI в РФ строится по принципу: сначала старая база (152-ФЗ, закон о рекламе 38-ФЗ и прочее), а сверху — новые нормы об ИИ. В начале 2026 обсуждаются и частично приняты положения, которые прямо говорят: обучать модели на персональных данных без законных оснований и мер защиты нельзя, а на обезличенных — можно и нужно.
На практике это означает, что обучение нейросетей и закон должны идти вместе: вы не можете «спрятаться» за словом «ИИ» и игнорировать 152-ФЗ. Напротив, чем активнее вы используете модели, тем яснее должны быть прописаны процессы обработки информации, роли оператора и обработчика, а также границы для персональных данных.
По данным отраслевых обзоров Gartner и отечественных аналитических центров, компании, которые с самого начала учитывают требования 152-ФЗ в архитектуре своих AI-систем, тратят на переделки в 2-3 раза меньше, чем те, кто сначала «просто сделал», а потом столкнулся с проверками. Дальше придётся говорить про обезличивание — без него к нейросетям в 2026 лучше не подходить.
Как обезличивать данные так, чтобы Роскомнадзор не придрался
Обезличивание — это не про «замажем ФИО маркером и будем считать, что всё ок». С точки зрения закона это процесс, после которого нельзя восстановить человека без отдельного ключа или допинформации, и в 2026 к этому стали относиться заметно строже.
В определении: обезличивание персональных данных — это действия, в результате которых становится невозможным без дополнительной информации определить принадлежность ПД конкретному субъекту. То есть просто удалить фамилию недостаточно, если рядом остался уникальный e-mail или номер договора.
Какие методы обезличивания реально работают сейчас
На практике в проектах PROMAREN чаще всего встречаются три рабочих подхода: псевдонимизация через идентификаторы, маскировка значимых полей и агрегация. Формально можно перечислить ещё больше, но эти три закрывают 80% задач обучения нейросетей.
Псевдонимизация — когда ФИО, номера телефонов, e-mail и ID клиентов заменяются на внутренние коды, а таблица соответствий хранится отдельно и под доступом. Маскировка — когда вы оставляете структуру, но убираете уникальность: обрезаете часть номера, зашумляете даты рождения, заменяете конкретные суммы диапазонами.
Агрегация хорошо заходит там, где модели не нужен уровень отдельного человека: суммы по дням, сегменты, статистика по группам. Здесь ПД растворяются в массиве, и даже без сложных техник уже нет привязки к субъекту.
По данным разъяснений Роскомнадзора, опубликованных в 2025 на официальном сайте службы, критично, чтобы восстановление личности без доступа к отдельному ключу было именно невозможным, а не «крайне маловероятным». Иначе контролёр может признать данные всё ещё персональными.
Как подготовить данные для GigaChat и других облачных моделей
Когда речь заходит про «скармливание данных GigaChat», у многих в глазах появляется смесь интереса и страха: «А если модель всё запомнит, и потом это куда-нибудь утечёт?» Чтобы не полагаться на обещания провайдера, мы в PROMAREN делаем максимально жёсткий препроцессинг до выхода данных наружу.
Типичный сценарий обучения: у вас есть массив обращений клиентов в поддержку за год, и вы хотите дообучить модель, чтобы она точнее отвечала на вопросы. В этих обращениях есть ФИО, телефоны, номера заказов, иногда куски переписок из мессенджеров с очень личной информацией.
Здесь работает такая логика: сначала локально (на своём сервере или защищённой VM) пробегаемся скриптом по текстам и вычищаем всё, что хоть как-то тянет на ПД. ФИО меняем на «Клиент1», «Клиент2», телефоны и e-mail маскируем, уникальные ID заменяем на внутренние. Сам ключ сопоставления, если он вообще нужен, остаётся в вашем контуре и не попадает в GigaChat API.
В одном из кейсов ритейла мы так обработали около 50 тысяч обращений: сначала казалось, что после маскировки модель «оглупеет». На деле точность ответов выросла, потому что модель перестала цепляться за лишние детали и научилась лучше понимать типы вопросов. По прямым данным клиента, время обработки тикетов сократилось почти вдвое.
Как проверить, что данные реально обезличены
Тут я раньше думала, что достаточно «визуального осмотра»: пробежался глазами, не увидел ФИО — молодец. После пары жёстких внутренних проверок поменяла подход и добавила несколько формальных шагов проверки качества обезличивания.
Сейчас работает такой набор практик: отдельный чек-лист полей, которые обязаны быть обезличены; выборочная ручная проверка с попыткой «угадать» человека по тексту; и небольшой скрипт, который ищет паттерны телефонов, e-mail, паспортов и прочего. Если хоть что-то из этого срабатывает — возвращаемся на этап препроцессинга.
Критичный момент: обезличенные данные должны храниться отдельно от исходников и тем более от ключа соответствия. Если вы складываете всё в одну папку «для модели» и считаете, что достаточно написать «обезличено», при проверке это могут признать фикцией, а не реальной мерой защиты.
На сайте PROMAREN у меня есть раздел со статьями про AI-инструменты и практику с нейросетями, где я периодически показываю такие пайплайны обезличивания на Python и n8n. Следующий логичный вопрос, который возникает после обезличивания, — а что делать с облаком.
Передача данных в облако: где проходит красная линия
Сейчас в 2026 передавать ПД в облако «просто так» — это как переходить трассу ночью в чёрном: формально можно, но вероятность неприятностей слишком высока. Для обучения нейросетей безопасно в облако должны уходить уже обезличенные данные.
В логике 152-ФЗ оператор персональных данных отвечает за то, кому и в каком виде он их передаёт. Облачный провайдер вроде Yandex Cloud или сервиса GigaChat становится обработчиком, и все нарушения с ПД по цепочке всё равно прилетают в вашу сторону.
Как передавать данные в облако безопасно по 152-ФЗ
Если упростить, безопасная передача в облако — это комбинация из трёх вещей: обезличивания до выхода наружу, защищённого канала и внятных договорённостей с провайдером. Обучение нейросетей и закон тут снова идут рука об руку.
Сначала вы очищаете данные локально, как мы говорили в предыдущей части. Дальше настраиваете шифрованный канал: по состоянию на январь 2026 минимальный стандарт — TLS 1.2, лучше 1.3, плюс контроль сертификатов. И только после этого данные отправляются в облако через API, будь то GigaChat, Yandex или другой сервис.
В договорах с провайдером должно быть прописано, что он выступает обработчиком, а не оператором ПД, и использует данные строго по вашему заданию. На практике это означает DPA (data processing agreement) или дополнительные положения к основному договору. Многие крупные игроки уже выложили типовые формы на своих сайтах.
Согласно рекомендациям Роскомнадзора и Минцифры, которые можно найти в открытом доступе, операторам советуют фиксировать все такие действия: акты передачи данных, журналы выгрузок, регистры систем, где обучаются модели. В PROMAREN мы часть этого автоматизируем через n8n, чтобы журналы формировались сами, а не руками аналитика.
В чём разница между локальными и внешними облаками для обучения
Представь ситуацию: у вас есть выбор — обучать модель в локальном приватном облаке или использовать публичное решение от крупного провайдера. С точки зрения 152-ФЗ риски разные, но база одна и та же: обезличивание и договорённости.
В локальном облаке (на базе своего дата-центра или проверенного партнёра) у вас больше контроля: вы понимаете, где физически лежат данные, кто к ним имеет доступ, и можете вшить дополнительные меры защиты. Но это дороже и требует своей команды.
Во внешнем облаке (Yandex, VK, иногда зарубежные решения) контролировать внутреннюю кухню сложнее, зато вы получаете готовую инфраструктуру и доступ к сильным моделям. В 2025-2026 многие компании идут по гибридному пути: критичные ПД и сырые данные хранят локально, а в облако отправляют только обезличенные и уже подготовленные выборки.
На сайте PROMAREN я часто привожу этот подход как «честную архитектуру под 152-ФЗ»: максимум white-data в облаке, весь «мясной» контент — в вашем контуре. Следующий шаг в этой логике — собственно обучение моделей.
Какие типичные ошибки я вижу при работе с облаком
Тут я поняла одну простую вещь: компании чаще всего попадают не на «чёрных» нарушениях, а на мелочах, которые казались безобидными. Например, кто-то решил «для теста» отправить в GigaChat пару реальных диалогов клиентов, а API-логирование включено по умолчанию и хранит тексты на стороне провайдера.
Другая частая история — смешивание обезличенных и исходных данных в одном бакете облачного хранилища. Формально вроде как «основная модель обучается на обезличенном», но рядом валяется архив с сырыми ПД, доступ к которым имеют те же сервисные аккаунты.
По данным нескольких аудитов, которые мы делали в PROMAREN во второй половине 2025 года, такие «мелочи» составляют до 60% замечаний по работе с ИИ и персональными данными. Поэтому я теперь всегда закладываю отдельное время на ревизию бакетов, прав доступа и логов — даже если клиент уверен, что «там точно всё чисто».
Когда с облаком разобрались, встаёт уже главный вопрос: как обучать нейросети так, чтобы и закон был доволен, и бизнесу было не стыдно за свои процессы.
Как обучать нейросети без нарушения закона на практике
Если собрать опыт 2025-2026, то большинство проблем с 152-ФЗ при обучении моделей рождаются не в коде, а в отсутствии нормального «инструктажа» по работе с данными. Как только прописываем, кто что делает и в каком виде, уровень риска падает в разы.
Здесь я смотрю на обучение нейросетей как на связку из трёх вещей: юридические основания, технический контур и человеческая дисциплина. Провалиться можно в любой из них, но лучше укрепить все три сразу и спокойно жить.
Как выглядит безопасный цикл обучения модели
По опыту PROMAREN устойчивый цикл обучения без нарушений 152-ФЗ всегда начинается с инвентаризации. Сначала вы отвечаете себе на вопрос: какие именно данные пойдут в модель и где в них спрятаны ПД. Логи чатов, резюме, заявки, обращения — всё это нужно разложить по полочкам.
Дальше вы проверяете правовые основания: согласия в формах, условия договоров, локальные акты. Иногда на этом шаге становится понятно, что часть старых данных вообще нельзя использовать, и это лучше осознать до, а не после запуска модели.
Третий слой — тот самый препроцессинг и обезличивание, о котором мы уже говорили. На этом же этапе можно закладывать технические ограничения: лимиты по логам, отдельные хранилища, шифрование. Только после всего этого модель начинает учиться, а не наоборот.
Согласно исследованиям McKinsey и локальным обзорам рынка ИИ, компании, которые рассматривают данные как актив с юридическими характеристиками, а не просто «топливо для нейросетей», показывают более стабильные внедрения и меньше откатов проектов из-за рисков compliance.
Как встроить 152-ФЗ в пайплайн обучения, а не приклеить сверху
Когда я только начинала заниматься AI-проектами, мне казалось, что можно сначала построить пайплайн, а потом «докрутить» к нему 152-ФЗ. После шести-семи проектов стало понятно: так дороже и дольше, чем сразу спроектировать процессы с учётом закона.
Сейчас работает другой подход: мы берём типовой контур обучения (подготовка данных, загрузка, fine-tuning, валидация, деплой) и прямо в него вшиваем контрольные точки. Например, отдельный шаг в n8n, который не пропускает датасет дальше, пока не выполнены правила обезличивания.
Для GigaChat и похожих сервисов это может выглядеть так: коннектор забирает только уже подготовленные данные из безопасного хранилища; доступ к нему имеют только сервисные аккаунты; а сами ключи сопоставления ПД живут в другой системе, с которой API не дружит принципиально.
На сайте PROMAREN я показывала схему, где вся автоматизация через n8n строилась вокруг одной идеи: «в облако уходит только то, что мы можем показать регулятору без покраснения». Это не всегда красиво на диаграммах, зато очень успокаивает на аудите.
Как инструктировать команду и что автоматизировать в первую очередь
152-ФЗ нейросети обучение инструктаж — это, по сути, разговор с людьми, которые привыкли «просто заливать данные в модель». Здесь я делаю ставку на короткие, но конкретные правила, а не на толстые политики, которые никто не читает.
На практике мы фиксируем несколько вещей: какие типы данных можно использовать для обучения, какие — только после обезличивания, а какие вообще нет; какие облачные сервисы разрешены и на каких условиях; кто отвечает за журналы, акты и техническую часть. Всё это укладывается в пару страниц, а не в роман.
Автоматизировать в первую очередь имеет смысл скучные, но критичные шаги: поиск ПД в датасетах, журналирование выгрузок, проверку прав доступа сервисных аккаунтов. Здесь очень выручает связка из n8n или Make и внешних API, которые помогают не держать всё в голове и не надеяться на «авось не забудем».
В одном из HR-проектов мы так перевели команду от хаоса к порядку: раньше аналитик просто кидал CSV в облако и обучал модель на резюме, сейчас перед этим автоматически запускается сценарий проверки и обезличивания. Время на подготовку выросло на 10-15 минут, зато риск получить претензию от Роскомнадзора резко упал.
Когда команда и пайплайн выровнены, становится ясно, что 152-ФЗ — это не тормоз, а рамка, внутри которой AI-проекты живут дольше одного пилота.
Почему 152-ФЗ стал опорой для AI, а не только запретом
Парадокс 2026 в том, что компании, которые раньше громче всех ругались на 152-ФЗ, теперь чаще всего ссылаются на него как на «страховку» при запуске AI-проектов. Регулирование AI в итоге подстраивается под эту логику, а не живёт отдельно.
За последний год я всё чаще слышу от клиентов не «как обойти закон», а «как встроить закон в архитектуру так, чтобы не мешал». И здесь 152-ФЗ неожиданно оказывается хорошим чек-листом зрелости для всего, что связано с нейросетями.
Как 152-ФЗ помогает строить устойчивые AI-системы
Если вынуть из 152-ФЗ эмоции и оставить только суть, он про три вещи: осознанный сбор данных, их защиту и права людей, к которым они относятся. Для нейросетей это превращается в конкретные вопросы: откуда взялись данные для обучения, на каком основании вы их используете и можете ли вы объяснить это человеку.
Компании, которые честно отвечают на эти вопросы ещё до старта проекта, обычно оказываются впереди. У них понятны источники данных, есть прозрачные политики, а архитектура AI-систем не завязана на «серых» схемах. Это означает меньше неожиданных блокировок и больше доверия со стороны клиентов и партнёров.
По данным отраслевых обзоров Минцифры и аналитиков, рынок ИИ в РФ в 2025-2026 годах растёт двузначными темпами, и до 80% крупных компаний так или иначе внедряют нейросетевые решения. Те, кто сразу строит их с учётом 152-ФЗ и смежных требований, показывают не только рост эффективности, но и меньше репутационных провалов.
В PROMAREN мы это видим на очень приземлённых цифрах: там, где с самого начала есть методика white-data и честная архитектура под 152-ФЗ, команды экономят 20-30% времени на переделках и юридических согласованиях. И да, это тот случай, когда закон реально экономит часы.
Как меняется отношение к обучению нейросетей и закону в 2025-2026
Раньше «обучение нейросетей и закон» звучало для многих как конфликт: либо ты делаешь крутой AI, либо соблюдаешь 152-ФЗ. В начале 2026 эта дихотомия постепенно уходит: становится понятно, что без нормальной работы с персональными данными серьёзные проекты просто не выживают.
Я вижу, как меняется тон обсуждений: если в 2023-2024 мы спорили, можно ли вообще использовать облачные модели вроде GigaChat или решений от Yandex, то сейчас разговор скорее про то, как встроить их в свой контур так, чтобы и бизнесу было выгодно, и проверка не становилась кошмаром.
Где-то в этот момент у многих происходит сдвиг: закон перестаёт быть страшилкой и превращается в набор ограничений, с которыми можно работать. Кто-то идёт по пути локальных моделей, кто-то использует гибридные схемы с обезличиванием и облаком, кто-то строит полностью свой стек — но почти все уже задают правильные вопросы.
На сайте PROMAREN я стараюсь собирать такие истории и схемы в одном месте, чтобы не рассказывать их заново на каждом созвоне. А в канале PROMAREN иногда разбираю забавные кейсы из практики — с исправленными деталями, но живыми граблями.
Что будет, если по-прежнему «не думать» про 152-ФЗ
Я хотела написать здесь что-нибудь мягкое, но это было наивно реальность пока менее романтична. Если продолжать обучать модели так, как будто 152-ФЗ нет, в какой-то момент вы упрётесь в проверку, утечку или жалобу, и тогда придётся не строить AI, а тушить пожар.
Сценарий довольно приземлённый: нейросеть, обученная на «сырых» данных, начинает выдавать в ответах реальные ФИО или детали договоров; кто-то делает скриншот и пишет запрос в компанию или сразу в регулятор. Дальше запускается маховик разборок, и это уже не история про технологии.
Сейчас работает другой путь: сначала минимальный набор порядка с данными, потом аккуратное внедрение нейросетей, потом масштабирование. Это скучно по сравнению с картинками «ИИ захватывает мир», но стабильно выдерживает проверки и помогает бизнесу экономить время вместо того, чтобы его терять.
Если всё это собрать в одну мысль, получится примерно так: 152-ФЗ для AI — не стоп-кран, а поручень. Держишься за него — и можно спокойно подниматься по ступенькам сложных проектов, не проверяя каждый раз, не провалился ли пол.
Кратко: к чему приходим на практике
Получается, что безопасное обучение нейросетей в РФ держится на трёх опорах: честное определение, где у вас персональные данные; стабильный процесс обезличивания до выхода в облако; и архитектура, в которую 152-ФЗ встроен изначально, а не приклеен потом.
Я раньше думала, что это про «страховку от штрафов», а сейчас вижу: компании с такой логикой быстрее запускают AI-проекты и реже их сворачивают. Закон не гарантирует идеальный результат, но очень неплохо отделяет рабочие подходы от рискованных.
Если хочется докрутить эту тему на примерах и схемах, на материалах по AI-инструментам на PROMAREN я показываю, как это собирается на практике на n8n и других инструментах.
Кто всё это пишет и где смотреть продолжение
Обо мне. Я — Марина Погодина, основательница PROMAREN и AI Governance & Automation Lead, раньше занималась внутренним аудитом и ИТ-рисками. С 2024 года помогаю командам в РФ строить white-data AI-системы под 152-ФЗ. За 12 месяцев мы запустили десятки проектов, о которых пишу в блоге PROMAREN и разбираю в канале.
Если хочется разложить свой проект по полочкам, в тестовом доступе можно посмотреть, как мы автоматизируем контент и процессы. А в канале PROMAREN я регулярно показываю живые разборы внедрений, без магии, но с цифрами.
Что ещё важно знать про закон и нейросети
Можно ли обучать нейросеть на данных сотрудников без отдельных согласий
Да, но только если обработка прямо вытекает из трудовых отношений и не выходит за их разумные пределы. В этом случае основанием будет трудовой договор и локальные акты, а не отдельные согласия. Но если вы используете данные для других целей, например, для внешнего AI-сервиса, лучше предусмотреть отдельные уведомления и согласия.
Что делать, если исторические данные собраны без учёта обучения моделей
В такой ситуации безопаснее считать эти данные «условно пригодными» и пройтись по ним повторно. Сначала нужно проверить формы согласий и политики обработки, затем решить, можно ли использовать массив для обучения. Иногда проще собрать новый, меньший, но юридически чистый датасет, чем пытаться легализовать всё прошлое.
Можно ли обойтись без обезличивания, если модель разворачивается только локально
Теоретически возможно, но риск остаётся высоким, потому что 152-ФЗ не делает послаблений для «локальных» моделей. Если в обучении участвуют реальные персональные данные, вы должны обеспечить их защиту и законные основания, независимо от места размещения. Обезличивание в этом смысле снижает объём требований и последствия возможных инцидентов.
Нужно ли уведомлять Роскомнадзор, если я запускаю проект с нейросетью
Сам по себе факт использования нейросети не требует отдельного уведомления. Важно, чтобы вы уже были зарегистрированы как оператор персональных данных, если обрабатываете ПД, и в уведомлении были отражены соответствующие цели обработки. Если проект меняет цели, категории данных или круг субъектов, может потребоваться обновление сведений.
Чем GigaChat и локальные модели отличаются с точки зрения 152-ФЗ
С точки зрения 152-ФЗ разница скорее техническая, чем юридическая: в обоих случаях вы остаетесь оператором ПД и отвечаете за обезличивание и защиту. GigaChat и другие облачные решения требуют особого внимания к договорам и передаваемому содержимому. Локальные модели дают больше контроля, но не освобождают от обязанностей по закону и внутренней дисциплины.