Защита данных при использовании ИИ: контуры, 152-ФЗ и проверка утечек

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

Что именно утекает: модель угроз без абстракций

«Данные утекают в нейросеть» — слишком общая формула, по ней невозможно строить защиту. Полезнее перечислить конкретные каналы. В терминах OWASP Top 10 для LLM-приложений это прежде всего LLM02 — раскрытие чувствительной информации, но каналов больше:

• Промпты и вставленные документы. Всё, что сотрудник вставил в чат внешнего сервиса, ушло на чужие серверы и живёт там по правилам провайдера: история, резервные копии, иногда — обучение будущих моделей.
• Файлы в базе знаний. Загрузили регламенты в облачный RAG-сервис — отдали наружу весь корпус документов разом, включая версии, которые давно отменили.
• Логи и телеметрия. У провайдера остаются журналы запросов; у самих инструментов — в том числе self-hosted — бывает телеметрия, включённая по умолчанию. Её видно только по сетевому трафику.
• Секреты в промптах. Ключи API, пароли и реквизиты, вставленные «для контекста», — классика инцидентов. Модель может воспроизвести их в другом ответе.
• Персональные данные. Имена сотрудников и клиентов в расшифровках встреч и переписке — отдельная категория: к ней добавляются требования 152-ФЗ о локализации. Разбор правовой части — в отдельной статье.

Важное следствие: часть каналов закрывается договором и настройками, а часть — только архитектурой. Какая именно часть — зависит от контура размещения.

Шаг ноль: узнайте, что происходит прямо сейчас

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

Инвентаризация по DNS. Включите на корпоративном резолвере журнал запросов и посмотрите, к каким доменам ИИ-сервисов ходят рабочие станции: публичные чаты, переводчики, генераторы презентаций, расшифровщики встреч. Почти всегда список оказывается длиннее, чем ожидает ИБ, — и это трафик, который уже идёт, независимо от того, «внедрили» вы ИИ или нет.

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

Карта задач. Список того, что сотрудники реально делают с ИИ, с уровнем данных для каждой задачи. Обычно выясняется, что 70–80% задач — внутренний уровень, которому достаточно локальной модели, и только редкий сложный анализ просит флагманскую внешнюю.

Три контура: внешний, гибридный, внутренний

Все схемы работы с нейросетями сводятся к трём вариантам. Разница между ними — в одном вопросе: у кого root-доступ к машине с моделью и куда смотрит её сеть.

Полностью внешний контур

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

Полностью внутренний контур

Модель, платформа и данные живут на инфраструктуре, где root у вас: серверная компании, ЦОД по колокейшену — или арендованный выделенный сервер. Последнее стоит проговорить отдельно, потому что его часто ошибочно записывают в «облако»: bare-metal сервер с GPU, на котором вы сами ставите ОС, шифруете диски, управляете доступом и закрываете сеть, — это ваш контур. Провайдер владеет железом и электричеством; данными, ключами и правилами сети управляете вы. Принципиальная разница с SaaS: там вы арендуете сервис и данные обрабатывает чужой софт, здесь — арендуете железо и всё, что выше, ваше. Для компаний без своей серверной это самый быстрый путь к внутреннему контуру: современные открытые модели уровня Qwen и DeepSeek уверенно работают на одной-двух арендованных GPU-картах.

Гибридный контур

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

Практика: как убедиться, что данные не утекают

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

Закройте исходящие по умолчанию

Базовый принцип — default-deny egress: серверу с моделью исходящие соединения нужны в исключительных случаях, поэтому по умолчанию они закрыты, а открыто только перечисленное. В nftables это выглядит так:

table inet egress {
  chain output {
    type filter hook output priority 0; policy drop;
    ct state established,related accept
    oif lo accept
    ip daddr 10.0.0.0/8 accept              # свой контур
    udp dport 123 ip daddr <NTP-сервер> accept
    tcp dport 443 ip daddr <IP шлюза обновлений> accept
    log prefix "egress-drop " counter drop  # всё остальное — в журнал
  }
}

Строка log … counter drop — самая полезная: каждая заблокированная попытка выйти наружу попадает в журнал со счётчиком. Если на сервере с моделью счётчик растёт — что-то пытается «позвонить домой», и вы видите куда.

Пустите разрешённый трафик через прокси со списком

Тому, чему интернет всё-таки нужен — шлюзу к внешней модели, загрузке обновлений, — открывайте выход не «в интернет», а через прокси с явным списком доменов: Squid или nginx в режиме forward-proxy. Практический порядок такой: первую неделю прокси работает в режиме наблюдения и пишет в лог всё, куда ходят сервисы; по логу составляется список реально нужных доменов; затем список включается, и каждая попытка выйти мимо него оседает в журнале как TCP_DENIED. Это одновременно и защита, и диагностика: неожиданный домен в логе — это либо телеметрия инструмента, либо зависимость, о которой вы не знали.

Мониторинг на границе

Файрвол отвечает «пустить или нет», мониторинг — «что вообще происходило». На границе контура достаточно двух источников: журналы дропов с самого файрвола и поток NetFlow/IPFIX c пограничного маршрутизатора — по нему видно объёмы, направления и время каждого соединения. Для более глубокого разбора существуют анализаторы вроде Zeek, которые раскладывают трафик по протоколам и доменам, но для контура с default-deny это чаще избыточно: там сама редкость событий делает каждое заметным. Настройте одно оповещение — «появился исходящий трафик к неизвестному назначению» — и этого хватит на большинство сценариев.

