Как безопасно пустить ИИ в боевую базу 1С: транзакция с гарантированным откатом
Иван Недомолков · Опубликовано:
Есть заманчивый сценарий: пустить ИИ-агента в боевую базу 1С, чтобы он сам посмотрел данные, нашёл аномалию, посчитал показатель, разобрался в структуре. Читающий агент экономит массу времени на диагностике. Но есть и очевидный страх: агент исполняет код, а код в проде может не только читать. Одна ошибочная запись в боевую базу, и последствия придётся разгребать долго. Причём агент напишет такой код спокойным уверенным тоном: языковая модель обязана продолжить последовательность всегда, и разбор её внутреннего устройства на BSL показывает, что отказаться она не умеет в принципе.
Мы решали ровно эту задачу и пришли к паттерну, который даёт агенту читать прод и при этом технически не даёт ему туда записать. Разберём, как он устроен, и, что важнее, где его границы.
Кейс с этой же историей, но короче и с реакцией коллег в комментариях, у нас опубликован на Инфостарте.
Идея: исполнять код агента внутри транзакции, которая всегда откатывается
Механизм простой до изящества. Код, который сгенерировал агент, исполняется не напрямую, а внутри обёртки:
- открываем транзакцию;
- выполняем код агента (любые чтения, вычисления, обращения к данным);
- безусловно откатываем транзакцию в конце, всегда, независимо от того, что код делал.
Если агент случайно или намеренно попытался что-то записать, запись произойдёт внутри транзакции, а откат её сотрёт. База возвращается ровно в то состояние, в котором была до запуска. При этом всё, что агент прочитал и посчитал, у нас на руках: результат вычислений мы забираем до отката.
Обёртка компактная, несколько десятков строк, и её задача одна: гарантировать, что после исполнения кода агента в базе не осталось ни одного изменения. Смысл в безусловности отката. Откат происходит не по итогу проверки “а не записал ли агент чего”, а всегда, по построению. Даже если проверка чего-то не заметила бы, откат всё равно уберёт все изменения.
На таком контуре агент у нас читал под два миллиона строк за один прогон, считал показатели, разбирал структуру, и база после этого была бита в бит той же.
Почему безусловный откат надёжнее проверок
Напрашивается альтернатива: разобрать код агента и запретить операции записи. Мы от неё отказались, и вот почему.
Разбор кода это гонка щита и меча. Способов записать в базу много, часть неочевидна, что-то прячется за косвенными вызовами, что-то появится в новой версии платформы. Любой анализатор запрещённых операций рано или поздно чего-то не увидит, и одна пропущенная запись обнулит всю защиту.
Транзакция с безусловным откатом работает иначе: ей всё равно, какими способами код пытался записать. Что бы он ни сделал, откат это сотрёт. Защита не зависит от полноты списка запрещённых операций, а значит её нельзя обойти тем, чего этот список не предусмотрел.
Честно: чего этот паттерн НЕ закрывает
Тут начинается самое важное, и это ровно то, о чём обычно молчат. Транзакция с откатом защищает от одного: от остаточных изменений в данных. Всё остальное она не закрывает, и делать вид, что закрывает, опасно.
- Нагрузку. Тяжёлый код агента внутри транзакции нагружает боевой сервер по-настоящему: читает, считает, крутит запросы. Откат убирает изменения, но не убирает потраченные CPU и IO. Запускать это в час пик так же вредно, как любой тяжёлый отчёт.
- Блокировки. Открытая транзакция на чтение больших объёмов может ставить блокировки и мешать боевым пользователям, пока она живёт. Откат в конце этого не отменяет: пока транзакция шла, она мешала.
- Внешние эффекты. Если код агента дёргает что-то за пределами базы (HTTP-запрос, запись в файл, отправку сообщения), откат транзакции это не вернёт. Транзакция управляет только данными базы, всё за её границей остаётся сделанным.
- Чтение чувствительного. Агент читает боевые данные, а значит видит ФИО, суммы, реквизиты. Откат защищает базу от изменений, но не защищает данные от того, чтобы их прочитали и отправили наружу. Это отдельная задача, и решается она обезличиванием (об этом у нас есть отдельный разбор). Только не считайте её решённой одним прогоном: на живой базе движок распознавания трижды приходилось переделывать, и последний раз он молча пропустил реквизит с настоящими номерами физлиц, отчитавшись, что база обезличена полностью - как это выглядело на трёх конфигурациях.
Паттерн отвечает ровно на один вопрос: “не останется ли после агента изменений в базе”. На него он отвечает твёрдым нет. На остальные вопросы безопасности отвечать надо отдельно.
Где это применимо
Read-only доступ через откат хорош для диагностики и анализа: дать агенту посчитать показатель, найти аномалию в данных, разобрать структуру, проверить гипотезу по боевым данным без риска их испортить. Для этих задач он снимает главный страх “а вдруг запишет”. Если же показатели по боевым данным нужны руководителю регулярно, к защите от записи добавляются общие определения выручки и остатков и расчёт, который можно сверить с контрольным отчётом. Это отдельная задача, аналитика данных с нейросетями.
Он не годится, когда агент должен что-то менять в базе по-настоящему: тут нужен обычный контролируемый процесс с ревью, а не песочница с откатом.
Итог
Пускать ИИ в боевую 1С можно, если чётко понимать, от чего именно вы защитились. Транзакция с безусловным откатом закрывает риск остаточных изменений полностью и надёжно, потому что не полагается на полноту проверок. А нагрузку, блокировки, внешние эффекты и утечку прочитанного она не закрывает, и это надо держать в голове.
Мы такие контуры и строим: безопасный доступ инструментов к продуктивным базам 1С для диагностики, где риск для данных снят по построению. Если нужен внешний взгляд на вашу базу без риска для неё, посмотрите нашу услугу обслуживания баз 1С: мы работаем с продом аккуратно и с гарантиями, а не на авось.
Это разбор доступа к одной базе. Когда баз становится десять, схема меняется: появляется отдельный реестр, два круга аутентификации и одна точка входа вместо десяти подключений. Как это устроено и чем приходится платить по безопасности - в статье “MCP для 1С: один сервер на десять баз”.
