У цехового AI потолок надёжности достигается быстрее, чем рассчитывают команды. Копилот оператора должен корректно читать состояние алармов, ссылаться на ID активов, совпадающие с CMMS, и предлагать действия, укладывающиеся в реальный SOP цеха. Разрыв между «впечатляет в питче» и «доверяет диспетчер в щитовой» — это обычно не проблема модели. Это проблема интеграции. Её мы и закрываем.
Операторы сверяют AI-сводку с реальным списком алармов каждый раз, весь первый месяц. Любой дрейф — не та критичность, не то количество, устаревшее состояние — и копилот теряет оператора. Состояние алармов должно читаться из источника, никогда из памяти модели или сводки.
У промышленных активов длинные структурные ID (площадка / линия / ячейка / устройство). Текст LLM, который роняет сегмент или выдумывает полный ID, ломает последующее действие. ID приходят из tool-а активов, никогда из вывода модели.
Инструкция SOP («при скачке температуры в ячейке 3 подтвердить в течение 2 минут») должна находиться не в системном промпте, а в поисковом слое или конечном автомате. Закодированные в промпте SOP хрупки, дороги и молча отказывают при обновлении.
Промышленные CMMS-системы (Maximo, SAP PM, кастомные) — это системы, с которыми должен работать копилот. Screen-scraping или CSV-интеграция выглядит прагматично и становится ненадёжной за квартал. Типизированные границы интеграции остаются стабильными.
Аудит интеграции существующего IIoT-стека — telemetry-historian, CMMS, менеджер алармов — и точки контакта с оператором, которой служит AI
Слой retrieval для знаний SOP и активов — держится вне промпта, версионируется, запрашивается
Типизированные UI-контракты для действий оператора (подтвердить, эскалировать, запланировать задание) — структурированные, а не проза
Eval-harness, следящий за критичными для оператора классами: выдумывание ID, дрейф алармов, неправильное применение SOP
Runbook передачи — команда щитовой самостоятельно эксплуатирует копилот после передачи