«Прикладной ИИ не работает»: полный перевод статьи Vas

Я нахожу в X действительно важные статьи и хочу сохранять их здесь, чтобы к ним можно было вернуться и прочитать по-русски.

Автор этой статьи — Vas (@vasuman), руководитель Varick, компании по внедрению ИИ в крупном бизнесе. В своём профиле он также указывает, что раньше работал над ИИ в Meta.

Ниже я сохраняю его материал полностью в русском переводе, с оригинальными иллюстрациями. Все примеры, оценки, резкие формулировки и заявления о результатах принадлежат автору. «Я» и «мы» в переводе относятся к Vas и его команде.

Оригинал: Applied AI Doesn’t Work, 4 сентября 2026 года.

Прикладной ИИ не работает

Мир потратил на ИИ целое состояние. Для большинства компаний ничего не изменилось. Я поговорил более чем с 300 генеральными, ИТ- и финансовыми директорами крупнейших компаний планеты. И понял: большинство компаний накладывают ИИ на свои паршивые процессы, а в результате просто производят ту же дрянь быстрее. Покупают тысячи лицензий Claude Code, берут на себя обязательства тратить по 50 миллионов долларов в год на токены или проводят обучение работе с ИИ в Zoom — я своими глазами видел, насколько неэффективным оказалось внедрение. Но так быть не должно.

Мы уже проходили этот путь, причём неоднократно. И при внедрении ИИ стоит учиться на истории. Надеюсь, дочитав эту статью, руководители ИИ-направлений по всему миру откажутся от архаичного и наивного подхода к «применению ИИ» и начнут следовать проверенному процессу, который я описываю ниже.

Часть 1. История и её параллели

В 1990 году Майкл Хаммер, бывший профессор информатики MIT, написал статью для Harvard Business Review. К тому времени он уже несколько лет изучал компании, которые тратили огромные деньги на компьютеры, почти не получая отдачи от вложений. Он одним из первых разобрался в причинах.

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

Это настоящая цитата. Вы серьёзно? Замените «информационные технологии» на «ИИ», и такой текст можно хоть завтра публиковать на первой странице Business Insider. В той же статье он писал, что пора перестать асфальтировать коровьи тропы. Прошло 36 лет. Угадайте, чем мы всё ещё занимаемся?

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

Тем временем капитальные затраты на создание ИИ-инфраструктуры превысили триллион долларов. Одни Microsoft, Alphabet, Amazon и Meta потратили в 2025 году 410 миллиардов — знаю, от таких цифр глаза на лоб лезут. При этом предприятия потратили на собственно использование ИИ лишь 37 миллиардов долларов. Вот как это выглядит на практике: Министерство бизнеса и торговли Великобритании провело испытание Microsoft 365 Copilot и опубликовало результаты. На три месяца выдали тысячу лицензий, но в среднем на пользователя приходилось всего 1,14 действия в Copilot в день. Слайды PowerPoint делали на семь минут быстрее: за 11 минут вместо 18. Однако оценка качества оказалась вдвое ниже. Анализ в Excel выполняли даже медленнее — и тоже с худшим качеством. Экономия времени на электронной почте была, цитирую, «крайне незначительной». Их собственный дословный вывод: «Мы не обнаружили убедительных доказательств того, что экономия времени приводит к повышению производительности». И всё же 72% пользователей заявили, что довольны или очень довольны.

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

Немного контекста: я Vas, генеральный директор @varickagents. Мы работаем с очень крупными компаниями — с выручкой от 500 миллионов до 100 миллиардов долларов и штатом от тысячи до ста тысяч человек. Помогаем им внедрять ИИ: от общей стратегии и перепроектирования процессов до разработки, внедрения и сопровождения агентов. Эта статья основана на наших выводах о том, что отличает неудачные ИИ-пилоты, не дающие измеримой отдачи, от успешных, где агент полностью выполняет более 80% работы, экономя время и деньги.

Причина повторения этой истории не сводится к глупости. Хотя и она, конечно, присутствует. Но главным образом дело в инерции и устройстве организации. Человек, который сегодня подписывает контракт на ИИ, может отвечать за инструменты и выбор поставщика, но за сам процесс он точно не отвечает. Ни у кого в этой цепочке нет полномочий прийти, например, в финансовый отдел и сказать, что их процесс из 14 шагов на самом деле должен состоять из пяти. Поэтому никто этого и не делает. Вместо этого вы «применяете ИИ» к тому, что уже есть, и получаете ускоренное дерьмо.

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

