Что произошло
5 октября 2026 года компания Anthropic опубликовала заявление, в котором обвинила ряд китайских технологических компаний, включая DeepSeek, в проведении масштабной кампании по незаконному извлечению знаний из её модели Claude. По данным Anthropic, речь идёт о целенаправленной деятельности, которую компания классифицирует как «illicit distillation» — незаконную дистилляцию. Суть обвинения сводится к тому, что ответчики использовали API Claude для генерации огромного массива синтетических данных, которые затем стали основой для обучения собственных конкурирующих моделей.
В заявлении, на которое ссылается The Verge, приводятся конкретные цифры. Так, в июле 2026 года активность, связанная с DeepSeek, составила более 12 млн обменов с API Claude за 14 дней. Совокупная активность пяти китайских компаний, включая DeepSeek, Alibaba, Moonshot AI, Xiaomi и Zhipu, по оценке Anthropic, достигла почти 200 млн обменов в период с конца 2024 по август 2026 года. Американское агентство по кибербезопасности и безопасности инфраструктуры (CISA) подтвердило, что рассматривает эту деятельность как организованную кампанию как минимум с конца 2024 года.
Этот инцидент происходит на фоне ужесточения регуляторного внимания к ИИ. 5 октября 2026 года совет городского совета Нью-Йорка провёл слушания по безопасности ИИ, на которые были вызваны представители OpenAI, Google, Anthropic и Meta. События вокруг DeepSeek показывают, что технологическая конфронтация переходит из плоскости конкуренции в плоскость промышленного шпионажа и правовых споров, где методы защиты интеллектуальной собственности становятся таким же стратегическим активом, как и сами модели.
Важно отметить, что на текущий момент опубликованная информация отражает исключительно позицию Anthropic и американских госорганов. Независимого судебного разбирательства, подтвердившего факты нарушения, или подробного публичного ответа от DeepSeek в доступных источниках нет. Поэтому корректнее говорить о заявленной кампании по извлечению модельных возможностей, а не о доказанном в суде факте кражи интеллектуальной собственности.
Как это устроено
Механика незаконной дистилляции
Дистилляция моделей — это легальный метод, при котором компактная «студенческая» модель обучается имитировать ответы более мощной «учительской» модели. Однако сценарий, описанный Anthropic, отличается по масштабу и намерениям. Вместо обычного использования API для решения прикладных задач, злоумышленники создают инфраструктуру для массового, автоматизированного опроса модели. Цель — не получить ответ на конкретный запрос, а собрать миллионы пар «вход-выход», раскрывающих логику рассуждений, стиль кода и структуру ответов «учителя». Эти синтетические данные затем используются для дообучения собственной модели, что позволяет значительно сократить затраты и время на её разработку.
Экономика и мотивация
Экономический смысл такой операции очевиден: создание конкурентоспособной фундаментальной модели с нуля требует сотен миллионов долларов и доступа к тысячам передовых GPU. Использование API для дистилляции — это обходной путь. Стоимость API-запросов, даже в масштабе сотен миллионов, может быть на порядок ниже, чем расходы на самостоятельный сбор датасетов, разметку и вычислительные ресурсы для обучения. Для компаний, стремящихся сократить отставание от лидеров рынка, это становится заманчивым, хотя и рискованным, методом быстрого получения конкурентных преимуществ.
Технические методы выявления
Anthropic и CISA описывают несколько подходов к обнаружению подобных атак. Ключевой метод — поведенческая аналитика. Системы мониторинга анализируют паттерны API-трафика: аномально высокую частоту запросов с одного IP или из подсети, использование множества аккаунтов с похожим поведением, выход на лимиты запросов сразу после регистрации. CISA также рекомендует обращать внимание на промышленные шаблоны нагрузки, необычное соотношение между типом подписки и фактическим использованием, а также на запросы, целенаправленно «прощупывающие» слабые или сильные стороны модели.
Защитные механизмы и их ограничения
В ответ на угрозы Anthropic заявила о внедрении многоуровневой системы защиты. Она включает классификаторы подозрительных запросов, усиленную верификацию аккаунтов, адаптивное ограничение скорости (rate limiting) и поведенческое профилирование. Более продвинутые методы предполагают изменение ответов для подозрительных клиентов — добавление шума, небольшую деградацию качества или введение водяных знаков (watermarking). Однако исследования показывают, что универсальной защиты нет. Водяные знаки могут удаляться при перефразировании, а добавление шума снижает качество сервиса для добросовестных пользователей, что создает баланс между безопасностью и удобством.
Как это выглядит на практике
Сценарий первый: российская финтех-компания интегрировала зарубежный языковой модельный API для своего чат-бота поддержки. После инцидента с Anthropic провайдер API ужесточает политику KYC (знай своего клиента) и вводит дополнительные проверки для компаний из определенных юрисдикций. В результате доступ к API для российской компании внезапно ограничивается. Процесс поддержки клиентов замедляется, а срочный поиск и интеграция альтернативного решения, например, отечественной модели, требует незапланированных расходов и времени на доработку.
Сценарий второй: российский стартап разработал узкоспециализированную модель для анализа юридических документов и предоставляет доступ к ней через B2B API. Конкурент, не обладающий такой экспертизой, использует сеть прокси и регистраций через подставные компании, чтобы массово запросить модель и собрать датасет для обучения своего аналога. Через несколько месяцев на рынке появляется более дешёвый продукт, уступающий в качестве на 10–15%, но подрывающий бизнес-модель оригинального стартапа, который инвестировал годы в R&D.
Сценарий третий: крупная промышленная корпорация использует внешнюю модель для оптимизации логистических цепочек. Новые правила комплаенса, принятые провайдером под влиянием регуляторов, требуют, чтобы любые данные, связанные с критической инфраструктурой, не обрабатывались моделью без дополнительного аудита. Корпорация оказывается перед выбором: либо остановить эффективный проект, либо передать конфиденциальные данные о своих маршрутах и партнёрах третьей стороне, что нарушает внутреннюю политику безопасности.
Что это значит для российской компании
Для российского бизнеса инцидент — это сигнал о трёх ключевых угрозах. Первая — риск внезапной деградации или прекращения доступа к зарубежным ИИ-моделям. Причины могут быть разными: от геополитической санкции до внутренней политики комплаенса провайдера, который решит ограничить работу с клиентами из «рискованных» юрисдикций. Вторая угроза — прямая экономическая конкуренция со стороны компаний, использующих дистилляцию для быстрого создания аналогов, что обесценивает инвестиции в собственные R&D. Третья — правовые и репутаци риски при передаче данных за рубеж, особенно в контексте российского законодательства о персональных данных (152-ФЗ) и требований к локализации критической инфраструктуры.
Текущая ситуация с дефицитом вычислительных мощностей в России, о которой публично заявляли представители «Сбера» и «Яндекса», усугубляет проблему. Зависимость от иностранных API становится вынужденной мерой, но она создаёт технологическую уязвимость. Стратегия импортозамещения в области ИИ приобретает не только идеологическое, но и прагматическое значение: построение суверенного контура снижает операционные риски и защищает интеллектуальные активы.
| Стратегия | Преимущества | Риски и издержки | Подходящие задачи |
|---|---|---|---|
| Полная зависимость от внешнего API | Низкие первоначальные затраты, быстрый доступ к передовым моделям | Риск блокировки, передача данных за рубеж, зависимость от ценовой политики поставщика | Некритичные задачи, генерация идей, проекты без чувствительных данных |
| Гибридная модель (внешний API + локальный fallback) | Гибкость, резервирование критических функций, возможность сравнения | Сложность интеграции, удорожание поддержки, необходимость управления двумя системами | Клиентские сервисы, где отказ недопустим, но можно использовать внешний API для пиковых нагрузок |
| Полный суверенный контур | Максимальный контроль над данными и моделью, независимость от поставщиков | Высокие CAPEX и OPEX на железо и R&D, потребность в квалифицированной команде | Обработка персональных данных, работа с гостайной, уникальные производственные процессы |
Что делать: пошагово
- Провести аудит текущего использования ИИ-моделей. Документируйте, какие сервисы и API используются в компании, для каких задач и какие типы данных к ним поступают.
- Классифицировать задачи и данные по критичности. Разделите все процессы на критические (недопустимы отказ или утечка данных) и некритические.
- Разработать стратегию резервирования. Для каждой критической задачи определите fallback-вариант на основе открытых моделей (например, Llama 3) или российских аналогов, которые можно развернуть на своей инфраструктуре.
- Внедрить технические средства защиты для собственных API. Если вы предоставляете доступ к своей модели, настройте системы мониторинга аномальной активности, ограничьте скорость запросов и требуйте верификацию корпоративных клиентов.
- Пересмотреть договоры с зарубежными поставщиками. Обратите внимание на пункты о владении сгенерированными данными, возможности обучения на ваших запросах и порядке изменения условий.
- Создать внутреннюю компетенцию по дообучению моделей. По нашему опыту проектов, даже небольшая команда, способная тонко настраивать open-weight модели под свои задачи, даёт огромное стратегическое преимущество.
- Разработать политику управления ИИ-активами. Определите, кто отвечает за выбор моделей, за безопасность данных и за план действий в случае недоступности внешнего сервиса.
- Начать поэтапный переход к суверенной архитектуре. Начните с некритичных задач, чтобы наработать опыт развертывания и поддержки локальных моделей, прежде чем переносить на них ключевые бизнес-процессы.
Типичные ошибки
- Игнорирование условий использования API. Многие компании не читают разделы о запрете на использование данных для обучения конкурирующих продуктов, что создаёт юридические риски.
- Отправка сырых внутренних данных во внешние модели. По нашему опыту, даже обезличивание не всегда гарантирует невозможность восстановления чувствительной информации через сложные запросы.
- Отсутствие плана «Б». Уверенность, что «наш провайдер большой и не исчезнет», приводит к параличу бизнеса при первом же ужесточении политики доступа или изменении цен.
- Недооценка стоимости перехода. Откладывание разработки собственного контура до момента блокировки иностранного API приводит к срочным и дорогим проектам, результат которых непредсказуем.
- Смешивание инфраструктур. Размещение российских моделей на облачных площадках, подконтрольных иностранным юрисдикциям, сводит на нет весь смысл суверенитета.
- Фокус только на модели, а не на данных. Компания вкладывает миллионы в обучение уникальной модели, но не защищает датасет, на котором она обучалась, становясь лёгкой мишенью для дистилляции.
Как понять, что вы на верном пути
- У вас есть как минимум два независимых источника языковых моделей для решения одних и тех же задач, и вы можете переключаться между ними.
- Критически важные данные (персональные, коммерческая тайна, ноу-хау) никогда не покидают периметр вашей корпоративной сети или доверенного российского облака.
- Вы ведёте журнал использования API и анализируете его на предмет аномалий, а не только для биллинга.
- Ваша команда способна взять open-weight модель, дообучить её на своих данных и развернуть в продуктивной среде за обозримое время.
- Стратегия развития ИИ в компании задокументирована, согласована с руководством и включает сценарии реагирования на внешние шоки.
- Вы понимаете экономическую структуру своих ИИ-проектов: разделяете затраты на инфраструктуру (CAPEX/OPEX), данные и разработку.
Вопросы, которые нам задают
Стоит ли полностью отказываться от зарубежных API?
Полный отказ не всегда целесообразен и экономически оправдан. Зарубежные модели до сих пор лидируют в ряде задач. Стратегически верно строить трёхуровневую систему: критичные задачи — на суверенном контуре, задачи средней важности — на гибридной схеме с fallback, а некритичные, экспериментальные — можно вести на внешних API с строгим контролем за потоком данных.
Как защитить свою модель, если мы не Anthropic?
Даже без ресурсов гиганта можно применять эффективные меры. Во-первых, введите обязательную регистрацию и верификацию для API-доступа. Во-вторых, установите разумные лимиты на количество запросов в единицу времени. В-третьих, внедрите базовый мониторинг координированной активности с одного IP. Наконец, для анонимных или бесплатных пользователей можно намеренно немного упрощать ответы, снижая их ценность для дистилляции.
Какие российские модели можно считать полноценными аналогами?
На российском рынке представлены решения от «Яндекса» (YandexGPT), VK (в рамках экосистемы), «Сбера» (GigaChat) и других игроков. Выбор конкретной модели зависит от задачи: для генерации кода одна может подходить лучше, для анализа документов — другая. Важно понимать, что прямого сравнения их устойчивости к целенаправленной дистилляции в открытых источниках нет, поэтому оценка должна проводиться индивидуально под ваши сценарии использования.