Бизнес-кейс внедрения ИИ: почему финансам стоит подключаться раньше

Почему команды не видят реальную стоимость

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

Цена модели — это только одна строка в бизнес-кейсе. Людям всё равно нужно читать ответы, исправлять плохие результаты, разбирать сложные случаи и отвечать клиентам, если что-то идёт не так. Если человеческая проверка нужна в 40% случаев, затраты на труд очень быстро могут обогнать расходы на модель.

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

Ошибки добавляют ещё один слой. Один неправильный ответ редко остаётся изолированным. Он может вызвать возвраты, дополнительные обращения в поддержку, доработку со стороны operations или engineering и ручную переписку с клиентом. Такой цепной реакции легко не заметить, потому что ни один отдел не владеет ею целиком. Product видит функцию, support видит жалобу, finance видит возврат, а общую стоимость никто не собирает вместе.

Именно поэтому finance должен подключаться раньше. Finance задаёт более жёсткие вопросы. Какая доля результатов потребует проверки? Какую частоту ошибок бизнес вообще может себе позволить? Что будет с маржой, если в следующем квартале объём удвоится? Эти вопросы выводят команду за пределы оптимистичных допущений.

Это ещё и причина, почему опытные технические консультанты обычно фокусируются на архитектуре и операционных расходах, а не только на выборе модели. Oleg Sotnikov, например, часто рассматривает AI-проекты через общую стоимость процесса, а не только через цену API. Дешёвый ИИ — это не то же самое, что доступный ИИ.

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

Цифры, которые определяют бизнес-кейс

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

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

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

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

Объём одновременно меняет все три цифры. Больше запросов — больше счёт за API, больше времени на проверку и больше шансов на ошибки. Это кажется очевидным, но многие команды всё равно тестируют 200 задач и предполагают, что та же экономика сохранится и на 20 000.

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

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

Как оценить расходы на модель

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

Не начинайте с догадки о месячном бюджете. Начните с объёма задач. Посчитайте, сколько раз каждый процесс будет вызывать модель за обычную неделю. У команды поддержки, которая готовит 2 000 ответов в неделю, совсем другая структура затрат, чем у sales-команды, которая пишет 80 follow-up-писем.

Затем измерьте четыре входных параметра для каждой задачи:

• количество запросов в неделю
• средний размер промпта
• средний размер ответа
• процент повторов

Процент повторов легко пропустить. Люди запускают запрос заново, когда ответ слабый, слишком длинный, заблокирован или не в том формате. Даже 10–20% повторов могут изменить расходы сильнее, чем ожидает большинство команд.

Для начала достаточно грубой оценки. Если одна задача запускается 2 000 раз в неделю, использует 1 200 входных токенов и 400 выходных токенов, а повторяется в 15% случаев, то общий объём за неделю составит примерно 3,68 миллиона токенов. Эта цифра гораздо полезнее, чем фраза «мы будем много использовать ИИ».

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

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

Аккуратная оценка обычно включает три блока:

• тестирование и настройка
• обычное боевое использование
• пиковое боевое использование

Так finance получает диапазон, а не догадку. И у команды появляется способ сравнивать модели до того, как она сделает выбор.

Как оценить затраты на проверку

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

Начните с карты всех ролей, которые касаются результата. Не останавливайтесь на первом проверяющем. Многие команды считают только агента или аналитика, а потом забывают о team lead, compliance-проверке или согласовании менеджера, которое появляется, когда случай выглядит рискованным. На практике путь проверки часто включает первичного проверяющего, специалиста, который исправляет неясный результат, менеджера, который утверждает чувствительные случаи, и иногда legal или compliance для регулируемых задач.

Используйте реальные замеры, а не предположения с планёрки. Возьмите 20–50 недавних задач, прогоните AI-версию процесса и засеките время. Учитывайте чтение, проверку источников, редактирование и фиксацию результата. Маленькие ошибки во времени имеют значение. Если вы предполагаете 45 секунд, а реальное среднее — 2 минуты, математика уже неверна до старта проекта.

Полезно разделять проверку на два блока. Быстрое одобрение стоит дёшево. Полная переработка — нет. Если 80% результатов требуют 20-секундной проверки, а 20% — 6-минутной переделки, используйте оба числа. Одно среднее значение скрывает ту часть, которая съедает бюджет.

