ИИ в бизнесе: как не сжечь бюджет и не отстать

Парадокс мая 2026

Ситуация, в которой сейчас находится бизнес, выглядит так.

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

Внедрить в лоб — почти наверняка сожжёшь деньги. По разным оценкам 2025-2026 годов, от 75% до 95% корпоративных ИИ-инициатив либо не доходят до продакшена, либо не дают измеримого финансового эффекта (исследования MIT NANDA «GenAI Divide», август 2025; Prosigns; и др.). Цифры спорные — критики справедливо отмечают, что «нет измеримого P&L» ≠ «провал», часть авторов аффилирована с продавцами решений, а методология опирается на ограниченные выборки. Но общий сигнал устойчивый: большинство корпоративных проектов не окупается. Не потому что технология плохая. А потому что её прикручивают к старым процессам, не разобравшись, зачем именно.

Важно сразу развести два разных явления, которые в этой статистике часто путают. Индивидуальное использование ИИ сотрудниками (ChatGPT для черновика письма, расшифровка звонка, поиск формулы в Excel) — массово и часто полезно. Корпоративная инициатива с бюджетом, проектным офисом и подрядчиками — массово проваливается. Это разные вещи. Дальше речь в основном про второе.

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

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

Часть 1. Что ИИ делает для бизнеса

Если упрощать, ИИ обычно делает что-то одно из двух.

1. Снижает расходы. Заменяет человека на рутине или сильно его ускоряет. Меньше людей или те же люди делают больше работы. Сюда же — меньше ошибок и переделок.
2. Повышает выручку. Делает то, что без ИИ либо невозможно, либо слишком медленно. Быстрее отвечает клиенту — выше конверсия. Точнее рекомендует — выше средний чек. Глубже анализирует данные — лучше решения.

Есть и пограничные случаи — снижение рисков (комплаенс, безопасность, поиск аномалий), улучшение качества (меньше переделок, выше NPS), которые в P&L попадают не напрямую. На старте мыслить ими сложнее, поэтому первые пилоты разумно подбирать так, чтобы они укладывались в одну из двух категорий выше. К более сложным эффектам имеет смысл подходить, когда уже есть опыт пары рабочих проектов.

Если ты не можешь относительно чётко сказать, к какой из этих категорий относится твоя идея — стоит задержаться и подумать ещё. На этом фильтре отсеивается значительная часть «давайте попробуем».

«Давайте поставим ChatGPT всем сотрудникам» — это не категория. Это покупка инструмента без понимания, что с ним делать. Именно такие траты массово попадают в неокупающиеся.

Полезная формулировка звучит примерно так:

«У нас отдел поддержки отвечает на N однотипных писем в день, тратит на это X часов каждого сотрудника. Если ИИ возьмёт на себя бОльшую часть — освободим столько-то человеко-часов в неделю». Это снижение расходов.

Или:

«Менеджер обрабатывает заявку за часы. Если ИИ будет квалифицировать лида и готовить первичное предложение за минуты — мы успеем ответить раньше конкурентов». Это про выручку.

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

Часть 2. Этапы зрелости

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

Этап 0. Индивидуальное любопытство

Что происходит: отдельные сотрудники сами пробуют ChatGPT/YandexGPT/Claude для своих задач. Без системы, без бюджета, без согласований.
Цель этапа: разрешить и поощрить. Сделать так, чтобы это перестало быть «партизанским» использованием.
Инструментарий: то, чем сотрудники уже пользуются.
Культурный сдвиг: руководство вслух говорит — «пробовать можно, делиться находками — хорошо, бояться замены — не надо».
Промежуточный результат: ты знаешь, кто в компании уже умеет работать с ИИ. Это твой будущий кадровый резерв для тестовой команды.
Сколько занимает: несколько недель наблюдения.

