Managed API или локальный ИИ-агент: как мы выбираем после сентябрьских релизов

Клиент прислал ссылку и одно предложение: «Смотрите, теперь можно взять готовый managed-агент за день. Может, нам вообще не нужен свой?» Ссылка вела на анонс OpenAI Agents API, вышедший в public beta пару дней назад. Через час пришло второе письмо — на этот раз про DeepSeek V4.1 Flash с миллионным контекстом и MoE-архитектурой, который можно поднять локально. «А может, наоборот — полностью офлайн?»

Вопрос понятный. За последние две недели вышло столько всего, что даже мы, разрабатываем ИИ-агентов каждый день, потратили вечер на разбор релизов. Managed-платформы дозрели: OpenAI, Salesforce, Cloudflare выкатили сервисы с долгой памятью и durable execution — так, чтобы агент жил днями и неделями. Одновременно DeepSeek, Cognition и Abacus.AI выложили новые open-weight модели, оптимизированные под agentic-нагрузку. А NVIDIA на IFA показала апдейты llama.cpp и vLLM, которые ускоряют локальный инференс в разы на потребительском железе.

Клиенту нужно было ответить не «что модно», а «что взять именно вам». Разберу, как мы это делаем в реальности.

Что изменилось за две недели

Раньше выбор был грубый: облачный API или собственная сборка на своих серверах с open-source моделью. Между ними — пропасть. Managed API давал скорость запуска, но забирал контроль и уводил данные в чужой периметр. Локальный агент давал контроль, но требовал команды, железа и терпения.

Сейчас пропасть сузилась с обеих сторон. С одной стороны, managed-платформы научились держать долгие сессии, обрабатывать subagents и компактить контекст без нашего участия — то есть закрывают то, что раньше приходилось писать руками. С другой стороны, локальный запуск перестал быть уделом энтузиастов: MoE-архитектуры с восемью-шестнадцатью активными миллиардами параметров при общем размере в полтриллиона работают быстрее, чем плотные модели вдвое меньше. Плюс отечественный контур подрос: GigaChat 3.5 Reasoning вышел с открытыми весами под MIT-лицензией.

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

Первый порыв — взять managed. И почему он не подошёл

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

Первая мысль — взять готовый managed-агент, накидать инструментов через MCP, за неделю собрать демо. И действительно, для прототипа это отличная идея. Мы так и предложили начать: пока идёт закупка железа, поднимем на облачном API, посмотрим на диалоги, поймём границы задачи.

Но дальше вылезло три вещи, которые перевесили удобство.

Первое — данные. В обращениях мелькали персональные данные подрядчиков, реквизиты договоров, иногда — коммерческая тайна. По внутреннему регламенту клиента такие вещи не могут покидать российский периметр. Не потому что нельзя технически, а потому что нельзя по политике безопасности, подписанной с ключевыми заказчиками. Managed-агент за рубежом отпадал сразу.

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

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

Managed отпал не потому что плохой, а потому что не совпал с профилем ответственности.

Что значит «сделать локального ИИ-агента» в 2026 году

Когда я объясняю клиентам, как сделать ИИ-агента для собственного контура, я обычно рисую четыре слоя.

Внизу — железо. Раньше сюда шло серверное оборудование с профессиональными ускорителями за большие деньги. Сейчас, после сентябрьских апдейтов инференс-движков, порог входа заметно ниже: рабочая станция с современной потребительской видеокартой уже тянет модели с активными восемью-шестнадцатью миллиардами параметров на приемлемой скорости. Для отдельных задач хватает даже мини-ПК с RTX. Это не значит «купите одну коробку и живите» — для отказоустойчивости всё равно нужны хотя бы две. Но масштаб инвестиции стал другим.

Следующий слой — модель. Тут выбор зависит от того, что важнее: рассуждение, инструменты, длина контекста, язык. Если задача — разбор длинных документов, MoE-модель со свежей архитектурой и миллионным контекстом закрывает её без ухищрений. Если задача — работа с русским регламентом и внутренней терминологией, часто выигрывает GigaChat Pro в облаке отечественного провайдера или его open-weight версия локально. Мы честно тестируем на данных клиента, а не на бенчмарках.

Третий слой — оркестрация. Здесь собственно и живёт ИИ-агент: планировщик, память, инструменты, регламенты. Мы делаем это на своём фреймворке поверх FastAPI и PostgreSQL с pgvector под память и историю. Никакой магии — просто набор проверенных кирпичей.

Четвёртый слой — интеграции через MCP-серверы. Учётная система, почта, файловое хранилище, справочники. MCP хорош тем, что не завязан на конкретную модель: сегодня инференс идёт на одной модели, завтра на другой, MCP-серверы остаются те же.

Где локальный агент выигрывает, а где — нет

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

Он проигрывает managed-варианту по скорости запуска. Первая версия на облачном API поднимается за неделю, локальная — за месяц-полтора, если начинать с нуля. Если у клиента горит квартальный план, локальный путь просто не успеет.

Он проигрывает по «свежести» модели. Managed-провайдер регулярно катит апдейты, локально их надо тестировать и накатывать самому. Пропустил релиз — сидишь на модели трёхмесячной давности, а конкуренты уже перешли на новую.

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

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

Как мы решаем в реальности

За пару лет работы с ИИ-агентами у нас сложилось простое правило, которым делимся с клиентами.

Managed берём тогда, когда данные некритичные, задача — быстро проверить гипотезу, и нам заранее известен потолок по объёму. Прототипы, внутренние помощники маркетологов, разбор публичных документов — сюда.

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

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

Клиенту, с которого начался этот текст, мы предложили именно гибрид: прототип на облачном отечественном API, чтобы за пару недель поймать реальную форму задачи, и параллельно — сборку локального контура на open-weight модели, куда мигрируем через полтора-два месяца. Первый вариант — чтобы люди начали работать сразу. Второй — чтобы через год не пришлось всё переписывать заново.

Что бы я спросил у себя на месте заказчика

Прежде чем выбирать между managed и локальным ИИ-агентом, стоит честно ответить на три вопроса.

Куда попадут данные, которые обработает агент, и переживёт ли компания, если завтра эти данные окажутся не там, где должны? Сколько мы готовы платить за агента через год, когда он реально втянет всю компанию, а не только пилотный отдел? Готовы ли мы держать команду, которая будет следить за инференсом, обновлениями и MCP-серверами — или предпочтём отдать это провайдеру?

Если ответы указывают на облако — берите managed и не переживайте. Если хотя бы на один вопрос ответ «нельзя» или «дорого» — стройте локальное решение. Осень 2026 года впервые сделала оба пути реалистичными для среднего бизнеса, а не только для гигантов. Дальше — вопрос вашего профиля, а не моды.