При разработке ИИ на заказ сложности зачастую начинаются после того, как модель уже научилась решать задачу. Мы столкнулись с этим при создании HR-платформы: ИИ успешно оценивал резюме по требованиям вакансии, но HeadHunter позволял загружать только 500 анкет в сутки. При этом на отдельные вакансии приходило больше 600 откликов. Чтобы система могла работать с таким потоком, пришлось реализовать контроль лимитов, сохранение резюме и повторный скоринг без новых обращений к API.
Это только один из примеров ограничений, которые обнаруживаются при интеграции ИИ в реальные бизнес-процессы. К ним добавляются требования к качеству результатов, безопасности, отказоустойчивости и стоимости эксплуатации. Каждое из них может повлиять на архитектуру, сроки и бюджет проекта.
Поэтому ещё до заключения договора важно понять, насколько глубоко подрядчик проработал будущую систему и какие риски учёл. Разберём пять проверок, которые помогут оценить исполнителя и избежать дорогостоящих доработок после запуска.
Когда нужна разработка ИИ на заказ
Готовых ИИ-сервисов хватает для многих повседневных задач: подготовки текстов и презентаций, перевода документов, расшифровки встреч, анализа таблиц и генерации изображений. Сотрудник самостоятельно формулирует запрос, загружает материалы и проверяет результат.
Потребность в заказной ИИ-разработке возникает, когда те же задачи становятся частью серьезных бизнес-процессов. Например, система должна получать обращения из CRM, проверять данные в 1С, находить нужные регламенты, готовить ответы и передавать их сотрудникам на согласование. Здесь не обойтись без интеграций, управления доступом, обработки ошибок и контроля качества.
Если смотреть на конкретные примеры — работать с PDF можно в обычном ИИ-чате, но корпоративному RAG-ассистенту приходится искать информацию в тысячах документов, учитывать права сотрудников и подтверждать ответы источниками. Аналогично с генерацией изображений: готовый сервис создаст иллюстрацию, а для товарного каталога производителя потребуется сохранить геометрию изделия и встроить генерацию в PIM-систему.
В большинстве таких проектов используют готовые ИИ-модели. Основная инженерная работа приходится на бизнес-логику, интеграции, безопасность и обеспечение стабильной работы системы. Поэтому при выборе подрядчика важно понять, насколько хорошо он умеет решать эти задачи. Начать стоит с самого важного — понимания бизнес-процесса, который предстоит автоматизировать.
1. Понимает ли подрядчик, какую работу должен выполнять ИИ
Запрос «нужен ИИ-агент для продаж» даже приблизительно не позволяет спроектировать рабочую систему. Подрядчику необходимо выяснить, какие данные она будет получать, какие действия выполнять, по каким правилам принимать решения и что считать результатом. Только после этого можно определить архитектуру и выбрать подходящие технологии.
Заметим, что далеко не каждую операцию нужно поручать нейросети. Например, остатки товаров в 1С или скидку по заданной формуле надежнее получать обычным кодом. А вот LLM пригодится для анализа свободного текста заявки, поиска информации в документах или подготовки предварительных расчётов.
Последнюю задачу мы автоматизировали внутри SVK.Digital. Раньше первая оценка проекта могла готовиться до двух недель: требовалось собрать двух-трёх специалистов и поставить задачу в рабочий план. Сейчас ИИ-сметчик готовит черновик примерно за 20 минут. После настройки на наших данных отклонение от инженерных оценок составляет около 10–15%. Специалистам остаётся проверить расчёты и скорректировать их при необходимости.
Эффект измеряется временем подготовки, точностью сметы и трудозатратами инженеров.
Что проверить: способен ли подрядчик описать конкретный сценарий от поступления задачи до результата и назвать показатели, по которым будет оцениваться автоматизация?
2. Доступны ли данные и выдержат ли интеграции реальную работу
Даже самая точная ИИ-модель не сможет решить задачу, если у неё нет доступа к необходимым данным. А ограничения внешних систем могут серьезно повлиять на работу всего сервиса.
В HR-платформе SVK.Digital модель анализирует резюме, сопоставляет их с требованиями вакансии и объясняет рейтинг кандидата. Но используемая интеграция с HeadHunter считала загрузку полного резюме просмотром. Лимит составлял 500 анкет в сутки, а откликов на отдельную вакансию было больше 600.
Мы предусмотрели контроль лимита и сохранение загруженных резюме. Теперь рекрутер может изменить критерии вакансии и пересчитать рейтинг без повторного получения тех же анкет. Увеличение числа серверов не устранило бы исходное ограничение: оно находилось на стороне внешнего сервиса.
Похожие ограничения создают ERP, устаревшие API и документы в личных таблицах сотрудников. В таком случае сначала приходится приводить данные в порядок.
Что проверить: какие источники и методы API уже изучены, какие лимиты действуют и что произойдет, когда данные окажутся недоступны? Непроверенные интеграции должны быть явно обозначены в оценке проекта.
3. Согласованы ли измеримые критерии качества
Несколько удачных примеров на демо не гарантируют качество на неполных запросах и нестандартных данных.
Для производителя светильников мы разрабатывали сервис генерации изображений из исходных 3D-рендеров. Он должен был показывать изделие в интерьере, при разном освещении и с разных ракурсов. Модель могла сделать красивую сцену, но иногда меняла геометрию корпуса или крепления. Такое изображение не подходило для товарного каталога: покупатель увидит конструкцию, которой не существует.
Для поддержания требуемого качества в решении на базе Stable Diffusion и ControlNet мы предусмотрели сохранение геометрии изделия, автоматическую проверку согласованности и передачу изображений в PIM. Критерием приемки стало соответствие реальному товару.
У RAG-ассистента оценивают достоверность ответа и корректность источников, при обработке договоров — точность извлечения условий, при ИИ-скоринге — объяснимость оценки.
Для этого заранее формируют набор типовых, сложных и пограничных задач. Он служит основой для приёмки системы и оценки качества после обновлений модели.
Что проверить: кто готовит контрольную выборку, какие ошибки критичны и при каком результате работу можно считать принятой?
4. Что случится при ошибке агента или отказе внешней системы
У агента, который сам меняет данные в CRM или отправляет сообщения, высока цена ошибки. Для него крайне важно задать пределы полномочий и правила обработки сбоев.
В проекте второй линии поддержки DIY-ритейлера оператору приходилось собирать контекст из CRM, истории заказов, биллинга, склада, логистики и базы знаний. Обработка обращения занимала 10–20 минут. Мультиагентная система классифицирует тикет, получает нужные сведения, находит регламент и готовит ответ. Отправка остаётся за оператором.
Ситуация — клиент спрашивает о задержанной доставке. CRM доступна, а логистическая система не отвечает. Агенту нельзя придумывать дату: нужно сообщить об отсутствии подтверждённого статуса, повторить запрос по установленным правилам или передать задачу человеку.
Если агент создал заявку, но потерял подтверждение из-за сетевого сбоя, повторная попытка может создать дубликат. Нужны проверка результата, защита от повторных операций и журнал действий.
Полномочия также ограничивают технически: чтение документов, создание черновика и изменение финансовых данных требуют разных прав. Внешние письма и документы не должны иметь возможности расширить доступ агента своими инструкциями.
Что проверить: какие действия разрешены без подтверждения человека, что происходит при отказе API и можно ли восстановить историю решений и вызовов агента?
5. Понятна ли стоимость разработки ИИ на заказ и его эксплуатации
В смету входят данные, интеграции, интерфейсы, тестирование и безопасность. После запуска добавляются расходы на модели, инфраструктуру, API и сопровождение.
Допустим, модель А стоит 10 рублей за запрос и требует исправления в 2% случаев. Модель Б — 3 рубля, но исправления нужны в 12%. При цене ручной правки 150 рублей средняя стоимость обращения составит соответственно 13 и 21 рубль. Расчет конечно же условный, без инфраструктуры, но все равно показывает цену ошибок ИИ для бизнеса.
Для ИИ-агентов принято считать стоимость успешно выполненной задачи: учитываются вызовы моделей, поиск, внешние сервисы, повторные попытки и трудозатраты сотрудников. Подробнее этот подход разобран в нашем материале об AI FinOps.
Смету лучше разделить на прототип и промышленную систему. Прототип проверяет гипотезу на реальных данных. Промышленная система требует обработки отказов, разграничения прав, мониторинга и сопровождения. До старта также согласовывают, что подрядчик передаст заказчику: исходный код, документацию, тестовые сценарии, инструкции и права на результаты разработки.
Что проверить: сколько стоит создать систему, сколько — выполнить одну успешную операцию и какие расходы останутся после запуска? Сможет ли другая команда развивать продукт без первоначального подрядчика?
Как выглядят требования, по которым можно принять ИИ-систему
Вот как может выглядеть фрагмент требований к агенту, который готовит ответы о задержке доставки.
Задача. Подготовить оператору проект ответа с актуальной информацией о заказе.
Данные. Текст обращения, номер заказа, история переписки; источники — CRM, система заказов, логистический API и база знаний.
Результат. Ответ содержит подтвержденный статус и опирается на доступные сведения. Клиент получает его только после проверки оператором.
Исключения. Если логистический API недоступен или данные противоречивы, система сообщает об отсутствии подтверждённого срока. Выдумывать дату доставки запрещено.
Приёмка. На согласованной выборке проверяются достоверность статусов, соблюдение регламентов и работа при сбоях. Размер выборки и допустимую долю ошибок утверждают заранее.
Эксплуатация. Сохраняются журналы действий, учитываются расходы на обработку и предусмотрена передача обращения человеку.
Для полноценного финального ТЗ добавится нагрузка, время ответа и требования к безопасности.
С чего начать заказную ИИ-разработку
Начните с одного процесса: зафиксируйте объём задач, время выполнения, цену ошибок и источники данных. Затем определите, что проверит пилот.
Мы в SVK.Digital занимаемся разработкой ИИ на заказ: создаем ИИ-агентов, RAG-системы и инструменты автоматизации с интеграцией в корпоративную ИТ-инфраструктуру. Давайте обсудим ваш сценарий, ограничения и состав работ, чтобы оценить архитектуру, сроки и бюджет.
