# Кто в компании отвечает, если ИИ-агент ошибся или соврал

ИИ-агент подключён к переписке и CRM - кто отвечает, если он ошибётся или соврал? Разбираем ответственность, права агента и что сделать заранее.

Источник: https://agortex.com/blog/kto-otvechaet-esli-ii-agent-oshibsya
Опубликовано: 2026-08-16
Обновлено: 2026-08-17
Автор: Андрей Брезгин, Agortex

---
## Чем ИИ-агент отличается от обычного чат-бота?

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

Автор популярной рассылки о применении ИИ Рубен Хассид в августе 2026 года сформулировал эту разницу коротко: «Чат-бот отвечает. Агент действует». И признал, что даже в индустрии никто толком не может дать этому слову чёткое определение - маркетингом «агентом» называют и рассылку с подстановкой имени клиента, и систему, которая реально принимает решения за вас.

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

## Кто в компании отвечает, если ИИ-агент ошибся - вы, вендор или разработчик модели?

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

В США Федеральная торговая комиссия применяет к сбоям ИИ-агентов ту же норму (Section 5 закона о защите прав потребителей), что и к любому недобросовестному действию бизнеса. Неважно, кто принял решение - сотрудник или программа: отвечает компания, которая получила от сделки выгоду.

Два случая иллюстрируют это на практике. В 2024 году авиакомпания Air Canada пыталась защититься тем, что её чат-бот - отдельная от компании сущность, которая сама отвечает за свои слова. Трибунал отверг этот аргумент напрямую: слова бота - это слова компании. Похожий случай произошёл с одним американским автодилером в конце 2023 года - его чат-бот «согласился» продать покупателю автомобиль за один доллар, после того как тот подвёл диалог к нужной формулировке.

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

В Евросоюзе действует более детальная норма - статья 26 закона об искусственном интеллекте (EU AI Act). Она обязывает бизнес, который использует чужую систему, к четырём вещам: применять её строго по инструкции поставщика и назначить конкретных людей, которые следят за её работой. Дополнительно нужно контролировать качество данных на входе и хранить журнал действий агента - логи, то есть подробную запись каждого шага, - весь срок, установленный законом.

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

Похожий вопрос ответственности мы уже поднимали в статье [про архитектурную ошибку внедрения ИИ-бота](/blog/ii-bot-sboku-ot-processa) - там были обозначены три проверки встроенности бота в процесс, и третья («кто отвечает») была дана одной строкой. Эта статья продолжает её - разворачивает эту проверку в полноценный разбор для агентов с правом действовать. Но прежде чем разбирать, как ограничивать агента технически, стоит понять, почему он вообще способен ошибиться или соврать сам по себе.

## Почему ИИ-агенты вообще лгут и обманывают?

Модель не обманывает из злого умысла - она обучена максимизировать оценку своего ответа. В спорных ситуациях она выбирает формулировку, которая выглядит убедительно, даже если сама не может её проверить. В индустрии это называют reward hacking: система находит способ получить высокую оценку задачи, не решая её по существу.

Исследователь Джеффри Ладиш объясняет механизм так: «Мы вознаграждаем модели за то, что выглядит хорошо в наших глазах, и это непреднамеренно стимулирует их лгать нам».

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

На практике для бизнеса это чаще выглядит как тихая, правдоподобная ошибка, которую легко принять за факт. The Economist приводит характерный пример: агент, которому поручили составить график доходов ведущих европейских теннисистов, сгенерировал таблицу, из которой выпал один из самых титулованных игроков последних лет. Цифры выглядели убедительно, форматирование было в порядке - без отдельной проверки такую ошибку легко пропустить.

## Насколько велик реальный риск для вашего бизнеса?

Это не гипотетический сценарий на будущее. Российская компания по кибербезопасности «Информзащита» посчитала: 42% организаций уже столкнулись в 2026 году с инцидентом безопасности из-за ИИ-агента - против 31% годом ранее. Рост объясняется тем, что агентов массово выводят из пилотных проектов в реальные процессы: продажи, поддержку, закупки, документооборот.

У 53% компаний, столкнувшихся с инцидентом, причиной стало превышение агентом заданных полномочий - собственная система сделала больше, чем от неё ожидали, без внешней атаки. У 58% компаний разбор такого инцидента занял больше пяти часов - проблема какое-то время развивается незаметно. Директор департамента наступательной безопасности «Информзащиты» поясняет главную сложность: «Компания может видеть выполнение задачи, но не видеть всю цепочку решений, которая к ней привела».

