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

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

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

На практике с доступа к модели работа только начинается.

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

Поэтому я работаю по такой управленческой формуле.

Модель даёт примерно 10% успеха. Остальные 90% приходятся на методологию, данные, процессы, роли, контроль и ответственность.

Это не статистика, а способ расставить акценты. Формула помогает отделить возможности технологии от способности компании ими пользоваться.

О примерах. Все кейсы ниже взяты из практики. Я строю систему управленческих контуров и передаю её командам клиентов. Система охватывает продажи на двух маркетплейсах и работает с ассортиментом около 20 000 SKU.

В неё входят четыре контура: еженедельный классификатор товаров, модель скорости продаж, слой планирования продаж и рекламный классификатор с ИИ-наставником для менеджеров.

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

Пользоваться ИИ и внедрить его не одно и то же

Компания может активно пользоваться ИИ и при этом не иметь системы его применения.

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

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

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

Но если каждый сотрудник работает по собственной логике, это остаётся набором экспериментов.

У компании нет единого ответа на вопросы:

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

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

Из практики. Тест на пять секунд

Отличить одно от другого помогает простой вопрос. Что произойдёт, если сессия с моделью закончится прямо сейчас?

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

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

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

Реестр версий. Какой файл сейчас боевой, а какой историческая ветка.

Журнал релизов расчёта. Что изменилось, почему и на каких данных проверено.

Реестр методологических решений. Что решили, какие были варианты, почему выбрали этот.

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

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

Почему компании начинают с модели

Это естественно. Модель заметнее всего. Сервисы можно сравнить, ответы протестировать, скорость оценить, тариф выбрать. Результат виден сразу. Вчера инструмента не было, сегодня он есть.

Гораздо сложнее увидеть и организовать остальные элементы:

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

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

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

Этот контекст нужно спроектировать, подготовить и передать.

Из чего складываются остальные 90%

1. Правильно поставленная бизнес-задачаЗапрос «проанализируй продажи» слишком широк.

Что именно должен получить руководитель?

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

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

Например:

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

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

Но раньше этого задают другой вопрос. Способна ли система вообще решить такой запрос корректно.

Механизм. Сначала запрос классифицируют и только потом ставят как задачу

Проверка короткая и даёт один из трёх исходов.

Вариант 1. Методика есть, срез собран. Это разбор. Пересобрать готовое под нужный разрез, минуты работы.

Вариант 2. Методика есть, среза нет. Это сборка по описанным правилам. Дольше, но результат предсказуем, потому что правила уже утверждены.

Вариант 3. Методики нет. Это вообще не задача на расчёт. Это задача на проектирование методики, и решают её люди.

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

Мой практика. Пришёл запрос на прогноз остатков. Сколько и когда закупать.

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

Собирать нечего, пока не приняты четыре решения, которых нет ни в одних данных.

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

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

Оснований считать такой ответ верным для конкретной компании почти нет. Дело не в слабости модели. Перечисленные решения принимает сама компания, и в общем знании их нет и быть не может.

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

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

Ценность механизма именно в том, что он различает эти два случая до начала работы, а не после.

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

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

Модель в обоих случаях одна и та же.

2. Качественные данные.

ИИ не превращает плохие данные в достоверную аналитику. Перед работой нужно проверить:

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

Ошибка во входных данных быстро и убедительно расходится на весь анализ.

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

Механизм 1. Лист аудита данных, который собирают до анализа

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

Важная деталь методологии. Отсутствие данных это отдельное состояние, а не худшая оценка. Смешивать их нельзя.

Что это поймало. До введения правила пустая себестоимость приравнивалась к плохой марже. Товар без себестоимости получал худшую букву кода, попадал в отказ и выпадал из плана. В одной группе так выпала серия, дающая 67% объёма. План выставили в 8,6 раза ниже фактических продаж.

После исправления план совпал с фактом. Но главным результатом стала не эта группа, а сплошная проверка всей матрицы, которую я запустила следом. Вне корректного плана оказались 401 SKU и 35% объёма. В одной группе ошибка просто стала заметна.

Механизм 2. Еженедельная сверка «движение без плана» с указанием причины

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

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

Ни одна из этих проблем не видна в ответе модели. Все они видны в сверке, которая идёт до анализа.

Механизм 3. Приёмка чужой реализации по данным, а не по формулам

Когда модель переносят в другую систему, я проверяю не только логику, но и то, что под ней лежит.

Что это поймало. Аналитик клиента перенёс рекламный классификатор в BI-систему. Формулы двух осей перенесены безошибочно, 100% совпадение. При этом факт задвоился ровно вдвое примерно у 85% товаров, потому что соединение таблиц размножало строки. План подставлялся один и тот же на обе площадки. 1290 товаров вообще не имели плана, и у 38 из них крутилась реклама без всякого контроля.

