Безопасность LLM в компании: что защищать, в каком порядке и когда проверять

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

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

Общий контекст внедрения разобран в опорном материале: LLM для бизнеса.

Три способа потерять данные

Начнём с того, как это происходит в реальности, а не в каталоге уязвимостей.

Сотрудник уносит данные сам

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

У этого явления есть название: теневое использование, shadow AI. Специалисты Cleverbots описывают его как неконтролируемое обращение сотрудников к сторонним моделям, о котором служба безопасности не знает.

Запретительный подход здесь работает плохо. Как замечают в разборе на РБК Компании, отказ от публичных моделей не выход: сотрудники продолжат ими пользоваться, просто перестанут об этом сообщать. Рабочая связка другая: дать легальный инструмент, который решает ту же задачу, и одновременно описать, что в него можно нести, а что нельзя.

Система видит больше, чем должна

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

Формально утечки наружу нет. Фактически вы раздали внутренние документы всем, у кого есть доступ к чату.

Инъекция в промпт

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

Anti-Malware разделяет два вида:

Прямая инъекция. Злоумышленник пишет боту напрямую: «забудь предыдущие инструкции и сделай то-то». Модель не имеет встроенного механизма проверки, кто именно отдал команду.

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

Важно понимать: фильтром запрещённых слов это не лечится. Инструкцию можно переформулировать бесконечным числом способов. Работают другие вещи, и о них ниже.

Разграничение доступа важнее выбора модели

Если запомнить из этой статьи один пункт, пусть это будет он.

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

Что это даёт сразу:

• сотрудник не получит через чат документы, закрытые для него в системе-источнике;
• увольнение или смена роли автоматически меняют доступ и в AI-инструменте;
• в журнале видно, кто и какие документы получил.

Как выстроить это в системе корпоративного поиска, разбираю подробно в материале про RAG для бизнеса.

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

Что считает угрозами отрасль

Чтобы не изобретать список самостоятельно, полезно свериться с отраслевым ориентиром. OWASP поддерживает перечень LLM Top 10, разбор которого опубликован на Хабре. В верхней части списка:

1. промпт-инъекции;
2. отравление, кража и утечка данных;
3. проблемы цепочки поставок и подключаемых компонентов;
4. отказ в обслуживании;
5. галлюцинации модели.

Специалисты по безопасности в обзоре компании Raft называют примерно тот же набор, добавляя кражу модели и риски инфраструктуры машинного обучения.

Два пункта из списка стоит расшифровать, потому что их названия ничего не говорят руководителю.

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

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

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

Меры по уровням риска

Вот здесь начинается практика. Определите свой уровень и берите соответствующий набор.

Первые две строки нужны всем и внедряются в первую очередь. Они дают наибольший эффект на единицу усилий и не требуют бюджета на инфраструктуру.

Про регулируемые отрасли отдельно: если вы работаете с персональными данными в объёме, подпадающем под требования 152-ФЗ, статья в блоге не заменит юриста. Здесь нужна проверка конкретной конфигурации под вашу отрасль и страну.

Что на самом деле закрывает приватный контур

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

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

Всё остальное остаётся на вас:

• разграничение доступа нужно спроектировать и поддерживать самостоятельно;
• журналирование и аудит нужно настроить самостоятельно;
• маскирование персональных данных нужно реализовать самостоятельно;
• защита от промпт-инъекций работает точно так же, ваш сервер тут ни при чём;
• сотрудник по-прежнему может скопировать документ в публичный чат со своего телефона;
• ответственность за инцидент остаётся полностью на компании.

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

Когда он всё-таки оправдан: данные по закону или договору не могут покидать периметр, объём запросов высокий и устойчивый, есть команда для сопровождения. Экономика такого решения разобрана в материале про стоимость внедрения: речь идёт о капитальных вложениях в миллионы рублей вместо ежемесячного счёта.

Персональные данные и 152-ФЗ

Как только в переписке с ассистентом появляется имя клиента, его телефон или номер заказа, это обработка персональных данных со всеми требованиями закона. Технический вопрос «где стоит модель» здесь второй. Первый - на каком основании данные обрабатываются и кто за это отвечает.

Что считается персональными данными в переписке с ИИ

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

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

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

Кто отвечает: компания или подрядчик

Оператором остаётся компания, всегда. Подрядчик, который собрал систему, и провайдер модели - обработчики, действующие по поручению. Ответственность перед человеком, чьи данные обрабатываются, и перед регулятором лежит на операторе.

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

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

Что нужно сделать до запуска

Определить основание обработки для каждого потока данных, который попадает в модель.

Получить согласие там, где основанием служит именно оно, и сохранить подтверждение.

Закрепить обработчиков в договоре: кто, что именно делает с данными и на каких условиях.

