Еще недавно главный вопрос вокруг искусственного интеллекта звучал примерно так: какие задачи способны решать современные модели?

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

Поэтому для бизнеса постепенно становится важнее другой вопрос:

Готова ли сама организация использовать эти возможности и способна ли она доказать, что их применение действительно создает ценность?

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

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

Сначала не ИИ, а проблема!

Одна из самых распространенных ошибок начинается с формулировок:

«Нам нужно внедрить ИИ».
«Давайте сделаем корпоративного ИИ-ассистента».
«Нам нужны ИИ-агенты».
«Какие процессы можно автоматизировать с помощью LLM?»

Во всех этих случаях технология появляется раньше задачи. Разумная последовательность противоположна:

бизнес-цель > проблема > процесс > работа человека > возможность изменения > технология

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

Это бизнес-проблема!

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

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

Технология появляется в конце рассуждения, а не в его начале.

На что вообще можно рассчитывать?

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

Прямая экономия

Самый очевидный вариант:

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

Такой эффект проще всего обнаружить в финансовой отчетности. Однако ИИ далеко не всегда приводит именно к нему.

Предотвращенные расходы

Предположим, компания быстро растет. Без ИИ увеличение объема операций на 50% потребовало бы увеличения штата на 40%. После автоматизации бизнес вырос на те же 50%, а штат — только на 5%. Расходы формально не уменьшились. Но компания избежала будущих затрат.

Это предотвращение затрат (cost avoidance), и для многих ИИ-проектов именно оно может стать основным экономическим результатом.

Рост производительности

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

Например: до ИИ: 40 обращений на специалиста в день >>> после ИИ: 70 обращений.

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

Улучшение качества

AI может снижать:

количество ошибок;
долю повторных обращений;
число пропущенных нарушений;
вероятность мошенничества;
количество неверно оформленных документов;
стоимость исправлений.

В некоторых функциях именно качество, а не сокращение труда является главным источником ценности.

Дополнительный доход

ИИ может влиять на:

конверсию;
скорость обслуживания;
удержание клиентов;
количество продаж;
качество предложения;
time-to-market.

В таком случае задача состоит не в снижении затрат, а в увеличении дохода (revenue).

Снижение риска

Это один из самых сложных для измерения эффектов. Например, ИИ-система начинает проверять все договоры на определенный класс рисков, тогда как раньше эксперты успевали анализировать только наиболее крупные сделки. Количество юристов может не измениться. Затраты тоже. Но покрытие (coverage) контроля увеличивается с 20% до 100%. Такой эффект невозможно адекватно оценить простой формулой «сколько FTE мы сократили».

Главная проблема — отсутствие исходного состояния (baseline)

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

Без этих данных практически невозможно корректно оценить ИИ. Поэтому полезно сформулировать жесткое правило:

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

Это не означает, что внедрение невозможно. Но оценка результата превратится в субъективное: «кажется, сотрудники стали работать быстрее».

От FTE к единице работы

Традиционно многие организации измеряют интеллектуальный труд количеством людей.

Есть:

80 бухгалтеров;
50 юристов;
300 операторов;
40 специалистов закупок.

Для анализа ИИ этого недостаточно. Искусственный интеллект автоматизирует не должности — он автоматизирует отдельные единицы работы. Поэтому полезно ввести понятие — единица работы (Work Unit). В разных областях такой единицей может быть:

в бухгалтерии — хозяйственное событие или документ;
в поддержке — обращение;
в юридической функции — проверка договора;
в закупках — заявка;
в кредитовании — заявка заемщика;
в HR — кандидат;
в страховании — страховой случай.

После этого появляется возможность измерять:

Стоимость единицы выполненной работы (Cost per Work Unit)
Время на единицу выполненной работы (Time per Work Unit)
Человеческие минуты на единицу работы (Human Minutes per Work Unit)
Уровень ошибок (Error Rate)
Уровень исключений (Exception Rate)
Уровень автоматизации (Automation Rate)
Стоимость ИИ на единицу работы (AI Cost per Work Unit)Cost per Work Unit)

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

