Что я хочу увидеть у подрядчика до начала AI-проекта

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

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

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

Прошу пересказать задачу бизнеса

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

Если после обсуждения исполнитель может описать только желаемый интерфейс, постановка ещё не закончена. Красивый чат сам по себе не объясняет, зачем он нужен сотруднику.

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

Хочу увидеть границы первого этапа

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

Полезна таблица ответственности. Кто готовит данные, подключает доступ, определяет бизнес-правила, оценивает ответы и обучает пользователей? Формулировка «это будет сделано совместно» без конкретного ответственного часто оставляет место для разных ожиданий.

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

Спрашиваю о проверке качества

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

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

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

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

Разбираю стоимость через состав работы

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

Я прошу отдельно показать первоначальные работы, регулярные расходы, допущения по нагрузке и задачи, которые останутся сотрудникам компании. Если оценка предварительная, полезнее обозначить диапазон и условия его изменения, чем делать вид, что всё известно заранее.

Также важно понять, что происходит при неудачном пилоте. Какие материалы и выводы компания сохранит? Можно ли использовать подготовленные данные и проверки в другом подходе? Исследовательская неопределённость нормальна, если она прямо описана и ограничена этапом.

Проверяю передачу и управляемость

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

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

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

Прошу назвать слабые места

Мне полезнее конкретный разговор об ограничениях, чем обещание справиться с любой задачей. Какие данные чаще всего мешают? Где потребуется человек? Какое условие может сделать проект невыгодным?

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

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

Как я сравниваю предложения

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

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

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