Контекстная заметка. К 2026 году индивидуальное использование ИИ среди руководителей высшего звена и значительной доли сотрудников — это уже не «передовая практика», а базовое состояние рынка. Опросы конца 2025 — начала 2026 года показывают, что почти все C-level так или иначе пользуются генеративным ИИ для рабочих задач, а большинство сотрудников экономят таким образом несколько часов в неделю. Это значит, что Этап 0 в твоей компании, скорее всего, уже идёт сам по себе — вопрос только в том, замечаешь ли ты это и пользуешься ли этим знанием. И ещё одно: то, что Этап 0 успешен, не означает, что компания готова к Этапу 1. Индивидуальная польза и корпоративная окупаемость — разные вещи (см. парадокс в начале статьи).

Этап 1. Первый пилот

Что происходит: выбираем один процесс, собираем тестовую команду, делаем песочницу, доводим до запуска на одном отделе. Детально про эту фазу — Часть 4.
Цель этапа: убедиться на одном кейсе, что ИИ в вашей компании может давать измеримый результат. Не «в индустрии», не «у Сбера», а у вас, на ваших данных, в вашей рутине.
Инструментарий: одна-две подписки на ИИ-модель, одна low-code платформа для автоматизации, экспорт данных в песочницу.
Культурный сдвиг: появляется ритуал — «прежде чем делать новый процесс руками, спроси, можно ли его автоматизировать». Появляется тот, кто за это отвечает.
Промежуточный результат: один работающий процесс с замером «до/после», один обученный человек внутри, понимание реальной стоимости и сроков для вашей компании.
Сколько занимает: от нескольких недель (готовый облачный инструмент на типовой задаче) до 2-3 месяцев (кастомное решение с интеграцией).

Этап 2. Второй-третий процессы. Накопление опыта

Что происходит: используя опыт первого пилота, запускаем 2-3 параллельных процесса в разных отделах. Каждый — короче и дешевле первого.
Цель этапа: проверить, повторяется ли успех. Один работающий процесс может быть удачей. Три — это уже метод.
Инструментарий: расширяется. Появляются доступы к API, общая «база промптов», внутренняя документация «как мы делаем ИИ-проект».
Культурный сдвиг: сотрудники из разных отделов сами приходят с идеями: «а у нас тут такая рутина, можно посмотреть?». Когда появилась очередь снизу — Этап 2, считай, пройден.
Промежуточный результат: 3-4 рабочих процесса, накопленная база типовых решений, несколько человек, умеющих с этим работать.

Этап 3. Систематизация

Что происходит: ИИ перестаёт быть отдельным «экспериментом» и становится обычным инструментом. Появляются стандарты: как оценивать новые инициативы, как считать окупаемость, как обеспечивать безопасность данных, кто согласует доступ к моделям.
Цель этапа: убрать хаос. Чтобы ИИ-проект не зависел от энтузиазма одного человека, а проходил через ясный процесс.
Инструментарий: внутренний реестр ИИ-инициатив (что в работе, что в очереди, что отвергли и почему), типовая методика расчёта окупаемости (Часть 3), политика безопасности.
Культурный сдвиг: «ИИ-проект» перестаёт быть особенным словосочетанием. Это просто проект. Со своими этапами, бюджетом и KPI.
Промежуточный результат: устойчивый поток новых пилотов, низкая зависимость от конкретных людей, понимание совокупной экономики ИИ-направления.

Этап 4. ИИ в основе продукта и управления

Что происходит: компания начинает использовать ИИ не только для внутренних процессов, но и в продукте, в принятии решений, в стратегии. К этому этапу подходит меньшинство — и подходит честно, имея за плечами этапы 1-3.
Цель этапа: создать преимущество, которое без ИИ повторить сложно.
Инструментарий: возможно — собственные модели, тонкая настройка, локальная инфраструктура (Часть 6), интеграция с ключевыми бизнес-системами.
Культурный сдвиг: ИИ становится частью того, как компания думает о себе.

Большинство компаний за горизонт двух-трёх лет добирается до Этапа 2-3. Это нормально. На Этапе 3 уже идёт реальная экономика. Прыгать через этапы — основной способ потерять деньги.

Часть 3. Как считать эффективность

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

Сразу одна важная развилка, которая определяет всё дальнейшее.

Два разных сценария — разная экономика

