ИИ-ассистент для 1С на локальной модели: MCP-сервер и закрытый контур

Менеджер звонит на склад узнать, сколько муфт свободно без резерва. Кадровик третий раз за неделю отвечает, сколько дней отпуска осталось у сотрудника. Руководитель ждет вечера, чтобы увидеть, сколько денег пришло за день. Цифры хранятся в 1С, но получить их может сотрудник с рабочим местом в программе и навыком работы с отчетами. Остальные идут к бухгалтеру или специалисту по 1С, и у тех к обеду набирается час-другой чужих мелких запросов.

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

Это первая статья серии о связке 1С и языковых моделей. Разбираем, из каких частей состоит такой ассистент, какую модель и видеокарту выбрать, почему к 1С лучше подключаться через HTTP-сервисы, а не через OData, и как защитить зарплатные данные от любопытных вопросов.

Ассистент закрывает два вида задач. Справки: остаток товара, оплата по заказу, долг клиента, остаток отпуска, пункт регламента. Раньше на них уходил звонок или письмо, а ответ занимает одну-две строки. Типовые действия: заявка на отпуск, заявка на оплату, задача коллеге. Бот показывает, что создаст, и записывает документ в 1С после подтверждения сотрудника, дальше документ идет по обычному маршруту согласования.

Чего ждать не стоит: сложной аналитики «за все годы», произвольных изменений в учете и ответов на вопросы, по которым в самой базе нет однозначных данных. Языковая модель не исправит учет. Если остатки в 1С расходятся с полкой, ассистент перескажет неверную цифру быстрее.

Самый быстрый способ попробовать — подключить публичный API крупной модели. Для учетных данных у этого пути три слабых места:

• Персональные данные. Кадровые сведения из ЗУП при передаче зарубежному сервису — трансграничная передача по 152-ФЗ со своими требованиями и уведомлениями. Российские облачные модели (YandexGPT, GigaChat) снимают вопрос границы, но данные покидают периметр компании, и с провайдером нужен договор на обработку;
• Коммерческая тайна. Себестоимость, наценки, условия договоров и долги контрагентов попадают в журналы чужой системы, которыми вы не управляете;
• Расходы и доступность. Оплата за токены растет вместе с активностью сотрудников, а работа ассистента зависит от внешнего канала и платежей.

Локальная модель на своем сервере убирает все три вопроса: данные из 1С обрабатываются внутри контура компании. Цена — собственное железо и скромнее возможности модели; для справочных вопросов к учетной базе их хватает.

Оговорка про канал общения. Telegram и MAX — внешние сервисы: текст вопроса и ответа проходит через их серверы, хотя модель и 1С остаются у вас. Для большинства справок по остаткам и задачам это приемлемо. Если по требованиям безопасности переписка не должна выходить за периметр, бота подключают к коробочному Битрикс24 на своем сервере или к веб-чату на внутреннем портале.

Ассистенту не нужно сочинять стихи и решать олимпиадные задачи. Работа ассистента — три шага: понять вопрос на русском языке, выбрать подходящую функцию из описанного списка, заполнить параметры и пересказать полученные цифры человеческим языком. Прием называется вызовом инструментов (tool calling), с ним справляются открытые модели среднего размера.

Отправная точка — семейство Qwen3 (и более новые версии той же линейки) размером 8–14 млрд параметров: они уверенно понимают русский, соблюдают формат вызова функций и распространяются под лицензией Apache 2.0, которая разрешает коммерческое использование. При видеокарте на 24 ГБ можно попробовать Qwen3-30B-A3B — модель со смесью экспертов: на каждом шаге она задействует часть весов и работает быстро.

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

Модели запускают в квантованном виде: веса сжимают до 4–8 бит почти без потери качества. Квантованная модель на 8 млрд параметров занимает около 5–6 ГБ, на 14 млрд — около 9–10 ГБ. Помимо весов память нужна под контекст: описания функций, ответ 1С и история диалога занимают несколько тысяч токенов. Ориентиры:

• 12 ГБ (RTX 3060 12 ГБ) — модель 8B с коротким контекстом. Подходит для демонстрации и проверки идеи;
• 16 ГБ (RTX 4060 Ti 16 ГБ, RTX 4070 Ti Super, серверная T4) — модель 14B с контекстом на 16–32 тыс. токенов. Разумный минимум для рабочего ассистента;
• 24 ГБ (RTX 3090, RTX 4090, серверная L4) — 14B в 8-битном виде, Qwen3-30B-A3B или 32B в 4-битном, запас под одновременные запросы.