Это самая точная иллюстрация формулы «модель даёт 10%», которая мне встречалась. Логика перенесена идеально. Пользоваться результатом нельзя.

3. Единая методология

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

Например, при падении продаж специалист проверит:

1. наличие товара;
2. изменение цены;
3. динамику трафика;
4. конверсию;
5. рекламную активность;
6. позиции и видимость;
7. отзывы и рейтинг;
8. действия конкурентов;
9. сезонность;
10. внутренние операционные события.

ИИ тоже нужна такая последовательность.

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

Методология определяет:

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

Но методология не только защищает от неверных расчётов. Она создаёт ландшафт, на котором работает аналитик.

Механизм. Аналитик не уходит из процесса, а меняет позицию

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

Эта роль сверяет не результат, а ход. Проверка идёт по трём уровням, и цена у них очень разная.

Уровень 1. Данные на входе. Всё ли на месте, сопоставимы ли периоды, из тех ли источников.

Уровень 2. Ход вычислений. От какой величины считали, от какого знаменателя брали доли, на каком множестве товаров, на каком слое воронки остановились. Этот уровень пропускают чаще всего. Результат уже получен, и проверять хочется его, а не дорогу к нему.

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

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

Вывод остановил один вопрос. «Подожди, ты уверен, что они остановлены? Если на складе ноль, реклама же не будет показываться. Или я не права?»

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

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

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

Действия по этим двум группам прямо противоположные.

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

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

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

Это тот сценарий, где ИИ силён и где его почти никто не использует. Не «напиши документ», а «проверь, что документ соответствует реальности».

В последней сверке из 45 проверяемых утверждений 42 совпали дословно, 2 разошлись, 1 описывал правку, которой в файле не было. Последний случай хуже всех остальных. Не потому, что документ ошибается, а потому что менеджер поверит документу.

Вывод. Самая дорогая ошибка анализа сидит не в формулах, а в непроверенной вводной. Расчёт про рекламу был технически корректен. Он просто стоял на предпосылке «остановлен значит не продаётся», которую никто не проверял.

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

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

Хороший контур не тот, где машина не ошибается. Хороший контур тот, где ошибка не доживает до решения.

4. Контекст бизнеса

Одно и то же изменение показателя значит для разных компаний разное.

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

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

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

ИИ не восстановит весь контекст по одним данным. Его нужно передавать явно:

цели компании;

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

Контекст бывает двух видов, и обращаться с ними надо по-разному.

Вид первый. Постоянные правила, которые нельзя вывести из данных

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

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

Вес выходных. Профиль спроса по дням неровный. Воскресенье около 1,17 среднего дня, суббота около 0,99, пятница около 0,885. Плоская дневная норма завышает выполнение на выходных. На практике старт нового плана пришёлся ровно на два выходных дня и показал 131% выполнения, а с поправкой на профиль около 122%. Разница в 9 пунктов на первом же замере отделяет «план занижен, срочно поднимаем» от «план в целом адекватен».

Гибридная неделя. Неделя на стыке месяцев покрывается планом только в своих календарных днях. Пять относятся к одному месяцу, два к следующему.

Такой контекст трудоёмкий, но безопасный. Записал, и он работает.

Вид второй. Состояние бизнеса, которое меняется по ходу. Вот он и опасен

Механизм. При повторном расчёте первым проверяют не число, а задачу.

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

Поэтому проверка встроена явно. Событие разовое или это серия? Горизонт прежний? Что теперь ресурс, а что риск?

Что это поймало. Сгорел склад.

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

Затем вмешался фактор, которого в постановке не было. Склады продолжали гореть. Событие оказалось не разовым сбоем, а серией.

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

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

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

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

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

5. Встроенность в рабочий процесс.

Даже качественная рекомендация не создаёт результат сама по себе.

Нужно определить:

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

Без этого ИИ выдаёт аналитику, которая бывает интересной, но не превращается в действие.

Механизм 1. Порядок операций закреплён регламентом, а не здравым смыслом

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

Механизм 2. Ответственного проставляет расчёт, а не подразумевает контекст

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

Что это поймало. Сначала роль определялась по действию, которое назначил классификатор. Но два особых случая переопределяют действие уже после этого, и строки «усилить до пересмотра плана» уходили менеджеру по рекламе. Хотя оба действия относятся к уровню плана, а план ведёт категорийный менеджер. ИИ-наставник честно копировал поле «ответственный» и складывал всё усиление не в ту зону. В расчёте это исправили, теперь ответственный меняется вместе с действием.

