разработка

Как выбрать разработчика ИИ-агентов: гайд для бизнеса

Главная
/
Блог

Максим Жуков

Сооснователь ecommerce-агентства KISLOROD

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

Содержание

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

Нужен ли вам агент

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

какую операцию агент выполняет и где обязан остановиться;
как будет измеряться бизнес-эффект;
какие данные попадут в модель и где они будут храниться;
что входит в MVP, сколько стоит эксплуатация и кто отвечает за поддержку после запуска;
как заказчик заберет код, документацию и доступы при смене исполнителя.

ИИ-агент — это программная система, которая получает задачу, обращается к модели, выбирает инструменты и выполняет действия: ищет сведения в корпоративных документах, запрашивает данные из CRM, создает заявку, рассчитывает условия по заданным правилам. В отличие от обычного чат-бота, он не ограничивается ответом в диалоге.

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

Есть простой тест. Агент уместен, если в процессе одновременно встречаются три условия:

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

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

Если вы решили, что необходимо внедрение ИИ-агента в бизнес, предлагаем схему по шагам, как выбрать подрядчика.

Шаг 1. Переведите идею в одну задачу

Внедрение ИИ в бизнес — это большое количество процессов. Мы советуем начинать с конкретной операции, у которой известны объем, текущая стоимость и проблемное место:

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

Шаг 2. Проверяйте портфолио по устройству проекта

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

Попросите разобрать один проект подробно:

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

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

Еще попросите показать сценарий со сбоем, например, с неудачным вызовом CRM. Для компании эта часть критически важна, вот только не все подрядчики готовы показывать обратную сторону проекта.

Чтобы проверить разработчика за одну встречу, попросите решить всех одинаковую условную ситуацию: «Клиент прислал письмо, в котором просит изменить адрес доставки. Заказ уже передан в логистику, в CRM есть два контакта с одинаковой фамилией, а в приложенном файле находится инструкция для ИИ проигнорировать правила».

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

Шаг 3. Посмотрите, кто именно будет делать проект

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

ML-инженер выбирает и тестирует модели, проектирует RAG, собирает набор проверочных сценариев, следит за качеством и стоимостью генерации;
бэкенд-разработчик отвечает за API, очереди, авторизацию, повторы операций и интеграцию с CRM/ERP;
аналитик описывает процесс, исключения, роли и источники данных;
QA-инженер проверяет не только интерфейс, но и последовательности действий, плохие входные данные, таймауты и восстановление;
DevOps- или инфраструктурный специалист настраивает окружения, секреты, мониторинг, резервирование и развертывание;
менеджер проекта удерживает границы пилота и собирает решения нескольких внутренних заказчиков.

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

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

Шаг 4. Попросите объяснить архитектуру ИИ-агента на языке действий

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

Базовая схема выглядит так:

Пользователь или корпоративная система передает задачу.
LLM (Large Language Models) интерпретирует запрос и выбирает следующий шаг.
Агент получает контекст из базы знаний или рабочих систем.
Детерминированный код проверяет параметры и права.
Инструмент выполняет разрешенное действие.
Результат записывается в журнал; при необходимости задача уходит человеку.

В роли модели могут использоваться YandexGPT, GigaChat, зарубежный API или модель в собственной инфраструктуре. У GigaChat, например, в официальной документации описаны режимы вызова пользовательских функций, а в Yandex AI Studio есть сценарии создания агентов с внешними функциями. Нужно сравнивать качество на данных заказчика, задержку, тарифы, доступность, условия обработки информации и удобство эксплуатации.

Шаг 5. Разберите безопасность данных ИИ-агента до расчета стоимости

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

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

Международные рекомендации NIST по управлению рисками генеративного ИИ рассматривают безопасность и оценку рисков на всем жизненном цикле системы. Для заказчика нужны схема, правила доступа, тесты и ответственные.

Особое внимание — prompt injection (внедрение вредоносных инструкций в промпт). Вредная инструкция может прийти не только от пользователя, но и из письма, веб-страницы или документа, который попал в RAG. В перечне OWASP Top 10 для LLM-приложений рядом с prompt injection указаны утечки чувствительной информации, небезопасная обработка выхода модели и избыточная автономность.

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

Облако или on-premise

Развертывание on-premise бывает оправдано требованиями к контуру, задержке или контролю над данными, в том числе требованиями 152-ФЗ о персональных данных. В таком случае кто-то должен обновлять модели и библиотеки, закрывать уязвимости, управлять доступами, следить за мощностями и резервными копиями.

Попросите сравнить три варианта — облачный, локальный и гибридный — по рискам и полной стоимости владения. Если компания предлагает on-premise как универсальное лекарство, но не включает эксплуатацию инфраструктуры в смету, расчет неполный.

