Готовые ИИ-агенты: что работает из России

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

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

Проверка, с которой стоит начинать

Прежде чем сравнивать возможности, стоит выяснить простую вещь — отвечает ли сервис на запросы из России.

Мы проверили это с сервера в Москве 24 августа 2026 года. Результат показателен: платформа для разработчиков OpenAI на запрос с российского адреса возвращает ошибку доступа. Не «медленно работает» и не «нужна регистрация» — просто отказ.

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

• зависимость от посредника, который может исчезнуть;
• дополнительное звено, через которое идут данные ваших клиентов;
• невозможность заключить договор и предъявить претензию;
• оплату через третьи руки с непредсказуемым курсом и комиссией.

Для эксперимента это терпимо. Для системы, от которой зависят заявки, — нет.

Три группы платформ

Разложим по доступности, а не по популярности.

Дальше разберём каждую группу: что она даёт, чего стоит и кому подходит.

Группа 1. Зарубежные платформы

Самые известные и самые обсуждаемые. Именно про них пишут обзоры и снимают ролики.

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

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

Что происходит с запросом через посредника

Ваша системаЗапрос с данными клиента

ПосредникВидит запрос целиком

Зарубежный сервисОбрабатывает

Ответ обратноЧерез того же посредника

Когда это оправдано: исследования, эксперименты, задачи без персональных данных, разовые расчёты. Когда важна максимальная сила модели и не важна непрерывность.

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

Группа 2. Российские облачные платформы

Здесь набор возможностей скромнее, зато нет вопросов с доступом.

Что они дают:

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

Что проверить перед выбором. Не «есть ли у них агенты», а конкретные вещи, которые определяют, заработает ли ваша задача.

Что выяснить до начала

1. 1
   Есть ли вызов инструментовБез него агент не сможет действовать в ваших системах
2. 2
   Какой размер контекстаСколько документов поместится в один запрос
3. 3
   Как считается оплатаПо токенам, по запросам или подписка
4. 4
   Что с хранением данныхСколько живут ваши запросы и кто их видит
5. 5
   Есть ли ограничения по скоростиСколько запросов в секунду выдержит

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

Группа 3. Открытые решения на своём сервере

Третий путь: платформа и модель разворачиваются на вашем железе.

Что это даёт. Данные не покидают контур, нет зависимости от чужого сервиса, нет счёта за каждый запрос.

Чего стоит. Железо, обслуживание и качество моделей, которое пока уступает старшим облачным. Подробный разбор — в статье про локального ИИ-агента.

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

Сравнение по тому, что действительно решает

Готовая платформаБыстрее начать

• Каркас уже есть
• Первый агент за дни
• Логика в их терминах
• Данные у поставщика
• Зависимость от их развития

Своя разработкаБольше свободы

• Любая логика и интеграции
• Код и данные ваши
• Дольше и дороже на старте
• Нужен тот, кто поддержит
• Не зависит от чужих решений

Что вообще называют «платформой для агентов»

Под одним словом продают четыре разные вещи, и это первая причина путаницы при выборе. Отдельно стоит держать в голове, что агентами называют и инструменты разработчиков — те, что пишут код; это соседняя тема со своими правилами, разобранная в статье про ИИ-агентов для программирования.

Конструктор даёт результат за вечер, но упирается в свою логику. Где именно — разобрано в статье про то, где у конструктора потолок.

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

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

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

Российские облачные: на что смотреть

Раз это основной работающий вариант, разберём подробнее, чем они отличаются друг от друга.

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

Размер контекста. Определяет, сколько документов поместится в один запрос. Для агента с базой знаний это критично: маленький контекст означает, что придётся отдавать модели меньше найденных фрагментов.

Вызов инструментов. Уже упоминали, но повторим: без него агент не действует, а только разговаривает.

Скорость ответа. Для переписки терпимо почти всё, для голоса — нет. Если планируете звонки, проверять надо заранее.

Ограничения по частоте. Сколько запросов в секунду разрешено. На потоке в сотни диалогов это упирается быстрее, чем кажется.

Условия по данным. Сколько хранятся запросы, используются ли они для обучения, есть ли режим, где не хранятся вовсе.

Как проверять кандидата за час

1. 1
   Открыть документацию с российского адресаБуквально: открывается ли
