Как пустить ИИ-агента в боевую систему и не наделать необратимого?

Я технический директор университета Зерокодер. Мы отдали ИИ-агенту работу внутри боевой системы — ту, что съедала у команды три рабочих дня в неделю.

Самой сложной частью оказалась не сама автоматизация, а предохранитель к ней.

Когда мы готовим вебинарную или автовебинарную воронку, проджекты присылают ТЗ — документ, в котором собрана пачка писем - обычно от 10 до 20.

Каждое письмо нужно собрать отдельно под каждый канал: почта, Telegram, MAX, иногда ВКонтакте — зависит от того, какую воронку строим. Возьмём средний случай, семнадцать писем на четыре канала: получается 68 рассылок на один вебинар.

Письмо на почту верстается в HTML, там своя сложность с визуальным оформлением, поэтому всё делается кодом. Одно такое письмо — минут десять. Бот-каналы проще, две-три минуты.

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

Потом количество запусков выросло. Сейчас это четыре, иногда пять вебинаров в неделю. Умножаем: 340 рассылок, которые надо собрать примерно за пару дней. По времени — около 25 часов ручной работы. Три полных рабочих дня, которых у команды просто нет.

К финальному решению мы пришли не сразу, а четырьмя ступенями. Каждая снимала боль предыдущей и обнажала следующую.

1. Руками. Человек верстает HTML каждого письма.

2. Нейросеть пишет код. Первая ступень: HTML-письмо генерирует модель, человек проверяет и вставляет.

3. Программа, которая верстает. Тексты на входе, готовый HTML по нашей дизайн-системе на выходе. Ручной труд ушёл из вёрстки, но остался в самом нудном — создать 68 рассылок в системе, каждую руками.

4. Агент, который создаёт рассылки сам. Вот тут и начинается интересное.

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

Первое, что спрашивает любой технический человек: зачем гонять браузер, если есть API.

Затем, что нужного метода в нём нет. Публичный API нашей платформы умеет работать с пользователями, заказами и выгрузками — со всем, что касается данных. А создание и редактирование рассылок живёт только в админке, наружу оно не выведено. Хочешь сделать рассылку программно — не можешь, метода не существует.

Когда у системы нет API под твою задачу, вариантов ровно три:

- ждать, пока вендор его сделает. Срок неизвестен и от тебя не зависит

- не автоматизировать. И дальше платить 25 часов в неделю

- автоматизировать интерфейс. То есть посадить агента нажимать те же кнопки, которые нажимал человек

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

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

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

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

А действие тут необратимое, потому что отправленную рассылку не откатишь и «извините, не читайте» никому не напишешь. Одно неверное нажатие — и письмо ушло всем, кто попал в выборку.

Поэтому предохранитель проектировался раньше функциональности. Он состоит из трёх уровней, и важен именно третий.

Уровень первый: агент создаёт только черновики. Кнопку «готово к отправке» он не нажимает никогда. Запуск остаётся полностью за человеком.

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

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

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

Это называется fail-closed: при поломке защиты система не открывается, а закрывается. Пока агент в принципе способен нажать кнопку, обещание не нажимать не стоит ничего — спокойно спишь только тогда, когда он этого не может физически.

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

— проджект отдаёт ТЗ, из документа выгружается архив в формате `.md`

— специалист открывает панель. Она за паролем и не торчит в открытый интернет.

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

— Жмёт кнопку

Через минуту в системе лежат 68 черновиков с правильными именами и проставленными метками. Дальше человек проверяет и запускает сам.

Первая версия закрывала идеальный сценарий. Реальность внесла правки.

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

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

Редактирование уже созданных писем. У каждой рассылки есть свой id. Система запоминает соответствие «имя рассылки → id», поэтому повторная загрузка не плодит дубли, а обновляет то, что уже создано. Правки в готовой воронке перестали быть отдельным адом.

Приём готового HTML. Если письмо сверстано где-то снаружи, его можно отдать по API, минуя разбор и вёрстку. Вот это оказалось важнее, чем я думала.

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

Моя сотрудница после прохождения курса по Claude Code написала собственную программу автоматической вёрстки анонсов. И приделала к ней одну кнопку, которая отправляет готовый HTML в мою систему по API, а та создаёт рассылку.

Три часа превратились в 15 минут. Дальше остаётся только выставить сегмент — автоматизацией этого шага занимаемся сейчас.

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

- 68 рассылок на один вебинар: около пяти часов ручной работы → одна минута - на пяти запусках в неделю освободилось порядка 25 часов, три рабочих дня

- анонс: 3 часа → 1 час - случайная отправка невозможна архитектурно, а не «по договорённости не нажимать»

Если будете пускать агента в боевую систему — начните с предохранителя, а не с функциональности. Автоматизация, которая делает в проде необратимые вещи, стоит ровно столько, сколько стоят её ограничения.