80% сотрудников уже используют неутвержденные генеративные ИИ-сервисы на работе, тогда как формальная политика управления такими инструментами есть только у 12% компаний. Теневой ИИ перестал быть маргинальной проблемой: для российских команд разработки, продуктовых отделов и ИБ это уже не спор про моду, а вопрос доступа к почте, исходникам, документам и внутренним данным.
Об этом сообщает BleepingComputer со ссылкой на материал Adaptive Security о том, как компаниям выстраивать практичное управление ИИ-инструментами без привычного сценария «все запретить и сломать людям работу». Логика проста: сотрудник ставит AI-ассистента для текстов, подключает coding copilot к IDE или включает сервис для саммаризации встреч, потому что хочет работать быстрее. Проблема в том, что такие сервисы часто получают доступ к Google Workspace, Microsoft 365, письмам, календарям, общим дискам и внутренним файлам через OAuth или сессию браузера, а служба безопасности узнает об этом в лучшем случае постфактум.
Здесь и возникает теневой ИИ: инструменты уже живут внутри процессов, но не проходят нормальную проверку. Классические средства защиты смотрят на почту, сетевой трафик и управляемые приложения. Браузерное расширение с ИИ, которому сотрудник за двадцать секунд выдал права на чтение документов или переписки, эти контуры легко обходит. Оно может вообще не касаться корпоративной сети в привычном понимании. Для ИБ это слепая зона, для бизнеса — риск случайной утечки, а для разработчиков и менеджеров — еще один пример того, как корпоративные процессы отстают от реальной практики на несколько кварталов.
В Adaptive Security предлагают начать не с репрессий, а с инвентаризации. Первый шаг — собрать полную картину того, что уже используется. Основных источников три. Во-первых, OAuth-подключения сторонних приложений к Google Workspace и Microsoft 365: квартальный аудит таких интеграций обычно вытаскивает десятки сервисов, которые никто официально не одобрял. Во-вторых, браузерные расширения: многие ИИ-инструменты живут именно там, поэтому традиционное управление конечными устройствами их просто не видит. В-третьих, ИИ-функции, которые появились внутри уже утвержденных продуктов после первоначальной закупки или проверки. В материале в качестве примеров названы Microsoft Copilot, Google Gemini и Salesforce Einstein. Отдельно советуют провести опрос сотрудников: если сформулировать его не как допрос, а как попытку помочь людям работать безопаснее, он нередко показывает то, что автоматические средства обнаружения пропускают.
Следующий шаг — политика, которую сотрудники не будут обходить в первый же день. Главная ошибка многих компаний в том, что они публикуют список запретов и на этом считают работу завершенной. На практике людям нужен не черный список, а понятный маршрут: какие инструменты разрешены, где их найти, какие данные запрещено загружать в любые ИИ-сервисы и как запросить новый продукт без бюрократии на полтора месяца. В такой политике важно зафиксировать как минимум пять вещей: перечень одобренных сервисов, правила классификации данных, подтвержденный отказ от использования корпоративных данных для дообучения модели там, где это критично, процесс запроса новых инструментов и целевой срок ответа. Последний пункт особенно важен: если сотруднику нужен сервис сегодня, а согласование длится шесть недель, он найдет обходной путь еще до первого письма от службы безопасности.
Отсюда вытекает третий принцип — сделать для новых ИИ-инструментов «быструю полосу». Не каждый запрос требует полноценной закупочной процедуры и многоэтапной оценки вендора. Для низкорисковых сервисов может хватить стандартизированной формы и набора критериев: к каким данным инструмент просит доступ, как у поставщика устроена защита, можно ли отключить обучение на пользовательских данных, есть ли комплаенс-сертификации и не дублирует ли он уже одобренный продукт. Это звучит почти очевидно, но в реальности именно отсутствие такого механизма и разгоняет теневой ИИ внутри компаний. Люди не ждут корпоративную машину, когда на рынке каждую неделю появляется новый помощник для кода, встреч, поиска или работы с документами.
Четвертый и пятый шаги касаются того, как сделать контроль не карательным, а рабочим. Adaptive Security предлагает постоянный мониторинг использования ИИ-инструментов как общий защитный слой для ИБ и самих сотрудников. Идея в том, чтобы видеть активность в браузере без перенаправления всего веб-трафика и без лишнего трения в ежедневной работе. Такие сигналы можно складывать в общий профиль риска сотрудника наряду с результатами фишинговых симуляций и прохождением обучения. Это полезно не потому, что один неразрешенный сервис сразу означает инцидент, а потому, что риски любят собираться в пачки: если человек кликает по фишинговым письмам, игнорирует тренинги и одновременно подключает к рабочим данным сомнительные ИИ-расширения, уровень проблемы резко меняется. Финальный акцент — обучение в моменте. Короткая подсказка прямо в момент попытки использовать несанкционированный сервис работает лучше, чем очередной квартальный курс на сорок минут. Особенно если она не читает мораль, а быстро объясняет риск и показывает одобренную альтернативу.
Для русскоязычной ИТ-аудитории в этой истории важен неприятный, но полезный вывод: вопрос уже не в том, будут ли сотрудники использовать ИИ без одобрения, а в том, насколько быстро компания признает это нормой и перестроит процессы под реальность. Там, где безопасность все еще спорит с продуктивностью, теневой ИИ будет расти. Там, где ИБ научится давать видимость, быстрые решения и понятные правила, ИИ из серой зоны постепенно превратится в управляемый корпоративный инструмент.