Агент согласовал договор. В договоре была ошибка в реквизитах. Компания перевела деньги не туда.
Кто виноват?
Разработчик? Сотрудник, который запустил процесс? Руководитель, утвердивший внедрение?
Это не философский вопрос. Это юридический и организационный. И если на него нет ответа до запуска — первый же инцидент парализует всю систему.
Почему это важно
В прошлой статье я показал, что инструкция для LLM-агента — это 10-15 страниц вместо полстраницы для человека. Но даже идеально описанный процесс не гарантирует отсутствие ошибок.
AI-агенты ошибаются. Это факт.
GPT-4 галлюцинирует в 3-5% случаев на бенчмарках. Claude — примерно так же. В реальных бизнес-процессах с грязными данными, нестандартными ситуациями и человеческим фактором — процент выше.
Вопрос не «ошибётся ли агент». Вопрос — что будет, когда он ошибётся.
Модель 1: «Инструмент»
Агент — это инструмент. Как Excel или калькулятор. Вся ответственность на операторе.
Как работает. Сотрудник запускает агента, получает результат, проверяет, принимает решение. Если ошибка — виноват сотрудник, т.к. не проверил.
Плюсы. Просто юридически. Не нужно менять существующие регламенты. Понятно всем.
Минусы. Люди боятся использовать. «А вдруг агент ошибётся, а отвечать мне?» В итоге система простаивает.
Когда подходит. Низкие риски. Вспомогательные задачи. Этап пилота.
Модель 2: «Supervised Autonomy»
Агент автономен в определённых рамках. Есть чёткие границы — внутри действует сам, за пределами — эскалация на supervisor'а.
Как работает. Определяем границы автономии: тип задач, суммы, уровень риска, уверенность агента. Внутри границ — компания принимает риск как операционный. За пределами — ответственность переходит к тому, кто подтвердил.
Вот как выглядит конфиг границ:
# autonomy_boundaries.yaml supervised_autonomy: autonomous_decisions: # Агент решает сам max_amount_rub: 100000 contract_types: [standard_supply, standard_service, nda] min_confidence: 0.95 contractor: whitelist_only requires_approval: # Supervisor подтверждает amount_rub: ">100000" contract_types: [rent, custom, framework] confidence: "<0.95" contractor: new escalation: # Сразу на руководителя amount_rub: ">1000000" risk_indicators: [sanctions_list, bankruptcy_risk, litigation]
Плюсы. Баланс между скоростью и контролем. Чёткие правила. Настраивается под конкретный бизнес.
Минусы. Сложная настройка границ. Нужна система мониторинга уверенности. Нужен supervisor.
Когда подходит. Большинство бизнес-процессов. Средние риски. Масштабирование после пилота.
Модель 3: «Full Autonomy + Insurance»
Агент полностью автономен. Риски застрахованы.
Как работает. Агент действует без подтверждений. Компания страхует операционные риски. Если что-то пошло не так — страховая покрывает убытки.
Плюсы. Максимальная скорость. Нет узких мест в виде supervisor'ов. Масштабируется линейно.
Минусы. Дорогая страховка (если вообще найдёте страховщика для AI-рисков). Репутационные потери не застрахуешь. Не для всех типов рисков.
Когда подходит. Низкорисковые массовые операции. Зрелые системы с доказанной надёжностью. Финтех — там привыкли к страхованию операционных рисков.
Как выбрать модель
Три фактора.
Цена ошибки. Ошибка в email-рассылке — неприятно, но не критично. Ошибка в договоре на 10 млн — может убить компанию. Чем выше цена, тем жёстче контроль.
Частота операций. 10 договоров в месяц — можно проверять каждый вручную. 1000 в день — нужна автоматизация контроля. Иначе supervisor станет бутылочным горлышком.
Зрелость системы. Новый агент — больше контроля. Агент, работающий год без серьёзных сбоев — можно ослаблять.
Получается простая логика: начинаем с модели «Инструмент», переходим к Supervised Autonomy, и только зрелые системы на массовых операциях доводим до Full Autonomy.
Юридическое оформление
Модель ответственности должна быть зафиксирована в документах. Иначе это просто слова.
Регламент использования AI-системы. Кто может запускать агента. Какие задачи можно делегировать. Какие — нельзя. Процедура при обнаружении ошибки.
Матрица ответственности (RACI). Для каждого типа операций:
Операция: Согласование типового договора до 100к R (исполняет) — AI-агент A (отвечает за результат) — Руководитель отдела C (консультирует) — Юрист (при нестандартных условиях) I (информируют) — Финдиректор (еженедельный отчёт)
Договор с интегратором. Ответственность за ошибки, вызванные дефектами системы. Не за все ошибки — а за те, которые из-за багов в коде или неправильной логики.
SLA с метриками. Допустимый процент ошибок. Время реакции на инцидент. Процедура компенсации.
Частые ошибки
«Разберёмся по ходу». Запускают агента без определения модели ответственности. Первый инцидент — хаос. Все показывают друг на друга.
«Агент всегда прав». Слепое доверие к результатам. Нет проверок, нет логирования. Ошибки копятся незаметно, пока не станет поздно.
«Агент всегда виноват». Обратная крайность. Любую ошибку списывают на «тупую нейросеть». Не анализируют причины, не улучшают систему.
«Один размер для всех». Одна модель ответственности на все операции. Но NDA и контракт на 100 млн — разные уровни риска. Нужна дифференциация.
Чеклист перед запуском
Определить цену ошибки для каждого типа операций
Выбрать модель ответственности (скорее всего — Supervised Autonomy)
Определить границы автономии агента
Назначить supervisor'ов и процедуру эскалации
Зафиксировать всё в регламенте
Составить RACI-матрицу
Настроить логирование всех решений агента
Определить процедуру разбора инцидентов
Без этого запускать агента в прод — безответственно. В буквальном смысле.
Выводы
Ответственность за ошибки AI-агента — это не техническая проблема. Это организационная.
Модель «Supervised Autonomy» работает в большинстве случаев: агент автономен в рамках, за пределами — эскалация.
Главное — определить эти рамки до запуска, а не после первого провала.
Серия «Почему AI-проекты проваливаются»:
Кто отвечает за ошибки AI-агента ← вы здесь
Анатолий Лапков. Telegram: @futex_ai
Комментарии (9)
Skubent
07.03.2026 14:46И на круг получается что вместо работника для составления договора мы получаем работника для проверки договора и некоего «инженера ИИ». Похоже правы те, кто говорит что «работы станет больше»
aborouhin
07.03.2026 14:46Работы может стать или больше, или меньше, в каждой организации по-своему. Но структура этой работы точно изменится. Младших юристов, на потоке проверяющих похожие друг на друга договоры, станет меньше (т.к. проверять их получится быстрее). Но появится бóльшая потребность в опытных юристах, которые могут на основании наработанных (и особенно - пропущенных) замечаний составлять и актуализировать чеклисты / скиллы / пр. для ИИ-агентов.
В любом случае, проверка договоров - это та деятельность, в которой соотношение "затраты на персонал / предотвращённые риски" настолько пренебрежительно мало, что измерять имеет смысл не экономию ФОТ, а повышение качества. Особенно актуально для малого бизнеса, который опытных юристов себе позволить не может, а неопытные проверяют так, что лучше уж ИИ-агент в полностью автономном режиме :) А так появляется рыночная ниша для достаточно дешёвого, но качественного аутсорсинга этой функции.
a_lapkov Автор
07.03.2026 14:46Верно. ИИ не волшебная таблетка и не решает все проблемы.
И в первой статье, текущей серии, я указал, что много проектов ломаются именно на том, что пытаются шаблонно решить не шаблонные задачи.
Нужно думать и считать - есть ли выгода.
И наличие выгоды не всегда очевидно "на берегу". По этому порой нужен путь PoC → MVP → опытно-промышленная эксплуатация с обязательным подтверждением эффекта финансами.
aborouhin
А чего бояться-то, если процесс проверки за агентом занимает меньше времени/усилий, чем сделать без него?
А потом агент ошибётся в определении границ. В том самом примере с договорами из статьи элементарно в простой договор поставки на маленькую сумму сделать "инжект" такого условия, которое не выловить обычными чеклистами и которое создаст проблем куда больше, чем на сумму договора.
powerman
Вы исходите из того, что работу нужно выполнить в любом случае одну и ту же - а это не так. ИИ агенты позволяют сделать работу иначе, так, как человек бы не стал - потому что слишком долго/сложно/нудно/не хватает компетенций/и так сойдёт… И объёмы и сложность проверки работы ИИ запросто могут оказаться выше, чем сделать (не совсем то же самое, но тоже приемлемое) без ИИ.
Обязательно ошибётся! Просто хороший промпт заметно снизит число таких ошибок. Кроме того, люди известны тем, что все они ошибаются. Так что мы просто меняем одни ошибки на другие, и размен может оказаться выгодным.
В идеале, конечно, границы должны определяться обычным кодом ещё до первого вызова ИИ - т.е. из входящих запросов берётся следующий, смотрим в поле "сумма", и если она выше порога то вообще не даём этот запрос ИИ. Но такое получится сделать далеко не везде, во многих случаях границы будут применяться к значениям, для вычисления которых сначала нужно привлечь ИИ.
aborouhin
Безусловно, случаи бывают разные. Я проецирую свои выводы исключительно на сценарий проверки входящих договоров (т.е. никак не формализованных, чистый текст, в котором может быть любое). Потому что и я сейчас этим сценарием активно занимаюсь, и Вы его привели в пример.
Как раз один из недостатков всех существующих инструментов - что они с одной стороны, не обеспечивают 100% приемлемый результат (и не могут, само собой), а с другой - не предоставляют удобного интерфейса доработки этого результата пользователем. Выдают готовое заключение без возможности что-то убрать, что-то дополнить, оперативно посмотреть, на основании чего сделаны выводы, прогнать по второму кругу с уточнёнными инструкциями и т.п.
Вот и приходится разрываться между "мелочёвку отдаём ИИ не глядя, но может случиться эпичный факап" и "да за ИИ исправлять дольше, проще сам руками". Но не обязательно же так делать... Мне кажется, именно сценарий "ИИ агент - помощник под контролем специалиста" в бизнес-задачах (в отличие от того же кодинга) совершенно недооценён. Ну, может, ещё накладывается маркетинговая лапша про то, что внедрение ИИ позволит сократить персонал / уменьшить ФОТ и пр., так что надо прям обязательно кого-то демонстративно уволить, чтобы ROI оправдать и KPI выполнить :)
a_lapkov Автор
Вы подняли, наверное ключевой, на текущем этапе развития ИИ в бизнесе, вопрос: удобство взаимодействия. Все текущие инструменты заточены под работу людей с людьми.
И это не простая задача, у которой пока нет наработанных решений.
С договорами, вполне может подойти интрумент рецензирования, который уже давно встроен в основные текстовый редакторы. Но этот инструмент подходит для отображения конечного результат работы. А как показать процесс? Нужно прикрутить какой-то интерфейс, где будет отображаться ход процесса.
И всё это вполне может привести к тому, что сложность контроля за агентом, станет выше сложности выполнения самой работы человеком. :)
В этом, случае нам нужна декомпозиция. А возможно и рекомпозиция. Т.е. процесс того же согласования договора, следует либо разделить на более мелкие составляющие, каждый из которых можно свести к вариантам "Согласовано" и "Не согласовано" и на оценку которой, человеку требуются секунды. При таком подходе фактически исчезает сложность проверки, упрощаются инструменты взаимодействия. И появляется выгода от внедрения.
Плюс у ИИ агентов есть, на мой взгляд, ключевое преимущество для бизнес-систем, относительно человека: можно тестировать.
Дело в том, что мы можем собрать набор тестовых данных и прогнать тест, далее мы можем скорректировать набор данных и вновь прогнать тест и т.д. И такой подход даёт нам проверяемую уверенность в том, как будет работать наш агент.
В своей статье я указал на варианты распределения ответственности, но это лишь один разрез в котором следует вести работу, для успешного внедрения ИИ.
edogs
Если кратко и упрощенно, то поэтому
При проверке, особенно больших объемов, очень просто упустить что-то просто потому, что являясь неправильным оно воспринимается как правильное.
a_lapkov Автор
Всё верно!
Для этого создаём тестовую выборку, проводим evals, смотрим на частоту ошибок в зависимости от типа входных данных (и тут я имею в виду не int, float и т.п., а типа договоров). И для тех где ошибки входят в приемлемое значение - пропускаем без контроля, а те где не проходит отправляем на контроль.
Более того! Человечество давно придумало способ контроля больших объёмов - ОТК. Если требуется и видна выгода, можно применить методологии ОТК. В таком случае создаём иерархию контроля и вперёд.
Тут важно не пытаться штамповать шаблоны, а искать подходящее решение.