Сценарий А. Готовый облачный инструмент на типовой задаче. Подписка на ChatGPT/Claude/YandexGPT, или готовый сервис типа транскрибатора звонков, или ИИ-функции уже встроены в твой CRM. Внедрение — это «дать сотрудникам доступ + договориться, как использовать + замерить». Без разработки, без интеграций, без своей инфраструктуры. Стоимость стартует от десятков долларов в месяц. Запуск — дни или недели. Отдача может прийти быстро.

Сценарий Б. Кастомное решение с интеграцией. Пайплайн в Make/n8n с подключением к CRM, или собственный инструмент на API модели с обвязкой, или локальное развёртывание. Здесь появляются время на разработку, тестирование, обкатку, обучение людей. Стоимость — десятки и сотни тысяч рублей единовременно плюс ежемесячное сопровождение. Запуск — недели и месяцы. Отдача — соответственно дольше.

Это два разных вида проектов с разной экономикой. Если их мерить одной линейкой, либо первый покажется подозрительно быстрым («так не бывает»), либо второй — провальным («где результат через месяц»). Дальше при разговоре о сроках и порогах будем разделять.

Когда отдача может прийти быстро

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

• Готовый облачный инструмент на типовой задаче. Транскрибатор звонков, который встал в работу отдела продаж. ChatGPT для черновиков ответов в поддержке. ИИ-функция в CRM, которая уже там есть и которую просто включили. Стоимость — десятки долларов в месяц на пользователя. Если задача массовая и регулярная — окупаемость может быть в первые недели использования.
• Высокообъёмный повторяемый процесс. Чем выше объём, тем быстрее накапливается экономия в абсолютных деньгах при той же стоимости инструмента. 1000 расшифровок в месяц с экономией 10 минут каждая — это уже серьёзная экономика даже при копеечной стоимости инференса.
• Пилот без интеграции в боевые системы. Если на старте не интегрируешь ИИ в CRM / биллинг / 1С, а просто кладёшь черновики в почту или в общую папку — экономишь недели и месяцы на разработке. Это меняет всю экономику пилота. Интеграция — следующий этап, когда уже понятно, что инструмент полезен.
• Дешевеющий инференс. Стоимость токенов у крупных провайдеров за последние два-три года упала в сотни раз и продолжает падать — примерно в 5-10 раз в год для frontier-моделей, ещё быстрее для отдельных классов задач. Если ты делал расчёт «не окупится» год назад — пересчитай по текущим ценам, ответ мог измениться.
• Инструменты, которые убирают конкретное узкое место. Если у тебя в воронке продаж заявки лежат необработанными по 4 часа, а конкуренты отвечают за 15 минут — даже простой ИИ-помощник, который сразу шлёт первичный ответ и квалификацию, окупится с первых же спасённых сделок.

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

Шаг 1. Базовый замер до пилота

Самая частая ошибка — начинать пилот без baseline. Через два месяца не на чём показать улучшение. «Кажется, стало лучше» — не аргумент для бюджета.

Что меряем ДО того, как ИИ войдёт в процесс:

• Время на одну операцию. Хронометраж. Сотрудник записывает в простую таблицу: дата, тип заявки, время начала, время окончания. Это можно делать в обычной Google-таблице, никакой автоматизации пока не надо.
• Объём за период. Сколько обращений/документов/звонков проходит через процесс за день и за неделю. Если объём сильно колеблется — посчитай среднее и разброс.
• Частота ошибок и переделок. Что считается ошибкой в этом процессе и сколько их в неделю. Если сейчас никто не считает — значит первая задача не ИИ, а ввести учёт ошибок хотя бы на месяц.
• Полная стоимость часа сотрудника. Не «зарплата на руки», а нагруженная: зарплата + налоги + страховые + аренда рабочего места + ПО + амортизация техники. В российских реалиях это в 1,5-2 раза выше зарплаты на руки. Если у бухгалтерии нет готовой цифры — посчитай сам, не пропускай этот шаг. Без него экономия времени не превратится в деньги.

Сколько длится замер. Зависит от объёма процесса.

• Если через процесс проходит 50+ операций в день — двух недель достаточно с запасом.
• Если 5-10 операций в день — двух недель хватит, чтобы понять основную картину.
• Если операций мало (несколько в неделю) — растягивать замер на месяцы не надо. Лучше зафиксировать хронометраж 10-15 типичных случаев и идти дальше, понимая, что статистика слабая.

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

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

