Локальный ИИ-агент: когда данные нельзя отдавать в облако

За последний год ко мне трижды обращались клиники и юридические конторы с одним и тем же запросом: нужен ИИ-помощник, который не отправляет переписку и документы в OpenAI или Anthropic. Решение в таких случаях одно - локальный ИИ-агент, работающий на собственном сервере без выхода данных за периметр компании. Дальше разберу, какие модели для этого годятся, что нужно из железа и когда локальный вариант реально оправдан, а когда проще остаться в облаке.

Когда без локального ИИ-агента не обойтись

Медицинская клиника с историями болезни, юридическая контора с материалами дел, финансовая компания с данными клиентов - в каждом из этих случаев отправка текста во внешний API означает передачу персональных данных, врачебной или адвокатской тайны на серверы стороннего облачного провайдера, чаще всего зарубежного. По 152-ФЗ обработка персональных данных граждан РФ должна вестись на серверах, расположенных в России. Формально можно найти облачную модель с российским хостингом, но большинство сильных LLM такой опции не дают, а сам договор с провайдером не снимает вопрос о том, кто физически видит содержимое запросов. Отдельная история - дообучение модели на внутренних документах: даже если единичные запросы к облачному API формально не сохраняются, загрузка целого корпуса документов для тонкой настройки заметно повышает риск утечки, и в таких случаях я всегда рекомендую считать это отправкой данных третьей стороне независимо от условий договора.

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

Локальные модели против облачных: что реально тянет продакшн

Через Ollama, LM Studio или vLLM сейчас разворачиваются модели с открытыми весами: Llama 3.1, Qwen2.5, Mistral, дистилляты DeepSeek-R1, русскоязычные тюнинги вроде Saiga. На задачах вроде классификации обращений, извлечения данных из документов и ответов по внутренней базе знаний модели от 30 миллиардов параметров догоняют облачные по качеству почти вплотную. На сложном рассуждении, генерации кода и длинных цепочках инструкций разрыв с Claude или GPT‑4 остаётся заметным. Качество русского языка тоже стоит проверять отдельно: базовые версии Llama и Mistral заметно слабее на русском, чем на английском, а вот Qwen2.5 и русскоязычные тюнинги вроде Saiga держат грамматику и стиль гораздо увереннее, это я тестирую на реальных примерах документов клиента перед тем, как остановиться на модели.

Лицензии у части моделей ограничивают коммерческое использование или требуют указания источника, это стоит проверять до внедрения, а не после.

Железо: сколько видеопамяти нужно на самом деле

Требования к GPU растут не линейно, а квантизация GGUF снижает аппетит модели почти вдвое ценой небольшой просадки качества. На практике для клиники или юрфирмы с потоком в 20-40 обращений в день хватает одной видеокарты с 24 ГБ памяти.

Инференс на одном CPU через llama.cpp тоже работает, но ответ модели 7B в этом режиме занимает 20-40 секунд, для рабочего чат-бота с потоком обращений это не годится, только для теста и разовых запросов.

Локальный агент против облачного: что меняется на практике

• Приватность. Локальный агент не передаёт содержимое запросов третьей стороне, облачный обрабатывает их на серверах провайдера, обычно за пределами РФ.
• Качество на сложных задачах. Claude и GPT‑4 увереннее ведут себя на многошаговом рассуждении и коде, локальные модели 30-70B почти не уступают на классификации и RAG.
• Скорость ответа. При низкой нагрузке локальная модель на своём GPU отвечает не медленнее облака, но при параллельных запросах упирается в потолок одной видеокарты, тогда как облако масштабируется само.
• Стоимость владения. Облачный агент оплачивается по токенам и растёт вместе с нагрузкой, локальный требует разовых вложений в сервер и последующего обслуживания вне зависимости от объёма запросов.
• Обновление модели. В облаке новая версия модели появляется у вас автоматически, локальную нужно тестировать и переразворачивать самостоятельно.

Как я собираю локального агента для клиента

Стек обычно такой: сервер в российском дата-центре или на площадке клиента, Ollama или vLLM для инференса, векторная база Qdrant либо pgvector для поиска по внутренним документам, n8n для оркестрации сценария - приём обращения, поиск релевантных фрагментов, формирование ответа, запись результата в CRM. Интерфейсом для сотрудников часто ставлю Telegram-бота на aiogram, это быстрее, чем городить отдельную веб-панель, и сотрудники уже умеют пользоваться Telegram.

Контакты клиентов и результаты работы агента в такой схеме храню на серверах в РФ, а не в Google Sheets, Airtable или Notion, зарубежные облачные таблицы для персональных данных не подходят по той же 152-ФЗ, из-за которой весь проект и затевается. Обычно беру на себя разработку ИИ-интеграций под задачи бизнеса, включая схемы, где данные не выходят за периметр компании. Стоимость такой работы у меня начинается от 50 000 ₽, конкретная цифра зависит от того, разворачиваю готовый стек под RAG или пишу пайплайн с нуля под нестандартные источники данных. Перед полноценным запуском прогоняю пилот на реальных, но обезличенных документах клиента: неделю-две агент отвечает параллельно с сотрудником, я сверяю точность и только после этого подключаю его к боевому потоку обращений.

Подводные камни локального развёртывания

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

Отдельно уточняю у клиентов лицензии моделей: часть открытых весов разрешает только исследовательское использование или ограничивает коммерческое применение определённым числом пользователей. Ошибка на этом этапе выясняется обычно уже после внедрения, поэтому я проверяю лицензию до, а не после запуска. Свой сервер сам по себе не гарантирует безопасность: нужны обновления системы, ограничение доступа по ролям и отдельный контур для документов с персональными данными, иначе локальность превращается в формальность. Для клиентов, которым важна не разовая настройка, а постоянный присмотр за сервером и моделью, у меня есть техподдержка от 15 000 ₽ в месяц.

Частые вопросы

Можно ли обойтись без видеокарты?

Инференс через llama.cpp на CPU технически работает, но ответ модели 7B в таком режиме занимает 20-40 секунд. Для одиночных тестовых запросов сгодится, для рабочего чат-бота с потоком обращений нужен GPU.

Насколько локальная модель хуже Claude или GPT‑4?

На классификации, извлечении данных из документов и ответах по базе знаний разница на моделях от 32 миллиардов параметров почти не заметна. На сложном рассуждении, генерации кода и длинных цепочках инструкций облачные модели остаются увереннее.

Что делать с 152-ФЗ, если часть инфраструктуры уже в облаке?

Персональные данные нужно хранить и обрабатывать на серверах в России. Локального агента можно развернуть в российском дата-центре или на сервере в офисе компании, тогда данные физически не покидают страну и не передаются во внешний API.

Сколько занимает внедрение локального агента?

Простой RAG-бот по внутренней базе знаний на арендованном сервере с одной видеокартой я разворачиваю за 2-3 недели. Если нужна интеграция с CRM, несколько источников данных и обучение сотрудников, срок растягивается до 5-6 недель.