Локальный ИИ: как развернуть модель, чтобы данные не уходили в облако

Меня всё чаще спрашивают одно и то же: «Можно развернуть модель у себя, чтобы промпты и данные вообще не уходили наружу?» Спрашивают айтишники, спрашивают безопасники, спрашивают юристы. Ответ короткий: да, можно. Но за коротким «да» стоит длинный список компромиссов, и его редко проговаривают вслух. Ниже - честная картина без хайпа: что локальный ИИ реально покупает, чего он стоит и когда он оправдан, а когда вы просто усложняете себе жизнь.

Что на самом деле даёт «локальность»

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

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

Именно это, а не производительность и не мода, - настоящая причина, по которой локальный ИИ хотят регулируемые отрасли и компании с чувствительной интеллектуальной собственностью. Они не гонятся за скоростью. Они убирают из схемы третью сторону.

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

Ещё одна причина, которую редко называют вслух, - предсказуемость. Когда модель ваша, вендор не может внезапно поменять условия использования, поднять цены, переехать в другую юрисдикцию или объявить, что теперь он обучается на трафике «по умолчанию». Вы контролируете версию модели и не зависите от чужой дорожной карты. Для одних это второстепенно, для других - в закрытых контурах с многолетним циклом жизни системы - это решающий довод.

Лестница вариантов: от лёгкого к тяжёлому

«Локальный ИИ» - это не один сценарий, а диапазон. Я обычно раскладываю его на три ступени, от самой лёгкой к самой ресурсоёмкой.

Ступень 1. Модели с открытыми весами на своём железе

Модели с открытыми весами - Llama, Mistral, Qwen и родственные - можно скачать и запускать самостоятельно. Для этого есть зрелые инструменты:

• Ollama - самый простой путь. Поднять модель локально можно буквально за вечер, хорошо подходит для экспериментов и небольших нагрузок.
• llama.cpp - когда нужен контроль над квантованием, запуском на CPU или на скромном GPU, встраивание в свои процессы.
• vLLM - когда нужен серверный инференс с нормальной пропускной способностью и очередью запросов на несколько пользователей.

Чего от этого стоит ждать реалистично: чат и черновики, классификация и разметка, извлечение сущностей, RAG поверх ваших собственных документов. Для большинства внутренних задач этого достаточно. Если вы строите поверх этого поиск по базе знаний, полезно параллельно продумать саму архитектуру извлечения - об этом я писал в разборе RAG для корпоративного контекста.

Ступень 2. Частное облако или развёртывание в VPC

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

Это разумный средний вариант для тех, кому не нужен полный on-prem, но нужна гарантия, что запросы не смешиваются с чужим трафиком и не используются для обучения.

Ступень 3. On-prem или air-gapped установка

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

Расплата за этот контроль - максимальная операционная нагрузка. Всё, что в облаке делает вендор, здесь делаете вы: от закупки железа до патчей безопасности в изолированной сети, куда обновления надо ещё доставить.

Честная стоимость и компромиссы

Тут начинается часть, которую в презентациях обычно пропускают.

Железо. Сильная локальная модель хочет настоящих GPU и много памяти. Запустить крепкую модель - это не бесплатно, и, что важнее, простаивающая мощность тоже стоит денег. Вы платите за GPU, даже когда он ничего не считает. В облаке вы платите за токены по факту; на своём железе вы платите за capacity независимо от загрузки.

Разрыв в качестве. Открытые модели за последние пару лет стали очень хороши, и на типовых задачах разница с топовыми хостовыми моделями часто незаметна. Но на самых сложных задачах - длинные цепочки рассуждений, сложный код, редкие языки и домены - локальные open-weight модели, как правило, всё ещё отстают от фронтира. Вы меняете часть возможностей на контроль. Иногда это честный обмен, иногда - нет.

Операции. Обновления, патчинг уязвимостей, мониторинг, масштабирование, аптайм - теперь это ваша забота, а не вендора. Модель, которую вы развернули полгода назад, не обновится сама. Инцидент в три часа ночи будете разбирать вы.

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

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

Кадры и компетенции. Отдельная, часто недооценённая статья. Развернуть и держать в проде локальный инференс - это навык. Нужны люди, которые понимают квантование, память GPU, батчинг запросов, обновление весов и мониторинг качества во времени. Если такой команды нет, вы либо нанимаете её, либо платите подрядчику, и это тоже часть полной стоимости. Облачный сервис прячет эту сложность за API; локально она снова становится вашей.