Шаг 2. Обозначить одну главную метрику

У пилота должна быть одна главная цифра, по которой принимается решение «идём дальше или закрываем». Не три, не пять. Одна.

Примеры:

• Среднее время обработки одной заявки сократилось на X%
• Доля заявок, на которые ответили в течение 15 минут, выросла с Y% до Z%
• Стоимость обработки одного документа упала с N рублей до M рублей
• Конверсия из заявки в сделку выросла на P пунктов

Эта метрика должна быть:

• Привязана к деньгам (либо прямо, либо через очевидную цепочку: время → деньги, скорость ответа → конверсия → выручка)
• Измерима в тех же единицах, что и baseline (нельзя «было в часах, стало в звёздочках»)
• Иметь заранее заданный порог успеха. Например: «считаем пилот успешным, если время на обработку сократилось минимум на 20%, иначе закрываем».

Порог нужно зафиксировать ПЕРЕД запуском, а не подгонять по факту. Иначе любая цифра задним числом покажется успехом.

Плюс 2-3 диагностические метрики, чтобы понимать, что происходит:

• Качество ответа (например, процент ответов, которые сотрудник принял без правок)
• Реальное использование — пользуются ли сотрудники инструментом, на каком объёме работы
• Удовлетворённость команды (короткий опрос раз в неделю, оценка 1-5)

Про «реальное использование» — отдельная мысль. Часто говорят про процент сотрудников, реально работающих с ИИ. Цифра сама по себе мало что значит. Если из 20 человек активно пользуются 5, но они обрабатывают 80% объёма — это не провал, это нормальное распределение. Смотри не на процент людей, а на процент работы, которая прошла через ИИ. Если этот процент маленький — есть смысл разобраться почему: не подходит для задачи, неудобно, не доверяют, не научили. Это диагностический сигнал, а не приговор пилоту.

Шаг 3. Пилот с контрольной группой — если получается

Это шаг, который чаще всего пропускают. Без контрольной группы потом сложнее доказать, что улучшение — заслуга ИИ, а не чего-то ещё (сезон, новый менеджер, изменение трафика).

Простейший вариант: в отделе 10 человек. Пять работают с ИИ-помощью, пять продолжают работать по-старому. Через месяц сравниваешь их метрики между собой.

Более продвинутые варианты:

• A/B-тест: входящие заявки случайно делятся пополам. Половина идёт через ИИ, половина через обычный процесс.
• Поэтапный запуск: первый филиал/отдел в этом месяце, второй — в следующем. Сравниваешь между собой и каждый с собой во времени.

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

Шаг 4. Ритм замеров и перевод в деньги

Ритм зависит от того, какой у тебя сценарий.

Для Сценария А (готовый облачный инструмент). Цикл сжимается.

• Конец 2-й недели: уже видно, пользуются ли люди и помогает ли. Если на типовой задаче после двух недель использования никто не сэкономил время — скорее всего, не та задача или не тот инструмент. Можно закрывать или менять.
• 1-й месяц: первая оценка экономии в часах и попытка перевести её в деньги.
• 3-й месяц: окончательное решение «масштабируем / закрываем / меняем подход».

Для Сценария Б (кастомное решение). Цикл длиннее.

• Месяц 1: меряем, пользуются ли (см. диагностику в Шаге 2), процент ответов ИИ, которые пришлось переделать (качество), число ошибок в выходных данных. На этом этапе экономии может ещё не быть — люди только учатся.
• Месяц 3: главная метрика против baseline. Сравниваешь с контрольной группой или с собой до пилота. Тут уже видно — работает или нет.
• Месяц 6: считаешь реальную экономику. Не «потенциальную», а сколько реальных часов сэкономлено × полная стоимость часа, минус все реальные расходы. Это первая точка, где можно сказать «окупился» или «нет».
• Месяц 12: сравниваешь фактический ROI с планом. Зафиксированный разрыв (если он есть) — самое ценное знание для следующих пилотов.

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

