Как выбрать подрядчика по разработке: разбор реального тендера на AI-модуль

Когда бюджет на разработку уже согласован, а дедлайн зафиксирован, вопрос «кому отдать проект» становится самым дорогостоящим решением квартала. Ошибка здесь стоит не только денег — она стоит времени, которого нет…

Точка входа: как формировался шорт-лист

Заказчик — средний ритейлер с собственным IT-отделом из трёх человек. Задача: интегрировать AI-модуль распознавания и классификации входящих документов в существующую 1С-инфраструктуру. Срок — 14 недель, бюджет согласован «вилкой». В шорт-лист попали пять команд: две крупные студии с именем на рынке, одна команда на аутстафе, небольшое продуктовое агентство и специализированная AI-компания. Все прошли первичный фильтр: наличие юрлица, опыт от трёх лет, хотя бы один реализованный проект с ML-компонентом.

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

Технический бриф как инструмент отсева: что спрашивать на пресейле

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

Второй фильтр — запрос на демонстрацию архитектурного подхода. Не финального решения, а именно подхода: как команда будет декомпозировать задачу, какие риски видит, где предполагает итерации. Формат — 30-минутный созвон с техлидом, без слайдов. Это быстро показывает реальный уровень компетенции: говорит ли технический руководитель конкретно или уходит в общие слова про «гибкую методологию» и «agile-подход». Из оставшихся трёх одна команда провалила именно этот этап — технический лид не мог объяснить, как они планируют обрабатывать документы с нестандартной структурой.

Итого после двух этапов в финале осталось два кандидата: AI-компания с узкой специализацией и продуктовое агентство с опытом интеграций в 1С. Именно такой разрыв — между «умеют в AI» и «умеют в экосистему заказчика» — и стал ключевым выбором.

Как сравнивать коммерческие предложения, когда цена отличается вдвое

AI-специализированная компания предложила 3,9 млн рублей и 16 недель. Продуктовое агентство — 2,1 млн и 12 недель. Разница почти двукратная. Типичная реакция заказчика — выбрать дешевле. Правильная реакция — разобрать структуру каждого предложения по статьям. Попросите разбивку: сколько стоит аналитика и проектирование, сколько — разработка модели, сколько — интеграция, сколько — тестирование и документация. Если подрядчик не может или не хочет давать такую разбивку — это сигнал.

В данном кейсе разбивка показала: агентство закладывало 80% бюджета на интеграцию и почти ничего — на качество самой AI-модели. По сути, они планировали использовать готовое облачное решение с минимальной настройкой. Это было бы приемлемо, если бы задача не предполагала работу с конфиденциальными финансовыми документами, которые нельзя отправлять во внешние API. Этот нюанс вскрылся именно через анализ структуры сметы — не через вопросы на созвоне.

Ориентир для рынка 2026 года: разработка специализированного AI-модуля с обучением на собственных данных заказчика и интеграцией в корпоративную инфраструктуру стоит в диапазоне 2–5 млн рублей в зависимости от сложности данных и объёма интеграции. Предложения ниже нижней границы почти всегда означают либо использование готовых внешних моделей, либо существенное сокращение этапа тестирования.

Договор и процесс: что проверить до подписания

К моменту выхода на договор заказчик выбрал AI-компанию — несмотря на более высокий бюджет, именно они могли гарантировать работу модели на инфраструктуре заказчика без передачи данных наружу. Но переговоры по договору вскрыли ещё один критически важный пункт: кому принадлежит обученная модель после сдачи проекта? В первой редакции договора это было сформулировано размыто — «результаты работ передаются заказчику». Это не то же самое, что передача прав на веса модели, датасет и пайплайн обучения.

Проверяйте в договоре минимум три вещи: точный состав передаваемых результатов (код, модель, документация, тестовые данные), порядок приёмки с измеримыми критериями качества (например, точность классификации не ниже X% на тестовой выборке) и ответственность за просрочку с понятным механизмом — не просто «штраф 0,1% в день», а с верхней границей и порядком фиксации нарушения. Без этих трёх пунктов договор защищает подрядчика, а не вас.

Финальный совет по процессу: договоритесь о формате промежуточной приёмки до начала работ. Оптимально — демонстрация рабочего прототипа на реальных данных заказчика на 4–5-й неделе. Если к этому моменту показать нечего — значит, проект уже в зоне риска, и у вас ещё есть время для управляемой остановки.

Чему учит этот кейс: три правила выбора подрядчика

Первое: специализация важнее размера. Крупная студия с громким именем проиграла узкоспециализированной команде, потому что задача требовала глубины, а не широты. Спрашивайте не «сколько проектов вы сделали», а «сколько проектов именно такого типа, с такими ограничениями, вы довели до продакшна». Второе: структура сметы честнее, чем итоговая цифра. Дешевле — не значит лучше; дороже — не значит надёжнее. Смотрите, за что именно платите. Третье: договор — это архитектура отношений, а не формальность. Всё, что не написано — трактуется в пользу того, кто написал документ.

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