Как дать ИИ-агенту доступ к боевой базе 1С и не поседеть

Недавно мы провели эксперимент: дали четырём ИИ-агентам — Fable 5 и Opus 5 в Claude Code, двум прогонам GPT в Codex — одинаковое задание: оптимизировать тормозящую обработку в продуктивной базе. Не в тестовой копии, не на выгрузке — в живой базе работающей розничной сети, где в этот момент шли продажи. Агенты выполнили в базе сотни запросов, построили десятки замеров, один из них прочитал 1,89 миллиона строк регистра цен. Кто из них что нашёл — разбираем в отдельной статье цикла; эта — про фундамент, который сделал эксперимент возможным.

Количество записей, изменённых в базе за всё это время, — ноль. Не «мы проверили, и вроде ноль». Ноль по построению: записать в базу агент физически не мог. Эта статья — про механизм, который это гарантирует. Он занимает 59 строк кода, разворачивается за полчаса и, судя по нашему опыту, является обязательным условием для любых экспериментов с ИИ на живых данных. Заодно честно расскажу, чего этот механизм не гарантирует — без этого раздела статья была бы вредной.

Зачем агенту вообще продуктив

Первый вопрос на этом месте: «а зачем пускать ИИ в прод, работайте на копии». Ответ короткий: потому что задача этого требует, а копии не всегда есть. Наша задача звучала так: «обработка выполняется 1 минуту 32 секунды, найди причину с доказательствами, оптимизируй, докажи, что результат не изменился». Что для этого нужно агенту:

• Реальные объёмы. По выгрузке конфигурации не видно, что в регистре цен 1,89 млн строк, а у регистра отключена таблица итогов среза последних. Именно эти два факта оказались корнем главного тормоза — и оба живут в данных, а не в коде.
• Реальные замеры. «Этот запрос медленный» — гипотеза. «Этот запрос выполняется 42 935 мс, а переписанный — 3 359 мс на тех же данных» — диагноз. Замер возможен только там, где есть данные боевого масштаба.
• Реальная проверка эквивалентности. Доказать, что оптимизированный запрос возвращает то же самое, можно только сравнив оба результата на одном снимке живых данных.

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

Почему запрета в промпте недостаточно

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

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

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

Решение: транзакция, которая всегда откатывается

В нашей конфигурации есть HTTP-сервис Data API: метод принимает JSON {"code": "<текст на встроенном языке>"}, выполняет его через Выполнить() и возвращает результат из переменной ЛокальныйРезультат. Штука мощная и опасная — поэтому для агентов сделана обёртка execute_code_ro. Схема потока — на картинке ниже, а затем весь код целиком.

// execute_code_ro — выполнение произвольного кода в режиме «только чтение».
// Весь переданный код исполняется внутри транзакции, которая безусловно
// откатывается, поэтому изменения данных в базе не сохраняются.
// Контракт: вход {"code": "<BSL>"}, результат — в переменной ЛокальныйРезультат.

КодДляВыполнения = Неопределено;
Если ТипЗнч(Аргументы) = Тип("Соответствие") Тогда
    КодДляВыполнения = Аргументы.Получить("code");
ИначеЕсли ТипЗнч(Аргументы) = Тип("Структура") Тогда
    Если Аргументы.Свойство("code") Тогда
        КодДляВыполнения = Аргументы.code;
    КонецЕсли;
КонецЕсли;

Если НЕ ЗначениеЗаполнено(КодДляВыполнения) Тогда
    СтруктураОтвета = Новый Структура;
    СтруктураОтвета.Вставить("success", Ложь);
    СтруктураОтвета.Вставить("error", "Не указан параметр code");
    Результат = ОбщегоНазначения.СтруктураВJSON(СтруктураОтвета);
    Перейти ~Конец;
КонецЕсли;

ЛокальныйРезультат = Неопределено;

НачатьТранзакцию();
Попытка
    // В коде доступна переменная ЛокальныйРезультат для записи результата
    Выполнить(КодДляВыполнения);

    СтруктураОтвета = Новый Структура;
    СтруктураОтвета.Вставить("success", Истина);
    СтруктураОтвета.Вставить("result", БезопасноеЗначение(ЛокальныйРезультат));
    Результат = ОбщегоНазначения.СтруктураВJSON(СтруктураОтвета);

Исключение
    СтруктураОтвета = Новый Структура;
    СтруктураОтвета.Вставить("success", Ложь);
    СтруктураОтвета.Вставить("error", ОписаниеОшибки());
    Результат = ОбщегоНазначения.СтруктураВJSON(СтруктураОтвета);
КонецПопытки;

// Откат ВСЕГДА: контракт метода — ничего не менять в базе.
// Если переданный код сам закрыл нашу транзакцию — фиксируем нарушение.
Если ТранзакцияАктивна() Тогда
    ОтменитьТранзакцию();
Иначе
    СтруктураОтвета = Новый Структура;
    СтруктураОтвета.Вставить("success", Ложь);
    СтруктураОтвета.Вставить("error",
        "Нарушение контракта read-only: переданный код управлял транзакциями");
    Результат = ОбщегоНазначения.СтруктураВJSON(СтруктураОтвета);
КонецЕсли;

~Конец:;

(ОбщегоНазначения.СтруктураВJSON — тривиальный сериализатор структуры в JSON; подставьте свой или ЗаписьJSON напрямую.)

Разберём три места, на которых всё держится.

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

«Попытка» вокруг «Выполнить». Код агента падает регулярно — это нормально. Исключение превращается в аккуратный JSON с текстом ошибки, агент читает его и чинит свой код. Без попытки первое же кривое обращение уронило бы соединение.

