McKinsey учит сотрудников экономить ИИ-токены: как контролировать расходы без запретов

McKinsey учит сотрудников экономить ИИ-токены: как контролировать расходы без запретов

К маю McKinsey тратила около 5 трлн ИИ-токенов в месяц, а 65% расхода приходилось всего на 10% сотрудников. Компания отказалась от жёстких лимитов и собрала систему контроля: письма со статистикой, внутренний шлюз, предохранители и кэш. Разбираем, как это устроено и что применимо в вашей компании.

Что случилось в McKinsey: 5 трлн токенов и 10% сотрудников

К маю 2026 года McKinsey тратила около 5 трлн ИИ-токенов в месяц. На 10% сотрудников приходилось 65% этого объёма. Компания не стала отключать модели и не ввела жёсткие лимиты: она собрала систему контроля из четырёх частей. Самые активные пользователи получают письмо с персональной статистикой, запросы проходят через внутренний ИИ-шлюз, аномальные всплески расхода ловят автоматические предохранители, повторяющиеся ответы берутся из кэша.

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

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

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

Почему перерасход токенов стал проблемой именно сейчас

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

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

McKinsey не единственная компания с такой проблемой, но одна из немногих, кто показал устройство решения. Похожий случай публично описал разработчик HR-софта Rippling: там сотрудники тратили на ИИ сумму, равную 40% бюджета на зарплаты отдела разработки, а один инженер сжигал $50 000 в месяц. Разбор этого кейса и инструмента AI Spend Console есть в отдельном материале.

Система контроля расходов на ИИ в McKinsey: четыре ключевых элемента

Каждый элемент закрывает свой сценарий. Уведомления работают с поведением людей, шлюз снижает цену запроса, предохранители ловят аварийные всплески, кэш убирает повторную работу.

Как работает система уведомлений и почему она эффективнее запретов

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

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

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

Внутренний ИИ-шлюз: что это и как он экономит токены

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

Для сотрудника разницы почти нет: он задаёт вопрос в привычном окне и получает ответ. Экономия накапливается на стороне инфраструктуры, а не за счёт качества ответа на типовых задачах.

Автоматические предохранители и кэширование: защита от аномалий

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

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

Подход Дебасиша Патнайка: оценивать токены по результату, а не по сотруднику

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

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

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

Как компаниям выстроить контроль расходов на ИИ: пошаговый план

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

  1. Проведите аудит: какие ИИ-инструменты используются, сколько токенов уходит, на какие задачи и кто лидирует по расходу.
  2. Определите метрики. Считайте стоимость на успешную задачу, а не токены на сотрудника.
  3. Настройте уведомления для самых активных пользователей. Сначала только информирование, без отключений.
  4. Подключите внутренний шлюз: он отфильтрует дубли и направит простые запросы на дешёвые модели.
  5. Добавьте предохранители и кэш. Первые защитят от аварийных всплесков, второй снимет повторную генерацию.
  6. Обучите сотрудников формулировать запросы точнее.
  7. Пересматривайте политику раз в квартал: модели дешевеют, сценарии меняются.

С чего начать: аудит и пилот на одном отделе

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

Пример: если в отделе маркетинга из 40 человек восемь сотрудников выбирают 80% токенов, начинать стоит с них. Так пилот даёт быстрый эффект и не требует перестраивать работу всего офиса.

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

Обучение сотрудников: как объяснить экономию токенов без давления

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

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

Технические способы снизить расход ИИ-токенов

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

Слой обработки данных и вычислений: как отсеять лишнее до запроса к модели

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

В описаниях подобной архитектуры приводят пример: на входе 100 ГБ информации, а для ответа нужна малая часть. Система сначала находит релевантное, сжимает и передаёт модели только необходимое. Значительная доля данных оказывается либо нерелевантной задаче, либо пригодной для обычных вычислений, либо извлекаемой из структурированной базы. Каждую такую категорию можно отсеять до платного вызова.

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

Маршрутизация моделей: когда маленькая модель справится лучше

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

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

Метрики эффективности: как измерять успех контроля расходов на ИИ

Метрика «токены на сотрудника» годится только для поиска аномалий. Она не отличает дорогую и полезную работу от дорогой и бесполезной. Более честные показатели:

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

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

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

Что это значит для вашей компании: выводы и рекомендации

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

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

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

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

Отправить тому, кому пригодится

Ссылка сохранит весь материал без сокращений.

По почте

Заметили неточность? Сообщить редакции