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

Контур агента

TL;DR

Локальный ИИ-агент — тот же контур «модель + инструменты + цикл проверки», что у любого агента, только целиком на сервере компании: без обращения к облаку вендора ни на одном шаге, включая журнал действий и память.

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

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

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

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

Внутри периметра

Локальный агент и агент у вендора решают задачу одним и тем же циклом — разница в том, кто отвечает за контур и его состояние.

Ось сравненияЛокальный агентАгент у вендора
Где хранятся данныена сервере компании, внутри периметрана стороне сервиса вендора
Кто следит за обновлениямикоманда компании сама обновляет модель и инструментыобновления встроены в сервис вендора
От чего зависит доступностьот своего железа и канала связиот доступности сервиса вендора
Кто ограничивает права инструментовинженер компании настраивает вручнуюготовые ограничения задаёт вендор

Каждая строка таблицы — отдельное решение, которое команда принимает один раз на старте, а корректирует по мере роста контура.

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

Когда он оправдан

Персональные данные клиентов, договоры с грифом конфиденциальности и доступ к внутренним системам компании без выхода наружу — три частых повода держать агента на своём сервере вместо облака вендора.

  • Персональные данные — обработка внутри периметра снимает вопрос, куда уходит запрос с данными клиента
  • Договоры и внутренние документы — контур без внешнего сервиса подходит там, где утечка формулировки дорого обходится компании
  • Связка с внутренними системами — CRM, 1С или база без внешнего доступа проще подключается к агенту на своём железе, чем к облаку стороннего вендора

Каждый из трёх поводов взвешивают вместе с ИБ-отделом, глядя на конкретные данные и систему компании, — готового универсального правила здесь нет.

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

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

Когда хватит вендора

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

Свой сервер добавляет постоянную работу команде — обновления модели, мониторинг журнала действий, ограничение прав инструментов, — и эта работа окупается там, где контур используют регулярно; на разовой задаче на неделю она остаётся лишней нагрузкой.

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

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

Такой порядок снижает риск лишней работы: контур на своём сервере команда собирает уже под проверенный сценарий, а гипотеза без проверки остаётся на стороне вендора до подтверждения пользой.

● Discovery · 1 час · бесплатно

Какой процесс компании стоит перевести на локального агента?

Прийти на Discovery →

Типичные провалы

  • Слабая модель на роли планировщика — агент теряет цель на третьем-четвёртом шаге и повторяет действия по кругу
  • Инструменты без ограничения прав — агент с полным доступом к системе меняет данные за пределами исходной задачи
  • Журнал действий отсутствует — ошибку находят по жалобе сотрудника при полном отсутствии записи в логе

Три провала объединяет одна причина — контур собрали быстро и запустили в работу до проверки на живых задачах компании; тест на полусотне реальных случаев с ошибками и вложениями остался за кадром.

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

// с чего начать

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

Пошаговую сборку агента слой за слоем — модель, промпт, инструменты, человек — разбирает статья как создать ИИ-агента с нуля, а запуск открытой модели Qwen на своём сервере, которая чаще всего ложится в основу такого контура, — статья Qwen локально: как запустить для компании. Оценку задачи и сборку контура под неё компании обсуждают на странице ИИ-агентов под ключ.

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

Чем локальный ИИ-агент отличается от агента у вендора?
Данные, инструменты и журнал действий локального агента остаются на сервере компании, а агент у вендора работает на стороне сервиса — разницу решает вопрос, где физически считается каждый шаг.
Когда компании нужен именно локальный агент?
Там, где персональные данные, договоры с грифом конфиденциальности или внутренние системы без внешнего доступа делают облако вендора неудобным вариантом.
Можно ли обойтись обычным промптом вместо агента?
Да, для разовой задачи без цепочки шагов обычный промпт или чат с моделью решает быстрее сборки целого контура.
Какая модель нужна для локального агента?
Открытая модель, способная держать план из нескольких шагов, — слабая модель на роли планировщика теряет цель уже на третьем-четвёртом шаге цикла.
Что случается, если у агента нет журнала действий?
Ошибку находят по жалобе сотрудника, потому что запись в логе отсутствует, а разбор причины превращается в реконструкцию событий по памяти команды.
С чего начать сборку локального агента в компании?
С узкой задачи на данных без грифа секретности, включённого с первого дня журнала действий и постепенного расширения набора инструментов.