Агент согласовал договор. В договоре была ошибка в реквизитах. Компания перевела деньги не туда.
Кто виноват?
Разработчик? Сотрудник, который запустил процесс? Руководитель, утвердивший внедрение?
Это не философский вопрос. Это юридический и организационный. И если на него нет ответа до запуска — первый же инцидент парализует всю систему.
Почему это важно
В прошлой статье я показал, что инструкция для 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
Автор: a_lapkov
