Разговор о безопасности языковых моделей обычно устроен так: читателю выдают список из сорока угроз и предлагают закрыть их все. Список честный, а совет бесполезный. Компании из тридцати человек и банку нужны разные меры, и начинать им нужно с разного.
Эта статья про порядок действий: где данные теряются на практике, что защищать в первую очередь, какой минимум достаточен на вашем уровне риска и на каком этапе проекта проводить проверку.
Общий контекст внедрения разобран в опорном материале: LLM для бизнеса.
Три способа потерять данные
Начнём с того, как это происходит в реальности, а не в каталоге уязвимостей.
Сотрудник уносит данные сам
Самый частый и самый недооценённый путь. Человек копирует договор, выгрузку из базы или переписку с клиентом в публичный чат, чтобы быстрее составить ответ. Он не злоумышленник, он экономит время.
У этого явления есть название: теневое использование, shadow AI. Специалисты Cleverbots описывают его как неконтролируемое обращение сотрудников к сторонним моделям, о котором служба безопасности не знает.
Запретительный подход здесь работает плохо. Как замечают в разборе на РБК Компании, отказ от публичных моделей не выход: сотрудники продолжат ими пользоваться, просто перестанут об этом сообщать. Рабочая связка другая: дать легальный инструмент, который решает ту же задачу, и одновременно описать, что в него можно нести, а что нельзя.
Система видит больше, чем должна
Ошибка проектирования, которая обходится дороже всего. AI-ассистент подключают к файловому хранилищу или базе знаний под общей учётной записью с полным доступом. Дальше рядовой сотрудник через чат получает то, что не открыл бы в интерфейсе хранилища: зарплатную ведомость, документы соседнего отдела, черновики договоров.
Формально утечки наружу нет. Фактически вы раздали внутренние документы всем, у кого есть доступ к чату.
Инъекция в промпт
Класс атак, которого не существовало до языковых моделей. Суть в том, что модель не отличает инструкцию разработчика от текста, который ей передали на обработку.
Anti-Malware разделяет два вида:
Прямая инъекция. Злоумышленник пишет боту напрямую: «забудь предыдущие инструкции и сделай то-то». Модель не имеет встроенного механизма проверки, кто именно отдал команду.
Косвенная инъекция. Опаснее и незаметнее. Вредоносная инструкция заранее спрятана в документе, письме или на веб-странице, которые система обработает штатным образом. Пользователь ни при чём, атакующий с системой не общался, а команда выполнена.
Важно понимать: фильтром запрещённых слов это не лечится. Инструкцию можно переформулировать бесконечным числом способов. Работают другие вещи, и о них ниже.
Разграничение доступа важнее выбора модели
Если запомнить из этой статьи один пункт, пусть это будет он.
Система должна действовать от имени конкретного пользователя и видеть ровно то, что видит он. Не больше. Технически это означает, что права проверяются на этапе поиска документов, а не на этапе показа ответа. Разница принципиальна: во втором случае данные уже попали в модель и могли просочиться в формулировку.
Что это даёт сразу:
- сотрудник не получит через чат документы, закрытые для него в системе-источнике;
- увольнение или смена роли автоматически меняют доступ и в AI-инструменте;
- в журнале видно, кто и какие документы получил.
Как выстроить это в системе корпоративного поиска, разбираю подробно в материале про RAG для бизнеса.
Практическое следствие для инъекций: если система не имеет прав на опасное действие, выполнить его она не сможет, какую бы команду в неё ни внедрили. Ограничение прав инструментов работает лучше любого фильтра. Второй рабочий приём это подтверждение человеком перед необратимыми операциями: отправкой письма клиенту, изменением записи в базе, платежом.
Что считает угрозами отрасль
Чтобы не изобретать список самостоятельно, полезно свериться с отраслевым ориентиром. OWASP поддерживает перечень LLM Top 10, разбор которого опубликован на Хабре. В верхней части списка:
- промпт-инъекции;
- отравление, кража и утечка данных;
- проблемы цепочки поставок и подключаемых компонентов;
- отказ в обслуживании;
- галлюцинации модели.
Специалисты по безопасности в обзоре компании Raft называют примерно тот же набор, добавляя кражу модели и риски инфраструктуры машинного обучения.
Два пункта из списка стоит расшифровать, потому что их названия ничего не говорят руководителю.
Отравление данных это подмена содержимого источников, на которые опирается система. Если в вашу базу знаний попадёт документ с неверной инструкцией, ассистент будет уверенно её транслировать всем, кто спросит. Защита здесь не техническая, а процессная: кто имеет право добавлять документы в индекс и кто это проверяет.
Проблемы цепочки поставок это риски компонентов, которые вы не писали: библиотек, плагинов, сторонних сервисов в конвейере. Каждое подключённое расширение получает доступ к данным, которые через него проходят. Перед подключением стоит спросить, что именно этот компонент видит и куда отправляет.
Список полезен как карта, но не как план работ. Перечень меняется, и закрывать его целиком компании вне регулируемых отраслей не нужно.
Меры по уровням риска
Вот здесь начинается практика. Определите свой уровень и берите соответствующий набор.
| Мера | Внутренний помощник без ПДн | Работа с данными клиентов | Регулируемая отрасль |
|---|---|---|---|
| Права доступа от имени пользователя | обязательно | обязательно | обязательно |
| Список запрещённых к передаче полей | обязательно | обязательно | обязательно |
| Журнал обращений и ответов | желательно | обязательно | обязательно |
| Подтверждение человеком для внешних действий | желательно | обязательно | обязательно |
| Маскирование персональных данных | нет | обязательно | обязательно |
| Договор с провайдером о неиспользовании данных | желательно | обязательно | обязательно |
| Сроки хранения и удаления журналов | желательно | обязательно | обязательно |
| Обособленный контур обработки | нет | по обстоятельствам | обязательно |
| Сертифицированные средства защиты | нет | нет | обязательно |
| Юридическая проверка под отрасль | нет | обязательно | обязательно |
Первые две строки нужны всем и внедряются в первую очередь. Они дают наибольший эффект на единицу усилий и не требуют бюджета на инфраструктуру.
Про регулируемые отрасли отдельно: если вы работаете с персональными данными в объёме, подпадающем под требования 152-ФЗ, статья в блоге не заменит юриста. Здесь нужна проверка конкретной конфигурации под вашу отрасль и страну.
Что на самом деле закрывает приватный контур
Тема, вокруг которой больше всего маркетинга. В выдаче по этому запросу половина материалов принадлежит вендорам решений для закрытого контура, и вывод у них одинаковый.
Разберём честно. Развёртывание модели на своих серверах закрывает ровно одну вещь: данные не покидают ваш периметр. Это существенно, и для некоторых отраслей решающе.
Всё остальное остаётся на вас:
- разграничение доступа нужно спроектировать и поддерживать самостоятельно;
- журналирование и аудит нужно настроить самостоятельно;
- маскирование персональных данных нужно реализовать самостоятельно;
- защита от промпт-инъекций работает точно так же, ваш сервер тут ни при чём;
- сотрудник по-прежнему может скопировать документ в публичный чат со своего телефона;
- ответственность за инцидент остаётся полностью на компании.
У крупного провайдера часть механизмов вдобавок уже реализована и протестирована, а в своём контуре вы строите их с нуля силами своей команды. Приватный контур даёт не готовую безопасность, а перенос ответственности за неё на себя.
Когда он всё-таки оправдан: данные по закону или договору не могут покидать периметр, объём запросов высокий и устойчивый, есть команда для сопровождения. Экономика такого решения разобрана в материале про стоимость внедрения: речь идёт о капитальных вложениях в миллионы рублей вместо ежемесячного счёта.
Когда проводить проверку
Ответ короткий: до ограниченного запуска, а не после.
Разница в цене принципиальна. Проблема с правами доступа, найденная на этапе интеграции, стоит нескольких дней работы. Та же проблема после запуска стоит инцидента, объяснений с клиентами и, в регулируемой отрасли, разговора с регулятором.
В дорожной карте внедрения проверка безопасности встаёт между этапом интеграций и ограниченным запуском:
аудит процесса -> пилот -> данные и интеграции
-> ПРОВЕРКА БЕЗОПАСНОСТИ -> ограниченный запуск -> масштабирование
Что проверяется на этом шаге:
- От чьего имени система обращается к источникам данных.
- Может ли пользователь получить документ, закрытый для него в системе-источнике.
- Какие поля уходят к провайдеру модели и все ли они там нужны.
- Что пишется в журнал, кто имеет к нему доступ и сколько он хранится.
- Какие действия система выполняет без подтверждения человека.
- Что происходит при отказе модели или недоступности источника.
Шесть вопросов, ответы на которые нужно получить письменно. Если хотя бы на один ответа нет, запускать рано.
Разбор процесса вместе с ограничениями по данным входит в AI-аудит.
Что делать, если инцидент уже случился
Порядок действий стоит описать заранее, на холодную голову. В момент инцидента его никто не придумает.
Первое: остановить поток. Отключить интеграцию или сам сервис, а не пытаться сначала разобраться. Разбор занимает часы, а данные уходят в это время.
Второе: определить объём. По журналу обращений понять, какие данные и за какой период прошли через систему и кто их получил. Если журнала нет, вы не сможете ответить ни себе, ни клиенту, ни регулятору. Это, кстати, лучший аргумент за журналирование из всех существующих.
Третье: оценить обязанность уведомления. В части случаев компания обязана сообщить о произошедшем субъектам данных и регулятору, причём в ограниченный срок. Здесь нужен юрист, и лучше знать его телефон заранее.
Четвёртое: закрыть путь, а не следствие. Отозвать ключи доступа, сузить права, поправить конфигурацию. Восстановление сервиса без устранения причины означает повторение инцидента.
Пятое: зафиксировать выводы письменно. Что именно позволило этому произойти и какая проверка это ловит в следующий раз.
Частые вопросы
Можно ли просто запретить сотрудникам публичные нейросети? Формально да, практически нет. Запрет без альтернативы переводит использование в невидимую зону: люди продолжат работать через личные устройства, а вы потеряете даже возможность узнать об этом.
Обучаются ли модели на наших данных? Зависит от условий конкретного провайдера и тарифа. У корпоративных тарифов обычно предусмотрен отказ от использования данных для обучения. Это тот случай, когда условия читаются целиком и фиксируются в договоре, а не принимаются на слово.
Достаточно ли российской модели, чтобы соответствовать требованиям? Выбор провайдера решает вопрос трансграничной передачи, но не отменяет остальных требований к обработке персональных данных: оснований, сроков, прав субъекта. Соответствие определяется конфигурацией процесса целиком, а не страной поставщика.
Чек-лист
- Выясните, чем сотрудники пользуются сейчас, и дайте легальную альтернативу.
- Опишите список полей, которые не передаются модели никогда.
- Постройте доступ от имени пользователя, а не от общей учётной записи.
- Ограничьте права инструментов минимумом, необходимым для задачи.
- Поставьте подтверждение человеком перед необратимыми действиями.
- Включите журналирование и определите срок хранения.
- Зафиксируйте письменно условия провайдера об использовании ваших данных.
- Проведите проверку до ограниченного запуска, а не после.
Полного покрытия рисков этот список не даёт и дать не может. Он закрывает те пути, по которым данные теряются чаще всего.
Нужен разбор ограничений вашего проекта?
На 30-минутном разборе пройдём по процессу и данным: какие ограничения реальны, какой минимум мер достаточен и нужен ли вам вообще закрытый контур.
Напишите мне в Telegram: https://t.me/dtamarov
Подготовьте описание процесса, список систем и данных, которые в нём участвуют, и требования регулятора, если они к вам применимы.
Материал носит информационный характер и не заменяет юридическую консультацию и профессиональный аудит информационной безопасности.
