Как подключить ИИ к 1С: пять способов и их ограничения

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

Рейтинга моделей и обещаний «точности до N процентов» здесь нет: такие цифры без вашей базы ничего не значат. Всё, что зависит от версии платформы, конфигурации (УТ, ERP, БП, ЗУП, доработанные базы) и поставщика, помечено, и проверять это нужно на копии. Готовое решение по третьему способу описано на странице «ИИ-ассистент для 1С», а границы прав агента — в статье «Как ограничить ИИ-агента».

Пять способов подключить ИИ к 1С: от безопасного к рискованному

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

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

Способы 1 и 2: без доступа к базе

Способ 1. Выгрузка отчёта в чат вручную

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

Что нужно от 1С. Ничего. Отчёт формирует сотрудник под своими правами и сам отвечает за то, что в него попало.

Что ломается.

• выгружен не тот период или не те отборы, а в файле нет следов настроек отчёта;
• в отчёте свёрнутые группы или скрытые колонки, и в файл попало не всё, что видно на экране;
• длинная таблица не помещается в контекст модели, она читает часть и называет итог приблизительно;
• модель складывает числа «в уме» и ошибается: итоги нужно проверять формулой, а не словами модели;
• выгрузка с ценами, контрагентами и персональными данными уходит во внешний сервис: это самый частый и самый дорогой сбой (о нём подробнее в статье про загрузку договоров во внешние чат-сервисы).

Цена ошибки. Низкая для неверного ответа, потому что человек видит отчёт перед глазами. Высокая для утечки: после отправки вы не контролируете, где хранится выгрузка и кто её увидит. Правило такое: модель формулирует и объясняет, числа берутся из отчёта, итоги проверяются формулой, а выгрузки обрабатывает только модель в вашем контуре.

Способ 2. Поиск по инструкциям и регламентам (RAG)

Модель отвечает по найденным фрагментам документов: инструкции по оформлению операций, описание учётной политики, руководства по работе с 1С, типовые ответы поддержки. Как это устроено, разобрано в статье «Что такое RAG», а почему для документов чаще берут поиск, а не дообучение, — в статье «RAG или дообучение LLM».

Когда подходит. Когда сотрудники спрашивают «как оформить», «кто согласует», «что делать, если». Доступ к базе не нужен, поэтому такой способ согласуется быстрее всех остальных и годится как первый шаг.

Что нужно от 1С. Ничего. Нужны сами документы в читаемом виде и владелец, который отвечает за их актуальность.

Что ломается.

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

Цена ошибки. Сотрудник оформит операцию по устаревшему порядку; такую ошибку находят на сверке, а не в момент ввода. Для снижения риска у каждого ответа есть ссылка на документ и раздел, а у каждого раздела базы есть владелец. Готовая услуга — ИИ-ассистент по документам и базе знаний.

Способ 3. Набор готовых проверенных запросов (вызов инструментов)

Модель получает список инструментов. У каждого есть название, описание и параметры: например «остатки товара на складе на дату» с параметрами «склад», «номенклатура», «дата». Модель выбирает инструмент и значения параметров, код вызывает HTTP-сервис или OData, запрос выполняется в 1С, а в ответ приходит таблица. Формулировать ответ модель может только по этой таблице, а программа сверяет, что каждое число в тексте есть в таблице.

Когда подходит. Когда основные вопросы повторяются и их можно перечислить: остатки, взаиморасчёты, статус заказа, продажи за период. Этот способ мы считаем основным: он даёт числа из учёта, а ошибка остаётся неверным ответом человеку, а не изменением в базе.

Что нужно от 1С.

• публикация базы на веб-сервере: через неё 1С отдаёт HTTP-сервисы и OData;
• либо HTTP-сервис в расширении конфигурации (метод на запрос), либо стандартный интерфейс OData с опубликованным составом объектов;
• отдельный пользователь с ролью на чтение нужных объектов;
• тестовая копия базы, на которой всё это проверяется до боевой.

