В первой статье мы разобрали, почему доступ к модели ещё не означает внедрение ИИ. Рабочий результат появляется только тогда, когда вокруг модели выстроены данные, методология, процесс, контроль и человеческая ответственность.

Теперь разберём следующий вопрос. Как эта система выглядит в ежедневной работе и какие механизмы не дают ошибке дожить до управленческого решения.

Ниже семь практических правил, к которым я пришла, пока строила управленческие контуры для команд своих клиентов. Продажи на двух маркетплейсах, совокупный ассортимент около 20 000 SKU. Дальше разберём кейс, где пришлось опровергать исходную гипотезу, и проверим, по каким признакам компания переходит от экспериментов к управляемой системе.

Семь приёмов, которые дали больше всего

Это не теория, а рабочие правила. Каждое снимает свой класс проблем.

1. Модель интерпретирует. Считает проверяемый расчёт

Языковая модель не должна быть источником истины в массовых расчётах. Современная ИИ-система умеет запускать код и вычислительные инструменты, но точные числа всё равно рождаются в отдельном расчётном контуре, который можно воспроизвести и принять.

Мы пробовали обеспечить надёжность только промптом. Этого оказалось недостаточно.

Закрылось архитектурой. Расчёт сам собирает сводку, сам проставляет метки по порогам, сам формирует готовые списки «требуют усиления», «на отключение», «на пересмотр плана» и сам строит итоговую таблицу разбора. Модель списки не пересобирает. Она объясняет, почему товар в них попал, и отвечает на вопросы менеджера.

Правило-хребет всей системы умещается в одну строку.

Показательная деталь. Теоретически возможных сочетаний кодов 108, а на реальных данных встречается около тридцати. Остальные невозможны по построению модели. Это знание живёт в методологии и в расчёте, а не в модели.

2. Контекст это продукт, а не переписка

Слепок проекта, реестр версий, журнал релизов, реестр решений. Всё это пишут не «для истории», а как рабочий вход в следующую сессию.

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

3. ИИ работает как оппонент, а не только как исполнитель

Прямой вопрос «как аналитик, согласен или нет?» и требование контраргументов, а не поддержки. Методология дорабатывается через спор.

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

Ответ без границ применимости это не результат, а мнение.

4. Границы автономии заданы заранее, а не по ходу

Предлагать можно и нужно. Вносить крупные правки только по явной отмашке.

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

5. Ошибка чинится на том уровне, где она возникла

Когда в работе ИИ-роли находится ошибка, первый вопрос звучит не «как поправить промпт», а «на каком уровне это чинится»:

• сбор и обработка чисел через расчёт;
• поведение и формат ответа через системный промпт;
• недостающее знание через карточка в базе знаний.

Без этого правила промпт быстро превращается в свалку заплаток, которая перестаёт работать целиком.

6. ИИ-роль проходит аттестацию, как сотрудник

До выдачи менеджерам наставник проходит приёмочный тест. 13 вопросов, зачёт от 11 правильных. Дальше качество проверяют транскриптами реальных прогонов, построчно против сводки и правил, а найденное чинят на нужном уровне из пункта 5.

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

7. У ИИ-роли есть себестоимость и ограничения по контуру

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

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

Отдельная тема это режим доступа. Когда круг людей с правом редактирования расширился до нескольких десятков, ключ доступа к сводке ротировали, а в учебные и архивные копии расчёта пошла заглушка. Живое значение существует ровно в двух местах, и это записано в регламенте.

Практический пример: гипотеза, которую пришлось опровергать

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

Исходная ситуация. В конце весны компания остановила около сотни позиций товарной группы A. Причина в логистике, бой и возвраты. Через несколько месяцев появилась гипотеза. Товары группы A по отдельности вообще не нужны, спрос естественным образом уходит в сопутствующую группу B, значит группу A закрываем и развиваем B.

Задача пришла не как вопрос, а как готовый вывод. Категорийный менеджер подготовил под гипотезу расчёт, сравнение продаж пар «товар из A» и «товар из B» до и после остановки. По заказам выходило, что группа B подхватывает спрос.

Вариант 1. Как эта задача решается по умолчанию

Расчёт загружают в модель с запросом «проверь и оформи обоснование».

Модель добросовестно его оформит. И будет права, потому что расчёт внутренне непротиворечив.

Проблема в том, что он смотрел только на заказы, то есть на последний слой воронки. Там группа B действительно выглядела лучше. Всё, что происходило выше, в расчёт не входило, и любая работа поверх него унаследовала бы этот горизонт.

Ошибку здесь допускает не модель, а постановка. И это самый частый способ применить ИИ во вред. Попросить его достроить чужой вывод вместо того, чтобы проверить исходный вопрос. Результат получится аккуратным, убедительным и неверным, причём быстро.

