Суверенный AI-стек: как выстроить работу с ИИ в российской юрисдикции

Что на самом деле требует закон — и чего он не требует

«Суверенный AI» звучит как декларация, но по сути это ответ на конкретный регуляторный вопрос: где физически обрабатывается ваш промпт и что в нём находится. 152-ФЗ привязывает первичную обработку персональных данных граждан РФ к базам данных на территории России и отдельно регулирует их передачу за рубеж — как именно это работает по статьям, разобрано в материалах ниже. Это не запрещает использование AI. Это ограничивает, куда можно отправлять определённые данные и на какой инфраструктуре они должны в итоге оседать.

Отсюда вытекает практическая ошибка, которую мы видим постоянно: путать «AI как категория» с «конкретный промпт с конкретными данными». Использование зарубежного AI-сервиса само по себе не запрещено — доступ к нему часто ограничивает сама компания-вендор, а не российский закон. Вопрос, который реально определяет риск, — какие данные вы в этот сервис отправляете. Публичный пресс-релиз можно отправить куда угодно. Транскрипт звонка с клиентом, база контактов журналистов, резюме кандидата — это уже персональные данные, и для них выбор инфраструктуры перестаёт быть техническим предпочтением и становится юридическим требованием.

Разбор этого вопроса — «легален ли конкретный сервис» и «что именно можно ему отправлять» — сделан отдельно и подробно в статье «Можно ли использовать ChatGPT для бизнеса в России». Там же разведены три разных вопроса, которые обычно сливаются в один: легальность сервиса, доступность его для российских пользователей и легальность конкретной отправки данных. Если вам нужна практическая decision-таблица по типам данных — какие можно грузить в managed-сервис, какие требуют self-hosted, а какие вообще нельзя выгружать за пределы вашего периметра, — это «152-ФЗ и AI: что можно и что нельзя выгружать». Мы не повторяем эти таблицы здесь: они уже разобраны по конкретным сценариям, а эта страница — про то, как выбрать архитектуру целиком, а не про решение по одному промпту.

Если сузить до одного тезиса: суверенная архитектура — это не про то, чтобы «не пользоваться зарубежным AI из принципа». Это про то, чтобы данные, для которых закон требует локализации, физически не имели возможности её нарушить — не потому что кто-то в команде не забыл настройку, а потому что архитектура устроена так, что нарушить некуда.

Кому этот вопрос вообще критичен. Для большинства маркетинговых и контентных задач суверенность — вопрос гигиены, а не выживания бизнеса. Но для государственных учреждений, финансовых институтов и организаций здравоохранения использование иностранных облачных AI-сервисов для основного потока данных зачастую вообще не рассматривается как опция — не потому что кто-то в компании принял такое решение, а потому что 152-ФЗ и отраслевые требования делают трансграничную передачу персональных данных клиентов и пациентов юридически неприемлемой с самого начала. Это не значит, что таким организациям недоступен AI — это значит, что им нужна инфраструктура, изначально построенная в российской юрисдикции, а не адаптированная постфактум под требования регулятора.

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

Три уровня суверенности

Компании, которые начинают проектировать «суверенный AI», почти всегда стартуют с вопроса «self-hosted или нет» — и почти всегда ошибаются с ответом, потому что вопрос сформулирован слишком грубо. На практике есть три уровня, и каждый следующий стоит дороже и решает более узкий круг задач, чем кажется на старте.

Уровень 1 — managed-РФ. Вы подключаетесь к API модели, которая физически работает в российской юрисдикции — прежде всего YandexGPT в Yandex Cloud. Инфраструктуру, обновления, масштабирование держит вендор; вы отвечаете только за то, что отправляете в промпт. Речь именно о managed-сервисе в российской юрисдикции — зарубежный cloud-SaaS в этот уровень не входит. С точки зрения закона это схема с «лицом, осуществляющим обработку» по ст. 6 152-ФЗ — она закрывает большинство сценариев, но только при наличии согласия субъекта персональных данных и договора поручения с вендором. Это самый быстрый и самый дешёвый уровень старта, и для агентства без своей инженерной команды — путь по умолчанию.

Уровень 2 — self-hosted open-source в РФ-контуре. Вы разворачиваете открытую модель (в нашем случае Qwen) на собственной инфраструктуре внутри российского периметра. Оператором обработки становитесь вы сами — данные физически не покидают контур, потому что физически некуда покидать. Этот уровень нужен там, где managed-сервис не закрывает требования: специальные категории персональных данных, договоры с оговоркой о независимости от единственного вендора, потребность в дообучении модели под собственный домен. Плата — GPU-инфраструктура и инженерное время на поддержку inference-стека.

