Как бизнесу использовать ИИ-автоматизацию (без хайпа)

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

ИИ-автоматизация — это не что-то одно

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

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

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

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

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

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

Сценарии, которые выдерживают продакшен

Приём документов и извлечение полей

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

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

Сортировка, классификация и маршрутизация

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

Черновики, а не решения

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

Внутренний поиск по знаниям

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

Выявление отклонений

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

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

Оценивайте кандидатов по четырём критериям, именно в этом порядке:

1. Объём, умноженный на время обработки. Десять минут в день — это не проект. Десять минут сорок раз в день — уже проект.
2. Цена и обратимость ошибки. Неверно направленное обращение поправимо. Ошибочная таможенная декларация или сумма в расчётном листе — нет.
3. Наличие примеров. Есть ли у вас несколько сотен прошлых случаев с известными правильными ответами? Если нет, оценивать нечего, и любое обсуждение превращается в столкновение мнений.
4. Владелец процесса. Этого должен хотеть человек, чья работа заметно улучшится.

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

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

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

1. Замер базовой линии. Посчитайте, сколько случаев проходит за неделю, сколько минут уходит на каждый и какова текущая доля ошибок. Команды, которые это пропускают, потом никогда не смогут доказать, что автоматизация сработала.
2. Сбор оценочного набора. Двести-триста реальных случаев с согласованными правильными ответами, намеренно включая самые неудобные. Это самый ценный артефакт всего проекта, и принадлежать он должен вам, а не подрядчику.
3. Прототип на этом наборе. Цель прототипа — быстро провалиться на настоящих, грязных данных, а не хорошо выглядеть на трёх отобранных примерах.
4. Настройка порогов. Решите, какая оценка означает «обработать автоматически», какая — «отправить на проверку», а какая — «отклонить сразу».
5. Теневой запуск. Система работает параллельно текущему процессу, её результат сравнивают, но не используют. Каждое расхождение — информация о том, где она ломается.
6. Перевод одного среза. Один тип документа, один филиал, один регион — никогда всё сразу.
7. Мониторинг и повторная оценка. Поставщики обновляют модели, а ваши документы меняются. Прогоняйте оценочный набор по расписанию и относитесь к просадке как к инциденту в продакшене.

Как сохранить контроль человека, не потеряв скорость

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

Уровень	Поведение	Кому подходит
Подсказка	Только черновики, работу делает человек	Новые или ответственные задачи
Проверка	Действует только после явного согласования	Большинство бэк-офисных процессов
По порогу уверенности	Ясные случаи обрабатываются сами, остальные уходят в очередь на проверку	Проверенные потоки большого объёма
Автономно с аудитом	Действует и ведёт журнал, люди проверяют выборочно	Дешёвые и обратимые действия

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

Трёхъязычная реальность Узбекистана

• Документы и сообщения приходят на узбекском (и латиницей, и кириллицей), русском и английском, часто вперемешку внутри одной переписки. В вашем оценочном наборе должны быть все три языка.
• Качество моделей на этих трёх языках неодинаково. Требуйте отчёт о точности отдельно по каждому языку: одна усреднённая цифра скроет язык, на котором всё плохо.
• Имена и адреса встречаются в нескольких вариантах транслитерации одной и той же сущности. Нормализация — задача детерминированного кода, опирающегося на ваши собственные справочники, а не предмет суждения модели.
• Сканы с печатями, подписями и рукописным текстом задают потолок для всего, что идёт дальше. Если качество OCR низкое, наладьте практику сканирования, прежде чем винить модель.
• Всё, что касается государственных порталов, банков и платёжных провайдеров, обязано соответствовать их форматам и графикам. Это работа по системной интеграции, лежащая под ИИ, и обычно она составляет большую половину усилий.

Вопросы, которые стоит задать любому подрядчику

1. Как мы будем измерять, что решение работает, и на каких данных?
2. Можно ли увидеть точность в разбивке по типам документов и по языкам?
3. Что именно происходит, когда модель не уверена, — что видит пользователь?
4. Где обрабатываются и хранятся наши данные, как долго и используются ли они для обучения моделей?
5. Что будет запасным вариантом, если у провайдера случится сбой или он снимет с поддержки модель, от которой мы зависим?
6. Кому в итоге принадлежат код, промпты и оценочный набор?
7. Сколько стоит эксплуатация в месяц при нашем объёме и что произойдёт, если объём удвоится?
8. Какая ручная работа останется после запуска и кто будет её делать?

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

Ошибки, которые тихо убивают такие проекты

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

Итог

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