Как безопасно пустить ИИ в боевую базу 1С: транзакция с гарантированным откатом

Есть заманчивый сценарий: пустить ИИ-агента в боевую базу 1С, чтобы он сам посмотрел данные, нашёл аномалию, посчитал показатель, разобрался в структуре. Читающий агент экономит массу времени на диагностике. Но есть и очевидный страх: агент исполняет код, а код в проде может не только читать. Одна ошибочная запись в боевую базу, и последствия придётся разгребать долго. Причём агент напишет такой код спокойным уверенным тоном: языковая модель обязана продолжить последовательность всегда, и разбор её внутреннего устройства на BSL показывает, что отказаться она не умеет в принципе.

Мы решали ровно эту задачу и пришли к паттерну, который даёт агенту читать прод и при этом технически не даёт ему туда записать. Разберём, как он устроен, и, что важнее, где его границы.

Кейс с этой же историей, но короче и с реакцией коллег в комментариях, у нас опубликован на Инфостарте.

Идея: исполнять код агента внутри транзакции, которая всегда откатывается

Механизм простой до изящества. Код, который сгенерировал агент, исполняется не напрямую, а внутри обёртки:

1. открываем транзакцию;
2. выполняем код агента (любые чтения, вычисления, обращения к данным);
3. безусловно откатываем транзакцию в конце, всегда, независимо от того, что код делал.

Если агент случайно или намеренно попытался что-то записать, запись произойдёт внутри транзакции, а откат её сотрёт. База возвращается ровно в то состояние, в котором была до запуска. При этом всё, что агент прочитал и посчитал, у нас на руках: результат вычислений мы забираем до отката.

Обёртка компактная, несколько десятков строк, и её задача одна: гарантировать, что после исполнения кода агента в базе не осталось ни одного изменения. Смысл в безусловности отката. Откат происходит не по итогу проверки “а не записал ли агент чего”, а всегда, по построению. Даже если проверка чего-то не заметила бы, откат всё равно уберёт все изменения.

На таком контуре агент у нас читал под два миллиона строк за один прогон, считал показатели, разбирал структуру, и база после этого была бита в бит той же.

Почему безусловный откат надёжнее проверок

Напрашивается альтернатива: разобрать код агента и запретить операции записи. Мы от неё отказались, и вот почему.

Разбор кода это гонка щита и меча. Способов записать в базу много, часть неочевидна, что-то прячется за косвенными вызовами, что-то появится в новой версии платформы. Любой анализатор запрещённых операций рано или поздно чего-то не увидит, и одна пропущенная запись обнулит всю защиту.

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

Честно: чего этот паттерн НЕ закрывает

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

• Нагрузку. Тяжёлый код агента внутри транзакции нагружает боевой сервер по-настоящему: читает, считает, крутит запросы. Откат убирает изменения, но не убирает потраченные CPU и IO. Запускать это в час пик так же вредно, как любой тяжёлый отчёт.
• Блокировки. Открытая транзакция на чтение больших объёмов может ставить блокировки и мешать боевым пользователям, пока она живёт. Откат в конце этого не отменяет: пока транзакция шла, она мешала.
• Внешние эффекты. Если код агента дёргает что-то за пределами базы (HTTP-запрос, запись в файл, отправку сообщения), откат транзакции это не вернёт. Транзакция управляет только данными базы, всё за её границей остаётся сделанным.
• Чтение чувствительного. Агент читает боевые данные, а значит видит ФИО, суммы, реквизиты. Откат защищает базу от изменений, но не защищает данные от того, чтобы их прочитали и отправили наружу. Это отдельная задача, и решается она обезличиванием (об этом у нас есть отдельный разбор). Только не считайте её решённой одним прогоном: на живой базе движок распознавания трижды приходилось переделывать, и последний раз он молча пропустил реквизит с настоящими номерами физлиц, отчитавшись, что база обезличена полностью - как это выглядело на трёх конфигурациях.

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

Где это применимо

Read-only доступ через откат хорош для диагностики и анализа: дать агенту посчитать показатель, найти аномалию в данных, разобрать структуру, проверить гипотезу по боевым данным без риска их испортить. Для этих задач он снимает главный страх “а вдруг запишет”. Если же показатели по боевым данным нужны руководителю регулярно, к защите от записи добавляются общие определения выручки и остатков и расчёт, который можно сверить с контрольным отчётом. Это отдельная задача, аналитика данных с нейросетями.

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

Итог

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

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

Это разбор доступа к одной базе. Когда баз становится десять, схема меняется: появляется отдельный реестр, два круга аутентификации и одна точка входа вместо десяти подключений. Как это устроено и чем приходится платить по безопасности - в статье “MCP для 1С: один сервер на десять баз”.