Проверка «ТранзакцияАктивна» — детектор взлома контракта. Самое интересное место. Если переданный код сам вызвал фиксацию транзакции — наша транзакция больше не активна, и её откат уже невозможен: данные зафиксированы. Предотвратить это внутри Выполнить() нельзя, зато можно обнаружить: если после выполнения транзакция не активна — кто-то ею управлял. Ответ агенту подменяется ошибкой «нарушение контракта», а в задании этот случай объявлен немедленным провалом. Дополнительно управление транзакциями запрещено промптом — и вот здесь запрет в промпте уместен: он не единственная линия обороны, а дублирующая.

Проверяем, что защита работает

Перед тем как подпускать агента, — два smoke-теста руками.

Тест 1: чтение живо. Передаём {"code": "ЛокальныйРезультат = 2 + 2;"} — получаем {"success": true, "result": 4}. Метод работает, код выполняется, результат возвращается.

Тест 2: запись умирает. Передаём код, который создаёт элемент справочника, записывает его и тут же читает из базы:

Спр = Справочники.Контрагенты.СоздатьЭлемент();
Спр.Наименование = "SMOKE_TEST_УДАЛИ_МЕНЯ";
Спр.Записать();
Найден = Справочники.Контрагенты.НайтиПоНаименованию("SMOKE_TEST_УДАЛИ_МЕНЯ");
ЛокальныйРезультат = ?(Найден.Пустая(), "НЕ НАЙДЕН", "НАЙДЕН: " + Найден.Код);

Ответ: НАЙДЕН — внутри транзакции запись честно существует. А теперь тот же поиск, но отдельным вызовом:

Найден = Справочники.Контрагенты.НайтиПоНаименованию("SMOKE_TEST_УДАЛИ_МЕНЯ");
ЛокальныйРезультат = ?(Найден.Пустая(), "В БАЗЕ НЕТ", "УТЕЧКА: " + Найден.Код);

Ответ: В БАЗЕ НЕТ. Запись жила ровно до конца транзакции. Это и есть контракт: внутри вызова — полноценная база, между вызовами — ни следа.

Чего обёртка НЕ закрывает

Раздел, без которого всё написанное выше вводило бы в заблуждение. Транзакция с откатом решает ровно одну проблему — сохранность данных. Остальные четыре остаются на вас.

Нагрузка. Читающий запрос агента — полноценный запрос к СУБД. Агент, которому велели «найди тормоза», с удовольствием напишет соединение двух срезов регистра на 1,89 млн строк — мы такое видели: 43 секунды исполнения. Пользователи в это время делят с ним диск и процессор. Лечится требованиями в задании: ПЕРВЫЕ N в разведочных выборках, отборы по периоду и организации, тяжёлые серии — в часы минимальной нагрузки. У нас агенты эти требования соблюдали, но проверять надо.

Блокировки. Всё выполнение живёт в одной транзакции — длинной. Если переданный код успел изменить данные (внутри транзакции — можно!), эти записи заблокированы до отката. Код, который «на пробу» перезаписывает популярный регистр и потом десять секунд что-то считает, подержит блокировку все десять секунд. Правило то же: читающие сценарии — пожалуйста, пишущие эксперименты — короткими.

Внешние эффекты. Транзакция СУБД откатывает данные. Она не откатывает: отправленное письмо, исходящий HTTP-запрос, созданный файл на сервере, COM-объект, запущенное фоновое задание. Всё это надо запрещать отдельно — у нас в задании перечислено явно: файлы, COM, исходящие соединения, фоновые задания. И это как раз тот случай, где промпт-запрет работает в паре с проверкой: журнал регистрации после прогона покажет, не было ли попыток.

Чтение чувствительного. Агент видит всё, что видит учётная запись, под которой он ходит. Зарплаты, персональные данные, себестоимость — если учётке можно, агенту можно. Отдельная учётная запись с урезанными правами — не паранойя, а гигиена. И помните, что всё прочитанное агент отправляет в облако провайдера модели — на это у вас должно быть право.

Чек-лист внедрения

1. Развернуть метод-обёртку (у нас — справочник методов Data API, у вас может быть HTTP-сервис напрямую). Проверить, что «голый» execute_code наружу не торчит.
2. Прогнать оба smoke-теста. Убедиться в ответе «В БАЗЕ НЕТ».
3. Завести агенту отдельную учётную запись с минимальными правами чтения.
4. Выдать агенту ровно один метод — обёртку. Не адрес сервиса «вообще».
5. В задании запретить: управление транзакциями, файлы, COM, исходящий HTTP, фоновые задания. Потребовать щадящие запросы.
6. После первого прогона — журнал регистрации: что читал, не пытался ли писать.

Полчаса работы. После этого фраза «а давайте спросим у ИИ, почему у нас закрытие месяца два часа идёт» перестаёт быть страшной.

Что показал боевой прогон

Четыре агента, четыре сессии в продуктивной базе, сотни выполненных фрагментов кода — от невинных 2 + 2 до серий замеров по семь прогонов тяжёлого запроса. Один агент получил 401 из-за проблем с кодировкой Basic-заголовка и полчаса честно дебажил доступ. Другой прочитал регистр на 1,89 млн строк и нашёл, почему срез последних строится на лету. Третий вычитал из метаданных, что у измерения длина 10 символов, и поймал на этом потенциальный баг сравнения ключей.

Записей в базу — ноль. Проверено журналом регистрации, а не верой в промпт.

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

Как мы гоняли четырёх агентов на одной задаче и что из этого вышло (сравнение диагнозов, замеров и хода мыслей), а также методику честного сравнения моделей на своей конфигурации — разбираем в соседних статьях цикла. Эта была про фундамент, без которого обе были бы безответственностью.