Как выбрать подрядчика по ИИ: критерии качества и риски дешевой разработки

Как выбрать подрядчика по ИИ в России: почему SLA и опыт важнее цены (полное руководство 2025)

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

Вы открываете поиск, вбиваете «разработка нейросетей на заказ» и получаете десятки предложений. Рынок пестрит:

• •Крупные системные интеграторы с громкими именами и такими же громкими ценниками.
• •Бодрые IT-студии, обещающие «сделать убийцу ChatGPT за месяц».
• •Команды фрилансеров и студенты-энтузиасты, готовые работать за еду и опыт.

Разброс цен шокирует. Одна компания предлагает сделать систему видеоаналитики за 5 миллионов рублей, другая — «точно такую же» за 800 тысяч.

Соблазн сэкономить огромен. В голове возникает мысль: «ИИ — это же просто программный код. Какая разница, кто его напишет, если результат будет один? Зачем переплачивать за бренд?».

Это — самая опасная ловушка, в которую попадают 8 из 10 заказчиков на старте. В сфере сложной R&D разработки (а ИИ — это именно R&D) выбор самого дешевого подрядчика почти гарантированно приводит к тому, что вы заплатите дважды: сначала ему, а потом — профессионалам, которые будут переделывать всё с нуля.

В этой статье мы не будем говорить о технологиях, нейронах и слоях. Мы поговорим о доверии, рисках и деньгах. Я на реальных примерах объясню, почему отраслевой опыт и железобетонные гарантии (SLA) в сто раз важнее стартовой цены.

Вы узнаете:

1. •Как выглядит анатомия провального проекта (чтобы не повторить чужих ошибок).
2. •Домашняя работа: что нужно сделать ДО того, как звонить подрядчикам.
3. •Три кита надежного подрядчика: Опыт, Команда, Гарантии.
4. •Что такое SLA и почему без него нельзя подписывать договор.
5. •Юридические нюансы: как не остаться без прав на собственный софт.
6. •Чек-лист из 20 неудобных вопросов, который выведет любого продавца на чистую воду.

Часть 1. Анатомия провала: как «экономия» убивает проекты

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

Дано: Компания «Альфа» (крупный производитель кухонной мебели) решила внедрить ИИ для контроля качества. Задача: Автоматически находить царапины и сколы на мебельных фасадах с помощью камер на конвейере. Бюджет: Руководство хочет «подешевле», так как это эксперимент.

Компания провела тендер и получила два финалиста:

Претендент №1: «Опытные Интеграторы»

• •Цена: 5 000 000 ₽.
• •Срок: 8 месяцев.
• •Подход: В коммерческом предложении (КП) на 20 страниц подробно расписаны риски: «Глянцевые фасады бликуют, нужно специальное освещение», «Нужна разметка 5000 фото дефектов», «Точность на старте будет 85%, дообучение займет 2 месяца».
• •Реакция заказчика: «Дорого, долго, да еще и гарантий 100% не дают. Мутные ребята».

Претендент №2: «Молодые и Дерзкие»

• •Цена: 2 800 000 ₽.
• •Срок: 4 месяца.
• •Подход: «Да что там делать? Возьмем YOLO v8, камеры с AliExpress, все полетит. Мы такое сто раз делали (правда, для распознавания котиков, но принцип тот же). Гарантируем 99% точности!»
• •Реакция заказчика: «Вот это деловой разговор! Берем».

Хроника катастрофы

Месяц 1-2 (Медовый месяц): Подрядчик получил аванс 50% (1 400 000 ₽). Работа кипит, отчеты красивые. Разработчики просят прислать «пару фоток брака для примера».

Месяц 3 (Первые звоночки): Энтузиазм угас. Разработчики пишут: «У вас в цеху освещение меняется в течение дня, нейросеть сходит с ума. Надо ставить шторы и профессиональный свет». Заказчик в недоумении: «Вы же не предупреждали!». Внезапно выясняется, что «пары фоток» мало. Нужно 10 000 размеченных снимков. У подрядчика нет людей для разметки. «Альфе» приходится снимать своих контролеров с работы, чтобы они обводили царапины в Paint.

