Shadow AI: что делать, если сотрудники уже используют ИИ без правил

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

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

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

Сначала найдите не инструменты, а рабочие сценарии

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

Я бы провёл короткую инвентаризацию: какие задачи уже делегируют AI, какие данные туда попадают, откуда они берутся, что сотрудник делает с результатом и есть ли официальная альтернатива. Не как расследование нарушений, а как карта фактической работы.

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

Проверяемые источники: NIST — AI Risk Management Framework · European Commission — AI Literacy — Questions & Answers

Один запрет для всех данных почти наверняка слишком грубый

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

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

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

Проверяемые источники: NIST — AI Risk Management Framework · OWASP GenAI Security Project — Agentic AI — Threats and Mitigations

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже

Четыре нормальных ответа вместо бинарного «можно / нельзя»

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

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

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

Проверяемые источники: OWASP GenAI Security Project — Agentic AI — Threats and Mitigations

AI literacy должна объяснять конкретную цену ошибки

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

Европейская комиссия в актуальном разъяснении по AI literacy прямо связывает обучение с ролью организации, знаниями сотрудников, контекстом использования и риском систем. Мне нравится эта логика независимо от юрисдикции: разным людям действительно нужны разные знания. Маркетологу и инженеру интеграций не поможет один и тот же часовой вебинар.

Для высокорисковой работы я бы добавил практические упражнения: где искать разрешённый инструмент, как обезличить вход, как проверить утверждение, когда остановиться и кому передать спорный случай. Тогда политика становится частью рабочего навыка, а не PDF, который однажды подписали.

Проверяемые источники: European Commission — AI Literacy — Questions & Answers · European Commission — AI Act — regulatory framework

Безопасный корпоративный маршрут должен быть проще теневого

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

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

OWASP в рекомендациях для agentic AI отдельно обращает внимание на инструменты, память, права и человеческий контроль. Даже если сотрудники пока пользуются обычными чатами, вектор понятен: по мере появления агентов вопрос перестаёт быть только про текст, потому что система получает возможность действовать.

Проверяемые источники: OWASP GenAI Security Project — Agentic AI — Threats and Mitigations

Как измерять, становится ли Shadow AI меньше

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

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

Для меня хороший признак — когда сотруднику проще спросить «как сделать это безопасно?», чем спрятать использование. Если компания достигает этого состояния, Shadow AI перестаёт быть исключительно дисциплинарной проблемой и становится управляемой частью технологического изменения.

Проверяемые источники: NIST — AI Risk Management Framework · European Commission — AI Literacy — Questions & Answers

Вопросы, которые я бы уточнил до следующего шага

Нужно ли полностью запрещать публичные AI-сервисы сотрудникам?

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

Как найти Shadow AI, не превращая работу в слежку?

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

Что важнее: политика или корпоративный AI-инструмент?

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

Я бы относился к Shadow AI чуть спокойнее, чем принято. Сам факт неформального использования — не хороший знак, но и не повод сразу закрывать доступ ко всему. Это возможность увидеть, где официальный процесс проиграл реальной работе. Дальше вопрос уже практический: можем ли мы дать человеку безопасный путь, который не хуже обходного?

Рядом с этой темой я бы держал для «shadow AI»: Как подготовить данные компании к внедрению AI · Как безопасно дать AI доступ к CRM и внутренним системам · Какие действия AI можно выполнять автоматически, а какие требуют подтверждения.