Выбор между HTTP-сервисом и OData зависит от показателей и версии платформы. Сравнение по критериям:

Что ломается.

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

Цена ошибки. Неверный ответ человеку; запись в базу невозможна, потому что у роли нет таких прав. Риск ограничивают паспорта запросов, проверка чисел и основание под каждым ответом. Подробнее о том, как работает такое решение у нас, — на странице «ИИ-ассистент для 1С».

Способ 4. Произвольные запросы к базе по вопросу

Модель получает описание объектов базы и сама составляет запрос под вопрос. Это гибкость, которой нет у готового набора: можно спросить то, о чём заранее никто не подумал. Платить за неё приходится качеством проверки.

Когда подходит. Как режим для специалиста, который умеет прочитать запрос и оценить результат: аналитик, программист 1С. Для массового пользователя без проверки такой режим не подходит.

Что нужно от 1С. То же, что для третьего способа, плюс: роль только на чтение; список разрешённых объектов и полей, который передаётся модели в качестве описания; разбор текста запроса перед запуском; лимиты на строки и время; копия базы вместо рабочей; показ текста запроса пользователю. Сам язык запросов 1С предназначен для чтения, поэтому испортить данные запрос не может; основные риски лежат в другом.

Что ломается.

• запрос верен по синтаксису, но считает не то: соединение размножило строки и завысило сумму, взят не тот регистр, потерялся отбор по организации;
• запрос без отборов по периоду нагружает сервер так же, как тяжёлый отчёт;
• модель «придумала» несуществующий реквизит или перепутала названия объектов, и ответ строится на ошибке;
• запрос достаёт поля, которые спрашивающему видеть нельзя, если учётная запись шире, чем права человека;
• тексты запросов, найденные в интернете или предложенные моделью, подходят к одной конфигурации и не подходят к вашей.

Цена ошибки. Самая коварная из всех чтений: число выглядит правдоподобно и приходит с уверенным текстом. Поэтому в пилот по умолчанию режим не входит. Включать его стоит, когда готовые запросы закрыли основные вопросы, а на эталонном наборе, где есть и «ловушки» (близкие по названию регистры, похожие показатели), число неверных ответов ниже порога, записанного заранее. Ответ в этом режиме всегда помечается как «запрос составлен моделью», а его текст виден пользователю.

Способ 5. Агент с записью в базу

Агент не только читает, но и создаёт документы, заполняет реквизиты, меняет статусы. Это тема отдельной статьи — «Как ограничить ИИ-агента: права, подтверждения и откат»; здесь только то, что относится к 1С.

Когда подходит. Для рутинного ввода, где правила понятны, а ошибка поправима: создать документ по заявке, подготовить заполненную форму, предложить смену статуса. Начинать нужно не с проведения, а с черновика: человек открывает документ в 1С, проверяет и проводит сам.

Что нужно от 1С.

• отдельная учётная запись и роль на запись, не совпадающая с ролью на чтение;
• права на добавление нужных видов документов без права проведения (право проведения в 1С выдаётся отдельно от права записи документа);
• метод создания с проверкой полей и внешним идентификатором операции, чтобы повторная отправка не создавала второй документ;
• подтверждение человеком, привязанное к конкретным параметрам, журнал, лимиты и аварийный выключатель вне модели.

Что ломается.

• повторная доставка: один и тот же счёт пришёл по почте и в мессенджере, и создались два документа;
• запись без проведения в некоторых конфигурациях тоже запускает обработчики и занимает номер из нумерации, поэтому брошенные черновики засоряют базу (проверяется на копии: зависит от конфигурации);
• документ в этот момент изменил другой пользователь, и запись заканчивается конфликтом одновременной записи;
• период закрыт (например, датой запрета изменений, если она у вас настроена), и запись отклонена: ассистент должен передать случай человеку, а не искать обход;
• нужного контрагента нет в справочнике: создавать нового без подтверждения нельзя;
• во входящем письме написано «проведи и отправь» — это prompt injection, защищает от неё отсутствие права, а не фраза в промпте.

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

