Кто отвечает за результат, если работу сделал агент

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

Ответ короткий: отвечает тот, кто принял результат. Агент — инструмент, а не сторона. У инструмента нет ни умысла, ни обязательств, ни имущества, и переложить на него нечего.

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

Аналогия, которая почти работает

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

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

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

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

Три вещи, без которых модель не работает

Владелец результата

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

Проверка простая. Спросите: кому звонят, если то, что вышло из контура, сломало работу следующему звену. Если ответ занимает больше одной фамилии, модель ответственности не построена.

Журнал действий

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

Минимальный набор полей, который окупается почти сразу:

• временна́я метка и версия промпта либо конфигурации;
• вход ровно в том виде, в каком его получил агент, — не после нормализации;
• список вызовов инструментов с аргументами и тем, что они вернули;
• где сработала точка остановки и почему;
• финальный выход и признак «принято / отклонено», с автором решения.

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

Точка принятия

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

Разница между «выборочный контроль» и «никто не смотрит» — это наличие записи о том, что конкретный результат в выборку не попал. Без неё вы не знаете, что именно не проверялось.

Возражение: агент предсказуемее человека

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

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

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

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

Что писать в регламенте

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

Формулировки, которые я стараюсь использовать:

Плохо: «мы применяем надёжные модели и контролируем качество». Это не контроль, это намерение.

Хорошо: «результат публикуется только после отметки о принятии; отметку ставит владелец процесса; при отсутствии отметки в течение суток задача возвращается в ручную очередь».

Второе можно нарушить, и нарушение будет видно. Первое нарушить нельзя, потому что оно ничего не утверждает.

Чего делать не стоит

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

Описывать ответственность через качество модели. «Мы используем сильную модель» — не контроль. Сильная модель ошибается реже и убедительнее, что для проверяющего скорее хуже.

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

Что остаётся нерешённым

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

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