ИИ для 1С: две разные задачи

Обновлено 21 сентября 2026 г. · 7 мин чтения

Когда 1С-разработчику или руководителю говорят «давайте применим ИИ в 1С», за этим стоят две разные задачи. Первая — ИИ пишет код конфигурации. Вторая — ИИ отвечает на вопросы по данным базы. Инструменты у них разные, риски разные, отвечают за них разные люди. Обсуждают всё это обычно как одно.

Ответьте себе на один вопрос. Что должно получиться на выходе, изменённый код конфигурации или ответ по данным? Дальше всё расходится.

Две задачи рядом

Задача первая — ИИ пишет код

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

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

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

Спотыкается маршрут чаще всего на обратной загрузке правок, а не на самой выгрузке. Про это — отдельный разбор по шагам.

Задача вторая — ИИ отвечает по данным

Здесь два противоположных направления, и их тоже путают.

Направление первое: 1С ходит в модель. В коде конфигурации живёт вызов к API провайдера, и 1С сама отправляет туда текст — классифицировать обращение, вытащить поля из письма, собрать черновик комментария к документу. Пишется это на встроенном языке, в серверном контексте: HTTPСоединение, тело запроса через ЗаписьJSON, разбор ответа через ЧтениеJSON. Внешние компоненты и промежуточные сервисы для этого не нужны.

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

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

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

Чего нет в таблице

Зарплаты и закупочные цены лежат в той же базе, что и остатки на складе. Там же контрагенты с договорами. Роль, выданная агенту «чтобы попробовать», открывает их разом, и разбираться с этим будет уже не разработчик.

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

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

У ограничений на уровне записей есть ловушка, на которой теряют день. Если они наложены, а в запросе не передан параметр allowedOnly=true, платформа возвращает 401, и это читается как проблема с паролем, а не с правами.

Имя роли и ловушку с allowedOnly мы взяли из документации фирмы «1С» к её облачному сервису, где стандартный интерфейс OData расписан подробнее всего. Точное имя роли по разделу ИТС мы не сверяли и сами эту связку на базе не поднимали, так что список ролей своей конфигурации перед настройкой откройте глазами. Сами слои доступа от этого не двигаются, платформа проверяет их на каждом обращении.

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

Обе задачи требуют, чтобы кто-то понимал платформу, и по-разному. В первой человек проверяет код, который модель написала уверенно и неправильно. Во второй человек решает, что именно модели показывать, и это решение вообще не про программирование. Поэтому его чаще всего никто и не принимает. Задачу ставят разработчику, а упирается она в согласование доступа.

Что читать дальше

Если у вас первая задача — шаги миграции конфигурации в ИИ-редактор: выгрузка, дерево метаданных и какая модель на практике лучше пишет на BSL.

Если вторая, через OData, — полный список того, что интерфейс отдаёт наружу и чего не отдаёт: отчёты и обработки в него не входят при любых правах.

Если канал — MCP-сервер поверх OData, там разобран свой набор ограничений по отдельности, от набора инструментов сервера до роли и записей, с оценкой, какое из них слабое, а какое проверяет платформа насквозь.

Частые вопросы