Как провести пилот ИИ за 30 дней с карточкой инициативы и честно принять или закрыть результат

Зачем этот урок

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

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

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

Карточка, через которую проходит любая инициатива

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

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

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

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

Одна метрика и две ведущие

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

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

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

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

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

Четыре вопроса, которые решают до старта

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

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

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

Красные линии и журнал: два решения, которые ничего не стоят

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

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

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

Тихий саботаж

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

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

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

Считать надо владение, а не запуск

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

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

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

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

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

Арифметика правила сходится на его же условном примере. При стоимости 1000 и эффекте 2000 после такой правки получается 2000 против 1000, то есть убыток, и практик в этом случае не начинал бы. При стоимости 1000 и эффекте 10 000 выходит 2000 против 5000, то есть решение переживает перерасход. Разница между проектами обнаруживается не в аккуратности расчёта, а в запасе прочности.

Для владельца это смена вопроса: не «сходится ли бизнес-план», а «выживает ли он после удвоения сметы».

ИИ остаётся инструментом

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

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

«Зелёное» не значит «проверено»

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

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

Поэтому «готово» подтверждается двумя признаками сразу: команда завершилась без ошибки и сама сообщила о результате — например, «0 failed», файл создан. Отсутствие падения доказательством не является.

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

Всё это переносится в приёмку ИИ-работы дословно: спрашивать надо не «прошло ли», а «что именно проверено и сколько объектов попало в проверку».

Четыре стадии внедрения

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

Стоп-условия для старта: низкая зрелость данных, отсутствие кодифицированных процессов, нулевая ИИ-грамотность команды. Без успешного пилота масштабирование преждевременно; если данные не машиночитаемы или процессы держатся на договорённостях, сначала готовят среду.

Шкала зрелости организации

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

Когда процесс подходит под always-on агента

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

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

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