Месяц 4 (Срок сдачи): Подрядчик показывает демо. На тестовом стенде в офисе (в идеальных условиях) все работает. Привозят на завод. Результат: система пропускает 60% реального брака, зато каждые 5 минут орет сиреной на пылинки и блики от ламп. Конвейер встает. Начальник цеха матерится и требует убрать «эту шарманку».

Месяц 5 (Агония): Подрядчик выставляет доп. соглашение на 1 500 000 ₽: «Ну, мы не учли сложность, надо переписывать архитектуру и докупать сервер».

Месяц 6 (Финал): Директор «Альфы» понимает, что его водят за нос. Договор расторгается. Итог:

• •Потеряно денег: 1 400 000 ₽ (аванс).
• •Потеряно времени: 6 месяцев.
• •Потеряна вера: Директор уверен, что «ИИ — это сырая технология, нам рано».

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

Часть 2. Домашняя работа: 5 вопросов себе перед стартом

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

1. •Какую конкретную бизнес-боль мы лечим?
   • •Плохо: «Хотим внедрить ИИ, чтобы было современно».
   • •Хорошо: «Мы теряем 30% заявок, потому что менеджеры не успевают отвечать в чате. Нам нужно автоматизировать первичную обработку».
2. •Есть ли у нас данные?
   • •ИИ учится на примерах. Есть ли у вас история переписки с клиентами? Архив фотографий брака? Таблицы продаж за 3 года? Если данных нет, первый этап проекта будет посвящен их сбору.
3. •Кто будет отвечать за проект с нашей стороны?
   • •Вам нужен Product Owner внутри компании. Человек, который знает бизнес-процесс, имеет полномочия принимать решения и будет на связи с подрядчиком. ИИ нельзя внедрить «под ключ» без вашего участия.
4. •Как мы будем измерять успех?
   • •Сформулируйте критерии приемки. «Точность 95%» — это абстракция. «Сокращение времени ответа до 1 минуты» — это метрика.
5. •Готова ли наша инфраструктура?
   • •Есть ли у вас серверы? Можно ли ставить сторонний софт? Есть ли API у вашей CRM?

Часть 3. Три кита надежного выбора: Опыт, Команда, Гарантии

Как не стать «Компанией Альфа»? Забудьте о цене на первом этапе отбора. Смотрите на три критерия.

Кит №1: Отраслевой Опыт (Релевантность)

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

Что искать? Вам нужны не просто кейсы «мы внедряли ИИ», а кейсы в вашей нише или для вашего типа задач.

• •Если вы ритейл — ищите кейсы по прогнозированию спроса, рекомендательным системам, видеоаналитике полок.
• •Если вы промышленность — ищите кейсы по дефектоскопии, охране труда, цифровым двойникам.

Как проверять кейсы (Метод «Буравчика»): Не верьте красивым логотипам клиентов на сайте. Копайте глубже:

1. •«Покажите цифры».
   • •Плохо: «Внедрили ИИ на заводе N, клиент доволен».
   • •Хорошо: «Внедрили контроль СИЗ. Снизили количество нарушений на 80% за 3 месяца. Травматизм упал до нуля. Экономия на штрафах — 2 млн руб/год».
2. •«Расскажите про проблемы».
   • •Спросите: «А что пошло не так на этом проекте?». Профессионал честно расскажет: «Мы мучались с камерами, модель переобучали 5 раз, были проблемы с интеграцией». Дилетант скажет: «Все прошло идеально». В ИИ не бывает идеально.
3. •«Дайте телефон».
   • •Попросите контакт руководителя проекта со стороны клиента. Позвоните и спросите: «Как они решали проблемы? Соблюдали ли сроки? Работает ли система сейчас?».

Кит №2: Прозрачная Команда (Кто делает?)

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

Кто нужен для успеха и чем грозит их отсутствие:

1. •Бизнес-аналитик (Business Analyst):
   • •Зачем нужен: Он переводит вашу боль («теряем деньги на браке») на язык инженеров («нужна модель сегментации с метрикой IoU > 0.8»). Пишет подробное ТЗ.
   • •Если его нет: Разработчики сделают то, что им интересно, а не то, что нужно бизнесу. Продукт будет технически сложным, но бесполезным.
