Когда CTO должен сказать нет AI-идеям

Почему некоторые AI-идеи отнимают больше времени, чем экономят

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

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

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

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

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

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

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

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

Команды стартапов чувствуют это особенно быстро. Представьте, что в поддержку приходит 20 тикетов в день, а AI-черновик экономит 30 секунд на каждом, но при этом руководителю команды приходится тратить 15 лишних минут на проверку рискованных ответов. Формула перестает сходиться. Инструмент сделал что-то полезное, но рабочий процесс в целом стал хуже.

Большинство плохих AI-проектов — это не катастрофы. Это более медленные и более запутанные версии работы, которую команда и так выполняла достаточно хорошо. Хороший CTO замечает это заранее и идет дальше.

Сначала смотрите на объем очереди

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

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

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

Здесь помогает грубое правило. Если задача появляется только несколько раз в месяц — делайте ее вручную. Если она возникает десятки раз в неделю — начинайте измерять. Если она попадает в очередь сотни раз, ее уже стоит изучить внимательнее.

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

Это хорошо видно в небольших софтверных командах. Основатель может попросить AI помочь с редким письмом инвесторам. Звучит стратегически, но очередь слишком маленькая. А та же команда может каждую неделю обрабатывать 300 похожих обращений в поддержку по логину, оплате или настройке аккаунта. Такая очередь создает реальную нагрузку. Даже скромная автоматизация может сэкономить часы и сократить задержки.

То же самое видно и в lean AI-операциях: берите работу, которая повторяется. Повторяемость дает сигнал. Редкие задачи дают шум.

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

Проверьте реальную стоимость проверки

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

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

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

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

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

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

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

Сначала честно оцените, насколько понятны правила

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

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

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

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

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

Возможно, задача подойдет для AI позже, но не сейчас.

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

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

Используйте простой фильтр перед каждым пилотом

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

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

Оценку держите простой. Не нужен spreadsheet с двадцатью колонками. Часто достаточно ответа «да/нет» на каждый вопрос. Три «да» — запускайте маленький тест. Два — подождите и соберите больше данных. Одно — откажитесь.

Если случай не такой очевидный, используйте низкий, средний и высокий уровень. Очередь для triage в поддержке может получить высокий балл по объему, средний по стоимости проверки и высокий по ясности правил. Обычно этого уже достаточно, чтобы оправдать пилот. Ассистент для основателя по входящим письмам может получить средний, высокий и низкий. Низкий балл по правилам — это и есть сигнал тревоги.

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

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

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

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

CTO поставил идею на паузу и сначала проверил цифры.

В обычный день во входящий ящик приходило около 35–50 новых сообщений. Звучит много, но это не огромная очередь. Человек мог просмотреть и пометить большую часть писем меньше чем за 30 секунд. Даже если бы AI идеально выполнял половину этой работы, команда экономила бы только небольшой кусок времени в день.

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

Главной проблемой была ясность правил. Многие письма не помещались в одну чистую категорию. Клиент мог написать: «С меня списали деньги дважды, и экспорт у команды все еще не работает». Это вопрос по оплате, баг-репорт или срочная проблема с аккаунтом? На самом деле — все сразу. Были и сложные случаи: злые клиенты, юридические угрозы, запутанные скриншоты. Как только начали писать реальные люди, четкие правила развалились.

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

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

Именно в этом часто и разница между хорошим AI-проектом и шумным. Большая идея звучит лучше. Меньшая — действительно помогает.

Ошибки, которые затягивают команды в слабые AI-проекты

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

Такой порядок создает проблемы. «Использовать AI для ответов клиентам» — это не задача. «Готовить черновики ответов на возврат для заказов по фиксированной политике» — это задача. Если никто не может назвать точный вход, выход и проверяющего, пилот начнет расплываться.

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

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

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

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

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

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

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

Такая дисциплина экономит больше времени, чем еще один круг правок промптов.

Короткий чеклист перед тем, как одобрить тест

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

Используйте этот фильтр и останавливайтесь на первом «нет»:

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

Частота важнее, чем кажется. Задача, которая появляется шесть раз в неделю, может раздражать, но обычно она не дает достаточного объема, чтобы окупить настройку, промпты, проверки и последующие действия. А очередь из 150 похожих задач в неделю — это уже другое дело. Там достаточно повторяемости, чтобы быстро учиться и понять, меняет ли тест хоть что-то.

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

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

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

Задайте планку до старта пилота. Например, команда хочет сократить время проверки на 30 процентов, убрать бэклог до пятницы или сэкономить пять часов в неделю. Хорошая проверка AI-идеи должна казаться немного скучной. Простые цифры всегда лучше восторга.

Что делать дальше

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

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

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

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

Иногда команде нужен взгляд со стороны, потому что внутренний энтузиазм может исказить математику. Олег Сотников из oleg.is помогает стартапам и небольшим компаниям проверять AI-идеи на прочность, особенно когда нужен практичный взгляд CTO на то, где автоматизация уместна, а где нет. Короткий разбор может сэкономить недели работы над неправильной задачей.

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