Этапы внедрения ИИ: от аудита до продакшена
Семь этапов от цели в метрике до промышленной эксплуатации: что делается на каждом, какие артефакты остаются, кто отвечает и где проект рвётся чаще всего. С планом на 90 дней и дорожной картой на год.
Внедрение ИИ разваливается не на технологиях, а на порядке действий: компании начинают с выбора модели и заканчивают вопросом «а зачем мы это сделали». Правильная последовательность обратная — сначала цель проекта ИИ в терминах одной бизнес-метрики, затем стратегия внедрения ИИ и план проекта ИИ на ближайшие 90 дней, и только потом разработка. Ниже — семь этапов внедрения ИИ, которые я прохожу с фаундерами: что делается на каждом, какие артефакты остаются на выходе и где процесс рвётся чаще всего.
Этап 0. Цель внедрения ИИ: рамка, в которой считается всё остальное
Цель внедрения ИИ — это одно число в P&L, которое должно измениться к заданной дате, с фамилией человека, отвечающего за это число. Всё остальное — «повысить эффективность», «не отстать от рынка», «попробовать нейросети» — не цель, а настроение. С настроением нельзя закрыть проект, потому что нечем доказать, что он закончился.
Рабочая формулировка состоит из пяти элементов: метрика, текущее значение, целевое значение, срок, владелец. Например: «доля заявок, обработанных без участия менеджера, с 0% до 40% за 4 месяца, владелец — коммерческий директор». Такая цель проекта ИИ проверяема, её нельзя тихо переформулировать в середине пути.
Важно развести две цели, которые постоянно путают. Цель разработки ИИ — техническая: качество ответов на контрольной выборке, скорость, стоимость запроса, отказоустойчивость. Цель внедрения ИИ — денежная: сокращённое время цикла, снятая нагрузка, выросшая конверсия. Модель может выполнить первую цель и полностью провалить вторую — если её никто не использует в реальном процессе.
- «Внедрить ИИ в компанию до конца года».
- «Автоматизировать рутину с помощью нейросетей».
- «Сделать ИИ-ассистента для сотрудников».
- «Быть в рынке, у конкурентов уже есть».
- Среднее время подготовки коммерческого предложения — с 6 часов до 40 минут за 3 месяца.
- Стоимость обработки одной входящей заявки — минус 30% при сохранении конверсии.
- Просроченная дебиторка старше 60 дней — минус 15% за полугодие.
- Каждая цифра — с владельцем, датой замера и способом проверки.
Актуальность внедрения ИИ определяется не новостями рынка, а внутренней арифметикой: есть ли у вас процесс с высокой частотой повторений, понятной стоимостью одной операции и терпимой ценой ошибки. Если операция выполняется трижды в месяц — экономить на ней нечего, каким бы сильным ни был инструмент. Что вообще считать внедрением и почему четыре пилота из пяти не доходят до прибыли, я разбираю в материале про внедрение ИИ в бизнес на языке P&L; там же логика выбора первого процесса.
Проект без объявленной метрики не проваливается — он растворяется. Это хуже провала: провал хотя бы чему-то учит.Владимир Герасимов
Что требуется для внедрения ИИ в организацию до старта
До первой строки кода организация должна закрыть шесть позиций. Это не бюрократия: каждая из них в моей практике хотя бы раз становилась причиной, по которой готовое решение осталось лежать в тестовом контуре.
- Спонсор с бюджетом. Человек уровня собственника, CEO или CFO, который защищает проект, когда он замедляется на втором месяце.
- Владелец процесса. Тот, чью метрику меняем. Если владельца нет, менять нечего и некому.
- Доступ к данным. Выгрузки за 6–24 месяца, а не обещание «дадим, когда понадобится». Согласование доступа занимает больше времени, чем сама разработка.
- Описанный процесс as-is. Хотя бы на одну страницу: кто, что, чем, за сколько времени, с какой ошибкой.
- Бюджет на две итерации. Первая версия почти никогда не попадает в цель. Проект, у которого хватает денег ровно на один заход, статистически обречён.
- Юридический и информационный контур. Решение о том, какие данные могут покидать периметр компании, принимается до старта, а не после инцидента.
- Нет ни одного процесса, который повторяется чаще 100 раз в месяц.
- Данные существуют только в головах сотрудников и в переписке.
- Инициатор — ИТ-отдел, а бизнес-заказчик не назван.
- Компания в кассовом разрыве: ИИ-проект — не антикризисный инструмент, эффект наступает через кварталы.
RACI: кто владелец, кто спонсор, кто эксплуатирует
Роли фиксируются письменно до старта. Схема ниже — минимальный состав, который я считаю рабочим для компании от 500 млн ₽ выручки; в меньших командах роли совмещаются, но не исчезают.
| Роль | Статус в RACI | За что отвечает | Чем меряется |
|---|---|---|---|
| Спонсор (собственник, CEO, CFO) | Accountable | Бюджет, приоритет, решение «продолжаем / останавливаем» | Изменение целевой метрики P&L |
| Владелец процесса | Responsible | Постановка задачи, приёмка, перевод людей на новый регламент | Доля операций, реально идущих через новый контур |
| Продуктовый лид / архитектор | Responsible | Декомпозиция, выбор подхода, оценочный набор, сроки | Качество на контрольной выборке, срок этапа |
| Инженеры и разработчики | Responsible | Данные, прототип, промышленная сборка, интеграции | Стабильность, latency, стоимость запроса |
| ИБ и юрист | Consulted | Периметр данных, договорной контур, персональные данные | Отсутствие блокирующих замечаний на приёмке |
| Эксплуатация / поддержка | Responsible после запуска | Мониторинг, инциденты, обновление подсказок и правил | Время реакции, доля деградаций, замеченных до жалобы |
| Линейные сотрудники | Informed | Использование инструмента, обратная связь по ошибкам | Частота использования, количество возвратов на ручную обработку |
Самая частая поломка на этом уровне: спонсор и владелец процесса — один и тот же человек, а эксплуатацию никто не берёт. Через два месяца после запуска решение живёт без хозяина и медленно деградирует. Кого нанимать, кого обучать и какие компетенции покупать на рынке — в разборе про команду и специалистов по ИИ.
Этап 1. Аудит бизнес-процессов под внедрение ИИ
Аудит бизнес-процессов под внедрение ИИ — это инвентаризация операций компании по четырём параметрам: частота, трудоёмкость, вариативность и цена ошибки. Задача аудита не «найти, где применить нейросеть», а найти места, где повторяющаяся ручная работа стоит компании измеримых денег. Типовой срок — 2–4 недели при участии владельцев процессов.
| Что измеряем | Как измерить | Порог интереса |
|---|---|---|
| Частота операции | Выгрузка из CRM/ERP, счётчик за 3 месяца | от 100–200 раз в месяц |
| Трудоёмкость | Хронометраж на выборке 10–20 случаев | от 15 минут на операцию |
| Доля решений по правилам | Ручной разбор 30 кейсов | 60% и выше — хороший кандидат |
| Цена ошибки | Стоимость исправления × частота | Ошибка терпима и обратима |
| Наличие данных | Где лежит история: система, файл, почта | Есть структурированная история от 6 месяцев |
| Готовность людей | Кто теряет и кто выигрывает от изменения | Есть выигрывающий с полномочиями |
На выходе аудита должны остаться четыре артефакта, а не презентация: карта процесса as-is с точками потерь, реестр операций с объёмами и трудоёмкостью, реестр источников данных с владельцами доступа, список ограничений (юридических, интеграционных, кадровых). Эти артефакты дальше используются на каждом этапе — они и есть основа разработки ИИ.
В половине компаний, где я проводил аудит, самая денежная гипотеза находилась не там, где её ждали. Ждали ИИ в продажах — а находили в подготовке документов, согласованиях и разборе входящей почты: тише, скучнее, но с понятным объёмом часов и без сопротивления коммерческого блока.
Разберу ваши процессы по параметрам из таблицы выше и отдам реестр операций с оценкой эффекта в рублях — до того, как вы потратите бюджет на разработку.
Этап 2. Отбор гипотез: матрица «эффект × сложность»
Приоритизация решает судьбу проекта сильнее, чем выбор модели. Из реестра операций формируется список гипотез, каждая оценивается по двум осям — денежный эффект за год и сложность реализации — и попадает в один из четырёх квадрантов. Первым в работу идёт только правый верхний: высокий эффект при низкой сложности.
| Квадрант | Что это значит | Решение |
|---|---|---|
| Высокий эффект / низкая сложность | Частый процесс, данные есть, интеграция простая | Первый пилот. Один, не три |
| Высокий эффект / высокая сложность | Деньги видны, но нужны данные, интеграции, регламенты | Второй–третий квартал дорожной карты |
| Низкий эффект / низкая сложность | Быстро, дёшево, почти незаметно в P&L | Отдать сотрудникам как самостоятельную автоматизацию |
| Низкий эффект / высокая сложность | Красивая демонстрация, дорогая эксплуатация | Не делать. Вообще |
Скоринг я держу простым: годовой эффект в рублях × вероятность успеха (0,3–0,8 по честной оценке команды) ÷ оценка сложности в человеко-месяцах. Числитель считает бизнес, знаменатель — инженер, и спор между ними полезен. Именно на этом шаге отсекаются красивые направления разработки ИИ, у которых нет ни данных, ни владельца.
Здесь же фильтруются входящие предложения по внедрению ИИ от подрядчиков. Их удобно проверять одним вопросом: какую нашу метрику и на сколько это изменит за квартал. Если ответ звучит как перечень возможностей ИИ и разработки под них, но без метрики — это продажа технологии, а не решения задачи. Как считать эффект в рублях и из чего складывается смета, подробно разобрано в статье про стоимость внедрения ИИ и расчёт ROI.
Этап 3. Проверка данных — основа разработки ИИ
Данные проверяются до пилота, а не в его середине. Разработка ИИ основана на истории: если истории нет, нет и предмета для обучения, а есть только генерация текста по инструкции — это другой класс задач и другая экономика. Проверка занимает 1–2 недели и стоит дешевле, чем месяц разработки в никуда.
- Наличие и глубина. Сколько месяцев истории доступно в машиночитаемом виде, а не в PDF и скриншотах.
- Полнота. Какая доля записей содержит нужные поля. Ниже 70% заполненности задача превращается в проект по наведению порядка в данных.
- Согласованность. Один и тот же контрагент в трёх системах называется одинаково? Обычно нет.
- Разметка. Есть ли примеры «правильных» решений, на которых можно измерять качество. Без них качество не с чем сравнивать.
- Право использовать. Персональные данные, коммерческая тайна, договорные ограничения с контрагентами.
- Оценочный набор. 100–300 реальных кейсов с эталонными ответами, зафиксированных до старта разработки.
Самая дорогая ошибка этапа — начать разработку, договорившись о качестве «на глаз». Без оценочного набора приёмка превращается в спор вкусов: подрядчик показывает удачные примеры, заказчик — неудачные, и обе стороны правы. Оценочный набор фиксируется до старта и не меняется задним числом. Правовой контур и остальные способы потерять деньги я разбираю в материале про риски и проблемы внедрения ИИ.
Этап 4. Пилот с заранее объявленным критерием провала
Пилот — это ограниченный по сроку эксперимент, у которого до старта письменно объявлены критерий успеха и критерий провала. Типовая длительность — 4–8 недель, один процесс, одна команда, ограниченный объём операций. Пилот без объявленного критерия провала не заканчивается никогда: его всегда можно «ещё немного доработать».
- Зафиксировать базуЗамерить текущие показатели процесса до внедрения: время, стоимость, ошибки. Без базы прирост доказать невозможно.
- Объявить порогиУспех: например, 80% операций проходят без правок человека при качестве не ниже эталона. Провал: ниже 50% после двух итераций.
- Ограничить контурОдно подразделение, один тип операций, 2–5 пользователей. Расширение — только после прохождения порога.
- Работать в режиме «человек проверяет»Первые недели ИИ готовит, сотрудник подтверждает. Так собирается разметка ошибок для следующей итерации.
- Принять решение по трём вариантамМасштабируем, переделываем подход, закрываем. Третий вариант обязан быть разрешённым — иначе первые два обесцениваются.
Провалившийся пилот — нормальный результат, если он стоил 5–10% годового бюджета направления и дал понимание, где именно рвётся процесс. Ненормально — тянуть пилот девять месяцев, потому что признать неудачу дороже репутационно, чем финансово.
Помогу сформулировать пороги успеха и провала, собрать оценочный набор и выбрать один процесс из вашего списка вместо трёх параллельных экспериментов.
Этап 5. Промышленная разработка: процесс, методы и подходы
Промышленная разработка отличается от пилота не объёмом кода, а требованиями: отказоустойчивость, логирование, права доступа, воспроизводимость результата и стоимость эксплуатации. Этапы разработки ИИ на этой стадии выстраиваются в жёсткую последовательность, где каждый шаг заканчивается проверяемым артефактом.
- Техническая постановка. Границы задачи, форматы входа и выхода, что система делать не должна.
- Контур данных. Пайплайн загрузки, очистки, хранения; политика удаления и доступа.
- Базовое решение. Самый простой работающий вариант — правила, поиск, готовая модель. Он же становится точкой отсчёта.
- Итерации по качеству. Каждая итерация измеряется на одном и том же оценочном наборе.
- Нагрузка и безопасность. Поведение под пиком, ограничение прав, защита от утечки данных в запросах.
- Приёмка. Формальная сдача по объявленным метрикам, с протоколом и списком известных ограничений.
Методы разработки ИИ выбираются по данным, а не по моде. Правила и классические алгоритмы — там, где логика детерминирована и цена ошибки высока. Поиск по базе знаний с генерацией ответа — там, где ответ должен опираться на ваши документы. Дообучение — когда есть тысячи размеченных примеров и стабильный формат. Комбинация — чаще всего. Подходы к разработке ИИ, которые я считаю рабочими, сводятся к трём принципам: сначала baseline, затем усложнение; измеряем каждую итерацию; любое усложнение обязано окупаться приростом метрики.
Методы внедрения подсказок и продуктивность команды
Отдельная инженерная дисциплина — методы внедрения подсказок в ИИ-контур: библиотека промптов хранится в репозитории, версионируется, каждая правка прогоняется по регрессионному набору. Подсказка, изменённая «на живую» в продакшене без прогона, — это неконтролируемый релиз, только без code review.
Запрос «увеличь продуктивность разработки с AI-driven подходом» имеет смысл ровно там, где у команды уже есть тесты, ревью и понятная кодовая база. В проектах, которые я видел, AI-driven инструменты дают ускорение на 10–30% на типовом коде и почти ничего не дают на сложной доменной логике, зато увеличивают объём кода, который потом нужно поддерживать. Что именно ускоряется в инженерии, разобрано отдельно в статье про ИИ для разработки ПО.
Этапы 6–7. Интеграция, регламенты и эксплуатация
Решение начинает приносить деньги не в момент запуска, а в момент, когда старый способ работы становится недоступен. Между этими двумя событиями в среднем проходит от одного до трёх месяцев, и именно здесь теряется большая часть заявленного эффекта.
Интеграция в существующие системы
ИИ-контур подключается к тому, где реально живёт процесс: 1С, CRM, ERP, почта, мессенджеры, внутренний портал. Инструмент, требующий отдельного окна и ручного копирования, используется первые две недели, а потом тихо забывается. Способы подключения, локальные модели и контур безопасности — в материале про интеграцию ИИ в существующие системы.
Регламенты и люди
Меняется должностная инструкция, а не только интерфейс. Нужно письменно ответить: кто и что теперь делает, в какой момент человек обязан перепроверить результат, что делать при отказе системы, кому эскалировать спорный случай. Обучение — 2–4 часа практики на реальных задачах, а не рассылка с инструкцией.
Эксплуатация и мониторинг деградации
Качество ИИ-решения падает со временем само: меняются данные, поставщики моделей обновляют версии, процесс обрастает исключениями. Поддержка внедрения ИИ — это не «починить, если сломается», а регулярный замер по контрольному набору и бюджет на доработки.
| Что мониторим | Метрика | Частота | Порог реакции |
|---|---|---|---|
| Качество ответов | Доля правильных на контрольном наборе | Еженедельно | Падение более 5 п.п. к базе |
| Использование | Доля операций через новый контур | Еженедельно | Ниже 60% от плана |
| Возвраты на ручную обработку | Количество и причины | Ежедневно первые 4 недели | Рост две недели подряд |
| Стоимость эксплуатации | Расход на 1000 операций | Ежемесячно | Рост более 20% без роста объёма |
| Инциденты и отказы | Время недоступности, время реакции | Постоянно | Любой отказ дольше SLA |
Масштабирование
Активное внедрение ИИ начинается только после того, как первый контур отработал в продакшене 8–12 недель без деградации. Тогда компоненты — доступ к данным, библиотека подсказок, регламенты, мониторинг — переиспользуются на соседних процессах, и второй проект стоит заметно дешевле первого. Ошибка обратного порядка — запускать пять направлений одновременно «чтобы быстрее» — гарантированно даёт пять недоведённых пилотов.
План первых 90 дней и дорожная карта внедрения ИИ на 12 месяцев
План внедрения ИИ на 90 дней нужен для того, чтобы через квартал существовал предмет разговора: работающий контур с замером или обоснованный отказ. Ниже — те же этапы внедрения ИИ, разложенные по неделям: этапы работы над ИИ-проектом удобнее контролировать по артефактам, а не по календарю. Сроки сдвигаются, порядок — нет.
План на 90 дней
| Недели | Что делаем | Артефакт на выходе | Кто ведёт |
|---|---|---|---|
| 1–2 | Цель в метрике, ограничения, состав команды | Одностраничная рамка проекта, RACI | Спонсор |
| 3–5 | Аудит процессов, замер базовых показателей | Реестр операций, карта as-is | Владелец процесса |
| 5–6 | Отбор гипотез, матрица «эффект × сложность» | Одна выбранная гипотеза с оценкой эффекта | Продуктовый лид |
| 6–7 | Проверка данных, сбор оценочного набора | Оценочный набор 100–300 кейсов | Инженер данных |
| 8–12 | Пилот в ограниченном контуре | Работающий прототип, замер против базы | Продуктовый лид |
| 13 | Решение: масштабируем, переделываем, закрываем | Протокол с цифрами и решением | Спонсор |
Дорожная карта на 12 месяцев
Дорожная карта проекта ИИ на год отвечает на вопрос «что будет после пилота» и защищает бюджет от переигрывания каждый квартал. Карта внедрения ИИ строится по кварталам, а не по технологиям.
| Квартал | Фокус | Результат квартала |
|---|---|---|
| Q1 | Рамка, аудит, первый пилот | Проверенная гипотеза и замер против базы |
| Q2 | Промышленная сборка, интеграция, регламенты | Первый процесс работает в продакшене, метрика подтверждена |
| Q3 | Стабилизация, мониторинг, вторая гипотеза | Переиспользуемый контур данных и подсказок, второй пилот |
| Q4 | Масштабирование на соседние процессы, обучение команды | 2–3 процесса в эксплуатации, внутренние компетенции, план на следующий год |
Такая дорожная карта внедрения ИИ намеренно скромна по числу направлений. Компании, которые в первый год довели до эксплуатации два-три процесса, в моей практике обгоняют тех, кто запустил десять пилотов и не закрыл ни одного.
С чего начать внедрение ИИ, если бюджет ноль
Начать внедрение ИИ без бюджета можно, и это не компромисс, а разумный первый шаг: 30 дней ручной работы дают больше информации, чем закупка платформы. Разработка ИИ с нуля вообще не нужна на старте — сначала проверяется, есть ли задача, стоящая денег.
- Неделя 1. ХронометражТри сотрудника фиксируют, на что уходит время, с точностью до получаса. Это бесплатно и почти всегда неожиданно.
- Неделя 2. Ручная имитацияСамая частая операция выполняется с помощью общедоступного ИИ-инструмента вручную, 20–30 раз. Замеряется время и доля годных результатов.
- Неделя 3. Лог ошибокСобираются случаи, где инструмент ошибся, с причиной. Этот лог позже становится оценочным набором.
- Неделя 4. АрифметикаЧасы × ставка × частота = верхняя граница экономии за год. Если это меньше стоимости самой простой автоматизации — задача закрывается, и это выигрыш.
Началом разработки ИИ я считаю не первую строку кода, а первый честный замер: сколько времени операция занимает сейчас и сколько занимает с инструментом. Ответ на вопрос «разработка ИИ — с чего начать» почти всегда один: с четырёх недель измерений и одного процесса, а не с выбора модели или платформы.
Где вести разработку ИИ: внутри, с подрядчиком или под ключ
Вопрос «разработка ИИ — где её вести» решается по трём критериям: критичность процесса, наличие внутренних компетенций и требования к данным. Универсального ответа нет, но есть три рабочие конфигурации, и выбирается та, которая соответствует зрелости компании.
| Модель | Когда подходит | Главный риск |
|---|---|---|
| Своя команда | ИИ — часть продукта, процессов много, данные чувствительные | Долгий старт: набор и разгон команды — 4–8 месяцев |
| Подрядчик на разработку | Задача понятна, нужен один-два контура, компетенции внутри отсутствуют | Знание уходит вместе с командой подрядчика |
| Гибрид: внешняя разработка + внутренний владелец | Большинство компаний среднего размера | Требует сильного внутреннего заказчика, иначе вырождается в первый вариант |
Услуги внедрения ИИ на рынке продаются в двух форматах. Первый — почасовая разработка: вы платите за руки и сами отвечаете за результат. Второй — внедрение ИИ под ключ: подрядчик берёт на себя постановку, разработку, интеграцию и обучение людей, а вы получаете работающий процесс. Внедрение ИИ в бизнес под ключ дороже на 20–40% при прочих равных, но в компаниях без внутренней экспертизы оно обычно дешевле по итогу — потому что не оплачивается второй заход.
Выбирая услуги разработки ИИ, я рекомендую смотреть не на портфолио демонстраций, а на три вещи: как подрядчик формулирует критерий провала, что он делает с вашими данными и что остаётся у вас после завершения работ — код, документация, оценочный набор, права. Купить проект ИИ целиком, как коробку, нельзя: коробочная часть — это 30–50% работы, остальное — ваши данные, ваш процесс и ваши регламенты. Поэтому решение «заказать проект ИИ» стоит принимать после аудита, а не вместо него.
Один процесс за раз. Метрика до старта. Критерий провала письменно. Оценочный набор до разработки. Владелец процесса из бизнеса, а не из ИТ. Бюджет на две итерации. Эксплуатация с хозяином и мониторингом. Всё остальное — детали реализации.
Если вы дошли до решения заказать разработку ИИ или заказать внедрение ИИ под конкретную задачу, самая дорогая ошибка — начать с выбора исполнителя. Сначала формулируется цель в метрике и проверяются данные: с этими двумя артефактами любой разговор с подрядчиком становится коротким и предметным, а услуги внедрения ИИ в бизнес превращаются из абстрактной покупки технологии в проект с проверяемым результатом.
За одну сессию сформулируем цель внедрения ИИ в метрике, отберём первую гипотезу и наметим дорожную карту — чтобы вы сравнивали предложения по существу, а не по обещаниям.
Частые вопросы
В проектах, которые я видел, аудит процессов занимает 2–4 недели, проверка данных — 1–2 недели, пилот — 4–8 недель, промышленная сборка с интеграцией — ещё 6–12 недель. Итого от старта до работающего процесса в продакшене обычно проходит 4–7 месяцев для первого контура.
Второй и третий процессы идут быстрее: контур данных, библиотека подсказок и регламенты уже существуют и переиспользуются.
Цель разработки ИИ — техническая: качество на контрольной выборке, скорость ответа, стоимость запроса, устойчивость под нагрузкой. Цель внедрения ИИ — денежная: изменение конкретной метрики в P&L к заданной дате.
Решение может полностью выполнить первую цель и провалить вторую, если люди продолжают работать по старому регламенту. Поэтому обе цели формулируются письменно и с разными владельцами.
С четырёх недель измерений без разработки: хронометраж работы трёх сотрудников, ручная имитация самой частой операции с помощью общедоступного ИИ-инструмента, лог ошибок и подсчёт верхней границы экономии за год.
Этот путь не требует бюджета и специалистов, но даёт главное — понимание, стоит ли задача разработки. Разработка ИИ с нуля на старте почти никогда не нужна.
Шесть позиций: спонсор с бюджетом, владелец процесса из бизнеса, доступ к данным за 6–24 месяца, описанный процесс as-is, бюджет минимум на две итерации и решённый вопрос, какие данные могут покидать периметр компании.
Если хотя бы одна позиция не закрыта, разработку лучше отложить: технически проект сделают, но в эксплуатацию он не перейдёт.
Купить проект ИИ целиком, как коробку, нельзя: типовая часть закрывает 30–50% работы, остальное — ваши данные, ваш процесс и ваши регламенты. Внедрение ИИ в бизнес под ключ, когда подрядчик берёт постановку, разработку, интеграцию и обучение людей, в среднем дороже почасовой разработки на 20–40%.
Для компаний без внутренней экспертизы такой формат обычно оказывается дешевле по итогу, потому что не оплачивается второй заход. Решение заказать разработку ИИ разумно принимать после аудита процессов, а не вместо него.
Сравнить результат с порогом, который был объявлен до старта, и выбрать один из трёх вариантов: масштабировать, переделать подход или закрыть направление. Третий вариант обязан быть разрешённым решением, иначе первые два теряют смысл.
Провалившийся пилот — нормальный результат, если он стоил 5–10% годового бюджета направления и объяснил, где именно рвётся процесс.
Полноценный документ на 40 страниц — нет. Нужна одностраничная рамка: целевая метрика, выбранный процесс, ограничения по данным, бюджет на две итерации и критерий остановки. Этого достаточно, чтобы проект не растворился.
Дорожная карта проекта ИИ на 12 месяцев добавляется после первого пилота, когда уже понятно, что именно масштабируется.
Владельцем должен быть руководитель, чью метрику меняет проект: коммерческий директор, директор по операциям, финансовый директор. ИТ отвечает за контур данных, безопасность и эксплуатацию, но не за бизнес-результат.
Проекты, где инициатором и владельцем выступает только ИТ-отдел, в моей практике чаще всего останавливаются на стадии удачной демонстрации.
Проверяются пять признаков: машиночитаемая история от 6 месяцев, заполненность нужных полей выше 70%, согласованность справочников между системами, наличие примеров правильных решений и право использовать данные с точки зрения закона и договоров.
Отдельно собирается оценочный набор из 100–300 реальных кейсов с эталонными ответами — без него качество разработки не с чем сравнивать, а приёмка превращается в спор вкусов.