Залить данные проекта в нейросеть — самый быстрый способ получить проблему

Команда получает новый инструмент на базе языковой модели, кто-то из специалистов копирует содержимое рабочих файлов прямо в диалоговое окно и радуется ответу. Через неделю выясняется, что в запрос попали фрагменты отчёта с конфиденциальными находками, а модель работает на серверах за пределами юрисдикции заказчика. Договор о неразглашении мог быть нарушен — хотя никто не собирался ничего «сливать».

Безопасная работа с нейросетями — не факультативная тема, а часть архитектуры рабочего процесса. Защитные меры встраиваются заранее, наравне с выбором инструментов и распределением ролей. В 2023 году инженеры Samsung загрузили фрагменты закрытого исходного кода и протоколы внутренних совещаний в публичный чат-бот — инцидент вынудил компанию запретить сотрудникам использовать внешние языковые модели на рабочих устройствах. Утечки случаются, и разбираться с последствиями дороже, чем заранее выстроить защиту.

Публичный чат, корпоративный аккаунт и программный интерфейс — три разных режима

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

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

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

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

Какие данные требуют особого обращения

Персональные данные

Российский закон о персональных данных № 152-ФЗ регулирует трансграничную передачу в статье 12. Закон не запрещает передавать персональные данные за рубеж в принципе, но требует соблюсти ряд условий. До начала передачи оператор должен уведомить Роскомнадзор и указать правовое основание, цели обработки, категории передаваемых данных, страны, куда направляются данные, а также сведения о принимающей стороне.

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

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

Биометрические и медицинские сведения регулируются ещё строже. Даже после формального обезличивания медицинские записи при определённых условиях позволяют восстановить личность пациента — если совместить их с другими источниками по набору квазиидентификаторов (дата рождения, пол, почтовый индекс). Учитывать риск реидентификации нужно всегда.

Артефакты тестирования на проникновение и коммерческая тайна

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

Конкретная ситуация: тестировщик вставляет в диалоговое окно вывод сетевого сканера с внутренними адресами подсети заказчика, чтобы модель помогла рассортировать открытые порты. Два клика — и топология внутренней сети ушла на внешний сервер. Другой пример — разработчик загрузил трассировку стека вызовов (stack trace) с действующим токеном доступа.

Компании из финансового сектора, медицины, госструктур и объектов критической информационной инфраструктуры (КИИ) сталкиваются с дополнительными ограничениями. В отдельных регулируемых проектах договор, внутренние политики или отраслевые требования могут предписывать обрабатывать данные только на территории определённой страны, на сертифицированном оборудовании.

Матрица допустимости

Абстрактные предупреждения «не загружайте ничего важного» не работают, потому что в реальном проекте каждый второй файл кажется важным. Команде нужна конкретная шкала, привязанная к каналу доступа.

* Секреты не передаются модели даже локально — замените реальные значения на заглушки. Таблица — стартовая точка; конкретный проект может требовать более строгих правил в зависимости от договора с заказчиком и отраслевых требований.

Классификация данных до отправки

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

Рабочая схема: каждый документ получает метку — публичный, внутренний, конфиденциальный, клиентский, секреты доступа. Метка проставляется автором, хранится в свойствах файла или системе классификации (Microsoft Purview, Varonis, открытые альтернативы) и читается агентом или прокси-слоем перед отправкой. Документ с меткой «конфиденциальный» не уходит за пределы локального контура, материал с меткой «секреты доступа» не передаётся модели вовсе.

Минимальный вариант для небольшой команды — соглашение о префиксах в именах файлов и каталогах. Главное — единые правила для всех.

Модель угроз: откуда приходят утечки

Предупреждение «не загружайте лишнего» покрывает лишь один вектор — прямую передачу данных в запросе. Реальная модель угроз значительно шире. Классификация OWASP Top 10 for LLM Applications выделяет среди ключевых рисков раскрытие чувствительной информации и избыточную автономность агента.

Внедрение вредоносных инструкций через документы: злоумышленник размещает скрытую команду внутри PDF или веб-страницы, агент обрабатывает документ и передаёт конфиденциальные данные наружу. Утечка через систему дополненной генерации (RAG): документы разных клиентов попадают в общий индекс, и модель отвечает на вопрос одного пользователя фрагментами из документов другого. Утечка через инфраструктуру: журналы прокси-сервера, телеметрия, системы мониторинга фиксируют содержимое запросов в открытом виде. Избыточные права подключённых сервисов: агент с доступом к хранилищу документов или почте извлекает и пересылает больше, чем предполагалось.