Вернёмся к Хаммеру. Самый показательный пример у него — страховая компания, которую он изучал. Заявка проходила через компанию за 22 дня. Из этих 22 дней суммарное время, в течение которого кто-либо действительно работал над заявкой, составляло 17 минут. Допустим, сегодня ваш специалист по ИИ внедряет в этот процесс лучшую модель в мире, и каждый отдельный шаг выполняется вдвое быстрее. Он сэкономил восемь с половиной минут. Он записывает себе 50% экономии времени, получает повышение и премию и уезжает в закат. Восемь минут.

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

Когда я говорю, что большинство ИИ-программ ускоряют дерьмо, я имею в виду это буквально. Процесс — дерьмо. ИИ его ускоряет. Мне отвечают: «Ну, мы огромная компания, значит, явно что-то делаем правильно и нам не нужно меняться». Принцип «адаптируйся или умри» сегодня актуален как никогда. И вот здесь ИИ отличается от цифровых и облачных технологий. При правильном использовании он даёт конкуренту такое преимущество над вами, которого те не давали. Конкурент сможет перебить вас по издержкам, масштабироваться без ограничений, не наращивая штат обработки операций, или связаться со всем миром раньше, чем вы составите список потенциальных клиентов. Он вас раздавит. В лучшем случае вы продолжите расти, но ваш штат начнёт увеличиваться экспоненциально. Три аналитика превращаются в шесть, но этим шестерым уже нужен руководитель. Поскольку теперь это две команды, им нужна передача работы, которой раньше не было. Для неё нужны статусная встреча и менеджер проекта, и так далее. Поэтому графики численности загибаются вверх, а выручка на сотрудника — нет. Адаптируйтесь или умрите, но не делайте вид, что ИИ не существует. Ваши конкуренты не остановятся ни перед чем, чтобы с этим разобраться.

Часть 2. Что делать сегодня

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

TSB потратил 318 миллионов фунтов на миграцию основной банковской системы, понёс ещё примерно 200 миллионов расходов из-за инцидентов, в декабре 2022 года получил штраф в 48,65 миллиона фунтов от FCA и PRA и нарушил работу банковских сервисов для 5,2 миллиона клиентов. Zimmer Biomet, производитель с выручкой 8 миллиардов долларов, в сентябре 2025 года предъявил Deloitte требование на 172 миллиона долларов: неудачная «миграция и консолидация» лишила компанию возможности выполнять базовые функции — отгружать продукцию, выставлять счета клиентам и получать пригодную к работе отчётность по продажам. Это лишь два примера, попавших в новости. Подобные инциденты встречаются гораздо чаще, чем вы, возможно, думаете.

Сначала стоит привести к единому виду процесс. Допустим, за последние 20 лет вы купили девять компаний. Теперь один и тот же процесс выполняется девятью способами в девяти дочерних структурах. Чтобы «применить» ИИ во всей компании, вам придётся построить девять разных версий одного агента, а затем вечно поддерживать все девять наборов агентов. Чтобы избежать этого чистилища, сначала нужно определить единый процесс для всей группы и внедрить его во всех структурах. И лишь потом думать об ИИ поверх него.

При этом единая ERP вам НЕ ОБЯЗАТЕЛЬНА. Детерминированные интеграции раньше ломались, как только две системы расходились в том, что считать записью о поставщике. Агенты способны работать с такими несоответствиями. Поэтому слой оркестрации поверх уже имеющихся систем и ЕСТЬ решение проблемы их разрозненности. Вашим системам мало просто общаться: им нужно жить в счастливом браке, терпимо относясь к недостаткам друг друга.

Начните с карты процессов

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

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

1. Штатный сценарий, или happy path. За что отвечает процесс и что происходит в идеальных условиях. В большинстве компаний только эта часть и задокументирована действительно подробно.
2. Исключения. Именно на них уходит большая часть времени. Не ограничивайтесь описанием происходящего. Посчитайте, какая доля операций отклоняется от штатного сценария, куда они попадают, кого приходится подключать, сколько времени занимает обработка таких случаев и какова цена ошибки.
3. Что находится выше и ниже по цепочке. Как этот процесс взаимодействует с соседними, когда на какой-либо стороне возникают задержки или ошибки?
4. Все задействованные учётные системы. Какой источник считается главным, если две системы противоречат друг другу?
5. Различия между регионами и структурами. Как процесс меняется в зависимости от региона, юридического лица, дочерней компании или приобретения, через которое он пришёл в группу?
6. Время непосредственной работы и полное время прохождения. Как разрыв между ними меняется на каждом шаге?
7. Способность каждого сотрудника подразделения работать с ИИ. Какую степень ответственности за будущую ИИ-систему ему следует передать? Такая оценка субъективна и сильно зависит от ситуации.

