Урок 5: Санкции 2026 — как работать без OpenAI

Чему вы научитесь

• Быстро отличать «официально доступный сервис» от серой схемы, которая держится на прокси, дочке или чужом договоре
• Понимать, какие западные AI-сервисы для российского промышленного предприятия нельзя брать как опорный контур уже на этапе закупки
• Выбирать между российскими корпоративными LLM и open-weight моделями из КНР под конкретный сценарий
• Ставить интегратору правильные требования к on-prem-развёртыванию: аудит весов, изоляция, запрет внешних вызовов и контроль лицензии
• Связывать санкционный выбор с двумя соседними уроками модуля: уроком 1 про персональные данные и уроком 2 про КИИ

Главный вопрос здесь звучит не так: «какая модель умнее». Правильный вопрос: «какой контур закупки, эксплуатации и права доступа у нас вообще реален». Для российского промышленного предприятия OpenAI, Anthropic, Gemini, Azure OpenAI, AWS Bedrock и GitHub Copilot — это в лучшем случае нестабильный внешний ресурс, а не базовый корпоративный стандарт. Для значимых объектов КИИ такой внешний контур нужно считать закрытым ещё жёстче: не только из-за санкций, но и из-за запрета на иностранное ПО, о котором мы говорили в уроке 2 (Указ Президента РФ № 166 от 30.03.2022; КонсультантПлюс, Указ № 166 в ред. от 07.04.2025).

Что именно недоступно российскому предприятию как штатный корпоративный контур

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

Серые схемы: когда их вообще обсуждают

Серые схемы на рынке есть. Самые частые две:

• дочерняя компания или проектный офис в нейтральной юрисдикции, который сам покупает доступ к западному AI-сервису;
• AI-gateway или proxy-API, который прячет различия между OpenAI, Claude, Gemini и другими моделями за единым endpoint, например Eden AI или российский ProxyAPI.

Но эти схемы годятся только для узкого класса задач: нет КИИ, нет персональных данных, нет гостайны, нет критичной коммерческой тайны и нет зависимости производства от этого канала. Иначе вы строите не архитектуру, а управляемое нарушение.

flowchart TD
    A[Нужен внешний AI-сервис] --> B{Есть КИИ или значимый производственный контур?}
    B -->|Да| C[Иностранный SaaS исключить]
    C --> D[Смотреть on-prem российские модели или audited open-weight]
    B -->|Нет| E{Есть ПД или чувствительная КТ?}
    E -->|Да| F[Сначала урок 1: локализация, основания, договор, логирование]
    F --> G[После этого смотреть российский облачный или локальный контур]
    E -->|Нет| H{Нужен быстрый эксперимент?}
    H -->|Да| I[Допустим sandbox через proxy или arckep.ru на обезличенных данных]
    H -->|Нет| J[Стройте белый корпоративный контур сразу]

Чем заменять западный стек в белом контуре

Если вам нужен рабочий корпоративный путь, выбор обычно сводится к трём группам: российские B2B-модели, локально развёрнутые open-weight модели и узкий sandbox для экспериментов.

Российские корпоративные LLM

Для обкатки промптов, маршрутизации и user-flow на обезличенных данных можно использовать arckep.ru: это удобно как тренировочный полигон без VPN и с рублёвой оплатой. Но arckep.ru — это именно песочница для практики и проверки идей, а не способ обойти требования по КИИ, ПД и коммерческой тайне.

Open-weight из КНР: когда это уже не «китайский риск», а рабочий инструмент

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

Но здесь типовая ошибка обратная. Команды думают, что если модель можно скачать с GitHub или Hugging Face, то юридический и ИБ-вопрос закрыт. Это не так. Вам нужны минимум четыре вещи:

1. точное имя checkpoint и хеш поставки;
2. понятная лицензия на коммерческое использование;
3. изоляция от внешней сети и запрет несанкционированных outbound-вызовов;
4. аудит контейнеров, зависимостей, стартовых скриптов и механизма обновления.

Что реально смотреть в китайском open-weight сегменте

Практическое правило жёсткое: китайская open-weight модель имеет смысл, только если вы готовы владеть эксплуатацией. Если у вас нет команды для локального inference, сетевой изоляции, мониторинга и red-team проверки промптов, open-weight быстро превращается в дорогую имитацию суверенности.

Чек-лист для on-prem-модели: что требовать от интегратора

1. Зафиксируйте точную модель. Не «Qwen» и не «DeepSeek», а конкретный checkpoint, версия, дата публикации и контрольная сумма артефактов.

2. Проверьте лицензию. У юриста должен быть ответ: можно ли коммерческое использование, дообучение, модификация, перепродажа сервиса и передача результата третьим лицам.

3. Отрежьте сеть наружу. Для промышленного контура базовый режим — без внешних вызовов, кроме контролируемых зеркал обновлений и репозиториев, если они вообще разрешены.

4. Проверьте контейнеры и зависимости. Нужны SBOM, результаты сканирования уязвимостей и список внешних библиотек. Это особенно важно для agentic-стека с большим числом обвязок.

5. Проверьте журналирование. Логи запросов, ответов и действий агентов должны оставаться в вашем контуре, а не в облаке поставщика.

6. Сделайте red-team на своих сценариях. Не ограничивайтесь общими бенчмарками. Проверяйте prompt injection, утечки фрагментов документации, опасные действия tool-use и ошибки маршрутизации.

7. Разведите sandbox и production. Эксперименты с новой моделью нельзя проводить в том же контуре, где живут реальные технологические данные.

8. Для КИИ оформляйте это как отдельный проект ИБ. Не как «ещё один сервер с моделью», а как объект с понятным классом, границами и мерами защиты. Здесь снова нужен урок 2.

Матрица «что использовать под какой сценарий»