Как выбрать подрядчика по внедрению ИИ

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

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

Что видно на первой встрече

Разговор начинается с модели. «Мы работаем на такой-то модели», «у нас своя платформа», «подключим самую свежую версию» — ещё до того, как прозвучало, что именно надо сделать. Выбор модели — не первый шаг постановки, а один из последних: его делают, когда уже есть на чём сравнивать. Исполнитель, который приносит его готовым, продаёт инструмент, а не решение, и дальше будет подгонять задачу под то, что умеет.

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

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

Честный ответ о сроках звучит скучно: «первый этап займёт столько-то, срок всего проекта назовём после прогона ваших примеров». Если исполнитель готов назвать общий срок раньше, он либо не понимает, где уйдёт время, либо понимает и рассчитывает на дополнительные соглашения.

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

У вопроса есть вторая половина: кто с вашей стороны даст реальные примеры и отметит, какой ответ правильный. Без этого человека проект стоит, и хороший исполнитель выясняет это до сметы, потому что от него зависит весь график.

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

Что видно в смете

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

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

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

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

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

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

Вопросы до подписания

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

«Как вы поймёте, что задача решена?» Ждёте описания входа, результата и того, что считается провалом. «Заказчик будет доволен» — не ответ.

«Что будет на двадцати наших примерах?» Предложите прогнать реальные случаи до договора или в рамках короткого платного этапа. Отказ смотреть на ваши данные до подписания стоит в том же ряду, что и молчание о приёмке.

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

Если договор квалифицируется как подряд, то по общему правилу статьи 720 ГК РФ заказчик, принявший работу без проверки, теряет право ссылаться на недостатки, которые можно было обнаружить при обычном способе приёмки, если договором не предусмотрено иное. Для системы с моделью «обычная приёмка» без набора примеров почти ничего не находит, поэтому порядок приёмки по набору лучше записать в сам договор.

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

«Кому принадлежат промпты, набор примеров и код?» По статье 1296 ГК РФ исключительное право на программу или базу данных, созданные по заказу, принадлежит заказчику, если договором не предусмотрено иное. Промпты и набор примеров не обязательно считаются программой или базой данных, поэтому их судьбу лучше прямо назвать в договоре отдельной строкой. Всё остальное решает оговорка про «иное»: проверьте, не записано ли оно в типовом договоре исполнителя. Набор примеров с разметкой — самый долговечный результат проекта, и без него смена исполнителя означает начать сначала.

Последний вопрос — куда уходят данные и кто за них отвечает. Если подрядчик получает доступ к запросам с персональными данными, он обрабатывает их по вашему поручению. Часть 3 статьи 6 закона 152-ФЗ требует, чтобы в поручении были перечень данных и действий с ними, цели обработки и требования к защите, а по части 5 той же статьи отвечать перед человеком, чьи это данные, будете вы, а подрядчик отвечает уже перед вами. Какой сервис модели стоит за решением и где он расположен — вопрос того же порядка, подробнее о нём в заметке.

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

Первый этап как проверка исполнителя

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

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

Такая конструкция срезает главный риск — пилот, который всем понравился и не стал частью работы. Об этом риске предупреждали заранее: Gartner летом 2024 года прогнозировал, что не меньше 30% проектов генеративного ИИ к концу 2025 года бросят после проверки концепции, и называл причинами плохое качество данных, слабый контроль рисков, рост затрат и неясную пользу. Каждая из этих причин всплывает на коротком этапе, если он построен вокруг примеров, а не вокруг показа.

Условие несогласия

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

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

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

Чего я делать не стал бы

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

Не стал бы подписывать договор, где приёмка описана словами «в соответствии с техническим заданием», а в техническом задании нет ни одного примера. Такой договор производит спор, а не результат: каждая сторона окажется права по-своему.

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

Открытый вопрос

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

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