Материал VOSHOD. Практическая памятка для руководителей и владельцев бизнес-процессов. Подготовлено с использованием ИИ; пример ниже условный и не описывает клиентский проект.

Зачем учитывать изменения

ИИ-помощник может продолжать отвечать уверенно после того, как компания изменила тариф, срок доставки или порядок возврата. Проверка качества при запуске не заменяет проверку актуальности. Полезно заранее определить, как новое бизнес-правило попадёт в систему и кто убедится, что прежнее правило больше не используется.

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

Разделите три даты

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

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

Проверяйте всю цепочку

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

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

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

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

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

Договоритесь о возврате к предыдущей версии

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

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

Короткий шаблон записи

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

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

О VOSHOD: официальный сайт. Для связи: Telegram-бот VOSHOD.