Разговор об утечках через ИИ обычно сводится к одному сценарию — «данные ушли в обучение». Он не единственный и, как правило, не самый вероятный. Каналов несколько, и большинство из них не связано с моделью напрямую.
Каналы
Запрос во внешний сервис. Всё переданное покидает периметр. Даже если поставщик обязуется не использовать данные для обучения, факт передачи третьему лицу остаётся.
Обучение на ваших данных. Механика риска: попав в обучающую выборку, редкая уникальная строка — номер договора, ключ, кодовое слово — может быть запомнена моделью и воспроизведена в чужом ответе. Общие формулировки почти не всплывают, уникальные значения — могут; поэтому пункт договора о неиспользовании данных важнее для справочников и Credentials, чем для обычной переписки.
Хранение и кэши на стороне провайдера. Даже без обучения запросы какое-то время живут у поставщика: журналы мониторинга злоупотреблений, кэш промптов для ускорения, резервные копии. Сроки и состав этого хранения — часть условий обслуживания, а не свойство модели.
Журналы. Недооценённый канал. Запросы и ответы пишутся в логи приложения, в систему мониторинга, в отладочные файлы — часто без ограничения доступа и без срока хранения.
Индекс поиска. В векторной базе лежат ваши документы. Вектор не шифр: по нему частично восстанавливается исходный текст. Размещение индекса во внешнем сервисе стоит оценивать так же, как размещение самих документов.
Ответ не тому пользователю. Если разграничение доступа не настроено, система выдаёт сотруднику фрагмент документа, который ему не положен. Это утечка внутри периметра, и обнаруживается она обычно случайно.
Промпт-инъекция. Инструкция, спрятанная в обрабатываемом документе, способна заставить систему раскрыть содержимое контекста — механизм того же рода, что и джейлбрейк, но источник инструкции внешний.
Сотрудники. Самый частый путь на практике: человек копирует рабочий документ в публичный чат-сервис, чтобы быстрее сделать задачу.
Что делать с каждым
Обезличивание закрывает первый канал. Ограничение и срок хранения журналов — второй. Размещение индекса внутри периметра — третий. Фильтрация по правам во время поиска — четвёртый. Минимальные полномочия и подтверждение человеком — пятый.
Перед всеми этими мерами — минимизация состава запроса: из документа выбираются только поля, нужные задаче, и наружу не идёт остальное. Это самая дешёвая мера из всех: не требует конвейеров и инфраструктуры, только честный ответ на вопрос, что модели действительно нужно для задачи.
Шестой не закрывается техникой: нужна политика использования ИИ и понятная сотрудникам альтернатива. Запрет без предоставленного инструмента приводит к обходу запрета, а не к соблюдению.
Что проверить в договоре с провайдером
До подписания стоит получить письменные ответы на пять вопросов. Формулировки потом оценивает юрист, но сами вопросы технические, и задавать их должен не он.
Используются ли наши данные для обучения — включая субподрядчиков провайдера, а не только его самого.
Срок хранения запросов. У крупных API-провайдеров он по общему правилу ограничен днями и различается между тарифами; точное значение читают в действующих условиях, а не в статьях. Для вас важно число и момент, когда данные удаляются необратимо.
Кэш промптов и его срок. Ускорение ответов через кэширование — обычная практика; вопрос в том, кто и как долго может получить содержимое кэша.
Место обработки и цепочка субпроцессоров. Региональные эндпоинты против глобальных; вопросы локализации и трансграничной передачи разобраны в карточке «Персональные данные в ИИ-системах».
Уведомление об инцидентах — в какой срок и в каком виде провайдер сообщает о утечке со своей стороны.
Отдельная проверка: меняются ли эти условия в одностороннем порядке. Если да — технические меры строят так, чтобы изменение условий не меняло фактическую схему: обезличивание на входе, минимальный состав запроса.
Что проверить в первую очередь
Порядок инвентаризации — от дешёвого к дорогому. Сначала список: какие ИИ-сервисы фактически используются в компании — по опросу и логам прокси, расхождение между этими двумя источниками обычно показательно. Потом трассировка: что реально уходит в запросах работающих систем. Потом аудит журналов: куда пишутся запросы и ответы, кто имеет доступ, сколько хранится.
В большинстве проектов ответ на эти три вопроса неизвестен, а риск при этом реальный и легко устранимый.
Что записать в политику использования
Технические меры закрывают часть каналов, а самый частый — сотрудник, копирующий документ в публичный сервис, — закрывается только договорённостями. Документ на две страницы работает лучше регламента на двадцать, если в нём есть четыре вещи.
Что можно передавать и что нельзя — списком, с примерами, а не общими формулировками вроде «конфиденциальные сведения».
Какими сервисами пользоваться разрешено. Запрет без разрешённой альтернативы приводит к обходу: человеку нужно сделать работу.
Что делать при сомнении и к кому обращаться.
Что будет при нарушении — без этого документ читают как рекомендацию.
Как обнаружить утечку постфактум
Полностью — никак, и это стоит принимать в расчёт. Косвенные признаки: обращения к внешним ИИ-сервисам в логах прокси, всплески трафика на такие домены, появление внутренних формулировок в чужих материалах.
Поэтому план на инцидент готовят заранее: кто принимает решение об отзыве и удалении данных у провайдера, как инициируется удаление чатов и запросов, что делается с компрометированными секретами, кого и в какой срок уведомляют. В момент инцидента времени писать этот план нет.
Практический вывод: раз обнаружение слабое, вес переносится на предотвращение — обезличивание, ограничение того, что вообще попадает в запрос, и понятная сотрудникам альтернатива.
Частые вопросы
Используются ли мои данные для обучения модели?
Зависит от поставщика и тарифа: часть сервисов обязуется этого не делать, часть — нет, и условия меняются. Но даже при отказе от обучения передача данных третьему лицу остаётся фактом, который надо отражать в документах об обработке.
Какой канал утечки самый частый?
На практике — сотрудники, копирующие рабочие документы в публичные чат-сервисы. Техническими мерами это не закрывается: нужна политика и предоставленный людям рабочий инструмент, иначе запрет обходят.
Насколько опасен векторный индекс?
Вектор не является шифром: по нему частично восстанавливается исходный текст. Поэтому индекс с конфиденциальными документами следует размещать с теми же требованиями, что и сами документы.
Отличаются ли риски у API и у веб-чата того же провайдера?
Как правило да: условия у интерфейсных сервисов и программного доступа разные, и в потребительских тарифах использование ввода для улучшения сервиса встречается чаще. Проверять надо актуальные условия именно вашего тарифа, а не общее описание провайдера, и фиксировать это в договоре.
Что делать, если документ уже ушёл в публичный сервис?
Действия по порядку: удалить чат или запросить удаление у сервиса; если уходили секреты — отозвать и перевыпустить их; зафиксировать обстоятельства для разбора; уведомить тех, кого это касается, по вашей политике. И разобраться с причиной: единичный случай закрывается разговором, систематический — отсутствием нормального инструмента.
Стоит ли просто закрыть внешние ИИ-сервисы на файрволе?
Как единственная мера — нет: сотрудники находят обходы, от личных устройств до зеркал, и теряется видимость. Рабочая схема — закрыть то, что не соответствует политике, одновременно дав корпоративный инструмент с нужными возможностями и объяснив, чем он лучше обходных путей. Контроль остаётся: логи прокси показывают и объём обходного трафика, и результат его сокращения.