1С:Предприятие — система записи для склада, производства и финансов; LLM — probabilistic слой для языка и рассуждений. Смешивать их через «пусть модель напишет SQL» — архитектурная ошибка: риск порчи данных, обхода прав RLS и неповторяемых ответов. Правильный контур — опубликованные HTTP-сервисы (REST) или OData с узкой семантикой операций, которые middleware вызывает как tools после валидации. Ниже — как спроектировать controlled tools, типовой стек и пример getStock без доступа модели к SQL.
Когда задача касается интернет-магазина, важно сначала проверить согласование заказов и статусов между сайтом и 1С. Подключение языковой модели не заменяет устойчивые идентификаторы и правила владения полями.
Принцип: модель не трогает базу
В 1С уже есть роли, проведение документов, блокировки и транзакции. LLM не знает ваших регламентов проведения и может «логически» предложить списание без документа-основания. Поэтому:
- Модель видит только JSON-schema tools с бизнес-именами:
getStock,getOrderStatus,createServiceRequest. - Реализация tool — код 1С: запросы через язык запросов внутри сервера, проверки прав, журналирование.
- Любая запись — либо создание черновика документа с фиксированным типом, либо заявка в очередь для кладовщика.
Это тот же паттерн whitelist, что и для интеграции LLM с Bitrix24, только транспорт и авторизация — ваши (Basic, token, mutual TLS).
HTTP-сервисы в 1С: минимальный контракт
Публикуете endpoint, например /hs/ai/v1/stock, метод GET/POST с параметрами sku, warehouseId. Ответ — стабильный JSON:
{
"sku": "ART-0042",
"warehouse": "Основной",
"quantityAvailable": 128,
"unit": "шт",
"asOf": "2026-03-01T10:00:00+03:00"
}Внутри обработки — запрос к регистру накопления / остаткам с учётом резервов, без выдачи сырого SQL наружу. Ошибки бизнес-логики («номенклатура не найдена») — HTTP 404 с кодом, понятным middleware для переформулировки ответа пользователю.
Версионируйте API (/v1/, /v2/), документируйте для команды, которая пишет function calling schema. Изменение структуры остатков не должно ломать промпт — только контракт JSON.
Пример сценария getStock (не SQL)
Пользователь в Telegram-боте склада: «Сколько AR-0042 на основном складе?»
- Orchestrator отправляет в LLM историю + tool definition
getStock(sku, warehouseId?). - Модель возвращает tool call с нормализованным артикулом (middleware может дополнительно искать sku через справочник синонимов).
- Middleware вызывает HTTP-сервис 1С с сервисной учётной записью, у которой только чтение остатков.
- Ответ сервиса вкладывается в промпт; модель формулирует текст для человека и ссылку на отчёт в 1С при необходимости.
Модель ни разу не генерировала ВЫБРАТЬ ... ИЗ РегистрНакопления. Если пользователь спрашивает «а покажи все склады», tool может быть listWarehouses + несколько вызовов getStock — лимит на число вызовов задаёт orchestrator.
Для текстовых регламентов (как списывать брак) подключайте RAG по инструкциям, а факты остатков — только из 1С.
Middleware и размещение
Схема: клиент → бот/портал → Python/Go middleware (LLM API + state) → HTTPS → 1С web-сервер (Apache/IIS). Секреты 1С не передаются в OpenAI; в облако уходит только вопрос пользователя и обезличенный результат tool.
Для on-prem LLM (local inference) middleware тот же — меняется только upstream модели. Это актуально для factories с ограничением выноса данных.
Отличие от «универсального AI-агента» — набор tools жёстко привязан к вашей конфигурации 1С (УТ, ERP, КА); универсальные шаблоны без доработки конфигурации редко работают.
Безопасность и аудит
- Отдельная учётная запись HTTP с минимальными ролями; не используйте администратора.
- IP whitelist между middleware и 1С, TLS, rotation паролей.
- Журнал регистрации 1С + внешний log tool calls (sku, user telegram id, latency).
- Запрет произвольных строк в параметрах: regex артикула, enum складов.
- Нагрузочное ограничение: batch остатков — отдельный tool с лимитом sku count.
Экономическое обоснование автоматизации запросов кладовщикам — в расчёте ROI от внедрения ИИ; реальные цифры пилотов — в кейсах.
Типичные ошибки
Выдача модели «текстового доступа» к консоли запросов 1С через RPA; использование OData без фильтров на организацию; смешивание тестовой и боевой базы в одном bot token; отсутствие идempotency при создании документов. Каждый из этих пунктов уже ломал пилоты на промышленных базах.
Экспертные разборы архитектуры учётных систем и AI — у Александра Тимофеева; эксперименты с промптами и retrieval — в блоке исследований.
Итог: LLM + 1С = тонкий слой языка над проверенными HTTP-сервисами. Начните с read-only tools (остатки, статусы заказов), измерьте hit rate и время ответа, затем добавляйте заявки на операции с human approve. SQL и проведение документов остаются внутри платформы 1С — там, где им и место.
Тестирование и нагрузка
Контур тестов: unit на HTTP-сервис 1С (остатки при нуле, резерв, несколько складов), contract tests JSON schema, нагрузочный прогон с peak ×2 к пику запросов кладовщиков. LLM eval отдельно: golden questions с expected tool. Не смешивайте нагрузочный стенд с копией prod без obfuscation — бэкапы в prompts запрещены политикой.
При обновлении конфигурации 1С regression на сервисах обязателен: изменение алгоритма резерва ломает ответы bot без изменения кода middleware. Документируйте mapping sku synonyms в справочнике, а не в промпте. Для холдингов добавьте tool parameter organizationId с проверкой прав пользователя на middleware. Экспертная поддержка архитектуры — страница автора.
Если используете несколько информационных баз (розница и опт), middleware должен маршрутизировать tool call по контексту пользователя, а не давать модели выбирать connection string. Один bot — одна база на первом этапе снижает класс ошибок «ответ из другой организации».
Планируйте окно обслуживания HTTP-сервисов: публикация расширения конфигурации не должна ронять bot без graceful degradation — cached read-only ответ «данные временно недоступны» лучше, чем галлюцинация остатков.
Для производственных заказов добавьте tool статуса этапа маршрута — менеджеры чаще спрашивают «когда будет готово», чем сырой остаток материалов.
Обучите ключевых пользователей формулировать артикулы так, как их понимает справочник синонимов — качество tool call выше, чем у попыток «угадать» запрос языком запросов.