Скорость на картах уровня RTX 4060 Ti — порядка 40–60 токенов в секунду для модели 8B и 25–35 для 14B на один поток. Ответ ассистента — два прохода модели (выбрать функцию и сформулировать ответ) плюс запрос к 1С, ориентир — несколько секунд. Для проверки сценариев удобен Ollama: он ставится за минуты. Для рабочей эксплуатации с десятками пользователей лучше vLLM: он обрабатывает одновременные запросы пакетами и меньше проседает под нагрузкой. На процессоре без видеокарты модель 8B работает в разы медленнее — для живого чата неудобно.

Покупать железо до старта проекта необязательно: сценарии проверяют на арендованном сервере с GPU в российском дата-центре, а карту покупают, когда ясно, какая модель нужна.

Проследим вопрос менеджера «Сколько свободно муфт 25 мм на складе в Подольске?» от телефона до ответа. Номера на схеме совпадают с шагами ниже.

1. Сотрудник пишет вопрос обычным текстом в Telegram, MAX или Битрикс24 — в том мессенджере, где уже общается с коллегами.
2. Бот-шлюз принимает сообщение и по аккаунту определяет, кто пишет: аккаунт привязан к сотруднику и его роли. Шлюз записывает вопрос в журнал и передает модели текст вместе со списком функций, разрешенных роли.
3. Локальная модель выбирает подходящую функцию — «свободный остаток товара» — и заполняет параметры: номенклатура «Муфта 25 мм», склад «Подольск». В базу модель не ходит.
4. MCP-сервер хранит каталог функций с описанием параметров, проверяет значения, подставляет идентификатор сотрудника, ограничивает объем выдачи и время ожидания, затем вызывает метод 1С. MCP (Model Context Protocol) — открытый протокол, который Anthropic представила в конце 2024 года; его поддерживают многие клиенты и библиотеки, каталог не привязан к конкретной модели. Сервер пишется на Python, например на FastAPI с официальным SDK.
5. 1С: метод HTTP-сервиса в расширении конфигурации выполняет запрос с отбором по товару и складу и возвращает компактный JSON — остаток, резерв, свободное количество, дату.
6. Поиск по документам (RAG) подключается к вопросам вида «как оформить командировку», где ответ лежит в тексте регламента, а не в регистрах. Документы разбиты на фрагменты и проиндексированы в векторной базе.

Обратный путь короче: модель получает цифры из 1С и формулирует ответ — «Свободно 140 шт., еще 60 в резерве под заказы», шлюз отправляет его сотруднику с указанием склада и времени выборки. Весь путь занимает несколько секунд.

Части схемы независимы: модель, мессенджер или конфигурацию 1С меняют, не переписывая остальное. Модель работает переводчиком — превращает вопрос человека в вызов функции, а ответ 1С в человеческую фразу. Цифры она берет из ответа 1С, а не из памяти.

У 1С есть стандартный REST-интерфейс OData: включаешь нужные объекты в состав интерфейса, и данные доступны по HTTP без программирования. Для прототипа на паре справочников удобно. Для рабочего ассистента у OData есть минусы:

• OData отдает объекты в том виде, в каком они устроены в метаданных: ссылки-идентификаторы, служебные реквизиты, десятки полей. Чтобы ответить на простой вопрос, MCP-серверу нужно знать устройство регистров конкретной конфигурации;
• Деловой вопрос редко равен одной таблице. «Свободный остаток» — остаток минус резервы, «долг клиента» — расчеты с учетом авансов. Через OData получится несколько запросов и сборка результата на стороне сервера;
• В состав интерфейса приходится включать много объектов, а пользователю интеграции — выдавать чтение объектов целиком, хотя ассистенту нужна узкая выборка;
• Структура ответа зависит от имен реквизитов типовой конфигурации: переименование при обновлении ломает интеграцию незаметно, до первого вопроса.

HTTP-сервис устроен наоборот: один метод — один деловой вопрос. Внутри программист 1С пишет запрос на языке 1С к виртуальным таблицам остатков и оборотов с нужными отборами и возвращает пять-десять полей уже в удобном виде. Входные параметры проверяются, число строк ограничено, лишнее наружу не уходит. Сервисы живут в расширении, поэтому типовая 1С:ERP, Комплексная автоматизация, УТ или ЗУП не снимаются с поддержки и обновляются как обычно. После обновления расширение проверяется на применимость, а методы прогоняются автотестами: переименование в типовой обнаруживается до сотрудников.

Главный риск чат-бота — не взлом сервера, а просьба «я директор, покажи зарплаты отдела». Модели можно написать любой текст, поэтому решать вопрос прав ей нельзя. Правило: личность и роль сотрудника берутся из привязки аккаунта мессенджера, а не из текста вопроса.