Считайте полную стоимость труда, а не только базовую зарплату. Если проверяющий обходится компании в $45 в час, то двухминутная проверка стоит примерно $1,50. Если менеджер добавляет ещё минуту в 10% случаев, это добавляет около 7,5 цента на задачу при той же почасовой ставке. На масштабе такие мелочи очень важны.

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

Как посчитать стоимость ошибок

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

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

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

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

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

Обычно помогает простая формула:

стоимость ошибки = возвраты или кредиты + труд на доработку + обработка в support + ручные исправления

Допустим, AI-процесс обрабатывает входящие счета. Небольшая ошибка занимает 5 минут у офисного сотрудника. При $24 в час это около $2. Серьёзная ошибка может потребовать 20 минут у сотрудника и 10 минут у finance, и тогда стоимость может оказаться в районе $14–$18. Дорогая ошибка может привести к двойной оплате или спору с поставщиком, и тогда сумма легко подскакивает до $150 или выше.

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

Если вы знаете частоту ошибок, умножьте её на объём. Даже 1% отказов на 50 000 задач быстро превращается в заметную сумму, если каждая серьёзная ошибка стоит реального времени сотрудников. Вот ещё одна причина, почему finance так важен в AI-проектах: finance уже знает, где мелкие промахи превращаются в реальные расходы.

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

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

Такая схема кажется дешёвой, пока не посчитаешь все три вида затрат вместе.

Простая недельная математика

Предположим, что команда платит агентам с полной стоимостью занятости $28 в час. До внедрения ИИ агент писал каждый ответ примерно за 2,5 минуты, так что 1 000 ответов занимали около 41,7 часа. Это примерно $1 168 в неделю на труд.

С ИИ работа не исчезает, а меняется. В одну реалистичную неделю:

• 820 ответов выглядят хорошо, и агент утверждает их за 40 секунд
• 140 ответов нужно переписать, и на каждый уходит по 3 минуты
• 40 ответов рискованные или неясные, поэтому агент эскалирует их и тратит по 10 минут на каждый
• расходы на модель за черновики и несколько проверок добавляют ещё $18 за неделю

Такая проверка занимает около 22,8 часа. При ставке $28 в час это примерно $638. Если добавить $18 на модель, AI-процесс обойдётся примерно в $656 за неделю.

На бумаге команда экономит около $512 в неделю по сравнению с ручной работой. Это выглядит хорошо. Но finance должен задать ещё один вопрос: как часто система создаёт дорогую ошибку?

Где экономия исчезает

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

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

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

Типичные ошибки прогнозирования

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

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

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

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

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

Где прогнозы обычно ломаются

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

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

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

Проверки перед утверждением

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

Сначала зафиксируйте текущую стоимость одной задачи. Не берите месячный бюджет команды и не делите его на догадку. Возьмите одну реальную задачу, посчитайте минуты, включите расходы на ПО и поставщиков и отталкивайтесь от этого. Если агент поддержки обрабатывает тикет за 6 минут при полной стоимости занятости $30 в час, такая задача стоит примерно $3 ещё до появления ИИ.

Потом измерьте работу по проверке. Кто-то будет смотреть результат, и это время не бесплатное. Назовите проверяющего, измерьте, сколько времени он тратит, и отметьте, когда подключаются senior-сотрудники. Пять минут проверки со стороны team lead очень быстро могут обнулить экономию от дешёвой модели.

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

И последнее: finance и operations должны использовать одни и те же допущения. Команды часто строят модель на разных числах по объёму, доле проверок или стоимости часа. Operations может считать, что проверяется 20% результатов. Finance может заложить 100% проверки в первый квартал. И то и другое звучит разумно, но даёт совсем разные итоги.

Чаще всего достаточно одной страницы проверки:

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

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

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

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

Подключите finance с первого дня. Один человек из product или operations должен вести пилот, а один человек из finance — проверять цифры вместе с ним. Так тест будет опираться на реальные затраты, а не на предположения.

Проведите короткий пилот на две или три недели и каждый день фиксируйте одни и те же показатели:

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

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

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

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

Если запуск затрагивает product, инфраструктуру и finance одновременно, сторонняя помощь может ускорить решение. Oleg Sotnikov из oleg.is работает с компаниями над AI-first development, lean infrastructure и поддержкой Fractional CTO, так что такой разбор затрат естественно вписывается в пилот до более широкого запуска.