Модель на собственном сервере закрывает главный вопрос 152-ФЗ простым способом: персональные данные вообще не покидают вашу сеть. Нет передачи третьему лицу — значит, не нужны поручение обработки провайдеру модели и уведомление о трансграничной передаче, а вопрос «где физически лежат наши данные» получает ответ, который можно показать службе безопасности заказчика и проверяющему. Всё остальное — согласия, цели обработки, журналы доступа, сроки хранения — остаётся вашей обязанностью ровно в том же объёме.
Дальше — практика: какие модели ставят в России по состоянию на сентябрь 2026, на каком железе они работают, три конфигурации с бюджетами для компании 50–200 человек, полная стоимость владения в месяц и порог, начиная с которого свой контур дешевле облачных вызовов. И отдельный раздел про то, когда локальная модель избыточна: таких случаев больше, чем принято думать.
Все суммы — модельные расчёты на прозрачных вводных, а не прайс. Ставки: инженер 3 000 ₽/час, системный администратор 2 500 ₽/час. Цены на видеокарты и аренду GPU в России волатильны — проверяйте на дату закупки, вилки ниже даны как порядок величины на сентябрь 2026.
Что именно меняет локальная модель в документах по 152-ФЗ
Полезно разделить обязанности оператора на две группы: те, что снимаются переносом модели в свой контур, и те, что остаются при любом варианте. Первая группа небольшая, но именно она обычно и блокирует проект в компаниях, где есть медицинские данные, кадровые досье или требование заказчика по размещению.
| Обязанность оператора | Облачная модель по API | Модель в своём контуре |
|---|---|---|
| Передача данных третьему лицу | Провайдер становится обработчиком: нужен договор поручения по ч. 3 ст. 6 152-ФЗ с перечнем действий и целями | Передачи нет. Договор поручения нужен только подрядчику, который обслуживает систему и имеет доступ к данным |
| Трансграничная передача | У российских провайдеров её нет. У зарубежных через посредника — есть, и она требует отдельного основания и уведомления Роскомнадзора | Отсутствует по построению: трафик не выходит за периметр сети |
| Локализация баз данных (ч. 5 ст. 18) | Проверяется по договору: где серверы, где резервные копии, где журналы диалогов | Выполняется по построению — при условии, что и резервные копии, и векторное хранилище тоже в России |
| Хранение текста запросов у постороннего | Логи провайдера живут по его правилам: срок хранения и круг доступа определяет он | Логи ваши. Срок хранения и круг доступа определяете вы — и обязаны определить письменно |
| Согласия, цели, сроки хранения, журналы доступа | Полностью на вас | Полностью на вас — локальность здесь не меняет ничего |
Практическое следствие: локальная модель — это ответ на вопрос «кому мы отдаём данные», а не на вопрос «как мы с ними обращаемся». Компании, которые ставят свой контур и на этом считают тему 152-ФЗ закрытой, обычно спотыкаются на второй группе обязанностей — про неё отдельный раздел ниже.
Две горизонтальные схемы одна под другой. Верхняя: «Сотрудник» → «Ваша система» → пересечение штриховой границы периметра → «Облачный провайдер модели» → обратно; на границе рамка «третье лицо: нужен договор поручения, логи по его правилам». Нижняя: «Сотрудник» → «Ваша система» → «Сервер с моделью» → обратно, всё внутри одной замкнутой штриховой рамки с подписью «периметр компании»; сбоку пометка «участников обработки — один». Внизу общая подпись: «Согласия, сроки хранения и журналы доступа обязательны в обоих случаях».
Что ставят на практике: модели, размеры и обвязка
Набор рабочих вариантов на сентябрь 2026 устоялся. Разворачивают открытые модели — Qwen 3, Llama, DeepSeek, Mistral — чаще всего через Ollama, потому что это самый короткий путь от голого сервера до рабочего интерфейса. Векторное хранилище для базы знаний обычно кладут в pgvector: это расширение к PostgreSQL, который у компании, как правило, уже есть, и отдельную специализированную базу заводить не приходится.
Размер модели считается по простому правилу: в 4-битном квантовании веса занимают примерно 0,6 ГБ видеопамяти на миллиард параметров, плюс 15–30% сверху на контекст и служебные буферы. Модель на 32 млрд параметров — это около 19 ГБ весов и 24–28 ГБ с контекстом, то есть карта на 32 ГБ уже впритык, а на 48 ГБ комфортна. Модель класса 70 млрд в тех же 4 битах требует порядка 50–60 ГБ, то есть двух карт.
| Класс задачи | Размер модели | Нужно видеопамяти | Что получается на практике |
|---|---|---|---|
| Классификация писем и обращений, извлечение полей из типовых форм | 8–14 млрд параметров | 16–24 ГБ | Ровный результат на коротких структурных задачах, ответ за 1–3 секунды |
| Ответы по базе знаний со ссылкой на источник, резюме звонков | 27–32 млрд параметров плюс отдельная модель эмбеддингов | 32–48 ГБ | Рабочий уровень для внутреннего ассистента, контекст 16–32 тысячи токенов |
| Длинные документы: договоры, тендерная документация, своды | 70 млрд параметров | 64–96 ГБ | Держит длинный контекст, но требует двух карт и заметно дольше отвечает |
Отдельный вопрос — лицензии на веса, и он юридический, а не технический. Они разные и меняются между версиями: у части моделей это свободная лицензия, допускающая коммерческое использование, у других — собственная лицензия сообщества с ограничениями, у третьих — исследовательская, прямо запрещающая коммерческое применение без отдельного договора. Юрист должен посмотреть лицензию конкретной версии весов до внедрения, а не «семейства моделей вообще». Ещё одна проверка, о которой обычно забывают: у потребительских видеокарт есть ограничения на использование в дата-центре — если сервер размещается в коммерческом ЦОД, уточните это у поставщика заранее.
Горизонтальная столбчатая диаграмма, ось X — гигабайты видеопамяти от 0 до 96. Три группы столбцов: «8–14 млрд — 16–24 ГБ», «27–32 млрд — 32–48 ГБ», «70 млрд — 64–96 ГБ». Каждый столбец разделён на две части: сплошная «веса модели» и штриховая «контекст и буферы». Вертикальными линиями отмечены типовые объёмы карт: 24 ГБ, 48 ГБ, 96 ГБ (две карты). Подпись внизу: «4-битное квантование, сентябрь 2026».
Три конфигурации под компанию 50–200 человек
Конфигурация выбирается не по числу сотрудников, а по самой тяжёлой из задач и по пиковой одновременной нагрузке. Считать пик нужно из своей статистики: возьмите час максимального потока обращений за последний месяц и делите на 3 600 — получите требование в запросах в секунду, из которого и следует число одновременных сессий.
| Конфигурация | Видеопамять | Что тянет | Одновременных запросов | Бюджет железа |
|---|---|---|---|---|
| Малая | Одна карта на 24 ГБ | Модели 8–14 млрд: классификация, маршрутизация, извлечение полей, короткие ответы | 3–5 | 550 000–800 000 ₽ |
| Средняя | Одна карта на 48 ГБ или две по 24 ГБ | Модели 27–32 млрд плюс эмбеддинги: ответы по базе знаний, резюме звонков, черновики писем | 8–12 | 1 100 000–1 600 000 ₽ |
| Тяжёлая | Две карты по 48 ГБ | Модели класса 70 млрд, контекст 64–128 тысяч токенов: договоры, тендеры, длинные своды | 10–20 | 2 400 000–3 800 000 ₽ |
В бюджет входит сам сервер: корпус, процессор, 128–256 ГБ оперативной памяти, быстрые диски под веса моделей и видеокарты. В него не входит резервный узел — а он нужен: при единственном сервере любой отказ останавливает процесс целиком, и в компании, где на модели висит обработка входящих обращений, это ощущается в тот же час. Обычная схема — либо второй узел попроще, либо облачный запасной контур, который включается автоматически на обезличенных запросах.
Последняя оговорка в расчёте важна. База знаний, интеграции, ограничители, приёмка — это отдельные 250 000–500 000 ₽ по рыночным ориентирам на заказного ИИ-агента, и они нужны в обоих вариантах. Свой контур меняет только строку «где считает модель», и сравнивать варианты нужно именно по ней, иначе разговор быстро уходит в сравнение несравнимого.
Три вертикальные колонки одинаковой ширины с заголовками «Малая», «Средняя», «Тяжёлая». В каждой четыре строки: «Видеопамять» (24 ГБ / 48 ГБ / 2×48 ГБ), «Модели» (8–14 млрд / 27–32 млрд / 70 млрд), «Одновременных запросов» (3–5 / 8–12 / 10–20), «Бюджет железа» (550–800 тыс. ₽ / 1,1–1,6 млн ₽ / 2,4–3,8 млн ₽). Под колонками общая полоса с подписью «Резервный узел в бюджет не входит и нужен всем трём».
Порог: с какого объёма свой контур дешевле облака
Расчёт простой, и результат обычно неприятно удивляет сторонников своего сервера. Стоимость облачного обращения складывается из входных и выходных токенов. Возьмём типичный запрос к ассистенту по базе знаний: около 4 000 входных токенов (инструкция, пять найденных фрагментов, история) и 400 выходных. При ориентировочной цене 0,20 ₽ за 1 000 входных и 0,60 ₽ за 1 000 выходных одно обращение стоит 1,04 ₽. Свой контур стоит фиксированные 89 700 ₽ в месяц независимо от того, сделали вы сто обращений или сто тысяч.
Для компании на 50–200 человек 2 900 обращений в день — это очень много: столько даёт разве что клиентский поток в контакт-центре или массовая обработка документов. На внутреннем ассистенте, которым пользуются сотрудники, реалистичный объём — 3 000–15 000 обращений в месяц, и в этом диапазоне облако дешевле в пять-восемь раз. Порог сдвигается вниз в двух случаях: если операции длинные (на сводках договоров по 5,54 ₽ за документ он падает примерно до 16 000 документов в месяц) или если провайдер поднимает тариф.
За последние два года все участники этого рынка меняли тарифы, вводили и снимали лимиты и обновляли модели под прежними именами. Если цена обращения вырастет втрое — до 3,12 ₽, — порог перехода в свой контур упадёт с 86 000 до 28 750 обращений в месяц, и решение, которое сегодня выглядит очевидным, поменяется. Поэтому в расчёте окупаемости всегда держите такой сценарий: если при тройной цене проект перестаёт сходиться, он не готов к запуску. И заранее закладывайте адаптер, который позволяет переключить систему между облаком и своим сервером за часы, а не за недели. У локальных моделей есть зеркальный риск: лицензия на веса может отличаться у следующей версии — фиксируйте версию, храните скачанные веса у себя и не рассчитывайте на то, что они будут доступны на прежних условиях всегда.
Отсюда честный вывод, который стоит проговорить до закупки железа: локальную модель почти никогда не покупают ради экономии. Её покупают, когда есть требование — специальные категории персональных данных, условие заказчика по размещению, госконтракт, позиция службы безопасности — или когда объём действительно перевалил за порог. Если ни того, ни другого нет, свой сервер обойдётся дороже облака в несколько раз, и это надо сказать собственнику прямо, а не прятать в смете.
Двухосевой график. Горизонтальная сплошная линия на уровне 89 700 ₽ подписана «свой контур, любой объём». Наклонная линия от нуля — облако при 1,04 ₽ за обращение, с отметками 10 000 обращений — 10 400 ₽, 50 000 — 52 000 ₽, 86 250 — 89 700 ₽. Точка пересечения выделена и подписана «86 000 обращений в месяц, 2 900 в день». Пунктиром показана вторая наклонная — «тариф вырос втрое», пересекающая горизонталь в точке 28 750. Оси: обращения в месяц и рубли.
Что остаётся в зоне 152-ФЗ даже при локальной модели
Собственный сервер закрывает вопрос передачи данных наружу и не закрывает всё остальное. Ниже — то, что остаётся вашей обязанностью и что проверяющий спросит независимо от того, где считает модель.
- Правовое основание и цели обработки. Локальность не создаёт основания: согласие или иное основание нужно так же, а цель «обучение сотрудников через ассистента» должна быть заявлена, если данные используются для неё.
- Сроки хранения диалогов. «Храним всё навсегда, вдруг пригодится» противоречит принципу минимизации. Срок определяется письменно, а удаление — автоматически, а не по напоминанию.
- Журналы доступа. Кто и когда открывал переписку с персональными данными, включая администратора сервера: его доступ к базе — тоже обработка, и она должна быть учтена.
- Обезличивание на входе. Самая дешёвая мера из всех: если в запрос уходит «клиент №4718» вместо фамилии и телефона, объём обязанностей сокращается сразу и для локального, и для облачного варианта.
- Поручение обработки подрядчику сопровождения. Если сервер обслуживает внешняя команда и её инженеры видят данные — нужен договор поручения по ч. 3 ст. 6 152-ФЗ, ровно как с облачным провайдером.
- Уведомление об инциденте. При утечке — сообщение в Роскомнадзор в течение 24 часов и результаты внутреннего расследования в течение 72 часов. Свой сервер этого срока не отменяет, а иногда усложняет: расследовать придётся самим.
К этому с 1 сентября 2026 добавились требования регулирования ИИ, включая маркировку сгенерированного контента и правила обработки персональных данных в моделях. Практический минимум для компании — внутренняя политика использования ИИ на две-три страницы: какие данные допустимо отправлять в модель, какие нельзя ни при каких условиях, кто отвечает за проверку ответов и как маркируются материалы, подготовленные с участием ИИ. Завести её дешевле до внедрения, чем объяснять её отсутствие после.
Кто это обслуживает
Свой контур — это не «поставили и забыли», а маленькая инфраструктура со своим сопровождением. В спокойном режиме нагрузка невелика и предсказуема, но она есть всегда, и человек должен быть назван поимённо. В среднем по кварталу это те самые 10 часов администратора и 4 часа инженера в месяц, которые заложены в расчёт стоимости владения выше.
- 8–12 часов администратора в месяц: мониторинг занятости видеопамяти, очереди запросов и худшей задержки, ротация логов, резервные копии, обновление системы.
- 4–6 часов инженера в квартал на обновление весов модели и обязательный регресс-прогон на своих примерах: новая версия ведёт себя иначе, и без прогона это выяснится на клиентах.
- Дежурство. Отказ узла в субботу — это простой процесса до понедельника, если нет запасного контура. Либо второй узел, либо облачный резерв на обезличенных запросах, либо честно согласованное с бизнесом окно недоступности.
- Ответственность за качество: около двух часов в месяц на просмотр выборки диалогов. Локальная модель деградирует так же, как облачная, если база знаний устарела, — а заметить это можно только выборочным контролем.
Самая частая ошибка внедрения выглядит одинаково почти всегда: сервер купили, модель развернули, администратора не выделили. Через полгода система работает на весах годичной давности, диск забит логами диалогов с персональными данными без установленного срока хранения, мониторинга нет, а на вопрос «почему стало хуже отвечать» никто не может ответить, потому что не с чем сравнивать. Стоимость этой ошибки не в деньгах, а в том, что проект тихо признают неудачным.
Когда локальная модель не нужна
Честный список случаев, в которых мы отговариваем от своего контура. Он длиннее, чем список поводов его строить, и это нормально.
- Нет специальных категорий данных и нет требования извне. Если в модель уходят рабочие вопросы сотрудников и обезличенные фрагменты документов, российское облако закрывает вопрос дешевле и быстрее.
- Объём далеко ниже порога. При 5 000–15 000 обращений в месяц облако дешевле в пять-восемь раз, и никакая инженерная красота этого не компенсирует.
- Данные можно обезличить на входе. Замена фамилий и телефонов на идентификаторы стоит 8–16 часов работы и часто снимает само требование о локальности — это первое, что стоит проверить.
- Некому обслуживать. Если в компании нет системного администратора и не планируется договор на сопровождение, сервер станет источником проблем, а не решением.
- Гипотеза ещё не проверена. До подтверждения пользы железо не покупают: на время пилота GPU-сервер арендуется в российском облаке — ориентир 40 000–200 000 ₽ в месяц в зависимости от класса карты. Это позволяет померить и качество, и реальную нагрузку до закупки.
- Задача решается правилами. Маршрутизация по условиям, разбор структурированной выгрузки, сверка справочников — это программа на несколько часов, и вопрос о модели вообще не возникает.
С чего начать, если решение принято
Порядок шагов важнее скорости: почти все дорогие ошибки в этой теме сделаны из-за того, что железо покупали раньше, чем меряли.
- 1Описать маршрут данных: что именно уходит в модель в каждом сценарии и какие из этих полей — персональные данные. Часто на этом шаге выясняется, что половину можно не отправлять.
- 2Проверить обезличивание: сколько сценариев закрывается заменой персональных данных на идентификаторы. Если все — свой контур не нужен, дальше можно не идти.
- 3Арендовать GPU-машину на месяц и померить качество на 100 своих примерах, сравнив локальную модель с облачной. Тот же протокол, что и для выбора любой модели.
- 4Посчитать пиковую нагрузку из своей статистики и по ней выбрать конфигурацию — а не по самой большой модели, которую хочется поставить.
- 5Собрать документы: срок хранения диалогов, журналы доступа, поручение обработки подрядчику сопровождения, внутренняя политика использования ИИ. Это делается параллельно закупке, а не после запуска.
- 6Запланировать сопровождение поимённо: кто администратор, кто дежурит в выходные, кто раз в месяц смотрит выборку диалогов и кто обновляет веса.
Горизонтальная лента из шести этапов с подписями: «Маршрут данных — 1 неделя», «Проверка обезличивания — 1 неделя», «Аренда GPU и замер на 100 примерах — 1 месяц», «Расчёт пиковой нагрузки — 3 дня», «Закупка и развёртывание — 4–6 недель», «Документы и сопровождение — параллельно». Над третьим этапом развилка со стрелкой вбок и подписью «если обезличивание закрывает всё — стоп, свой контур не нужен». Под лентой отметка «здесь тратятся деньги» под этапом закупки.
Свой сервер отвечает на вопрос «кому мы отдаём данные». На вопрос «как мы с ними обращаемся» он не отвечает — и именно за второй спрашивают на проверке.