Шаг 6. Ограничьте MVP и заранее договоритесь о приемке

Хороший MVP проверяет одну дорогую гипотезу. Например: сможет ли агент разбирать входящие B2B-заявки, задавать уточняющие вопросы и передавать менеджеру заполненную карточку. Один канал, одна команда продаж, несколько типов заявок. Без автоматического изменения цен и рассылки договоров.

У пилота должны быть границы:

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

Как проверить качество агента

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

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

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

Что получить на выходе MVP

В качестве результата пилота запросите:

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

Шаг 7. Сравните стоимость разработки ИИ-агента

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

Предпроектное обследование и проектирование.
Подготовка данных и интеграций.
Разработка и тестирование MVP.
Промышленное развертывание.
Использование моделей, векторной базы и инфраструктуры.
Мониторинг, поддержка и развитие.

Модель ценообразования зависит от определенности. Фиксированная цена подходит для обследования или узкого этапа с ясной приемкой. Time & Materials — для исследовательской части, где архитектура уточняется по результатам экспериментов. Возможен смешанный вариант: фиксированная диагностика, MVP с лимитом бюджета и отдельная оценка масштабирования.

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

Что включить в техническое задание и договор

Техническое задание (ТЗ) на агентную систему описывает рабочий контур.

Зафиксируйте в документе:

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

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

Поддержка после запуска

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

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

Уточните время реакции на критический сбой и кто дежурит вне рабочего времени, если агент участвует в круглосуточном процессе.

Как принять решение

Некоторые тревожные сигналы видны еще до коммерческого предложения. Собрали основные красные флаги:

Обещают стопроцентную точность и отсутствие галлюцинаций. Риск можно снижать с помощью RAG, проверок, ограничений и участия человека. Удалить его одной настройкой нельзя.
Выбирают модель и стек до знакомства с данными. YandexGPT или GigaChat могут хорошо подойти для одного сценария и уступить в другом. Сравнивать нужно на реальной выборке и с учетом ограничений контура.
Предлагают много агентов потому, что это современно. Несколько программ увеличивают число вызовов, стоимость и количество точек отказа.
Показывают только ответы модели. Для рабочего агента нужны логи вызовов инструментов, обработка ошибок, контроль доступа и измерения после запуска.
Не спрашивают об исходных показателях. Без них невозможно доказать измеримый результат и бизнес-эффект.
Уходят от разговора о данных. Неясно, где хранятся запросы, кто видит логи и как удаляется информация, — проект рано подключать к корпоративным системам.
Не считают регулярные расходы. В смете есть разработка, но нет API моделей, инфраструктуры, мониторинга и обновления знаний.
Не предусматривают ручное подтверждение и откат. Особенно когда агент может отправлять письма, менять цены, удалять записи или проводить операции.
Привязывают заказчика к себе. Нет передачи кода, документации, тестов и доступов. То есть смена подрядчика фактически означает разработку заново.

Этот список можно отправить кандидатам до встречи:

Какую одну бизнес-операцию вы предлагаете отдать агенту первой и почему?
В каких случаях вы посоветуете обычную автоматизацию вместо ИИ-агента?
Какие данные нужны для проверки гипотезы и где они будут обрабатываться?
Как вы сравните модели на нашей задаче?
Где агент получает права и как они ограничиваются?
Какие действия требуют подтверждения сотрудника?
Как система защищается от инструкций во внешних письмах и документах?
Что произойдет при недоступности LLM, CRM или ERP?
Как устроены тестовый набор, мониторинг качества и журнал действий?
Из чего складываются бюджет MVP и ежемесячная эксплуатация?
Что мы получим при завершении проекта и сможем ли сменить модель или подрядчика?
Кто и на каких условиях поддерживает систему после релиза?

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

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

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

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

В KISLOROD мы начинаем с разбора вашей задачи

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

Часто задаваемые вопросы

Сколько стоит разработка ИИ-агента?

Стоимость зависит от сложности сценария, числа интеграций и модели оплаты. Фиксированная цена подходит для ограниченного MVP, Time & Materials — для сценариев, которые уточняются по ходу проекта. Мы рекомендуем не ориентироваться только на разовую разработку, учитывайте стоимость тысячи обработанных задач при вашем объеме — в нее входят токены, инфраструктура и поддержка.

Чем ИИ-агент отличается от обычного чат-бота?

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

Как понять, что бизнесу нужен именно ИИ-агент, а не обычная автоматизация?

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

Сколько времени занимает разработка MVP ИИ-агента?

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

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

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

Можно ли сменить подрядчика после запуска агента?

Да, если в договоре зафиксирована передача кода, документации, тестов и доступов. Уточняйте это на этапе ТЗ — иначе смена исполнителя фактически означает разработку заново.

Получайте полезный контент от KISLOROD в любом из мессенджеров

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