AI-агенты для бизнеса: где они реально экономят деньги

Слово «агент» прилипло ко всему, что связано с ИИ, а от точности определения зависят и бюджет, и ожидания. Gartner ожидает, что к концу 2026 года узкоспециализированные агенты появятся в 40% корпоративных приложений против менее 5% годом ранее: в ближайший год их будут предлагать почти все, кому вы платите за софт, — тем важнее понимать, что именно вам продают.

Разговор «нам нужен агент» превращается в смету, когда становится видно, из чего его собирают:

• Модель. Языковая модель, которая понимает запрос и решает, что делать дальше. Заменяемая часть, а не суть решения.
• Инструменты. Функции и API ваших систем, которые агент может вызвать: найти клиента, создать заявку, отправить документ, проверить остаток. Ровно это определяет, что он умеет.
• Доступ к знаниям (RAG). Поиск по вашим документам и регламентам с ответом, опирающимся на найденный источник. Механизм, который снижает вероятность выдумок и позволяет проверить ответ.
• Память. Контекст диалога и история решений по задаче.
• Оркестратор. Логика цикла: сколько шагов допустимо, когда останавливаться, когда звать человека.
• Контроль. Журнал действий, тестовая выборка, метрики качества и обязательная эскалация.

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

Подготовка знаний: где проект встаёт на две недели

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

Регламенты устарели. Инструкция от 2022 года противоречит текущей практике, а сотрудники работают по устной версии. Агент будет отвечать по написанному — то есть неправильно, и виноватым окажется ИИ.

Документы в сканах. PDF без текстового слоя нужно распознавать, таблицы из сканов теряют структуру. Это решается, но это работа, а не галочка.

Несколько версий правды. Один и тот же прайс или условия лежат в трёх файлах разных лет. Пока не назначен источник истины, поиск будет выдавать любой из них.

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

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

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

Границы стоит зафиксировать до старта, иначе они выясняются на инциденте:

• Деньги. Скидки, возвраты, платежи, изменение условий договора. Агент готовит решение, подтверждает человек.
• Права доступа. Выдача и расширение прав — не задача вероятностной системы.
• Юридические и кадровые выводы. Трактовка договоров и решения по людям остаются за специалистами.
• Необратимые действия. Всё, что нельзя откатить: удаление данных, отправка отчётности, публикация.
• Шаги, где ошибку не видно. Если неверный результат всплывёт через месяц, автоматизировать шаг агентом рано.

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

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

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

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

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

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

Порядок величин на примере поддержки. Обращение, которое оператор закрывает за 8 минут, при ставке около 700 ₽ в час стоит примерно 90 ₽. Вызовы модели на то же обращение — единицы рублей на сильной модели и десятки копеек на бюджетной. Экономика решается не ценой токенов, а тем, какую долю обращений агент закрывает сам и сколько стоит разобрать его ошибки.

Ориентиры по нашим работам: ML- и AI-разработка, включая агентов, начинается от 1,8 млн ₽, чат-бот — от 300 тыс. ₽, интеграция с внешней системой — от 150 тыс. до 1,5 млн ₽ за одну. Точная сумма зависит от числа инструментов, состояния данных и требований к контуру: смету считаем по сценарию, а оценка проекта бесплатная — опишите задачу.

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

Три вопроса, которые определяют архитектуру, и лучше задать их до выбора модели.

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

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

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

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

Без метрик агент живёт по принципу «вроде отвечает». Набор, который стоит завести с первого дня:

• Доля автономно закрытых задач — сколько дошло до результата без человека. Главная цифра экономики.
• Точность на контрольной выборке. 100–200 реальных примеров с правильными ответами, собранных до старта. Это ваш эталон на весь срок жизни агента.
• Доля эскалаций и их причины. Не ошибка, а источник улучшений: причины показывают, каких инструментов или данных не хватает.
• Стоимость задачи и время ответа — до внедрения и после, иначе эффект не доказать.

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

Агент — не проект со сдачей, а сервис, у которого есть стоимость владения. Из чего она складывается:

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

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

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

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

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

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

• 1. Неделя 1 — сценарий и выборка. Выбираем одну задачу с большим потоком, собираем контрольные примеры и договариваемся, что считается правильным результатом.
• 2. Неделя 2 — доступы и интеграции. Самая недооценённая часть: согласования и права занимают больше времени, чем разработка.
• 3. Недели 3–4 — сборка. Инструменты, поиск по документам, оркестрация, ограничения и эскалация.
• 4. Неделя 5 — проверка на выборке. Замер точности, разбор ошибок, правки промптов и инструментов.
• 5. Неделя 6 — работа на реальном потоке. Агент работает с человеком в контуре: сотрудник подтверждает результат, метрики собираются автоматически.

Смысл пилота — не демонстрация, а решение: масштабировать, доработать или закрыть. Ровно так же, как в MVP: проверяем гипотезу минимальным объёмом работ, а не строим платформу под все будущие сценарии.

Начинать с технологии, а не с задачи. «Внедрим ИИ» — не цель. Цель — закрыть 40% обращений первой линии или убрать ручной ввод счетов.

Не дать агенту инструментов. Модель без доступа к системам умеет только разговаривать, а от неё ждали действий.

Пропустить контрольную выборку. Без эталона качество обсуждают на уровне «мне показалось, стало хуже», и спор невозможно закрыть.

Забыть про эскалацию. Агент, который не умеет передать задачу человеку, в сложном случае выдаёт уверенную неправду.

Ставить ИИ на шаг, где ошибку не видно. Тихие ошибки в отчётности или расчётах дороже любой экономии на рутине.

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

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

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