Чтобы получить эту информацию, нужны две процедуры.

1. Анализ процессов по журналам учётных систем — process mining. Соберите действия, временные метки, объёмы обработки, правки и реальную картину, которая не совпадает с документацией.
2. Интервью. Предыдущий шаг даст данные, но разговоры с исполнителями покажут, где именно болит. Реальное устройство вашей организации живёт в головах 10–20 человек, которые годами выполняют эту конкретную работу именно в вашей компании. В конечном счёте именно им предстоит принять ваш ИИ, чтобы он работал эффективно.

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

Работающие агенты — это больше, чем вызовы LLM

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

1. Детерминированное выполнение. Если X, то Y, без необходимости оценочного решения. Например, если сумма счёта ниже заданного порога и счёт совпадает с заказом на закупку и документом о получении товара, его оплачивают. Если в декларации указан конкурент, её передают команде по проверке конфликтов интересов. Такие действия лучше всего выполняет обычное старое доброе ПО. Незачем делать хитрый вызов большой языковой модели, LLM, если можно обойтись обычным кодом: он дешёвый, проверяемый, детерминированный — никогда не галлюцинирует — и быстрый.
2. Агентное выполнение. Если у вас есть тысячи прошлых примеров, в которых люди принимали оценочные решения и результат был зафиксирован, а риск на этом шаге достаточно низок, например при согласовании условий сделок или отнесении операций на счета главной книги, определённо стоит использовать LLM для вынесения суждения. Особенно когда результат имеет вид «да/нет», «направить этой команде», «пометить/не помечать», «совпадает/не совпадает»: поручайте это агенту и измеряйте каждый результат. Если же на выходе требуется пять страниц документа, которые человеку всё равно придётся полностью прочитать для проверки, лучше сочетать подходы. Здесь нужно оценивать сложность действия, а не сложность размышления.
3. Человек в контуре принятия решений — human-in-the-loop. На слишком рискованных шагах или при недостатке исторических данных лучше оставить решение человеку: цена ошибочного действия агента слишком высока. Подготовьте для человека все необходимые свидетельства к моменту решения. Например, агент обнаруживает расхождение между счётом и заказом на закупку и предлагает три варианта: всё равно одобрить, отклонить или добавить комментарий и передать другому сотруднику. Агент только что сэкономил человеку 40 минут поисков по письмам, счетам и другим источникам, позволив принять решение за 30 секунд. Но последнее действие по-прежнему требует согласия человека.

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

После этого, ещё до начала разработки, зафиксируйте исходные значения ключевых показателей — KPI. Ваша задача — определить числа, описывающие процесс, которым вы занимаетесь, включая то, где и как они измеряются сегодня. Если этого сделать не удаётся, проект обречён. Через 12 месяцев вы должны иметь возможность оглянуться и сказать: раньше у нас было X, а благодаря созданным агентам стало 3X, 10X или 100X. Только тогда проект можно назвать по-настоящему успешным.

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

Как это выглядит на практике?

Мы перепроектировали работу международной компании, которая каждый месяц сверяла более 300 банковских счетов. Две трети обрабатывала зарубежная команда, остальные были распределены между двумя другими регионами. Использовались три разных формата, но всё велось в Excel. Накопилось более 12 тысяч незакрытых позиций сверки. Первые четыре дня каждого месяца уходили на получение выписок. Сам процесс сверки почти каждый месяц занимал весь месяц.

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

1. Напоминать каждому банку и собирать выписки в том формате, в котором он их предоставляет.
2. Привести их к формату региональной рабочей книги.
3. Выгрузить данные главной книги.
4. Сопоставить записи построчно.
5. Отметить несовпадения.
6. Написать местному финансовому контролёру и запросить контекст по отмеченным позициям.
7. Ждать ответа.
8. Если ответа нет, напомнить.
9. Наконец получить ответ и провести корректировку.
10. Включить регион в консолидированный файл.
11. Повторить все шаги с первого по десятый для каждого из двух остальных регионов, у каждого из которых свой формат.
12. Закрыть период.

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

Мы перепроектировали этот процесс до трёх шагов.

