Суверенитет в ИИ часто представляют как «одну большую российскую нейросеть», которая заменит всё сразу. На практике так не работает: одна модель не может одновременно тянуть код, документы, корпоративный поиск и чувствительные данные, к которым предъявляются разные требования по ИБ и комплаенсу. В материалах по российскому ИИ-стеку мы собрали референс-архитектуру и пришли к главному выводу: суверенитет в 2026 году — это не «полный отказ от внешних моделей», а умение маршрутизировать задачи между контурами. Ниже — как эта архитектура устроена и с чего начинается переход.
Почему «одна нейросеть на всё» не работает
«Всё в один API» выглядит удобно на старте и опасно в проде. Три причины:
- Разные классы данных требуют разного режима. Публичная аналитика и внутренняя переписка не могут идти по одному маршруту. Там, где данные чувствительные, внешний API недопустим в принципе.
- Разные задачи требуют разных моделей. Код, корпоративный поиск, документы, аналитика и reasoning — это не один сценарий. Где-то выигрывает российское ядро, где-то — сильная reasoning-модель.
- Один контур — один риск. Если модель, вендор или канал отказывает, останавливается весь стек. Разведённые контуры эту зависимость снижают.
Поэтому вместо «выбора единственной модели» мы проектируем маршрутизацию: набор правил, по которым задача и её данные попадают в подходящий контур.
Контуры вместо «одного окна в модель»
Практичная модель разведения — три контура по классам данных:
- Красный — только локальные модели и self-hosted решения для самых чувствительных данных. Никаких внешних вызовов, полный контроль размещения и доступа.
- Жёлтый — российские управляемые сервисы и API как основной рабочий контур: Yandex AI Studio, GigaChat и отечественные MLOps-инструменты.
- Зелёный — разрешённые внешние reasoning-модели (например, DeepSeek) для задач вне чувствительного контура: рассуждения, фоновая аналитика, черновики.
Граница между контурами — это не «плохо/хорошо», а политика: что, куда и при каких условиях можно отправлять. Именно она превращает набор моделей в управляемый стек.
Риск не в стране модели, а в маршруте данных
Частое упрощение — «российская модель безопасна, зарубежная — нет». Это неверная рамка. Риск для организации лежит не столько в стране происхождения модели, сколько в том, куда реально уходят данные, кто имеет к ним доступ и как устроено журналирование.
Практический вывод: перед выбором модели нужно описать классификацию данных и политику маршрутизации. Тогда вопрос «можно ли использовать внешнюю модель» превращается из идеологического в инженерный: для класса данных A — да, для класса B — только локально, для класса C — через policy gate с логированием.
Смотреть нужно не на страну происхождения модели, а на маршрут данных, доступ к ним и журналирование.
Слои, а не «одна покупка»
Суверенный стек собирается по слоям — и покупать его целиком не нужно:
- Рабочее место. Linux-first: Альт, Astra Linux. Основа контура, а не «косметика».
- Dev workbench и coding-ассистент. GigaIDE, SourceCraft, GigaCode — инженерная среда, в которой рождается код.
- Git-платформа. GitFlic, GitVerse как корень инженерного контура: код, ревью, история.
- AI-ядро. Yandex AI Studio, GigaChat, локальные модели для чувствительных задач.
- Документы и офис. Р7-Офис, МойОфис, docs-as-code — знания как код, а не как вложения в почте.
- Агентный слой. Оркестрация ролей и задач поверх управляемого контура.
- Безопасность и эксплуатация. Политики, права, журналирование, мониторинг.
Каждый слой можно внедрять отдельно, но ценность появляется, когда они связаны политикой маршрутизации.
Суверенный гибрид и строгий контур: кому что
Не каждой компании нужен максимально изолированный стек. Мы различаем два базовых сценария:
- Суверенный гибрид — базовый вариант для большинства: российское ядро и основной контур плюс разрешённые внешние модели в зелёном контуре там, где это допустимо политикой данных.
- Строгий изолированный контур — для критической инфраструктуры и сред с прямыми требованиями к размещению и доступу: только локальные модели и self-hosted решения, внешние вызовы исключены.
Выбор между ними — не вопрос «зрелости», а вопрос требований: где данные должны физически лежать и кто к ним имеет доступ.
Дорожная карта: база → ядро → маршрутизация → агенты
Переход начинается не с покупки модели. Порядок такой:
- База. Linux-first рабочее место, Git как инженерный корень, классификация данных, база знаний как код.
- Российское AI-ядро. Подключаем отечественные модели и сервисы в основной контур.
- Развод контуров и политика маршрутизации. Определяем, что и куда можно отправлять, настраиваем policy gate и журналирование.
- Агенты и рутина. И только поверх управляемого контура — агентный слой и автоматизация повторяемых процессов.
Такой порядок снижает риск: сначала управляемость, потом автономия.
Типовые ошибки
- Начать с агентов. Автономия без базы, политик и журналирования — это управляемый риск, а не инновация.
- Купить «одну модель» и считать задачу решённой. Без слоёв и маршрутизации это демо, а не стек.
- Забыть про классификацию данных. Без неё политика маршрутизации превращается в лозунг.
- Путать страну модели с безопасностью данных. Смотреть нужно на маршрут и доступ, а не на флаг вендора.
Что это значит для нас
Эти материалы легли в основу нашего инженерного практикума «Суверенный AI-стек» и подходов к внедрению для госсектора и промышленности. Если вы проектируете российский контур, разумный первый шаг — разобрать ваш текущий стек и определить, какой контур вам реально нужен: строгий или гибрид.
Записаться на практикум · ИИ-консалтинг: аудит и внедрение · Интеграция российского ПО