Передача ИИ‑проекта: когда внешний CTO должен взять управление на себя

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

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

Это кажется быстрым. И это же создаёт хаос.

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

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

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

В этот момент пилот уже не маленький эксперимент. Это полу-внедрённый рабочий процесс с реальными расходами и реальным риском.

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

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

Что должен взять на себя один ответственный руководитель

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

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

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

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

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

Короткой еженедельной заметки достаточно, если она простая:

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

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

Когда внешний CTO должен взять лидерство

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

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

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

Передачу стоит делать уже сейчас, если верно хотя бы одно из условий:

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

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

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

Короткое окно для решения помогает. Дайте команде 30 дней на настройку и 45 дней на проверку. В конце один человек решает, продолжать, менять масштаб или остановить. Такой дедлайн не даёт маленькому эксперименту превратиться в дорогую привычку.

Соберите оценочную карту до запуска

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

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

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

Нужна и база для сравнения. Измерьте текущий ручной процесс до начала пилота. Если сотрудник поддержки отвечает на 40 тикетов в день с 3% ошибок, это ваша стартовая точка. Если ИИ‑инструмент ускоряет ответы, но удваивает количество переделок, значит работу он не улучшил. Без базового уровня команды могут заявлять о прогрессе там, где ничего не стало лучше.

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

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

Именно здесь помогает внешний проверяющий. Человек со стороны, не вовлечённый в ежедневный азарт, может составить оценочную карту до того, как мнения застынут. Oleg Sotnikov через oleg.is часто работает со стартапами и небольшими бизнесами в роли частичного CTO: сначала определяет цифры, а потом даёт пилоту доказать себя. Звучит просто, потому что так и есть. И это экономит месяцы блужданий и много лишних расходов.

Задайте бюджетные лимиты и правила остановки

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

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

Зафиксируйте лимиты согласования в письменном виде

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

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

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

Запишите и реакцию на сбой. Если инструмент перестанет работать в 11 утра в рабочий день, кто получит уведомление, кто решит, выключать ли его, и какой ручной процесс подхватит работу? Хороший план отката не должен быть драматичным. Это может быть так же просто, как выключить функцию, вернуть работу в старую очередь и заносить каждый сбой в журнал для проверки.

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

Напишите план отката, которому люди действительно последуют

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

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

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

Перед тем как кто-то меняет настройки, сохраните то, что может понадобиться для восстановления:

• свежий экспорт затронутых данных
• текущие настройки поставщика и выбранные модели
• используемые версии промптов и файлы шаблонов
• роли аккаунтов, API‑ключи и заметки по доступу

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

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

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

Как передавать проект шаг за шагом

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

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

Используйте паузу, чтобы сделать четыре вещи по порядку:

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

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

Простой пример из небольшой компании

Компания B2B из 30 человек хотела ускорить исходящие продажи, поэтому маркетинг начал использовать ИИ для черновиков первых писем. На первых порах результат выглядел отлично. Менеджеры могли за час сделать черновики на весь день, а маркетингу нравилось, как быстро можно тестировать новые подходы.

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

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

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

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

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

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

Ошибки, из-за которых пилот превращается в хаос

Большинство ИИ‑пилотов сбиваются с курса по скучным причинам. Модель может работать нормально, но команда ставит ей расплывчатые цели, неаккуратные расходы и не даёт правила, кто может расширять пилот.

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

Использование — ещё одна ловушка. Люди говорят: «Его попробовали 200 сотрудников», будто это доказывает, что пилот сработал. Это не так. Высокое использование может скрывать низкий эффект, плохой результат или дополнительную ручную проверку. Если сотрудники тратят 30 минут на исправление слабых ИИ‑черновиков, инструмент не экономит время. Он просто перекладывает работу на другое место.

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

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

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

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

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

Быстрые проверки перед расширением

Финальный тест простой: компания контролирует пилот или пилот контролирует компанию?

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

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

Если нужна внешняя помощь, Oleg Sotnikov на oleg.is делает такой обзор для стартапов и небольших бизнесов в роли частичного CTO и советника. Короткая рабочая сессия по ответственности, лимитам бюджета и правилам отката часто обходится дешевле, чем месяц незаметных ИИ‑расходов или один сломанный рабочий процесс.

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