Уровень 3 — полностью офлайн. Контур без сетевого выхода вообще: ни исходящих запросов к внешним API, ни телеметрии, ни обновлений через интернет. Встречается в средах с максимальными требованиями к физической изоляции и на практике кратно реже первых двух уровней. Для большинства коммерческих команд, даже тех, что подпадают под жёсткие требования 152-ФЗ, уровень 2 уже закрывает вопрос: физическая изоляция сети — отдельное, куда более узкое требование, и подтверждать его необходимость стоит с профильным специалистом по информационной безопасности, а не выбирать «на всякий случай».

Главная практическая ошибка — брать уровень 2 или 3 по умолчанию, «раз уж всё равно строим суверенный AI». Мы регулярно видим команды, которые разворачивают self-hosted-инфраструктуру для сценариев, где managed YandexGPT полностью закрывает и закон, и риск, — и получают на руки инженерную нагрузку, которая не покупает им ничего сверх того, что уже давал API. Правильная последовательность — определить, какой уровень требует конкретный поток данных, а не выбрать уровень заранее и подгонять под него все сценарии компании.

Уровни не исключают друг друга — они сосуществуют внутри одной компании, потому что разные потоки данных требуют разного режима. Публичный контент маркетинговой команды может спокойно идти через managed-РФ, пока HR-департамент той же компании обрабатывает резюме кандидатов через self-hosted-контур, потому что резюме — персональные данные с более узким основанием обработки. Ошибка — искать единый ответ «какой у нас уровень суверенности» для всей организации сразу; правильная единица анализа — конкретный поток данных, а не компания целиком. Миграция между уровнями тоже не одномоментное событие: типичный путь — начать с managed-РФ для всех задач, а затем поднимать в self-hosted только те потоки, для которых появляется реальное юридическое или бизнес-основание, а не переносить всё сразу «на всякий случай».

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

Стек по слоям

Каждый уровень суверенности реализуется одним и тем же образом — набором слоёв, которые конфигурируются независимо друг от друга. Вот наш стек в текущем виде: он не самый сложный из возможных, но закрывает уровень 1 и уровень 2 одновременно, потому что каждый слой можно двигать между managed и self-hosted независимо от остальных.

Мы не проектировали этот стек «под суверенность» с чистого листа — он вырос из обычного продуктового стека, где мы по каждому слою отдельно спросили «эта часть обязана быть в РФ-периметре или нет». Слои, которые касаются данных клиента напрямую — хранилище и векторный индекс, — оказались self-hosted почти сразу. Слои, которые касаются только вычислений над уже собранным контекстом, — модели и оркестрация, — остались гибкими и могут переключаться между managed и self-hosted в зависимости от задачи. Это и есть практический смысл слоёного подхода: суверенность — не свойство всего стека сразу, а свойство конкретного слоя, применённое к конкретному потоку данных.

API-слой. Next.js API routes закрывают аутентификацию и маршрутизацию запросов между фронтендом и остальным стеком. Этот слой не хранит и не обрабатывает персональные данные сам по себе — он передаёт запрос дальше.

Оркестрация. LangChain управляет цепочками промптов и взаимодействием с моделями — сборкой контекста, вызовом нужной модели, обработкой ответа. Это точка, где решается, какая модель обслуживает конкретный запрос: если задача требует self-hosted-уровня, маршрутизация на Qwen происходит здесь, а не требует переписывания остального стека.

Модели. YandexGPT API — основной генеративный слой для задач на русском языке, обработка остаётся в РФ-юрисдикции. Qwen — open-source альтернатива для специфических задач, которые требуют self-hosted-уровня или кастомизации. Оба варианта закрывают 152-ФЗ, но на разных уровнях суверенности — разница в том, кто выступает оператором обработки, разобрана в предыдущем разделе.

Векторное хранилище. pgvector отвечает за семантический поиск по эмбеддингам в RAG-пайплайнах. Эмбеддинги — тоже результат обработки данных, и если исходный текст содержал персональные данные, эмбеддинг наследует этот статус: векторное хранилище должно оставаться в том же периметре, что и исходные данные.

Хранилище данных. Self-hosted Supabase — PostgreSQL, авторизация и файловое хранилище, развёрнутые через Docker. Это базовый слой, где физически оседают данные клиента, и первый кандидат на self-hosted независимо от того, на каком уровне суверенности находятся остальные слои стека.

Разворачивание этого стека по слоям на конкретных GPU-инстансах Yandex Cloud, с ценами по SKU и точкой окупаемости self-hosted против per-token billing — отдельная тема, которую мы разбираем целиком в статье «Self-hosted AI на Yandex Cloud: архитектура для агентств». Там же — почему «self-hosted» на практике почти всегда означает гибрид по слоям, а не всё-или-ничего: слой данных и векторное хранилище self-hosted, потому что там оседают персональные данные, а слой моделей может оставаться managed через YandexGPT API там, где это не противоречит требованиям.