Пример (цифры условные, для иллюстрации механики):

• До пилота: 25 минут на обработку одной заявки
• После: 10 минут на ту же заявку
• Экономия: 15 минут на заявку
• Объём: 800 заявок в месяц
• Экономия в часах: 15 × 800 / 60 = 200 часов в месяц
• Экономия в деньгах: 200 × твоя полная стоимость часа

Дальше по той же логике добавляешь экономию на ошибках (число предотвращённых ошибок × средняя цена одной ошибки) и, если есть, прирост выручки от скорости. Из этого вычитаешь расходы: подписка / стоимость API за месяц + амортизация затрат на разработку (раздели единовременные затраты на 12 или 24 месяца) + сопровождение (часы команды на поддержку).

Трассировка в P&L

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

Прямые финансовые эффекты (видны в P&L сразу):

• «Через 6 месяцев не наняли двух планируемых сотрудников» — снижение ФОТ в плане найма.
• «Сократили один штатный юнит на отделе» — прямое снижение ФОТ.
• «Освободившееся время перенаправили на работу, на которую раньше не успевали, и она дала прирост выручки X» — прирост в выручке.

Косвенные эффекты (видны в операционных метриках, в P&L проявляются через квартал-два):

• Стало успеваться больше клиентов на одного менеджера, выручка отдела растёт. Здесь нужно подождать накопления и проверить, что рост действительно связан с освободившимся временем, а не с сезоном или маркетингом.
• Снизилась нагрузка, сотрудники реже выгорают и реже увольняются. Эффект реальный, но через ФОТ виден только когда сокращается стоимость найма и адаптации замен.

Чего лучше не считать вообще:

• «Сотрудники стали успевать больше, эффективность выросла». Если «больше» не превратилось ни в выручку, ни в снижение ФОТ, ни в число обработанных заявок — это не эффект, это ощущение.

Эта дисциплина неприятная, но именно она отделяет компании, у которых ИИ окупается, от тех, у кого «вроде что-то делает».

Когда не начинать

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

Ориентиры из практики

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

• Реалистичная экономия времени на типовых текстовых задачах (классификация писем, черновики ответов, саммари звонков) — от 30% до 60% времени на операцию. На высокообъёмных и хорошо описанных задачах, когда инструмент уже встроен в рутину (поддержка, обработка типовых обращений, расшифровка звонков), верхняя граница смещается ощутимо выше — встречаются устойчивые цифры в 50-80%, а доля обращений, закрывающихся ИИ без участия человека, у крупных вендоров поддержки доходит до десятков процентов. Если в расчёте получается «почти всё» на сложных нетиповых задачах — скорее всего, ты завышаешь, и потом разочаруешься.
• Снижение частоты ошибок на задачах классификации и проверки — в 3-5 раз против ручной работы.
• Скрытые расходы (обучение, изменение процессов, безопасность, юридическая проверка) увеличивают бюджет ощутимо — закладывай запас сразу. (Про дешевеющий инференс — уже сказано выше в блоке «когда отдача может прийти быстро».)

Часть 4. Первый пилот на практике

Эта часть детализирует то, что в Части 2 названо Этапом 1. Здесь — как выбрать процесс, как собрать песочницу и кого посадить заниматься этим внутри компании.

4.1. С чего начинать

Самая частая ошибка — начинать с самого важного. Лучше начать с самого скучного.

Первый процесс хорошо бы выбрать по пяти критериям, и пятый из них — главный.

5. Описуемый. Это не последний пункт по важности, а первый по причине провала. Важно понимать, что именно делает человек, который сейчас занимается этим процессом. Какие шаги, в каком порядке, по каким признакам принимает решения. Если на вопрос «как ты это делаешь?» сотрудник отвечает «ну, по ощущениям» или «по опыту» — это сигнал. Не значит, что автоматизировать нельзя. Значит, что первый этап — не ИИ, а описание процесса.

Часто оказывается, что половина «процесса» живёт в голове одного человека: он смотрит на письмо и за полсекунды решает, кому переслать. Спросишь почему — не объяснит. ИИ такое «не объяснит» воспроизвести не сможет, пока ты сам не разложишь это на признаки. Поэтому до песочницы полезен короткий шаг: посадить носителя процесса рядом и разобрать 20-30 типичных кейсов вслух — что он видит, по чему решает, что делает.

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

