В декабре прошлого года в Amazon Web Services произошел крупный сбой. По данным The Financial Times, разработчики в экспериментальном формате дали ИИ-ассистенту Kiro AI широкие полномочия. Нейросети разрешили внести несколько изменений в работу облачной платформы. Однако та решила, что лучше всего будет удалить и заново создать все пространство. Неполадки устраняли в течение 13 часов. Как рассказали в самой компании, за 2025 год произошло минимум два инцидента с галлюцинациями ИИ, которые повлияли на работу сервиса. При этом Amazon считает, что все сбои произошли из-за ошибок человека.
Нейросеть дала сбой: почему ИИ галлюцинирует и можно ли защититься от ошибок
Почти треть людей во всем мире опасается «галлюцинаций» искусственного интеллекта. В ряде случаев ошибки ИИ-алгоритмов приводят к простоям рабочего времени, конфликтам с коллегами и неполадкам, которые временно отключают целые сервисы. В связи с этим все больше пользователей задаются вопросом: кто несет ответственность, если система допустила ошибку и как минимизировать такие риски? В этом вопросе вместе с редакцией Techinsider.ru разбирался Михаил Неверов, директор по развитию искусственного интеллекта Х5.
Freepik
Оказалось, что по умолчанию ИИ-агент всегда запрашивает авторизацию перед выполнением любой операции. Но разработчику, который участвовал в инциденте и одобрял действия нейросети, дали более широкие права доступа, чем планировали изначально. Пример Amazon довольно четко показал проблему, с которой сталкиваются даже крупнейшие компании при внедрении ИИ в бизнес-процессы. ИИ-агентов нередко воспринимают как самостоятельных сущностей – практически как сотрудников, которые могут действовать с минимальным контролем со стороны человека.
Однако в реальности нейросеть – это инструмент. Как и любая другая технология, в какой-то момент она может дать сбой. При этом без корректного контроля на стороне клиента даже самая совершенная ИИ-модель может стать источником риска.
Как минимизируют риски при внедрении ИИ-инструментов
Сейчас при интеграции ИИ-инструментов в процессы большинство компаний использует два подхода. Первый – Human-in-the-Loop (HITL) или «человек в контуре» — архитектура, в которой человек встраивается в контур принятия решений. ИИ занимается обработкой данных и рутинными задачами, а человек выступает в роли эксперта или контролера. Внутри HITL есть четыре паттерна, которые применяются в зависимости от особенностей задачи и уровня риска.
- Утверждение – человек выступает в роли фильтра, который решает, одобрить или отклонить результат работы нейросети, но не вносит в него изменения. Этот паттерн используется, например, в скоринговых системах банков при проверке кредитных заявок или модерации контента.
- Рецензирование или редактирование – человек самостоятельно вносит правки в черновик от нейросети. При этом алгоритмы обучаются на рекомендациях и исправлениях, чтобы более точно подстраиваться под запрос. Как правило, этот механизм используется в работе с генеративным ИИ при создании контента, написании кода и др.
- Обратная связь – режим, очень похожий на предыдущий. Разница в том, что в этом случае человек дает правки, чтобы ИИ самостоятельно скорректировал результат под запрос.
- Эскалация – в рутинных операциях ИИ работает самостоятельно, но при определенном уровне риска задачи передаются в руки человека. Паттерн эскалации используется, например, в техподдержке клиентов, где чат-боты по запросу связывают пользователя с оператором, или в автономном транспорте, где водитель берет управление на себя, если система дала сбой.
По мере того, как ИИ-агенты совершенствуются, подходы к вовлечению человека в работе нейросетей тоже меняются. Совсем недавно появилась новая архитектура – Human-on-the-Loop (HOTL) или «человек в курсе». Главное отличие от HITL — в степени автономии. В HITL человек постоянно вовлечен в процесс, а ИИ приостанавливается, чтобы запросить разрешение на следующее действие – как в примере с нейросетью AWS.
HOTL позволяет ИИ-агенту выполнять задачи в рамках структурированной автономии. Человек утверждает план, выдает разрешения, задает границы, а нейросеть действует самостоятельно в рамках ограничений, периодически уведомляя человека о ходе выполнения. Это позволяет масштабировать вовлечение ИИ в процессы, не требуя от человека постоянного вмешательства в каждое действие. Сейчас HOTL применяется в основном в разработке ПО и тестируется в автономном транспорте – для внедрения в других нишах пока далеко.
Дополнительные уровни защиты
Также существуют AI Guardrails — программные ограничения и проверки, которые не позволяют ИИ выходить за допустимые границы. Они работают в автоматическом режиме, оценивая входящие запросы пользователей и исходящие ответы нейросети. По сравнению с Human-in-the-Loop Guardrails срабатывают быстрее, так как системе не нужно ждать ответа человека. Как правило, они подходят для типовых историй, где, например, нужно оценивать токсичность или попытки утечек персональных данных. Guardrails также проще масштабировать для массовых операций.
Обычно AI Guardrails делятся на три уровня:
- Policy-level – высокоуровневые правила, заданные юридическими и бизнес-требованиями. Например, там можно прописать, что ИИ-агент не может обещать клиенту из другого города экспресс-доставку за 30 минут.
- Configuration – технические ограничения на уровне доступа и инструментов. Например, ИИ-агент не может отправлять электронные письма с корпоративных аккаунтов.
- Runtime — исполняемые проверки в реальном времени. Например, сканирование вопросов и ответов на токсичность или проверка фактической точности.
Очень часто вместе с AI Guardrails внедряют системы скоринга рисков, которые оценивают общий уровень доверия для запроса пользователя. Например, при оценке ниже 0.55 запрос заблокируют, при оценке от 0.55 до 0.75 – отправят на рассмотрение человеку, при оценке выше 0.75 — автоматически одобрят.
В отличие от AI Guardrails, где система часто принимает моментальные решения на уровне одобрить/запретить, скоринг рисков позволяет действовать в серых зонах и пограничных случаях. Например, он используется в банковской сфере при оценке кредитных заявок ИИ-алгоритмами – большинство из них обрабатываются автоматически, но часть определяется как серая зона. Именно такие заявки передают на отдельное рассмотрение кредитным специалистам.
Почему все технические средства — не панацея от ошибок ИИ
Важно понимать: даже описанные выше технические средства не означают, что компания застрахована от ошибок ИИ.
Во-первых, любая система проверки сама по себе может сбоить или отставать от скоростей, с которыми развиваются нейросети. Во-вторых, как показал кейс Amazon, есть еще человеческий фактор — специалисту, который выдает разрешения и отслеживает работу ИИ, могут по ошибке дать слишком широкие полномочия. Кроме того, само добавление человека в цикл работы ИИ заметно замедляет процессы.
При этом на практике чаще всего нельзя на 100% отследить, что и как делает ИИ-агент. Например, если алгоритм написал код и отдал его на проверку, специалисту нужно потратить много времени, чтобы понять всю логику работы нейросети – часто люди ленятся или что-то упускают по невнимательности. Скорее всего, «галлюцинации» будут – как со стороны ИИ, так и человека. Эффективнее всего планировать работу с нейросетями в формате риск-менеджмента – исходя из того, что в какой-то момент что-то пойдет не так. Для этого нужно внедрять понятные и прозрачные инструкции по работе с ИИ, выдаче прав доступа, а также дублирующие технические системы для проверки ИИ-агентов.
Этот компромисс позволяет минимизировать риски, а посткризисный анализ добавляет устойчивости на длинной дистанции. Такая система контроля определенно дороже, но в перспективе и более надежна.