2. •ML-архитектор / Team Lead:
   • •Зачем нужен: Выбирает стек технологий, стратегию обучения. Решает, использовать готовую модель или учить с нуля.
   • •Если его нет: Команда выберет хайповую, но сырую технологию, которая завтра перестанет поддерживаться. Вы попадете в тупик.
3. •Data Scientists (ML-инженеры):
   • •Зачем нужны: Те самые «строители». Чистят данные, обучают модели, проводят эксперименты, борются за каждый процент точности.
   • •Если их нет: Вы получите просто «оболочку» без мозгов.
4. •Data Engineer / DevOps:
   • •Зачем нужен: Настраивает серверы, базы данных, «трубопроводы» (pipelines). Делает так, чтобы модель работала быстро и стабильно под нагрузкой.
   • •Если его нет: Модель будет падать при заходе 10 пользователей, а серверы будут стоить в 5 раз дороже из-за неоптимальной настройки.
5. •Backend/Frontend разработчики:
   • •Зачем нужны: Пишут API, делают удобные кнопки, дашборды, интеграцию с 1С.
   • •Если их нет: У вас будет работающая нейросеть в виде кода в ноутбуке программиста, которой никто из сотрудников не сможет пользоваться.
6. •Project Manager (PM):
   • •Зачем нужен: Ваше «одно окно». Пинает команду, следит за сроками, бюджетом и переводит с технического на русский.
   • •Если его нет: Сроки сорвутся, бюджет раздуется, а вы будете тратить 50% своего времени на микроменеджмент программистов.

Вопрос подрядчику: «Пришлите, пожалуйста, обезличенные резюме (CV) специалистов. Кто из них будет на фул-тайме, а кто — на частичной занятости?»

Кит №3: Железобетонный Договор и Интеллектуальные Права

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

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

• •Что это значит: Вы заплатили за разработку, но права остались у разработчика. Он может завтра продать ваше решение (обученное на ваших данных!) вашему прямому конкуренту. Вы не сможете дорабатывать систему силами другой команды.
• •Как надо: Требуйте полного отчуждения исключительных прав на специально разработанный код и обученные модели. Это должно быть прописано явно: «Исключительные права переходят Заказчику с момента подписания акта».

Конфиденциальность (NDA): Вы передаете подрядчику свои данные: базы клиентов, чертежи, фото производства.

• •Требуйте жесткого NDA (Non-Disclosure Agreement) с большими штрафами за утечку данных или использование их для обучения чужих моделей. Пропишите удаление данных с серверов подрядчика после завершения проекта.

Часть 4. SLA (Service Level Agreement): Страховка от простоя

Представьте: пятница, «Черная пятница», распродажа. Ваш умный чат-бот, который обрабатывает 90% заказов, ложится. Вы теряете миллионы в час. Вы звоните подрядчику, а там автоответчик: «Мы работаем с пн по пт до 18:00».

Чтобы этого не случилось, в договоре должен быть раздел SLA — Соглашение об уровне сервиса. Это не просто «техподдержка», это финансовые гарантии работоспособности.

Таблица: Что должно быть в SLA

Штрафные санкции: Самый важный пункт. Если его нет, SLA — просто бумажка.

• •Пример: «Если Uptime упал ниже 99.9%, Исполнитель возвращает 10% стоимости обслуживания за месяц. Если ниже 95% — возвращает 100%». Только финансовая ответственность заставляет подрядчика реально следить за вашими серверами, настраивать мониторинг и просыпаться ночью от смс об аварии.

Часть 5. Топ-5 мифов о подрядчиках, которые стоят вам денег

Завершим наш разбор коротким блиц-опросом по самым популярным заблуждениям.

Миф 1: «Крупный интегратор сделает лучше, чем маленькая студия»

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

Миф 2: «Мы подпишем договор на поддержку потом»

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

Миф 3: «ИИ — это разовая покупка, как станок»