2. 2
   Найти раздел про вызов функцийЕсли его нет — это не платформа для агентов
3. 3
   Посмотреть тарифы и лимитыЦена за токены, ограничения по частоте
4. 4
   Прочитать условия по даннымХранение, обучение, удаление
5. 5
   Прогнать пять своих задачНа пробном доступе, до всяких решений

Привязка к платформе: чем это грозит

Тема, которую не поднимают продавцы, а она определяет долгосрочные расходы.

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

Что остаётся вашим при любом раскладе:

• сами документы и база знаний в исходном виде;
• описания процессов и критериев, которые вы формализовали;
• накопленные данные о том, что клиенты спрашивают.

Что теряется при переезде:

• настроенные сценарии в формате платформы;
• интеграции, собранные их средствами;
• накопленная история диалогов, если её нельзя выгрузить.

Снижаем привязкуСтоит делать сразу

• База знаний хранится у вас в исходном виде
• Логика описана словами, а не только в интерфейсе
• История диалогов выгружается регулярно
• Интеграции по возможности на своей стороне

Усиливаем привязкуТак делать не надо

• Единственная копия базы — внутри платформы
• Логика существует только в виде схемы
• Данные накапливаются и не выгружаются
• Всё завязано на их коннекторы

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

Что делать, если платформа закрылась или подорожала

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

План на этот случай

1. 1
   Держать копию базы знанийВ исходных файлах, а не только внутри сервиса
2. 2
   Выгружать историюРегулярно, автоматически
3. 3
   Описывать логику текстомЧтобы её можно было воспроизвести где угодно
4. 4
   Знать запасной вариантХотя бы на уровне «куда переедем»
5. 5
   Разделять слоиИнтеграции со своими системами — на вашей стороне

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

Что на самом деле означает «бесплатный ИИ-агент»

Бесплатные агенты — то, что в этой теме ищут чаще всего. Разберём честно, что за этим стоит.

Бесплатно попробовать — реально. У платформ есть стартовые лимиты, у открытых моделей нет платы за сами веса, у конструкторов есть бесплатные тарифы. Собрать первого агента и посмотреть, как он работает, действительно можно без денег.

Бесплатно работать на клиентах — нет. И вот где именно заканчивается бесплатное:

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

Что должно быть у платформы, чтобы на ней делать агента

Список требований, по которому стоит сверять любое решение — независимо от того, кто его делает.

Обязательный минимум

1. 1
   Вызов инструментовМодель должна уметь запрашивать действия в ваших системах
2. 2
   Работа с историей диалогаИначе агент не помнит, о чём шла речь
3. 3
   Подключение своей базы знанийОтветы по вашим документам, а не общие
4. 4
   Ограничения и границыЧто агент делает сам, что через подтверждение
5. 5
   Логи действийЧто агент сделал и почему — без этого не разобрать инцидент
6. 6
   Экспорт настроекВозможность забрать своё, если решите уходить

Про логи отдельно. Агент совершает действия, и рано или поздно совершит неправильное. Вопрос не в том, случится ли это, а в том, сможете ли вы понять, что произошло. Платформа без внятной истории действий превращает разбор инцидента в гадание.

Как выбрать: три вопроса вместо сравнительной таблицы

Таблицы возможностей устаревают за месяцы. Вопросы — нет.

Вопрос первый: что будет, если сервис завтра станет недоступен? Если ответ «остановится приём заявок» — вам нужен либо российский поставщик с договором, либо своё решение. Если «поэкспериментируем позже» — подойдёт что угодно.

Вопрос второй: что именно уходит в модель? Разберите на составляющие: имя клиента, номер телефона, текст обращения, история покупок. Если в этом списке есть то, что нельзя отдавать, круг вариантов сужается сразу.

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

Типовые ошибки при выборе

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

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

Считают только стоимость запросов. К ней добавляются разработка, поддержка, обновление базы знаний. Модель — обычно наименьшая статья.

Берут платформу под будущие задачи. «Возьмём с запасом, вдруг понадобится» приводит к переплате за возможности, которые не используются. Начинать надо под текущую задачу.

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

Порядок выбора, который работает

Как выбирать

1. 1
   Сформулировать задачуЧто агент должен делать и в каких системах
2. 2
   Проверить доступность кандидатовБуквально: открывается ли, проходит ли оплата
