IBM: у 92% компаний с AI-инцидентами не было базового контроля доступа

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

Где на самом деле возникает уязвимость

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

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

• 92% компаний-жертв AI-инцидентов не имели достаточного контроля доступа к ИИ-системам
• Модель ИИ редко была первопричиной нарушения безопасности
• Главные векторы атаки: избыточные права пользователей и сервисных аккаунтов
• Отсутствие мониторинга аномальных запросов к AI-системе усугубляло масштаб инцидентов

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

Почему AI-системы стали привлекательной целью

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

Типичная корпоративная AI-установка подключает модель к документам, CRM-данным, рабочим чатам и базам знаний. Если нет ограничений на то, что система может «видеть» и выдавать по запросам, масштаб потенциальной утечки определяется только тем, насколько широкий доступ к данным имел скомпрометированный аккаунт.

«Модель сама по себе редко оказывается проблемой», — следует из

исследования IBM, которое указывает на организационные и конфигурационные факторы как ключевую причину большинства зафиксированных AI-инцидентов.

Почему базовые меры остаются невнедрёнными

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

Принцип минимальных прав (least privilege), регулярный аудит доступа, мониторинг аномальных запросов, сегрегация тестовых и рабочих сред — это не новые концепции. IT-безопасность применяет их для CRM, ERP и баз данных уже десятилетиями. По данным IBM, при развёртывании AI-систем этот шаг систематически пропускается.

Что это значит

Исследование IBM переводит разговор об AI-безопасности из области алгоритмических рисков в область организационной зрелости. Публичные дискуссии об ИИ-угрозах часто фокусируются на уязвимостях самих моделей: prompt injection, галлюцинации, непредсказуемое поведение. Но реальная картина инцидентов, согласно IBM, иная: девять из десяти компаний, столкнувшихся с AI-нарушением, могли бы его избежать с помощью мер, которые специалисты по информационной безопасности применяют уже десятилетиями. Для CISO и IT-команд это ключевой вывод: прежде чем масштабировать AI-инфраструктуру, нужно убедиться, что вокруг неё работают те же стандарты контроля доступа, что действуют для любого другого критического корпоративного инструмента.