Рамочный документ NIST AI RMF и профиль NIST AI 600-1 помогают структурировать управление рисками генеративного ИИ на уровне организации. Опираться на подобные источники при проектировании защиты полезнее, чем изобретать классификацию с нуля.

Слой безопасности агентской системы

Агенты — автономные модули, которые взаимодействуют с языковой моделью и принимают промежуточные решения без участия человека на каждом шаге. Без явного слоя безопасности агент может отправить конфиденциальный фрагмент во внешний сервис или сформировать запрос с данными, не предназначенными для передачи. Программа выполняет инструкции буквально, и если инструкции не содержат запретов, границы соблюдаться не будут.

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

Кстати, по теме сборки агентских систем под наступательную безопасность 21 мая 2026 года в 19:00 МСК проходит открытый вебинар «Как собрать своих AI-агентов для пентеста и bug bounty». Сергей «Похек» Зыбнев, тимлид пентестеров в «Бастион», разбирает рабочую схему применения AI в offensive security: от анализа и гипотез до валидации и отчёта — с акцентом на ограничения, контроль ToS/Scope и реальные ошибки из практики.

Фильтрация ввода и вывода

Фильтрация ввода проверяет данные перед отправкой в модель: обнаруживает и маскирует персональные данные, ключи доступа, пароли, внутренние адреса. Из готовых инструментов — Microsoft Presidio для распознавания и маскирования персональных данных, detect-secrets от Yelp для поиска секретов в коде, TruffleHog для обнаружения ключей и токенов. Ни один фильтр не гарантирует стопроцентной точности, поэтому фильтрация работает как один из слоёв защиты, а не единственный барьер.

Фильтрация вывода перехватывает ответ модели до того, как результат попадёт к пользователю. Модель способна воспроизвести фрагменты обучающей выборки, сгенерировать код с жёстко заданными учётными данными или раскрыть внутреннюю архитектуру системы. Типичная ошибка — настроить фильтрацию ввода и забыть про вывод, воспринимая результат генерации как «уже безопасный».

Ведите реестр паттернов и обновляйте его регулярно: новые форматы токенов, нестандартные структуры адресов, специфичные для проекта идентификаторы — добавляйте в правила по мере появления.

Ограничения действий и прокси-слой

Принцип минимальных привилегий применим к агентам в полной мере. Агент получает только те разрешения, которые необходимы для конкретной задачи. Доступ к сети, файловой системе, хранилищам и каналам коммуникации ограничивается белыми списками. Любое действие за пределами списка блокируется, попытка фиксируется в журнале.

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

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

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

Изолированная среда (песочница) — отдельный контур, в котором модель работает без возможности передать информацию наружу. Открытые модели — Llama, Mistral, Qwen — запускаются на собственном оборудовании через Ollama, vLLM или llama.cpp. Производительность уступает крупным облачным моделям; для задач с длинным контекстом или сложными рассуждениями разрыв может быть существенным. Для классификации, обобщения текстов и генерации шаблонов локальных мощностей обычно хватает.

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

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

Регламент и организационные меры

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

Минимальный безопасный контур для команды: корпоративный аккаунт выбранного сервиса, запрет на личные чат-боты для рабочих задач, DLP-система или фильтр перед отправкой, маскирование секретов, этап согласования, журналирование и список разрешённых моделей. Десяток страниц с конкретными примерами эффективнее пятидесятистраничной политики, которую никто не откроет. Раз в квартал перепроверяйте настройки и работоспособность фильтров — инструменты и условия соглашений пересматриваются регулярно.

Типичные ошибки и ответственность

«У нас корпоративная подписка, значит, всё безопасно» — подписка снижает часть рисков, но не решает вопрос юрисдикции, не заменяет фильтрацию и не освобождает от проверки результатов. «Мы заменили имена на вымышленные, значит, данные обезличены» — комбинация должности, отдела, даты рождения и города часто позволяет идентифицировать человека без имени. «Модель не запоминает» — даже без сохранения истории данные проходят через серверы провайдера и могут логироваться во временных буферах.

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

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

Вместо заключения

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

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

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