Один пилот удался. Как перенести ИИ в другие отделы без потери качества

Разберите первый пилот на части

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

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

Выберите второй отдел по сходству задачи

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

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

Введите версию и контрольный набор для каждого отдела

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

Не теряйте экономику поддержки

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

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

Общая платформа и разные владельцы данных

Централизовать удобно журнал, мониторинг стоимости, аварийную остановку и порядок выпуска версий. Но правила клиентского ответа, доступ к папке и метрики результата остаются у отдела. Например, поддержка может считать успехом закрытую проблему без повторного обращения, а продажи — заявку с полным контекстом для менеджера. Один общий показатель «число ответов агента» не отражает пользу ни там, ни там. Запишите локальную метрику до подключения второго отдела.

Как избежать эффекта копирования ошибок

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

Минимальная карточка нового отдела

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

Когда общий агент становится слишком сложным?

Признак — длинная инструкция с исключениями «если это отдел А, кроме случая Б, но не по пятницам». Сложность повышает риск, что правка для одного подразделения изменит поведение другого. Разделите общий слой инструментов и журналов от локальных сценариев. Возможно, нужны два агента с ясными владельцами вместо одного универсального. Решение принимайте по тестам, стоимости поддержки и числу конфликтов, а не по желанию сократить количество карточек в реестре.