ИИ и 1С: как безопасно подключить нейросеть и не слить ПДн в облако

Внедрение ИИ в 1С буксует не из-за цены и не из-за качества моделей. Мешает страх утечки. По совместному опросу интегратора УЦСБ и группы Солар (2026 год, 102 компании) среди тех, кто ИИ пока не внедряет, 42,5% главной причиной называют риски безопасности и конфиденциальности: утечку кода и коммерческой информации. Это причина номер один, с заметным отрывом от второй, нехватки компетенций (35%).

Цена ошибки давно перестала быть абстрактной. По поправкам в статью 13.11 КоАП, действующим с 30 мая 2025 года, штраф за утечку персональных данных составляет от 3 до 15 млн рублей в зависимости от объёма, а за повторную утечку введён оборотный штраф от 1 до 3% годовой выручки, вплоть до 500 млн рублей. При этом сама учётная система это и есть хранилище ПДн: оклады и ФИО в ЗУП, паспорта, ИНН и СНИЛС физлиц, телефоны и реквизиты контрагентов. Как только нейросеть получает доступ к такой базе, возникает вопрос, куда уходят эти данные и кто видит их на той стороне.

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

Дальше по пунктам: где данные реально покидают периметр и чем закрывается каждый канал.

Где происходит утечка

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

• Копипаст в браузерный чат. Разработчик вставляет выгрузку таблицы или дамп метаданных в ChatGPT или Claude прямо в браузере. Отдельные инструменты ровно для этого и сделаны: выгружают структуру конфигурации в JSON, чтобы её удобно было вставить в публичную модель. Данные оседают в облаке вендора, чьи логи вам недоступны.
• Облачный прокси. Такие связки гонят запросы из 1С в сотни внешних моделей по HTTP. Направление обратное безопасному: ПДн по умолчанию выезжают за периметр.
• Сырой MCP без фильтра. Часть бесплатных MCP-серверов отдаёт модели результат запроса как есть. Токен-маскировщики закрывают обезличивание, но ролей и аудита не дают. Решения с обратимыми токенами держат инструмент execute_code, а запись прикрывают лишь настраиваемым чёрным списком строк (Записать, Удалить), который можно обойти или отключить, это не жёсткий read-only на уровне шлюза. Другие серверы отдают десятки инструментов, включая тот же execute_code, за единственным грубым глобальным белым списком.

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

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

Безопасная схема: чек-лист

Ниже практический порядок настройки. Он расписан под управляемый шлюз MCP-1C, но логика подойдёт к любой связке ИИ и 1С.

1. Локальный сервер вместо копипаста. MCP-сервер работает на вашей машине и читает конфигурацию локально, код не проходит через чужие серверы. Почему так устроено на уровне самого протокола, разобрано в заметке про on-premise. Практический смысл один: канал к базе должен быть локальным процессом, а не вкладкой браузера.
2. Жёсткий read-only на проде. Включите fail-closed read-only для боевых баз. Запись и удаление блокируются на самом шлюзе, а не на честном слове модели. Эксперименты уводите на стейдж, тест и dev. Даже если модель сгенерирует опасный запрос, до прода он не дойдёт.
3. Маскирование ПДн на выходе. Шлюз обезличивает персональные данные в ответе до того, как он уйдёт в модель. Три режима: off для dev-баз без реальных данных, balanced и aggressive для баз с ПДн. Модель получает структуру и логику запроса, но не сами персональные данные.
4. Роли и лимиты. Ролевые профили (Owner, Admin, Manager, Viewer) определяют, кто и к каким базам ходит через ИИ. Сверху квоты и rate-limit на каждую базу: даже перехваченный клиент не выкачает базу пачкой запросов.
5. Аудит каждого обращения. Журнал фиксирует, кто спросил, к какой базе, что было разрешено, замаскировано или заблокировано, с выгрузкой в CSV или JSONL. Без него подозрительное обращение замечают задним числом и по косвенным признакам, когда данные уже ушли. С ним у службы ИБ есть с чем работать при разборе инцидента.
6. Отключение внешних LLM-вызовов у dev-инструментов. Если контур должен быть закрыт полностью, погасите обращения к облаку и в сборочных функциях. В Профессиональной редакции к внешнему провайдеру (YandexGPT или GigaChat) обращаются четыре функции: автодокументация, генерация тестов, сборка .epf и навигация по типовым конфигурациям. Данные уходят только если вы сами прописали ключи провайдера в переменных окружения. Три функции умеют работать целиком на вашей машине, по флагам --testgen-llm-disable, --epfgen-llm-disable и --typicalconfigs-llm-disable. Автодокументация исключение: отдельного флага у неё нет, без ключей она просто не запускается, но и молча ничего не отправляет.

Гигиена промпта

Технический контур не отменяет дисциплины. Даже со шлюзом не вставляйте в чат сырые выгрузки с ПДн, полные дампы таблиц и конфигурацию целиком: модели хватает структуры и обезличенного примера. Ориентир простой: если фрагмент нельзя показать постороннему подрядчику без NDA, его нельзя вставлять и в облачный чат. И если ИИ сотрудникам действительно нужен, дайте им санкционированный локальный канал вместо теневого ChatGPT в браузере. Запрет без замены не работает: люди всё равно найдут, куда вставить данные, поэтому канал должен быть и удобным, и подконтрольным.

On-prem и что это меняет по закону

Самый надёжный способ не отдать данные наружу это не отдавать их вообще. MCP-1C ставится self-hosted одним бинарником, данные остаются в вашем контуре, хранилище на выбор: PostgreSQL, SQLite или MSSQL. Для полностью закрытого периметра и модель можно держать локально: в шлюз, например, встроен триаж ошибок на локальной LLM, без выхода в интернет. Для госсектора, финансов и других регулируемых отраслей это часто единственный приемлемый вариант, когда данные не пересекают границу организации ни на одном шаге.

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

Коротко

Безопасно подключить ChatGPT или Claude к 1С это не «запретить ИИ», а поставить между моделью и базой управляемый локальный канал: локальный сервер, read-only на проде, маскирование ПДн, роли, лимиты и аудит. Бесплатные инструменты закрывают один-два пункта из этого списка, а риск живёт в незакрытых.

Как ИИ вообще видит конфигурацию 1С, разобрано в заметке про ИИ для 1С. Где проходит сетевая граница, в заметке про on-premise. Сравнение редакций и цены на странице тарифов.