Вашим ИИ-агентам нужны должностные инструкции, а не более удачные промпты

Спросите в компании, что разрешено делать новому аналитику по кредиторской задолженности, и получите точный ответ. Она работает в таких-то системах, с такими-то поставщиками, а всё, что превышает лимит согласования — скажем, 10 000 долларов США, — передается руководителю на подпись. Первые несколько месяцев она проходит испытательный срок. Обычно всё это прописано в матрице делегирования полномочий, которую служба внутреннего аудита проверяет каждый год.

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

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

Почему промпт не справится с этой задачей

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

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

У специалистов по безопасности уже есть название для такого результата. В списке OWASP Top 10 for LLM Applications чрезмерная автономность указана как один из ключевых рисков, обусловленных избыточной функциональностью, чрезмерными разрешениями или чрезмерной автономией. Проще говоря, это всё равно что в первый же день выдать сотруднику ключи от всего. Рекомендации OWASP напоминают контрольный список хорошего руководителя: предоставляйте агенту только необходимые ему инструменты, ограничивайте его разрешения, требуйте одобрения человека для действий с серьёзными последствиями и обеспечивайте соблюдение правил авторизации в последующих системах, а не полагайтесь на то, что модель сама себя проконтролирует.

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

Отмены проектов указывают на проблемы управления

По прогнозу Gartner, к концу 2027 года будет закрыто более 40% проектов с агентным ИИ из-за роста затрат, неясной бизнес-ценности и недостаточных мер контроля рисков.

Свою роль в этом играют шумиха вокруг технологии и незрелость продуктов. И всё же попробуйте взглянуть на три причины глазами операционного директора. Затраты растут, когда никто не установил бюджет. Ценность остается неясной, когда никто не зафиксировал, какой результат должна была дать работа. Меры контроля рисков оказываются недостаточными, когда нет ограничений, проверок и человека, который несет четко определенную ответственность. Gartner не формулирует это таким образом — это мое прочтение. То же самое происходит, когда людей оставляют без надзора и системы управления; эта проблема возникла задолго до появления ИИ.

В рамках тоже виден тот же пробел. В системе управления рисками ИИ NIST функция «Руководство» проходит через этапы «Картирование», «Измерение» и «Управление», а профиль генеративного ИИ распространяет этот подход на генеративные системы. Но в рамках не найти рабочего механизма — наделения полномочиями, тестирования и проверок, которые команда действительно проводит в обычный вторник. Без этого управление остается PDF-файлом на общем диске.

Как применить к агентам привычные инструменты управления

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

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

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

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

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

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

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

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

Что выяснят при разборе инцидента

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

Если честные ответы — «подсказка», «никто не помнит», «несколько часов» и «непонятно», более совершенная модель вас бы не спасла.

Где в итоге оказывается преимущество

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

Разница — в системе управления, выстроенной вокруг модели. Её создают постепенно, в основном люди, которые уже руководили организациями.

Если завтра ваш новейший агент превысит свои полномочия, заметит ли это кто-нибудь в вашей компании? И сможете ли вы письменно показать аудитору, где проходила граница?