Сценариум

Работа уходит к агентам. Как организация будет принимать их работу?

Чего не показывает дорожная карта AI-продукта

Агент начинает выполнять работу

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

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

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

С этих строк карта описывает уже не только функции продукта. Она описывает перераспределение работы между человеком и AI. И об этом перераспределении не говорит ничего. Что меняется при передаче агенту части работы?

Проверять недостаточно

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

Но проверка применяет критерии приёмки. Она их не создаёт.

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

Раньше организация принимала исполнителя. Теперь ей приходится принимать работу.

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

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

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

Часть проверки можно передать агентам: сопоставить результат с требованием, найти расхождение, отбраковать или эскалировать. Но агент-контролёр тоже получает критерий извне, а не изобретает его.

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

Критический путь смещается

Проблема не только в том, что критерии приёмки не зафиксированы. Конфигурация исполнения меняется быстрее, чем организация успевает её заново принять.

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

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

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

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

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

Но что именно нужно зафиксировать, чтобы критерии приёмки пережили смену модели, платформы или другого исполнителя?

Что переживёт смену исполнителя

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

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

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

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

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

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

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

Спецификация нужна не везде

Не любую работу, передаваемую AI, нужно доводить до уровня спецификации. Её создание и поддержание тоже требуют времени и внимания.

Спецификация нужна прежде всего там, где агент самостоятельно принимает решения или совершает действия: меняет данные, запускает операции, взаимодействует с клиентами или другими системами.

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

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

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

Это практический выбор, а не обязательная ступень зрелости.

Описать — не значит проверить

Критерий записан. Достаточно ли этого?

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

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

Масштабировалось не только производство. Масштабировалась приёмка.

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

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

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

Описание делает передачу работы возможной. Дешёвая независимая проверка делает возможным массовое исполнение.

Критерию нужен владелец

Переносимой бывает и ошибка.

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

Проблема в том, что критерий — не объективная истина. Это принятое определение того, что считать годным результатом, допустимым действием или приемлемым риском. Оно может быть неполным, устареть или не учитывать отложенные последствия.

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

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

Что добавить к продуктовой дорожной карте

Вернёмся к дорожной карте продукта.

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

Карта появляется, когда ответы зафиксированы, связаны с владельцами и проверены на данных реального исполнения. Как это выглядит на практике, проще показать на одной строке.

Продуктовая формулировка: автономный агент выполняет задачу от начала до конца.

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

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

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

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

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