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

Когда ИИ-агент ошибается — списывает не ту сумму, отправляет клиенту неверный ответ, удаляет не тот документ, — первая реакция компании обычно звучит одинаково: «кто за это ответит?». И почти всегда ответ ищут не там. По данным «Инфосистемы Джет» (октябрь 2026), лишь 8% компаний готовы делегировать ИИ решения среднего и высокого риска, а 44% отказов от ИИ-агентов связаны в первую очередь с незрелостью процессов, а не с качеством моделей. Иными словами, страх «а вдруг агент натворит дел» напрямую тормозит рынок, но сам этот страх возникает из-за того, что в проекте не назначен владелец результата.

Ответственность распределяется не поровну между вендором и заказчиком, а по слоям: за модель, интеграцию, данные, регламенты и решение действовать. Ниже — эти слои, матрица RACI, права доступа, аудит, песочница, ревью, 152-ФЗ, регламент внедрения и чек-лист.

Модель ответственности: три роли и границы

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

Вендор (поставщик модели или платформы) отвечает за поведение модели в заявленных границах: качество генерации, соответствие документации, стабильность API, отсутствие уязвимостей, корректность работы в заявленных условиях. Вендор не отвечает за то, какие данные вы в него подаёте, какие промпты пишете и какие права выдаёте агенту. Типичная ошибка — перекладывать на вендора последствия неправильного использования модели.

Интегратор отвечает за корректную сборку: как модель подключена к вашим системам, какие права выданы, как настроены проверки, как работает логирование и обработка ошибок. Если интегратор выдал агенту доступ на запись «чтобы работало быстрее», это его зона ответственности. Интегратор отвечает за техническую реализацию ограничений, а не за бизнес-политику компании.

Заказчик (владелец бизнеса) отвечает за самое главное: за данные, за описанные процессы, за регламенты и за решение предоставить агенту ту или иную автономию. Именно заказчик определяет уровни риска операций, назначает ревьюеров и владельца результата. Без этого слоя не работает ни одна техническая защита: если в компании нет правила «платежи подтверждает человек», интегратор не сможет его выдумать.

Матрица RACI для ИИ-агента

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

Расшифровка ролей: R (Responsible) — выполняет работу; A (Accountable) — единственный, кто отвечает за конечный результат; C (Consulted) — даёт консультацию до принятия решения; I (Informed) — получает информацию о решении. Правило: на каждый артефакт должен быть ровно один «A».

Права доступа: read-only по умолчанию и RBAC

Большинство инцидентов происходит не из-за «глупой модели», а из-за слишком широких прав. Главный принцип — минимум прав и режим только для чтения по умолчанию.

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

RBAC (ролевая модель доступа). Агент должен действовать под отдельной сервисной учётной записью с ролями, а не под правами сотрудника. Роли описывают ровно те действия, которые нужны для задачи. Например, агент поддержки может читать карточку клиента и создавать обращение, но не может менять сумму заказа или удалять записи. Ролевая модель позволяет легко аудировать и отзывать доступ.

• Отдельная учётная запись для агента — никогда не под правами человека или администратора;
• Минимальный набор ролей под конкретный сценарий, а не «всё на всякий случай»;
• Разделение чтения и записи — разные роли и разные подтверждения;
• Ограничение по времени и объёму — лимиты на количество операций в час и на сумму сделок;
• Пересмотр прав — доступы отзываются при изменении сценария.

Аудит и логирование действий агента

Без аудита невозможно ни доказать невиновность агента, ни найти настоящую причину ошибки. Аудит и логирование — это не только требование безопасности, но и обязательное условие, при котором ответственность можно распределить честно. Если действие не зафиксировано, разобраться, кто ошибся, почти невозможно.

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

Песочница: где учится и где действует

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

• Копия данных без реальных персональных данных или с обезличенными;
• Изолированные интеграции с тестовыми ключами и адресами;
• Те же права, что в проде — иначе тест бесполезен;
• Набор тестовых сценариев, включая злонамеренные и некорректные запросы;
• Журнал прогонов для повторяемости и сравнения версий.

