Выбор определяется не бюджетом, а четырьмя вопросами: какие системы нужно подключить, где обрабатываются данные, насколько нестандартна логика и что будет при росте объёма. Платформа выигрывает на старте и на типовых сценариях; разработка окупается там, где платформа упирается в потолок. Разумный порядок — начать с платформы и переходить к разработке по конкретному ограничению, а не по ощущению, что «своё солиднее».
Обзор конкретных инструментов — в статье «Платформы для создания ИИ-агентов без кода»; здесь — критерии выбора.
Пять критериев
1. Интеграции
Главный практический вопрос. Если нужные системы есть среди готовых коннекторов платформы — это экономия недель. Если нет, придётся писать интеграцию самому, и часть преимущества исчезает.
Проверять нужно не наличие коннектора, а его полноту: коннектор к CRM может уметь читать сделки и не уметь менять статус так, как нужно вам.
2. Где обрабатываются данные
Если в процессе есть персональные данные, вопрос перестаёт быть техническим. Многие платформы обрабатывают данные вне России, и это определяет выбор независимо от удобства — см. «152-ФЗ и нейросети».
Уточнять следует не только где стоит сама платформа, но и какую модель она вызывает: цепочка может уходить дальше, чем кажется.
3. Сложность логики
Платформы хорошо справляются с линейными сценариями и простыми ветвлениями. Плохо — с нестандартными правилами, сложной обработкой ошибок и специфичными проверками.
Признак приближения к потолку: обходные решения начинают занимать больше места, чем сама логика.
4. Объём
При малом потоке разница в стоимости обращения незаметна. При большом наценка платформы становится заметной статьёй, а лимиты тарифов — ограничением.
5. Кто будет сопровождать
Платформа позволяет менять сценарий силами сотрудника без разработчика — это реальное преимущество для процессов, которые часто меняются. Разработка требует исполнителя при каждом изменении.
Сравнение
| Платформа | Разработка | |
|---|---|---|
| Срок запуска | дни-недели | месяцы |
| Стоимость входа | низкая | высокая |
| Стоимость на большом объёме | наценка платформы | только модель и инфраструктура |
| Нестандартная логика | ограничена | без ограничений |
| Интеграции | готовые, если есть нужные | любые, но пишутся |
| Обработка данных | по правилам платформы | как решите |
| Изменения | силами сотрудника | нужен разработчик |
| Зависимость от поставщика | высокая | низкая |
Скрытые ограничения платформ
О них редко пишут в описаниях, а сталкиваются почти все:
- Неполные коннекторы. Есть подключение к системе, но нет нужной операции.
- Ограничения на длину шага или число итераций — упираются именно агентские сценарии с непредсказуемым числом шагов.
- Трудно отладить. Журнал показывает результат, но не то, почему модель выбрала этот инструмент.
- Слабый контроль расходов. Лимит на задачу с автоматической остановкой есть не везде, а без него зацикливание бьёт по счёту — см. «Зацикливание ИИ-агента».
- Ограниченные права. Разграничить доступ агента на уровне отдельных операций удаётся не всегда.
- Смена тарифов. Условия меняются, и заложенная экономика перестаёт сходиться.
Последние два пункта важнее прочих: они касаются безопасности и предсказуемости, а не удобства.
Промежуточный вариант
Часто оптимально не «или — или», а комбинация: платформа для оркестрации и своя реализация критичных частей.
Например, сценарий собран в конструкторе, а обращения к учётной системе идут через собственный сервис-посредник, где живут проверки, лимиты и права. Платформа отвечает за последовательность шагов, ваш код — за безопасность действий.
Такой подход сохраняет скорость изменений и снимает главный риск платформ — невозможность нормально ограничить полномочия агента.
Когда переходить на разработку
Не «когда вырастем», а по конкретному признаку:
- нужной интеграции нет и не будет;
- требования к данным не выполняются платформой;
- обходные решения стали сложнее прямой реализации;
- стоимость на текущем объёме превысила разработку с окупаемостью в разумный срок;
- нужны ограничения полномочий, которых платформа не даёт.
Переход дешевле, чем кажется, если на платформе уже отработан сценарий: логика известна, правила маршрутизации выписаны, ошибки видны. Заново проектировать не придётся — это и есть главный аргумент за то, чтобы начинать с платформы.
Расчёт точки перехода
Универсального ответа «до какого объёма платформа» не существует, но метод расчёта простой. Числа условные — подставьте свои тарифы.
Что нужно знать:
| Величина | Обозначение |
|---|---|
| Задач в месяц | N |
| Наценка платформы за задачу | П |
| Стоимость своей разработки | Р |
| Ежемесячное сопровождение своего решения | С |
| Срок, за который решение должно окупиться | Т месяцев |
Условие перехода:
```
N × П × Т > Р + С × Т
```
Слева — переплата платформе за срок Т. Справа — стоимость своего решения за тот же срок.
Пример. Пусть Р = 600 000 ₽, С = 20 000 ₽/мес, П = 12 ₽ за задачу, Т = 24 месяца.
```
600 000 + 20 000 × 24 = 1 080 000 ₽ — своё решение за два года
N × 12 × 24 = 288 × N — платформа за два года
288 × N > 1 080 000
N > 3 750 задач в месяц
```
При потоке меньше 3 750 задач в месяц платформа за два года обходится дешевле. Выше — окупается разработка.
Что этот расчёт не учитывает, а учесть надо:
- скорость запуска. Платформа даёт результат через недели, разработка — через месяцы. Полгода работающего решения — это полгода эффекта, которых иначе не было бы;
- риск не подойти. Если сценарий на платформе не взлетит, вы потеряете недели, а не полугодовой бюджет;
- стоимость изменений. На платформе сценарий правит сотрудник, в своём решении — разработчик. При частых изменениях это заметная статья в пользу платформы;
- нефинансовые ограничения. Требования к обработке данных или невозможность разграничить права могут исключить платформу независимо от арифметики.
Практический вывод. Расчёт почти всегда показывает, что на старте платформа выгоднее, — и это верно. Но он же объясняет, почему переход не стоит откладывать бесконечно: при растущем потоке переплата накапливается тихо, а решение о разработке принимается тем труднее, чем дольше работает привычное.
Правильный момент для пересчёта — когда поток вырос вдвое относительно того, при котором платформу выбирали.
Частые вопросы
Что дешевле — платформа или своя разработка?
На старте и малом объёме — платформа, причём с большим отрывом. При росте потока наценка за обращения накапливается, и в какой-то момент разработка окупается. Точка перехода считается под конкретный объём: универсального ответа нет, но считать нужно с учётом сопровождения, а не только стоимости запуска.
Можно ли сделать серьёзного агента на конструкторе?
Для типовых сценариев с готовыми интеграциями — да, и это рабочее решение. Ограничения появляются на нестандартной логике, тонком разграничении прав и контроле расходов. Признак потолка: обходные решения занимают больше места, чем полезная логика.
Что делать, если у платформы нет нужной интеграции?
Проверить, есть ли универсальный способ вызвать внешний сервис — тогда интеграцию можно написать самому и подключить. Если и этого нет, платформа не подходит для сценария. Комбинированный вариант — оркестрация в конструкторе, а обращения к системе через собственный сервис-посредник.
Насколько сложно перейти с платформы на свою разработку?
Проще, чем начинать с нуля, если сценарий уже отработан: логика, правила и типичные ошибки известны, проектировать заново не нужно. Переписывается техническая часть, а самое трудоёмкое — выяснение реальных правил процесса — уже сделано. Это довод в пользу того, чтобы начинать именно с платформы.
Безопасно ли отдавать данные платформе?
Зависит от данных и от того, где они обрабатываются. Для персональных данных вопрос регулируется законом, и уточнять нужно всю цепочку: где стоит платформа и какую модель она вызывает. Ответственность за передачу несёт ваша компания, а не поставщик, поэтому решение принимается до запуска.
Что дальше
Обзор конкретных инструментов — «Платформы для создания ИИ-агентов без кода». Что входит в собственную разработку — «Разработка ИИ-агента: этапы и стоимость». Ограничения, которые нужно проверить у платформы, — «Ограничение действий». Как считать экономику — «Стоимость эксплуатации ИИ-агента».
Выбор между платформой и разработкой под конкретный процесс — часть аудита процессов перед разработкой и внедрением ИИ-агента.