Выбор подрядчика по ИИ — оценка исполнителя по измеримым результатам, методике работы с данными и готовности к проверяемому пилоту, а не по списку технологий и громкости кейсов. В ИИ-проектах цена ошибки выше, чем в классической разработке: результат недетерминирован, и нечестный подрядчик может месяцами «настраивать» то, что не работает.
Парадокс рынка: чем хуже подрядчик понимает предмет, тем увереннее обещает. Компетентный исполнитель заранее говорит о рисках и отказывается от гарантий качества — и при грамотной оценке это аргумент за, а не против.
Критерии оценки
Кейсы с измеримыми результатами. «Внедрили ИИ в поддержку» — не результат; «доля автоматических ответов 55% на потоке 8 тысяч обращений в месяц, время первого ответа с 15 минут до 40 секунд» — результат. Спрашивайте числа, сценарий и что было до; кейс без цифр — описание занятости.
Вопросы про данные на первой встрече. Компетентный подрядчик спросит, где живут данные, кто их владелец, сколько обращений в месяц, что с персональными данными. Подрядчик, который не спросил про данные вообще, будет строить систему на предположениях — за ваш счёт.
Прозрачность методики оценки. Как исполнитель будет измерять качество: проверочный набор, метрики, пороги, кто размечает. Если методики нет, «стало лучше» означает «нам кажется»; как должна выглядеть методика — в статье про проверочный набор и бенчмарк.
Готовность к пилоту с критериями. Исполнитель, уверенный в методике, согласуется на пилот 2–6 недель с заранее зафиксированными порогами успеха и провала. Отказ от пилота или «сразу большое внедрение» — маркер уверенности за счёт заказчика; логика пилота — в статье пилотный проект.
Что остаётся у вас после проекта. Права на код, промпты, проверочный набор, методику оценки. Система, которую нельзя сопровождать без автора, — это зависимость, а не актив; вопрос прав фиксируется в договоре до старта.
Красные флаги
Гарантия 100% качества. Явный маркер: у генеративных моделей не бывает стопроцентной точности, это свойство механизма, а не вопрос старания. Обещающий гарантию либо не понимает предмет, либо понимает, но продаёт. Честная формулировка — пороги на согласованном наборе с зоной провала.
Отказ от проверочного набора. «Набор не нужен, мы и так видим качество» — путь к приёмке на глаз и месяцам споров. Нежелание измеряться — нежелание отвечать за результат.
Демо на синтетических данных без оговорок. Красивое демо на десяти подготовленных вопросах показывает верхнюю границу, а не рабочий режим. Нормальный подрядчик сам предупреждает об этом и предлагает проверку на ваших данных.
Фикс-прайс на весь проект до диагностики данных. До проверки данных и короткого замера невозможно честно оценить ИИ-проект; полная фиксация на старте означает, что риск заложен в цену с запасом или будет переложен на заказчика через «допработы».
Отсутствие разговоров о сопровождении. ИИ-система живёт в сопровождении; подрядчик, который говорит только о запуске, оставит вас с деградирующей системой через квартал. Ориентиры стоимости владения — в статье совокупная стоимость владения.
Модели договора: фикс-прайс против time&materials
Фикс-прайс годится для известного. Диагностика данных, интеграции, развёртывание — работы с предсказуемой формой. Условие применимости: детальное ТЗ с критериями приёмки; как его строить — в статье ТЗ на ИИ-проект.
Time&materials честнее для поиска. Подбор промптов, настройка качества, расширение сценария — исследовательская работа: количество итераций заранее неизвестно. Фикс на ней означает либо завышенную цену, либо остановку на первой договорённости.
Рабочая схема — гибрид. Фикс на диагностику и пилот с критериями, далее — этапы с фиксацией по результатам пилота, исследования внутри этапов — по T&M с бюджетным потолком. Так риск делится по способности сторон им управлять: подрядчик отвечает за известное, заказчик платит за реальную сложность неизвестного.
Как сравнить двух подрядчиков
Одинаковая пробная задача с общими критериями. Узкий сценарий, один и тот же срез данных, общие метрики и пороги. Сравнивать презентации бессмысленно — сравнивать результаты на своих данных осмысленно; бюджет такой проверки — порядка цены пилота и на порядок дешевле ошибки выбора.
Сравнивайте методику, а не только цифры. Два исполнителя дают 85% и 80%: у первого набор из 30 лёгких вопросов, у второго — из 100 боевых. Просите набор и методику у обоих, при возможности — прогон результатов одного на наборе другого.
Смотрите на поведение при трудностях. Что исполнитель ответил на вопрос «что если не взлетит»: честный ответ — план Б со сценарием сужения и критериями остановки. Уклончивый ответ предсказывает поведение в середине проекта.
Цена — фильтр, а не критерий выбора. Отбросьте выбивающиеся предложения (в обе стороны), из оставшихся берите по методике и кейсам. Самая низкая цена на ИИ-проекте обычно означает экономию на проверочном наборе и сопровождении — тех вещах, отсутствие которых выясняется после оплаты.
Типичные ошибки заказчика
Выбор по громкости бренда технологий. «Работают с GPT и векторными базами» говорит о доступе к API, а не об умении строить систему. Технологии в резюме измеряются нечем; результаты в кейсах — измеряются.
Отсутствие своей стороны в проекте. Подрядчик без владельца данных и приёмки со стороны заказчика работает вслепую; качество приёмки «подпишите, что всё хорошо» гарантированно упадёт до уровня проверки.
Передача всех решений подрядчику. Выбор сценария, пороги качества, границы данных — решения заказчика: у подрядчика нет информации о процессах и ценах ошибок. Исполнитель, охотно принимающий эти решения за вас, снимает с себя ответственность за последствия.
Частые вопросы
Что спросить на первой встрече?
Пять вопросов: как будете измерять качество и что считать провалом; какие данные нужны и в каком виде; покажите кейс с числами «было — стало»; кто будет сопровождать систему через год и сколько это стоит; что останется у нас, если мы расстанемся. Ответы «не знаем, покажем по ходу» на первые два — повод насторожиться.
Можно ли доверять демо?
Демо показывает, что система умеет в лабораторных условиях. Доверять можно после прогона на ваших данных: срез реальных обращений или документов, ваши люди, метрики, о которых договорились заранее. Подрядчик, отказывающийся от такой проверки, уже ответил на вопрос о доверии.
Нужен ли внешний подрядчик, если есть своя ИТ-команда?
Внешний подрядчик оправдан там, где у команды нет опыта: проверочные наборы, метрики, пайплайны оценки, интеграция моделей. Команда без этого опыта построит систему, но потратит на открытие известных вещей месяцы. Рабочая схема — пилот с подрядчиком и передача методики команде для развития.
Что фиксировать в договоре?
Критерии приёмки по метрикам на согласованном наборе, права на код и артефакты, включая проверочный набор, условия сопровождения и его стоимость, процедуру изменения объёма, порядок передачи данных и требования к их защите после расставания. Юридические требования к работе с персональными данными — отдельная тема; по ИИ-специфике это минимальный список.
Как проверить кейсы, если они под NDA?
Нормальная ситуация в корпоративном сегменте. Просите измеримые детали без названий: сценарий, объём потока, метрики до и после, срок. Отказ назвать хотя бы числа под предлогом NDA — уклонение: цифры не раскрывают клиента. Дополнительная проверка — профессиональные вопросы исполнителя о вашей задаче: знание предмета видно по вопросам, а не по слайдам.
Что важнее — отраслевой опыт или ИИ-компетенция?
Для типовых сценариев — ИИ-компетенция: поддержка и обработка документов устроены похожа в разных отраслях, а методика измерения переносится целиком. Отраслевой опыт критичен в регулируемых областях — финансы, медицина: там цена незнания комплаенса выше цены менее отточенной методики.
Когда пора менять подрядчика посреди проекта?
Сигналы: метрики не измеряются вторую итерацию подряд, сроки сдвигаются без изменения критериев, вопросы о данных игнорируются, а работы продаются как «сложность задачи». Менять разумно на границе этапа, когда проверочный набор, промпты и код передаются по акту — именно поэтому права на артефакты фиксируются в договоре до старта, а не при расставании.