Механизм 3. Результат доставляют туда, где работает исполнитель

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

Здесь важна не технология, а то, что у ИИ-роли есть цель, база, ограничения, формат результата, критерий готовности и человек, отвечающий за качество.

6. Контроль качества

ИИ может ошибаться не только в фактах, но и в самой логике.

Например:

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

Поэтому результат должен быть проверяемым.

Хороший ответ ИИ показывает:

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

Механизм. В расчёт вшиты стражи, каждый защищает от своего класса ошибок

Ниже четыре из них и то, что каждый поймал.

Страж 1. Сравнение двух периодов проверяет, не менялся ли план между ними.

У трёх ключевых показателей общий плановый знаменатель. Пересмотр плана двигает все три одновременно, и портфель выглядит так, будто рынок разом улучшился по всем фронтам. На реальных данных плановые клики между срезами менялись примерно на 13%. Этого достаточно, чтобы «тройное улучшение» стало массовым.

Страж сравнивает плановые числа двух срезов с допуском 2% и дальше делает одно из двух. Либо приводит прошлый срез к текущему плану и возвращает строку в сравнение, либо честно помечает её как несравнимую. Формулировки в отчёте разные, и путать их нельзя. «Срезы приведены, сравнение корректно» и «план менялся, сравнение запрещено». Проверка идёт построчно, в одном срезе бывают оба типа.

Страж 2. Граница месяца.

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

Страж 3. Показатель и его норматив считают от одного знаменателя.

Фактическую стоимость привлечения считали от рекламных корзин, а норматив, с которым её сравнивали, строили от всех корзин. Знаменатели разные, значит индекс переплаты систематически завышен. Медианно примерно в 1,7 раза, в первом квартиле около 1,25.

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

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

Страж 4. Человек и машина смотрят на одно и то же число.

Строка отчёта печаталась при изменении показателя от 1 пункта, а в список «улучшения за неделю» товар попадал при изменении от 3 пунктов, но по неокруглённому значению. Весь диапазон от 2,5 до 2,999 давал прямое противоречие. Строка сообщала «+3 пункта», а в списке улучшений товара не было. Правило теперь одно. Округляем один раз, и порог проверяем по тому числу, которое видит человек.

Прогнали старую и новую версию бок о бок на 132 значениях. Противоречий было 12, стало 0.

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

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

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

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

Ответственность остаётся у человека, который:

• определяет цель;
• утверждает методику;
• предоставляет доступ к данным;
• проверяет вывод;
• оценивает риски;
• принимает решение;
• контролирует результат.

Это особенно важно при работе с ценами, рекламными бюджетами, поставками, ассортиментом и другими областями, где ошибка приводит к прямым финансовым потерям.

Механизм. Расчёт формулирует сигнал, а не приговор

Ниже четыре решения, которые он принять не может.

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

Краевой случай проверяют до того, как правило начнёт действовать. Механизм ротации выводил слабый товар, если находил кандидата на замену. В группе, целиком состоящей из новинок, кандидатов не было, и алгоритм выводил лидера, дающего 84% продаж своей группы. Правило дополнили. Нет кандидатов, значит «оставить», план строится по факту, товар помечается как лидер группы. Из-под вывода вышли 13 товаров на двух площадках.

Достроенные данные помечают прямым текстом. Часть планов расчёт восстанавливает, когда исходных данных нет. Формально по такому плану считается всё то же самое, и вывод выглядит одинаково убедительно. Поэтому появилась отдельная колонка «основание оценки» с формулировкой «план восстановлен, проверить перед решением». На одной из площадок такую пометку получили 123 строки из 183 восстановленных.

Проверка показала, зачем это нужно. У товаров с восстановленным планом статус «недобор трафика» встречался в 48,6% случаев против 30,3% у обычных. То есть рекламе выдавали команду по плану, которого фактически не существовало.

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

Это в чистом виде управленческое решение о допустимом риске. У модели нет оснований его принять. Нет ни данных о планах закупки, ни права рисковать.

Управленческая формула результата

Работу системы можно представить так. Результат от ИИ = модель × данные × методология × процесс × контроль × ответственность.

Важно, что здесь умножение, а не сложение. Если один из элементов близок к нулю, качество всей системы резко снижается.

Сильная модель, работающая с неполными данными, не создаст достоверный анализ.

Качественные данные без понятной бизнес-задачи дадут много наблюдений, но не управленческое решение.

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

Быстрый процесс без контроля позволит быстрее принимать неправильные решения.

Поэтому улучшать нужно не только модель, а весь рабочий контур.

Что следует из первой части

Доступ к модели это ещё не внедрение.

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

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

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

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