Остальные четыре критерия:

1. Повторяемый. Делается каждый день или каждую неделю по более-менее одинаковому сценарию. Не разовая аналитика — её ИИ всё равно не закроет.
2. Измеримый. Понятно, сколько часов уходит и какой объём проходит через процесс. Если непонятно — это пока не процесс, а ощущение.
3. Низкий риск ошибки. Если ИИ ошибётся — потери не катастрофические. Не финансовая отчётность, не медицинские диагнозы, не юридические заключения в суд. А черновики писем, классификация заявок, расшифровка звонков, первичный отбор резюме.
4. Есть baseline. Известно, как процесс работает сейчас и сколько занимает. Без этого потом будет нечем доказать, что ИИ что-то улучшил.

Чаще всего подходят на первый запуск:

• Обработка типовых обращений клиентов (поддержка, FAQ)
• Расшифровка и саммари звонков менеджеров
• Первичный отбор резюме и составление вопросов на собеседование
• Составление черновиков коммерческих предложений по типовому шаблону
• Подготовка отчётов из CRM и таблиц на естественном языке

Чаще всего не стоит брать первым:

• Финансы и бухгалтерию
• Юридические документы
• Стратегическое планирование
• Креативный маркетинг (бренд-коммуникации)
• Всё, что требует контекста по всей компании сразу

Иллюстративный кейс (анонимизированный). Сервисная компания, ~30 сотрудников, отдел продаж жалуется на «нет времени». Замер: средний менеджер тратит в день ~40 минут на расшифровку и саммари звонков и ещё ~50 минут на черновики коммерческих по типовым запросам. Внедрили готовый сервис расшифровки + ChatGPT с заранее настроенными промптами на черновик КП. Через три недели использования экономия около часа в день на менеджера, или пять рабочих часов в неделю на каждого. Никакой разработки, никакой интеграции с CRM на старте — просто два готовых инструмента и описанные правила, в каких случаях ими пользоваться. Интеграция в CRM появилась через четыре месяца, когда стало понятно, что инструмент прижился. Это типичный профиль пилота из Сценария А: дешёвый старт, быстрая отдача, наращивание сложности по мере того, как привычка устаканивается.

4.2. Песочница

Песочница — небольшое огороженное пространство, где пробуешь ИИ на реальных задачах, но без риска что-то сломать в боевых системах.

Минимальный набор:

1. Один аккаунт ChatGPT Plus или Claude Pro или Yandex GPT Premium.
2. Аккаунт на платформе автоматизации без кода: Make, n8n (можно self-hosted бесплатно), Lindy, Albato.
3. Доступ к API одной из языковых моделей с небольшим стартовым депозитом.
4. Тестовая копия данных — экспорт CRM в Google Sheets, выгрузка обращений за месяц, шаблоны документов. Никаких боевых интеграций пока.

Алгоритм:

• Неделя 1. Тестовая команда берёт один процесс и руками прогоняет через ChatGPT/Claude. Без автоматизации. Просто копируют письмо, спрашивают, получают ответ, оценивают качество. Делают так несколько десятков раз на разных кейсах.
• Неделя 2. Собирают статистику. В скольких случаях ответ был сразу пригоден? В скольких пришлось переписать? В скольких — забраковали? Если меньше половины пригодны — настраивают промпт, дают примеры, добавляют контекст компании.
• Неделя 3-4. Когда качество стабильное, собирают это в простой пайплайн через Make или n8n. Письмо приходит — попадает в ИИ — ответ ложится в черновики, человек проверяет и отправляет.
• Месяц 2. Запуск в работу на одного-двух сотрудников. Не на весь отдел. Смотрим месяц, замеряем экономию, фиксируем баги.
• Месяц 3. Если работает — масштабируем на весь отдел. Если нет — честно закрываем эксперимент. Это нормально. Часть пилотов так и закроется.

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

4.3. Кого собрать на старте