Настроить маскирование до отправки в модель: заменять имена, телефоны и номера договоров на метки, если задача решается без них.

Ограничить срок хранения переписки с ассистентом и настроить автоматическое удаление по его истечении.

Описать порядок реагирования на запрос субъекта: как найти его данные в переписке, как их удалить и за какой срок.

Трансграничная передача

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

Зарубежная модель не запрещена, но требует отдельных оснований, и управляемым риск в этом случае становится чаще на бумаге, чем на практике: проверить, что происходит с данными на чужой стороне, вы не сможете. Разумный порядок такой: обезличенные задачи можно решать где угодно, задачи с настоящими персональными данными - внутри контура или у российского провайдера.

Что это меняет в архитектуре

Ничего нового по сравнению с мерами, описанными выше. Маскирование до отправки, разграничение доступа от имени пользователя, журналирование и ограничение прав инструментов остаются теми же техническими решениями.

Меняется их статус. Раньше это были меры разумной осторожности, которые можно было отложить. Теперь у них появляется юридическая причина, а у отложенного решения - последствия за пределами технического долга. Как это устроено на практике в проектах, я разбираю на странице про внедрение под ключ; подход к корпоративным базам знаний и тому, что именно уходит в модель при поиске по документам, разобран в материале про RAG и корпоративные базы знаний.

Когда проводить проверку

Ответ короткий: до ограниченного запуска, а не после.

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

В дорожной карте внедрения проверка безопасности встаёт между этапом интеграций и ограниченным запуском:

аудит процесса  ->  пилот  ->  данные и интеграции
                ->  ПРОВЕРКА БЕЗОПАСНОСТИ  ->  ограниченный запуск  ->  масштабирование

Что проверяется на этом шаге:

1. От чьего имени система обращается к источникам данных.
2. Может ли пользователь получить документ, закрытый для него в системе-источнике.
3. Какие поля уходят к провайдеру модели и все ли они там нужны.
4. Что пишется в журнал, кто имеет к нему доступ и сколько он хранится.
5. Какие действия система выполняет без подтверждения человека.
6. Что происходит при отказе модели или недоступности источника.

Шесть вопросов, ответы на которые нужно получить письменно. Если хотя бы на один ответа нет, запускать рано.

Разбор процесса вместе с ограничениями по данным входит в AI-аудит.

Что делать, если инцидент уже случился

Порядок действий стоит описать заранее, на холодную голову. В момент инцидента его никто не придумает.

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

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

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

Четвёртое: закрыть путь, а не следствие. Отозвать ключи доступа, сузить права, поправить конфигурацию. Восстановление сервиса без устранения причины означает повторение инцидента.

Пятое: зафиксировать выводы письменно. Что именно позволило этому произойти и какая проверка это ловит в следующий раз.

Частые вопросы

Можно ли просто запретить сотрудникам публичные нейросети? Формально да, практически нет. Запрет без альтернативы переводит использование в невидимую зону: люди продолжат работать через личные устройства, а вы потеряете даже возможность узнать об этом.

Обучаются ли модели на наших данных? Зависит от условий конкретного провайдера и тарифа. У корпоративных тарифов обычно предусмотрен отказ от использования данных для обучения. Это тот случай, когда условия читаются целиком и фиксируются в договоре, а не принимаются на слово.

Достаточно ли российской модели, чтобы соответствовать требованиям? Выбор провайдера решает вопрос трансграничной передачи, но не отменяет остальных требований к обработке персональных данных: оснований, сроков, прав субъекта. Соответствие определяется конфигурацией процесса целиком, а не страной поставщика.

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

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

Чек-лист

1. Выясните, чем сотрудники пользуются сейчас, и дайте легальную альтернативу.
2. Опишите список полей, которые не передаются модели никогда.
3. Постройте доступ от имени пользователя, а не от общей учётной записи.
4. Ограничьте права инструментов минимумом, необходимым для задачи.
5. Поставьте подтверждение человеком перед необратимыми действиями.
6. Включите журналирование и определите срок хранения.
7. Зафиксируйте письменно условия провайдера об использовании ваших данных.
8. Проведите проверку до ограниченного запуска, а не после.
9. Определите основание обработки для каждого потока данных, попадающего в модель.
10. Закрепите обработчиков в договоре с подрядчиком и провайдером.
11. Опишите порядок ответа на запрос субъекта персональных данных.

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

Нужен разбор ограничений вашего проекта?

На 30-минутном разборе пройдём по процессу и данным: какие ограничения реальны, какой минимум мер достаточен и нужен ли вам вообще закрытый контур.

Напишите мне в Telegram: https://t.me/dtamarov

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

Материал носит информационный характер и не заменяет юридическую консультацию и профессиональный аудит информационной безопасности.