Автоматизация с AI начинается там, где жёсткие правила ломаются о реальность: разные формулировки в заявках, шум датчиков, нетипичные простои, неполные данные в накладных. Классический RPA и скрипты на if-else отлично работают, пока мир предсказуем. Но как только входящий поток становится «грязным» — синонимы, опечатки, смена формата поставщика, аномалия на линии — человек снова оказывается в контуре.

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

Правила vs модель: фреймворк выбора

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

Предсказуемость входа. Если 95% заявок приходят в одном JSON-шаблоне, хватит валидатора и маппинга полей. Если половина — сканы, PDF разной вёрстки и письма в свободной форме, правила быстро превращаются в зоопарк регулярок.

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

Объём ручной работы. Посчитайте, сколько FTE уходит на классификацию, сверку, разбор инцидентов. Если это 0,2 ставки — AI может не окупиться. Если 8 человек в смену перекладывают тикеты — экономика другая.

Наличие размеченных данных. Без истории «вход → правильное решение» модель либо не обучить, либо придётся жить на zero-shot и тщательной валидации.

Безопасный контур для продакшена: модель предлагает, система разрешает. На производстве автопилот без аудита — риск, а не инновация. Даже когда модель уверена на 99%, критичные действия проходят через whitelist разрешённых команд, лимиты скорости изменения уставок и обязательный лог с объяснением (хотя бы кратким: какие признаки сработали).

Когда гибрид работает лучше «чистого AI»

Типичная схема для промышленной телеметрии: пороги и скользящие окна ловят грубые отклонения мгновенно, модель оценивает «мягкие» паттерны — дрейф вибрации, изменение профиля тока до выхода за hard limit. Для документооборота: regex и справочник контрагентов извлекают ИНН и номер заказа, LLM достраивает нестандартные поля и сверяет смысл («поставка на склад Б» vs «склад А» в шапке).

Команда фиксирует это в ADR или коротком decision log: почему на шаге 3 появилась модель, какой baseline у правил, какой порог отката.

Типовые сценарии и что измерять

Предиктивное обслуживание

По вибрации, току, циклам наработки — вероятность отказа в горизонте N часов, а не «среднее по паспорту». Ценность не в красивом графике, а в сокращении внеплановых остановок и оптимизации запасов ЗИП. Метрики пилота:

• Precision@k — из k самых рискованных узлов сколько реально потребовали вмешательства.
• Lead time — за сколько часов до отказа модель подала сигнал (если сигнал за 10 минут до поломки, диспетчер не успевает).
• Стоимость ложных срабатываний — лишний выезд бригады, остановка линии «на всякий случай».

Связанный контекст — мониторинг оборудования: без нормальной телеметрии и временных меток модель не из чего учиться.

Разбор инцидентов и операционная аналитика

Агрегация логов, алармов HMI, действий оператора за смену в связный отчёт. Здесь LLM часто выигрывает у правил, потому что формулировки событий разнородны. Риск — галлюцинации: модель может «достроить» причину простоя. Антипаттерн: отправлять отчёт руководству без ссылок на сырые события. Правильно: каждый тезис в сводке кликабелен до исходной записи в журнале.

Маршрутизация заявок

Сервисная служба, запчасти, приоритет, эскалация. Workflow: вход → классификация (модель) → проверка обязательных полей (правила) → назначение по матрице компетенций (правила) → при низкой уверенности классификации — очередь человека. Метрика — не accuracy на тесте, а время до первого корректного назначения и доля переоткрытых тикетов.

Документооборот

Распознавание накладных, сверка с заказом, выявление расхождений. Пилот на одном типе документов, эталонный набор из 200–500 реальных сканов (с обезличиванием), сравнение с ручной обработкой по времени и по доле полей, извлечённых без правки.

База инфраструктуры остаётся классической: очереди, идемпотентность, роли, аудит. Об этом подробнее — в материале про разработку автоматизации. AI-слой ставится поверх, а не вместо.

Рабочий процесс внедрения для команды

Опыт показывает, что провалы чаще организационные, чем технические. Рабочий цикл из шести этапов:

1. Карта процесса as-is. Не схема «как в регламенте», а реальность: где люди подменяют систему Excel, кто принимает решение в серой зоне, какие исключения случаются еженедельно.

