Жизненный цикл AI‑проекта: как пройти путь от идеи до работающей системы

Современный AI‑проект можно запустить за несколько дней (да что там дней — при желании, за несколько часов): подключить готовую модель, загрузить документы прописать задачи и получить убедительный прототип. И именно эта кажущаяся простота и скорость часто вводят бизнес в заблуждение, ведь не один действительно рабочий ИИ‑проект не обходится без качественной работы с данными, продуманных интеграций, обучения сотрудников и постоянного контроля со стороны человека. В текущей статье разберем, из каких этапов состоит проект и что нужно сделать на каждом из них, чтобы все действительно заработало.

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

Рассмотрим этапы запуска ИИ проекта подробнее.

Этап 1. Определение задачи

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

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

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

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

Этап 2. Получение данных и их проверка

В классическом машинном обучении на этом этапе собирали набор примеров для обучения модели. В современных проектах чаще требуется открыть системе доступ к данным самой компании: CRM, записям звонков, документам, переписке, справочникам и базе знаний.

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

Чтобы понять, готова ли компания к внедрению ИИ нужно для начала ответить на три простых вопроса:

1. Где физически лежит нужная информация?
2. Можно ли получать ее программно, например через API, или сотрудник должен каждый раз присылать файл?
3. Насколько информация актуальна и кто отвечает за исправления?

Пока на эти вопросы нет ответов — говорить об ИИ‑преобразовании компании пока рано.

Объясню на примере: в проекте для гостинично‑медицинского бизнеса мы объединяли заявки из нескольких источников в CRM и подготовка интеграций и правил работы с данными оказалась объемнее разработки самого ИИ‑компонента. Это нормальная ситуация: модель умеет обработать полученный текст, но не может догадаться, какая из трех клиентских карточек актуальна и почему сотрудники по‑разному заполняют одно поле. Также при наведении порядка в данных, нужно определить границы безопасности: что разрешено передавать внешнему провайдеру? Что должно обрабатываться внутри корпоративного контура? Нужно ли удалять персональные сведения? Кто получит доступ к журналам работы системы? Эти решения лучше принять до прототипа, иначе удачное демо придется собирать заново на другой архитектуре.

Этап 3. Сборка прототипа и выбор архитектуры

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

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

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

Этап 4. Проверка системы на реальных ситуациях

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

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

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

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

Этап 5. Встраивание решения в ежедневную работу

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

Для первых запусков хорошо работает режим «черновик на утверждение». В нашей операционной работе звонки автоматически расшифровываются, агенты распределяют договоренности по проектам и готовят письма, но перед отправкой результат проверяет человек. Сотрудники видят, как работает система, а команда разработки получает исправления и пополняет тестовый набор. Автономность можно увеличивать постепенно: сначала агент только предлагает действие, затем самостоятельно выполняет безопасные типовые операции и передает исключения. Уровень доверия должен опираться на статистику качества, а не на впечатление от нескольких удачных ответов.

Этап 6. Оценка качества и экономического результата

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

Поэтому после запуска ИИ‑проекта ему нужны два контура наблюдения. Первый — это наблюдение за работой системы (ведение журнала действий, определение доли успешных операций, числа исправлений человеком, причин эскалаций и инцидентов) и второй контур наблюдения должен показывать пользу для бизнеса: ту самую метрику, которую мы выбрали при постановке задачи на первом этапе. Если обработка заявки ускорилась, но менеджеры стали тратить больше времени на исправления — проект нельзя считать успешным, равно как и в случае, когда система работает точно, но ею пользуется только один энтузиаст… Разделение технических и бизнес‑показателей помогает понять, куда возвращаться и что исправлять!

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

Почему жизненный цикл замыкается

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

С чего начать: краткий чек‑лист

1. Выберите одну дорогую или медленную операцию (на самом деле выбор инициатив для ииизации на практике более сложен, но это тема для отдельного материала). Опишите, кто выполняет ее сейчас, какие данные нужны и сколько времени она занимает.
2. Выберите ответственного за процесс. Он будет принимать результат, собирать обратную связь и отвечать за изменения после запуска.
3. Зафиксируйте метрику до начала разработки. Иначе доказать экономический эффект будет невозможно.
4. Проверьте доступность и качество данных. Не ограничивайтесь ответом «они у нас есть» — выясните, где они хранятся и как система будет их получать.
5. Соберите прототип на реальных примерах. Используйте его для проверки гипотезы, а не как обещание готового продукта.
6. Создайте золотой набор и режим приемки. На старте безопаснее, когда ИИ готовит черновик, а сотрудник утверждает результат.
7. После запуска следите и за качеством, и за деньгами. Ошибки пополняют тесты, а бизнес‑метрика показывает, стоит ли развивать сценарий дальше.

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