# Этапы внедрения ИИ: от диагностики до эксплуатации

> Семь этапов внедрения ИИ по шагам: диагностика, формализация процесса, данные, модель и железо, пилот, продуктив, масштабирование. Сроки и результат каждого.

- Источник: https://lokai.ru/blog/etapy-vnedreniya-ii/
- Организация: Local AI — Внедрение ИИ в закрытом контуре
- Обновлено: 2026-08-07
- Раздел: Главная → Блог → Этапы внедрения

---

Внедрение ИИ проходит семь этапов: диагностика и выбор процесса, формализация с метрикой, подготовка данных, выбор модели и инфраструктуры, пилот, вывод в продуктив, масштабирование и сопровождение. До первого работающего пилота на типовом кейсе уходит 4–8 недель. Ниже — что происходит на каждом шаге, кто нужен со стороны заказчика, чем шаг заканчивается и где проекты обычно встают.

- **7** — этапов от разбора процессов до промышленной эксплуатации
- **4–8** — недель до первого работающего пилота на типовом кейсе
- **2–4** — недели занимает сам пилот на одном процессе
- **1** — процесс и одна метрика на старте — больше не берём

## Этапы внедрения ИИ: срок, результат и участие заказчика

Сроки в таблице — для типового процесса среднего бизнеса: один сценарий, две-три системы, данные в рабочем состоянии. Полный порядок работ под ключ описан на странице [внедрения ИИ](https://lokai.ru/vnedrenie-ii/).

*Этапы внедрения ИИ: длительность, результат этапа и роли на стороне компании*

| Этап | Срок | Результат | Кто нужен от заказчика |
|---|---|---|---|
| Диагностика и выбор процесса | 30–40 минут разбора плюс 2–3 дня расчёта | Карта процессов, ROI-модель, отобранный сценарий | Владелец процесса и человек с правом решения по бюджету |
| Формализация процесса и метрика | 3–7 дней | Схема шагов и развилок, метрика с замером «до» | Владелец процесса, руководитель подразделения |
| Подготовка данных | 1–3 недели | Индекс базы знаний, доступы, набор проверочных примеров | Носитель знаний, ИТ-специалист, служба безопасности |
| Выбор модели и инфраструктуры | 3–10 дней, параллельно с данными | Конфигурация железа, стек моделей, схема размещения | ИТ-директор или системный администратор |
| Пилот | 2–4 недели | Работающий сценарий и цифра «после» на одной метрике | Владелец процесса и 2–5 сотрудников на реальных задачах |
| Вывод в продуктив | 2–4 недели | Роли и доступы, регламенты, мониторинг, обученная команда | ИТ, служба безопасности, руководители пользователей |
| Масштабирование и сопровождение | итерации по 1–2 недели | Новые сценарии, еженедельные релизы с приёмкой | Администратор системы и владельцы новых сценариев |

## Этап 1. Диагностика и выбор процесса-кандидата

Первый этап не про технологии. Мы садимся с владельцем процесса и разбираем, из каких шагов он состоит, сколько операций проходит в месяц, сколько минут уходит на одну и во что обходится час людей, которые её выполняют. Со стороны компании нужны двое: тот, кто знает процесс изнутри, и тот, кто принимает решение по бюджету. Сам разбор занимает 30–40 минут.

Дальше 2–3 рабочих дня уходит на расчёт. На выходе — карта процессов с отметкой «передаём машине», «передаём с подтверждением человека», «оставляем людям», ROI-модель в таблице с вашими цифрами и один отобранный сценарий для пилота. У нас этап входит в работу бесплатно: как устроен [бесплатный аудит](https://lokai.ru/besplatnyy-audit-ii/), описано отдельно.

Застревают здесь на выборе. Компания хочет начать с самого болезненного процесса, а он же самый сложный: редкий, нестандартный, завязанный на согласования. Первый сценарий нужен другой — частый, повторяемый, с понятным критерием качества. Второй тупик: цифр по процессу нет ни у кого, и никто не готов оценить их даже навскидку. Как собрать эти цифры своими силами, разобрано в статье [с чего начать](https://lokai.ru/blog/s-chego-nachat-vnedrenie-ii/).

## Этап 2. Формализация процесса и выбор метрики

Процесс, который живёт в головах, автоматизировать нельзя. На этом шаге он раскладывается до шагов, развилок, входов и выходов: что приходит на вход, по каким признакам принимается решение, что считается хорошим результатом, а что браком. Работают владелец процесса и руководитель подразделения, от нас — аналитик. 3–7 дней, если люди доступны и встречи не переносятся.

Одновременно выбирается метрика — ровно одна на пилот. Время на операцию, доля обращений, закрытых без человека, конверсия квалифицированных лидов, срок подготовки отчёта. И снимается замер «до» из вашей системы, письменно согласованный обеими сторонами. Без цифры «до» любой результат потом можно оспорить, и спор этот выигрывает тот, кто громче.

Ловушка первая — метрика, которую нельзя посчитать без ручного подсчёта: «качество ответов», «удовлетворённость команды». Ловушка вторая — шесть метрик сразу: после пилота начинается спор, какая из них главная. Третий тормоз тише: процесс описывают таким, каким он записан в регламенте, а не таким, как он работает в реальности с обходными путями и исключениями.

## Этап 3. Подготовка данных и базы знаний

Самый недооценённый этап и обычно самый долгий: 1–3 недели. Нужно собрать то, на что модель будет опираться, — регламенты, инструкции, прайсы, спецификации, историю удачных решений — и привести в состояние, пригодное для поиска: убрать устаревшие версии, снять противоречия, отметить, где документ действует, а где отменён.

От компании нужен носитель знаний, который отличает актуальный регламент от прошлогоднего, ИТ-специалист для выгрузок и доступов и служба безопасности, если данные чувствительные. Заканчивается этап поисковым индексом и набором примеров «вопрос — правильный ответ», по которому дальше проверяется качество. Если планируется [дообучение модели](https://lokai.ru/doobuchenie-modeley/), здесь же собирается обучающая выборка.

Застревают тут почти все. Документы лежат в трёх местах в разных форматах, половина инструкций противоречит другой половине, а единственный человек, который помнит, как правильно, ушёл в отпуск. Утешение одно: разбор полезен сам по себе. Часть найденных проблем чинится переписанным регламентом за неделю и без всякого ИИ.

## Этап 4. Выбор модели и инфраструктуры

Модель выбирается после того, как известны задача, объём и требования к данным, а не до. Для текстовых и агентных сценариев обычно берём Qwen, DeepSeek, GLM или Kimi, для русской речи — GigaAM и T-one, для поиска по документам — multilingual-e5 или BGE-M3. Комбинация подбирается под задачу; каталог стека собран на странице [открытых моделей](https://lokai.ru/modeli/).

Параллельно считается железо: сколько запросов в пиковый час, какой нужен контекст, сколько людей работает одновременно. Отсюда GPU-конфигурация и вариант размещения — свой сервер, аренда выделенного или гибрид. Этап держит ИТ-директор или системный администратор, занимает 3–10 дней. Когда данные нельзя выпускать за периметр вообще, вариант один — [локальный контур](https://lokai.ru/lokalnyy-ii/).

Частая ошибка — закупить сервер до того, как посчитана нагрузка. Чаще берут избыточную конфигурацию, реже — недостаточную, и на пилоте выясняется, что памяти не хватает на нужный контекст. Второе место занимают сроки закупки: техническая часть решается за дни, тендер и поставка — за месяцы. Это планируют с самого начала, иначе весь график поедет.

## Этап 5. Пилот на одном процессе

Пилот — 2–4 недели, один процесс, одна метрика. Система собирается в рабочем виде и сразу встраивается туда, где люди уже сидят: Битрикс24, 1С, почта, телефония. Не отдельная вкладка для эксперимента — иначе замер получится про демонстрацию, а не про работу, и в продуктиве цифра развалится.

Со стороны компании нужны владелец процесса и 2–5 сотрудников, которые прогоняют через систему реальные задачи и отмечают ошибки. Заканчивается пилот цифрой «после», сравнением с замером «до» и списком того, что не сработало. У нас пилот стоит $3–5k, и сумма засчитывается в стоимость внедрения, если идём дальше.

Застревание номер один — пилот на подобранных примерах: точность отличная, на реальном потоке падает вдвое. Номер два — расползание объёма: к третьей неделе в пилот докладывают ещё три сценария, срок уезжает, метрика размывается. Отрицательный результат тоже результат — остановиться после пилота дешевле, чем после внедрения, и в этом весь смысл короткого платного шага.

## Этап 6. Вывод в продуктив

Разница между пилотом и продуктивом не в модели, а во всём, что вокруг. Настраиваются роли и права, SSO и разграничение доступа, журналирование действий, подтверждение человеком на каждом необратимом шаге, мониторинг качества и оповещения. Пишутся регламенты: что система делает сама, что отдаёт человеку, что делать при сбое и к кому идти.

Здесь подключаются ИТ, служба безопасности и руководители подразделений, где система пойдёт в работу. Отдельная часть — обучение: администратор на вашей стороне и владельцы сценариев должны уметь менять правила и читать дашборды без нас. Срок 2–4 недели, итог — промышленная эксплуатация и акт с зафиксированными показателями качества.

На этом шаге чаще всего вскрывается сопротивление команды: людям выдали инструмент, который меняет их работу, и никто не объяснил зачем. Лечится участием тех же сотрудников в пилоте и прямым разговором о том, что автоматизируется операция, а не человек. Второй риск — требования ИБ, всплывающие в последний момент. Их собирают ещё на диагностике, иначе запуск сдвигается на месяц.

## Этап 7. Масштабирование и сопровождение

После первого работающего сценария внедрение переходит в режим итераций по 1–2 недели: следующий процесс, следующий отдел, следующая интеграция. Порядок берётся из [дорожной карты](https://lokai.ru/blog/dorozhnaya-karta-vnedreniya-ii/), а не из очереди желающих: сначала то, что даёт эффект и опирается на уже подготовленные данные.

Сопровождение — не «поддержка по звонку». Мастер-система развивается ежедневно, раз в неделю выходит release candidate с полным changelog, каждый релиз версионирован и криптографически подписан, откат делается одним действием. Ни одно обновление не уходит в продуктив без ручной проверки человеком и без гейта на стороне заказчика. От компании нужен администратор системы и владелец каждого нового сценария.

Провал на этом этапе выглядит буднично: пилот сработал, эффект показали, а через полгода система обросла исключениями, за качеством ответов никто не следит и люди тихо вернулись к ручной работе. Помогают две вещи — цифровые KPI в дашборде руководителя и регулярная сверка факта с моделью. Как считается эффект, разобрано в статье про [эффекты внедрения](https://lokai.ru/blog/effekty-vnedreniya-ii/).

## Частые вопросы про этапы внедрения ИИ

**Сколько занимают все этапы внедрения ИИ вместе?**

На типовом кейсе от первой встречи до работающего пилота проходит 4–8 недель. Разброс объясняется не сложностью модели, а готовностью компании: если регламенты собраны, доступы дают за день и владелец процесса на связи, срок ближе к нижней границе. Если документы нужно искать по трём хранилищам, а закупка сервера идёт через тендер, к сроку добавляется от месяца. Вывод в продуктив после удачного пилота занимает ещё 2–4 недели, дальше система расширяется итерациями по 1–2 недели без пауз на переустановку.

**Можно ли пропустить пилот и сразу идти во внедрение под ключ?**

Технически можно, экономически — плохая идея. Пилот стоит $3–5k и засчитывается в стоимость внедрения, то есть при удачном исходе вы не теряете ничего, а при неудачном останавливаетесь, потратив стоимость короткого эксперимента вместо бюджета всего проекта. Пилот проверяет не только модель: он показывает, дают ли доступы, отвечает ли владелец процесса, есть ли данные нужного качества и как люди реагируют на новый инструмент. Эти вещи в презентации не видны и всплывают только на реальном потоке задач.

**Какой этап внедрения ИИ самый долгий и почему?**

Подготовка данных, 1–3 недели, а в компаниях с длинной историей и больше. Причина не техническая: выгрузить документы легко, а вот решить, какая версия регламента действует, какие инструкции противоречат друг другу и кто имеет право это утверждать, — работа человеческая и небыстрая. Второй по длительности этап — закупка железа, если сервер берут в собственность через тендерную процедуру. Оба срока сокращаются, если начать заниматься ими параллельно с формализацией процесса, а не после неё.

**Сколько людей со стороны компании нужно на проект?**

На пилоте обычно трое-пятеро и никто из них не занят полностью. Владелец процесса тратит несколько часов в неделю, ИТ-специалист подключается точечно на доступы и интеграции, 2–5 сотрудников работают через систему на своих обычных задачах и отмечают ошибки. На выводе в продуктив добавляются служба безопасности и руководители подразделений. Постоянная роль появляется одна — администратор системы, который к концу проекта умеет менять правила, добавлять документы в базу знаний и читать дашборды без нашего участия.

**Что делать, если пилот не показал заявленного эффекта?**

Сначала разобрать, где именно разошлись ожидание и факт: модель ошибается на определённом типе задач, данных не хватило, процесс оказался менее повторяемым, чем выглядел, или метрику выбрали не ту. В части случаев сценарий чинится за неделю дообучением или изменением правил маршрутизации. В части — вывод честный: этот процесс автоматизировать не стоит, и тогда мы говорим об этом прямо. Артефакты пилота остаются у вас: формализованный процесс, приведённые данные и замеры пригодятся и без нас.

**Нужен ли свой ИИ-специалист в штате, чтобы пройти эти этапы?**

Для старта не нужен. Требуются люди, которые знают процесс и данные, и один ИТ-специалист для доступов и интеграций. Компетенция по моделям приходит с нашей стороны. К концу внедрения на вашей стороне обучается администратор системы — обычно это действующий системный администратор или аналитик, который принимает на себя эксплуатацию. Собственный ИИ-инженер имеет смысл, когда сценариев становится больше десятка и компания хочет вести разработку сама; до этого штатная единица не окупается.

---

Бесплатный аудит и расчёт окупаемости на ваших данных: https://lokai.ru/besplatnyy-audit-ii/

Почта: hello@lokai.ru · 123112, Москва, ММДЦ «Москва-Сити» · Пн–Пт, 09:00–19:00 МСК
