Запросы на ИИ приходят в компанию со всех сторон. На встрече вендор показывает демо, сотрудники просят доступ к нейросети «для рутины», собственник после отраслевой конференции спрашивает, почему конкуренты «уже внедрили». Через полгода таких инициатив в компании живут три отдельных пилота: у каждого свой исполнитель, своя подписка и никакой связи между собой. После второй неудачи ИИ здесь надолго становится синонимом потраченных денег.
Проблема не в том, что ИИ не работает. Проблема в том, что решения о нём принимаются по отдельности — под каждым конкретным предложением. Стратегия внедрения ИИ — это способ вынести эти решения на уровень компании и принять один раз: в каких процессах используем ИИ, в каком порядке, что готовим заранее, кто принимает решения и по какой метрике судим результат.
Позиция у меня такая: стратегия внедрения ИИ — не документ про технологии, а короткий список портфельных решений руководителя. Пять решений, одна страница. Когда они есть, каждый следующий пилот наследует правила, данные и метрики из общего контура. Когда их нет — каждый пилот стартует с нуля и зависит от красноречия продавца.
Когда стратегии нет, бюджет дробится
Microsoft в Cloud Adoption Framework формулирует это без обтекаемости: без ясной стратегии команды экспериментируют без достаточной отдачи, а инвестиции в ИИ дробятся [1]. Каждый эксперимент по отдельности может выглядеть разумно — расходы небольшие, команда получает опыт. Складывать картину из них всё равно не получается: у каждого свой критерий успеха, свои данные, свои подписки.
Исследования последних полутора лет сходятся ещё в одном: причина неудач редко в самих моделях.
Команда MIT (Project NANDA) в отчёте «The GenAI Divide» оценила, что около 95% организаций не получают измеримой отдачи от пилотов генеративного ИИ. Причина, которую называют сами исследователи, — компании покупают готовые инструменты и избегают перестройки процессов, в которые их нужно встраивать [2]. Gartner ещё в 2024 году прогнозировала закрытие минимум 30% проектов генеративного ИИ после пилота — из-за качества данных, растущих затрат, неясной бизнес-ценности и слабого контроля рисков [3].
Российские данные добавляют детализации. По сплошным обследованиям Росстата, обработанным ИСИЭЗ ВШЭ, среди организаций, которые уже используют ИИ, 62,7% отметили рост качества и эффективности бизнес-процессов, 51,1% — производственных. Барьеры при этом такие: высокие затраты — 54%, нехватка или низкое качество данных — 34%, нехватка квалифицированных кадров — 33%, нехватка ИКТ-инфраструктуры — 32% [4].
Ни в одном из этих списков нет пункта «слабая нейросеть». Затраты, данные, ценность, границы — это решения уровня компании. Именно их и фиксирует стратегия.
Что входит в стратегию внедрения ИИ
В методологии Microsoft стратегия (или устав) внедрения ИИ должна фиксировать три вещи: приоритеты организации, права решений — кто и что решает — и способ измерения ценности вложений в ИИ [1]. Звучит как описание работы руководителя, а не ИТ-отдела. Так и есть.
Для средней компании всё это умещается на одной странице. Не в презентации на шестьдесят слайдов про цифровую трансформацию, а в пяти решениях:
- какие процессы берём первыми и по каким критериям;
- в каком порядке их запускаем;
- что готовим заранее — данные, доступы, людей;
- кто принимает решения и где проходят границы автоматизации;
- по какой метрике судим результат и когда пересматриваем портфель.
Теперь о том, чем стратегия внедрения ИИ быть не должна.
Не роадмап моделей и вендоров. Конкретная модель или платформа морально устаревает быстрее, чем подписывается приказ. В стратегии живут критерии выбора, а не сам выбор.
Не план проекта. План внедрения описывает этапы конкретного пилота: что делаем в первую неделю, как принимаем, когда останавливаемся. Стратегия отвечает на вопрос уровнем выше — почему этот пилот вообще в очереди и что должно произойти, чтобы за ним появился следующий.
Не политика использования ИИ сотрудниками. Политика отвечает на вопрос, какими инструментами людям можно пользоваться в работе. Стратегия — на вопрос, какие процессы компании и зачем мы переводим на ИИ. Документы пересекаются, но заменять друг друга не могут.
Решение 1. Какие процессы брать первыми
Типичная ошибка — выбирать не процессы, а технологии: «давайте внедрим агента» вместо «давайте разгрузим обработку входящих заявок». Технология без процесса не даёт метрики, а без метрики — не даёт решения о продолжении.
Отбор по четырём критериям:
- Повторяемость. Операция выполняется регулярно и вручную: обработка заявок, ответы на типовые вопросы, перенос данных между системами. Разовая задача даже с ИИ останется разовой.
- Проверяемость. Результат можно проверить по правилу или по факту: заявка создана, ответ совпадает с базой знаний, документ заполнен полностью. «Стало лучше» — не проверяемость.
- Известная цена ошибки. Компания понимает, что стоит ошибка в этом месте, и она терпима на пилоте — с проверкой человеком там, где цена высока.
- Реальные данные и доступы. Известен владелец данных, система, где они живут, и тот, кто отвечает за их актуальность.
И правило перед стартом: сначала проверить, не решается ли задача вообще без ИИ — правилами, формой, регламентом, изменением самого процесса. Разбор, где достаточно правил, а где оправдан ИИ, — отдельная статья на этом сайте. Нередко после такого разбора «ИИ-задача» оказывается обычной автоматизацией — и это хороший исход, он дешевле.
Решение 2. В каком порядке запускать
Порядок — это ответ на вопрос «что идёт первым, а что ждёт». Рациональный по умолчанию вариант: один-два пилота в квартал, не больше. Не потому, что больше нельзя, а потому, что параллельные пилоты в одной компании дерутся за одних и тех же людей, данные и внимание руководителя.
Каждый кандидат в очереди проходит одинаковую оценку: ценность для бизнеса, вероятность успеха, полная стоимость — подписка плюс интеграции, поддержка и время сотрудников. Как устроена такая оценка до старта — разобрано в отдельной статье; повторяться не буду.
Срок портфеля — квартал. Роадмап на год с конкретными внедрениями по кварталам в этой области не живёт: за год меняются и модели, и цены, и то, что умеют вендоры. Планировать год вперёд стоит для данных и доступов, а не для конкретных внедрений.
Решение 3. Что готовить заранее
Данные — под выбранные сценарии, а не «вообще». Microsoft прямо пишет: перед внедрением ИИ не требуется целиком новая стратегия данных; сначала определяется, какие данные нужны конкретным принятым сценариям, и обеспечивается безопасный доступ к ним [1]. Это снимает типичный паралич «у нас грязные данные, сначала наведём порядок во всём». Порядок наводится там, куда идёт первый пилот.
Тот же подход закрывает барьеры из российских обследований [4]. Затраты — считаются по конкретному процессу: интеграции, поддержка, время людей. Данные — собираются под сценарий: что нужно ассистенту поддержки, то и чистим. Кадры — обучаются на том же пилоте: один человек, который понимает процесс и умеет проверять ответы ИИ, полезнее курса «ИИ для всех». Инфраструктура — выбирается под задачу, а не впрок.
Решение 4. Кто решает и где границы
Без назначенных прав решений стратегия превращается в перечень пожеланий. Нужно немного:
- один ответственный за направление — у него сходятся очередь процессов, метрики и бюджет. Отдельная структура вроде центра ИИ-компетенций нужна компаниям с десятками процессов; в средней компании это роль, а не отдел;
- правило запуска: кто утверждает пилот и по каким документам — критерии, метрика, срок;
- правило остановки: кто и на каком основании закрывает проект. Без него проекты не закрываются — они тихо догорают в подписках;
- границы автоматизации: где решение остаётся за человеком. Внешние обязательства, суммы, клиентские обещания — не для самостоятельных действий агента;
- правила данных: что нельзя отправлять во внешние сервисы, какие документы могут попадать в базу знаний, кто даёт доступ.
Microsoft в той же методологии называет это централизацией управления: общие политики и границы задаются один раз, бизнес-команды работают внутри них [1]. Для компании на тридцать человек «центр» — это файл на два абзаца и человек, который за него отвечает.
Решение 5. Метрика и пересмотр
Каждому процессу в портфеле — своя метрика и исходный замер до старта: время ответа на заявку, доля обращений без участия человека, стоимость обработки документа. Пилот проверяет одно: изменилась ли метрика против замера, и изменилась ли настолько, чтобы покрыть стоимость.
Дальше — квартальный пересмотр портфеля. Три исхода у каждого проекта: расширять, оставлять в текущем виде, останавливать. Остановка после пилота — не провал, а нормальная работа портфеля: Gartner закладывает закрытие минимум 30% проектов после проверки концепции именно потому, что проверка и должна отсеивать слабое [3]. Дорого обходится не остановленный пилот, а пилот, который год никто не решился остановить.
Если проект буксует уже после запуска — перед тем как его закрывать, стоит пройти диагностику по пяти точкам: результат, владелец, данные, встраивание в рабочий поток, эксплуатация. Разбор типовых проблем внедрения ИИ есть на этом сайте.
Когда стратегия не нужна
Стратегия внедрения ИИ не спасёт, и писать её рано, в трёх ситуациях.
Первая: в компании не описан ни один процесс с повторяющейся ручной работой, известной ценой ошибки и текущей метрикой. Тогда стратегия выродится в список лозунгов — сначала разбор процессов, потом решения о них.
Вторая: задача не бизнесовая. «Внедрить ИИ, потому что конкуренты внедрили» — это не цель, и портфель под неё не соберёшь. Честнее признать и отложить.
Третья: компания на тридцать человек копирует корпоративный подход — центр компетенций, платформенные команды, комитет по этике ИИ. Управленческий каркас дороже результата. Роль ответственного и два правила вместо трёх комитетов.
Отдельный случай — всё наоборот: стратегия есть, большая и красивая, но ни один процесс под неё не подведён. Это тоже отсутствие стратегии — только в дорогой упаковке.
Вывод
Стратегия внедрения ИИ — пять решений на одной странице: какие процессы берём, в каком порядке, что готовим заранее, кто решает и где границы, по какой метрике судим и когда пересматриваем. Документ про модели и вендоров в неё не входит — он устареет раньше, чем его дочитают.
Первый шаг без всякой стратегии: выбрать три–пять процессов-кандидатов и по каждому записать участников, данные, текущую метрику и цену ошибки. Эта таблица — готовый черновик стратегии. Если по ходу станет ясно, что процессы описаны слабо, а метрик нет — начать имеет смысл с разбора: аудит бизнес-процессов для внедрения ИИ как раз отвечает на вопрос, нужен ли здесь ИИ, обычная автоматизация или изменение процесса, и определяет границы первого пилота.
Частые вопросы
Чем стратегия внедрения ИИ отличается от плана внедрения?
Разные авторы и разные моменты. Стратегию пишет руководитель — собственник или операционный директор — до первого пилота; умещается она в таблицу процессов и несколько правил. План внедрения составляет владелец конкретного проекта уже под этот пилот: он опирается на стратегию и отвечает за её исполнение в одном процессе. Если план входит в противоречие со стратегией, пересматривают не план, а портфель.
Нужна ли стратегия ИИ небольшому бизнесу?
Нужен её смысл, а не форма. Пять решений можно записать на одной странице за один рабочий вечер. Полноценный корпоративный документ с центром ИИ-компетенций малому бизнесу не нужен — там достаточно одного ответственного и двух правил: порядок запуска и порядок остановки.
Кто должен отвечать за стратегию внедрения ИИ в компании?
Человек, у которого сходятся процессы, данные и бюджет, — обычно операционный директор или сам собственник. Передавать ответственность ИТ-отделу — частая ошибка: отбор процессов и метрики лежат в бизнесе, технологии подключаются позже.
Как выбрать процессы для первого пилота?
Список кандидатов составляется не в одиночку: три–пять процессов берутся вместе с их владельцами, иначе в оценку попадут чужие представления о рутине. Типичная ошибка — начинать с самого заметного процесса или самого эффектного демо вместо самого проверяемого. Если у процесса нет текущей метрики, он сначала идёт на замер, а не в пилот.
Как часто пересматривать стратегию внедрения ИИ?
Раз в квартал, вместе с портфелем пилотов: расширять, оставлять или останавливать каждый проект. Технологическая часть (модели, вендоры) пересматривается чаще, но в самой стратегии её нет — там живут критерии выбора, а не выбор.
Источники
- AI adoption — Cloud Adoption Framework — Microsoft Learn, обновлено 15.10.2026
- The GenAI Divide: State of AI in Business 2025 — MIT Project NANDA, август 2025
- Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025 — Gartner, 29.07.2024
- Крупный бизнес наиболее активно внедряет ИИ — ИСИЭЗ НИУ ВШЭ (Г. Ковалева, Г. Абдрахманова, П. Рудник), 24.09.2026