AI заставляет измерять интеллектуальный труд как производственный процесс. Для промышленного производства такой способ мышления давно привычен.

Известны:

производительность линии;
стоимость единицы продукции;
время цикла;
процент брака;
простой;
пропускная способность.

В интеллектуальной деятельности подобная прозрачность встречается значительно реже. Работа специалиста часто представляет собой непрозрачную последовательность:

получил информацию > что-то изучил > с кем-то поговорил > принял решение > внес результат

ИИ-трансформация практически заставляет сделать этот процесс наблюдаемым. И здесь появляется следствие:

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

Если работа выполняется через ИИ-runtime, можно увидеть:

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

По сути появляется аналог наблюдаемости (observability) для бизнес-процессов.

Три уровня метрик

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

Метрики модели

Например:

точность (accuracy);
прецизионность (precision);
полнота (recall);
частота галлюцинаций (hallucination rate);
оценочный балл (evaluation score).

Они необходимы инженерам. Но сами по себе почти ничего не говорят руководителю бизнеса. Модель с accuracy 97% может быть как исключительно полезной, так и совершенно непригодной — в зависимости от характера оставшихся 3% ошибок.

Метрики процесса

Именно здесь становится видно изменение операционной модели:

коэффициент автоматизации (Automation Rate);
Степень сквозной обработки (Straight Through Processing);
Коэффициент участия человека (Human Touch Rate);
Количество человеко-минут на один случай (Human Minutes per Case);
Коэффициент исключений (Exception Rate);
Время цикла (Cycle Time);
Коэффициент ошибок (Error Rate);
Коэффициент эскалации (Escalation Rate).

Эти показатели связывают ИИ с реальной работой организации.

Бизнес-метрики

В конечном итоге интерес представляет:

стоимость (cost);
доход (revenue);
маржа (margin);
емкость (capacity);
удержание (retention);
риск (risk);
избегание найма (avoided hiring);
финансовые потери (losses).

Поэтому хорошая ИИ-инициатива должна формировать цепочку:

Model Metric > Process Metric > Business Metric.

Например, не — точная классификации обращений составила 96%, а — 68% обращений теперь закрываются без участия оператора, средняя стоимость обработки снизилась с 74 до 31 рубля при сохранении доли критических ошибок ниже установленного уровня.

Это уже измеримый бизнес-результат.

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

Для AI-native процессов особенно полезен показатель Straight Through Processing Rate, STP — доля операций, полностью завершенных без участия человека.

Предположим, из одного миллиона операций:

620 тысяч AI обработал полностью;
250 тысяч подготовил, но потребовалось подтверждение человека;
130 тысяч остались полностью человеческими.

Тогда можно видеть сразу три класса:

Автономные (Autonomous) — 62%.
С участием ИИ (AI-assisted) — 25%.
Выполненные человеком (Human-only) — 13%.

Такое распределение гораздо информативнее, чем утверждение: «ИИ используется в 87% операций». Потому что использование ИИ еще не означает изменение экономики процесса.

Автоматизация без качества ничего не стоит

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

Автоматизация (Automation).
Качество (Quality).
Экономика (Economics).

Например:

STP — 82%.
Critical Error Rate — 0,01%.
Cost per Case — 23 рубля.

Только их сочетание позволяет сделать вывод о качестве решения. Особенно опасным показателем становится показатель некорректной автоматизации (False Automation Rate) — доля случаев, которые ИИ обработал автоматически, хотя должен был передать человеку. Для финансовых, юридических, медицинских, промышленных и других высокорисковых процессов он может быть важнее общей accuracy.

Хороший ИИ должен уметь не решать задачу

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

На практике зрелая система должна уметь определять:

«Здесь я уверен».
«Здесь мне не хватает данных».
«Здесь слишком высок риск».
«Здесь решение должен принять человек».

