152-ФЗ и искусственный интеллект в 1С: какие данные нельзя отправлять в облачные модели
152-ФЗ делает оператором персональных данных вас, а не нейросеть. Какие поля 1С нельзя отправлять в облачный LLM и как снизить риск штрафа.
Облачная нейросеть не станет оператором ваших персональных данных. По 152-ФЗ оператор это вы. Стоит сотруднику вставить в чат с внешним ИИ карточку из ЗУП или выгрузку контрагентов из Бухгалтерии, и обработку ПДн организовали именно вы. Спросит регулятор тоже с вас, а не с вендора модели. Сервер чужой, логи запросов вам недоступны, а данные могут осесть в обучающей выборке. Юридически это не «мы просто уточнили у ИИ», а передача персональных данных из 1С третьему лицу.
Сколько это стоит в деньгах
Штрафы по статье 13.11 КоАП переписали законом 420-ФЗ, размеры действуют с 30 мая 2025 года. Шкала привязана к масштабу утечки:
- от 1 000 до 10 000 субъектов: от 3 до 5 млн рублей для организации;
- от 10 000 до 100 000: от 5 до 10 млн;
- свыше 100 000: от 10 до 15 млн;
- специальные категории, например данные о здоровье: от 10 до 15 млн;
- биометрия: от 15 до 20 млн;
- повторная утечка любой категории: оборотный штраф от 1 до 3% годовой выручки, до 500 млн рублей.
Скидку 50% за быструю оплату по этой статье отменили целиком. Рядом стоит уголовная статья 272.1 УК, введённая законом 421-ФЗ. За незаконную передачу ПДн там до 4 лет, а если данные ушли за рубеж (трансграничная передача, часть 4), то до 8 лет и штраф до 2 млн рублей. Статья не спит: по данным МВД, с января по октябрь 2025 года её применили 923 раза, и не только к продавцам баз, но и к рядовым сотрудникам, слившим данные по неосторожности.
Бизнес это чувствует. В июньском опросе 2026 года интегратора УЦСБ и ГК «Солар» (102 компании из телекома, госсектора, финансов, промышленности) главной причиной не внедрять ИИ назвали риск утечки кода и коммерческой информации: 42,5% ответов. Не нехватка кадров и не отсутствие сценариев оказались на первом месте, а именно страх, что данные утекут.
Что в 1С уже является персональными данными
Особенность 1С в том, что ПДн лежат не в свободном тексте, а в типизированных реквизитах. Одна выгрузка документа или результат запроса, и за периметр уходит готовый набор идентификаторов:
- ЗУП: ФИО, дата рождения, паспорт, СНИЛС, ИНН, адрес, оклад и начисления. Больничные и прочие сведения о здоровье это уже специальная категория, ответственность за неё выше.
- Бухгалтерия: контрагенты-физлица и ИП, подотчётные лица, банковские реквизиты, ИНН.
- УТ и CRM: клиенты-физлица, телефоны, почта, история покупок.
База с такими данными это ИСПДн. Отправка карточки во внешнюю модель это обработка ПДн, а если модель хостится за рубежом, ещё и трансграничная передача. По статье 12 152-ФЗ оператор обязан уведомить Роскомнадзор до начала такой передачи, а по странам без адекватной защиты дождаться его решения: не разрешит, значит передавать нельзя. Копипаст документа в зарубежный чат-бот пропускает эти шаги по определению.
«Обезличивание»: три разных смысла
Слово перегружено, и подмена смысла обходится дорого.
- Юридическое обезличивание (ст. 3 152-ФЗ): данные обработаны так, что без дополнительной информации привязать их к человеку нельзя. Планка высокая. С 1 сентября 2025 года порядок регулируется отдельным постановлением правительства (№ 1154 от 01.08.2025), с методами и правилами.
- Уничтожение или обезличивание данных уволенных внутри самой 1С:ЗУП. Это про жизненный цикл записей в базе, а не про ИИ. Большинство статей «про обезличивание в 1С» именно об этом.
- Снятие идентификаторов с полезной нагрузки перед отправкой в модель. Вот что нужно, когда вы подключаете LLM.
Третье не равно первому. Маскирование уменьшает объём ПДн, покидающих контур, но не делает данные «обезличенными» в смысле закона. Это снижение риска, не индульгенция.
Почему на источнике в 1С чище, чем в браузере
Типовой облачный сценарий выглядит так: сотрудник копирует данные в браузерный ChatGPT, а какой-нибудь фильтр задним числом пытается вырезать ПДн регулярками или NER из уже готового свободного текста. На русском это ненадёжно: склонения, инициалы, латиница в именах, сокращения. Что-то фильтр поймает, что-то пропустит, и вы не узнаете, что именно.
В 1С стартовая позиция другая. ФИО, паспорт, ИНН это не догадка парсера, а реквизиты с известными путями и типами. Значит, убирать их можно детерминированно на источнике, а не угадывать в потоке символов. Отсюда и вывод: пусть ИИ ходит в 1С через управляемый шлюз, а не через копипаст в браузер.
Что действительно снижает риск
Волшебной кнопки «теперь вы соответствуете 152-ФЗ» не существует, и продавать её нечестно. Но набор мер сокращает и вероятность утечки, и её цену. По убыванию эффекта.
Держите модель и данные в одном контуре. Локальная LLM плюс self-hosted шлюз означают, что запрос вообще не уходит во внешнее облако, а трансграничной передачи не возникает. mcp-1c ставится одним бинарником на ваш сервер, данные остаются на месте. Про то, как именно проходит граница «наружу ничего не уходит», написано отдельно: MCP-1C on-premise. Общий разбор, как ИИ вообще подключается к 1С, тоже в блоге: ИИ для 1С.
Дальше маскирование на выходе. В корпоративной редакции mcp-1c ответ базы очищается на самом шлюзе, до того как уйдёт ассистенту, в трёх режимах: off, balanced, aggressive. Не «попросили модель не запоминать», а физически не отдали.
Доступ режьте по ролям. Кадровику ФИО нужны, аналитику по выручке нет. Ролевые профили (Owner, Admin, Manager, Viewer) определяют, кто и к какой базе обращается, а режим маскирования настраивается отдельно для каждого контура. Чем меньше ролей видят сырые ПДн, тем меньше поверхность.
И не пускайте ИИ на запись в прод. Жёсткий fail-closed read-only блокирует запись в боевые базы прямо на шлюзе: не предупреждает, а отклоняет. Разделение баз по средам (прод, стейдж, тест, дев) с квотами на каждую позволяет отдать модели тестовый или обезличенный контур вместо боевого, а спорные правки провести через черновики с согласованием, не давая ИИ писать напрямую.
Наконец, журнал. Полный аудит фиксирует, кто спросил, к какой базе, что разрешили, замаскировали или заблокировали, с выгрузкой в CSV или JSONL. Оператор по закону обязан доказывать, как он обходится с ПДн, и отрабатывать отзыв согласия. Придёт проверка, без журнала обращений к ИИ доказывать будет нечем.
Красный список: что не отдавать облачной модели из 1С
| Данные из 1С | Где лежат | Чем грозит выгрузка |
|---|---|---|
| ФИО, паспорт, СНИЛС, ИНН, адрес | ЗУП, Бухгалтерия | Штраф от 3 до 15 млн, повтор до 500 млн |
| Здоровье, больничные (спецкатегория) | ЗУП | Отдельный состав, от 10 до 15 млн |
| Оклад, начисления, банковские реквизиты | ЗУП, Бухгалтерия | ПДн плюс коммерческая тайна |
| Клиенты и контрагенты-физлица, телефоны, почта | УТ, CRM, Бухгалтерия | Оборотный штраф, репутация |
| Любое из этого в зарубежный LLM | Любая база | Ст. 12 (уведомление РКН), риск по ст. 272.1 УК |
Что запомнить
152-ФЗ не запрещает ИИ в 1С. Он запрещает бесконтрольно выгружать персональные данные наружу и назначает ответственным за это вас, а не нейросеть. Отсюда четыре рабочих правила: держите модель в контуре, снимайте идентификаторы на источнике в 1С, режьте доступ по ролям, логируйте каждое обращение. Юридическую квалификацию под конкретный случай оставьте юристу или DPO. А инструмент выбирайте по одному критерию: чтобы в случае вопроса регулятору было что показать.