On-prem ИИ для 1С без VPN и иностранных карт: локальные модели в вашем контуре

локальный ИИ для 1СИИ без VPNgigachat on-prem 1сMCP шлюз для 1С152-ФЗ и ИИ

Локальный ИИ для 1С без VPN и иностранных карт. Модель в вашем контуре и управляемый MCP шлюз: роли, аудит, read-only на проде.

On-prem ИИ для 1С без VPN и иностранных карт: локальные модели в вашем контуре

В оптовой компании на 280 человек ведущий разработчик 1С правил доработку в ЗУП: сложный свод по начислениям с разбивкой по подразделениям на СКД. Запрос не собирался, движения по регистру накопления вели себя не так, как он ждал, и человек решил ускориться с помощью ИИ. Подписки на зарубежный чат у компании не было: иностранная карта не проходит, без VPN сервис вообще не открывается. Разработчик поднял VPN, оплатил доступ через реселлера и, чтобы модель поняла контекст, вставил в чат кусок реальной выгрузки: ФИО, табельные номера, оклады, СНИЛС нескольких сотрудников.

Ответ пришёл за минуту. Через неделю служба ИБ, разбирая логи прокси, увидела, что персональные данные работников ушли на иностранный сервер. Инцидент закрыли внутренним разбором, но факт остался фактом: данные граждан РФ покинули контур, прошли через зарубежный VPN и осели в логах внешнего сервиса, к которым у компании нет доступа. Это ровно тот сценарий, против которого написан закон.

VPN и чужая карта это не обходной путь, а новый риск

История упирается в несколько норм. Локализация: по части 5 статьи 18 152-ФЗ базы с персональными данными граждан РФ должны находиться в России. Отправляя выгрузку из ЗУП в зарубежную модель, вы обрабатываете эти данные на иностранном сервере. Больше того, такая отправка это ещё и трансграничная передача по статье 12: о ней оператор обязан уведомить Роскомнадзор заранее, а по странам, которые не обеспечивают адекватной защиты прав субъектов (к ним относят, например, США и Китай), регулятор вправе передачу не разрешить вовсе.

Дальше цена ошибки. С 30 мая 2025 года действует новая редакция статьи 13.11 КоАП (Федеральный закон 420-ФЗ от 30.11.2024). За утечку персональных данных для юридического лица штраф теперь от 3 до 15 миллионов рублей в зависимости от числа пострадавших субъектов, а за повторную утечку введён оборотный штраф: от 1 до 3 процентов годовой выручки, до 500 миллионов рублей. Отдельная санкция предусмотрена и за неуведомление регулятора об инциденте в срок.

Важная деталь: сам сотрудник не злоумышленник. Он хотел, чтобы нейросеть помогла с запросом, а единственный доступный ему способ подключить ИИ вёл через границу. Пока рабочий инструмент это чужое облако за VPN и иностранной картой, такие вставки будут повторяться, и статистика это подтверждает. По данным ГК «Солар», в 2025 году число утечек в публичные LLM выросло примерно в 30 раз. Совместное исследование УЦСБ и ГК «Солар» показало, что 50,5 процента российских компаний подозревают или уже фиксируют утечки через ИИ-инструменты. Проблема не в дисциплине людей, а в архитектуре доступа.

Что значит локальный ИИ для 1С

Локальный ИИ для 1С означает, что нейросеть работает на вашем железе, в вашем контуре, а данные из баз к ней и обратно не выходят в интернет. Ни VPN, ни зарубежная карта не нужны, потому что наружу вы никуда не ходите. Это и есть ИИ без VPN и без иностранных карт: не обход блокировок, а отсутствие самой блокирующей границы.

Технически это уже реально. У GigaChat есть локальная (on-prem) поставка: модель Сбера разворачивается на собственных серверах, и для сценария gigachat on-prem 1с это значит, что инференс идёт на вашем GPU, а не в чужом ЦОД. Рядом стоят открытые веса локальных моделей (семейства вроде Qwen, GLM, DeepSeek, Gemma), которые поднимаются на своей инфраструктуре без внешних подписок. Выбор конкретной модели это отдельный разговор, но принципиально нейросеть в контуре компании перестала быть экзотикой.

Как именно граница контура держится на стороне 1С, я подробно разбирал в материале про on-premise развёртывание; здесь механику повторять не буду, важен вывод: и модель, и шлюз доступа к базам могут жить локально, ничего не отдавая наружу.

Локальная модель это только половина задачи

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