Поэтому важна не только способность решить задачу, но и качество эскалации.

Это приводит к архитектуре:

низкий риск + высокая уверенность > автоматическое действие;
неопределенность > уточнение;
повышенный риск > подтверждение человеком;
критический риск > только человек.

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

Какая зрелость требуется от организации

Не каждая компания одинаково готова к AI-native изменениям. Условно можно представить несколько уровней зрелости.

Уровень 0. Heroic Organization

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

Уровень 1. Documented

Основные процессы хотя бы описаны.

Понятно:

кто что делает;
какие системы используются;
где начинаются и заканчиваются основные операции.

Здесь уже возможно выполнять локальные AI Integration пилоты.

Уровень 2. Measured

Организация знает:

объем работы;
cycle time;
SLA;
количество ошибок;
FTE;
основные затраты.

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

Уровень 3. Digital

Основные события процесса существуют в цифровом виде. Данные доступны системно. Есть API, события, идентификаторы объектов, история операций. Можно проследить жизненный цикл единицы работы. На этом уровне становятся возможными более глубокие интеграции и agentic workflow.

Уровень 4. Optimized

Организация понимает:

стоимость транзакции;
throughput;
bottleneck;
типовые исключения;
причины ошибок;
структуру трудозатрат.

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

Уровень 5. Adaptive

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

сложности;
риска;
уверенности;
стоимости;
необходимости экспертизы.

Исключения становятся источником дальнейшего обучения и совершенствования системы. Это уже можно считать AI-native организационной моделью.

Десять лет повышать зрелость?

У модели зрелости (maturity model) есть опасная трактовка: «Мы пока на втором уровне, значит сначала необходимо построить идеальную корпоративную архитектуру, Data Lake, MDM, BPM, а потом когда-нибудь займемся ИИ». Такой подход практически гарантирует отсутствие результата. Зрелость лучше создавать локально вокруг выбранного процесса. Если компания хочет автоматизировать проверку договоров, ей не нужно сначала перестраивать весь бизнес. Необходимо сделать измеримым именно этот процесс:

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

После этого можно переходить к ИИ. То есть правильнее говорить:

Готовность к внедрению ИИ строится от процесса к процессу.

Что необходимо подготовить для серьезного внедрения

Для выбранного процесса желательно иметь как минимум несколько вещей.

Владельца процесса

Должен существовать человек, отвечающий не за ИИ, а за результат бизнес-функции.

Определенную единицу работы

Необходимо понимать, что именно будет обрабатываться и измеряться.

Исходное состояние

До изменения должны быть известны:

объем (volume);
стоимость (cost);
время (time);
качество (quality);
ошибки (errors);
исключения (exceptions);
вовлеченность человека (human effort).

Данные

Какие данные требуются для выполнения работы?
Где они находятся?
Какого они качества?
Можно ли предоставить их ИИ?

Модель угроз

Какие действия:

разрешено автоматизировать;
требуют подтверждения;
допустимы только как рекомендация;
не должны передаваться ИИ.

Целевая операционная модель

Как должен выглядеть процесс после внедрения? Без ответа на этот вопрос организация рискует просто добавить ИИ поверх старой работы.

Архитектура изменений (Measurement Architecture)

Как именно после запуска будет доказан эффект? Этот вопрос должен решаться до разработки, а не после.

Архитектура изменений — часть самой системы!

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

Например:

версия модели (model version);
версия задания и конфигурации (prompt/configuration version);
принятое ИИ-решение;
уверенность (confidence);
использованные источники;
выполненные запросы к инструментам (tool calls);
участие человека;
исправления;
время обработки;
стоимость вывода (inference cost);
конечный выход (outcome).

Без этого через полгода может возникнуть знакомая ситуация: «Мы вложили значительные средства в ИИ. Какой результат?», «Пользователям вроде нравится».

Для промышленного внедрения этого недостаточно.