Ревью человеком: где останавливается автономия

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

Рабочий подход — уровни риска. Низкорисковые операции (поиск, сортировка, черновик) агент делает сам. Средний риск (смена статуса, создание документа, ответ клиенту) требует подтверждения человеком. Высокий риск (платежи, удаление, юридически значимые действия) — двойной проверки. Из-за нерешённости этих границ лишь 8% готовы доверять ИИ решения среднего и высокого риска.

• Черновик, а не отправка: на старте агент готовит результат, человек подтверждает;
• Пороговые суммы: операции выше лимита всегда проходят ревью;
• Низкая уверенность: сомневаешься — задача уходит человеку;
• Выборка: часть автоматических операций проверяется вручную;
• Регулярный пересмотр: по мере накопления аудита часть ревью снимается осознанно.

152-ФЗ: персональные данные и обезличивание

Если агент обрабатывает персональные данные, к вопросу ответственности добавляется 152-ФЗ. Оператор персональных данных — то есть заказчик — отвечает за законность обработки, даже если технически обработку выполняет агент и модели вендора. Вендор и интегратор могут быть обработчиками по поручению, но ответственность перед субъектом данных остаётся на операторе.

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

• Минимизация: не передавайте в модель больше данных, чем нужно для задачи;
• Обезличивание: для тестов, обучения и аналитики — только обезличенные данные;
• Локализация: учитывайте требования к месту обработки персональных данных;
• Согласие и основания: обработка должна иметь законное основание;
• Договоры с обработчиками: поручение на обработку для вендора и интегратора;
• Журнал обработки: фиксируйте, какие данные и для чего передавались.

Ответственность за нарушение 152-ФЗ не перекладывается на вендора модели. Если агент передал персональные данные в модель за пределами разрешённого контура, отвечает оператор. Поэтому контроль передачи данных и обезличивание — не «юридическая формальность», а часть технической архитектуры агента.

Практический регламент внедрения

Чтобы ответственность не осталась на бумаге, нужен практический регламент, по которому проект агента проходит от идеи до эксплуатации. Он описывает не только «что делать», но и «кто за что отвечает» на каждом шаге. Такой регламент удобно закрепить внутренним документом и приложением к договору с интегратором.

1. Определить владельца результата — человека из бизнеса, который отвечает за метрику и инциденты;
2. Заполнить матрицу RACI до старта разработки и согласовать её с вендором и интегратором;
3. Классифицировать операции по риску и назначить для каждого уровня режим ревью;
4. Спроектировать RBAC с учётной записью агента, минимальными ролями и read-only по умолчанию;
5. Запустить песочницу с копией данных и тем же набором прав, что в проде;
6. Настроить аудит с единым trace id и хранением логов в контролируемом контуре;
7. Проверить 152-ФЗ: минимизация, обезличивание, договоры с обработчиками;
8. Провести приёмку по метрикам и зафиксировать версию модели в договоре;
9. Запустить с ограниченной автономией и человеческим ревью на среднем и высоком риске;
10. Пересматривать права и ревью регулярно, по данным аудита, а не по ощущениям.

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

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

• Назначен владелец результата из бизнес-подразделения, а не только из «инноваций»;
• Матрица RACI заполнена, у каждого артефакта ровно один ответственный;
• Операции классифицированы по риску, для среднего и высокого назначено ревью;
• У агента отдельная сервисная учётная запись с минимальными ролями;
• По умолчанию включён режим только для чтения, запись — точечно и обоснованно;
• Агент проверен в песочнице на тех же правах, что и в проде;
• Включено логирование каждого действия с единым trace id;
• Логи хранятся в контролируемом контуре и защищены от изменения агентом;
• Персональные данные минимизированы, тесты и аналитика — на обезличенных данных;
• Зафиксированы версия модели и границы её ответственности в договоре;
• Есть план остановки агента и порядок разбора инцидента.

Частые вопросы