Как компании защищают модели ИИ от кражи интеллектуальной собственности

Вы разработали модель, которая работает лучше, чем у конкурентов. Она учитывает специфику вашего рынка, оптимизирует затраты на логистику, предсказывает отток клиентов с точностью 92% — и это ваше главное конкурентное преимущество. Но что, если кто-то скопирует её за пару часов, просто скачав API-ответы или вытащив веса через атаку на инференс? Это не фантастика — это реальность, с которой сталкиваются компании, запускающие собственные модели. И если вы не защищаете их, вы просто дарите конкурентам то, что стоило миллионов.

Почему кража моделей — это не просто «утекла идея»

Модель ИИ — это не код, как в обычном ПО. Это набор чисел: миллиарды весов, которые накопили знания за месяцы обучения на ваших данных. Скопировать её можно, даже не имея доступа к исходному коду. Достаточно отправить сотни запросов к API, проанализировать ответы, и с помощью методов вроде model extraction или membership inference восстановить структуру и параметры. Уже в 2023 году группа исследователей из Беркли восстановила модель GPT-2 с точностью 98% всего по 10 000 запросов. Представьте, что ваша модель — это рецепт супа, который вы варите в закрытой кухне. А конкурент просто пробует блюдо, записывает вкус, и через пару дней делает свой — почти такой же.

Потеря модели — это не только потеря технологии. Это потеря:

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

Как именно крадут модели

Вот три основных способа, которыми пользуются злоумышленники — и почему обычные меры безопасности не помогают.

1. API-экстракция. Злоумышленник отправляет тысячи запросов к вашему API, записывает ответы и использует их для обучения «теневой» модели. Даже если вы ограничиваете частоту запросов, можно обойти это с помощью распределённых прокси или ботов.
2. Сторонний доступ через контейнеры или облако. Если модель развернута в Docker-контейнере без шифрования весов, её можно извлечь через уязвимость в системе или через внутреннюю утечку. Был случай, когда модель из компании по анализу медицинских снимков была скопирована через доступ к S3-бакету, куда разработчик случайно загрузил файл с весами.
3. Атака на инференс через дифференциальный анализ. Злоумышленник отправляет похожие входные данные и смотрит, как меняются ответы. По этим изменениям можно реконструировать архитектуру и даже частично восстановить обучающие данные.

Важно: вы не защищаете код. Вы защищаете знания, которые в него вложены. И это другая задача.

Что реально работает: четыре уровня защиты

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

1. Шифрование весов и ограничение доступа к ним

Веса модели — это её «мозг». Если они лежат в открытом виде в файле .pt или .h5 — это как оставить ключ от сейфа на двери. Лучшая практика: шифровать веса с помощью homomorphic encryption или secure enclaves (Intel SGX, AMD SEV). Это не значит, что вы шифруете всё. Достаточно шифровать только те части, которые хранятся вне процесса инференса — например, файлы с весами в облаке или резервных копиях.

Компания, которая делает прогнозы спроса для ритейла, шифрует веса модели с помощью AES-256 и хранит ключи в отдельном сервисе — HSM (Hardware Security Module). Даже если злоумышленник получит доступ к серверу, он не сможет прочитать веса без ключа, который физически находится в другом месте.

2. Ограничение доступа к API — не просто лимиты

Ограничение на 100 запросов в минуту — это начало, но не решение. Настоящая защита — это аномалия-детекшн на уровне поведения.

Вот как это работает на практике:

• Вы анализируете шаблоны запросов: если один IP отправляет 5000 запросов с почти одинаковыми входами — это подозрительно.
• Вы добавляете «шум» в ответы: незначительные, случайные отклонения в предсказаниях, которые не влияют на бизнес-логику, но мешают обучению теневой модели.
• Вы требуете уникальные токены для каждого клиента — и отслеживаете, кто и сколько запрашивает. Если токен используется с разных IP — блокируете.

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

3. Динамическая архитектура и фрагментация

Если модель — это единый файл, её легко скопировать. А если она разбита на 10 частей, каждая из которых работает на отдельном сервере, и только приложение собирает результаты — скопировать её становится почти невозможно.

Пример: компания по анализу кредитных рисков разбила свою модель на три модуля:

• Модуль A — обрабатывает доходы (работает на сервере в Европе);
• Модуль B — анализирует историю платежей (на сервере в США);
• Модуль C — финальное решение (на локальном сервере клиента).

Никто не имеет полного доступа к модели. Даже если кто-то взломает один сервер — он получит только фрагмент. Для восстановления нужно одновременно скомпрометировать три системы. Это снижает риск в десятки раз.

4. Аудит и мониторинг — не «для отчетности»

Вы не можете защитить то, что не видите. Настоящие компании используют системы, которые:

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

Один из сервисов по анализу поведения клиентов внедрил систему, которая каждый день генерирует «отчёт по подозрительным запросам» — и отправляет его в Slack не только разработчикам, но и CEO. Через три месяца они обнаружили, что один из партнёров, которому давали доступ к API, использовал его для обучения конкурентной модели. Было быстро отключено — и подан иск.

