Как внедрить ИИ: этапы внедрения искусственного интеллекта в компании

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

Что считать внедрением ИИ и чем оно отличается от автоматизации

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

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

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

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

Как проверить, нужен ли вам именно искусственный интеллект

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

1. Опишите задачу одним предложением без слов про цифровизацию и эффективность. Если предложение не получается, задача пока не сформулирована.
2. Возьмите двадцать реальных случаев из прошлого месяца и попросите опытного сотрудника решить их вручную, фиксируя время и логику решения.
3. Посмотрите, пользовался ли он информацией, которой нет в системах компании. Если да, модель тоже её не найдёт.
4. Проверьте, можно ли описать его логику десятью правилами. Если можно, делайте автоматизацию.
5. Посчитайте, сколько раз в месяц этот случай повторяется. Редкие задачи не окупают ни разработку, ни сопровождение.

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

Какие процессы отдают искусственному интеллекту первыми

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

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

Клиентский сервис и поддержка

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

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

Продажи и маркетинг

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

Документооборот и бэк-офис

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

Аналитика, производство и логистика

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

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

Признаки процесса, готового к искусственному интеллекту

Хороший кандидат на первый проект узнаётся по набору свойств. Чем больше пунктов совпадает, тем выше шанс довести дело до промышленного запуска.

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

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

Процессы, которые не стоит брать в первую волну

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

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

Этапы внедрения искусственного интеллекта в компании

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

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

Этап 1. Аудит процессов и выбор задачи под искусственный интеллект

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

Рабочий порядок действий выглядит так.

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

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

Этап 2. Проверка данных и инфраструктуры

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

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

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

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

Что делать, если данные не готовы

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

Этап 3. Выбор технологии, платформы и поставщика

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

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

Критерии, по которым стоит сравнивать варианты, сводятся к короткому списку.

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

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

Этап 4. Пилот на реальных данных

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

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

Последовательность работ внутри пилота выглядит так.

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

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

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

Как выбрать режим участия человека

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

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

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

Этап 5. Промышленный запуск и интеграция в процессы

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

Содержание этапа сводится к пяти направлениям работ.

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

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

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

Этап 6. Масштабирование сработавших сценариев

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

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

Чтобы масштабирование не превратилось в десять независимых проектов, в компании появляется набор общих элементов.

1. Единая точка доступа к моделям, через которую работают все сценарии. Это позволяет менять поставщика и контролировать расходы централизованно.
2. Общая библиотека промптов и настроек с версиями, чтобы удачные формулировки не терялись в переписке.
3. Повторно используемый набор проверочных выборок и единая процедура приёмки нового сценария.
4. Реестр внедрённых решений с указанием владельца процесса, целевой метрики и фактического результата.
5. Правила работы с данными, одинаковые для всех подразделений, чтобы каждый раз не согласовывать вопрос заново.

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

Этап 7. Сопровождение, обучение сотрудников и донастройка

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

Регулярное сопровождение состоит из нескольких процедур.

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

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

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

Этапы, сроки и стоимость одной таблицей

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

Этап	Срок	Кто участвует	Результат этапа	Порядок затрат
Аудит процессов и выбор задачи	1–3 недели	Руководители направлений, владелец процесса	Выбранный процесс, цель в цифрах, базовый замер	Внутренние трудозатраты
Проверка данных и инфраструктуры	1–2 недели	Служба информационных технологий, аналитик, служба безопасности	Заключение о пригодности данных и ограничениях по их размещению	Внутренние трудозатраты или аудит от 150 тысяч рублей
Выбор технологии и поставщика	2–4 недели	Закупки, служба информационных технологий, владелец процесса	Выбранный вариант, испытание на своей выборке, договор	Без прямых затрат, кроме платных испытаний
Пилот на реальных данных	4–6 недель	Группа из 3–5 сотрудников, подрядчик, аналитик	Статистика качества, решение о продолжении	От 300 тысяч до 2 миллионов рублей
Промышленный запуск	4–8 недель	Служба информационных технологий, владелец процесса, служба персонала	Интеграция, регламент, порядок действий при отказе	От 500 тысяч до 3 миллионов рублей
Масштабирование	2–6 месяцев	Проектный офис, подразделения	Сценарий работает на всём объёме и в соседних подразделениях	20–40 процентов от стоимости первого запуска на каждый новый участок
Сопровождение	Постоянно	Владелец процесса, служба информационных технологий, подрядчик	Стабильное качество, обновление базы знаний	15–25 процентов годовых от стоимости внедрения плюс плата за обращения к модели

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

