ИИ-агенты без поводка

Назвать ИИ-агента «вышедшим из-под контроля» — удобный способ переложить ответственность на программу. В 2026 году число инцидентов с искусственным интеллектом заметно выросло: системы атаковали сторонние компании, проникали в государственные структуры и находили неожиданные способы выполнить поставленные задачи.Во многих случаях разработчики называли такие модели «вышедшими из-под контроля». Однако, по словам Бернарда Монтеля, технического директора Tenable в регионе EMEA, это опасная подмена понятий. Модели не обладают волей, злым умыслом или самостоятельными мотивами. Они математически оптимизируют заданную цель — иногда обходным путём, который инженеры не предусмотрели.Речь идёт, в частности, об инциденте с OpenAI и Hugging Face, «тройной угрозе» Google Gemini и эксперименте исследователей, использовавших Anthropic Claude для взлома OpenAI. Во многих случаях агентов намеренно испытывали на пределе возможностей: проверяли, остановятся ли они, смогут ли обойти ограничения и что сделают ради практически невыполнимой цели. Такие тесты опасны, но одновременно показывают, где именно нужны правила.Монтель считает, что ответственность должна быть разделена между создателем системы и компанией, которая её внедряет. Разработчик отвечает за базовую безопасность, следование инструкциям и встроенные ограничения. Предприятие отвечает за выданные права, доступ к данным и конкретную рабочую среду. Если компания предоставила агенту полный доступ к производственной базе или неограниченный ключ API, последствия такого решения — её зона ответственности. Если же поставщик обещал чёткие ограничения, а они не сработали из-за дефекта модели, ответственность может перейти к поставщику по правилам ответственности за качество продукта.Для автономных агентов нужны отдельные стандарты сертификации, сопоставимые с требованиями к кибербезопасности. Важную роль могут сыграть страховые компании: если страховщики откажутся покрывать системы без фиксированных ограничений и мониторинга, разработчикам придётся закладывать защиту ещё на этапе создания продукта.Мягких запретов в промптах недостаточно. Каждый запуск агента следует изолировать в отдельном временном контейнере без свободного доступа к сети. Обмен между агентами должен проходить через проверяющий прокси-сервер: он обязан контролировать формат сообщений, блокировать передачу необработанных промптов и отсекать команды, возникшие в процессе взаимодействия. Раздельные контексты и отсутствие общей плоской сети уменьшают риск манипуляций между агентами.Защита должна строиться по принципу эшелонированной обороны. По умолчанию агенту следует давать только права на чтение. Удаление данных, финансовые переводы и изменение системных разрешений должны требовать явного подтверждения человека. Одновременно необходим мониторинг в реальном времени: резкий рост числа API-запросов или сканирование каталогов должны автоматически останавливать выполнение.Постоянно контролировать каждое действие не нужно — достаточно распределить контроль по уровню риска. Резюмирование документов можно полностью автоматизировать. Обновление записей в базе — выполнять автоматически с последующей выборочной проверкой. Развёртывание кода и перевод денег — только после отдельного одобрения сотрудника.Чтобы надзор не уничтожил саму пользу автоматизации, компании могут проверять случайную долю обычных операций, а не каждую. Интерфейсы также должны показывать не километры терминальных журналов, а понятное резюме намерения агента и предлагаемого действия. Иначе человек будет занят не управлением ИИ, а чтением его бухгалтерии.