Выбор модели: YandexGPT или Qwen

Внутри слоя моделей стоит отдельный вопрос — какую модель использовать по умолчанию, а какую держать как self-hosted-опцию для чувствительных задач. Мы используем обе не потому что «на всякий случай», а потому что они закрывают разные сценарии: YandexGPT — managed-удобство и сильный русский язык без своей GPU-инфраструктуры, Qwen — open-weights модель, которую можно развернуть на собственном железе с полным контролем и без per-token-зависимости от вендора.

Развёрнутое сравнение — качество на русском, юрисдикция данных, лицензия, экономика, кастомизация, зависимость от вендора — и практическая рекомендация, какую модель брать под какую задачу, вынесены в отдельный материал: «YandexGPT vs Qwen: что выбрать для бизнеса в России». Короткая версия: если у вас нет инженерной команды и нужен быстрый старт с сильным русским языком — YandexGPT. Если нужен максимальный контроль, дообучение под домен или данные, которым нельзя покидать ваш периметр ни при каких обстоятельствах, — Qwen self-hosted. Гибрид, где обе модели работают параллельно под разные классы задач, — не компромисс, а рабочая архитектура, которую мы используем сами.

Важно не путать выбор модели с выбором уровня суверенности — это два разных решения, которые принимаются по разным критериям. Уровень суверенности определяется тем, что за данные вы обрабатываете и что требует закон. Выбор модели внутри уже выбранного уровня определяется задачей: для какого языка, какого объёма контекста, с какой степенью кастомизации. Managed YandexGPT и self-hosted Qwen у нас работают не как взаимоисключающие варианты одного и того же уровня, а как две модели внутри одного стека, между которыми оркестрация маршрутизирует запрос в зависимости от того, что этот конкретный запрос требует.

Честные издержки

Суверенная инфраструктура — это не бесплатный апгрейд к обычному облачному AI. У неё есть конкретная цена, и мы предпочитаем говорить о ней прямо, а не оставлять клиентам открывать это самостоятельно через полгода после запуска.

Латентность. YandexGPT медленнее GPT-4o или Claude на сопоставимых задачах — это факт инфраструктуры, а не временная проблема, которую вендор скоро решит. Мы компенсируем это на уровне архитектуры: агрессивное кэширование повторяющихся запросов, предвычисление там, где ответ можно подготовить заранее, асинхронные очереди вместо синхронного ожидания ответа модели там, где UX это допускает. Полностью убрать разницу в скорости нельзя — можно спроектировать пайплайн так, чтобы пользователь её не замечал.

Качество модели по языкам и задачам. Для текстов на русском языке YandexGPT показывает уверенные результаты — это её основная зона силы. Для английского языка или генерации кода она заметно отстаёт от мультиязычных моделей. Мы не пытаемся переиграть это несоответствие в лоб — вместо этого проектируем пайплайны так, чтобы задачи попадали к модели, которая в них сильна, а не заставляем одну модель тянуть весь диапазон задач одинаково хорошо.

Сложность инфраструктуры. Self-hosting Supabase и управление Docker-контейнерами требует ощутимо больше операционных усилий, чем просто вызывать облачный API. Это постоянная статья инженерного времени, а не разовая настройка: обновления, мониторинг, реакция на инциденты. Мы закрываем это скриптами развёртывания и мониторингом, но сама нагрузка никуда не девается — она просто становится предсказуемой, а не случайной.

Предсказуемость затрат. У managed-API экономика линейная и понятная: платите за то, что реально используете, и счёт растёт вместе с нагрузкой. У self-hosted-уровня она устроена иначе — GPU-инстанс нужно держать поднятым независимо от того, идёт на него нагрузка прямо сейчас или нет, потому что холодный старт модели занимает время, недопустимое для интерактивного сценария. Это означает, что в периоды спада спроса компания платит за простаивающие мощности, а не только за использование, и эта разница особенно заметна у продуктов с неравномерной, пиковой нагрузкой. Обратная сторона той же медали — при self-hosted-уровне итоговая стоимость на единицу использования становится предсказуемой заранее, а не зависит от того, сколько токенов сожгли пользователи в конкретном месяце. Какая из этих двух моделей выгоднее — зависит от профиля нагрузки, и это тот вопрос, который стоит закрыть до перехода на self-hosted, а не после.

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

Кто в команде это несёт. Издержки суверенной инфраструктуры редко ложатся равномерно. Латентность и качество модели — это то, с чем сталкивается продуктовая команда и конечный пользователь; сложность инфраструктуры — то, что несёт инженер, отвечающий за деплой и мониторинг. Если в компании нет чёткого владельца инфраструктурного слоя — а не только владельца продукта, — операционная нагрузка self-hosted-уровня имеет свойство молча копиться, пока не проявится в виде инцидента. Прежде чем поднимать уровень суверенности выше managed-РФ, стоит явно закрепить, кто отвечает за эту постоянную нагрузку — не как разовую задачу на спринт, а как часть должностных обязанностей.