Распространённая ошибка — поручить ИИ-эксперименты IT-отделу или нанять отдельного «руководителя направления ИИ».

Почему не айтишники. Они начнут с инфраструктуры — какую модель развернуть, какой векторный поиск, какая база данных. Потратят месяцы на платформу. Бизнес-процесс они обычно не знают и не любят. На выходе — красивая штука, которой никто не пользуется.

Почему не отдельный «руководитель ИИ». Сразу начнёт строить большое видение, делать стратегию, нанимать команду. Эффект — через год, если повезёт. Деньги — прямо сейчас.

Кто нужен на старте — 2-3 человека внутри компании. Это не «команда» в смысле выделенного штата, это маленькая рабочая группа, в которой все заняты процентов на 20-30:

1. Один сотрудник из того отдела, чей процесс автоматизируем. Не руководитель — линейный человек, который сам делает эту работу руками каждый день. Он знает все нюансы, исключения, «а вот ещё бывает». Без него ИИ не настроишь.
2. Один человек с техническим складом ума — необязательно программист. Маркетолог, который умеет в Excel-формулы и Google Sheets, или менеджер, который сам собирал интеграции в Bitrix. Главное — не боится разобраться в Make/n8n и API.
3. Один человек, который принимает решения. Кто-то из руководства, кто может за один разговор сказать «да, идём дальше» или «нет, закрываем». Без этого группа упрётся в согласования.

Где их найти внутри:

• Кто из сотрудников сам уже пробует ChatGPT для работы (те самые люди с Этапа 0).
• Кто жалуется на рутину больше всех. Они мотивированы её убрать.
• Кто умеет осваивать новые инструменты быстро.

Нанимать со стороны на первом этапе обычно не имеет смысла — внешний человек не знает бизнес и потратит первые месяцы на адаптацию.

Часть 5. Культурные изменения

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

• Привычка измерять. До ИИ многие процессы шли «как-то». Сколько часов уходит — никто не считал. С ИИ это становится невозможно — нужно базовое измерение, иначе непонятно, был ли эффект. Этот навык остаётся в компании и после конкретного проекта.
• Привычка описывать. Параллельно с привычкой измерять. До ИИ многое жило в головах конкретных людей — и в этом не было проблемы. С появлением ИИ становится важно уметь разложить «как я это делаю» на шаги и признаки. Это полезный навык сам по себе: уходит зависимость от незаменимых людей, новых проще вводить в работу.
• Привычка пробовать и закрывать. Раньше — «начали проект, обязаны довести». С ИИ — нет. Часть пилотов закрывается, потому что не показала экономики. Это не провал, а нормальная гигиена. Без этой культуры компания начинает тащить десяток мёртвых ИИ-проектов «потому что вложились».
• Привычка делиться внутри. Если в одном отделе нашли хороший промпт или собрали работающий пайплайн — это должно быстро становиться доступным остальным. Общий канал, база промптов, регулярные короткие демо «что нового получилось».
• Отношение к ошибкам. ИИ ошибается. Не «может ошибаться» — а гарантированно ошибается на какой-то доле случаев. С этим нужно жить и проектировать процессы с учётом этого, а не делать вид, что ИИ — это «правильный ответ из машины». Роль сотрудника — не «передать вопрос ИИ», а «проверить и принять решение».
• Открытый разговор про сокращения. Если люди боятся, что ИИ их заменит — они саботируют. Если знают, что освободившееся время пойдёт на работу, которую раньше не успевали — помогают. Разговор должен быть искренним. Если ты планируешь сокращения — лучше сказать правду заранее и помочь перестроиться.
• Ясное право на ИИ. Должен быть понятный ответ на вопросы «можно ли мне это использовать?», «что можно отправлять, что нельзя?», «к кому идти с идеей?». Без ясных правил половина людей не пробует ничего на всякий случай.

Часть 6. Облако или локально

Эта развилка появляется не сразу. На Этапе 1, как правило, достаточно облака. К вопросу «может, пора своё?» компания подходит позже — обычно на Этапе 3, когда уже есть несколько работающих процессов, понятный объём и реальные расходы на API.

Путь 1: Облако

