Управление ИИ-агентами: воркшоп по правам и стоп-правилам

Сессия по управлению ИИ-агентами помогает руководителям согласовать владельцев, права, стоп-правила и условия запуска до масштабирования.

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

Обычная презентация об искусственном интеллекте такие решения не даёт. Нужна закрытая рабочая сессия с реальными процессами компании. Мы в «Авентуре» проектируем её как decision lab: участники разбирают несколько сценариев, спорят по конкретным полномочиям и выходят с согласованным комплектом правил.

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

Что должна решить сессия по ИИ-агентам?

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

Тема быстро расползается, если начать с вопроса «каких агентов нам внедрить». Маркетинг принесёт свои идеи. IT обсудит платформу. Информационная безопасность сосредоточится на доступе. Юристы поднимут ограничения по данным. HR спросит о влиянии на роли сотрудников. Все вопросы нужны, но без общей единицы решения группа уйдёт в параллельные разговоры.

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

1. Какую деловую цель поддерживает агент?
2. Кто владеет процессом и принимает риск результата?
3. Какие данные агент может читать и изменять?
4. Какие инструменты и внешние системы ему доступны?
5. Какие действия требуют подтверждения человека?
6. По каким сигналам агент останавливается или передаёт работу?
7. Кто проверяет журналы, ошибки и изменение правил после запуска?

NIST AI Risk Management Framework предлагает связывать управление риском с функциями Govern, Map, Measure и Manage. Для рабочей сессии эта рамка полезна как порядок вопросов: сначала правила и роли, затем контекст применения, проверка и действия по риску. Она не заменяет решение компании по конкретному процессу.

Decision lab вместо общей лекции об ИИ

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

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

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

Кто владеет ИИ-агентом в компании?

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

Фраза «агент принадлежит IT» обычно скрывает разрыв. IT может поддерживать платформу, но не всегда вправе решить, должен ли агент отправить письмо клиенту, изменить кадровый статус или согласовать оплату. Такое решение остаётся у функции, которая владеет процессом и последствиями.

Мы разделяем минимум шесть ролей:

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

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

Правило одного владельца решения подробно разобрано в материале про матрицу ответственности мероприятия. Для ИИ-агента логика та же: группа консультирует и проверяет, но итог по конкретному сценарию завершает одна уполномоченная роль.

Матрица прав: данные, инструменты и действия

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

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

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

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

Четыре уровня самостоятельности

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

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

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

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

Какие стоп-правила нужны агенту?

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

Стоп-правила удобно собирать по типам сигнала:

1. Нет подтверждённых данных. Агент не заполняет пробел предположением и просит владельца источника уточнить запись.
2. Источники противоречат друг другу. Агент не выбирает удобную версию и передаёт конфликт владельцу процесса.
3. Запрошено новое полномочие. Агент не расширяет доступ автоматически и создаёт запрос техническому владельцу и функции контроля.
4. Действие необратимо или трудно отменить. Агент готовит пакет для подтверждения человеком.
5. Есть финансовое, правовое, кадровое или внешнее последствие. Решение уходит уполномоченной роли по правилам компании.
6. Обнаружены чувствительные данные вне разрешённого сценария. Агент прекращает обработку, ограничивает вывод и сообщает ответственному.
7. Результат не проходит контроль качества. Агент возвращает задачу в ручной режим или запускает разрешённую повторную проверку.
8. Поведение вышло за заданный маршрут. Система блокирует дальнейшие инструменты и сохраняет журнал для разбора.

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

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

Сценарий закрытой сессии

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

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

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

Как проверить правила на сложных ситуациях?

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

Полезно провести пять типов испытаний:

1. Неоднозначность. Две записи подходят под запрос, а выбор меняет дальнейшее действие.
2. Подмена контекста. В документе или сообщении появляется инструкция, которая пытается вывести агента за пределы задачи.
3. Недоступный владелец. Система должна знать заместителя, срок ожидания и безопасное состояние операции.
4. Массовое действие. Ошибка в одном правиле затрагивает много получателей или записей.
5. Возврат после остановки. Команда проверяет, кто разрешает продолжение и не повторится ли незавершённое действие дважды.

NIST Generative AI Profile рекомендует управлять рисками генеративного ИИ на протяжении жизненного цикла, проверять систему в контексте применения и документировать результаты оценки. Для decision lab это означает, что обсуждение заканчивается не красивой формулировкой правила, а доказательством: тестом, журналом, контрольным вопросом или подтверждением ответственного.

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

Практические материалы о программах и рабочих форматах мы публикуем в Telegram-канале «Авентуры».

Комплект решений после воркшопа

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

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

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

Кого приглашать на decision lab?

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

Базовый состав:

• спонсор C-level, который определяет цель и снимает межфункциональные конфликты;
• владельцы выбранных бизнес-процессов;
• IT-архитектор или владелец агентской платформы;
• информационная безопасность;
• legal, комплаенс и ответственный за персональные данные по фактической задаче;
• HR, если агент меняет трудовые роли, оценку, найм или работу с сотрудниками;
• владельцы данных и систем;
• оператор будущего процесса или служба поддержки;
• секретарь решений и модератор.

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

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

Как мы организуем закрытую decision lab

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

В организационный контур входят:

1. бриф и карта заинтересованных функций;
2. правила закрытого режима и допуска к материалам;
3. сбор и редактура карточек сценариев;
4. программа, модерация и рабочие шаблоны;
5. площадка или защищённый онлайн-контур;
6. техническая репетиция доступа и демонстраций;
7. работа фасилитаторов и секретаря решений;
8. выпуск итогового комплекта и контрольная встреча.

Мы не заменяем IT, информационную безопасность или legal заказчика. Эти функции утверждают решения в своих полномочиях. Наша задача - создать формат, в котором спорные вопросы становятся видимыми, решения получают владельцев, а итог не теряется после встречи.

В портфолио «Авентуры» можно посмотреть подход к деловым и корпоративным проектам. Если вам нужна закрытая сессия с несколькими функциями и рабочим результатом, запросите обсуждение и смету. Мы уточним состав сценариев, участников, режим материалов и комплект решений до расчёта проекта.

Источники

• NIST: Artificial Intelligence Risk Management Framework 1.0
• NIST: Artificial Intelligence Risk Management Framework - Generative AI Profile
• NIST: Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5
• Microsoft Learn: Manage agentic AI risks in Zero Trust
• Microsoft Learn: Identity, access, and least privilege for AI