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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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