Сколько времени нужно на разработку ИИ-решения для бизнеса

Разработка ИИ-решения для бизнеса обычно занимает от нескольких недель для ограниченного прототипа до нескольких месяцев для системы, связанной с корпоративными данными и внутренней инфраструктурой. Простой ИИ-бот можно подготовить за 2–5 недель, интегрированный MVP — за 1–3 месяца, а кастомный продукт с несколькими контурами данных, повышенными требованиями к безопасности и собственной ML-логикой — за 3–6 месяцев или дольше. Это ориентиры, а не нормативные сроки.

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

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

Содержание

Что именно считать разработкой ИИ-решения

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

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

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

Сколько времени занимают разные типы ИИ-проектов

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

Тип проекта	Что входит в первую версию	Ориентир по сроку
Прототип одной гипотезы	Один сценарий, тестовые данные, минимум интерфейса	От нескольких дней до 2–3 недель
ИИ-бот с ограниченной базой знаний	Один канал, ответы по документам, базовые ограничения и тесты	2–5 недель
Автоматизация с ИИ-этапом	Обработка писем, документов или заявок, одна-две интеграции	3–8 недель
Интегрированный MVP	Рабочий интерфейс, корпоративная база знаний, CRM или другая система, логирование	1–3 месяца
ИИ-агент для нескольких систем	Несколько действий и ролей, права доступа, контроль операций, передача человеку	2–4 месяца
Кастомный ИИ-продукт	Несколько модулей, сложные данные, высокая нагрузка, безопасность и промышленная эксплуатация	3–6 месяцев и более
Собственная ML-модель	Сбор и разметка данных, обучение, оценка, внедрение и MLOps	От нескольких месяцев

Диапазоны в таблице — редакционный ориентир, синтезированный из типовой последовательности работ и оценок профильных разработчиков. Например, один из предоставленных источников оценивает простого Telegram-бота в 2–3 недели, решение с RAG — в 3–5 недель, интеграцию ИИ в существующий сервис — в 3–6 недель, а SaaS-продукт с ИИ-функциями — от восьми недель. Эти оценки нельзя переносить на конкретный проект без обследования данных и интеграций.

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

Из каких этапов складывается календарный план

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

Обследование процесса и постановка задачи

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

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

Подготовка данных и проектирование архитектуры

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

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

Разработка прикладной логики и интеграций

На реализацию ограниченного решения обычно требуется несколько недель; сложная интеграционная часть может занять месяцы. Команда создает интерфейс или канал общения, подключает модель, реализует обработку ошибок, бизнес-правила, авторизацию, журнал действий и обмен с CRM, ERP, телефонией, хранилищами или внутренними API.

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

Оценка качества и приемочные испытания

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

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

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

Пилот, запуск и стабилизация

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

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

Какие факторы сильнее всего влияют на срок

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

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

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

На срок также влияют:

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

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

Прототип, MVP и промышленная система: в чем разница

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

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

Промышленная система рассчитана на регулярную эксплуатацию. К ней добавляются управление доступами, наблюдаемость, резервные сценарии, контроль затрат, эксплуатационная документация, поддержка и процедура обновления. Для классических ML-систем Google Cloud отдельно выделяет проверку данных и модели, сравнение новой версии с действующей и онлайн-валидацию перед переводом всего трафика.

Переход от прототипа к промышленному решению редко сводится к «дописать несколько функций». Основное время уходит на превращение удачного эксперимента в управляемый элемент корпоративной инфраструктуры.

Почему проекты выходят за первоначальный график

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

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

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

Еще один источник задержек — приемка по субъективному впечатлению. Требование «бот должен отвечать хорошо» нельзя воспроизводимо проверить. До разработки нужны примеры запросов, ожидаемое поведение, запрещенные ответы, допустимая доля ошибок и правила эскалации. Метрики могут сочетать автоматическую проверку и оценку профильных специалистов.

Можно ли ускорить разработку без потери качества

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

Готовые модели, облачные API и no-code-платформы ускоряют проверку гипотезы, когда сценарий стандартный и требования к инфраструктуре допускают их использование. Они не отменяют подготовку данных и проектирование процесса. Если платформа уже умеет подключать нужный канал, технический запуск может занять дни, но актуализация базы знаний и приемочные испытания потребуют отдельного времени.

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

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

Как получить реалистичную оценку от подрядчика

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

В запросе на оценку стоит зафиксировать:

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

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

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

Почему запуск не завершает работу над ИИ

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

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

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

Как планировать срок, чтобы ИИ-проект дошел до эксплуатации

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

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

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

FAQ

Можно ли разработать ИИ-решение за две недели?

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

Что занимает больше времени: модель или интеграции?

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

Нужен ли бизнесу собственный ИИ с нуля?

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

С какого проекта лучше начинать внедрение?

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

Нужно ли включать пилот в срок разработки?

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

Можно ли заранее назвать точную дату запуска?

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

Об авторе

Игорь М.

Chief Editor

Игорь М. — Chief Editor в компании Полигант, отвечает за редакционную стратегию и качество публикуемого контента. Работает в сфере цифровых финансов, блокчейн-технологий и ИИ более 6 лет.

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

Актуальные статьи: