Этапы создания ИТ-продукта с искусственным интеллектом: от идеи до запуска MVP

Обычное приложение предсказуемо: одна и та же кнопка каждый раз даёт один и тот же результат. С нейросетью так не выйдет. Разработка AI-продуктов от идеи до MVP подчиняется тем же продуктовым правилам, что и любая другая, но пять особенностей меняют каждый шаг.

Ответ вероятностный. Модель может ошибиться или уверенно выдать несуществующий факт: такие ответы называют галлюцинациями. Если цену ошибки не продумать заранее, продукт застревает в пилоте: по данным ИТ-компании «Инфосистемы Джет» и аналитического агентства Smart Ranking, из-за нестабильного качества ответов 40% крупных компаний не могут масштабировать ИИ-пилоты.

Качество зависит от данных. Сильная модель всё равно плохо ответит на вопрос о внутренних правилах компании, если не видела её документов.

Каждый запрос стоит денег. Поставщики берут плату за токены — фрагменты текста, на которые модель делит запрос и ответ. Расходы растут вместе с аудиторией.

Модели быстро меняются. У GigaChat API от Сбера за неполные два года вышло шесть обновлений моделей, а после обновления ответы «той же» модели могут заметно измениться.

Есть правовые рамки. Данные пользователей подчиняются закону о персональных данных, а летом 2026 года появился профильный закон об ИИ.

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

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

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

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

Пример выбран не случайно. По данным «Инфосистемы Джет» и Smart Ranking, контакт-центр и поддержка — самый частый сценарий ИИ в крупном бизнесе: там его применяют 75% компаний. Авторы объясняют это так: ИИ быстрее приживается там, где у процесса уже есть цифровой след, операция повторяется, а результат можно проверить.

Специфика ИИ видна в двух дополнительных вопросах. Первый — нужен ли здесь ИИ вообще. Модель выигрывает, когда на вход приходит что-то неструктурированное: письмо клиента, договор, вопрос в свободной форме. Ещё лучше, если операция повторяется, а результат можно проверить, как в поддержке из нашего примера. Если задачу закрывает правило вида «платёж больше 100 000 ₽ отправить на проверку», нейросеть только удорожит продукт.

Второй — во что обойдётся ошибка. Неточный черновик письма стоит пары минут правки, неверный расчёт платежа — куда дороже, и там ответ модели проверяет человек. Бизнес в этом осторожен: только 8% крупных компаний из выборки «Инфосистемы Джет» готовы доверить ИИ решения со средним и высоким уровнем риска.

Ценность можно проверить ещё до появления модели методом «Волшебник страны Оз»: пользователь общается с системой, а отвечает ему человек. Название методу дал исследователь IBM Дж. Ф. Келли в статье 1984 года.

Собрать такой тест несложно. Допустим, команда проверяет сервис, где ИИ разбирает резюме под конкретную вакансию: соискатель загружает файл, а первые недели разбор вручную пишет HR-специалист. Если люди возвращаются с новыми вакансиями и готовы платить, гипотеза жива. Если нет, команда сэкономила месяцы разработки.

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

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

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

Вариантов три, по возрастанию цены и сложности.

У первого варианта есть и практическое подтверждение: самую заметную отдачу крупные компании видят в работе с корпоративными знаниями через RAG, этот сценарий назвали 63% участников исследования «Инфосистемы Джет» и Smart Ranking.

Среди российских вариантов — GigaChat API от Сбера, причём веса последних версий GigaChat открыты по лицензии MIT и модель можно развернуть на своих серверах. Открытую модель T-Pro 2.0 выпускает Т-Банк, а каталоги вроде Evolution Foundation Models от Cloud.ru дают доступ к разным моделям через один интерфейс.

Тут же считают себестоимость. Условный расчёт по тарифам GigaChat API для действующих клиентов на октябрь 2026 года: GigaChat Max стоит 0,65 ₽ за 1 000 токенов, так что черновик примерно в 3 000 токенов вместе с вопросом клиента и найденными регламентами обойдётся в 1,95 ₽. Тарифы меняются быстро: летом 2025 года тот же GigaChat Max стоил втрое дороже, и такой черновик обошёлся бы в 5,85 ₽. Поэтому расчёт обновляют вместе с ценами.

Себестоимость черновика уходит в юнит-экономику — расчёт выручки и расходов на единицу продукта, в нашем примере на одно обращение. Черновик окупается, если сэкономленное время оператора стоит дороже, чем он сам. Возьмём нижнюю границу: при зарплате на уровне МРОТ в 27 093 ₽ и норме 1 972 рабочих часа в 2026 году минута работы оператора стоит около 2,75 ₽. Значит, черновик окупается, даже если экономит всего минуту.

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

Чек-лист стоит воротами между этапами создания ИТ-продукта с искусственным интеллектом. MVP строят, если выполнены все условия, иначе дешевле вернуться на шаг назад:

На выходе: прототип на тестовых данных, расчёт себестоимости и пройденный чек-лист. Навыки продакта — работа с данными, юнит-экономика и постановка задач технической команде.

MVP решает одну задачу для одного сегмента пользователей. Для ИИ-продукта это часто бот в Telegram, простое веб-приложение или новая функция в продукте, которым люди уже пользуются. Помощнику операторов для старта хватит кнопки «Черновик ответа» в окне, где оператор отвечает клиенту.

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

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

Команда MVP небольшая: продакт-менеджер, разработчик, дизайнер и, если нужно дообучение, ML-инженер — специалист по машинному обучению. Главное решение продакта здесь — чего в MVP не будет. Собрать прототип руками поможет наша инструкция по созданию первого ИИ-агента.

На выходе: MVP у первых пользователей и настроенный сбор обратной связи. Навыки продакта — приоритизация и управление командой.

После запуска MVP команде нужны данные, чтобы решить его судьбу. Этот шаг часто пропускают: по данным «КОРУС Консалтинг», 44% опрошенных компаний вообще не измеряют эффект от ИИ, ещё 25% следят за отдельными показателями, не связывая их с деньгами. Вместе это больше двух третей. Похожую картину показывает исследование «Инфосистемы Джет»: 46% крупных компаний признались, что ИИ-проекты закрываются ещё на пилоте, не дав ожидаемого экономического эффекта.

Метрику успеха задают на первом этапе, а смотрят на трёх уровнях:

В помощнике операторов три слоя превращаются в конкретные цифры: доля черновиков без фактических ошибок, доля черновиков, отправленных без правки, и время обработки обращения.

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

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

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

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

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

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

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

Тем, кто уже работает продактом или тимлидом и хочет добавить к своей базе работу с ИИ, подойдёт курс «Управление ИИ-продуктами»: он сосредоточен на ИИ-части цикла — от постановки задач ML-команде и ИИ-пилота до метрик и окупаемости.

Путь от идеи до MVP укладывается в четыре этапа, и на каждом нейросеть добавляет свою специфику: