Как примеры теневого ИИ выявляют скрытые риски

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

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

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

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

Теневой ИИ говорит о пробеле в контроле, а не о типе продукта

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

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

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

NIST AI Risk Management Framework 1.0 делит работу на функции Govern, Map, Measure и Manage. Здесь важен их порядок. Компания не может оценить риск или управлять сценарием, который не внесла в карту, а карта без владельца превращается в устаревшую таблицу. Поэтому реестру теневого ИИ с первого дня нужны доказательства и назначенные ответственные.

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

Браузерные расширения скрываются рядом с обычной работой

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

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

Если компания управляет браузерами, их корпоративный реестр даст самые чистые данные. Выгрузите идентификатор расширения, название, версию, источник установки, запрошенные разрешения, устройство, профиль браузера и время последнего появления. На контрольном устройстве страницы chrome://policy и edge://policy покажут, дошли ли правила для расширений до браузера. Политика, которая существует в панели администратора, но не действует на рабочих устройствах, остается намерением, а не мерой контроля.

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

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

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

Личные учетные записи превращают данные компании в частную историю

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

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

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

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

Личная учетная запись не всегда опасна, а слово «корпоративный» не гарантирует безопасность. Проверьте, обучаются ли модели поставщика на запросах, как долго хранится содержимое, может ли администратор удалить его, где субподрядчики обрабатывают данные и соответствуют ли условия договора типу информации. Верным решением может стать перенос работы в учетную запись компании, ограничение входных данных, замена инструмента или полный отказ от него.

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

Встроенный ИИ поставщика обходит старую проверку

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

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

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

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

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

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

Подключения и API-ключи расширяют возможный ущерб

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

Такое применение часто начинается с эксперимента. Инженер создает API-ключ для проекта выходного дня. Менеджер по продажам подключает помощника к календарю. Руководитель операционного отдела добавляет модель в один этап автоматизации. Прототип становится общим процессом, но учетные данные остаются привязаны к одному человеку, и никто не ограничивает расходы, не меняет секреты, не проверяет области доступа и не отвечает за сбои.

Ищите в панелях управления, где доступ уже фиксируется. Системы идентификации перечисляют разрешения OAuth и согласованные области доступа. Системы управления исходным кодом показывают установленные приложения и токены. Хранилища секретов в облаке, переменные CI/CD, платформы автоматизации, менеджеры паролей и сведения о расходах дают другие части картины. Сканирование репозиториев найдет случайно сохраненный ключ, но не обнаружит правильно сохраненный ключ, который используют в несогласованной задаче.

Названия областей доступа нужно толковать, а не просто переписывать. Доступ на чтение файлов может означать один выбранный файл или все файлы, которые видит пользователь. Автономный доступ может позволить сервису продолжить работу после закрытия сеанса браузера. Подключение с широкими правами сотрудника способно унаследовать доступ, случайно накопленный за годы. Спросите, что ему действительно нужно для задачи, затем создайте отдельную учетную запись или более узкую область, если платформа это позволяет.

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

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

Полный запрет уничтожает нужные доказательства

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

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

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

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

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

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

Поиск должен стать повторяемым циклом работы с доказательствами

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

1. Задайте охват и объявите амнистию. Назовите подразделения, устройства, типы данных и срок проверки. Объясните сотрудникам, что цель состоит в переводе полезной работы под контроль компании. Приведите примеры: личные чат-боты, браузерные дополнения, сводки встреч, переключатели ИИ у поставщиков, API моделей и подключенные агенты, чтобы ответы не ограничились очевидными чатами.
2. Соберите уже доступные доказательства. Выгрузите управляемые расширения браузера, приложения единого входа, разрешения OAuth, установленные приложения системы управления кодом, поставщиков из отчетов о расходах, этапы автоматизации, список одобренных поставщиков и настройки ИИ рабочих пространств. Используйте уже существующую законную телеметрию. Запишите дату сбора, потому что все эти системы меняются.
3. Спрашивайте о рабочих процессах. Проведите опрос по задачам: где сотрудники готовят краткие пересказы и черновики, расшифровывают речь, переводят, классифицируют, ищут, создают изображения, анализируют данные или автоматизируют решения? Затем коротко поговорите с подразделениями, которые работают с чувствительной информацией. Вопрос «Каким ИИ вы пользуетесь?» даст гораздо более бедный реестр.
4. Сопоставьте и проверьте. Свяжите заявленные инструменты с доменами, учетными записями, договорами, расширениями и подключениями. Подтвердите функцию, владельца, пользователей, входные и выходные данные, хранение, условия обучения, разрешения и действия. Помечайте факты как проверенные, заявленные, предполагаемые или неизвестные, чтобы рецензент не принял догадку за доказательство.
5. Примите решение и вернитесь к нему. Разрешите, ограничьте, перенесите, замените, приостановите или отклоните каждый сценарий. Назначьте владельца, дату проверки и условие для досрочного пересмотра. Сообщите сотрудникам об одобренных вариантах и следите, не появляется ли та же задача в другом инструменте.

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

use_case_id,business_task,tool,feature,account_type,owner,user_group,input_data,output_destination,access_scope,automated_actions,retention,model_training,contract_status,evidence_source,evidence_confidence,decision,conditions,review_date

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

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

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

Риск зависит от данных, охвата и действий

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

• Риск входных данных остается ниже для общедоступных или искусственных материалов и растет для секретов, персональных данных, договоров и исходного кода.
• Охват остается узким для одного выбранного объекта и растет при постоянном доступе к репозиториям или почтовым ящикам.
• Риск результата ниже для личного черновика, который проверит сотрудник, и выше для внешнего сообщения, изменения рабочей системы или решения о праве человека на услугу.
• Возможность действий ограничена без права записи и растет, если инструмент отправляет, меняет, удаляет, покупает или развертывает.
• Контроль сильнее в корпоративной учетной записи с владельцем и слабее в личной учетной записи без администратора.

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

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

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

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

Ответственный владелец сохраняет реестр живым

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

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

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

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

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

Если компании нужна внешняя исходная оценка, Team & AI Audit от oleg.is за пять рабочих дней составляет карту команды и применения ИИ, а затем связывает выводы с экономией в работе. Внутри компании действует то же правило: требуйте назвать процесс, доказательство, владельца и решение вместо слайда с логотипами.

Не ждите идеального продукта для обнаружения. Объявите период амнистии, выгрузите уже доступные доказательства и поговорите с подразделениями, которые выполняют самую чувствительную работу. Через несколько дней компания поймет, какие скрытые сценарии требуют контроля, какие нужно перевести в управляемую учетную запись, а какие показывают, что саму работу стоило перестроить много лет назад.