Смотрите на DNS

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

Мелочи, о которых забывают

• Метаданные облака. Если контур арендован у провайдера виртуализации, закройте доступ к служебному адресу 169.254.169.254 — через него получают учётные данные инстанса.
• Телеметрия инструментов. У открытых ML-инструментов встречается телеметрия, включённая по умолчанию. Флаги отключения — хорошо, но проверка по трафику надёжнее: файрволу безразлично, что написано в настройках.
• Обновления моделей и пакетов. Загружайте веса и пакеты через отдельный шаг с временным правилом или через внутреннее зеркало — постоянно открытый выход «для обновлений» быстро превращается в выход для всего.
• Канал к внешней модели. В гибриде наружу смотрит одна машина — шлюз. Рабочие места сотрудников выхода к API моделей не имеют вовсе: меньше точек контроля, проще журнал.

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

Типичные ошибки, которые сводят защиту на нет

• «Откроем egress на время отладки». Временное правило переживает отладку, релиз и смену администратора. Правильный вариант — отдельное правило с комментарием и датой, и еженедельная проверка списка исключений.
• Локальная модель + облачная векторизация. Компания ставит модель в контур, а базу знаний собирает облачным сервисом эмбеддингов — и весь корпус документов уезжает наружу на этапе индексации. Векторизация обязана жить в том же контуре, что и документы.
• Один API-ключ на всех. Общий ключ к внешней модели, вшитый в десять сервисов, означает, что журнал не отвечает на вопрос «кто отправил». Ключи — по сервисам, доступ — через шлюз.
• Бэкапы наружу в открытом виде. Контур закрыт, а резервные копии с историей чатов и документами уходят на внешнее S3-хранилище без шифрования на своей стороне. Бэкап — тот же канал утечки, шифруйте до отправки своими ключами.
• Права «на всякий случай». База знаний, видимая всем сотрудникам, превращает ИИ-поиск в инструмент обхода файловых прав: человек спрашивает чат о том, к чему у него нет доступа в папках. Права на коллекции должны повторять права на исходные документы.

Персональные данные и 152-ФЗ: что меняется от контура

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

• Внешний зарубежный сервис. Отправка персональных данных в него — трансграничная передача с усиленным порядком уведомления Роскомнадзора, при этом проверить обработку на той стороне нельзя. Для задач с персональными данными этот контур практически закрыт.
• Российский облачный сервис. Требование локализации соблюдается, но провайдер становится лицом, обрабатывающим данные по вашему поручению: нужен договор с обязанностями по защите, а ответственность перед субъектами всё равно остаётся на вас как на операторе.
• Внутренний контур. Вы единственный обработчик, третьи лица из схемы исчезают. Остаются ваши собственные обязанности оператора: модель угроз, уровень защищённости ИСПДн и меры по требованиям ФСТЭК, политики и согласия. Зато все они в вашей власти и проверяются вашим же аудитом.

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

Анонимайзер: что он даёт и чего не гарантирует

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

Чек-лист для службы безопасности перед пилотом

• По каждому типу задач определено: какие данные участвуют и в какой контур им можно.
• У кого root на машине с моделью и платформой; если сервер арендован — включено ли шифрование дисков и чьи ключи.
• Исходящие соединения контура закрыты по умолчанию; список разрешённых назначений умещается на полэкрана.
• Журналы: попытки выхода мимо списка, обращения к моделям, доступ к документам. Что фиксируется, где хранится, кто читает.
• Внешние модели доступны только через шлюз; на нём — анонимайзер и перечень разрешённых типов задач.
• Доступ к базе знаний разделён: закрытые коллекции видны только нужным командам.
• Секреты и учётные данные в промптах запрещены регламентом, а в идеале — фильтром на шлюзе.
• Проведён «тихий прогон»: неделя типовой работы на стенде с закрытым egress и просмотром журналов.

Вопросы, которые задают чаще всего

Арендованный выделенный сервер — это внутренний контур или облако?

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

Нужно ли вскрывать TLS-трафик, чтобы контролировать утечки?

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

Провайдер обещает «не обучаться на моих данных». Этого достаточно?

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

С чего начать, если своей серверной нет?

С аренды выделенного GPU-сервера у российского провайдера: одна-две карты достаточны для локальной модели на команду. Дальше — платформа в этот контур, закрытие egress, «тихий прогон» и подключение внешних моделей через шлюз, если они вообще нужны.

Чем гибрид лучше внешнего контура с анонимайзером?

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

Как это связано со 152-ФЗ?

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

Вместо вывода

Защита данных при использовании ИИ — это в первую очередь выбор контура, а уже потом настройки и регламенты. Внешний контур контролируется договором, гибридный и внутренний — файрволом и журналами, то есть проверяемо. Арендованный выделенный сервер делает внутренний контур доступным даже без своей серверной. А критерий готовности простой: вы можете показать аудитору журнал, в котором за неделю работы нет ни одной незапланированной попытки выйти наружу. Как это устроено в Aiklava — на страницах о безопасности и о поставке on-premise.