Вопросы совета об ИИ, которые идут дальше сокращения штата

Почему первый вопрос про штат — не тот

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

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

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

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

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

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

Что показывает нагрузка на проверку

Нагрузка на проверку показывает, убирает ли ИИ работу или просто переносит её.

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

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

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

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

Короткая карточка показателей обычно сразу показывает проблему:

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

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

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

Как читать долю исключений

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

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

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

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

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

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

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

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

Где проявляются утечки данных

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

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

Спросите про промпты, логи и передачи

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

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

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

Ограничения нужно закреплять письменно

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

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

Как ИИ влияет на маржу, а не только на фонд оплаты труда

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

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

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

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

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

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

Простой обзор для совета директоров в шесть шагов

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

Используйте шесть шагов:

1. Начните с базы. Узнайте, как процесс выглядел до ИИ: стоимость одной задачи, время выполнения, доля ошибок и влияние на валовую маржу.
2. Посчитайте новые затраты. Включите плату за модель, софт, услуги поставщика и время сотрудников, которое нужно, чтобы настроить систему и поддерживать её работу.
3. Измерьте человеческую проверку. Если люди всё ещё проверяют большую часть результатов, инструмент может помогать с черновиками, но не с готовой работой.
4. Проверьте долю исключений до того, как одобрять более широкое внедрение. Посчитайте, как часто система даёт сбой, требует доработки или возвращает задачу человеку.
5. Проверьте утечки данных простыми словами. Какие данные попадают в модель, где хранятся логи, кто может видеть промпты и результаты и попадают ли в процесс данные клиентов, финансовые данные или данные сотрудников.
6. Задайте правило остановки и дату повторной проверки. Если стоимость одной задачи растёт, маржа падает или риск увеличивается, поставьте запуск на паузу и ещё раз посмотрите те же цифры через 30–60 дней.

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

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

Пример команды поддержки

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

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

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

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

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

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

Ошибки, которые совершают советы директоров при оценке ИИ

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

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

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

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

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

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

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

Что проверить, прежде чем одобрять новый бюджет

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

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

Короткий чек-лист помогает сохранить честный разговор:

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

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

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

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

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

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

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

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

Здесь важен масштаб. Пилот, который работает на 200 случаях, может провалиться на 2 000. Советы директоров должны попросить команду доказать стабильную работу в течение нескольких отчётных циклов, прежде чем одобрять более широкое внедрение или больший бюджет.

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

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

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