Начинается всё с подключения. Чтобы завести ассистента в 1С напрямую, обычно публикуют HTTP-сервис прямо в конфигурации, и в спешке демонстрации его нередко выставляют без аутентификации платформы. Дальше модель, подключённая через сырой MCP-сервер без governance-слоя, видит всё, что видит её учётная запись: оклады из регистра сведений в ЗУП, справочник контрагентов и цены из УТ, проводки из Бухгалтерии. Решения с выполнением кода за грубым списком разрешений или наборы из нескольких Docker-контейнеров с правилами на стороне клиента только усугубляют картину: контроль оказывается там, где его проще всего обойти, и ассистент, который просто помогает, получает возможность изменить проведённый документ или движение по регистру в боевой базе. А если такого ассистента ещё и повесить на регламентное задание или на массовое формирование отчётов, объём того, что уходит в модель за сутки, вы уже не проверяете глазами. Данные при этом из контура не ушли, но внутренний контроль вы потеряли. Локальность отвечает на вопрос, где крутится модель, но не на вопрос, как она ходит в базы.

Второй вопрос и закрывает управляемый шлюз.

Управляемый доступ к базам в том же контуре

Feenlace MCP-1C это governance-шлюз между ИИ-ассистентом и базами 1С. Модель, локальная или любая другая, обращается к 1С не напрямую, а через политику доступа. Что это даёт на практике:

  • Ролевые профили (RBAC): для каждого ассистента и роли на стороне шлюза задаётся свой набор разрешённых операций и баз, независимо от того, какая модель подключена. Аналитику по продажам незачем видеть оклады из ЗУП, и он их не получит.
  • Жёсткий read-only на проде: запись в боевые базы блокируется на самом шлюзе по принципу fail-closed. Если правило не разрешает запись явно, попытка отклоняется, а не проскакивает на всякий случай.
  • Полный аудит действий ИИ: какой ассистент, к какой базе обратился, что было разрешено и что заблокировано, с экспортом в CSV или JSONL. Тот самый журнал, которого не хватило в истории с прокси, только теперь он внутри контура и принадлежит вам.
  • Маршрутизация по нескольким базам и квоты на базу: ЗУП, УТ, Бухгалтерия, тестовые копии разведены по разным правилам, и на каждую базу можно поставить лимит запросов.
  • Лицензирование по местам (seat) и контроль устройств: доступ выдаётся конкретным сотрудникам и их машинам, а не всем, кто нашёл эндпоинт.

Всё это один автономный бинарник, который ставится в вашем контуре рядом с 1С (хранилище на PostgreSQL, MSSQL или SQLite). Внешние подписки и облачные панели управления ему не нужны: шлюз, как и локальная модель, работает офлайн.

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

Что это меняет с точки зрения 152-ФЗ

Честно: on-prem сам по себе не делает вас соответствующими 152-ФЗ и не заменяет модель угроз, оценку рисков и организационные меры. Соответствие это процесс, а не галочка от вендора, и обещать её было бы враньём. Но локальный контур убирает самый очевидный и самый дорогой вектор нарушения: данные из баз 1С физически не покидают периметр, не пересекают границу и не оседают в логах внешнего сервиса. Дальше вы уменьшаете объём ПДн, доступный ИИ, за счёт ролевых профилей, и получаете журнал, которым закрываете вопрос, кто и что смотрел. Меньше данных наружу, меньше поверхность риска. Это не сертификат, это снижение экспозиции, и в текущем режиме штрафов оно стоит вполне конкретных денег.

С чего начать

Если в компании уже кто-то носит выгрузки из 1С в чат за VPN, начните с малого:

  1. Разверните локальную модель в контуре и проверьте, что локальный у вас не только клиент, но и сам инференс. Частая подмена: «локальный» интерфейс, который под капотом всё равно ходит в облако.
  2. Поставьте между моделью и базами управляемый шлюз с read-only на проде и полным аудитом. Никогда не оставляйте HTTP-сервис инфобазы без аутентификации ради быстрой демонстрации: временный доступ имеет свойство оставаться навсегда.
  3. Дайте разработчикам и аналитикам легальный инструмент вместо обходного и заведите привычку логировать каждое обращение ассистента.

Бесплатная редакция Feenlace MCP-1C ставится за вечер и уже показывает, как выглядит доступ ИИ к 1С под контролем; Корпоративная добавляет ролевые профили, маршрутизацию и общий журнал на всю команду. Посмотреть, как это устроено, и попробовать в своём контуре можно на feenlace.ru. Без VPN и без иностранной карты, потому что всё остаётся у вас.