Скрытая цена работы с ИИ: проверки съедают экономию

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

Команды обычно сначала считают то, что видно. Они замечают больше черновиков, больше ответов и больше тикетов, обработанных за день. Но они упускают человеческое время, которое спрятано вокруг каждого результата ИИ. Ответ, который создается за 20 секунд, все равно может потребовать 3 или 4 минуты на чтение, сравнение, исправление и одобрение.

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

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

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

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

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

Какие расходы команды обычно упускают

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

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

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

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

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

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

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

Как измерить один процесс

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

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

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

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

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

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

Небольшой пример из поддержки делает это особенно заметным. Допустим, стоимость модели — 3 цента за ответ. Это кажется дешево. Но если 40 процентов ответов требуют правок, проверяющие тратят 4 минуты на каждый элемент, а 10 процентов нуждаются во втором проходе, затраты на труд быстро съедают всю экономию.

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

Пример из службы поддержки

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

Первые 140 обращений простые. Сбросы пароля, вопросы о статусе заказа и базовые инструкции требуют только быстрого просмотра. Если проверяющий тратит примерно 35 секунд на каждое, это занимает около 82 минут.

Следующие 40 уже не такие чистые. Черновик ИИ близок к нужному, но что-то не так. Неправильна дата, пропущена деталь политики или клиент расстроен и нуждается в более мягком ответе. По 2 минуты на каждое — это еще 80 минут.

Затем идут 20 случаев с возвратом денег или спором. Они редко остаются в основной очереди. Проверяющий выносит их в сторону, делает пометку, проверяет счет, обращается в финансы или к менеджеру и возвращает их позже. Когда задача снова попадает обратно, проверяющий перечитывает всю переписку, потому что контекст уже потерян. По 4 минуты на каждый случай — еще 80 минут.

Итого команда тратит примерно 4 часа только на проверку и очистку результатов ИИ.

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

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

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

Почему устройство очереди меняет счет

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

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

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

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

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

Несколько правил помогают держать это под контролем:

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

Владение задачами важнее, чем думают многие команды. Когда элемент лежит часами, люди предполагают, что его возьмет кто-то другой. Затем один и тот же случай открывают, закрывают и снова открывают три разных человека.

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

Такой операционный дизайн важен не меньше, чем сам промпт. Если команде нужен второй взгляд на этот процесс, Oleg Sotnikov в oleg.is работает с AI-first операциями и задачами Fractional CTO, например с устройством очередей, передачей задач и стоимостью рабочих процессов.

Почему разбор исключений растет быстрее, чем ожидают команды

Большинство команд воспринимают исключения как погрешность округления. Они предполагают, что ИИ выполнит 95 процентов работы, а последние 5 процентов останутся небольшими. Такая математика ломается быстро.

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

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

Первый черновик может стоить копейки. А вот разбор исключений стоит зарплатных часов.

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

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

Ранние признаки обычно такие:

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

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

Ошибки, которые превращают дешевую автоматизацию в дорогую работу

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

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

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

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

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

Более разумный подход прост:

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

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

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

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

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

Перед увеличением объема спросите себя:

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

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

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

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

Что делать дальше вашей команде

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

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

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

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

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

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

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

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

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