152-ФЗ и трансграничная передача как драйвер

Для российского контура у локального ИИ есть отдельный, вполне конкретный мотив. Требование локализации первичной базы персональных данных граждан РФ (часть 5 статьи 18 152-ФЗ) означает, что запись, систематизация и хранение таких данных должны идти в базах на территории России. Плюс отдельный режим для трансграничной передачи.

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

Тут важно не перепутать причину со следствием. Локализация не требует, чтобы вся обработка шла именно на локальной ИИ-модели. Она требует, чтобы первичная база персональных данных граждан находилась в России. Локальный ИИ - это один из способов удержать данные в периметре, но не единственный и не всегда обязательный. Иногда достаточно грамотно выстроить потоки так, чтобы модель работала с обезличенными или производными данными, а не с исходной базой. Прежде чем поднимать GPU-кластер под требование локализации, стоит проверить, действительно ли ваш сценарий вообще гоняет через модель то, что подпадает под часть 5 статьи 18. Часто оказывается, что нет.

Когда локально оправдано, а когда хватит бизнес-тарифа

Не каждому нужен свой ИИ-контур. Чаще всего решает не идеология, а профиль данных и нагрузки.

Идти локально стоит, когда:

• вы обрабатываете регулируемые персональные данные с требованиями к резидентности или локализации;
• у вас строгая тайна - интеллектуальная собственность, ноу-хау, закрытые разработки;
• контур офлайновый или изолированный по определению;
• у вас высокий и ровный объём запросов, где экономика собственного железа обыгрывает поштучную оплату токенов.

Облачного бизнес-тарифа с DPA и отключённым обучением чаще всего достаточно, когда:

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

Разница между «локально» и «бизнес-тариф с отключённым обучением» - это отдельный большой разговор. Отключение обучения на ваших промптах закрывает вопрос дообучения вендора, но не вопрос физической передачи данных наружу. Я разбирал это подробнее в заметке про то, как запретить обучение ИИ на ваших промптах.

Как бы я подходил к этому

Порядок, которого я держусь, скучный, но он экономит деньги и нервы.

1. Начните с карты данных и с реального требования. Что именно вас гонит: резидентность? тайна? стоимость? От ответа зависит вся дальнейшая ступень. Требование «хотим локально, потому что так спокойнее» - плохая опора для бюджета.
2. Выберите самый лёгкий вариант, который закрывает требование. Если хватает бизнес-тарифа с DPA - не поднимайте кластер GPU. Если хватает VPC - не идите в air-gapped. Каждая лишняя ступень - это операционная нагрузка навсегда.
3. Пилотируйте один рабочий процесс. Не всю компанию сразу. Один сценарий, одна команда, измеримый результат.
4. Измерьте качество и полную стоимость до расширения. Полную - значит с железом, простоем, людьми и обслуживанием, а не только «цену за токен на бумаге». Часто именно на этом шаге локальный вариант либо подтверждает себя, либо тихо проигрывает облаку.

Честные оговорки

• Локальный ИИ убирает третью сторону из схемы, но не убирает ваши обязанности оператора. Контроль доступа, логи, минимизация, основание для обработки - всё это остаётся на вас.
• Open-weight модели быстро догоняют фронтир, но на самых сложных задачах разрыв ещё есть. Не обещайте бизнесу «то же самое, только у себя» - проверьте на своих задачах.
• Своё железо выгодно на ровном высоком объёме. На рваной нагрузке облако почти всегда дешевле, потому что вы не платите за простой.
• «Air-gapped» звучит надёжно, но это самый дорогой режим по эксплуатации. Не выбирайте его из осторожности - выбирайте, только если требование действительно этого просит.
• Модель, которую вы развернули и забыли, - это уязвимость, которая стареет. Локальный ИИ требует эксплуатации так же, как любой прод.

Если коротко

Локальный ИИ реально решает то, ради чего его обычно и хотят: данные не уходят наружу, третья сторона не видит запросы, вопросы трансграничной передачи и обучения вендора по большей части снимаются. Это честный выбор для регулируемых данных, строгой тайны и офлайновых контуров. Но он не бесплатен: вы берёте на себя железо, эксплуатацию и часть разрыва в качестве, и вы всё равно остаётесь оператором со всеми обязанностями. Для многих команд облачный бизнес-тариф с DPA и отключённым обучением закрывает задачу дешевле и проще. Правильный ответ определяется не идеологией, а картой данных, требованием и профилем нагрузки.

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