Сравнение подходов: что подходит когда

Не все компании могут позволить себе HSM и фрагментацию. Вот что реально можно применить в зависимости от масштаба и рисков.

Уровень защиты	Сложность внедрения	Стоимость (ориентир)	Эффективность против кражи	Когда использовать
Ограничение API + лимиты	Низкая	0–5 тыс. $	Низкая	Тестовая версия, MVP, внутренние инструменты
Шифрование весов + HSM	Средняя	10–50 тыс. $	Высокая	Коммерческая модель, работа с чувствительными данными
Фрагментация архитектуры	Высокая	50–200 тыс. $	Очень высокая	Ключевая модель, высокая конкуренция, интеллектуальная собственность — основной актив
Динамические ответы + шум	Средняя	5–30 тыс. $	Средняя–высокая	API-сервисы, где точность не критична до 2–3%
Аудит запросов + поведенческий анализ	Средняя	15–60 тыс. $	Высокая	Любая модель с публичным API

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

Частые ошибки — и как их избежать

Вот что видят те, кто уже прошёл через кражу моделей.

• «Мы зашифровали код — всё в порядке». Код — это не модель. Модель — это веса. Если вы зашифровали только скрипт запуска, а веса лежат открыто — вы ничего не сделали.
• «Мы ограничили 100 запросов в минуту». Это не защита. Это просто «не дай бог, чтобы слишком много». Злоумышленник может использовать 100 прокси — и обойти это за час.
• «Мы не публикуем модель — она у нас на сервере». Если у вас есть API — модель уже доступна. Достаточно 10 000 запросов.
• «Мы используем облако — там всё защищено». AWS, Azure, GCP защищают инфраструктуру. Они не защищают ваши веса от внутреннего сотрудника, который загрузил их на GitHub по ошибке.
• «Мы не видим угрозы — у нас мало клиентов». Кража модели не зависит от размера компании. Даже небольшая модель с уникальной точностью может быть скопирована и продана как «решение для малого бизнеса».

Что выбрать — в зависимости от вашей ситуации

Вот как принимать решение, если вы не Google и не Tesla.

Ситуация 1: Вы — стартап с MVP, модель обучена на 5000 записях

Делайте: ограничение API (100 запросов/мин), базовый аудит, шифрование весов в хранилище. Не тратьте деньги на фрагментацию. Ваша цель — не защита от кражи, а защита от утечки. Если кто-то скопирует модель — вы уже успеете выйти на рынок, и ваша скорость будет важнее.

Ситуация 2: Вы — средняя компания, модель используется клиентами, вы получаете 500 тыс. $ в год

Делайте: фрагментация (минимум 2 части), аудит запросов, шум в ответах, HSM для хранения ключей. Это ваша основная защита. Если модель украдена — вы потеряете клиентов и репутацию. Инвестируйте в это как в страховку.

Ситуация 3: Вы — крупная компания, модель — ваш ключевой продукт (например, прогнозирование цен на сырьё)

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

Ситуация 4: Вы даёте доступ к модели партнёрам

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

Как лучше сделать — пошаговый план

Вот что делать прямо сейчас, если вы хотите начать защищать модель — без паники и переплат.

1. Найдите файл с весами модели (обычно .pt, .h5, .onnx). Если он лежит в открытом доступе — срочно закройте его.
2. Зашифруйте его с помощью AES-256. Храните ключи в отдельном сервисе — не в коде, не в переменных окружения. Используйте AWS KMS, HashiCorp Vault или аналоги.
3. Включите аудит запросов к API: записывайте IP, токен, время, размер запроса. Делайте это хотя бы 30 дней — посмотрите, есть ли подозрительные паттерны.
4. Добавьте ограничение: не более 50 запросов в минуту с одного IP. Используйте Cloudflare или аналоги.
5. Если у вас API — добавьте небольшой шум в ответы: ±0,5% к предсказанию. Это не повлияет на бизнес-решения, но сделает экстракцию почти невозможной.
6. Проверьте, есть ли у вас доступ к облаку или серверу у сотрудников. Удалите все открытые репозитории с весами — даже если они «для теста».
7. Создайте план на случай утечки: кто отключит API, кто уведомит клиентов, кто проверит логи. Не ждите, пока случится — подготовьтесь.

Итог: что делать прямо сейчас

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

Не ждите, пока кто-то скопирует её. Начните с трёх шагов:

• Зашифруйте веса и храните ключи отдельно;
• Включите аудит запросов — посмотрите, кто и как использует ваш API;
• Добавьте шум в ответы — даже 1% снизит риск экстракции в 10 раз.

Это не требует миллионов. Это требует внимания. Если вы сделаете это — вы не только защитите актив. Вы дадите команде уверенность: их работа не будет украдена. И это стоит больше, чем любая технология.

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