Кто несет ответственность за ИИ-агента в вашей компании: шесть обязанностей и те, кто за них отвечает.
Кто в вашей компании управляет ИИ-агентом? Рассматриваются вопросы, связанные с отсутствием положений по агентам в документе SR 26-2, шестью ответственными должностями, способами назначения сотрудников из существующих команд и повседневным управлением.
Источники: Who Owns What When Your Company Deploys an AI Agent: Six Responsibilities, and Which Teams Hold Them
Агентные ИИ — это программное обеспечение, которое самостоятельно выбирает последовательность действий и вызывает необходимые инструменты вместо того, чтобы следовать заранее заданному скрипту. Когда такое программное обеспечение используется в компании, возникает простой вопрос: кто из людей несет за него ответственность?
Регулирующие органы пока не пришли к единому мнению по этому вопросу. В совместном письме под номером SR 26-2 от 17 апреля 2026 года Федеральная резервная система и Управление казначейства отменили ранее действовавшие рекомендации по управлению рисками моделей SR 11-7, согласно которым банки действовали с 2011 года. В том же письме были отменены собственные бюллетени Управления казначейства по этой теме, датируемые 1997 годом. В примечании к письму говорится, что генеративные и агентные ИИ не подпадают под действие этих рекомендаций. Кроме того, понятие «владельца модели», которое подробно описывалось в старом документе, в новом вовсе не упоминается.
Пять месяцев ранее Сингапур пошел другим путем. Предложенные Валютным управлением Сингапура руководящие принципы управления рисками с использованием ИИ, консультации по которым завершились в январе 2026 года, и по состоянию на момент написания статьи окончательная версия еще не существовала, прямо охватывают агентов ИИ. В них предупреждается, что агент с доступом к системе может совершать действия, противоречащие бизнес-целям или интересам клиентов, и предлагается проводить независимую проверку, то есть рассмотрение специалистами, которые не создавали систему, прежде чем что-либо с высоким уровнем риска будет введено в эксплуатацию. Этот документ пока не является законом и будет обязательным только для лицензированных учреждений в одной юрисдикции.
В обоих документах не указано, кто внутри компании несет ответственность за агента после его запуска, и этот пробел нельзя оставлять без внимания регуляторов. Программное обеспечение, выполняющее действия, требует четких границ действий, то есть границы, разделяющей то, что оно может делать самостоятельно, и то, что требует участия человека. Обеспечение соблюдения этих границ — это техническая задача. Определение того, кто несет ответственность, — это организационный вопрос, и ни один документ его не регулирует. Далее рассматриваются все возможные действия агента и ошибки, которые он может совершить, и для каждого из них указывается лицо, ответственное за них. Рассматриваются также те, кто дает разрешение на запуск, способы заполнения должностей из существующих команд, что включает в себя эксплуатация агента после запуска и что должны знать разработчики. В качестве источников используются регуляторные документы, исследования, опубликованные с 2024 года, а также компании, подтвердившие свою причастность к конкретным утверждениям.
Шесть обязанностей, шесть ответственных лиц
В процессе разработки агент создает шесть обязанностей, и для каждой из них требуется ответственный владелец. Представьте себе диаграмму обязанностей: ответственное лицо несет ответственность за результат, лицо, выполняющее работу, фактически ее выполняет, а лицо, к которому обращаются за советом, предоставляет мнение, но не имеет окончательного слова.
- Бизнес и область деятельности. Владелец бизнеса и эксперты в данной области. Владелец несет ответственность за конкретный сценарий использования, а один из экспертов одновременно выступает в роли стандартного владельца — человека, хорошо разбирающегося в данной области и способного определить, что является правильным.
- Продукт и архитектура. Архитектор, менеджер продукта и специалист по проектированию интерфейсов.
Внутренний аудит не входит в этот список, поскольку в документе SR 26-2 говорится, что он обычно не дублирует деятельность, связанную с рисками моделей. Несколько компаний, упомянутых ниже (Kaiser Permanente, Thomson Reuters, Morgan Stanley), используют инструменты для составления и поиска информации вместо полностью автономных агентов, что делает их наиболее близкими к этому понятию публичными аналогами.
Владелец бизнеса: утверждение действий агента
Это утверждение касается объема деятельности, денежных порогов и клиентов, с которыми агент не имеет права взаимодействовать, причем все это классифицируется в зависимости от уровня риска, как предлагается в Сингапуре. Оно также включает в себя вопросы финансирования системы и ее последующего вывода из эксплуатации. У банков есть частичный прецедент для выполнения этой роли в рамках бизнеса. Согласно руководству OCC за 2021 год, в соответствии с документом SR 11-7 владелец модели обычно находился в бизнес-подразделении, хотя это и не было общим правилом, а в редакции 2026 года эта роль была упразднена без указания чего-либо взамен.
Практические аргументы имеют большее значение, чем прецеденты. Каждое решение, принимаемое при утверждении проекта — будь то установление пороговых значений, исключение определенных сегментов клиентов или определение даты завершения работы — подразумевает компромисс между доходами или качеством услуг и рисками. Единственный, кто может принимать такие решения и нести за них ответственность, — это тот, кто отвечает за итоговый результат. Человек, занимающий эту должность, должен иметь как бюджет, так и возможность прекратить проект, причем только владелец бизнеса обладает обоими элементами: риски могут остановить то, на что нет финансирования, а инженеры могут создать то, что невозможно остановить. Если передать полномочия инженерам, они смогут утверждать собственные рамки работы, а если — отделу управления рисками, никто не будет нести ответственность за положительные результаты. Формулировки Сингапура указывают на то же самое, поскольку они определяют вред с точки зрения бизнес-целей и интересов клиентов, причем только бизнес может определить эти цели. Рекомендации Гонконга возлагают ответственность на совет директоров.
Архитектор: ответственный за дизайн
Дизайн формируется там, где агент останавливается и вступает в игру человек. Он включает в себя процесс, который следует агент, точки передачи задачи человеку и разрешения, которые препятствуют дальнейшему выполнению. Последние два элемента вместе образуют конкретные границы действий. Две компании разместили точки передачи в одном и том же месте: врачи Kaiser Permanente редактируют черновик, созданный инструментом Ambient-Scribe, прежде чем он попадёт в медицинскую карту, а, согласно их собственному заявлению, инструмент Debrief от Morgan Stanley позволяет советнику отредактировать краткое описание встречи перед тем, как что-либо будет сохранено в базе данных клиентов. Инженеры или поставщики могут создавать модель разрешений и интерфейс. Тем не менее архитектор остаётся ключевой фигурой, поскольку выбор момента передачи задачи — это дизайнерское решение, которое должно соблюдаться независимо от того, кто пишет код.
Ответственный за стандарты: разработка критериев
Рубрика — это чек-лист, указывающий, что должно входить в правильный ответ. В Thomson Reuters старшие юристы высшего уровня потратили месяцы на разработку рубрик для приложения для поиска информации. Подводя итоги, они пришли к выводу, что хороший ответ содержит пятнадцать необходимых компонентов, тогда как ответ, кажущийся правдоподобным, — девять. Только юрист может отличить пятнадцать от девяти, что означает, что разработка рубрик требует времени специалиста в данной области, а также единоличного ответственного, поскольку критерии меняются, когда оценку проводят несколько человек. Исследование, посвящённое проверке инструментов для оценки больших языковых моделей, показало, что критерии начинают смещаться сразу после начала оценки, и исследование Шрейи Шанкар и Адитьи Парамесварана о пользователях инструментов для запроса данных пришло к тому же выводу, отметив, что бремя проверки ложится на пользователя.
Установление стандартов и их соблюдение — это два разных процесса. Оценка, то есть ежедневный цикл анализа результатов и ошибок, находится в ведении инженеров и специалистов по данным. Они разрабатывают механизмы оценки, создают необходимый код для выполнения тестовых случаев и оценки результатов, а также изучают возникающие сбои. Затем специалист по проверке анализирует уровень покрытия кода и калибровку механизмов оценки, не запуская снова тесты команды по разработке.
Эксплуатация: поддержание работоспособности
После запуска работа включает в себя мониторинг уровня покрытия кода в режиме 24/7, обработку сигналов тревоги, процедуры выключения и восстановления системы, повторное выполнение набора тестов на обнаружение регрессий (тестов, которые запускаются после каждой изменения) и отслеживание уровня использования ресурсов и затрат. В процесс участвует представитель бизнеса, поскольку некоторые сигналы тревоги связаны с бизнес-решениями. Планирование, определение уровней серьезности сигналов и процедуры их уровневания находятся в ведении ответственного за эксплуатацию, который является инженером.
Валидатор: проверка перед запуском
Проверка валидатором включает три этапа. Сначала он ищет признаки внедрения команд (злонамеренных инструкций, встроенных в материалы, которые читает агент), а также несанкционированные вызовы инструментов. Затем он анализирует личные данные, попадающие в отчет агента — лог его действий по шагам. Кроме того, он следит за людьми, которые утверждают действия агента.
Менеджер поставщика: контроль за контрактом
Место для пользователя появляется только тогда, когда компания осуществляет покупку. Затем поставщик создаёт часть системы, запускает её функционирование и генерирует доказательства, которые должен проверить верификатор; при этом ответственность остаётся на прежнем месте. Тем временем все остальные владельцы зависят от того, что может предоставить только контракт. Верификатору необходимы права на аудит. Операционной части системы требуется заранее уведомление о изменениях в модели, поскольку именно оно запускает процедуру тестирования на регрессию. Владельцу стандартов нужен способ экспорта трассировок и данных; в противном случае у компании не будет чего оценивать. Владельцу бизнеса необходимы условия выхода, иначе остановка системы превращается в переговоры, а не в принятие решения. Менеджер поставщика обеспечивает наличие этих четырёх элементов, не выполняя при этом ни одной из четырёх своих функций. Отдел закупок консультируется по объёму работ и критериям приёма, но не несёт ответственности ни за что из этого.
Три из шести функций — определение сценария использования, выбор критериев корректности и независимая проверка результатов — не могут быть выполнены командой по внедрению поставщика самостоятельно. Назначение ответственного за каждую из этих функций — это тот аспект, который упускают нормативные документы.
Назначение сотрудников из уже существующих команд
На эти позиции назначаются сотрудники из числа уже имеющихся, причем порядок имеет значение, поскольку каждая позиция зависит от предыдущей.
Начните с руководителя бизнеса; пока он не назначен, проект вынужден ждать. Этот человек контролирует бюджет, процессы и имеет полномочия на отключение системы, а также первым определяет уровень риска и утверждает полномочия сотрудников. Инженерные кадры не могут заменить эту роль, поскольку никто другой не может нести ответственность за связанные с ней компромиссы.
Далее — архитектор. В идеале это человек, хорошо знающий бизнес-процессы и систему, чтобы определять, где заканчивается работа агента и начинается работа человека. Если такой человек существует, место принадлежит ему. Если никто не подходит, работу может начать внешняя сторона, однако компания всё равно должна назначить внутреннего получателя, поскольку место не может оставаться вакантным даже тогда, когда работа выполняется где-то ещё.
На третьем месте находится стандартный владелец, причем решающим фактором является наличие у эксперта по доменам реального времени для работы. Если время защищено, эксперт сам составляет критерии оценки, как это сделали юристы Thomson Reuters. Если же времени нет, специалисты по продукту и дизайну разрабатывают проект, который затем должен быть утверждён экспертом, в результате чего стандарты смещаются, поскольку те, кто знает, как выглядит хороший ответ, не являются теми, кто его записывает. В своём письме акционерам Джейми Даймон излагает общее правило: работа, представляющая собой лишь малую часть обязанностей многих людей, никогда не будет завершена, и для выполнения миссии необходима команда, полностью посвятившая себе этой задаче.
При калибровке судьи и отслеживании отклонений функция измерения в этом решении должна передаваться в отдел данных или аналитики, если таковой существует в компании. В противном случае определенный член команды по разработке должен выделить на это время. Примеры показывают, как это меняет роль команды по науке о данных, когда модель агента поставляется поставщиком. Моделирование и настройка остаются за поставщиком, поэтому уже нельзя считать, что команда по науке о данных отвечает за ИИ. Остаются калибровка и мониторинг отклонений в качестве постоянных задач, а также новая обязанность для команды по созданию моделей кредитования, борьбы с мошенничеством, ценообразования и прогнозирования — указывать целевую аудиторию каждой модели перед тем, как агенту будет разрешено использовать ее в качестве инструмента. Страховые компании и больницы, вероятно, сталкиваются с аналогичными вопросами относительно собственных моделей, но ни один из рассмотренных здесь источников не затрагивает их.
В-четвертых, это инструмент валидации, и решающим фактором является момент, когда вступает в игру соблюдение стандартов. Соблюдение стандартов может обеспечить определения рисков с самого начала, что, по сообщениям, и делает команда по соблюдению стандартов в Chime, либо оно может осуществляться только на этапе выпуска продукта; в последнем случае, как требует проект закона Сингапура, даже для сценариев с высоким уровнем риска требуется независимая валидация перед развертыванием. Для банка наиболее простым вариантом кажется использование уже существующей функции управления рисками моделей, поскольку документ SR 26-2 не регулирует действия агентов и позволяет каждому учреждению принимать решения самостоятельно. Однако ни один источник за 2024 год и позже не сообщает о том, что какой-либо банк воспользовался этим подходом.
В-пятых, это операционная деятельность, и решающим фактором является то, кто будет контролировать систему после её запуска. В следующем разделе рассматривается этот аспект.
Два элемента являются общими для всех сценариев использования. Во-первых, шлюз — единственный путь, который каждый агент использует для доступа к модели, где проверяется идентичность и фиксируются вызовы; им управляет ответственный за операции. Компания Wealthsimple утверждает, что примерно 80 процентов трафика, связанного с ИИ-моделями, проходит через их шлюз, однако остается неясным, регулируется ли оставшаяся часть трафика. Во-вторых, система измерения, включающая инструменты для сбора данных и оценки, которыми совместно управляют отделы данных и аналитики, поскольку две команды, использующие разные инструменты для самооценки, получают показатели, которые невозможно сравнить. Остальные компоненты, а именно сценарий использования, критерии оценки, ответственный за стандарты и место в системе ротации, остаются в ведении бизнес-подразделения, которое ими управляет.
В основном эти роли лишь расширяют существующие задачи, не создавая новых. Владелец бизнеса, уже отвечающий за прибыль и убытки, добавляет утверждение объема работ. Эксперт в определенной области дополняет уже имеющиеся у него знания новыми критериями. Инженер берет на себя функции судьи и управляющего. Специалисты по науке о данных, уже контролирующие состояние собственных моделей, распространяют этот контроль и на агента. Отдел соблюдения правил включает определения рисков в процесс проверки, который он уже выполняет. Новые наймы не предусмотрены. Только роль верификатора не может быть расширена, поскольку эта работа заканчивается там, где начинается процесс создания.
Ежедневное управление агентом
После запуска на протяжении всего срока существования системы выполняются шесть задач. Руководитель операций берет на себя четыре из них, ответственный за стандарты — одну, а верификатор — еще одну; для каждой из этих ролей требуется конкретный человек и определенное время реакции.
Распределение сигналов тревоги осуществляется отделом операций, где сменно работают специалисты. Сигналы тревоги неодинаковы: ошибка разрешений, сбой в работе системы и неправильно отклонённая заявка требуют разного подхода к оценке, причём в последнем случае принимается деловое решение. В проекте закона Сингапура, как и в Законе ЕС об ИИ, предусмотрен подобный процесс эскалации.
Остановка работы утверждается владельцем бизнеса и осуществляется отделом операций в четыре этапа: немедленная остановка, техническое восстановление, корректировка деятельности бизнеса и разрешение на возобновление работы. Закон ЕС об ИИ предусматривает, что ответственный за высокорисковую систему должен иметь возможность остановить её с помощью кнопки остановки или аналогичной процедуры, которая приводит систему в безопасное состояние. Человек, создающий кнопку, не обязательно является тем, кто решает нажать на неё. Закрытие окна чата не отменяет уже оформленную оплату или уведомление, находящееся в очереди, а корректировка деятельности бизнеса не имеет аналога в возврате к предыдущей версии кода. Следовательно, принятие решения об остановке является вопросом управления бизнесом, а его выполнение — задачей отдела операций.
Тестирование на регрессию после изменения модели — это совместные усилия специалистов по данным, инженеров и представителей бизнеса, причем выпуск продукта утверждается специалистом по верификации. Документированным примером является Morgan Stanley’s Assistant: он работает на моделях OpenAI, однако банк разработал собственную систему оценки. Советники и инженеры по формулировке запросов ежедневно вместе оценивают набор тестов на регрессию, при этом поставщик не предоставил ни критериев оценки, ни оснований для их применения. Источником является OpenAI, которое выигрывает, демонстрируя своего клиента; речь идет об приложении для поиска информации. Процесс начинается с уведомления о изменении от поставщика, которое должен получить менеджер по поставкам.
Использование и стоимость определяются процессами обработки, причем правильной единицей измерения является выполненная задача. Попытки повторной обработки, оценка и корректировка относятся к одной задаче, а один вызов модели — это лишь её часть; поэтому указание цены за каждый вызов отражает лишь часть общей стоимости.
Передача информации о сбоях в производстве в отдел оценки является постоянной обязанностью ответственного за стандарты. В докладе, переопубликованном компанией Arize, клиентом которой является Uber, специалист по дизайну интерфейсов Uber отметил, что инструменты оценки и соответствующие наборы данных обновляются еженедельно, поскольку данные из устаревших наборов хуже, чем их отсутствие. Это означает, что дизайнер выполняет работу, которая обычно поручается инженерам и учёным-датасайентистам. Сообщается, что сигналы о соответствии стандартам от Chime попадают в отдел оценки в течение нескольких часов благодаря автономной обработке, проводимой после факта возникновения сбоя.
Наблюдение за лицами, утверждающими запросы — это постоянная задача специалиста по проверке. Компания Anthropic сообщает, что примерно 93 процента запросов на предоставление разрешений для её кодинг-агента принимаются, что является достаточно высоким показателем и указывает скорее на формальное утверждение без реальной проверки. Поскольку речь идет о кодинг-агенте, а не об агенте для бизнес-процессов, это иллюстрирует риск, но не позволяет его количественно оценить. Профиль генеративного ИИ от NIST, который является добровольным, предлагает фиксировать каждый случай, когда человек переопределяет результат работы системы, что соответствует той же проверке, но с противоположной стороны.
Эти обязанности никогда не заканчиваются, и ни один публичный отчет не указывает количество часов, затрачиваемых на их выполнение. Ротацию сотрудников, тесты на регрессию и отслеживание затрат можно заказать у сторонних поставщиков, что является темой для будущего обсуждения.
Чему должна научиться команда и насколько высоки стандарты
Обучение поднимает три вопроса: что должен уметь каждый в команде, где необходим специалист, и какой уровень качества считается достаточным.
Четыре навыка важны для всех, независимо от должности:
- анализировать следы и результаты оценки непосредственно, не полагаясь на краткое изложение кого-либо
- рассуждать о распределении исходов, а не о отдельных примерах
- оценивать работу по конечному результату, а не по тому, что агент утверждает о сделанном
- четко сформулировать задачу для передачи её другому, а затем контролировать результат
Главный информационный офицер Goldman Sachs Марко Ардженти называет именно этот последний набор действий. По его словам, лидеры должны овладеть тремя навыками управления: описанием задачи, её передачей ИИ-агенту и контролем за результатами.
Половина работы по оценке по-прежнему требует участия специалиста. Цикл оценок и анализа ошибок, ежедневная работа по оценке результатов и выявлению причин сбоев, делится на рутинную часть и периодическую часть. Рутинная часть включает написание кода для оценщика, настройку необходимых инструментов и анализ ошибок, возникающих ежедневно. Для этого требуются инженерные навыки и знания в области статистики, и работодатели всё чаще объединяют эти функции под одним названием — инженер ИИ. В документе DeepLearning.AI «Skills Map» описывается эта роль на основе вакансий и интервью, хотя его издатель сам продаёт курсы, которые требуются согласно этим вакансиям. Периодическая часть включает калибровку оценщика с использованием человеческих меток и оценку отклонений, что больше подходит специалистам по данным и в основном необходимо во время периодического анализа. Нетехнологическая компания разумно будет обучать программистов для работы инженерами по ИИ, оставляя датасайентс для калибровки и поддержки процесса проверки со стороны верификаторов. Никакие исследования не сравнивают эти два подхода, а отчет Skills Map указывает лишь то, что требуют работодатели.
Этот инструмент предназначен для выявления тех сбоев, которые инструменты постоянно упускают, и эта ответственность лежит на владельце стандарта и проверяющем. В исследовании 2026 года Антарипа Саха и Хамел Хусейн, преподающие платный курс по оценке, протестировали шесть автоматизированных систем анализа на 100 примерах из реальных производственных сценариев, содержащих 39 сбоев, отмеченных вручную. Лучшая система обнаружила 87 процентов отмеченных сбоев, причем упущения были систематическими: один тип сбоев ускользал от всех систем. Все они также выделяли сбои, которые проигнорировали люди-проверяющие, поэтому полученные результаты не позволяют составить рейтинг, а данные представляют собой единую выборку с метками одного эксперта. Исследование показывает, где всё ещё необходимы люди: владелец стандарта, чья шкала оценок определяет, что считается сбоем, и проверяющий, чей контроль покрытия помогает выявить именно то, что упускают инструменты.
Эта способность развивается путем демонстрации людям неудач и поддерживается плановым анализом. Хусейн и Шанкар, которые имеют одинаковый интерес к платным курсам, делят задачи оценки между инженерами и менеджерами продукта. Инженеры выявляют технические проблемы, такие как сбои при получении данных и ошибки инструментов, в то время как менеджеры продукта обнаруживают неудачи продукта, например, неисполнение ожиданий пользователей. Один решающий сотрудник занимается ежедневной оценкой, что отличается от независимого анализа, выполняемого специалистом по проверке. Чтобы добиться поддержки, они советуют не представлять оценки в виде отчетов, а показывать коллегам, что выявляется при анализе данных. В проекте закона Сингапура добавляется еще один аспект: сама эта способность должна периодически переоцениваться.
Что может и чего не может подтвердить эта информация
Каждый фрагмент нормативного текста и каждый конкретный случай имеют свой источник, но важны также определённые ограничения. Нормативные акты перечисляют требования, и документ SR 26-2 исключает искусственный интеллект-агента из сферы их применения. В исследованиях используются данные пользователей, выполняющих запросы, 39 случаев сбоев из одного набора данных и небольшая качественная выборка. Assistant от Kaiser, Thomson Reuters и Morgan Stanley являются инструментами для поиска информации или составления документов, а не многоэтапными агентами, действующими самостоятельно. Ни одна нетехнологическая компания не опубликовала список своих команд агентов, причём упомянутые фирмы — это те, которые решили это сделать; поэтому проекты, провалившиеся незаметно, отсутствуют в выборке. Большинство таких компаний не будут долго раздумывать над покупкой платформы для агентов; они выберут одного из крупных поставщиков облачных услуг и продолжат работу. Сложнее выбрать внешнюю помощь — будь то консалтинг, дополнительный персонал или инженер, работающий на месте, — а также определить, что останется после завершения сотрудничества. Все шесть должностей остаются внутри компании, а то, что можно приобрести, — это лишь возможности для выполнения задач.
В апреле Федеральная резервная система исключила владельца модели из своих рекомендаций, а Сингапур за пять месяцев до этого предложил, чтобы агента с доступом к системе проверяли люди, не входящие в команду по разработке. В обоих документах не указано, кто в компании несет ответственность за агента. Компании требуется шесть конкретно указанных владельцев, начиная с владельца бизнеса, который утверждает действия агента, оплачивает их и может их остановить. Регуляторы больше не описывают эту роль, однако ее нельзя оставлять пустой, поскольку именно это утверждение определяет рамки работы всех остальных. Предупреждение Марко Ардженти актуально: делегирование полномочий агенту без возможности его контроля ведет к катастрофе, поэтому людям необходимо новое понимание контроля качества и ответственности.
Связанные статьи
- Ваш граф агентов должен находиться в YAML: компиляция графа LangGraph из 17 агентов при запуске — Как небольшой движок компилирует один файл с описанием в формате YAML в граф StateGraph LangGraph: генерация состояний, плагины importlib, маршрутизаторы меток, адаптивные вызовы и замена узлов в рамках сессии.
- Gemini Spark: задачи, навыки, расписания, безопасность и цены — Что делает агент Gemini Spark от Google, работающий круглосуточно, в Gmail, Календаре и Docs, как функционируют его механизмы безопасности, сколько он стоит, где он заблокирован и кто должен им воспользоваться.