AI-агент для бизнеса стоит дороже, чем “прикрутить чат”, потому что ценность появляется не в окне с моделью, а в управляемом процессе вокруг неё. Агент должен знать, какие данные можно читать, какие действия можно выполнять, какие инструменты доступны, где нужна проверка человеком, как вести логи и как оценивать качество. Если в проекте есть RAG, CRM и tool-calling, бюджет нужно считать как продуктовую интеграцию, а не как эксперимент с промптом.
Короткий ответ
Для Pena реалистичный MVP AI-агента начинается от 450 000 ₽. В эту вилку попадает один ограниченный бизнес-сценарий: например обработка заявок, подготовка черновиков ответов, поиск по базе знаний или помощь менеджеру в CRM. Если нужны несколько ролей, сложные права, интеграции с CRM, RAG по документам, evals, наблюдаемость и support после релиза, бюджет растёт итерациями. Обучение команды отдельно начинается от 90 000 ₽ в день, а инженерные доработки считаются от 4 500 ₽/час.
Почему AI-агент не равен чат-боту
Чат-бот отвечает на сообщения. AI-агент участвует в рабочем процессе: получает контекст, выбирает инструмент, обращается к данным, предлагает действие, проверяет ограничения и оставляет след в системе. Для бизнеса это принципиальная разница. Ошибка бота может быть неприятной, а ошибка агента с доступом к CRM, документам или внутренним операциям может создать финансовый, юридический или репутационный риск.
Поэтому первый бюджет уходит не только на интерфейс, но и на проектирование границ. Нужно определить роли пользователей, источники знаний, список инструментов, правила доступа, точки approval, формат логов, тестовые сценарии и fallback-поведение. Без этой инженерной оболочки агент остаётся демо, которое впечатляет на презентации, но не выдерживает production.
Из чего складывается цена MVP
Хороший MVP AI-агента не пытается автоматизировать всю компанию. Он берёт один процесс, где есть повторяемые действия, понятный владелец, измеримый результат и приемлемый риск. Например, агент может разобрать входящую заявку, найти информацию в базе знаний, подготовить карточку для менеджера и предложить следующий шаг. Уже здесь появляются интеграции, хранение истории и правила доступа.
| Компонент | Почему влияет на цену | Что проверять |
|---|---|---|
| RAG / база знаний | Нужно подготовить документы, индексы, источники и правила цитирования. | Есть ли права доступа, версии документов и понятные источники ответа. |
| Tool-calling | Модель получает возможность вызывать функции, API или внутренние действия. | Есть ли whitelist действий, параметры, валидация и запрет опасных операций. |
| CRM-интеграция | Агент должен читать и иногда обновлять рабочие сущности. | Роли, логи, поля, статусы, rollback и human approval. |
| Evals | Нужны тесты качества, чтобы не ловить регрессии руками. | Покрыты ли типовые, спорные и опасные сценарии. |
| Наблюдаемость | После запуска нужно видеть ошибки, задержки, стоимость и качество. | Логи, метрики, алерты, отчёты и владелец процесса. |
Что делает проект дороже 450 000 ₽
Минимальная стоимость возможна, когда сценарий узкий, данные подготовлены, API понятны, а действие агента не требует высокой автономии. Проект дорожает, когда агент должен работать с разными ролями, несколькими системами, документами разного качества, нестабильными правилами или высокими последствиями ошибки. Чем больше агент похож на операционного сотрудника, тем серьёзнее нужно проектировать контроль.
- несколько бизнес-сценариев вместо одного первого workflow;
- разные роли пользователей, разные права и разные источники данных;
- неподготовленная база знаний: документы без структуры, версий и владельцев;
- запись в CRM, создание задач, отправка сообщений или другие действия с последствиями;
- требование хранить audit trail: кто запросил, что предложила модель, кто подтвердил, что изменилось;
- необходимость evals, мониторинга, отчётности и SLA-подобного сопровождения.
Как Pena проектирует безопасный первый сценарий
Рабочий старт строится вокруг ограничения. Сначала выбирается процесс, где агент не должен принимать необратимые решения. Например, он готовит черновик, классифицирует заявку, собирает источники, предлагает ответ или создаёт внутреннюю карточку. Человек остаётся в approval-flow для рискованных действий, а команда получает первые данные о качестве и экономике без лишнего риска.
Дальше проект делится на контуры: интерфейс для пользователя, слой orchestration, источники знаний, registry инструментов, права доступа, логи и evals. Это похоже на продуктовую разработку: есть backlog, релиз, метрики, владельцы и поддержка. Разница в том, что модель становится частью системы, а значит её поведение нужно регулярно проверять.
Практический артефакт: brief для оценки AI-агента
Что подготовить перед оценкой бюджета
Если собрать эти вводные до первой встречи, оценка будет точнее, а команда быстрее увидит, где нужен MVP, а где достаточно обычной автоматизации.
- Опишите один процесс, который хотите улучшить: вход, выход, участники, частота, текущая боль.
- Укажите источники данных: CRM, документы, база знаний, сайт, таблицы, внутренние API.
- Разделите действия на безопасные подсказки, черновики, действия после подтверждения и запрещённые операции.
- Соберите 30-50 примеров реальных запросов или кейсов, по которым можно тестировать качество.
- Назначьте владельца процесса, который будет принимать решения о правилах, доступах и приоритетах.
- Определите метрики: скорость обработки, доля корректных черновиков, снижение ручной работы, качество ответа.
Когда агент не нужен
Иногда бизнесу не нужен AI-агент. Если процесс полностью детерминирован, правила стабильны, данные структурированы и нет языковой вариативности, обычная автоматизация будет дешевле и надёжнее. Агент полезен там, где есть неопределённость: нужно понимать текст, искать по разным источникам, составлять ответ, выбирать следующий шаг и работать с исключениями.
Здоровая оценка проекта должна честно отвечать на вопрос: где модель действительно добавляет ценность, а где её пытаются поставить ради моды. Pena обычно разделяет сценарии на три группы: обычная автоматизация, ассистент с human approval и агент с ограниченными инструментами. Такой подход помогает не переплатить за “AI”, когда нужен аккуратный workflow.
Как Pena оценивает агентский MVP до разработки
Перед стартом AI-агента Pena разбирает не “какую модель взять”, а операционный контур: кто инициирует действие, где лежат данные, какие инструменты можно вызывать, какие ошибки допустимы и кто подтверждает результат. Это сразу показывает, достаточно ли простого ассистента, нужен ли RAG, требуется ли интеграция с CRM и где граница между автоматизацией и агентом.
После этого оценка становится предметной. Если агент только готовит черновик ответа, budget и риск одни. Если он читает CRM, создаёт задачи, меняет статусы и отправляет сообщения, нужны роли, журнал событий, approval-flow, тестовые наборы и эксплуатационная поддержка. Именно эти элементы отличают production-ready MVP от красивого прототипа в чате.
Источники и связанные материалы
- OpenAI platform docs: function calling — Официальная документация о вызове инструментов моделью и структурировании действий агента.
- OpenAI platform docs: evals — Подходы к проверке качества моделей, сценариев и регрессий перед production.
- Anthropic: Building effective agents — Практический разбор agentic systems, workflow, tools и границ автономии.
- Anthropic: Writing tools for agents — Инженерные рекомендации по проектированию инструментов, которыми пользуются AI-агенты.
Оценить AI-агента
Опишите процесс, данные и желаемый результат. Pena поможет понять, нужен ли AI-агент, RAG, CRM-интеграция или обычная автоматизация.