Когда суверенное решение не нужно

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

Пилотный проект на несколько месяцев. Если вы проверяете гипотезу, а не строите production-систему, инвестиция в self-hosted не успеет окупиться до того, как гипотеза либо подтвердится, либо будет закрыта. Возьмите managed YandexGPT API, проверьте идею, мигрируйте на более тяжёлый уровень суверенности, если продукт действительно пошёл в рост. Обратная ситуация — когда команда откладывает пилот на месяцы, пока строит self-hosted-контур «на будущее», — встречается не реже и обходится дороже: гипотеза, которую можно было бы проверить за две недели на managed API, зависает в ожидании инфраструктуры, которая может вообще не понадобиться.

Нет персональных данных в потоке. Публичные пресс-релизы, открытые отчёты, общий маркетинговый контент без упоминания конкретных людей — обработка такого контента через managed-сервис, включая зарубежные API, формально не создаёт конфликта с 152-ФЗ. Заводить под это self-hosted-инфраструктуру — решать проблему, которой нет. Такой поток можно оставить на managed-уровне и вернуться к вопросу суверенности только тогда, когда в него реально начнут попадать данные, которые её требуют, — не раньше.

Нет инженерной команды для поддержки inference-стека. Self-hosted — это не разовая настройка, а постоянная операционная нагрузка: обновления модели, мониторинг GPU, реакция на downtime. Без человека, который за это отвечает, self-hosted-контур быстро превращается в простаивающий GPU-инстанс, который никто не может объяснить финансовому директору. В этой ситуации managed-РФ — не временный компромисс, а корректный выбор до тех пор, пока в команде не появится роль, реально отвечающая за инфраструктурный слой.

Скорость важнее контроля на этой стадии. Если для бизнеса критична скорость выхода на рынок, а не архитектурная независимость, managed API даёт запуск за часы, а не недели. Это особенно верно на ранней стадии продукта, когда сам продукт ещё меняется быстрее, чем успевает окупиться любая инфраструктурная инвестиция, — в такой момент гибкость важнее контроля.

Мы рекомендуем суверенную инфраструктуру, когда верно хотя бы одно из следующего: закон прямо требует хранения данных на территории России для конкретного потока; организация регулярно обрабатывает чувствительные персональные данные; есть стратегическая потребность в независимости от одного AI-вендора; или долгосрочная экономика важнее скорости первоначальной настройки. Если ни один из этих пунктов не описывает вашу ситуацию сегодня — начните с уровня 1 и пересмотрите решение, когда появится реальный сигнал, а не гипотетический. Пересмотр решения — это не признание ошибки: архитектура, которую можно спокойно поднять на уровень выше при появлении основания, спроектирована лучше, чем архитектура, которая с первого дня несёт максимальный уровень сложности «про запас».

Куда идти дальше

Эта страница — карта решения, а не финальная точка. Если вы дочитали до этого места, скорее всего вы уже понимаете, на каком уровне суверенности находится ваша компания и какой поток данных заставил вас искать ответ. Следующий шаг — не «прочитать про суверенный AI ещё раз», а закрыть конкретный практический вопрос, который стоит перед вами прямо сейчас. В зависимости от того, какой это вопрос, ниже — один из пяти материалов:

• Нужно решить, какие конкретно данные можно отправлять в облако, а какие нет — «152-ФЗ и AI: что можно и что нельзя выгружать», с decision-таблицами по типам данных и сценариям.
• Готовы разворачивать self-hosted-контур на Yandex Cloud — «Self-hosted AI на Yandex Cloud: архитектура для агентств», с конкретными GPU-инстансами и точкой окупаемости.
• Команда спорит, можно ли вообще пользоваться ChatGPT, — «Можно ли использовать ChatGPT для бизнеса в России», прямой ответ и практическая маршрутизация задач.
• Выбираете между YandexGPT и Qwen под конкретную задачу — «YandexGPT vs Qwen: что выбрать для бизнеса в России», развёрнутое сравнение managed- и self-hosted-пути.
• Черновик от модели в суверенном контуре — это черновик, а не финальный текст, и на open-weights-пути редактуры требуется заметно больше — «Как гуманизировать AI-текст на русском», приёмы, которыми это делается на практике.

Канонический справочник остаётся на странице Суверенный AI для российских предприятий — это страница продукта с архитектурными вариантами и сравнением развёртываний, без привязки к конкретному кейсу выбора. Если хотите спроектировать суверенную архитектуру под свою компанию с нуля — поговорим: разберём, какой из трёх уровней суверенности реально нужен именно вашим данным, а не какой звучит внушительнее на презентации.