Принципы участия человека при использовании ИИ-агентов в Jira

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

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

• Подтверждения: действия, которые невозможно отменить без последствий, блокируются.

• Проверки: некачественный или некорректный вывод выявляется до передачи результата дальше.

• Эскалации: вопросы агента, требующие уточнения, автоматически направляются человеку.

В чем заключается принцип участия человека в работе ИИ-агентов?

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

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

На практике участие человека в процессе обычно бывает трех видов.

• Подтверждение — это официальное разрешение на выполнение действия с высоким риском или необратимыми последствиями.

• Проверка — это анализ вывода агента перед тем, как результат будет передан дальше.

• Эскалация — это передача задачи агентом человеку, когда ситуация неясна, отсутствует контекст или задача выходит за рамки компетенции агента.

Человек участвует, человек наблюдает и человек не участвует

Эти три режима обозначают уровни контроля человека за работой агента. Разница сводится к тому, кто действует и кто принимает решения.

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

Как человек должен контролировать ИИ-агентов?

Начните с определения сфер ответственности

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

Простой способ разделить задачи — оценить, во сколько обойдется ошибка в следующих ситуациях.

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

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

• Ответственный — человек. Действия, которые с самого начала выполняет человек, а агент помогает, но не принимает решения.

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

1. Подтверждения: согласование перед выполнением задач с высокой степенью влияния

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

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

2. Проверка: анализ вывода перед поставкой

Исходите из того, что вывод агента не заслуживает доверия, пока не пройдет проверку. Для агента написания кода проверкой является запрос pull, который проходит обычную процедуру контроля и слияния.

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

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

Назначьте любую задачу Jira агенту написания кода и наблюдайте, как он изучает вашу базу кода, пишет исправление или функцию и создает запрос pull, причем все это — в безопасной облачной «песочнице».

3. Эскалация: передача задачи, когда агент неуверен или упирается в заданные границы

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

С помощью правил автоматизации в Jira агенты Atlassian или сторонних поставщиков могут добавить комментарий, присвоить задаче метку «Требует уточнения» или направить ее человеку, если не хватает контекста. Момент, когда агент должен сделать паузу при выполнении задачи и задать вопрос, определяется в собственных инструкциях агента (в Jira для агента Rovo или Jira) или в настройках стороннего агента для таких инструментов, как Claude, Cursor или Copilot.

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

Достаточно один раз настроить автоматизацию в Jira, а остальное сделают агенты.

Когда участие человека становится узким местом, а не защитой?

С контролем связаны две проблемы. Если его слишком мало, происходят несогласованные или необратимые изменения. По мере распространения ИИ для написания кода рост производительности разработчиков остановился на уровне 10–15 %. Дело в том, что самый сложный аспект производства программного обеспечения — это не написание кода, а принятие решений о том, над чем работать, понимание изменяемой системы и умение определить, безопасно ли поставлять полученный результат. С другой стороны, чрезмерный контроль приводит к обратным результатам.

Участие человека становится узким местом, как только точки контроля перестают соответствовать риску. Чаще всего возникают три следующие ошибки.

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

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

3. Статистика вместо реального контроля. Подсчет подтверждений говорит лишь о том, что люди участвовали в процессе. Не факт, что при этом они поймали ошибки. Объем — не показатель качества контроля.

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

Jira как платформа для проверки и подтверждения

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

На одной платформе выполняются три процедуры:

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

• проверка запроса pull, связанного с задачей, в представлении сеансов агентов на странице Для вас в Jira, где видно, что сделал каждый агент и что ожидает внимания человека;

• эскалация на основе агентских инструкций и правил автоматизации с указанием информации о факте передачи и владельце прямо в задаче.

В Jira легко проверить вывод агента и решить, что поставлять.

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

Рекомендации по участию человека в работе ИИ-агентов

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

• Старайтесь вмешиваться реже, но с большей пользой. Каждый этап контроля — это издержки. Откажитесь от формальных проверок.

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

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

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

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

Как настроить свой первый рабочий процесс с участием человека в Jira?

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

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

2. Назначьте задачу агенту, имеющему право действовать только в ее пределах. Добавьте агента в поле «Исполнитель», столбец доски или переход рабочего процесса. Агент будет действовать от имени пользователя, поэтому в Jira ему будет доступно только то, что доступно этому пользователю. Jira контролирует доступ агента к задачам, а то, как сторонние агенты могут использовать свои собственные инструменты, настраивается отдельно, вне Jira. При назначении агент автоматически запускается. Здесь участие человека еще не предусмотрено — точку контроля вы добавите далее.

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

4. Отправьте вывод на проверку. Для внесения изменений в код попросите агента создать запрос pull, связанный с задачей. Так изменения пройдут полноценную проверку перед слиянием. Агент не должен ничего поставлять по собственному усмотрению.

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

Проверяйте, какие действия выполняли и какие решения принимали ваши агенты в Jira.

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

Готовы подключить специалистов к подходящим рабочим процессам? Используйте Jira для разработки на основе ИИ.

Часто задаваемые вопросы об ИИ-агентах с участием человека

Как обеспечить участие человека в работе ИИ-агентов написания кода?

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

Могут ли ИИ-агенты в Jira запрашивать подтверждение от человека?

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

Кто несет ответственность за действия ИИ-агента?

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

Что такое loop engineering для ИИ-агентов?

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

Соответствует ли участие человека в работе ИИ требованиям к управлению ИИ?

Человеческий надзор занимает центральное место в таких нормативных актах, как закон Европейского союза об ИИ и Руководство по управлению рисками ИИ от Национального института стандартов и технологий США, однако надзор не равноценен управлению. Необходим также обязательный контроль доступа, подтверждение и журнал аудита. См. статью Защитные механизмы и средства обеспечения безопасности при использовании ИИ-агентов в Jira.