Вариант 2. Управляемый анализ

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

Проверить, действительно ли спрос переходит из группы A в группу B, отделить переход спроса от общего роста рынка и оценить прямые потери в случае закрытия группы A. Разделить подтверждённые факты и гипотезы, указать, каких данных не хватает.

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

• проверить воздействие во всех системах, это остатки по всем схемам поставки, реклама, карточка и план;
• идти по воронке строго сверху вниз (показы - клики - корзины - заказы - деньги);
• обязательно иметь контрольную группу и считать стоимость замещения.

Слой 1. Заказы, но против контрольной группы. Сравнение «до и после» само по себе ничего не доказывает, потому что меняется весь рынок. Считали методом разности разностей. Группа B выросла на 10%, тогда как контрольная группа за тот же период выросла на 88%. Относительно рынка группа B спрос не подхватила, а отстала от него на 78 процентных пунктов.

Слой 2. Поток, а не заказы. Здесь гипотеза развалилась окончательно. Остановленная группа A давала больше половины всех показов своей товарной группы, то есть была не слабым ассортиментом, а донором трафика. При этом CTR группы B после остановки не изменился, перетока внимания не произошло.

Слой 3. Деньги. Посчитали прямые потери от остановки и отдельно стоимость замещения потерянного потока рекламой. Восстанавливать трафик пришлось бы по цене привлечения в разы дороже, чем стоил органический поток группы A. Величина потерь оказалась такой, что вопрос сняли с обсуждения.

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

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

Второй оказался почти ироничным. У группы B, которую предлагали развивать, почти половина возвратов приходилась на бой при доставке. То есть логистическая проблема, из-за которой останавливали группу A, спокойно жила и в «перспективном» формате. В исходной гипотезе этого не было вообще.

Как оформлен результат

Итог анализа собирают в одну структуру.

Наблюдение - подтверждающие данные - возможная причина - уровень уверенности - дополнительная проверка - действие - риск.

Пример реальной строки из этого разбора.

Наблюдение. Группа B выросла на 10%.

Подтверждающие данные. Контрольная группа за тот же период выросла на 88%, отставание 78 п.п. Группа A давала больше половины показов товарной группы. CTR группы B после остановки не изменился.

Возможная причина. Переключения спроса из A в B не происходит, рост B слабее рыночного фона.

Уровень уверенности. Высокий по направлению вывода, средний по величине эффекта. Нужна вторая контрольная точка.

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

Действие. Гипотезу закрытия группы A снять. Вопрос возвратов группы B вынести в отдельную задачу.

Риск. Тестовый период короткий. При сезонном сдвиге в категории величина расхождения изменится, а направление вряд ли.

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

Что в этом примере делает ИИ

При правильно организованной работе ИИ способен:

• быстро обработать несколько массивов данных;
• сопоставить периоды;
• найти отклонения;
• определить момент изменения;
• предложить возможные взаимосвязи;
• сформировать гипотезы;
• указать недостающие данные;
• подготовить варианты действий;
• составить управленческое резюме.

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

Но он не должен самостоятельно:

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

Граница проходит там же, где и во всей системе. Расчёт считает и размечает, ИИ интерпретирует, человек решает.

Четыре уровня зрелости работы с ИИ

Уровень 1. Стихийные эксперименты. Сотрудники используют разные модели и ставят задачи по собственному усмотрению. Результаты зависят от конкретного человека и почти не сохраняются как корпоративный опыт.

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

Уровень 2. Регулярные сценарии. Компания определяет несколько задач, для которых ИИ используется постоянно. Появляются шаблоны запросов, форматы ответов и первые правила проверки.

Основной признак. Отдельные процессы ускорились, но ещё сильно зависят от ручной работы конкретных сотрудников.

Уровень 3. Управляемые ИИ-роли. Компания описывает роли: например, ИИ-аналитик, ИИ-менеджер по рекламе или ИИ-помощник по ассортименту.

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

Основной признак. Работа становится воспроизводимой и контролируемой.

Уровень 4. Интегрированная система. ИИ встроен в процессы компании и взаимодействует с данными, расчётными инструментами и сотрудниками. Качество регулярно измеряется. Ошибки фиксируются. Методология обновляется. Автономность растёт только после подтверждения надёжности.

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

Из практики. Как выглядит переход между третьим и четвёртым уровнем

Описанные контуры находятся на третьем уровне, а по нескольким элементам уже на четвёртом.

Третий уровень закрыт полностью. У ИИ-роли есть цель, база знаний, ограничения, формат ответа, приёмочный тест перед выдачей и ответственный человек. Есть регламент, в каком порядке считать.