1. Выписки поступают непрерывным потоком, как по конвейеру: больше не нужно за ними гоняться. Это вообще никак не связано с ИИ.
2. Всё, что можно сопоставить по правилам, сопоставляется автоматически. Если не получается, агент целиком собирает материалы по случаю: саму позицию, исторические классификации, свидетельства из разных учётных систем и предлагаемый следующий шаг.
3. Человек разбирает очередь исключений с уже подготовленными материалами для проверки. Ему больше не приходится вручную просеивать данные, разбросанные по ERP и таблицам.

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

Часть 3. Почему так делают не чаще?

Вас обманули

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

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

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

Перепроектирование — сложная работа

По собственной оценке Хаммера и Чампи в 1993 году, от 50 до 70% организаций, пытавшихся перепроектировать процессы, не достигли намеченных результатов. Очевидно, с девяностых мало что изменилось. Сам Хаммер позднее говорил, что «недостаточно учитывал человеческое измерение». Он имел в виду следующее: «убрать передачу работы» в то время означало уволить человека, который за неё отвечал, — это и была вся его работа. А затем попросить всех остальных изменить свою работу, хотя тогдашнее ПО таких изменений не поддерживало. Поэтому после ухода консультантов структура организации и процессы быстро возвращались в исходное состояние, полное неэффективности и ошибок.

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

О дивный новый мир

Традиционные консультанты неплохо разбираются в процессах, отдам им должное. Если вам нужна подробная иллюстрация процесса из 15 шагов, проходящего через десять стран и три юридических лица, обычная консалтинговая фирма за 300 тысяч долларов подготовит самый красивый слайд, который вы когда-либо видели. Но она не справится со второй, более важной половиной работы: понять, что можно доверить модели, а что нельзя; сколько стоит агент, запускающийся 40 тысяч раз в месяц; какую модель — Fable 5.1 или Gemini 3.8 Flash — использовать для конкретного типа задачи, например отнесения операций на счета главной книги или маршрутизации согласований сделок; как оптимально спроектировать набор оценочных тестов для конкретного процесса; к какой из трёх категорий — детерминированное выполнение, агент или решение человека — действительно относится конкретный шаг. Если вы выберете этот путь, процесс будут перепроектировать консультанты, которые гадают, вместо опытных стратегов, работающих с ИИ, и инженеров внедрения. А через шесть месяцев вы будете удивляться, почему пилот разбился при посадке.

У ИИ-лабораторий и компаний обратная проблема. Они умеют создавать агентов — по крайней мере, в большинстве случаев. Но они никогда не садились за один стол с финансами и операционным подразделением, чтобы разобрать процесс, в котором стороны спорят об ответственности и о том, кто от кого зависит. Поэтому они просто прилепят ИИ к сломанному процессу и назовут это автоматизацией, хотя его следовало полностью разобрать и перепроектировать ещё несколько месяцев назад. Более того, крупнейшие лаборатории «прикладного ИИ», такие как OpenAI с DeployCo и Anthropic с Ode, заставят вас навсегда связать себя с их моделями. Ставить весь интеллектуальный стек компании на одного поставщика — самоубийство. Завтра они ограничат частоту запросов, применят квантование, поднимут цены или выведут из эксплуатации модель, на которой вы работаете, а разгребать последствия и оплачивать счета останетесь вы. Можно подумать, что достаточно поменять адрес API с Claude на GLM, Gemini или DeepSeek. Но это не так. Заново прогонять оценочные тесты и определять, какой уровень рассуждений нужен при каждом вызове модели, — кропотливая работа. Лаборатории не помогут вам её выполнить.

Вам нужно соединить сильные стороны обоих подходов: людей, которые действительно руководили финансами, операциями, продажами или HR; разработчиков, способных внедрять промышленное ПО в ERP вроде Microsoft Dynamics или CRM вроде Salesforce; ИИ-инженеров, умеющих создавать независимую от конкретной модели корпоративную среду работы агентов со встроенными механизмами управления и оценочными тестами. Иногда таких специалистов называют Forward Deployed Engineers, FDE, — инженерами внедрения, которые работают непосредственно с заказчиком. Но правда в том, что большинство сегодняшних FDE — посредственные инженеры и посредственные консультанты без каких-либо компетенций в ИИ. В результате толком не делается ничего.

Как выглядит правильный результат?

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