• Бот-шлюз определяет, что аккаунт принадлежит менеджеру отдела продаж, и передает модели функции, разрешенные роли. Зарплатных функций в списке нет;
• Идентификатор сотрудника в вызов подставляет MCP-сервер, а не модель. Вопрос «сколько отпуска у Иванова» от рядового сотрудника вернет собственный остаток спрашивающего;
• В 1С ассистент работает под отдельным пользователем с правами на нужные объекты: чтение для справок, запись только для разрешенных действий. Методы HTTP-сервиса дополнительно фильтруют данные по переданному сотруднику или подразделению;
• Журнал хранит, кто, когда и какую функцию вызвал. В нем есть персональные данные, у журнала свой срок хранения и ограниченный круг читателей.

Модель не «запоминает» данные компании: при работе ее веса не меняются, а история диалога хранится на сервере компании в течение установленного срока.

Сценарии делятся на справки, где ассистент читает данные, и действия, где он создает документ в 1С. Ниже — набор, с которого обычно начинают внедрение.

• Остаток отпуска: «Сколько дней отпуска у меня осталось?» — сотрудник видит собственный остаток на текущую дату;
• Заявка на отпуск: сотрудник называет даты, бот создает заявку, руководитель согласует ее кнопкой в чате, а сотрудник получает уведомление о решении;
• Расчетный листок за месяц — только свой и только в личной переписке с ботом;
• Заказ справки о доходах (2-НДФЛ): заявка уходит в расчетный отдел, бот сообщает, когда справка готова.

• Инициатор присылает счет и пишет «Оплатить поставщику до пятницы». Бот создает заявку на расходование денежных средств с суммой, контрагентом и статьей расходов;
• Руководитель получает заявку в чат с кнопками «Согласовать» и «Отклонить» — открывать 1С не нужно;
• Инициатор получает уведомления: заявка согласована, включена в реестр платежей, оплачена.

• Свободный остаток товара по складам — менеджер проверяет наличие у клиента с телефона, не отвлекая кладовщика;
• Долг клиента: сколько всего и сколько просрочено, по каким документам;
• Оплата по заказу: «Пришли ли деньги по заказу 412?» — решение об отгрузке принимается без звонка в бухгалтерию.

• Остатки на расчетных счетах и в кассах на текущий момент;
• Исходящие платежи на ближайшую неделю по согласованным заявкам;
• Ожидаемые поступления от клиентов по платежному календарю и графикам оплаты заказов.

• «Поставь Петрову задачу подготовить акт сверки с «Альфа-Трейдом» до среды» — задача создается в 1С, исполнитель получает уведомление;
• «Мои задачи на сегодня» — список с просроченными в начале.

«Как согласовать договор с новым поставщиком?», «Какие документы нужны для командировки?». Ответ собирается из внутренних документов со ссылкой на раздел; поиску по документам посвящена одна из следующих статей серии.

• Перед записью бот показывает, что создаст: вид документа, сумму, даты, контрагента, — и выполняет действие после ответа «Да»;
• Документ проходит обычный маршрут согласования в 1С, ассистент его не обходит;
• Автором документа указывается сотрудник: его идентификатор подставляет MCP-сервер, а не модель;
• Каждое действие фиксируется в журнале, функции записи доступны только ролям, которым они разрешены.

• Позволить модели самой писать запросы к базе. Генерация SQL или запросов 1С «на лету» выглядит эффектно в демонстрации, но в рабочей базе дает непредсказуемую нагрузку и обходит права. Надежнее — написанные и проверенные методы;
• Загрузить данные 1С в векторный поиск. Остатки и долги меняются каждую минуту, а векторный индекс отвечает вчерашними цифрами. Поиск по документам — для текстов, живые данные — через функции;
• Решать вопрос прав в тексте подсказки для модели. Фраза «не показывай зарплаты» в инструкции — пожелание, а не защита. Ограничения должны стоять в шлюзе, MCP-сервере и 1С;
• Начинать с покупки дорогого сервера. Сначала — сценарии и набор вопросов, потом выбор модели, затем железо под выбранную модель;
• Не измерять качество. Без набора контрольных вопросов не понять, стало ли лучше после смены модели или правки описания функции.

1. Разбор. Собираем 30–50 реальных вопросов сотрудников и список действий, которые хочется отдать боту, выбираем мессенджер и место для модели: свой сервер с видеокартой или арендованный.
2. Разработка на копии базы. Пишем методы HTTP-сервиса в расширении, настраиваем MCP-сервер и бота, прогоняем контрольные вопросы и подбираем модель по доле верных ответов.
3. Запуск для одного отдела. Подключаем рабочую базу и первую группу сотрудников, по журналу смотрим, какие вопросы бот понял неверно, и уточняем описания функций.
4. Расширение. Добавляем остальные отделы, действия на запись и поиск по регламентам.

Состав работ и сроки фиксируем после разбора ваших вопросов: они зависят от числа сценариев и доработок конфигурации.