Внедрение ИИ в компании: от PoC до результата, KPI и масштабирования

1. Опишите задачу как измеримую бизнес-проблему

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

Удобная заготовка:

В процессе A роль B каждую неделю тратит много времени на задачу C; мы хотим с помощью ИИ улучшить показатель D с текущего уровня до целевого значения, а владелец процесса E отвечает за изменение процесса и приемку результата.

До запуска стоит ответить минимум на пять вопросов:

• Кто будет пользоваться этой ИИ-функцией регулярно?
• В какой конкретный шаг процесса она встраивается?
• Какой сегодня базовый уровень: время обработки, ошибка, конверсия, стоимость, количество жалоб или ручные часы?
• Успех измеряется скоростью, качеством, выручкой, снижением затрат, риском или опытом сотрудников?
• Кто имеет право изменить процесс и взять ответственность за результат?

Без бизнес-владельца и исходной метрики PoC почти невозможно честно оценить — и еще сложнее масштабировать.

2. Выберите 1–3 частых сценария с уже доступными данными

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

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

3. До PoC проверьте данные, доступы и интеграции

ИИ-проект часто ломается не на модели, а на данных: их нельзя безопасно получить, они устарели, доступны не тем людям или не возвращаются в рабочие системы. В обзоре Talyx исследования RAND Corporation 2024 года, основанного на интервью с 65 опытными дата-сайентистами и инженерами, перечислены типовые причины провала AI-проектов: неверно понятая постановка задачи, недостаток подходящих данных, выбор технологии ради технологии, слабая инфраструктура и попытка решить задачу, выходящую за реалистичные рамки.

Перед PoC проверьте:

• Где лежат данные: в документах, CRM, ERP, системе заявок, хранилище данных или на личных дисках?
• Каково качество данных: нет ли устаревших версий, дублей, пропусков и разных форматов?
• Как устроены права: видят ли разные подразделения, роли и уровни доступа только то, что им положено?
• Как часто данные обновляются: отвечает ли ИИ по свежей информации или по версии месячной давности?
• Можно ли встроиться в системы: попадет ли результат обратно в CRM, заявку, отчет, согласование или документ?
• Есть ли аудит: можно ли понять, кто задал вопрос, что ответил ИИ, кто принял или исправил ответ?

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

4. Делайте PoC маленьким, но в реальном рабочем контуре

PoC — proof of concept, или проверка концепции — не должен быть презентацией в переговорной. Лучше относиться к нему как к первой версии продукта: реальные пользователи, реальные данные, реальный процесс и заранее заданные условия успеха, масштабирования и остановки.

PoC, который может перейти в эксплуатацию, должен отвечать на такие вопросы:

• Где пользователь запускает ИИ: в CRM, системе заявок, корпоративном портале, мессенджере или другом привычном инструменте?
• Кто проверяет результат ИИ?
• В каких случаях обязательно нужен человек в контуре?
• Как сообщать об ошибках и кто исправляет данные, правила или промпты?
• Какие действия ИИ может только предложить, но не выполнить автоматически?
• При каком уровне KPI проект расширяется, а при каком — закрывается?

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

5. Масштабируйте только после настройки управления рисками

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

Особенно осторожно стоит двигаться от поиска, резюме и черновиков к ИИ-агентам — более автономным сценариям, где система не только отвечает, но и может выполнять последовательность действий в рамках заданных правил. В сводке опроса McKinsey 2025 года не более 10% респондентов в любой отдельной бизнес-функции сообщили, что масштабировали AI agents. McKinsey также называет безопасность и риски главным барьером для масштабирования agentic AI; среди наиболее часто упоминаемых рисков остаются неточность и кибербезопасность.

Более надежная последовательность такая:

1. Сначала используйте ИИ для поиска, структурирования, резюме и черновиков.
2. Оставляйте человека в контуре и собирайте ошибки, исключения, логи и обратную связь.
3. Автоматизируйте только низкорисковые шаги, когда стабильны точность, процесс, права и аудит.
4. Перед расширением в новый отдел заново проверяйте данные, доступы, юридические требования, безопасность, приватность и контроль.

KPI: не ограничивайтесь точностью модели

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

На старте не нужно десятки показателей. Но каждый KPI должен быть связан с процессом. Если PoC доказывает только то, что ИИ может написать абзац текста, но не показывает улучшения скорости, качества, затрат или контроля, это еще не внедрение.

Почему многие ИИ-проекты не доходят до эксплуатации

1. Сначала покупают инструмент, потом ищут задачу

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

2. Подразделения по-разному понимают цель

Бизнес может ждать снижения трудозатрат, IT — оптимизировать точность модели, руководство — рассчитывать на экономию, а юристы — беспокоиться о рисках. Неверно понятая постановка задачи также входит в список распространенных причин провала AI-проектов в обзоре Talyx по исследованию RAND.

3. Данные и системы не соединены

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

4. PoC не меняет реальную работу

Рост использования ИИ сам по себе не означает масштабного эффекта. По материалу о глобальном опросе McKinsey, 88% организаций уже используют ИИ хотя бы в одной бизнес-функции, но почти две трети не продвинулись дальше экспериментов или ранних пилотов. Если PoC не встроен в процесс, у него нет владельца и KPI, он часто остается демонстрацией.

5. Governance вспоминают слишком поздно

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

Матрица выбора: что делать первым, а что отложить

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

Короткий чек-лист перед запуском

Перед стартом любого ИИ-проекта пройдитесь по десяти вопросам:

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

Главное

Внедрение ИИ лучше начинать не с покупки модели, а с переделки одного измеримого процесса. Модель важна, но сама по себе она не создает операционный результат. От PoC к рабочей эксплуатации проект проходит тогда, когда данные доступны, права понятны, процесс готов измениться, риски контролируются, а KPI показывают реальную ценность.