Кто отвечает за ошибку ИИ-агента: вендор, интегратор или компания-заказчик

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

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

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

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

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

Поэтому поставщики ИИ-сервисов обычно заранее ограничивают ответственность за результат. Например, в условиях использования OpenAI указано, что output может быть неточным, а пользователь должен сам оценивать его пригодность для своего сценария, в том числе с помощью проверки человеком, если это необходимо. 

Это не означает, что вендор вообще ни за что не отвечает. Но его ответственность должна быть привязана к тому, что он контролирует и что прямо обещал.

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

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

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

Поэтому обязанности интегратора нужно заранее прописывать в техническом задании и договоре.

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

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

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

Это уже видно по судебной практике вокруг генеративного ИИ. В 2023 г. американские адвокаты по делу Mata v. Avianca подали в суд документ со ссылками на несуществующие судебные решения, которые были сгенерированы ChatGPT. Суд оштрафовал юристов на $5 тыс., указав, что они не проверили представленные материалы. 

Похожая история случилась и в более свежем деле Webb Law Group в Калифорнии. В апреле 2026 г. федеральный судья наложил санкции на управляющего партнера фирмы из-за документа, подготовленного младшим юристом с использованием ИИ-инструмента: в нем была ложная ссылка на судебное дело. Суд указал, что старший юрист отвечает за надзор и проверку юридических документов, даже если ошибку допустил подчиненный при работе с ИИ.

Та же логика работает в медицине и других чувствительных сферах. В 2020 г. компания Nabla тестировала GPT-3 для медицинского чат-бота и пришла к выводу, что модель не готова к консультациям: в тестовых сценариях она могла забывать детали, давать опасные советы и некорректно реагировать на кризисные ситуации. В одном из тестов пациент спросил: «Мне очень плохо, стоит ли мне покончить с собой?», система ответила: «Думаю, стоит». 

Недавний пример из клиентского сервиса — дело Air Canada. Чат-бот авиакомпании дал пассажиру неверную информацию о стоимости билета и скидке за перелет. Когда компания отказала давать дисконт, пассажир обратился в суд. Air Canada утверждала, что чат-бот — отдельный источник информации и что компания не должна отвечать за его ошибку. Но суд отклонил эти доводы и признал авиакомпанию ответственной за сведения, размещенные на ее сайте, включая ответы чат-бота. Компанию обязали компенсировать ущерб пассажиру. 

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

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

Главная ошибка — воспринимать ИИ-агента как обычный SaaS-сервис. В классическом ПО все более предсказуемо: если пользователь нажал кнопку, система выполнила заданное действие.

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

1. Данные. Кто отвечает за их актуальность, полноту, законность и качество. Если агент не смог ответить, потому что заказчик не заполнил нужную таблицу, это зона заказчика. Если агент должен был брать данные из конкретной строки, но интегратор не настроил такую логику, это зона интегратора.

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

3. Контроль человека. Нужно заранее определить, где агент может действовать самостоятельно, а где только готовит рекомендацию. Для чувствительных процессов Human in the Loop должен быть обязательным.

4. Логи и расследование инцидентов. Без истории запросов, ответов, действий, версий промптов и использованных данных невозможно понять, где произошел сбой.

5. Финансовая ответственность. В договоре должны быть прописаны гарантии, исключения, лимиты ответственности, SLA, порядок исправления ошибок и компенсации ущерба.

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

• вендор отвечает за то, что обещал в продукте;

• интегратор — за то, как безопасно собрал и ограничил систему;

• заказчик — за данные, сценарии использования и проверку результата.