Кейс: автоматизация без попытки «добавить ИИ везде»

Немецкое независимое издательство Büchner Verlag раз в месяц собирало рассылку о новых книгах вручную. Сотрудник входил на сайт, находил новинки по категориям, переносил обложки, вводные тексты и стандартные сведения о книгах в шаблон, добавлял или удалял секции, сохранял версию и передавал её на согласование.

В кейсе европейского цифрового инновационного хаба EDITH описана автоматизация этого процесса с помощью Emma — RPA-ассистента компании WIANCO OTT Robotics. Официальная карточка опубликована 26 сентября 2024 года. По данным авторов кейса, полный цикл подготовки сократился в среднем с двух дней до 25 секунд. При 12 выпусках в год и средней зарплате €38 000 расчётная экономия составила 24 рабочих дня, или около €4 145 в год.

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

Что именно делает робот

В описанном процессе автоматизация запускается 15-го числа каждого месяца. Робот входит в административную часть сайта, открывает шаблон рассылки и проверяет категории на наличие новинок. Для каждой новой книги он переносит в нужный раздел обложку, вводный текст и стандартную карточку, меняет структуру шаблона, сохраняет черновик и уведомляет руководство издательства по электронной почте.

Критически важная деталь: рассылка не отправляется подписчикам автоматически. Редакция получает готовый черновик, проверяет его, утверждает и только после этого запускает отправку. Человек отвечает за состав выпуска, смысл, корректность данных и репутационный результат.

С технической точки зрения большую часть задачи можно описать без слова «интеллект»:

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

Такая постановка снижает пространство ошибок. Если правило можно выразить таблицей или условием, его лучше не передавать вероятностной модели.

API лучше браузера, но браузер иногда неизбежен

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

Поэтому порядок выбора интеграции должен быть таким:

1. Использовать API CMS и платформы рассылок, если они доступны.
2. Если API нет, получать данные из стабильного экспорта или внутренней базы.
3. Применять браузерную автоматизацию только к тем шагам, для которых нет программного интерфейса.

В браузерном сценарии нужны устойчивые селекторы и явные контракты интерфейса. Документация Playwright рекомендует ориентироваться на роли, подписи и специальные тестовые идентификаторы, а не на длинные цепочки CSS или XPath, зависящие от положения элемента в DOM. Автоматические ожидания помогают дождаться видимости и доступности элемента, но не заменяют проверку бизнес-результата.

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

Идемпотентность: защита от двойной рассылки

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

Для каждого выпуска нужен устойчивый ключ: год и месяц, идентификатор шаблона и дата отсечения каталога. Для каждой книги — внутренний ID или ISBN вместе с ключом выпуска. Перед созданием робот проверяет, существует ли черновик с тем же ключом, и продолжает его вместо нового.

Отдельно фиксируются статусы:

  • `collecting` — новинки собраны, но карточки ещё не проверены;
  • `draft_ready` — шаблон создан и прошёл автоматическую валидацию;
  • `approved` — ответственный сотрудник утвердил конкретную версию;
  • `sent` — провайдер рассылки подтвердил отправку;
  • `failed` — выполнение остановлено, известен последний подтверждённый шаг.

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

Автоматические проверки до редактора

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

  • у каждой книги есть название, обложка, аннотация, категория и рабочая ссылка;
  • одна книга не встречается дважды;
  • в выпуск не попали позиции позже даты отсечения;
  • изображения загружаются и имеют допустимые размеры;
  • число карточек совпадает с числом найденных новинок;
  • шаблон не содержит пустых обязательных секций;
  • ссылки ведут на тот же домен и нужную карточку;
  • создана текстовая версия письма;
  • тестовое письмо доставлено на внутренний адрес;
  • внешний запуск заблокирован до явного одобрения.

Где уместен генеративный ИИ

LLM может быть вторым слоем, а не сердцем процесса. Она способна предложить тему письма, короткое вступление, альтернативный текст для обложки или варианты подводки к разделу. Но модель должна получать только утверждённые структурированные данные выпуска и возвращать черновик в отдельные поля.

Опасно разрешать модели:

  • самостоятельно выбирать книги без прозрачных правил;
  • изменять названия, авторов, цены, даты и ссылки;
  • публиковать неподтверждённые характеристики;
  • отправлять письмо без просмотра;
  • использовать персональные данные подписчиков в промпте без необходимости.

NIST в профиле управления рисками генеративного ИИ рекомендует связывать применение модели с измеримыми рисками, проверкой и ответственностью. Для рассылки это означает журнал исходных данных и версии промпта, проверку фактов, фильтр запрещённых утверждений и сохранение человеческого решения.

Если тексты короткие и формульные, локальная модель может работать внутри контура компании. Но для одного ежемесячного вступления она не обязана окупать собственную инфраструктуру. Сначала стоит измерить объём задачи и цену внешнего API, а чувствительные данные вообще не передавать без основания.

Безопасность и доступы

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

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

Автоматизация не должна удалять обязательные элементы шаблона: RFC 8058, например, описывает механизм однокликового отказа от подписки.

Экономика кейса и модельный расчёт

Арифметика опубликованного кейса прозрачна: €38 000 делятся на 220 рабочих дней, затем дневная стоимость умножается на 24 дня в год. Получается около €4 145. Но «два дня подготовки» могут означать календарную длительность с ожиданиями, а не 16 часов непрерывной работы. Перед покупкой лицензии нужно провести собственный хронометраж.

Модельная годовая выгода равна:

`сэкономленные часы × полная стоимость часа + предотвращённые ошибки + ценность ускорения`.

Из неё вычитаются лицензия, разработка, поддержка, тестовый контур, время согласования и ремонты после изменений интерфейса. Если робот экономит 24 человеко-дня, но требует ежемесячно день специалиста на восстановление, эффект уменьшается вдвое.

Финансовый паспорт проекта содержит:

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

Пилот: три исторических выпуска и один живой

Начинать можно без доступа к подписчикам и без права отправки.

1. Опишите процесс по шагам и разделите правила от редакционных решений.
2. Возьмите три прошлых выпуска и исходный каталог на соответствующие даты.
3. Настройте создание черновика в тестовой среде.
4. Сравните состав, карточки, ссылки и макет с тем, что было отправлено вручную.
5. Смоделируйте сбой после сохранения и убедитесь, что повторный запуск не создаёт дубль.
6. Проведите один живой месяц в теневом режиме: робот готовит вариант, сотрудник выполняет обычный процесс отдельно.
7. Измерьте чистое рабочее время, число исправлений, длительность проверки и стоимость поддержки.

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

Что взять руководителю

Кейс Büchner Verlag показывает зрелый принцип автоматизации: робот делает повторяемую сборку, правила проверяют данные, редактор утверждает выпуск. Генеративный ИИ добавляется лишь в те поля, где нужен вариант текста, и не получает право менять факты или отправлять письмо.

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