Лучшие практики

AI-проект как эксперимент

Еще одна проблема оценки — обычное сравнение «до» и «после». Между двумя периодами могут измениться:

объем бизнеса;
сезонность;
состав команды;
процессы;
другие информационные системы;
клиентская база;
внешние условия.

Поэтому там, где это возможно, полезнее использовать контрольную группу.

Например:

часть обращений → старый процесс;
часть обращений → ИИ-процесс.

Или:

один филиал → решения принимают люди;
другой → ИИ.

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

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

Например:

ИИ должен автоматически закрывать не менее 60% типовых обращений, снизить стоимость обработки минимум на 30% и не увеличить Critical Error Rate выше 0,05%. Это гораздо более зрелая постановка, чем: «Запустим пилот ИИ-агента и посмотрим, что получится».

Начать с исторических данных

Прежде чем подключать ИИ к «боевым» процессам, можно посмотреть на историю.

Например:

10 000 обращений;
5 000 договоров;
50 000 бухгалтерских документов;
20 000 страховых случаев.

И проверить: что бы произошло, если бы ИИ работал в тот момент?

Это дает возможность понять:

потенциальная степень автоматизации (automation rate);
виды ошибок;
качество эскалации;
стоимость вывода (inference);
необходимые данные;
экономический потенциал.

Такая offline-оценка часто позволяет дешево закрыть слабую гипотезу до начала большой разработки.

Кто должен отвечать за эффект?

Здесь особенно важно не повторить старую ошибку цифровизации:

IT внедряет систему
 > бизнес продолжает работать по-старому
  > экономического результата нет
   > виноват IT-проект

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

Спонсор (business sponsor) отвечает за ожидаемый бизнес-результат.
Владелец процесса (process owner) — за изменение операционной модели.
ИИ-интегратор — за дизайн трансформации и выбор AI-возможностей.
Архитектор (solution architect) — за техническую реализацию.
Специалисты по оценке рисков, безопасности, юриспруденции (Risk / Security / Legal) — за допустимые границы.
Специалист по финансам и экономике — за методику расчета и подтверждение экономического эффекта.

Это особенно важный момент. ИИ-трансформация не должна принадлежать исключительно ее инициаторам или ИТ. Ценность возникает внутри бизнес-процесса, поэтому именно бизнес должен отвечать за ее реализацию.

Почему специалист по финансам и экономике должен участвовать с самого начала?

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

Например:

Hard Saving — реальные расходы исчезли.
Cost Avoidance — компания избежала будущих затрат.
Capacity Gain — возникла дополнительная производственная мощность.
Revenue Gain — появился дополнительный доход.
Risk Reduction — уменьшился expected loss.

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

Эффект иногда возникает только после изменения организации

Это, вероятно, одна из наиболее важных особенностей ИИ. Допустим, система увеличила производительность специалистов на 40%.

Если компания:

не увеличила объем работы;
не уменьшила штат;
не перевела людей на более ценные задачи;

то возникшая мощность осталась неиспользованной. Технологический эффект есть. Экономического — нет.

Поэтому между двумя понятиями необходимо проводить границу:

AI Value Created — технология создала возможность.
AI Value Realized — организация превратила эту возможность в результат.

Разница между ними определяется не моделью, а управлением и изменением способностей.

Эффект отскока (rebound effect): когда затрат меньше не становится

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

То же может произойти с:

определением мошенничества (fraud detection);
проверкой на соответствие (compliance);
аудитом (audit);
контролем качества (QA);
налоговой экспертизой;
анализом клиентских данных.

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

Когда AI-native имеет смысл?

AI-native подход особенно интересен, если процесс обладает несколькими свойствами. Существует большое количество вариантов одной задачи. Входные данные неструктурированы. Человек является преобразователем смысла (semantic translation layer) между реальностью и информационной системой. Значительная часть труда состоит из:

прочитать > понять > найти > сопоставить > классифицировать > решить > объяснить

