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