С чего начать внедрение ИИ: 8 проверок перед разработкой пилота

Когда руководитель формулирует задачу как «нам нужен ИИ-ассистент», разработчику пока нечего оценивать. Не определено, какой процесс должен измениться, какие действия получит система и по какому результату компания поймёт, что проект сработал.

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

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

Пилот — не демонстрация возможностей модели

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

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

Microsoft описывает proof of concept как сфокусированную проверку технической реализуемости, бизнес-ценности и основных предположений до полномасштабной разработки.[2] Названия «PoC», «прототип» и «пилот» в компаниях используют по-разному. Важнее заранее договориться, какое решение должен дать эксперимент.

Проверки 1–4: процесс, владелец, метрика и данные

1. Выберите один процесс, а не направление целиком

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

Рабочую гипотезу лучше сформулировать так:

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

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

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

Перед разработкой зафиксируйте:

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

2. Назначьте владельца результата

У пилота должен быть человек со стороны бизнеса, который может ответить на три вопроса:

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

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

Нужны и реальные пользователи. Регламент описывает идеальный маршрут, а сотрудники знают исключения: неверные форматы, дубли в CRM и правила, существующие только в переписке. Без этих деталей пилот проверит вымышленный процесс. Google Cloud также связывает готовность к масштабированию с участием бизнеса и внутренних сторон.[6]

3. Зафиксируйте исходный показатель до автоматизации

Нельзя доказать улучшение, если компания не знает, что происходит сейчас. До разработки не нужна идеальная система аналитики, но нужна базовая точка сравнения.

Для выбранного процесса можно измерять:

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

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

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

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

4. Проверьте не объём данных, а их пригодность

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

Microsoft рекомендует до выбора сценария провести инвентаризацию источников, форматов, качества и доступности данных, а затем сопоставить проект с реальными ресурсами и возможностями компании.[1][2]

Для пилота нужно ответить:

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

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

Проверки 5–8: роль ИИ, ошибки, контур и критерии

5. Определите участок, где действительно нужен ИИ

После описания процесса часто выясняется, что модель нужна только в одном месте — или не нужна вообще.

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

Практическая схема обычно выглядит так:

входные данные → обычные проверки → ИИ-операция → валидация → бизнес-правила → запись в систему → журнал

Так модель не управляет всем процессом. Она решает конкретную задачу внутри контролируемого контура.

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

6. Опишите цену ошибки и передачу человеку

Вопрос «какую точность даст модель?» полезен только вместе с вопросом «что произойдёт, когда она ошибётся?».

Ошибки удобно разделить на три группы:

• допустимые — результат можно автоматически принять или проверять выборочно;
• исправимые — система должна передать случай сотруднику и сохранить исходные данные;
• критические — действие нельзя выполнять без подтверждения человека или жёсткого правила.

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

NIST рекомендует ещё до решения о разработке зафиксировать назначение системы, границы применения, ожидаемые выгоды и затраты от ошибок, а также процесс человеческого контроля. Проверка и измерение должны продолжаться на протяжении жизненного цикла решения, а не появляться после запуска.[3]

Если критическую ошибку невозможно обнаружить или ограничить, это не «минус один балл» в оценке готовности. Это блокирующее условие.

7. Спроектируйте рабочий контур, а не отдельный чат

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

До разработки нужно хотя бы схематично описать:

• откуда поступает событие: сайт, почта, Telegram, CRM, папка с документами;
• где сохраняется оригинал;
• какие данные получает модель;
• кто и как проверяет результат;
• куда записывается итог;
• что происходит при недоступности Bitrix24, amoCRM или внутренней системы;
• как выполняются повторные попытки и исключаются дубли;
• какие события попадают в журнал;
• кто увидит ухудшение качества или рост стоимости после запуска.

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

AWS отмечает, что переход от удачного прототипа к рабочей системе часто упирается не в выбор модели, а в доступ к данным, интеграции, управление рисками, тестовые наборы, метрики и мониторинг.[5] Поэтому архитектурный контур должен появиться до сметы, а не после красивой демонстрации.

8. Сформулируйте гипотезу и правило остановки

Пилот должен уменьшать одну главную неопределённость. Формулировка может выглядеть так:

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

До разработки фиксируют:

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

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

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

Результат аудита: решение и паспорт пилота

Хороший аудит не обязан завершаться рекомендацией «разрабатывать ИИ». У него три нормальных исхода.

1. Процесс готов к пилоту

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

2. Сначала нужна подготовка

Ценность задачи понятна, но документы противоречат друг другу, CRM заполнена непоследовательно, нет тестовой выборки или сотрудники не согласовали правильный результат. Тогда первым проектом становится подготовка данных, изменение регламента или настройка обычного workflow.

Это не задержка «настоящего ИИ-проекта». Это устранение причины, из-за которой пилот дал бы недостоверный результат.

3. ИИ не нужен или риск пока неприемлем

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

Что должно быть в паспорте первого пилота

Перед передачей задачи разработчику достаточно компактного документа, в котором зафиксированы:

1. бизнес-проблема и границы процесса;
2. событие на входе и ожидаемый результат;
3. владелец процесса и реальные пользователи;
4. текущий показатель и ожидаемое изменение;
5. источники данных, доступы и правила обновления;
6. конкретная роль ИИ и детерминированные шаги вокруг него;
7. исключённые сценарии;
8. ошибки, эскалация человеку и запрещённые действия;
9. интеграции, журналирование и мониторинг;
10. тестовый набор, критерий успеха и правило остановки.

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

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

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

Вывод и частые вопросы

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

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

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

Как понять, готова ли компания к внедрению ИИ?

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

Какие данные нужны для пилота ИИ?

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

Чем прототип отличается от пилота?

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

Сколько стоит внедрение ИИ?

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

Нужен ли аудит, если модель уже выбрана?

Да, если ещё не определены процесс, данные, метрика и цена ошибки. Выбор модели отвечает на часть технических вопросов, но не определяет, что именно должна проверить разработка и будет ли результат полезен бизнесу.

Источники

1. AI strategy — Guidance to set your organization's AI strategy — Microsoft Cloud Adoption Framework, обновлено 26 июня 2026 года.
2. Plan for AI adoption — Microsoft Cloud Adoption Framework, обновлено 10 апреля 2026 года.
3. AI Risk Management Framework Core — NIST, версия 1.0, 2023 год.
4. Generative AI: Getting Proofs-of-Concept to Production — AWS, 8 мая 2024 года.
5. Navigating the generative AI journey: The Path-to-Value framework from AWS — AWS, 14 апреля 2026 года.
6. Organizational readiness for AI adoption and scale — Google Cloud, 5 июня 2025 года.