Внедрение ИИ в компании чаще всего упирается не в то, насколько «умна» модель. Слабое место обычно в другом: есть ли доступ к актуальным данным, понятны ли права, попадает ли результат в рабочую систему, кто отвечает за KPI и как контролируются ошибки. По материалу The Consulting Report, пересказывающему глобальный опрос McKinsey, 88% организаций уже используют ИИ хотя бы в одной бизнес-функции, но почти две трети остаются на уровне экспериментов или ранних пилотов[5]. Иными словами, бизнесу не хватает не идей для ИИ, а дисциплины, которая превращает пилот в устойчивую операционную практику.
Сначала выбирайте процесс, а не модель
Правильный стартовый вопрос звучит не так: «Нам нужен ИИ?» Лучше спросить: «Какой процесс мы готовы изменить первым, чтобы получить измеримый эффект?» Первый сценарий не обязан быть самым масштабным. Он должен быть частым, понятным, обеспеченным данными и достаточно безопасным, чтобы результат можно было проверять человеком.
Хороший первый кандидат обычно выглядит так:
- команда выполняет похожую задачу каждый день или каждую неделю;
- данные уже есть в документах, CRM, ERP, системе заявок, хранилище данных или внутренней базе знаний;
- текущий процесс явно болит: сотрудники долго ищут информацию, много копируют вручную, дают разные ответы или часто переделывают работу;
- результат ИИ можно проверить, исправить, выборочно проконтролировать или передать человеку;
- у процесса есть бизнес-владелец, который готов менять порядок работы и отвечать за эффект.
Если этих условий нет, закупка инструмента или модели с большой вероятностью закончится красивой демонстрацией, а не изменением бизнеса.
5 шагов: как провести PoC так, чтобы он мог стать рабочим процессом
1. Опишите задачу как измеримую бизнес-проблему
Не называйте проект просто «внедрение ИИ». Такая формулировка ничего не говорит о результате. Лучше зафиксировать: кто выполняет какую задачу, где процесс тормозит, какой показатель нужно улучшить и кто принимает итог.
Удобная заготовка:
В процессе A роль B каждую неделю тратит много времени на задачу C; мы хотим с помощью ИИ улучшить показатель D с текущего уровня до целевого значения, а владелец процесса E отвечает за изменение процесса и приемку результата.
До запуска стоит ответить минимум на пять вопросов:
- Кто будет пользоваться этой ИИ-функцией регулярно?
- В какой конкретный шаг процесса она встраивается?
- Какой сегодня базовый уровень: время обработки, ошибка, конверсия, стоимость, количество жалоб или ручные часы?
- Успех измеряется скоростью, качеством, выручкой, снижением затрат, риском или опытом сотрудников?
- Кто имеет право изменить процесс и взять ответственность за результат?
Без бизнес-владельца и исходной метрики PoC почти невозможно честно оценить — и еще сложнее масштабировать.
2. Выберите 1–3 частых сценария с уже доступными данными
Для первой волны лучше брать не самые сложные задачи, а те, где много повторов, понятен источник данных и допустима человеческая проверка. Типичные стартовые варианты:
| Сценарий | Почему подходит для старта | Первый KPI |
|---|---|---|
| Поиск ответов для клиентской поддержки | Ответы часто лежат в FAQ, продуктовой документации, истории заявок или базе знаний | Среднее время обработки, доля решений с первого обращения, точность по выборке, количество жалоб |
| Внутренний поиск по документам | Сотрудники тратят время на поиск регламентов, инструкций, продуктовой или технической информации | Время поиска, число ручных перенаправлений, доля принятых ответов |
| Резюме отчетов и встреч | Форматы повторяются, а потребность в быстром чтении высокая | Время подготовки отчета, доля принятых резюме, число правок |
| Извлечение полей из договоров или документов | Поля заранее известны, легко встроить проверку человеком | Точность полей, время проверки, доля переделок |
| Помощь в продажах и закупках | ИИ может собирать данные, сравнивать варианты, готовить черновики и подсказки | Скорость ответа, цикл сделки или закупки, конверсия, экономия ручного труда |
Не стоит начинать с максимально рискованного, плохо описанного и юридически чувствительного процесса. Если данные разбросаны, роли не определены, а правила не стандартизированы, сначала придется навести порядок в данных и процессе.
3. До PoC проверьте данные, доступы и интеграции
ИИ-проект часто ломается не на модели, а на данных: их нельзя безопасно получить, они устарели, доступны не тем людям или не возвращаются в рабочие системы. В обзоре Talyx исследования RAND Corporation 2024 года, основанного на интервью с 65 опытными дата-сайентистами и инженерами, перечислены типовые причины провала AI-проектов: неверно понятая постановка задачи, недостаток подходящих данных, выбор технологии ради технологии, слабая инфраструктура и попытка решить задачу, выходящую за реалистичные рамки[4].
Перед PoC проверьте:
- Где лежат данные: в документах, CRM, ERP, системе заявок, хранилище данных или на личных дисках?
- Каково качество данных: нет ли устаревших версий, дублей, пропусков и разных форматов?
- Как устроены права: видят ли разные подразделения, роли и уровни доступа только то, что им положено?
- Как часто данные обновляются: отвечает ли ИИ по свежей информации или по версии месячной давности?
- Можно ли встроиться в системы: попадет ли результат обратно в CRM, заявку, отчет, согласование или документ?
- Есть ли аудит: можно ли понять, кто задал вопрос, что ответил ИИ, кто принял или исправил ответ?
Если данные недоступны, сильная модель будет работать как витрина. Если права не продуманы, проект быстро упрется в информационную безопасность, приватность, юридические требования или аудит.
4. Делайте PoC маленьким, но в реальном рабочем контуре
PoC — proof of concept, или проверка концепции — не должен быть презентацией в переговорной. Лучше относиться к нему как к первой версии продукта: реальные пользователи, реальные данные, реальный процесс и заранее заданные условия успеха, масштабирования и остановки.
PoC, который может перейти в эксплуатацию, должен отвечать на такие вопросы:
- Где пользователь запускает ИИ: в CRM, системе заявок, корпоративном портале, мессенджере или другом привычном инструменте?
- Кто проверяет результат ИИ?
- В каких случаях обязательно нужен человек в контуре?
- Как сообщать об ошибках и кто исправляет данные, правила или промпты?
- Какие действия ИИ может только предложить, но не выполнить автоматически?
- При каком уровне KPI проект расширяется, а при каком — закрывается?
Цель PoC — не доказать, что ИИ умеет генерировать текст. Цель — доказать, что он стабильно используется в процессе и улучшает конкретный показатель.
5. Масштабируйте только после настройки управления рисками
Масштабирование ИИ — это не просто раздать больше лицензий. При переходе в другое подразделение появляются новые источники данных, права, исключения, юридические требования и KPI.
Особенно осторожно стоит двигаться от поиска, резюме и черновиков к ИИ-агентам — более автономным сценариям, где система не только отвечает, но и может выполнять последовательность действий в рамках заданных правил. В сводке опроса McKinsey 2025 года не более 10% респондентов в любой отдельной бизнес-функции сообщили, что масштабировали AI agents[2]. McKinsey также называет безопасность и риски главным барьером для масштабирования agentic AI; среди наиболее часто упоминаемых рисков остаются неточность и кибербезопасность[
8].
Более надежная последовательность такая:
- Сначала используйте ИИ для поиска, структурирования, резюме и черновиков.
- Оставляйте человека в контуре и собирайте ошибки, исключения, логи и обратную связь.
- Автоматизируйте только низкорисковые шаги, когда стабильны точность, процесс, права и аудит.
- Перед расширением в новый отдел заново проверяйте данные, доступы, юридические требования, безопасность, приватность и контроль.
KPI: не ограничивайтесь точностью модели
Если измерять только точность модели, легко пропустить главный вопрос: стало ли бизнесу быстрее, дешевле, качественнее или безопаснее? Сначала зафиксируйте базовый уровень, затем используйте несколько типов метрик.
| Тип KPI | Примеры метрик | Где применимо |
|---|---|---|
| Эффективность | Среднее время обработки, время цикла, ручные минуты на задачу, время подготовки отчета | Поддержка, отчеты, документы, внутренний поиск |
| Качество | Точность по выборке, доля принятых ответов, доля переделок, жалобы | Ответы клиентам, извлечение из договоров, черновики контента |
| Использование | Недельные активные пользователи, доля покрытых задач, повторное использование, число ручных перенаправлений | Внутренние ассистенты, базы знаний, инструменты отделов |
| Бизнес-результат | Конверсия, скорость ответа, закрытие заявок, стоимость обработки одного кейса | Продажи, поддержка, закупки, операционные процессы |
| Риск и контроль | Доля эскалаций человеку, нарушения политик, исключения по чувствительным данным, замечания аудита | Внешние ответы, работа с чувствительными данными, ИИ-агенты |
На старте не нужно десятки показателей. Но каждый KPI должен быть связан с процессом. Если PoC доказывает только то, что ИИ может написать абзац текста, но не показывает улучшения скорости, качества, затрат или контроля, это еще не внедрение.
Почему многие ИИ-проекты не доходят до эксплуатации
1. Сначала покупают инструмент, потом ищут задачу
Так появляются эффектные демо, которыми никто не пользуется каждый день. В обзоре Talyx по исследованию RAND выбор технологии ради технологии назван одной из типовых причин провала AI-проектов[4].
2. Подразделения по-разному понимают цель
Бизнес может ждать снижения трудозатрат, IT — оптимизировать точность модели, руководство — рассчитывать на экономию, а юристы — беспокоиться о рисках. Неверно понятая постановка задачи также входит в список распространенных причин провала AI-проектов в обзоре Talyx по исследованию RAND[4].
3. Данные и системы не соединены
Если ИИ не получает правильные документы, клиентские данные, заявки или транзакции, он отвечает слишком общо. Если результат нельзя вернуть в CRM, ERP, базу документов или систему заявок, сотрудник снова копирует все вручную, и выгода растворяется в процессных издержках. Слабая инфраструктура также названа среди типовых причин провала AI-проектов[4].
4. PoC не меняет реальную работу
Рост использования ИИ сам по себе не означает масштабного эффекта. По материалу о глобальном опросе McKinsey, 88% организаций уже используют ИИ хотя бы в одной бизнес-функции, но почти две трети не продвинулись дальше экспериментов или ранних пилотов[5]. Если PoC не встроен в процесс, у него нет владельца и KPI, он часто остается демонстрацией.
5. Governance вспоминают слишком поздно
Права доступа, аудит, безопасность, приватность и комплаенс лучше проектировать до запуска, а не накануне промышленной эксплуатации. Для ИИ-агентов это особенно важно: чем автономнее система, тем яснее должны быть границы данных, разрешенные действия, проверка человеком и ответственность. McKinsey называет безопасность и риски главным барьером для масштабирования agentic AI[8].
Матрица выбора: что делать первым, а что отложить
| Можно брать в первую волну | Лучше сначала подготовить |
|---|---|
| Частая повторяемая задача каждую неделю или месяц | Редкая исключительная задача, которая возникает несколько раз в год |
| Данные уже оцифрованы и понятен источник | Данные разбросаны по личным файлам, устным знаниям и неформальным записям |
| Правила относительно понятны, ответ можно проследить | Формулировка задачи размыта, отделы спорят о цели |
| Ошибку можно проверить и исправить человеком | Ошибка сразу ведет к серьезным юридическим, финансовым или безопасностным последствиям |
| Есть владелец процесса, готовый менять работу | Проект продвигают только IT или консультанты, а пользователи не вовлечены |
| KPI измеримы: время, точность, стоимость, жалобы | Цель звучит как «сделать инновационно», но эффект не определен |
Правая колонка не означает, что сценарий нельзя автоматизировать никогда. Она означает, что сначала нужны данные, стандартизация, распределение ответственности и контроль рисков.
Короткий чек-лист перед запуском
Перед стартом любого ИИ-проекта пройдитесь по десяти вопросам:
- Какую конкретную бизнес-проблему решает сценарий?
- Каков текущий базовый уровень: время, ошибки, стоимость, жалобы или другой показатель?
- Кто владелец процесса и кто может менять порядок работы?
- Пользователи действительно сталкиваются с этой задачей регулярно?
- Нужные данные существуют, доступны и обновляются?
- Понятны права доступа, приватность, юридические требования, безопасность и аудит?
- В какую реальную систему или рабочий поток попадет результат ИИ?
- В каких случаях обязательно нужен человек в контуре?
- Какие пороги KPI означают успех, масштабирование или остановку проекта?
- Если проект перенести во второе подразделение, останутся ли применимыми данные, процесс и контроль рисков?
Главное
Внедрение ИИ лучше начинать не с покупки модели, а с переделки одного измеримого процесса. Модель важна, но сама по себе она не создает операционный результат. От PoC к рабочей эксплуатации проект проходит тогда, когда данные доступны, права понятны, процесс готов измениться, риски контролируются, а KPI показывают реальную ценность.