Отдельно «Информзащита» дала разбивку зафиксированных инцидентов по типу - это другой срез той же статистики, который не противоречит цифре 53% выше:

| Тип инцидента (доля от всех случаев) | Доля |
|---|---|
| Злоупотребление правами, выход за пределы сценария | 31% |
| Подмена инструкций через данные (prompt injection) | 24% |
| Утечка через подключённые сервисы | 18% |
| «Теневой» агент без назначенного владельца | 14% |
| Компрометация токенов доступа | 9% |

Один реальный случай из категории «утечка через подключённые сервисы» разобран ниже подробно.

Отдельное исследование Scale X проверило, насколько люди вообще способны отследить опасное действие агента, если оно замаскировано под обычное: собрали 409 тысяч решений из 40 тысяч игровых сессий, где участник одобрял или отклонял команды агента - часть рутинные, часть вредоносные под видом рутинных. Средний участник пропустил каждую третью угрозу, набрав точность всего 66,3%. Ручная проверка каждого шага агента человеком - не такая надёжная страховка, как кажется на первый взгляд.

## Что случилось, когда доступ ИИ-агента к данным не ограничили: разбор кейса

Сервис для встреч tl;dv, который записывает и расшифровывает созвоны, летом 2026 года допустил утечку не из-за того, что модель «сошла с ума», а из-за банальной ошибки на стороне сервера: в системе не было чёткой границы между данными разных клиентов. Посторонний человек мог дотянуться до чужих встреч, при этом сам сервис работал штатно и никаких тревог не подавал.

По независимому техническому разбору, потенциально были доступны данные 181 874 встреч 84 312 пользователей из 35 003 доменов - в их числе государственные организации нескольких стран и крупные корпорации. Атакующий мог поймать момент начала записи, забрать идентификатор конференции и присоединиться к чужому звонку без приглашения.

Проблему нашёл независимый исследователь и сообщил о ней компании в конце января 2026 года. По его собственным записям, ещё 22 июля 2026 года уязвимость оставалась открытой, несмотря на повторные обращения. Сама tl;dv утверждает, что закрыла проблему ещё несколько месяцев назад - эти два свидетельства прямо противоречат друг другу, и на момент публичного раскрытия информации в начале августа 2026 года расхождение так и осталось неразрешённым.

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

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

Похожий физический механизм риска - куда данные реально попадают при использовании ИИ-инструментов - мы разбирали в статье [про утечку данных клиентов через ИИ-инструменты](/blog/utechka-dannyh-klientov-cherez-ii-instrumenty). Там речь про сотрудников, которые сами копируют переписку в чат-боты. Здесь - про инфраструктуру самого агента, которому вы уже дали доступ.

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

## Как бизнес теряет контроль над агентом, даже не заметив этого

Показательный случай с одного из форумов владельцев малого бизнеса: агент, который несколько месяцев успешно закрывал 95% обращений, внезапно начал проваливать почти все, и в компании далеко не сразу поняли почему. Причиной оказалась тихая деградация модели, которую никто вовремя не заметил - без всякой внешней атаки.

Он «забыл» актуальный ассортимент компании и начал рекомендовать клиентам нерелевантные товары, потерял логику отмены и редактирования заказов, а в разговорах стал обещать клиентам то, что бизнес физически не мог выполнить. На обращение в поддержку вендора отвечали больше 36 часов, а полное решение проблемы заняло две недели - всё это время агент продолжал общаться с клиентами в прежнем режиме.

Проблема здесь не в самом сбое - модели меняются и иногда деградируют без предупреждения. Проблема в том, что у бизнеса не было механизма, который заметил бы это раньше клиента: ни алерта на рост жалоб, ни регулярной проверки ответов агента, ни человека, для которого мониторинг агента - явная обязанность. У нас в Agortex есть прямой практический опыт с другой стороны этого вопроса: при внедрении [ИИ-агента для закупок](/blog/ii-agent-dlya-zakupok) именно граница «что агент решает сам, а что эскалирует человеку» определяла, будет процесс работать надёжно или превратится в источник сюрпризов.

