← Назад к блогу
Серия: Почему AI-проекты проваливаются · Статья 3

Кто виноват, если AI-агент ошибся: три модели ответственности

Агент согласовал договор. В договоре была ошибка в реквизитах. Компания перевела деньги не туда.

Кто виноват?

Разработчик агента? Сотрудник, который запустил процесс? Руководитель, который утвердил внедрение? Или сам агент?

Это не философский вопрос. Это юридический и организационный. И если на него нет чёткого ответа до запуска — первый же инцидент парализует использование системы.

Почему это важно

В прошлой статье я показал, что инструкция для AI-агента — это 10-15 страниц вместо полстраницы для человека. Но даже идеально описанный процесс не гарантирует отсутствие ошибок.

AI-агенты ошибаются. Это факт.

GPT-4 галлюцинирует в 3-5% случаев. Claude — примерно так же. GigaChat — чуть больше. И это в идеальных условиях, на тестовых данных.

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

Вопрос не в том, ошибётся ли агент. Вопрос — что будет, когда он ошибётся.

Три модели ответственности

За годы работы с AI-проектами я выделил три модели, которые реально работают.

Модель 1: «Инструмент»

Агент — это инструмент. Как Excel или калькулятор. Вся ответственность на операторе.

Как работает: Сотрудник запускает агента, получает результат, проверяет, принимает решение. Если ошибка — виноват сотрудник, т.к. не проверил.

Плюсы: Просто юридически. Не нужно менять существующие регламенты. Понятно всем.

Минусы: Люди боятся использовать. «А вдруг агент ошибётся, а отвечать мне?» В итоге система простаивает.

Когда подходит: Низкие риски. Вспомогательные задачи. Этап пилота.

Модель 2: «Supervised Autonomy»

Агент автономен в определённых рамках. Есть чёткие границы, в пределах которых он действует сам. За пределами — эскалация на supervisor’а.

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

Внутри границ агент действует сам и несёт ответственность… точнее, компания принимает этот риск как операционный.

За пределами границ агент запрашивает подтверждение. Ответственность переходит к тому, кто подтвердил.

Пример:

Автономные решения агента (без подтверждения):
— Договоры до 100 000 ₽
— Типовые шаблоны без изменений
— Уверенность агента > 95%
— Контрагенты из белого списка

Требуется подтверждение supervisor'а:
— Договоры > 100 000 ₽
— Нестандартные условия
— Уверенность агента < 95%
— Новые контрагенты

Плюсы: Баланс между скоростью и контролем. Чёткие правила. Можно настроить под специфику бизнеса.

Минусы: Сложная настройка границ. Нужна система мониторинга уверенности. Нужен supervisor.

Когда подходит: Большинство бизнес-процессов. Средние риски. Масштабирование после пилота.

Модель 3: «Full Autonomy + Insurance»

Агент полностью автономен. Риски застрахованы.

Как работает: Агент действует без подтверждений. Компания страхует риски ошибок. Если что-то пошло не так — страховая покрывает убытки.

Плюсы: Максимальная скорость. Нет узких мест в виде supervisor’ов. Масштабируется линейно.

Минусы: Дорогая страховка (если вообще найдёте страховщика). Не для всех типов рисков. Репутационные потери не застрахуешь.

Когда подходит: Низкорисковые массовые операции. Зрелые системы с доказанной надёжностью. Финтех (там привыкли к страхованию операционных рисков).

Как выбрать модель

Зависит от трёх факторов:

1. Цена ошибки

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

Чем выше цена ошибки, тем жёстче контроль.

2. Частота операций

10 договоров в месяц — можно проверять каждый вручную. 1000 договоров в день — нужна автоматизация контроля.

Чем выше частота, тем больше нужна автономность (иначе supervisor станет бутылочным горлышком).

3. Зрелость системы

Новый агент — больше контроля. Агент, который работает год без серьёзных сбоев — можно ослаблять контроль.

Как это оформить юридически

Модель ответственности должна быть зафиксирована в документах.

1. Регламент использования AI-системы

Кто может запускать агента. Какие задачи можно делегировать. Какие — нельзя. Процедура при обнаружении ошибки.

2. Матрица ответственности (RACI)

Для каждого типа операций:

  • Responsible (кто исполняет)
  • Accountable (кто отвечает за результат)
  • Consulted (кого консультируют)
  • Informed (кого информируют)

3. Договор с интегратором

Если агента делал подрядчик — прописать ответственность за ошибки, связанные с дефектами системы. Не за все ошибки, а за те, которые вызваны багами в коде или неправильной логикой.

4. SLA с метриками

Допустимый процент ошибок. Время реакции на инцидент. Процедура компенсации.

Частые ошибки

1. «Разберёмся по ходу»

Запускают агента без определения модели ответственности. Первый инцидент — и начинается хаос. Все показывают друг на друга.

2. «Агент всегда прав»

Слепое доверие к результатам агента. Нет проверок, нет логирования. Ошибки накапливаются незаметно, пока не станет поздно.

3. «Агент всегда виноват»

Обратная крайность. Любую ошибку списывают на «тупую нейросеть». Не анализируют причины, не улучшают систему.

4. «Один размер для всех»

Одинаковая модель ответственности для всех операций. Но согласование NDA и согласование контракта на 100 млн — это разные уровни риска.

Что делать перед запуском

Чеклист:

  1. Определите цену ошибки для каждого типа операций
  2. Выберите модель ответственности (скорее всего — Supervised Autonomy)
  3. Определите границы автономии агента
  4. Назначьте supervisor’ов и определите процедуру эскалации
  5. Зафиксируйте всё в регламенте
  6. Пропишите RACI-матрицу
  7. Настройте логирование всех решений агента
  8. Определите процедуру разбора инцидентов

Без этого запускать агента в прод — безответственно.

Выводы

Ответственность за ошибки AI-агента — это не техническая проблема. Это организационная.

Модель «Supervised Autonomy» работает в большинстве случаев: агент автономен в рамках, за пределами — эскалация.

Главное — определить эти рамки до запуска, а не после первого провала.

Подписывайтесь на канал:

Telegram @futex_ai