3. 3
   Отсеять по даннымЧто нельзя выпускать из контура
4. 4
   Проверить вызов инструментовЕсть ли механизм действий в ваших системах
5. 5
   Собрать прототип на одном сценарииНе на всех сразу
6. 6
   Посчитать месяц при вашем объёмеДо того, как масштабировать

Когда готовая платформа не подходит

Четыре ситуации, где придётся собирать своё.

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

Своя система без готовой интеграции. У платформ есть коннекторы к популярным сервисам. Если у вас самописная учётная система, интеграцию всё равно писать.

Данные под запретом. Если содержимое обращений не может уходить наружу, остаётся только свой контур.

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

Выбор под конкретную задачу

Универсального ответа нет, но есть закономерности. Разберём четыре самые частые задачи.

Поддержка клиентов

Что нужно: база знаний, ответы по документам, передача человеку, работа в нескольких каналах.

Что подходит: конструктор или российская облачная платформа. Задача типовая, логика простая, главное — качество ответов по вашим документам.

На что смотреть: размер контекста (сколько документов поместится) и качество поиска по базе. Сила модели здесь вторична: пересказать найденный фрагмент умеет любая.

Когда нужно своё: если поддержка должна лезть в вашу учётную систему за статусом заказа и остатками.

Продажи и обработка заявок

Что нужно: интеграция с CRM, квалификация по вашим критериям, создание сделок, уведомления менеджерам.

Что подходит: платформа автоматизации или своя разработка. Здесь агент много действует, а не только отвечает.

На что смотреть: наличие готового коннектора к вашей CRM. Если его нет, всё равно писать интеграцию — тогда преимущество готовой платформы уменьшается.

Разбор задачи целиком: ИИ-агенты для продаж.

Работа с документами

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

Что подходит: сервис модели плюс своя обвязка, либо специализированное решение.

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

Когда нужно своё: почти всегда, если документы содержат коммерческую тайну. См. локальный агент.

Внутренний помощник для сотрудников

Что нужно: база знаний по регламентам, ответы в рабочем мессенджере, разграничение доступов.

Что подходит: конструктор или облачная платформа — задача несложная.

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

Модель и платформа — это разные счета

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

Когда вы берёте конструктор или платформу автоматизации, вы платите за неё по тарифу. Но модель, которая внутри думает и формулирует ответы, — это отдельный поставщик и отдельный счёт.

Почему это важно на этапе выбора. Тариф платформы в 2 000 ₽ в месяц выглядит понятно. Но если каждый диалог внутри дёргает модель по три раза, а диалогов тысяча, счёт за модель может оказаться сопоставимым или больше.

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

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

Сколько стоит владение

Разложим по годам, потому что при выборе обычно смотрят только на старт.

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

Что переоценивают — стоимость модели. На типовых потоках это наименьшая статья. Считать её, конечно, надо, но решения принимать по ней не стоит.

Как посчитать, окупится ли

Простой способ, который не требует сложных моделей.

Расчёт за полчаса

1. 1
   Сколько обращений в месяцИз всех каналов, за обычный месяц
2. 2
   Какая доля типоваяТе, что закрываются известным ответом
3. 3
   Сколько времени уходит на одноВключая переключение внимания
4. 4
   Умножить и перевести в деньгиЧасы × стоимость часа сотрудника
5. 5
   Сравнить с суммой владения за годРазработка плюс двенадцать месяцев

Важная поправка. В расчёте выше не учтено главное — то, что раньше не делалось вообще. Ответы в нерабочее время, возврат к старым обращениям, обработка всех отзывов. Именно эта часть обычно и окупает проект, но её невозможно посчитать «до», потому что сравнивать не с чем.

Что спросить у поставщика

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

Вопросы поставщику

1. 1
   Что происходит, когда агент не знает ответаПравильный ответ: передаёт человеку, а не сочиняет
2. 2
   Как я увижу, что агент сделал и почемуЛоги действий должны быть доступны
3. 3
   Сколько будет стоить месяц при моём объёмеКонкретная сумма, а не «зависит»
4. 4
   Где хранятся данные и сколькоИ используются ли для обучения
5. 5
   Что я смогу забрать при уходеБаза знаний, история, настройки
6. 6
   Какие ограничения по частоте запросовВыдержит ли пиковую нагрузку
