Где ставить контроль в работе AI-агента

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

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

В этой статье разберём часть вопросов из этой статьи, оставив за рамками общие полномочия и доступы агента и сосредоточившись на контроле внутри работы:

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

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

Шаг 1. Найти недопустимое последствие

Для исполнения несколько действий удобно объединить в одного агента. Но для обеспечения контроля их приходится разделить.

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

Для агента это одна связная работа. Для контроля — действия с разными последствиями. После одного выбирается запись партнёра. Затем открывается доступ к данным. Потом формируется ответ. Наконец информация уходит наружу.

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

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

Шаг 2. Пройти назад к источнику ошибки

Мы знаем, какое действие создаёт недопустимое последствие. Теперь нужно пройти от него назад и понять, откуда может прийти ошибка. Интересуют места, где результат зависит от того, как агент понял ситуацию. Вместо вопроса «правильно ли агент понял?» полезнее спросить: как ещё агент может это понять?

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

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

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

Если такого решения нет, интерпретация остаётся за агентом. Тогда у нас появляется интервал: место возможного расхождения → … → недопустимое последствие. Его левая граница — интерпретация агента, правая — действие, создающее недопустимое последствие. Контроль должен сработать внутри этого интервала.

Шаг 3. Выбрать место контроля

Когда обе границы интервала найдены, остаётся выбрать место контроля внутри него.

Проверять сразу после места расхождения имеет смысл в двух случаях.

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

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

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

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

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

Кейс: чей это запрос

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

Приходит письмо с вопросом о сроках поставки. Его отправил сотрудник субподрядчика, но в подписи указан объект и ИНН генподрядчика.

Шаг 1. Что нельзя допустить

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

Шаг 2. Откуда может прийти ошибка

Идём назад.

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

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

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

Интерпретация стороны обращения становится левой границей интервала. Нужно ли вообще оставлять этот факт агенту для интерпретации?

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

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

Шаг 3. Где поставить контроль

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

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

Как искать точку контроля

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

1. Найти недопустимое последствие

• Какое последствие ошибки организация не готова принять?

2. Пройти назад к источнику

• Какие предыдущие решения могут привести к этому действию?
• Где среди них результат зависит от интерпретации агента?
• Как ещё агент может понять эту ситуацию?
• Можно ли критичный факт установить независимо от агента и передать ему уже подтверждённым?

3. Поставить контроль

• Если интерпретация остаётся за агентом, что может проверить её, не опираясь на то, как агент понял ситуацию?
• Где между этой интерпретацией и критичным действием выгоднее поставить контроль?

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

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