Стратегия ИИ в компании состоит из семи частей: связь с целями бизнеса, портфель задач с очерёдностью, общие данные и платформа, место запуска и требования безопасности, выбор между разработкой, покупкой и подпиской, роли и правила принятия решений, метрики с порядком пересмотра. План проектов описывает, что делаем, стратегия отвечает, почему именно это, в каком порядке и что общего у проектов между собой. Если проект один, стратегия не нужна, хватит описания пилота.
Ниже разбор каждой части, таблица отличий от плана проектов и признаки документа, который работает. Услуга по разработке стратегии описана на странице «Стратегия ИИ для бизнеса», здесь только метод.
Стратегия ИИ и план проектов: в чём разница
Путаница возникает потому, что обе бумаги содержат список инициатив. Различие в вопросах, на которые они отвечают, и в том, что с ними делают, когда обстоятельства меняются.
| Признак | План проектов | Стратегия ИИ |
|---|---|---|
| Главный вопрос | Что делаем и к какому сроку | Почему именно это, в каком порядке, что остаётся неизменным при смене задач |
| Единица | Проект с бюджетом и сроком | Направление, общие данные и правила для всех проектов |
| Чем заканчивается спор | Приоритет проекта выбирает руководитель на глаз | Критерии отбора записаны, проект проходит или не проходит |
| Что общего у проектов | Не описано, каждый проект решает сам | Данные, платформа, безопасность, роли и правила вынесены в общую часть |
| Когда пересматривается | При срыве срока | По графику и по триггерам: смена требований, новое семейство моделей, итог пилота |
| Как проверить | Выполнены ли проекты | Можно ли по документу отказать в проекте и объяснить, почему |
Из этого следует практическая проверка: попробуйте применить документ к идее, которую вам принесут завтра. Если по нему нельзя сказать «нет», это план или пожелание, а не стратегия.
Из чего состоит стратегия: семь частей
Размер документа не показатель. Рабочая стратегия умещается в десять страниц, потому что каждая часть отвечает на один вопрос и не повторяет остальные.
| Часть | Вопрос, на который отвечает | Что внутри | Кто отвечает |
|---|---|---|---|
| 1. Связь с бизнесом | Какие показатели компании должен двигать ИИ | Две-три цели в терминах бизнеса: срок обработки, потери, нагрузка на людей. Не «стать ИИ-компанией» | Руководитель компании |
| 2. Портфель задач | Что делаем и в каком порядке | Реестр кандидатов, критерии отбора, очередность, что сознательно не делаем | Владельцы процессов |
| 3. Данные и платформа | Что общего нужно нескольким проектам | Каталог источников, владельцы данных, общий поиск, хранилище, среда запуска моделей | ИТ и владельцы данных |
| 4. Размещение и безопасность | Где работает ИИ и что нельзя выносить | Классы данных, допустимые варианты размещения, правила доступа, журнал | Безопасность и ИТ |
| 5. Разработка, покупка, подписка | Что пишем, что берём готовым | Правила выбора с критериями, порог, после которого строим своё | ИТ и финансы |
| 6. Роли и решения | Кто решает и кто отвечает | Владелец каждого проекта, комитет, порядок принятия пилота, порядок остановки | Руководитель компании |
| 7. Метрики и пересмотр | Как узнаем, что работает | Метрики проекта и портфеля, график пересмотра, триггеры внеочередного пересмотра | Руководитель и владельцы |
Отсутствие любой из частей отзывается позже. Без первой проекты выбирают по моде, без третьей каждый строит свой поиск, без шестой пилоты остаются без приёмки. Подробнее о ролях и этапах в статье «Внедрение ИИ на предприятии».
Портфель задач: как не превратить его в список желаний
Самая частая ошибка: собрать двадцать идей на воркшопе и считать это портфелем. Идея становится кандидатом, когда для неё записаны пять полей.
- Процесс и владелец. Конкретная операция и человек, чьи показатели изменятся.
- Частота и объём. Сколько раз в день или неделю и сколько людей заняты. От этого зависит, окупится ли даже простое решение.
- Цена ошибки. Что будет, если модель ошибётся, и кто это поймает до последствий.
- Данные. Где лежат, есть ли записи с верными ответами, можно ли их использовать для этой цели.
- Проверка. Как будет измерен результат и какая цифра считается успехом.
Дальше кандидаты раскладываются по трём горизонтам. Это не обязательство, а способ распределить внимание.
| Горизонт | Что сюда попадает | Что делаем |
|---|---|---|
| Ближайший: до полугода | Есть данные и владелец, цена ошибки низкая, результат проверяем | Пилот и вывод в эксплуатацию по одному сценарию за раз |
| Подготовка: полгода-год | Нужна работа с данными, доступами или процессом | Исправляем причину и повторяем оценку готовности |
| Отложено | Нет данных, высокая цена ошибки без контроля человека, зависимость от чужой системы | Фиксируем причину и условие возврата, не держим в бюджете |
Строка «Отложено» не позор, а защита бюджета. Как выбрать первый проект из ближайшего горизонта, чтобы не застрять на пилоте, описано в статье «Почему ИИ-пилоты не доходят до продуктива».
Данные и платформа: что общего окупается на нескольких проектах
Главная экономия стратегии возникает здесь. Если три проекта по очереди строят поиск по документам, вы платите за него трижды и получаете три разных качества. Общая часть описывается один раз.
Что стоит делать общим
- Каталог источников данных. Какие системы, кто владелец, как выгружать, какого класса данные.
- Поиск по документам. Один способ разбора, хранения и поиска для всех ассистентов; об устройстве в статье «Что такое RAG».
- Среда запуска моделей. Один сервер или кластер с мониторингом вместо отдельных машин под каждый пилот.
- Правила оценки. Общий порядок: как собирается эталонная выборка, какая метрика, кто принимает.
- Журнал и доступы. Кто и что спрашивал у модели, какие права у агентов.
Что делать общим рано
Единую платформу «на вырост» до первого работающего сценария строить не стоит: требования неизвестны, и она окажется неудобной всем. Правило такое: общая часть выделяется, когда второй проект повторяет то, что сделал первый. До этого достаточно записать договорённость, чтобы первый проект не закрыл дорогу второму.
Размещение, безопасность и выбор: разработка, покупка, подписка
Эти две части самые приземлённые и самые недооценённые, потому что именно они решают, что можно запускать вообще.
Классы данных и варианты размещения
Запишите три класса: открытые данные, обезличенные, ограниченного доступа. Для каждого определите допустимое размещение. Для открытых и обезличенных данных внешний программный интерфейс облачной модели может подойти. Для данных ограниченного доступа облачные модели чаще не подходят по требованиям заказчика, и модель размещают на ваших серверах. Персональные данные граждан России обычно должны храниться на серверах в России, это уточняйте у юриста. Сравнение подходов в статье «Своя LLM или ChatGPT API».
Разработка, покупка или подписка
| Вариант | Подходит, когда | Риск | Проверка |
|---|---|---|---|
| Купить готовое | Задача типовая, данные открытые, отличие процесса от рынка невелико | Зависимость от поставщика, ограничения на данные, цена растёт с нагрузкой | Пробный период на ваших примерах |
| Подписаться на сервис | Нужно быстро проверить гипотезу без вложений в инфраструктуру | Данные уходят к поставщику, условия меняются без вашего участия | Классификация данных и договор |
| Разработать своё | Процесс специфичен для вас, данные ограниченного доступа, решение станет частью продукта | Нужны люди и сопровождение, срок до результата дольше | Пилот на вашей выборке с метрикой заранее |
Правило выбора записывается в стратегии один раз, чтобы не обсуждать его заново для каждого проекта. Вместе со сроком пересмотра: рынок готовых решений меняется быстро.
Роли и решения: кто отвечает за стратегию
Документ без владельца теряет силу через квартал. Нужны четыре вещи.
- Владелец стратегии. Один человек с правом сказать «не делаем». Часто это заместитель руководителя, а не руководитель ИТ: ИТ отвечает за системы, а не за результат процессов.
- Владелец каждого проекта. Руководитель подразделения, чьи показатели изменятся. Без него пилот не принять.
- Короткая встреча по портфелю. Раз в квартал: что сделано, что остановлено, что добавлено. Не отчёт, а решения.
- Порядок остановки. Условия, при которых проект закрывается: метрика не достигнута к сроку, данные недоступны, изменились требования. Об этом подробнее в статье «Когда останавливать пилот ИИ-проекта».
Отдельно решается вопрос с людьми: кто пользуется результатом и как его обучают. Не откладывайте до запуска, подробности в статье «Как обучить сотрудников работе с нейросетями».
Метрики и пересмотр: как понять, что стратегия работает
Метрики бывают двух уровней, и смешивать их нельзя. Метрика проекта говорит, работает ли решение: доля верных ответов на контрольной выборке, доля случаев, которые решаются без правки человеком. Метрика портфеля говорит, получает ли бизнес пользу: срок обработки, нагрузка на сотрудников, число обращений. Первая задаётся до пилота, вторая измеряется до и после.
Признаки документа, который работает:
- По нему можно отказать в проекте и объяснить причину.
- В нём нет слов «трансформация» и «экосистема» без расшифровки, что именно изменится.
- У каждого пункта есть владелец и срок.
- Он содержит раздел «Чего не делаем и почему».
- Его пересматривали хотя бы раз после написания, и пересмотр оставил следы.
Триггеры внеочередного пересмотра полезно записать сразу: итог пилота, смена требований безопасности, появление модели, которая меняет экономику выбора, уход владельца процесса. Расчёт эффекта по проекту описан в статье «Как посчитать ROI от внедрения ИИ»; суммы мы не называем без вашей выборки.
Когда стратегия не нужна
Стратегия обходится дорого по времени руководителей, и в трёх случаях её лучше не писать.
- Проект один. Достаточно описания пилота: цель, выборка, метрика, срок. Стратегия появится, когда подключится второй проект.
- Нет ни одной проверенной задачи. Стратегия, написанная до первого опыта, будет гипотезой о гипотезах. Сначала проверьте готовность и проведите пилот.
- Документ нужен для отчёта. Если его никто не будет применять к решениям, лучше потратить время на пилот.
Если вы на этапе выбора задачи и типа решения, это скорее консалтинг по ИИ, чем стратегия.
Что делаем мы и с чего начать
Мы не пишем стратегии на сто слайдов. Начинаем с обследования: 200 000 ₽ и 2–3 недели за один-два процесса, 350 000 ₽ и 3–4 недели при нескольких системах, 500 000 ₽ и 4–6 недель для производства или закрытого контура. На выходе документ, который можно применять: список задач с критериями, очерёдность, общая часть по данным и размещению, роли и вилка бюджета. Стоимость вычитается из первого этапа, если продолжаете с нами, а документом можно пользоваться без нас.
Мы берём один контур или один участок, а не внедрение системы целиком за десятки миллионов, и не дежурим круглосуточно. Исходный код, если дойдём до разработки, лежит в вашем репозитории с первого коммита. Услуга описана на странице «Стратегия ИИ для бизнеса», цены и сроки на странице «Тарифы».
Частые вопросы
Из чего состоит стратегия ИИ в компании?
Из семи частей: связь с целями бизнеса, портфель задач с очерёдностью, общие данные и платформа, размещение и безопасность, выбор между разработкой, покупкой и подпиской, роли и решения, метрики с порядком пересмотра. Документ укладывается в десять страниц.
Чем стратегия ИИ отличается от плана проектов?
План отвечает, что и к какому сроку делаем, стратегия отвечает, почему это, в каком порядке и что общего у проектов. По стратегии можно отказать в новом проекте, по плану нельзя, потому что критериев в нём нет.
Нужна ли стратегия, если у нас один ИИ-проект?
Нет. Хватит описания пилота: цель, выборка, метрика, срок и владелец. Стратегия нужна, когда проектов несколько и они начинают делить данные, серверы и людей.
Кто должен владеть стратегией ИИ?
Человек, который может сказать «не делаем»: заместитель руководителя или директор по направлению. Руководитель ИТ отвечает за системы, но не за результат процессов, поэтому единственным владельцем быть не должен.
Как часто пересматривать стратегию?
Раз в квартал короткой встречей по портфелю и внепланово при триггерах: итог пилота, смена требований безопасности, появление модели, меняющей экономику выбора, уход владельца процесса. Полный пересмотр документа раз в год.
Можно ли написать стратегию без пилота?
Можно, но она будет гипотезой. Лучше сначала проверить одну задачу, чтобы узнать реальное состояние данных, сроки согласований и поведение пользователей, затем записать это в стратегию.
Нужно ли выбирать одного поставщика моделей на всю компанию?
Нет. Выбор зависит от класса данных задачи. Для открытых данных подойдёт внешний программный интерфейс, для ограниченного доступа чаще модель на своих серверах. В стратегии фиксируются правила выбора, а не конкретный продукт.
Сколько стоит разработка стратегии?
Мы делаем её в рамках обследования: 200 000 ₽ за один-два процесса, 350 000 ₽ за несколько систем, 500 000 ₽ за производство или контур. Цена фиксируется в договоре, вычитается из первого этапа, если продолжаете с нами.