Есть роли, проставленные в самом результате.

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

Незакрытое я держу списком осознанно, а не «когда-нибудь». Это автоматическая оценка экономического эффекта, регулярный замер качества ответов на потоке и замкнутая петля «решение - результат - корректировка методологии». Обратную связь пока собираю вручную, разбором транскриптов.

Разрыв между третьим и четвёртым уровнем лежит не в технологии. Он в том, что кто-то должен регулярно тратить время на измерение качества. И это тоже управленческое решение, а не техническое.

Как понять, что компания пока только экспериментирует

Скорее всего, системного внедрения ещё нет, если:

• каждый сотрудник работает с ИИ по-своему;
• качество оценивается субъективно;
• нет утверждённых источников данных;
• нет общего словаря показателей;
• результаты остаются в личных чатах;
• удачные решения невозможно воспроизвести;
• ошибки не фиксируются;
• рекомендации не связаны с историей принятых действий;
• никто не отвечает за качество ИИ-процесса;
• эффект оценивается только по сэкономленному времени;
• руководство не знает, какие решения принимаются с участием ИИ.

Это не значит, что эксперименты бесполезны. Они нужны, чтобы найти подходящие сценарии.

Проблема возникает тогда, когда компания считает эксперимент готовым внедрением и начинает масштабировать его без методологии и контроля.

Чек-лист готовности задачи к внедрению ИИ

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

Бизнес-задача

• Понятно, какую проблему мы решаем?
• Определён ожидаемый результат?
• Результат связан с конкретным бизнес-показателем или управленческим действием?
• Мы решаем задачу или достраиваем чужой готовый вывод?

Данные

• Известны источники данных?
• Данные полны и актуальны?
• Показатели имеют единые определения?
• Один и тот же показатель считается от одного и того же знаменателя во всех местах?
• «Нет данных» отличается от «плохо», или пропуск трактуется как худшая оценка?

Методология

• Описана последовательность работы?
• Понятно, какие расчёты необходимы?
• Установлены правила отделения фактов от гипотез?
• Определено, какие выводы требуют дополнительного подтверждения?
• Известно, какие периоды сравнивать нельзя?

Роль ИИ

• Понятно, что именно делает ИИ?
• Что делает расчёт, а что модель?
• Определён формат результата?
• Установлены ограничения и границы автономии?
• Описаны ситуации, в которых задача должна быть передана человеку?

Контроль

• Можно проверить исходные данные и расчёты?
• Можно воспроизвести результат?
• Определены критерии качества?
• Известно, какая версия методики и расчёта сейчас развёрнута?
• Ответ называет, чего он не покрывает?
• Фиксируются ошибки и обратная связь?

Ответственность

• Назначен владелец процесса?
• Понятно, кто утверждает действия?
• Определено, кто отвечает за последствия решения?
• Есть возможность быстро вернуть процесс под полный ручной контроль?

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

С чего начинать руководителю

Первый вопрос звучит не так. Какую модель нам выбрать?

Гораздо полезнее спросить.

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

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

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

ИИ не уменьшает значение управления

Иногда внедрение ИИ представляют как способ убрать часть управленческой работы.

На деле ИИ делает качество управления ещё более значимым.

Он способен ускорить сильный процесс, но с той же скоростью может масштабировать:

• ошибки в данных;
• неясные цели;
• противоречивые правила;
• слабую аналитику;
• неверные показатели;
• отсутствие ответственности.

Поэтому зрелость работы с ИИ определяется не количеством моделей и не числом написанных промптов.

Она определяется тем, насколько компания умеет:

• формулировать задачи;
• описывать методологию;
• управлять данными;
• проектировать роли;
• контролировать качество;
• принимать решения;
• учиться на обратной связи.

Главный вывод

Доступ к модели можно получить за несколько минут. Для конкурентного преимущества этого мало.

Преимущество возникает тогда, когда компания строит вокруг ИИ собственную систему работы. Со своими данными, методологией, ролями, ограничениями и накопленным опытом.

Оглядываясь на обе статьи, замечу вот что.

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

И ни один из механизмов, которые их поймали, не является функцией модели. Аудит данных, регламент порядка расчёта, сверка документа против кода, стражи в расчёте, приёмочный тест, колонка ответственного, пометка «оценка условная». Всё это спроектировано.

Именно поэтому сама модель остаётся лишь частью результата. Основную ценность создаёт нормальная, последовательная и взвешенная работа по развитию управления.

В следующей статье разберём, как проектировать конкретные ИИ-роли на маркетплейсах. Что могут делать ИИ-аналитик и ИИ-менеджер по рекламе, насколько широко можно использовать их возможности и где должны проходить границы их самостоятельности.