• •Реальность: ИИ — это живой организм. Данные меняются, мир меняется. Модель нужно постоянно «кормить» новыми данными и дообучать. Закладывайте 15–20% от бюджета разработки на ежегодное обслуживание.

Миф 4: «Подрядчик сам разберется в наших данных»

• •Реальность: Никто не знает ваши данные лучше вас. Если вы просто скинете подрядчику «помойку» из файлов, на выходе получите «помойку» из результатов. Активное участие заказчика в подготовке данных — 50% успеха.

Миф 5: «Если работает у конкурентов, заработает и у нас»

• •Реальность: Даже если у конкурента «точно такой же склад», у него другое освещение, другие камеры, другая упаковка товаров. ИИ нельзя просто «скопировать-вставить», его всегда нужно адаптировать.

Часть 6. Чек-лист: 20 вопросов для «допроса» подрядчика

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

Блок 1: Опыт и Компетенции

1. •Покажите 3 кейса, максимально похожих на наш по задаче или отрасли.
2. •Какие конкретно бизнес-показатели (KPI) вы улучшили в этих проектах?
3. •Дайте контакты двух прошлых клиентов, которым можно позвонить.
4. •Есть ли у вас опыт работы с нашим стеком технологий (например, 1С, Битрикс, специфическое пром. оборудование)?
5. •Вы делаете все in-house (своими силами) или привлекаете субподрядчиков?

Блок 2: Процессы и Команда 6. Кто будет моим Project Manager? Познакомьте нас до старта. 7. Сколько Senior-специалистов будет в команде? 8. Как часто будут демо-показы промежуточных результатов? (Оптимально: раз в 1-2 недели). 9. Где будет вестись трекинг задач? (Jira, YouTrack, Trello). Дадите ли вы нам доступ? 10. Как организован процесс сбора и разметки данных? У вас свои разметчики?

Блок 3: Техника и Данные 11. Где будут физически находиться серверы и данные? (Важно для 152-ФЗ). 12. Какую архитектуру модели планируете использовать и почему? 13. Что будет, если данных окажется недостаточно или они будут плохими? Какой план «Б»? 14. Как вы гарантируете, что наши данные не утекут?

Блок 4: Юридические вопросы и Деньги 15. Кому будут принадлежать права на код и обученную модель? 16. Готовы ли вы подписать жесткий SLA с финансовой ответственностью? 17. Входит ли в стоимость лицензия на стороннее ПО или датасеты? 18. Как считается стоимость поддержки после внедрения? 19. Есть ли скрытые платежи (за облака, за API, за доп. часы)? 20. Готовы ли вы разбить проект на этапы с оплатой за результат (Milestones), а не Time & Material?

Заключение: Выбирайте партнера, а не кодера

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

Настоящий партнер отличается несколькими ключевыми признаками:

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

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

Глоссарий терминов

• •SLA (Service Level Agreement): Соглашение об уровне услуг. Это юридический документ, в котором четко прописаны гарантии качества сервиса (например, время доступности системы, скорость реакции на инциденты) и финансовые штрафы для подрядчика за их невыполнение.
• •NDA (Non-Disclosure Agreement): Соглашение о неразглашении. Этот документ юридически обязывает подрядчика хранить в тайне ваши данные, коммерческие секреты и любую информацию, полученную в ходе проекта.
• •Time & Material (T&M) vs. Fixed Price: Два основных подхода к оплате. T&M — это оплата за фактически отработанные часы команды; риски срыва сроков и бюджета лежат на заказчике. Fixed Price — это фиксированная цена за четко оговоренный объем работ; подрядчик закладывает свои риски в стоимость, что может сделать проект дороже, но предсказуемее для заказчика.
• •In-house: Разработка, выполненная внутренними силами компании, без привлечения внешних команд.
• •Стек (Tech Stack) и Uptime: Стек — это набор технологий (языки программирования, фреймворки), на котором строится проект. Uptime — это ключевой показатель надежности, выраженный в процентах времени, когда система была доступна и работала без сбоев.
• •Milestone (Веха): Контрольная точка в плане проекта, привязанная к конкретному измеримому результату (например, «работающий прототип»). Оплата часто привязывается к достижению таких вех.