После завершения пилота за ИИ-агента должен отвечать один владелец сервиса, наделённый полномочиями поддерживать работу агента, ограничивать её, приостанавливать или завершать. Он не заменяет специалистов по данным, безопасности, модели, инструментам и поставщикам. Его задача состоит в том, чтобы координировать их решения и отвечать за работу сервиса в целом, когда интересы и ограничения расходятся.
Разделите общую ответственность и специальные роли
Бизнес-владелец определяет ожидаемый результат, допустимый уровень ошибок и бюджет. Владелец сервиса отвечает за агента как за рабочий сервис. Владелец данных разрешает источники и правила обработки. Служба безопасности контролирует доступ и порядок реагирования на инциденты. Техническая команда поддерживает интеграции, наблюдаемость и восстановление. Закупки следят за обязательствами поставщика.
Назначения должны отвечать на конкретные вопросы. Кто разрешает новый источник? Кто расширяет права агента на использование инструмента? Кто согласовывает смену модели? Кто останавливает внешнюю отправку? Кто объявляет инцидент и кто отвечает за вывод сервиса из эксплуатации? Указания отдела недостаточно: нужна конкретная роль с полномочиями принять решение.
Архитектура тоже влияет на ответственность. Материал про архитектуру корпоративного портала показывает ценность опорных систем и границ компонентов. Для агента нужно так же видеть источник истины, интеграции, владельцев и точки, где действие переходит между сервисами.
Превратите передачу в испытание
Пилотная команда передаёт не только код и демонстрацию. Эксплуатационной команде нужны цель, архитектурная схема, перечень данных, учётные записи, права, версии модели и инструкций, контракты подключённых инструментов, сигналы и журналы мониторинга, правила согласования, известные сбои, порядок отката, контакты поставщика, расходы и нерешённые риски.
Доступы проверяются до ухода разработчиков. Чеклист защиты данных компании помогает проверить состав активов, права доступа, обновления и резервное копирование. Для агента дополнительно проверьте отзыв прав служебной учётной записи, остановку заданий по расписанию и незавершённые операции.
Проведите испытание отказа. Отзовите ключ, сделайте источник недоступным, верните повреждённый ответ инструмента, отклоните согласование и уберите основного оператора. Принимающая команда должна обнаружить проблему, сохранить сведения, перейти в безопасный режим и восстановить работу без помощи создателей пилота.
Финансируйте работу и завершение
Бюджет нужен не только на обращения к модели. Учтите мониторинг, реагирование, изменения со стороны поставщика, оценку качества, проверку безопасности, поддержку пользователей и вывод сервиса. Если эти работы не имеют владельца и времени, ответственность существует только на схеме.
Наблюдаемость должна помогать дежурной команде. Статья о том, готов ли центр мониторинга к скорости атак, подчёркивает важность контекста события. Для агента сигнал связывает пользователя, модель, инструмент, согласование, действие и результат, чтобы оператор видел причину, а не только ошибку.
Порядок завершения определите заранее. Нужно остановить расписания, отозвать права, выгрузить нужные записи, удалить данные, сохранить обязательные доказательства, уведомить пользователей и сверить незаконченные действия. Агент без проверенного сценария завершения работы не находится под полным управлением, даже если обычная работа выглядит стабильной.
После передачи проводите короткий эксплуатационный разбор. Владелец сервиса выносит на разбор нерешённые сбои, изменения доступа, уведомления поставщика, жалобы пользователей, результаты контрольных сценариев, отклонения от бюджета и ближайшие продления контрактов. Для каждого пункта требуется решение или конкретный следующий шаг с ответственным. Общая отметка «система работает стабильно» скрывает зависимость от одного разработчика, ручное исправление данных или обещание поддержки, для которого не выделена команда.
Первые разборы лучше проводить, пока создатели пилота доступны для уточнений, но выполнение уже лежит на принимающей стороне. Пусть новая команда сама меняет ключ, ограничивает инструмент, обновляет инструкцию, восстанавливает очередь и готовит уведомление о сбое. Создатели наблюдают и фиксируют пробелы, а не выполняют работу вместо неё. Когда накопится достаточная история эксплуатации, частоту разборов можно привязать к событиям и уровню риска. Существенная смена модели или источника требует внепланового разбора, а стабильная работа не должна поддерживать бесконечный режим пилотных встреч.
Закрепите передачу коротким документом приёмки. В нём принимающий владелец подтверждает область сервиса, доступ к рабочим материалам, результаты испытаний, открытые ограничения, бюджет, график поддержки и право остановки. Нерешённый пункт получает ответственного и срок, а не исчезает в приложении. Если критическая функция остаётся у пилотной команды, переход ещё не завершён. Решение продолжать работу при известном пробеле принимает тот, кто вправе принять соответствующий остаточный риск для бизнеса. Документ обновляют при смене владельца, существенном расширении области и переводе сервиса на другого поставщика.
Частые вопросы
Назначьте одного владельца сервиса с полномочиями поддерживать, ограничивать, приостанавливать или завершать работу агента и координировать остальные роли.
Передайте цель, архитектуру, данные, доступы, версии, инструменты, журналы мониторинга, правила согласования, известные сбои, порядок восстановления, расходы и риски.
Не единолично. Техническая команда поддерживает систему, бизнес-владелец определяет ожидаемый результат, а владелец сервиса связывает эксплуатационные решения.
Когда принимающая команда умеет запустить агента, контролировать его работу, ограничивать права, восстанавливать и поддерживать сервис, управлять бюджетом и безопасно выводить его из эксплуатации.
Чтобы проверить роли, передачу и готовность к эксплуатации, закажите аудит кибербезопасности до расформирования пилотной команды.
