Главное в исследовании

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

Авторы получили 228 валидных анкет от малых и средних компаний Хорватии. В выборке 68% организаций относились к услугам, 22% — к промышленности, 6% — к ИТ и 4% — к сельскому хозяйству. Респондентами были владельцы, руководители и сотрудники, участвующие в принятии решений. Для анализа использовалась множественная линейная регрессия.

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

Где связь оказалась сильнее

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

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

Модели объясняли 37,4% вариации оценок производительности труда и 34,2% вариации снижения операционных затрат. Для эффективности процессов показатель был заметно ниже — 15,9%. Это не означает, что ИИ «повышает производительность на 37,4%». R² показывает объясняющую способность статистической модели, а не размер экономии конкретной компании.

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

Почему процесс может не ускориться

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

Поэтому измерять нужно не скорость модели, а сквозной процесс:

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

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

Как выглядит прикладная архитектура

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

Рабочая схема может состоять из пяти слоёв:

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

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

Какие данные понадобятся

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

Минимальный набор контроля включает:

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

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

Как считать экономику без самообмана

Базовая формула проста:

**Месячный эффект = сэкономленные часы × полная стоимость часа + предотвращённые потери − эксплуатационные расходы.**

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

Модельный пример: восемь сотрудников экономят по 30 минут в рабочий день. При 20 рабочих днях это 80 часов в месяц. Если полная стоимость часа составляет 1000 рублей, валовой эффект равен 80 тысячам рублей. При эксплуатации за 60 тысяч остаётся 20 тысяч рублей в месяц. Пилот стоимостью 300 тысяч рублей окупится примерно за 15 месяцев. Если реальная экономия окажется не 80, а 120 часов, срок сократится примерно до пяти месяцев.

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

Что это значит для российского бизнеса

Российский контекст подтверждает, что инфраструктурный выбор всё чаще делается через экономику эксперимента. По данным исследования облачного рынка, которые приводит ComNews, 24% опрошенных компаний уже запустили ИИ-нагрузки в облаке, ещё 22% пилотируют их или планируют запуск в течение года. При этом 41% берут у провайдера только вычислительную инфраструктуру и внедряют ИИ самостоятельно.

Есть и обратная сторона: 57% участников управляют мультиоблачной средой вручную, а зрелую практику контроля облачных затрат имеют лишь 10%. Поэтому облако снижает порог пилота, но не отменяет FinOps, лимиты потребления и владельца бюджета. Локальный контур даёт больше контроля над данными, однако переносит на компанию стоимость оборудования, обновлений и эксплуатации.

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

План пилота на четыре недели

  • Неделя 1: выбрать один процесс, зафиксировать базовые метрики и собрать примеры.
  • Неделя 2: подключить данные и реализовать ИИ только для одного этапа, сохранив ручное подтверждение.
  • Неделя 3: провести параллельный прогон, измерить ошибки, время и стоимость одной операции.
  • Неделя 4: посчитать полный эффект, определить исключения и принять решение: масштабировать, изменить архитектуру или остановить пилот.

Результатом должен стать не чат-бот как таковой, а таблица «до/после» с качеством, временем, стоимостью и рисками. Если улучшение видно только в презентации, это ещё исследование возможностей, а не внедрение.

Что взять руководителю

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