Как внедрять AI-агента в российский бэк-офис через регламент, а не через демонстрацию

Демонстрация проверяет возможность, регламент — управляемость

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

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

Шаг 1. Зафиксируйте один процесс и одну единицу работы

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

Для процесса запишите:

1. какое событие запускает работу;
2. какие данные обязательны на входе;
3. какой результат считается завершённым;
4. в какой системе фиксируется результат;
5. какие случаи заведомо не входят в пилот.

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

Шаг 2. Разделите роли и ответственность

У каждой операции должен быть один владелец решения. «Команда проекта» или «бизнес» — недостаточно точные обозначения для инцидента.

Один человек может совмещать несколько ролей, но в регламенте они всё равно описываются отдельно. Так ответственность сохраняется при смене состава команды.

Шаг 3. Определите полномочия агента

Полномочия удобнее описывать по уровням. На первом пилоте выбирайте минимальный уровень, позволяющий проверить гипотезу.

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

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

Шаг 4. Составьте карту исключений

Фраза «в нестандартном случае передать человеку» неработоспособна без признаков нестандартности. Для каждого исключения укажите условие обнаружения, действие агента, получателя эскалации и допустимое время реакции.

Шаг 5. Задайте измеримые условия остановки

Стоп-условие должно срабатывать по наблюдаемому событию, а не по ощущению команды. Разделите немедленную остановку, приостановку потока и пересмотр по итогам периода.

Примеры формулировок, которые необходимо адаптировать к риску конкретного процесса:

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

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

Шаг 6. Оформите регламент как версионируемую конфигурацию

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

pilot:
  id: "backoffice-draft-v1"
  mode: "human_approval_required"
  scope:
    allowed_categories:
      - "типовое_внутреннее_обращение"
    forbidden_actions:
      - "external_send"
      - "payment"
      - "delete_record"
      - "change_bank_details"

roles:
  process_owner: "ROLE_PROCESS_OWNER"
  operator: "ROLE_OPERATOR"
  technical_owner: "ROLE_TECH_OWNER"
  controller: "ROLE_CONTROLLER"

exceptions:
  missing_input:
    action: "stop_and_escalate"
    code: "INPUT_MISSING"
  out_of_scope:
    action: "manual_queue"
    code: "OUT_OF_SCOPE"

logging:
  record_input_reference: true
  record_policy_version: true
  record_agent_decision: true
  record_human_decision: true
  secrets_in_logs: false

stop_conditions:
  unauthorized_data_transfer:
    threshold: 1
    action: "immediate_stop"
  forbidden_action:
    threshold: 1
    action: "immediate_stop"
  critical_error_rate:
    threshold: "SET_BEFORE_LAUNCH"
    sample_size: "SET_BEFORE_LAUNCH"
    action: "switch_to_manual"

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

Шаг 7. Проведите настольную проверку до реального потока

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

Минимальный набор сценариев:

1. нормальная задача в границах пилота;
2. пропущенное обязательное поле;
3. противоречивые данные;
4. задача вне области применения;
5. недоступность одной из систем;
6. ошибочный результат, замеченный до подтверждения;
7. ошибка, обнаруженная после действия человека;
8. срабатывание каждого стоп-условия.

Проверка считается пройденной не тогда, когда агент всегда отвечает правильно, а когда команда корректно обрабатывает каждый исход.

Как проверить результат пилота

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

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

Типовые ошибки

• Пилот без владельца процесса. Техническая команда вынуждена принимать решения о допустимом бизнес-риске.
• Скрытое расширение области. Успешный сценарий начинают применять к новым категориям без повторной оценки исключений.
• Проверка «на глаз». Исправления оператора не классифицируются, поэтому качество невозможно измерить.
• Общая кнопка остановки без процедуры. Не определено, кто имеет право её использовать и что произойдёт с незавершёнными задачами.
• Логи вместо управляемого журнала. Записи есть, но в них нельзя связать вход, версию правил, ответ и человеческое решение.
• Персональные данные в тестовых примерах. Для настольной проверки используйте синтетические данные; рабочие данные допускайте только после согласования режима обработки.

Ограничения подхода

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

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

Готовность к запуску: короткий чек-лист

• Определены событие старта, единица работы и результат.
• Назначены владелец процесса, оператор, технический владелец и контролёр.
• Разрешённые и запрещённые действия перечислены явно.
• Исключения имеют коды, маршруты и сроки реакции.
• Для каждой ошибки назначен ответственный за следующее действие.
• Стоп-условия измеримы и утверждены до запуска.
• Есть проверяемый журнал и версия регламента.
• Отработан возврат незавершённых задач в ручной процесс.
• Метрики пилота сопоставимы с исходным ручным процессом.

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