Есть возможность формально проверить хотя бы значительную часть результата. Стоимость человеческого труда заметно превышает стоимость ИИ вывода. Существует длинный хвост (long tail) ситуаций, которые дорого программировать отдельными рабочим процессом. Именно здесь ИИ способен изменить не один шаг, а всю операционную модель деятельности (operating model).

Когда лучше ограничиться AI Integration?

Иногда процесс в целом работает хорошо, но содержит локальную интеллектуальную операцию.

Например:

классификация входящего обращения;
извлечение информации из документа;
генерация summary;
подготовка ответа;
семантический поиск.

В этом случае перестраивать всю систему необязательно. AI Integration может дать большую часть ценности существенно меньшей ценой и риском. Это важный принцип зрелости:

Не каждую AI Integration необходимо превращать в AI-native трансформацию!

А когда ИИ вообще не нужен?

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

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

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

Когда компании, возможно, пока не стоит заниматься серьезным ИИ?

Есть несколько тревожных признаков. Компания не способна сформулировать бизнес-проблему, кроме «надо внедрять ИИ». Нет владельца процесса. Неизвестны объем, стоимость и качество текущей работы. Данные недоступны или критически некачественны. Результат работы невозможно проверить. Стоимость ошибки чрезвычайно высока, а надежного механизма контроля нет. Нет возможности встроить решение в существующий процесс. Руководство ожидает эффект исключительно от технологии, не предполагая менять работу людей. Наконец, если главным KPI проекта становится: «Количество внедренных ИИ-сценариев», скорее всего, организация уже движется не в ту сторону.

Практический путь к внедрению

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

Шаг 1. Найти дорогие интеллектуальные процессы

Не искать варианты использования ИИ вообще, а искать:

большие объемы ручного интеллектуального труда;
очереди;
ошибки;
дорогих специалистов;
низкую масштабируемость;
значительный «long tail».

Шаг 2. Выделить единицы работ

Определить измеримую единицу работы.

Шаг 3. Построить baseline

Измерить текущее состояние.

Шаг 4. Декомпозировать процесс

Разделить работу на:

Человек / ИИ / классическая автоматизация / исключение

Шаг 5. Сформировать целевую операционную модель

Описать, как процесс должен работать после изменений.

Шаг 6. Определить границы человек/ИИ

Задать уровни автономности и риска.

Шаг 7. Проверить исторические данные

Провести offline оценку.

Шаг 8. Посчитать экономику

Сравнить: Текущие затраты с ИИ Runtime + Иногда Человек + Платформа + Поддержка.

Шаг 9. Провести контролируемый пилот

По возможности с целевой группой.

Шаг 10. Измерить Business Outcome

И только после этого масштабировать.

Что тогда означает AI-зрелость?

ИИ зрелость не стоит измерять количеством моделей, GPU или ИИ-разработчиков. Можно предложить другую формулу:

Готовность к ИИ= Зрелость процессов × Доступность данных × Цифровая интеграция × Измеримость способностей × Управление рисками × Способность к изменениям.

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

ИИ, как следующий этап операционной зрелости

Предыдущие волны цифровизации в основном переводили информацию и процессы в цифровой вид. Организация становилась зрелой, если ее деятельность была:

автоматизирована;
интегрирована;
оцифрована.

ИИ добавляет новое требование: интеллектуальная работа должна стать измеримой и декомпозируемой. Компания должна понимать не только, сколько людей находится в подразделении, но и:

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

И только после этого можно системно решать:

что оставить человеку;
что передать обычному коду;
что передать ИИ;
а что вообще перестать делать.

Заключение

Внедрение ИИ не начинается с выбора LLM. И не заканчивается запуском ИИ-агента. Оно начинается с способности компании ответить на несколько значительно более приземленных вопросов:

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

И последний вопрос особенно важен:

Что организация сделает с производительностью, которую создаст ИИ?

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

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

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