Права и учётная запись: что настроить в 1С до подключения

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

• Отдельный пользователь для интеграции. Не учётная запись сотрудника и не администратор: тогда видно, что действие совершил ассистент, а доступ отзывается одним решением.
• Раздельные пользователи для чтения и записи. У учётной записи для чтения нет права записи.
• Роль строится от списка нужного. Перечисляются объекты и действия, а не запреты. Для документов право записи, проведения и удаления выдаются отдельно, и выдаётся только то, что действительно нужно.
• Привилегированный режим в сервисах не используется. Иначе роли и ограничения на уровне записей (RLS) не действуют. Это проверяется тестом: запрос к объекту вне роли должен вернуть отказ.
• Публикуется только нужное. Не вся база целиком, а конкретные сервисы или состав объектов.
• Секреты лежат вне промпта и репозитория. В хранилище секретов, со сроком жизни и ротацией; выдаёт и отзывает их заказчик.
• Лицензии. Подключения под учётной записью интеграции, как правило, учитываются в лицензировании; как именно в вашей поставке, уточняйте у поставщика лицензий до пилота.
• Журнал регистрации 1С как второй источник. В нём видны сеансы и изменения данных под учётной записью ассистента; собственный журнал вопросов и запросов он не заменяет.

Под чьей учётной записью приходит запрос

Есть два варианта. Первый: одна учётная запись ассистента на всех. Проще и дешевле, но 1С не знает, кто именно спросил, и права сотрудника не наследуются; значит, права нужно воспроизвести на стороне ассистента матрицей «роль сотрудника — разрешённые запросы», а в набор включать только то, что не опасно показать всем его пользователям. Второй: запрос под учётной записью самого сотрудника. Роли и RLS 1С применяются к нему как обычно, но нужны сопоставление сотрудников и пользователей 1С, безопасное хранение доступа и учёт лицензий; не при каждой схеме аутентификации это возможно. Если у пользователей ассистента права почти одинаковы, хватает первого. Если права различаются, а ошибка в разграничении дороже удобства, берут второй.

Нагрузка на рабочую базу: лимиты, окна и копия

Тяжёлый запрос от ассистента нагружает сервер 1С и СУБД так же, как тяжёлый отчёт у человека, а вопросы приходят пачкой. Главные риски и меры:

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

Персональные данные: облако или контур

Данные из 1С уходят с вопросом, с результатом запроса и в журнал. Если модель работает во внешнем сервисе, всё это покидает ваш периметр. Поэтому до пилота нужно решить пять вещей:

1. Классифицировать данные. Что в наборах запросов: персональные данные (ФИО, телефоны, паспортные, кадровые и зарплатные сведения), коммерческая тайна (закупочные цены, маржа, условия договоров), остальное.
2. Сузить состав полей. Ассистенту отдаётся только то, что нужно для ответа: контрагент и сумма, без телефона и адреса.
3. Решить, где работает модель. На вашем сервере данные наружу не уходят. Во внешнем сервисе — только если это разрешили служба безопасности и юрист, и тогда состав полей сужается ещё сильнее.
4. Маскировать там, где это возможно. В тестовой копии, в журнале, в примерах для проверки.
5. Назначить ответственного. Оператор данных — вы; требования законодательства о персональных данных и коммерческой тайне согласуйте с юристом.

Сравнение схем «своя модель или внешний сервис» разобрано в статьях «Своя LLM или ChatGPT API» и «On-premise или облако». Развёртывание модели в закрытом контуре мы делаем в рамках услуги «LLM на своём сервере». Для 1С правило простое: пока не решено, где работает модель и какие поля ей отдаются, выгрузки и запросы из 1С к ней не подключаются.

Тестовая копия, журнал и эталонные вопросы: как проверять ответы

Тестовая копия

