Один агент - это демонстрация. Чтобы в компании работали десятки агентов, нужна обвязка: доступ к данным и системам, единые правила, проверка качества, наблюдение и владелец у каждого сценария. Ниже - из чего состоит эта платформа, в каком порядке её собирают, четыре сценария под разные ограничения и ошибки, на которых чаще всего теряют год.
Собрать агента, который впечатляет на демонстрации, сегодня может небольшая команда за неделю. Дальше начинается разрыв: в промышленной эксплуатации нужны доступы, свежие данные, проверка качества, лимиты и ответственный. Именно на этом участке проекты и останавливаются.
88%
пилотов ИИ-агентов не доходят до промышленной эксплуатации
сводка трёх исследований 2026 года
40%+
агентских проектов будут закрыты к 2027 году
прогноз Gartner
21%
компаний имеют зрелую модель управления автономными агентами
данные 2026 года
42%
компаний строят агентов без сформулированной стратегии
данные 2026 года
Что называют главными блокерами сами руководители:
64%Нечем измерить качество
Нет проверочного набора и метрик - решение о запуске принимается по ощущениям от демонстрации.
57%Трение с управлением и ИБ
Правила доступа агентов не описаны заранее, согласование начинается после того, как всё уже собрано.
51%Надёжность в проде
На демо сценарий один, в жизни - десятки краевых случаев, на которых агент выдаёт правдоподобную ошибку.
Универсальный подход
Шесть слоёв и три сквозных контура
Набор слоёв одинаков для компании любого размера и любой отрасли - меняется только то, где каждый слой физически живёт и насколько он развит. Порядок сборки идёт снизу: данные и доступы, потом шлюзы, потом оркестрация, и только в конце интерфейсы.
01
Каналы и рабочие места
Где сотрудник встречается с агентом: корпоративный чат, среда разработки, портал, телефония, кнопка внутри учётной системы.
Один агент - несколько каналов. Логика не должна дублироваться под каждый интерфейс.
Канал определяет ожидания по скорости: в чате ждут секунды, в ночном пакетном разборе - нет.
Встраивание в существующую систему даёт охват выше, чем отдельное приложение, куда надо заходить.
Типичная ошибка: под каждую задачу делают отдельного чат-бота, и через год их двадцать, у каждого своя база знаний.
02
Оркестрация агентов
Слой, который превращает вызов модели в рабочий процесс: последовательность шагов, память, передача задачи другому агенту, точки, где нужен человек.
Сценарий и шаги: что агент делает по порядку и что считается завершением.
Состояние: что помнится между шагами и между запусками, где это хранится.
Передача между агентами: узкие специалисты вместо одного универсального.
Человек в контуре: где обязательное подтверждение перед действием с последствиями.
Здесь же решается, автономен агент или предлагает - и это решение принимает бизнес, а не разработчик.
03
Шлюз инструментов
Единая точка, через которую агент получает доступ к системам компании. Промышленный стандарт подключения инструментов - MCP; поверх него ставится корпоративный шлюз.
Реестр: какие инструменты вообще есть и кто их владелец.
Права по минимуму: агент видит только те инструменты, которые нужны его задаче.
Аудит: каждый вызов записан - кто, что, когда, с каким результатом.
Изоляция: инструмент, который может изменить данные, отделён от того, который только читает.
Сам протокол не навязывает ограничение прав на старте сессии - это закрывается на уровне шлюза.
04
Шлюз моделей
Единый API поверх всех моделей: своих в контуре и внешних. Приложения не знают, какая модель отвечает, и не переписываются при её смене.
Маршрутизация: простое - в лёгкую и дешёвую модель, сложное - в тяжёлую.
Квоты и лимиты по командам, проектам и людям.
Учёт токенов и стоимости - основа для внутреннего биллинга.
Фолбэк: если узел или провайдер недоступен, запрос уходит на резерв.
Совместимость с распространённым форматом API - причина, по которой существующие сервисы подключаются без переписывания кода.
05
Модели
Свои модели в контуре компании, внешние API там, где класс данных это позволяет, или комбинация. Это отдельная большая тема - ей посвящена соседняя страница.
Выбор модели идёт от задачи и класса данных, а не наоборот.
Массовый поток обычно закрывается моделью среднего размера, а не флагманом.
Дообучение под узкий сценарий часто дешевле, чем переход на модель большего размера.
Тяжёлое железо покупается под подтверждённую нагрузку, а не под гипотезу.
06
Данные и знания
То, из чего агент берёт факты: документы и регламенты, поиск по смыслу, связи между сущностями, живые данные из систем по запросу.
Поиск по смыслу вместо поиска по точному слову - базовый механизм для работы с документами.
Права на данные наследуются: агент не должен показывать сотруднику то, чего он не увидел бы сам.
Свежесть: часть данных берётся из систем в момент запроса, а не из индекса недельной давности.
Качество источника важнее размера модели: на противоречивых регламентах ошибётся любая.
Это самый недооценённый слой. Работы по нему обычно больше, чем по всем остальным вместе.
Три контура, которые пронизывают всё
Их нельзя доделать потом: наблюдаемость, разграничение прав и учёт стоимости закладываются вместе с первым агентом, иначе через полгода никто не сможет ответить на вопросы «почему он так ответил», «кто ему это разрешил» и «сколько это стоит».
Наблюдаемость и оценка качества
Каждый шаг агента записан: какой запрос, какие инструменты вызваны, что вернулось, сколько стоило. Поверх - регулярная проверка качества на собственном наборе примеров.
Трассы всех шагов, а не только финальный ответ - агенты ломаются в середине цепочки.
Свой проверочный набор с эталонными ответами, собранный вместе с экспертами подразделения.
Регрессия перед каждым релизом: новая версия не должна ухудшать то, что уже работало.
Отраслевой стандарт разметки телеметрии позволяет не привязываться к одному вендору мониторинга.
Безопасность и соответствие
Агент - это учётная запись, которая ходит в системы и что-то в них делает. К ней применимы те же правила, что к сотруднику, плюс несколько специфических.
Отдельная личность агента: не работает под учёткой сотрудника или под общим админом.
Класс данных для каждой задачи определяет, куда её вообще можно отправлять.
Модель угроз агентной системы: подмена инструкций через данные, доступ к лишним инструментам, утечка через логи.
Стоп-кран: любой агент выключается за минуту, и это проверено учениями, а не описано в регламенте.
Экономика
Расход на агентов растёт быстрее ожиданий: длинные цепочки шагов, растущий контекст, повторные вызовы. Без учёта это выясняется постфактум.
Лимиты на команду, сервис и сценарий - жёсткие, а не рекомендательные.
Стоимость одной обработанной задачи как рабочая метрика, понятная финансам.
Сравнение стоимости своего токена и внешнего API на реальном профиле нагрузки.
Отключение сценариев, где стоимость обработки выше ценности результата.
Порядок сборки
Сначала спрос, потом инфраструктура
Самая дорогая ошибка - построить платформу раньше, чем появился поток задач. Рабочая последовательность обратная: сначала руководители на практике понимают, что умеет ИИ, потом собирается портфель задач с владельцами, и под него растёт инфраструктура.
Роадмап на 24 месяца
Ориентир для компании, которая начинает с нуля. Сроки сдвигаются согласованиями и закупками, но порядок этапов остаётся.
Кто это делает
Модель, которая чаще других доживает до результата: небольшая центральная команда держит платформу и правила, а агентов собирают сами подразделения. Полностью централизованная разработка упирается в пропускную способность центра, полностью самостоятельная - в зоопарк решений.
01
Собрать портфель задач
Интервью с подразделениями: что повторяется каждую неделю, где теряется время, какие данные участвуют. На выходе - список задач с владельцами и приоритетом, а не список технологий.
02
Определить классы данных
Какие данные можно отправлять во внешние сервисы, какие - только в свой контур, какие вообще нельзя обрабатывать автоматически. Это решение определяет всю архитектуру и принимается вместе с безопасностью.
03
Поставить шлюз и учёт
Единая точка доступа к моделям с квотами и учётом токенов. Появляется до первого агента: иначе через полгода никто не сможет ответить, сколько компания тратит и кто именно тратит.
04
Сделать два-три агента до конца
Не десять пилотов, а два-три сценария, доведённых до промышленной эксплуатации с проверкой качества и владельцем. Они дают и результат, и понимание реальной трудоёмкости.
05
Открыть платформу подразделениям
Самообслуживание, шаблоны, обучение и внутренние проводники. С этого момента охват растёт без пропорционального роста центральной команды.
Четыре сценария
Одна логика, четыре способа развернуть
Слои платформы одинаковы. Отличается граница: что живёт в контуре компании, что снаружи и кто собирает агентов. Выбор определяется классом данных, требованиями безопасности и тем, насколько быстро нужен первый результат.
Сценарий A
Полностью в своём контуре
Всё живёт внутри компании: модели, шлюзы, данные, инструменты. Внешние сервисы не используются, возможен режим без выхода в интернет.
Комусубъекты критической инфраструктуры, оборонные и государственные заказчики, компании с данными, которые нельзя выносить по закону или по внутренней политике
Что нужноGPU-серверы, команда эксплуатации, процедура внесения открытого софта в контур, аттестация
Срок до первого агентаот 4 до 9 месяцев - основное время уходит на закупку железа и согласования, а не на разработку
Порядок бюджетакапитальные затраты от десятков до сотен миллионов рублей плюс постоянная команда
Рискжелезо покупается до того, как доказан спрос; санкционные ограничения на поставку и сроки
Не подходит, если задачи не требуют изоляции: получится дорогая инфраструктура под задачи, которые решались бы за недели.
Сценарий B
Гибрид: контур плюс внешние сервисы
Шлюзы, данные и чувствительные сценарии - внутри. Массовые задачи с обезличенными данными уходят во внешние модели. Маршрут выбирается по классу данных автоматически.
Комубольшинство крупных компаний: часть данных чувствительна, часть - нет
Что нужноклассификация данных, шлюз с маршрутизацией, договор с внешним провайдером
Срок до первого агента6-10 недель на задачах с открытыми данными
Порядок бюджетаначинается с операционных расходов, капитальные появляются под доказанный поток
Рискбез строгой маршрутизации чувствительные данные однажды уйдут наружу по недосмотру
Рабочий вариант по умолчанию: даёт скорость на старте и оставляет путь к полной изоляции для отдельных сценариев.
Сценарий C
На облаке российского провайдера
Модели, шлюзы и часть инструментов - управляемые сервисы провайдера в российской юрисдикции. Данные компании остаются в её собственных хранилищах и подключаются к сервисам.
Комукомпаниям без жёстких требований изоляции, которым нужен результат в этом квартале
Что нужнодоговор, разграничение доступа, правила работы с данными
Срок до первого агента3-6 недель
Порядок бюджетатолько операционные расходы, растут вместе с нагрузкой
Рискпривязка к экосистеме провайдера и его релизному циклу; стоимость на больших объёмах
Хорош как первая фаза: на нём проверяется спрос, а потом принимается решение о переносе внутрь.
Сценарий D
Федеративный: платформа как правила
Центр не строит агентов. Он даёт шлюз, доступы, проверку качества и стандарты, а подразделения собирают агентов сами - в том числе визуальными конструкторами.
Комухолдингам и компаниям с сильными самостоятельными подразделениями
Что нужношлюз с квотами, реестр агентов, обучение и внутренние проводники в каждом подразделении
Срок до первого агентанедели - первые агенты появляются там, где уже есть энтузиасты
Порядок бюджетаневысокий вход, расходы размазаны по подразделениям
Рискзоопарк решений и дублирование, если центр не держит стандарты и реестр
Обычно это не альтернатива, а следующая фаза: центр строит платформу, а затем открывает её подразделениям.
Соседняя тема
Внутренняя модель - один из слоёв
Своя модель в контуре компании часто обсуждается как отдельный проект. На деле это один из слоёв платформы - тот, который отвечает на вопрос «где выполняется вычисление». Ему посвящена отдельная страница: расчёт мощностей, варианты размещения, порядок проекта и кейсы.
Своя ИИ-модель внутри контура компании
Когда перенос внутрь оправдан, сколько нужно видеокарт, как проходит проверка безопасности и что это даёт в деньгах. С кейсами и цифрами по проектам.
Все они встречаются в концепциях, написанных сильными инженерами. Проблема не в квалификации, а в том, что документ отвечает на вопрос «как построить», не ответив на вопросы «зачем», «за сколько» и «кто отвечает».
Каталог технологий вместо выбора
В концепции перечислены четыре движка, шесть баз данных и четыре визуальных конструктора. Каждый компонент нужно обновлять, чинить и защищать - командой из пяти человек это не эксплуатируется. На старте достаточно одного движка, одной базы с векторным поиском и одного конструктора.
Железо под несуществующие задачи
Кластер под модели на сотни миллиардов параметров при профиле задач, который закрывается моделями среднего размера. Расчёт мощностей делается от нагрузки: сколько пользователей, сколько запросов, какой длины документы. Первая фаза почти всегда живёт на том, что уже стоит.
Нет проверки качества
Решение о запуске принимается по демонстрации на трёх удачных примерах. В работе с договорами или обращениями клиентов цена ошибки измеряется деньгами и репутацией. Нужен набор эталонных примеров, метрика и регресс перед каждым обновлением.
Интеграции недооценены
Почти любой полезный агент - это интеграция с существующими системами: форматы, права, владельцы, скорость ответа. На эту часть уходит основная доля трудозатрат, и именно она обычно не спроектирована, когда архитектура уже нарисована.
Аргумент «технически невозможно» вместо честного требования
Формулировка «на готовых платформах это невозможно» разбивается первым же грамотным пресейлом, и вместе с ней рушится доверие ко всему документу. Честный аргумент звучит иначе: такие-то задачи не проходят по требованиям безопасности, вот по каким именно пунктам.
Нет владельца и нет ворот
Если у агента нет владельца со стороны бизнеса, он превращается в вечный пилот. Ворота - это заранее оговорённые точки, где проект можно закрыть без потери лица: после прототипа, после проверки качества, после трёх месяцев эксплуатации.
Платформа строится раньше спроса
Порядок, который работает: сначала руководители на практике понимают, что умеет ИИ, потом собирается приоритизированный портфель задач с владельцами, и только потом под этот портфель строится платформа. В обратном порядке получается инфраструктура, которую некому загрузить.
Частые вопросы
Что спрашивают до старта
Короткие ответы на вопросы, которые возникают на первой встрече.
Нет. Она начинается с портфеля задач и классов данных. Технологический стек - следствие: под задачи с открытыми данными и потоком в сотни запросов в день нужна одна конфигурация, под изолированный контур с документами ограниченного доступа - совсем другая. Выбор стека до инвентаризации задач приводит к инфраструктуре, которую нечем загрузить.
Не обязательно и не всегда сразу. Своя модель в контуре нужна, когда данные нельзя выносить наружу или когда постоянный поток запросов делает внешний API дороже собственного железа. В остальных случаях разумнее начать с внешних сервисов и перенести внутрь то, что этого действительно требует. Подробно этот выбор разобран на соседней странице.
На старте достаточно небольшой центральной группы: инженер платформы, инженер по данным, специалист по безопасности и владелец направления. Дальше рост идёт не за счёт центральной команды, а за счёт подразделений, которые собирают агентов сами на готовой платформе. Полный стек из двух десятков компонентов пятью людьми не эксплуатируется - это отдельный повод сокращать стек.
Да, но как часть платформы, а не вместо неё. Конструктор закрывает быстрые сценарии и позволяет подразделениям проверять гипотезы без разработчиков. Всё, что дожило до промышленной нагрузки, обычно переезжает в код. Важно, чтобы конструктор ходил в модели и инструменты через общий шлюз, а не в обход него.
По заранее собранному набору примеров с эталонными ответами и по метрикам эксплуатации: доля задач, доведённых до конца без человека, доля возвратов на доработку, стоимость обработки одной задачи, время ответа. Набор примеров собирается вместе с экспертами подразделения до запуска, а не после первых жалоб.
Первые работающие агенты появляются через 6-10 недель, если не начинать с закупки железа. Полноценная платформа с самообслуживанием, реестром агентов и проверкой качества - это 12-18 месяцев поэтапной работы. Сроки растягиваются согласованиями: проверка безопасности в крупной компании занимает недели и месяцы, и её закладывают в план заранее.
Нет. Вендорская платформа закрывает часть слоёв - обычно модели, оркестрацию и конструктор. Остаются классы данных, интеграции с вашими системами, проверка качества, реестр агентов, лимиты и обучение людей. Практика показывает, что именно эта часть определяет, доедут пилоты до эксплуатации или нет.
На первой встрече обсудим задачи подразделений, ограничения безопасности и то, что уже есть. По итогам скажем, какой сценарий вам подходит и с чего начинать, чтобы первые агенты появились в этом квартале.