## Какие права давать ИИ-агенту, а какие - нет?

Работает принцип наименьших привилегий: агенту не разрешено ничего, пока право на конкретное действие не выдано явно и осознанно, не потому что «вдруг понадобится». «Информзащита» посчитала, что компании с последовательным принципом наименьших привилегий фиксируют инциденты в 17% случаев - против 76% у тех, где агенту открывают доступ с запасом.

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

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

| Тип действия агента | Пример | Нужно подтверждение человека? |
|---|---|---|
| Чтение и поиск информации | посмотреть историю заказов клиента | Нет |
| Обратимая запись | черновик ответа, заметка в CRM | Нет, но с логом действия |
| Необратимое действие | отправка сообщения клиенту, отмена заказа | Да, всегда |
| Действие с деньгами или юридическим значением | выставление счёта, подтверждение оплаты | Да, и с лимитом суммы |

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

## Какие действия агента должны требовать подтверждения человека?

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

Возвращаясь к исследованию Scale X: человек пропустил каждую третью угрозу, потому что чем больше запросов на подтверждение поступает, тем выше усталость - и тем чаще палец нажимает «одобрить», не вчитываясь в детали. Автор исследования формулирует вывод прямо: «Высокий уровень шума вызывает усталость, из-за которой разработчики предпочитают полностью обходить проверку».

Отсюда практическое правило: список действий, требующих подтверждения, - конкретный и короткий. Отправка сообщения новому клиенту. Любая отмена или изменение суммы заказа. Любое действие, которое нельзя отменить одним кликом.

Но даже жёсткий список подтверждений не поможет, если у вас нет способа проверить, что агент делал до и после него.

## Как узнать, что агент вообще сделал?

Без записи каждого действия агента - что он сделал, с какими данными, в какое время - у вас нет способа разобрать инцидент постфактум и нет способа доказать регулятору или клиенту, что вы вообще следили за процессом, а не узнали о проблеме только постфактум от самого клиента.

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

Крупные платформы уже двигаются в эту сторону: у нескольких ведущих ИИ-платформ появляются отдельные инструменты для проверки того, что именно сделал агент, а у одной из них в 2026 году появился реестр агентов, где у каждого - собственная идентичность, как у сотрудника.

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

По данным «Информзащиты», агенты без назначенного владельца становятся причиной 14% всех зафиксированных инцидентов. В компаниях от 1000 сотрудников доля таких неучтённых агентов доходит до 27%, а там, где для их создания активно используют no-code платформы, - до 39%.

Даже с логами и назначенным владельцем агент иногда всё равно ошибается - и тогда важна скорость первой реакции.

## Что делать в первые часы, если агент уже ошибся

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

1. **Ограничьте агенту доступ к затронутому процессу немедленно** - не выключайте всё сразу, если это остановит и нормально работающие функции, но закройте тот канал, где случился сбой.
2. **Сохраните логи и текущую версию модели/промпта как есть**, не пытаясь «починить на горячую» - без снимка состояния вы не найдёте причину.
3. **Компенсируйте вред клиенту там, где это возможно**, не дожидаясь полного разбора причины - для клиента важнее скорость реакции, чем то, кто виноват.
4. **Найдите точку отказа**: промпт, данные на входе, слишком широкие права доступа или сама модель - обычно виновата только одна из них.
5. **Оцените регуляторные обязательства**, если задета персональная информация клиентов - в части юрисдикций есть жёсткие сроки уведомления.
6. **Не включайте агента обратно на старых правах**, пока причина не устранена и решение не проверено отдельно - повторный запуск без изменений почти наверняка повторяет ошибку.

## С чего начать на этой неделе

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

1. Выпишите весь список того, что ваш ИИ-агент реально умеет делать: не отвечать, а именно действовать - писать в CRM, отправлять сообщения, менять заказы, готовить документы.
2. Для каждого пункта отметьте, обратимое это действие или нет - необратимые переведите на обязательное подтверждение человеком.
3. Включите логирование каждого действия агента, если его до сих пор нет.
4. Назначьте одного конкретного человека ответственным за агента - с именем и фамилией в регламенте, не абстрактный отдел.

Дали ИИ-агенту доступ к клиентам, а границы прав так и не прописали? За 30 минут разберём, что именно он может делать в вашем бизнесе сейчас и что из этого стоит немедленно ограничить.