Копию делают из резервной копии боевой базы и разворачивают отдельно. Что нужно сделать сразу: замаскировать персональные данные, если копия выходит из защищённой зоны, и отключить на копии регламентные задания, обмены и рассылки. Иначе копия начнёт отправлять письма реальным контрагентам или обмениваться с боевыми системами. Все запросы, права и черновики проверяются на копии, и только потом включаются на боевой базе узким потоком: одна организация, один склад.

Эталонные вопросы

Проверка ответов — это набор реальных вопросов сотрудников с верными ответами, а не разговор с ассистентом «на глаз». Собирается он так:

1. берутся реальные вопросы за период из чата, почты и заявок, а не те, которые удобно показывать;
2. для каждого вопроса человек получает верный ответ из отчёта 1С и записывает его;
3. набор делится на две части: на одной настраивают запросы и описания, на другой, контрольной, считают качество;
4. в набор входят вопросы четырёх видов: с готовым ответом, без подходящего запроса (ожидается честный отказ), неоднозначные (ожидается уточнение), вне роли пользователя (ожидается отказ).

Считать нужно раздельно, а не одной цифрой: доля верных ответов, доля честных отказов и уточнений, доля неверных ответов. Жёсткий порог ставится на неверных, потому что уверенный неверный ответ хуже, чем «не знаю». Тот же подход к измерению разобран для распознавания документов в статье «Как измерить точность распознавания документов». Набор прогоняют после смены модели, правки запросов, обновления конфигурации и изменения ролей.

Журнал

Для разбора ошибок нужна запись по каждому обращению: кто и когда спросил, текст вопроса, выбранный инструмент и параметры, сколько строк вернулось, текст ответа, версия модели и набора запросов. Журнал хранится у вас, доступ к нему идёт по роли, срок хранения задан заранее. Ошибки из журнала делятся на группы: параметры, выбор инструмента, определение показателя, данные 1С, формулировка. У каждой группы своё лечение, и «поменять промпт» подходит далеко не всем.

Типичные ошибки и с чего начать

Семь ошибок, которые встречаются чаще других:

• Выгружают всё в публичный чат, потому что так быстрее. Выгрузка с ценами и контрагентами уходит за периметр.
• Дают модели права администратора, «чтобы заработало». Любая ошибка или подмена инструкции получает доступ ко всей базе.
• Верят числу без основания. В ответе нет ни запроса, ни периода, ни времени расчёта, поэтому проверить его нельзя.
• Подключают рабочую базу без лимитов и запускают тяжёлые запросы в рабочие часы.
• Начинают с записи, минуя чтение: агент создаёт документы, а у чтения нет ни эталонных вопросов, ни проверки.
• Берут готовые тексты запросов «для любой 1С» и не проверяют на своей конфигурации и версии.
• Не назначают владельцев показателей. Не решено, что такое «выручка», и ассистент воспроизводит спор между отделами.

С чего начать:

1. выпишите реальные вопросы сотрудников за период и отнесите каждый к одному из пяти способов;
2. для каждого вопроса с числом запишите, откуда ответ и кто владелец показателя;
3. сделайте тестовую копию, опубликуйте на ней один сервис или OData с ролью только на чтение и проверьте нагрузку;
4. соберите эталонный набор и измерьте качество до того, как расширять права.

Если разбора своими силами недостаточно, мы делаем это как обследование: 200 000 ₽ при одном-двух процессах (350 000 ₽, если затронуто несколько систем), оно вычитается из следующего этапа. Дальше лёгкий пилот на чтение — 150 000 – 400 000 ₽, 2–8 недель, а черновики документов и интеграция в боевую базу относятся к тяжёлому пилоту — 400 000 – 1 200 000 ₽, 2–3 месяца. Цены и сроки всех ступеней — на странице тарифов. Исходники, паспорта запросов и эталонные вопросы остаются у вас. Универсальный продукт «для любой 1С» и круглосуточное дежурство мы не обещаем, а работы дешевле 150 000 ₽ не берём. Услуга описана на странице «Интеграции и сопровождение».