Доказательство безопасности локальных LLM для compliance: чек-лист, который спасёт от аудиторов

Когда ваш локальный ИИ становится проблемой безопасности, а не решением

Вы развернули локальную LLM. Вроде бы всё работает. Документы анализирует, промпты обрабатывает, данные никуда не утекают. Но вот приходят аудиторы с ФСТЭК 117 или GDPR compliance checklist - и начинаются вопросы.

"Докажите, что модель не содержит вредоносного кода". "Покажите журналы всех запросов". "Обоснуйте, почему модель не может выполнить prompt injection". "Предоставьте результаты penetration testing".

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

Что на самом деле проверяют аудиторы (и почему они не верят на слово)

Аудиторы compliance - существа недоверчивые. Они работают по принципу "не верь, проверь". И их проверки строятся вокруг трёх столпов:

• Доказательство изоляции - не просто "у нас нет интернета", а мониторинг всей исходящей связи
• Верификация модели - откуда взялись веса, кто их проверил, что внутри
• Контроль доступа и логирование - кто, когда и что спрашивал у модели

Если в вашей компании уже есть опыт с комплаенсом в РФ, вы знаете, о чём я. Если нет - готовьтесь к сюрпризам.

1 Чек-лист доказательства air-gap: больше, чем просто отключение кабеля

Air-gap - это не состояние, а процесс. И вот как его доказать:

2 Верификация модели: откуда взялся этот файл на 40 ГБ?

Самый неудобный вопрос: "А вы уверены, что в этих весах нет backdoor?". Особенно если качали модель с Hugging Face в 3 часа ночи.

Процесс верификации:

1. Проверка хэшей - сравнивайте SHA256 с официальными источниками. Не доверяйте скачанным файлам с торрентов.
2. Анализ архитектуры - используйте инструменты вроде Netron для проверки графа вычислений.
3. Статический анализ кода - если модель имеет кастомные операции или плагины.
4. Сертификаты подписи - проверяйте цифровые подписи от разработчиков (если есть).

Для моделей с поддержкой tool calling проверка усложняется - нужно анализировать не только модель, но и инструменты, к которым она получает доступ.

# Пример проверки хэшей модели
sha256sum llama-3.2-90b-instruct.Q4_K_M.gguf
# Сравните с официальным хэшем на сайте Meta

# Анализ исходящих вызовов при загрузке модели
strace -f -e trace=network python3 load_model.py 2>&1 | grep -i "connect\|send\|recv"

# Проверка digital signature (если доступна)
gpg --verify llama-3.2-90b-instruct.Q4_K_M.gguf.sig

Инструменты аудита, которые реально работают в 2026

Ручные проверки - это хорошо. Но аудиторы хотят автоматизации. Вот что я использую:

LLM Security Scanner

Набор скриптов, который проверяет:

• Уязвимости в зависимостях (особенно в трансформерных библиотеках)
• Конфигурацию безопасности inference сервера
• Настройки CORS и аутентификации
• Возможности prompt injection через тестовый набор промптов

Network Traffic Baseline Generator

Создаёт эталонный профиль сетевой активности модели в «чистом» состоянии. Любое отклонение - повод для расследования.

# Пример создания baseline
from scapy.all import *
import json

capture = sniff(timeout=300, filter="host 192.168.1.100")
baseline = {
    "allowed_ports": [],
    "dns_queries": [],
    "packet_sizes": {},
    "protocols": {}
}

for pkt in capture:
    if IP in pkt:
        # Анализируем только трафик от LLM сервера
        if pkt[IP].src == "192.168.1.100":
            baseline["allowed_ports"].append(pkt.dport)
            # Сохраняем статистику

with open("llm_baseline.json", "w") as f:
    json.dump(baseline, f, indent=2)

Model Integrity Verifier

Проверяет целостность модели на протяжении всего жизненного цикла:

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

Логирование: что нужно записывать, чтобы доказать compliance

Без логов вы слепы. Но какие логи нужны аудиторам?

Особое внимание - промптам с персональными данными. По GDPR и 152-ФЗ это отдельная история. Нужно либо анонимизировать перед логированием, либо шифровать.

3 Prompt injection защита: как доказать, что она работает

"Покажите, как вы тестируете защиту от prompt injection" - любимый вопрос аудиторов.

Ответ должен включать:

1. Регулярное тестирование - минимум раз в квартал прогоняйте тестовый набор
2. Мониторинг в реальном времени - детектор аномальных промптов
3. Защитные механизмы - как в StruQ и SecAlign
4. Документацию инцидентов - если были атаки, как их обнаружили и устранили

Мой подход: комбинация статического анализа промптов и динамического мониторинга ответов. Если промпт содержит подозрительные конструкции ("ignore previous", "system prompt", "output in format"), он отправляется на дополнительную проверку.

Пентест локальной LLM: что проверяют хакеры (и аудиторы)

Закажите внешний пентест. Серьёзно. Лучше заплатить этичным хакерам, чем получить штраф.

Хороший пентест должен включать:

• Black-box тестирование - без доступа к коду, только API
• White-box тестирование - с доступом к серверу и конфигурациям
• Социальную инженерию - проверка сотрудников на уязвимости
• Физический доступ - можно ли подключить флешку или ноутбук

После пентеста вы получаете отчёт с уязвимостями и рекомендациями. Этот документ - золото для compliance. Он показывает, что вы серьёзно относитесь к безопасности.

Документация: то, что читают аудиторы вместо кода

Код работает? Отлично. Теперь докажите это на бумаге.

Минимальный набор документов:

1. Политика безопасности LLM - кто, что и как может использовать
2. Руководство по развёртыванию - пошаговая инструкция с проверками
3. План реагирования на инциденты - что делать при обнаружении уязвимости
4. Отчёты о тестировании - результаты регулярных проверок
5. Журнал изменений - кто и когда менял конфигурацию

Эти документы должны быть живыми. Не создавайте их один раз и не забывайте. Аудиторы проверяют даты, версии и соответствие реальному состоянию.

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

Из реальной практики:

• "У нас air-gap, но модель качается через VPN при запуске" - это не air-gap, это хакерская мечта
• "Логи храним на том же сервере" - что будет, если сервер взломают? Логи уничтожат первыми
• "Все промпты анонимные" - но в логах есть IP-адреса, которые легко деанонимизировать
• "Мы используем только open-source модели" - а кто проверял код на backdoor? Вы?
• "Защита от injection не нужна, у нас доверенные пользователи" - самый частый источник утечек

Если вы делаете что-то из этого списка - исправляйте. Сейчас.

Самый важный совет: начните с малого, но начните сейчас

Не пытайтесь сразу построить идеальную систему. Compliance - это процесс, а не состояние.

Начните с:

1. Включения логирования ВСЕХ запросов к LLM
2. Настройки мониторинга исходящего трафика
3. Создания политики безопасности (хотя бы черновика)
4. Регулярного тестирования на prompt injection

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

И помните: безопасность локальных LLM - это не про паранойю. Это про управление рисками. Риск получить штраф в 5 миллионов рублей - вполне реальный риск. Управлять им дешевле, чем платить.

P.S. Если думаете "у нас маленькая компания, нас не проверят" - посмотрите статистику проверок Роскомнадзора за 2025 год. Проверяют всех. Особенно тех, кто думает, что их не проверят.