Платишь по API за запросы (OpenAI, Anthropic, Yandex GPT, Sber GigaChat) или подписка на готовый сервис.

• Плюсы: быстро запустить, не нужна инфраструктура, всегда свежая модель, платишь за факт использования.
• Минусы: на больших объёмах дорого, данные уходят на чужой сервер, зависимость от провайдера.
• Когда выбирать: на старте, при тестировании гипотез, при умеренных объёмах, когда данные не критичные.

Путь 2: Локальное решение

Свой сервер с открытой моделью (Llama, Qwen, DeepSeek, локальные варианты GigaChat и YandexGPT).

• Плюсы: данные не выходят из контура, на больших объёмах сильно дешевле, не зависишь от внешних провайдеров.
• Минусы: ощутимые стартовые вложения в железо, нужен инженер на поддержку, открытые модели слабее коммерческих на сложных задачах, запуск занимает месяцы.
• Когда выбирать: когда объём стабильно высокий, или когда данные критичные (медицина, юристы, банки, оборонка), или когда стратегически важна независимость от внешних сервисов.

Большинство малого и среднего бизнеса до объёмов, при которых локальное окупается, не доходит никогда. Это нормально.

Часть 7. Подводные камни

Не претендую на полноту. Это то, что в моей практике чаще всего реально валит проекты.

1. Саботаж из-за страха. Если люди боятся замены — они не дают честную обратную связь, не тестируют, специально находят плохие примеры. Лечится открытым разговором (см. Часть 5) и подкреплением делом.
2. Качество данных. ИИ работает на твоих данных — если в CRM мусор, на выходе будет мусор. Перед внедрением имеет смысл посмотреть, в каком состоянии данные процесса, который автоматизируешь. Если данных нет или они в полном бардаке — сначала порядок, потом ИИ.
3. Подрядчик продаёт стратегию вместо тактики. Типичная история: к компании, у которой ещё нет ни одного работающего пилота, приходят с предложением «ИИ-стратегии на год» — несколько миллионов рублей, презентации, дорожные карты, ничего работающего на выходе. Полезный фильтр: если подрядчик предлагает «стратегию» раньше, чем «один конкретный процесс, который мы запустим за два месяца», — это, скорее всего, не тот подрядчик. Стратегия — это Этап 3, когда есть что обобщать. До этого нужны тактические пилоты.
4. Bus-factor один. Часто весь ИИ-проект держится на одном энтузиасте, который освоил Make/n8n и пишет промпты. Он уходит — проект через месяц встаёт. Лечится тем, чтобы с самого начала пайплайны и промпты лежали в общедоступном месте и были описаны на человеческом языке, а в команде было хотя бы два человека, которые понимают, как это устроено.
5. Технический долг от «быстро собрали и забыли». Пайплайн собирали на коленке, чтобы быстрее проверить гипотезу — это нормально для песочницы. Но если он же ушёл в боевую работу без перепроверки и документации, то через полгода никто не помнит, почему там стоит именно этот промпт, что делает вон тот узел в Make и зачем нужна эта дополнительная проверка. Когда что-то сломается — чинить будет некому. Лечится разделением «черновой пилот» и «продакшен-версия»: после того как песочница показала результат, рабочий пайплайн собирается заново, аккуратно и с документацией.
6. Хайп вместо задачи. Команда увлекается технологией, забывает про задачу. «Давайте попробуем мультиагентную систему», «давайте развернём свою модель», «давайте сделаем RAG». Возвращай к вопросу — какую конкретную бизнес-задачу мы сейчас решаем? Если красивая технология не решает задачу — отложи её.
7. Безопасность данных. Когда сотрудники массово начинают отправлять в ChatGPT клиентские базы, договоры, финансовые данные — это утечка с реальными последствиями. Правила: что можно отправлять в облако, что — нельзя. Что нельзя — либо обезличивать, либо через локальную модель.

Вместо итога

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

Все остальные правила в этой статье — производные от этой мысли. Этапы зрелости, песочница, контрольная группа, трассировка в P&L, описание процесса до автоматизации — это всё про одно: про то, чтобы перестать действовать по ощущениям и начать видеть, что в компании реально работает.

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