RFP на агентную платформу: что спросить у вендора

Компании закупают платформы для ИИ-агентов — систем, где модель не просто отвечает на вопрос, а вызывает инструменты, ходит в базы данных, выполняет цепочки действий и доводит задачу до результата. В 2024–2025 годах агентные фреймворки и managed-платформы (LangChain/LangGraph, Microsoft Copilot Studio, Google Vertex AI Agent Builder, OpenAI Assistants и десятки нишевых продуктов) стали отдельной строкой в ИТ-бюджете. Проблема в том, что RFP* под них часто копируют из закупки обычного SaaS — и упускают три вещи, которые ломают проект: непредсказуемость стоимости токенов, отсутствие контроля над действиями агента и невозможность воспроизвести результат демо в реальных данных.

Почему стандартный RFP здесь не работает

Классический RFP на софт спрашивает про функции, SLA и цену лицензии. С агентной платформой этих вопросов мало по трём причинам.

Во-первых, стоимость непредсказуема. Агент, который на демо решает задачу за 3 вызова модели, в проде на грязных данных может уйти в цикл из 40 вызовов. Если платформа тарифицируется по токенам или по вызовам, счёт в конце месяца удивит.

Во-вторых, агент действует. Он не выдаёт текст, а нажимает кнопки: создаёт заявки, отправляет письма, меняет записи в CRM. Ошибка стоит не «неверного ответа», а реального действия, которое придётся откатывать.

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

Главный критерий в RFP на агентную платформу — не «умеет ли она», а «что происходит, когда агент ошибается, и кто за это платит».

Блоки, которые обязаны быть в RFP

1. Модель ценообразования и потолок расходов

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

• Тарификация: подписка, за вызов, за токен или гибрид;
• наличие ограничения на число итераций агента в одной задаче;
• алерты и автоостановка при превышении дневного/месячного бюджета;
• кто несёт стоимость токенов базовой модели — вы или вендор.

2. Контроль над действиями и человек в цикле

Агент, который может отправить платёж или удалить запись, должен уметь спросить разрешение. Проверьте, поддерживает ли платформа режим human-in-the-loop** с явным подтверждением перед необратимыми действиями, и на каком уровне гранулярности это настраивается — на весь агент или на конкретный инструмент.

3. Наблюдаемость и воспроизводимость

Без логов каждого шага — какой инструмент вызван, с какими аргументами, что вернул — отладить агента невозможно. Спрашивайте про трассировку (tracing) полного маршрута выполнения, про экспорт этих логов в вашу систему мониторинга и про возможность повторить прогон на тех же входных данных.

4. Развёртывание и данные

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

5. Интеграции и запирание

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

Сравнение подходов на рынке

Платформы делятся на три группы: managed от гиперскейлеров, открытые фреймворки и нишевые low-code продукты. У каждой — свой профиль рисков. Данные ниже актуальны на конец 2025 года, доступность и условия сверяйте на официальных страницах продуктов.

Кому это пригодится и кому нет

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

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

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

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

Как построить пилот перед закупкой

1. Выберите один реальный сценарий с измеримым результатом — например, разбор входящих заявок с точностью, которую вы уже знаете по ручной работе.
2. Дайте вендору ваши данные, а не его демо-набор — с типичным мусором и краевыми случаями.
3. Зафиксируйте метрики: доля задач, доведённых до конца без вмешательства человека, средняя стоимость одной задачи, время отклика.
4. Прогоните нагрузку хотя бы на порядок выше демо и посмотрите на счёт за токены.
5. Специально сломайте сценарий — подайте некорректный ввод и проверьте, остановится агент или начнёт действовать наугад.

Результаты пилота впишите в RFP как приёмочные критерии. Тогда вы покупаете не презентацию, а измеренный результат на своих данных.

* RFP (Request for Proposal) — запрос предложений: документ, где заказчик описывает требования, а поставщики отвечают, как и за сколько они их закроют.

** Human-in-the-loop — режим, при котором система на определённых шагах останавливается и запрашивает подтверждение человека, прежде чем выполнить действие.

*** RAG (Retrieval-Augmented Generation) — подход, при котором модель перед ответом ищет релевантные фрагменты в вашей базе и отвечает на их основе, а не только по памяти обучения.