7. 7
   Кто обновляет базу знанийЕсли «вы сами» — уточните, каким образом
8. 8
   Что будет при недоступности сервисаЕсть ли запасной путь

Как выглядит запуск на готовой платформе

Пройдём по шагам, чтобы было понятно, сколько работы остаётся на вашей стороне даже с готовым решением.

От регистрации до работающего агента

1. 1
   Регистрация и пробный доступПолчаса
2. 2
   Прогон своих задач на пробном тарифеДень — и это самый важный шаг
3. 3
   Сбор базы знанийНеделя-две, зависит от того, где лежат ответы
4. 4
   Описание границ и сценарияНесколько дней
5. 5
   Подключение каналовКаждый канал отдельно
6. 6
   Интеграция с вашими системамиДольше всего, если нет готового коннектора
7. 7
   Проверка на части потокаНеделя наблюдения перед полным запуском

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

Типовые сроки и что их сдвигает

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

Как понять, что выбрали неправильно

Признаки, которые проявляются на втором-третьем месяце.

Каждое изменение требует подрядчика. Если поменять текст ответа или добавить вопрос в базу знаний нельзя без разработчика, вы выбрали слишком сложный инструмент под свою задачу.

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

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

Счёт растёт быстрее потока. Обращений столько же, а платите больше. Обычно причина в разросшейся базе знаний или в том, что в каждый запрос уезжает лишнее.

Никто не знает, как это устроено. Собрал подрядчик, внутри компании не разобрался никто. Формально система есть, фактически она чужая.

Взяли слишком простоеУпираетесь в потолок

• Логика не помещается
• Нет нужных интеграций
• Лимиты по нагрузке
• Решение: переезд на уровень выше

Взяли слишком сложноеПлатите за неиспользуемое

• Работает один простой сценарий
• Любая правка через разработчика
• Дорого в обслуживании
• Решение: упростить, а не наращивать

Кто должен выбирать платформу

Решение часто принимает не тот человек, и от этого зависит результат сильнее, чем от самой платформы.

Когда выбирает ИТ. Смотрят на технические возможности, интеграции, безопасность. Обычно выбирают правильно с точки зрения архитектуры и промахиваются с точки зрения задачи: получается система, которую не могут менять те, кому она нужна каждый день.

Когда выбирает бизнес-заказчик. Смотрят на удобство и скорость. Часто берут конструктор, а через полгода упираются в невозможность подключить учётную систему.

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

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

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

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

Что стоит сделать до выбора платформы

Три вещи, которые полезны при любом решении и часто меняют само решение.

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

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

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

Пять заблуждений

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

«Готовое решение не требует работы». Требует, и немало: формализовать критерии, собрать базу знаний, описать границы. Платформа экономит разработку каркаса, а не подготовку.

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

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

«Бесплатного тарифа хватит». Хватит на проверку идеи. На поток клиентов — нет, и переход на платный происходит именно тогда, когда система стала нужной.

Один агент или несколько

Вопрос, который возникает на втором сценарии и на который стоит ответить заранее.

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

Почему универсальный агент работает хуже:

• Размывается инструкция. Чем больше задач в одном описании, тем чаще модель выбирает не тот путь.
• Смешиваются доступы. Агент, который говорит и с клиентами, и с сотрудниками, рано или поздно скажет клиенту то, что предназначалось внутрь.
• Растёт стоимость запроса. В контекст приходится класть инструкции для всех сценариев сразу.
• Невозможно отладить. Ошибка в одном сценарии чинится правкой, которая ломает другой.

Как правильно. Несколько узких агентов с разными границами и разными базами знаний. Каждый делает одно и делает предсказуемо.

Что при этом общее. Инфраструктура: платформа, модель, механизм поиска по документам. Разные — базы знаний, инструкции и права. Это и делает схему выгодной: разворачиваете один раз, а агентов заводите под задачи.

Что происходит через год

Наблюдения, которые полезно знать до начала, а не после.

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

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

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

Забывается, зачем сделано именно так. Если решения не записаны, через год никто не помнит, почему агент не отвечает на определённые вопросы. Короткий документ с обоснованиями экономит недели разбирательств.

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

Короткий итог

Три утверждения, к которым сводится весь выбор.

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

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

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

Что делаю я

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

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