Теневой ИИ-Джунгли: Почему одобрение платформы не то же самое, что обеспечение безопасности того, что на ней построено

Принятие ИИ в корпоративном секторе далеко не без проблем. Заботы о контроле над данными, соблюдении нормативных требований и безопасности сопровождают каждый этап этого пути. Но когда организации расширяют свои операции на крупных платформах, таких как Microsoft, Salesforce и ServiceNow, растет чувство, что самые сложные вопросы управления хотя бы частично решаются. Корпоративные соглашения заключены. Проведены обзоры безопасности. Платформы одобрены.

Однако это доверие часто упускает из виду другой вопрос: не является ли платформа безопасной, но кто и что строится на ней.

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

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

Первоначальная проблема Теневого ИТ была относительно простой: сотрудники использовали неавторизированные инструменты извне организации, и задачей безопасности было найти и заблокировать их. Теневой ИИ – это другое испытание. Инструменты находятся внутри платформ, которые вы одобрили. Люди, строящие их, – ваши собственные сотрудники. Доступ, который они используют, является законным. И ни одна из этих вещей не проходит через процессы безопасности, предназначенные для обнаружения проблем до того, как они достигнут производства.

То, что делает эту проблему особенно трудной для решения, – это масштаб. Большинство лидеров безопасности существенно занижают количество того, что строится внутри их собственных сред. Недавние исследования более 200 корпоративных директоров по информационной безопасности и лидеров безопасности показали, что средняя команда безопасности может отслеживать только 44% агентов ИИ, автоматизаций и приложений, созданных бизнес-пользователями. Это не пробел. Это слепое пятно, которое покрывает большинство того, что запущено.

Причина проста: бизнес-пользователи теперь численно превосходят профессиональных разработчиков в некоторых организациях. Они постоянно строят во всех отделах, на платформах, предназначенных для облегчения строительства, и затем поощряются руководством к строительству. Команды безопасности ориентированы на разработчиков и репозитории кода. Они никогда не предназначались для мониторинга этого.

Самое распространенное заблуждение заключается в том, что одобрение платформы решает проблему безопасности. Это не так, это просто перемещает ее. Когда корпорация заключает соглашение с Microsoft, Salesforce или UiPath, поставщик платформы обеспечивает безопасность своей инфраструктуры. Что сотрудники строят на ее основе и как они ее настраивают, – это полностью ответственность корпорации.

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

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

От нуля до катастрофы

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

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

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

Пробел управления, которого никто не оценил

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

Когда бизнес-агент утечет конфиденциальные данные, вопрос, который задаст совет директоров, не будет “как произошла эта ошибка конфигурации?” Он будет “как никто не знал, что этот инструмент запущен?” Они не будут различать нарушение, вызванное внешним атакующим, и нарушение, вызванное неправильно настроенным внутренним инструментом. Если были раскрыты личные данные и в организации не было видимости того, что запущено, отсутствие надзора само по себе является обязательством. “Сотрудник построил это на одобренной платформе” – это не защита, это описание пробела.

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

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

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

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