Как я передаю AI-помощника команде

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

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

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

Называю людей, которые принимают решения

Формулировка «передали в отдел» оставляет важные вопросы открытыми. Кто решает, что ответ правильный? Кто обновляет инструкцию? Кому сотрудник пишет, если документ не открывается?

Я предлагаю сначала распределить четыре роли. В небольшой команде один человек может совмещать несколько, но каждая ответственность должна быть принята явно.

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

Собираю короткую инструкцию для рабочего дня

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

• Где находится помощник и для каких задач его использовать?
• Какие данные можно вводить, а какие требуют другого порядка работы?
• Как открыть источник и проверить применимость найденного правила?
• Что обязательно проверить перед использованием черновика?
• В каких случаях остановиться и передать вопрос человеку?
• Где продолжить работу вручную и куда сообщить о проблеме?

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

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

Проверяю доступы под обычной ролью

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

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

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

Это продолжение границ полномочий помощника. Права сотрудника, права системы и право утверждать итоговое действие нужно проверить по отдельности.

Прошу сотрудника выполнить задачу самостоятельно

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

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

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

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

Включаю неудобные ситуации в обучение

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

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

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

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

Договариваюсь о переходном периоде

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

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

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

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

Фиксирую результат передачи

Для нашего условного сценария краткая запись могла бы выглядеть так:

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

Это пример содержания записи, а не свидетельство проведённой приёмки. В настоящем документе нужны фактические участники, версия и дата проверки.

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