2. Baseline без модели. Автоматизируйте всё, что дёшево автоматизируется правилами. Зафиксируйте метрики: время цикла, ошибки, стоимость обработки единицы.

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

4. Эталонные кейсы и регрессия. Набор «золотых» примеров + намеренно сложные edge cases. Любое обновление модели или промпта гоняется через этот набор до выката.

5. Shadow mode. Модель предлагает решение, но в проде пока исполняются старые правила. Сравниваете расхождения две–четыре недели.

6. Постепенное делегирование. Сначала только рекомендации, потом авто-действия с низким риском, потом расширение scope.

Роли в команде: владелец процесса (бизнес), инженер данных/ML, разработчик интеграций, представитель эксплуатации. Без владельца процесса пилот превращается в демо.

Антипаттерны, которые убивают проекты

«AI в тендере». Модель тащат в прод, не побив baseline правил. Если классификатор на правилах даёт 92% accuracy за два дня, а нейросеть 94% за три месяца — честный ответ очевиден.

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

Обучение на мусоре. Исторические тикеты закрывали «как попало», разметка противоречива. Модель воспроизводит хаос быстрее человека.

Отсутствие мониторинга дрейфа. Распределение входов меняется — сезон, новый поставщик, редизайн формы — качество падает незаметно, пока не случится инцидент.

Сквозная генерация без валидации. LLM пишет SQL, команды OPC, конфиги — без статического анализа, sandbox и лимитов. Отдельный класс рисков.

Единый промпт на весь завод. Один агент «делает всё» вместо цепочки узких специализированных шагов с чёткими контрактами между ними.

Метрики и отчётность для руководства

Технические метрики (F1, ROC-AUC) нужны команде. Руководству — перевод в деньги и время:

Отчитывайтесь когортами: «после включения авто-маршрутизации на линии 2», а не «AI улучшил всё». Иначе эффект смешивается с сезонностью и другими инициативами.

Организационная готовность

Даже идеальная модель не приживётся, если:

• нет владельца данных (кто отвечает за качество справочников и истории);
• IT и производство не согласовали окна на обновления;
• профсоюз или линейный персонал видят в AI угрозу, а не снятие рутины.

Полезный ход — начать с задач, которые снимают смену самую ненавистную рутину (ночные сводки, дублирование ввода). Прозрачность и право переопределения важнее слайдов про «цифровую трансформацию».

Технический контур: что заложить в архитектуру

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

Очереди и идемпотентность. Любое действие, инициированное моделью (создать заявку, отправить команду, записать в ERP), должно иметь idempotency key. Повторная доставка сообщения из Kafka или RabbitMQ не должна дублировать списание или остановку линии.

Версионирование моделей и промптов. В логе каждого решения — model_version, prompt_hash, входные признаки (или их хэш). Когда качество падает, вы можете откатиться не «вслепую», а на известную версию.

Human-in-the-loop API. Единый endpoint для оператора: принять, отклонить, исправить с комментарием. Исправления — золотая разметка для следующей итерации модели.

Feature store для промышленности. Если предиктивка — не разовый скрипт, а продукт, признаки (скользящие средние, FFT-полосы, счётчики циклов) должны считаться одинаково в обучении и в инференсе. Расхождение здесь — частая причина «модель в пилоте была гениальной, в проде — бесполезной».

SLA на latency. Классификация письма может ждать 2 секунды. Аварийный сигнал на линии — нет. Для тяжёлых моделей закладывайте каскад: быстрый фильтр правил → лёгкая модель на edge → тяжёлая в облаке только для неясных кейсов.

Пример недельного плана пилота (участок упаковки)

Такой ритм укладывается в один спринт и даёт материал для решения «масштабируем / дорабатываем / останавливаем» без полугодового проекта.

Итог

Автоматизация с AI — это не замена дисциплины инженерии, а её продолжение в зоне неопределённости. Правила держат безопасность и предсказуемость, модели — адаптивность. Пилот без baseline, shadow mode и метрик бизнес-эффекта — театр. Пилот с гибридным контуром, эталонными кейсами и постепенным делегированием — рабочий путь для команд, которые отвечают не за демо, а за простой линии и реальные заявки.