• Время. Мы сократили закрытие месяца с 18–22 до 7–9 дней. Сбои в цепочке поставок теперь проходят первичный разбор менее чем за шесть часов вместо нескольких дней.
• Выручка. Раньше сделки простаивали в среднем 23 дня, теперь шесть. Доля недели, которую продавцы тратили на административную работу, снизилась с 38 до 14%. Освободившееся время сразу вернулось в продажи.
• Затраты. Число счетов с исключениями в расчётах с поставщиками снизилось с 600–800 в месяц до менее 50. В маркетинговом подразделении удалось вернуть 8–12% медиабюджета, терявшихся из-за ошибок в темпе его расходования, которые раньше обнаруживались только в конце месяца. Это дало экономию в миллионы за квартал.
• Риск. Число корректировок зарплат снизилось на 90%, потому что сверка между системами теперь выполнялась до начисления зарплаты. На 80% обращений сотрудников система отвечала на основании внутренних документов компании, а нестандартные случаи по-прежнему передавались человеку в HR.

В совокупности эти внедрения дали более 100 миллионов долларов эффекта. Самое приятное: эту цифру мы рассчитали вместе с клиентами. Это не просто наше заявление — результат измеряли.

Как выглядит настоящая компания по ИИ-трансформации?

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

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

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

Краткое содержание

• Большая часть корпоративных расходов на ИИ сегодня приходится на его наложение поверх прежних процессов. По сути, вы лишь ускоряете плохо устроенный процесс. Майкл Хаммер говорил это об ИТ ещё в 1990 году, а правительство Великобритании фактически подтвердило то же самое в 2025-м на тысяче лицензий Copilot: 1,14 действия на пользователя в день, прироста производительности обнаружить не удалось, но 72% пользователей всё равно остались довольны.
• Время уходило на очереди и передачи работы. Страховая заявка из примера Хаммера находилась в процессе 22 дня, хотя реальная работа занимала 17 минут. Даже ускорив работу вдвое, вы сэкономите восемь минут.
• Предварительная консолидация систем — одна ERP, одна CRM, одна платформа данных — хорошо задокументированный способ потерять два года и девятизначную сумму, прежде чем получить хоть доллар отдачи. На деле вам нужны единое определение процесса и один ответственный за него: агенты способны работать с системами, противоречащими друг другу, а детерминированные интеграции этого никогда не умели.
• Начните с подразделения, проанализируйте журналы учётных систем и поговорите с исполнителями. Затем отнесите каждый шаг к одной из трёх категорий: детерминированное ПО, агент или решение человека с подготовленными материалами. При правильном подходе процесс из 25 шагов превращается в трёх агентов с двумя контрольными точками для человека.
• Когда мы сделали это таким образом, закрытие месяца сократилось с 18–22 до 7–9 дней, число исключений в расчётах с поставщиками упало с 600–800 в месяц до менее 50, число корректировок зарплат снизилось на 90%. Общий эффект всех внедрений превысил 100 миллионов долларов по совместным измерениям с клиентами.
• Ничего не получится без инициативы сверху, желания самих исполнителей и команды, в которой специалисты по процессам, разработчики ПО и ИИ-инженеры работают вместе. А все три компетенции почти ни у кого не собраны.

Автор текста и иллюстраций: Vas, Varick. Оригинальная публикация в X. Предисловие — Сергей Пименов.

Примечание к переводу

Испытание Copilot в DBT проходило с октября по декабрь 2024 года; отчёт опубликован 28 августа 2025 года. В нём действительно есть показатель 1,14 действия в день и приведённые результаты заданий. Однако авторы отчёта предупреждают о малой выборке наблюдаемых заданий и уточняют: оценка роста производительности не была основной целью, поэтому данных для неё собрали мало. Это ограничивает обобщения. Отчёт DBT.

По TSB регулятор сообщает, что сбой затронул значительную часть из 5,2 миллиона клиентов, а не утверждает, что пострадали все 5,2 миллиона. Штраф в 48,65 миллиона фунтов подтверждён. Сообщение FCA.

Результаты внедрений Varick, включая эффект свыше 100 миллионов долларов, здесь сохранены как заявления автора. Независимые данные по этим клиентским проектам не представлены. Названия моделей и проектов сохранены как в оригинале; их наличие и характеристики этим переводом не подтверждаются.

Связанные материалы

• Статья: Смерть компании: что такое организационная сингулярность
• Блог: ИИ уже используют все. Но тратят на него единицы
• База знаний: Cloudflare Agents — трассировка, replay и подтверждение действий в production

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov