Безопасный доступ к нейросетям на предприятии — это правило, кто от чьего имени вызывает модель, какие данные можно передать и где это фиксируется. Без этого «внедрение ИИ» сводится к надежде, что сотрудники сами не вставят в чат выгрузку из CRM.
Статья про DLP и 152-ФЗ разбирает содержимое промпта. Здесь — контур вокруг: учётки, обход, журнал, разделение сред. Одно без другого не работает: можно маскировать паспорт в шлюзе и параллельно держать личный ChatGPT с тем же паспортом.
Теневой ИИ выглядит обыденно
Маркетинг сидит в бесплатном чате, юрист загружает договор в сервис «для саммари», разработчик положил ключ в переменные GitLab runner под личным аккаунтом. Никто из них не считает себя нарушителем. Они закрывают задачу, которую компания не закрыла официально.
Инцидент начинается не с хакера. Он начинается с вопроса регулятора или заказчика: покажите, какие персональные данные уходили в генеративные сервисы за квартал. Если ответа нет, это уже не «серая зона инноваций».
Запрет и канал — пара
Сетевые политики на известные адреса публичных чатов имеют смысл. Имеет смысл и запрет расширений, которые перехватывают буфер. Но если единственная альтернатива — «подождите стратегию», люди найдут зеркало или телефон.
Разрешённый канал: корпоративный вход (SSO), список моделей, квота, DLP на входе. Для приложений — ключ, выданный шлюзом, а не скопированный из личного кабинета поставщика. Это как раз ИИ-шлюз, а не прокси «чтобы открывалось».
Роли, которые реально нужны
Не обязательно копировать всю ролевую модель Active Directory. Минимум: пользователь-человек, сервис приложения, администратор политик, аудитор журналов. Админ политик не обязан читать чужие промпты. Аудитор не обязан менять маршруты моделей.
Разделение prod и sandbox обязательно. В песочнице можно слабые политики и дешёвые модели. В проде — allow-list и жёсткий DLP. Смешение этих сред — частая причина, почему «у нас в тесте всё маскировалось, а в проде ключ обошёл шлюз».
Что считать аудитом запроса
Аудит — не дамп всего диалога в Elasticsearch навсегда. Это возможность ответить: этот идентификатор заявки вызывал такую-то модель в такое-то время, DLP сработал или нет, ключ принадлежал такому-то сервису. Для разбора утечки этого достаточно чаще, чем кажется.
Если политика хранения требует сырой промпт — храните его как персональные данные: срок, права, шифрование. Иначе журнал станет вторым хранилищем ПДн без учёта в модели угроз.
Выгрузка в SIEM и ложные надежды
События шлюза имеют смысл в корпоративном мониторинге: всплеск запросов ночью, массовые блокировки DLP, ключ с чужого IP. Это не заменяет DLP внутри модели и не ловит сотрудника с телефоном.
Модель угроз честно включает канал «человек сфотографировал экран». Корпоративный доступ закрывает системный и массовый контур, а не каждый бытовой слив. Имеет смысл писать это в политике, чтобы ИБ не обещала невозможное.
С чего начать на месяц
Инвентаризация теневых сервисов. Решение: какие адреса закрываем. Ввод шлюза хотя бы для двух пилотных команд. SSO для людей, ключи для одного-двух приложений. Базовые правила DLP. Запрет прямых ключей поставщиков в проде.
Документ на две страницы важнее регламента на сорок. Когда пилот стабилен, подключайте SIEM и разбор инцидентов. Закупка и контур — на платформе; если нужен разбор поставки целиком — что такое AIaaS.
Частые вопросы
Это использование нейросетей в обход корпоративного канала: личные чаты, расширения браузера, ключи в личных кабинетах. Компания не видит, какие данные ушли, и не может при инциденте восстановить цепочку.
Запрет без альтернативы почти всегда порождает обход. Имеет смысл закрыть несанкционированные адреса и одновременно выдать разрешённый вход с ролями и журналом. Иначе задача сотрудника никуда не денется.
Кто вызвал, когда, какая модель, идентификатор приложения, факт срабатывания DLP. Сырой текст с персональными данными — только если это согласовано с обработкой ПДн и закрыто правами. Журнал «всего подряд» сам становится утечкой.
Для людей — да, иначе через полгода у вас таблица ключей в Confluence. Для сервисных учёток приложений — отдельные ключи с квотой и возможностью отозвать. Оба типа учёток живут на [шлюзе](/platform#gateway).