В компании появился сотрудник, которого никто не нанимал. Он переписывает письма, чистит выгрузки, объясняет чужой код и собирает презентации. Он не подписывал NDA, и никто в компании не знает, где он хранит то, что ему показали.
Это не метафора будущего. Это описание текущего дня в большинстве организаций, где есть интернет и сотрудники, которым нужно успеть до вечера.
Почему запрет не работает
Первая реакция на теневой ИИ предсказуема: заблокировать домены на прокси, прописать запрет в политике, провести инструктаж под подпись. Мера понятная, и в отчёте она выглядит убедительно.
Проблема в том, что она меняет не поведение, а его видимость.
У сотрудника есть задача и дедлайн. Инструмент, который сокращает работу с двух часов до десяти минут, он не перестанет использовать из-за строчки в политике. Он достанет телефон. Перешлёт файл на личную почту, чтобы открыть его дома. Попросит коллегу из другого отдела, где блокировка ещё не доехала.
Запрет на корпоративном периметре не убирает риск. Он выносит его туда, где у вас нет ни логов, ни контроля, ни шанса узнать о проблеме раньше, чем она станет публичной.
Есть и второй эффект, менее очевидный. Запрет, который все обходят, обесценивает остальные правила. Если политика ИБ разошлась с реальностью в одном месте, к ней перестают относиться серьёзно и во всех прочих. Это дороже, чем конкретная утечка.
Поэтому задача формулируется не как «запретить», а как «сделать управляемым». Дальше – три слоя, от самого дешёвого к самому затратному.
Слой первый: видимость
Нельзя управлять тем, о чём не знаешь. Первый шаг не про технику и не про политику, а про инвентаризацию: какими ИИ-сервисами в компании реально пользуются.
Слово «реально» здесь ключевое. Вопрос не в том, что вы разрешили, а в том, что открыто в соседней вкладке прямо сейчас.
Как собрать эти данные.
Опрос работает лучше, чем ожидается, но только при одном условии: он должен быть анонимным и подчёркнуто безнаказанным. Формулировка «хотим понять, что вам полезно, чтобы дать нормальный корпоративный доступ» даёт совсем другой отклик, чем «сообщите о фактах использования». В первом случае сотрудник помогает себе, во втором – сдаёт себя.
Логи прокси и DNS дают фактическую картину по корпоративному контуру. Смотреть стоит не только на очевидные домены известных моделей, но и на агрегаторы, расширения браузеров и плагины к редакторам: значительная часть трафика идёт через них, и в отчётах они не выглядят как «ИИ».
CASB и DLP покажут, что именно уходит, если они у вас есть. Если нет, начинать с их закупки ради этой задачи не стоит – слишком дорогой вход.
Что записывать. Реестр ИИ-сервисов имеет смысл вести с минимальным набором полей, иначе его перестанут заполнять на второй неделе:
- сервис и его владелец внутри компании – конкретный человек, а не отдел;
- какие задачи решает и кто пользуется;
- какие категории данных туда попадают фактически;
- где обрабатываются данные, в какой юрисдикции;
- статус: разрешён, разрешён с ограничениями, запрещён, на рассмотрении.
Последнее поле важнее остальных. Реестр без статусов – это инвентаризация ради инвентаризации. Реестр со статусами – основа для разговора с бизнесом.
Слой второй: правила, которые помещаются на один экран
Здесь совершается самая частая ошибка: вместо правил пишут политику на двенадцать страниц с определениями, ссылками на стандарты и таблицей ролей. Её согласуют полгода, утверждают приказом и не читают никогда.
Правило, которое работает, помещается на один экран и понимается без юриста.
Практичная схема – три уровня данных.
Зелёный: можно без ограничений. Публичная информация, обезличенные тексты, общие вопросы по технологиям, черновики, не содержащие внутренних деталей. Сюда попадает большая часть повседневных задач, и это важно проговорить явно: если правила запрещают всё, ими не будут пользоваться.
Жёлтый: можно после обработки. Внутренние документы без персональных данных, фрагменты кода без секретов и специфики инфраструктуры, аналитика с заменёнными названиями. Условие – обезличивание перед отправкой, и лучше дать сотрудникам готовый инструмент, а не требование «удалите всё лишнее».
Красный: нельзя никогда. Персональные данные клиентов и сотрудников, коммерческая тайна, учётные данные и ключи, исходники критичных систем, документы под NDA с третьими сторонами, всё, что относится к охраняемым законом категориям.
Дальше – две детали, без которых схема не взлетает.
Первая: у каждого уровня должен быть разрешённый маршрут. Красное нельзя отправлять в публичный сервис – но можно в развёрнутую внутри контура модель, если она есть. Если маршрута нет вообще, сотрудник найдёт свой.
Вторая: правила должны отвечать на вопрос «а если очень надо». Процедура исключения с владельцем и сроком лучше, чем негласная практика нарушать в авральных случаях.
Слой третий: требования к поставщику
Когда сервис переходит из «им пользуются втихую» в «мы это разрешили», появляется вопрос к вендору. Минимальный набор, который стоит выяснить до, а не после:
- Юрисдикция обработки. Где физически обрабатываются и хранятся запросы. Для персональных данных это не вопрос предпочтений, а вопрос применимости закона.
- Обучение на ваших данных. Уходят ли запросы в дообучение модели, и можно ли это отключить договором, а не галочкой в интерфейсе.
- Срок хранения. Сколько живут запросы и ответы, включая копии в логах и системах модерации.
- Удаление по требованию. Есть ли механизм, и в какие сроки он отрабатывает.
- Разграничение доступа. Может ли администратор со стороны компании видеть, кто и что отправлял, – и, что не менее важно, может ли он этого не видеть, когда не должен.
- Сертификация и аудит. Есть ли независимые проверки, и готов ли поставщик показать отчёт, а не логотип на сайте.
Отдельный вопрос – когда разумнее развернуть модель внутри контура. Ответ зависит не от паранойи, а от арифметики: если через сервис регулярно проходят данные жёлтого и красного уровня, стоимость собственного развёртывания может оказаться ниже стоимости одного разбирательства с регулятором. Если же речь про помощь с формулировками в письмах, городить инфраструктуру незачем.
Что с регулированием
Летом подписан Федеральный закон № 243-ФЗ о поддержке развития технологий искусственного интеллекта. Читать его как источник требований к обычной компании пока рано: он посвящён преимущественно большим фундаментальным моделям и их разработчикам, вводит понятия суверенных и национальных моделей и задаёт рамку.
Общего запрета иностранных моделей в нём нет. Обязательной маркировки всего, что создано с помощью ИИ, – тоже.
Конкретика ожидается в подзаконных и отраслевых актах, и вот тут стоит быть готовым заранее. Практически любое будущее требование начинается с одного и того же вопроса: какие ИИ-сервисы вы используете и какие данные туда передаёте. Компания, у которой реестр уже есть, ответит за день. Компания, у которой его нет, будет собирать ответ месяц и всё равно соберёт неточно.
Это и есть главный практический аргумент за реестр: он нужен вам раньше, чем его спросят.
План на две недели
Если начинать с нуля, разумный порядок такой.
Первая неделя – смотреть. Выгрузить статистику по прокси и DNS за последний месяц, отфильтровать ИИ-сервисы, включая расширения и плагины. Запустить анонимный опрос с честной формулировкой. Свести в таблицу и удивиться.
Вторая неделя – договориться. Отнести картину владельцам процессов: вот чем пользуются ваши люди, вот какие данные туда уходят. Согласовать три уровня на конкретных примерах их работы, а не в абстракции. Выбрать один-два сервиса, которые станут официально разрешёнными, и обеспечить к ним нормальный доступ.
Дальше – поддерживать. Реестр без пересмотра устаревает за квартал. Раз в три месяца проходить по нему заново: что добавилось, что отвалилось, где статус разошёлся с реальностью.
Что в сухом остатке
Теневой ИИ – не технологическая проблема и не проблема дисциплины. Данные уходят не потому, что сотрудники безответственные, а потому, что компания не ответила на простой вопрос: чем пользоваться можно, что туда допустимо класть и куда идти, если очень надо.
Пока ответа нет, каждый отвечает себе сам. И отвечает в пользу удобства – потому что у него дедлайн, а у вас политика.
Правила проигрывают не запретам. Они проигрывают отсутствию правил.