Технологии под задачу

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

Машинное обучение на структурированных данных

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

Большие языковые модели

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

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

Поиск по собственным документам

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

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

Программные роботы

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

Агентные решения

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

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

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

Точечное внедрение или масштабная трансформация: как выбрать стратегию под размер компании

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

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

Размер и ситуация	Разумная стратегия	Количество сценариев в первый год	Кто ведёт
До 50 сотрудников	Готовые продукты и сервисы без разработки	1–2	Руководитель направления лично
50–300 сотрудников	Точечное внедрение в одном или двух процессах	2–4	Владелец процесса плюс внешний подрядчик
300–2000 сотрудников	Общая техническая основа, сценарии по одному	4–8	Проектный офис или центр компетенций из 2–4 человек
Свыше 2000 сотрудников	Программа с единой платформой и управлением портфелем	8–20	Выделенная команда, куратор на уровне правления
Данные в плохом состоянии при любом размере	Сначала порядок в данных, затем один сценарий	1	Служба информационных технологий и аналитик

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

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

Нужен ли компании центр компетенций

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

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

Как измерить эффект: показатели и расчёт возврата вложений

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

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

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

Как считать возврат вложений без самообмана

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

Порядок расчёта на примере разбора входящих обращений.

1. Объём. Четыре тысячи обращений в месяц, среднее время обработки двадцать две минуты, занято девять операторов.
2. Экономия времени. Подготовка черновика ответа сокращает обработку до четырнадцати минут, высвобождается около пятисот тридцати часов в месяц.
3. Денежная оценка. При полной стоимости часа оператора около девятисот рублей это примерно четыреста семьдесят тысяч рублей в месяц.
4. Поправка на реальность. Высвобожденное время превращается в деньги только если вы либо не нанимаете новых людей при росте объёма, либо переводите часть команды на другие задачи. Без этого экономия остаётся на бумаге.
5. Расходы. Обращения к модели около шестидесяти тысяч рублей в месяц, сопровождение сто двадцать тысяч, разовое внедрение один миллион восемьсот тысяч.
6. Срок окупаемости. При консервативной оценке, когда в деньги переводится половина высвобожденного времени, возврат наступает примерно через девять месяцев.

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

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

Когда искусственный интеллект не даёт ожидаемого результата

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

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

Разбор начинается с замера реального использования. Сколько раз в день система вызывается, какая доля сотрудников ею пользуется, какая доля результатов принимается без правок. Эти три цифры обычно сразу указывают на причину. Низкое использование означает организационную проблему, высокая доля правок означает проблему качества.

Риски и барьеры внедрения

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

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

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

Сопротивление сотрудников

Сопротивление редко бывает иррациональным. Чаще за ним стоит обоснованное опасение за рабочее место или за показатели премии. Люди, которые годами были источником экспертизы, видят в системе угрозу своему положению в коллективе.

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

Отсутствие владельца процесса

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

Безопасность данных и управление доступами

Вопрос решается на этапе проверки инфраструктуры, но возвращается при каждом расширении. Основные моменты, которые стоит закрыть документально.

1. Какие категории данных допустимо передавать во внешний сервис, а какие обрабатываются только внутри контура.
2. Как обрабатываются персональные данные и какие согласия для этого требуются.
3. Наследует ли система права доступа пользователя. Иначе поиск по базе знаний выдаст сотруднику документы, которых он видеть не должен.
4. Ведётся ли журнал запросов и ответов, кто имеет к нему доступ и сколько он хранится.
5. Что происходит при увольнении сотрудника, чьи переписки и документы попали в обучающую выборку.
6. Как компания реагирует на попытки через переписку заставить систему выдать то, чего она выдавать не должна.

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

Зависимость от поставщика

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

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

Ошибки при внедрении искусственного интеллекта и как их избежать

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

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

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

Примеры внедрения искусственного интеллекта в российских компаниях

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

Розничная торговля и электронная коммерция

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

Финансовый сектор

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

Производство и логистика

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

Профессиональные услуги и внутренние функции

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

Частые вопросы

Сколько времени занимает внедрение

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

Сколько стоит внедрение искусственного интеллекта в компании

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

Можно ли внедрить искусственный интеллект без изменения бизнес-процессов

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

Сколько данных нужно для старта

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

Кто должен отвечать за проект внутри компании

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

Что делать, если пилот не дал результата

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

Заменит ли искусственный интеллект сотрудников

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

С чего начать прямо сейчас, если ничего ещё не сделано

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

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