ИИ-агент может написать код, обновить CRM, подготовить договор, собрать отчёт или отправить сообщение. Когда работа выполнена хорошо, компания получает ускорение. Когда результат оказывается ошибочным, вопрос всё равно адресуют человеку: кто это разрешил и кто должен был проверить?
В статье «Смерть компании: что такое организационная сингулярность» описана организация, где агенты наблюдают, анализируют, предлагают решения и исполняют их, а человек остаётся над циклом. Следующий практический вопрос неизбежен: что именно означает «остаётся над циклом» и кто отвечает за финальный результат?
Роли, уровни доступа, память и реестр агентов я уже разбирал в материале «Хватит считать агента помощником — оформляйте его на работу». Здесь фокус сужен до одного перехода: как выполненная агентом работа становится результатом, который компания готова признать своим.
Организационная сингулярность упирается в ответственность раньше, чем в технологии. Чем больше работы передано агентам, тем точнее компания должна описать владельца результата, границы полномочий, способ проверки и момент обязательной остановки.
Агент выполняет работу, но не принимает ответственность
Модель может выбрать инструмент и построить последовательность действий. Она не становится стороной договора, руководителем функции или владельцем убытка. У неё нет собственного бюджета риска, должностных полномочий и обязанности объясняться перед клиентом.
Поэтому фраза «это сделал агент» описывает способ исполнения. Она не отвечает на управленческий вопрос.
NIST AI Risk Management Framework предлагает явно разделять роли и линии коммуникации в работе с ИИ. Руководство организации принимает ответственность за решения о рисках разработки и внедрения системы, а роли людей в связке с ИИ должны быть задокументированы и различимы.
Для обычного рабочего процесса полезно развести четыре функции:
| Функция | За что отвечает |
| Владелец результата | Формулирует пользовательский или бизнес-результат и принимает его |
| Владелец процесса | Проектирует путь работы, доступы, проверки и точки остановки |
| Агент-исполнитель | Выполняет разрешённые действия и оставляет проверяемые артефакты |
| Проверяющий | Сверяет результат с критериями и возвращает его на доработку при отклонении |
В небольшой команде один человек может совмещать несколько функций. Смешивать их в одну безымянную роль опасно: тогда согласование превращается в формальный клик, а ошибка остаётся без владельца.
Нажатие «Подтвердить» ещё не делает контроль человеческим
Человеческое участие в контуре часто обозначают термином human-in-the-loop: агент останавливается, а человек разрешает или отклоняет действие. Технически этот механизм уже стал обычной частью агентных систем. Например, OpenAI Agents SDK умеет приостанавливать запуск перед чувствительным вызовом инструмента и продолжать его после решения человека.
Но окно подтверждения решает только половину задачи. Человек должен понимать:
- какой результат требуется получить;
- что агент собирается изменить;
- на каких данных основано действие;
- какой риск он принимает;
- как проверить результат и как его отменить.
Если интерфейс показывает только кнопку и общее описание, человек быстро начинает подтверждать действия автоматически. Это известный риск чрезмерного доверия к автоматике. В требованиях EU AI Act к системам высокого риска человеческий надзор поручается людям с необходимой компетенцией, подготовкой и полномочиями. Они должны уметь интерпретировать результат, отвергать его, отменять решение и безопасно останавливать систему. Эти нормы относятся к определённым законом системам высокого риска, но управленческая логика полезна шире: контролёр без контекста и права сказать «нет» является декорацией.
Шесть черновиков, которые никто не принял
В моей текущей редакционной работе уже был эксперимент, хорошо показывающий разницу между выполнением и результатом. Я поручил агентному контуру подготовить семь материалов для pimenov.ai. В процессе появились шесть черновиков в Notion и 11 визуалов. Проверки источников, схемы, ссылок и метаданных в основном сработали.
После моего чтения ни один текст не был принят как готовый к публикации. В материалах не хватало моего контекста, позиции и практической пользы. Система успешно выполнила производственный пакет, но сам пакет пропустил разговор с владельцем смысла до начала массового производства. Полный разбор этого эксперимента есть в статье «Шесть черновиков и ноль готовых материалов».
Этот кейс дал мне рабочее разделение:
- агент отвечает за корректное исполнение порученного шага в разрешённых границах;
- проверяющий отвечает за доказанную проверку конкретных критериев;
- владелец процесса отвечает за порядок шагов и контрольные точки;
- я как владелец смысла отвечаю за то, что материал действительно стоит публиковать.
Техническая готовность черновика не равна редакционной готовности. Запись в Notion не равна публикации. Успешная публикация не равна тому, что читатель получил обещанную пользу. У каждого перехода должен быть свой владелец и своё доказательство.
Контракт результата вместо расплывчатого поручения
В текущей архитектуре редакции pimenov.ai материал проходит отдельные состояния: постановку, исследование, текст, проверку, сборку, подтверждение и запись черновика. Публикация остаётся отдельным действием. Такая схема нужна не ради процессной красоты. Она не позволяет агенту или человеку назвать работу завершённой раньше времени.
Перед передачей задачи агенту я бы фиксировал короткий контракт результата:
- Цель. Какое изменение должно произойти для пользователя или бизнеса.
- Владелец. Кто имеет право принять результат и кто ответит, если критерии были выбраны неверно.
- Артефакт. Что именно должен вернуть агент: документ, изменение кода, запись в системе, отчёт или подготовленное решение.
- Границы действий. Что агент может читать и менять самостоятельно.
- Точки остановки. Какие действия требуют отдельного решения человека.
- Критерии приёмки. Что должно быть проверено до смены статуса на «готово».
- Доказательство. Какие логи, версии, ссылки, тесты или повторные чтения подтверждают результат.
- Откат. Как вернуть безопасное состояние, если проверка после действия не пройдена.
Эта карточка важнее названия модели. Более сильный агент быстрее выполнит хороший контракт и быстрее масштабирует ошибку в плохом.
Где агент обязан остановиться
Точка остановки нужна там, где цена неверного действия выше цены дополнительной проверки. Обычно это пять групп:
- деньги, платежи, возвраты и финансовые обязательства;
- договоры, юридически значимые решения и обещания клиенту;
- публикации, внешние сообщения и действия от имени человека или компании;
- доступы, секреты, персональные данные и изменение правил авторизации;
- необратимое удаление, массовое изменение данных и решения, затрагивающие людей.
OpenAI описывает похожий принцип для внутреннего использования Codex: низкорисковые действия остаются быстрыми, а действия с повышенным риском останавливаются для проверки. При этом сохраняется телеметрия, позволяющая понять и проверить, что сделал агент. Документация OpenAI о безопасном запуске Codex прямо связывает границы доступа, человеческие подтверждения и журналы действий.
Точка остановки должна быть привязана к конкретному действию. Общее разрешение «работай с проектом» не должно автоматически означать право публиковать, платить, выдавать доступ или удалять данные.
Журнал нужен для ответа, а не для архива
После ошибки мало знать, какой текст сгенерировала модель. Для восстановления цепочки решения нужны:
- исходная цель и версия инструкции;
- данные и артефакты, доступные агенту;
- выполненные вызовы инструментов и изменения;
- автоматические проверки и их результаты;
- запросы подтверждения, решения и авторы решений;
- состояние системы после действия;
- результат повторного чтения и доступный способ отката.
NIST связывает документирование с прозрачностью и подотчётностью. EU AI Act отдельно требует от операторов определённых систем высокого риска сохранять автоматически созданные журналы под их контролем не менее шести месяцев, если другое не установлено применимым правом. Это конкретное юридическое требование нельзя переносить на любой агентный процесс, однако оно хорошо показывает направление: чем серьёзнее последствие, тем важнее восстановимая история действий.
Журнал без проверки финального состояния тоже недостаточен. Команда могла завершиться без ошибки, API мог вернуть успешный ответ, а пользователь всё равно не увидеть изменения. Поэтому в моих рабочих контурах внешнее действие заканчивается повторным чтением: нужно проверить именно тот объект и тот интерфейс, где должен появиться результат.
Кто отвечает, если агент ошибся
Единственного универсального ответа для всех отраслей и юрисдикций нет. Юридическая ответственность зависит от закона, договора, роли поставщика системы, статуса организации и характера ущерба. Здесь нужна отдельная консультация по конкретному случаю.
Управленческий ответ сформулировать проще:
- владелец результата отвечает за цель и принятие работы;
- владелец процесса отвечает за полномочия агента, последовательность и проверки;
- человек на контрольной точке отвечает за конкретное разрешённое действие;
- руководство отвечает за допустимый уровень риска и сам факт внедрения системы;
- поставщик отвечает в пределах своего продукта, договора и применимых требований, но не становится владельцем вашей бизнес-задачи.
Ответственность не исчезает при автоматизации. Она поднимается к тем, кто задал цель, выдал полномочия и признал результат достаточным.
Проверка одного процесса за десять минут
Возьмите любой процесс, где уже используется ИИ-агент, и письменно ответьте на пять вопросов:
- Кто назван владельцем результата?
- Какой наблюдаемый результат он принимает?
- Какие действия агент может выполнить без нового разрешения?
- Где система обязана остановиться?
- Как после сбоя восстановить ход событий и отменить последствия?
Если хотя бы на один вопрос нет конкретного ответа, автономность процесса уже выше его управляемости. Следующий шаг здесь простой: не менять модель, а сначала дописать контракт результата.
ИИ-агенты сокращают стоимость исполнения и координации. Человеческая работа смещается к постановке, пределам полномочий, проверке и принятию последствий. Именно этот слой остаётся организацией, даже когда привычные отделы и должности начинают исчезать.
Источники
- NIST AI Risk Management Framework Core
- NIST Generative AI Profile
- EU AI Act, Regulation (EU) 2024/1689
- OpenAI Agents SDK: Human-in-the-loop
- OpenAI: Running Codex safely
Следующий шаг
Чтобы определить уровни доступа, память, журналы и реестр агентов, продолжите с материалом «Хватит считать агента помощником — оформляйте его на работу».
Связанные материалы
- Статья: Шесть черновиков и ноль готовых материалов: чему меня научил BMAD-подобный эксперимент с Codex
- Блог: Правило для агента должно лежать там, где агент его читает
- База знаний: Четыре принципа делегирования субагентам
Такой разбор полезен командам, которые уже передают агентам реальные рабочие действия и хотят сохранить скорость без размытой ответственности.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov