--- md_version: 2 title: "Промышленный ИИ: 12 вопросов поставщику до пилота" description: "Чек-лист для проверки промышленного ИИ: задача, данные, редкие режимы, интеграция, безопасность, сопровождение и экономика." canonical: "https://tesstech.ru/blog/promyshlennyy-ii-12-voprosov-postavshchiku/" markdown: "https://tesstech.ru/blog/promyshlennyy-ii-12-voprosov-postavshchiku/index.md" published: "2026-08-29" author: "TESS Technology" organization: "ООО ТЕСС ТЕХНОЛОДЖИ" language: "ru-RU" category: "Технологии и AI" direction: "technology-ai" tags: ["Промышленный ИИ","Пилот","Производство","Технологический аудит"] image: "https://tesstech.ru/upload/articles/september-2026/0109_5.webp" related_service: title: "Системная ИИ-трансформация" url: "https://tesstech.ru/services/ai-transformation/" related_articles: - title: "Цифровой двойник: когда он помогает производству" url: "https://tesstech.ru/blog/tsifrovoy-dvoynik-kogda-pomogaet-proizvodstvu/" markdown: "https://tesstech.ru/blog/tsifrovoy-dvoynik-kogda-pomogaet-proizvodstvu/index.md" - title: "Почему корпоративный ИИ не знает ваш бизнес" url: "https://tesstech.ru/blog/pochemu-korporativnyy-ii-ne-znaet-vash-biznes/" markdown: "https://tesstech.ru/blog/pochemu-korporativnyy-ii-ne-znaet-vash-biznes/index.md" - title: "ИИ-агент в CRM: как ограничить доступ до инцидента" url: "https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/" markdown: "https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/index.md" sources: - "https://www.nist.gov/ai-measurement-and-evaluation" - "https://airc.nist.gov/airmf-resources/airmf/5-sec-core/" - "https://www.iso.org/standard/56847.html" --- # Промышленный ИИ: 12 вопросов поставщику до пилота На стенде промышленный ИИ почти всегда работает убедительно. Данные подготовлены, оборудование запущено в знакомом режиме, а специалист поставщика знает, какой сценарий показать. В цехе все грубее: меняется сырье, пропадают сигналы, случаются редкие режимы, а отвечать за решение нужно до конца смены. Точность модели на презентации отвечает лишь на часть вопросов. До пилота стоит проверить весь контур: производственную задачу, данные, реакцию пользователя, эксплуатацию и экономику. Ниже — двенадцать вопросов, после которых демо становится предметным разговором о результате. ## 1. Какое решение изменится благодаря системе? «Предсказывать дефект» — это способность. Бизнес-задача звучит конкретнее: предупредить оператора до необратимой операции, отправить изделие на дополнительный контроль, изменить режим или запланировать обслуживание. Если сигнал не встроен в решение, компания получает еще один экран. Попросите поставщика показать, кто, когда и на основании чего действует после прогноза. ## 2. Как выглядит единица результата? Это может быть изделие, партия, цикл оборудования, событие простоя или подтвержденная аномалия. Для единицы задают правильный исход и цену ошибок двух типов: пропущенной проблемы и ложной тревоги. Средняя точность без структуры ошибок мало полезна. На производстве последствия несимметричны. ## 3. На каких данных получен результат? Важно знать период, линии, режимы, сырье, долю редких событий и правила разметки. Тест на одной линии не доказывает переносимость на другую. Данные после ремонта или смены рецептуры могут иметь другое распределение. Попросите разделить обучающую, настроечную и контрольную выборки и объяснить, как исключено попадание близких случаев в разные части. ## 4. Что происходит при пропуске или запаздывании сигнала? В реальном контуре датчик может не передать значение, метка времени — сместиться, а сеть — задержать пакет. Система должна различать норму и отсутствие данных. Нужны правила деградации: продолжить с меньшей уверенностью, перейти на резервный признак или отключить рекомендацию. ## 5. Как решение работает на редких режимах? Пуск, остановка, переналадка, малые партии и аварийные состояния часто исключаются из красивой выборки. Именно там поведение может быть наиболее важным. Поставщик должен показать покрытие режимов и явные границы применимости. Ответ «модель сама разберется» не заменяет перечень проверенных условий. ## 6. Как результат попадет в работу смены? Сигнал должен появиться в понятном месте и вовремя. Уточните, нужна ли интеграция с MES, SCADA, системой качества или обслуживанием; кто подтверждает событие; как фиксируется причина отклонения и можно ли продолжить работу при недоступности ИИ. Отдельный интерфейс может быть оправдан в пилоте. В эксплуатации он часто создает параллельный процесс. ## 7. Что оператор увидит вместе с рекомендацией? Пользователю нужны объект, время, уверенность, ключевые признаки, допустимое действие и способ сообщить об ошибке. Избыточное объяснение мешает так же, как непрозрачный сигнал. Спросите операторов, какое решение они реально могут принять в доступное окно времени. ## 8. Как измеряется эффект на производстве? Метрика модели связывается с простоем, браком, выпуском, энергией, временем переналадки или трудоемкостью контроля. Нужна базовая линия и сопоставимый период. Условный пример: система раньше обнаруживает отклонение, но оператор не может вмешаться до конца цикла. Техническая метрика улучшилась, а производственный результат — нет. Значит, надо менять точку решения или процесс реакции. ## 9. Как контролируется изменение условий? После запуска меняются оборудование, рецептуры, поставщики сырья и способы маркировки. Решение должно отслеживать качество входных данных и фактический результат. Нужны пороги, после которых модель переводится в режим наблюдения или отправляется на пересмотр. Спросите, кто имеет право одобрить новую версию и можно ли вернуться к предыдущей. ## 10. Кто сопровождает систему через год? На пилоте рядом команда разработчика. В эксплуатации должны быть определены первая линия поддержки, владелец данных, ответственный инженер, порядок разбора ложных тревог, резервирование и сроки восстановления. Если для любой корректировки нужен автор модели, стоимость владения и зависимость от поставщика будут расти. ## 11. Какие права и данные получает решение? Промышленный ИИ может читать технологические параметры, архивы качества и данные оборудования, а иногда отправлять команды. Для каждого интерфейса нужны минимальные права, сегментация, журнал и безопасное состояние при отказе. Автоматическое управление требует отдельного уровня доказательств. Успешная рекомендательная система не становится замкнутым контуром управления одним изменением настройки. ## 12. Как устроена экономика полного цикла? В расчет включают обследование, датчики и связь, хранение, интеграции, разметку, вычисления, интерфейсы, обучение, поддержку и пересмотр моделей. Отдельно считают стоимость остановки и участия специалистов предприятия. Пилот должен отвечать на заранее заданное решение: масштабировать, доработать конкретный узел или остановить. Если критерии успеха появляются после результата, эксперимент легко объявить успешным при любом исходе. ## Как организовать независимую проверку Сначала зафиксируйте задачу и базовую линию без поставщика. Затем дайте нескольким решениям один набор случаев и одинаковые ограничения. Проверяйте не только среднюю метрику, но и режимы, пропуски данных, скорость реакции, работу интерфейса и восстановление после сбоя. Полезен теневой режим: система делает прогнозы, но не влияет на производство. Команда сравнивает их с фактическими событиями и оценивает, было ли у пользователя время и право действовать. После этого можно переходить к ограниченной рекомендации на одной линии. В протоколе пилота заранее фиксируют владельца результата, период, объем, критерии остановки, формат данных и права сторон на разработанные компоненты. Это снижает риск бесконечной доработки без управленческого решения. ## Что должно быть понятно после разговора После двенадцати вопросов у команды должно остаться не общее впечатление от модели, а границы пилота: какой результат меняется, на каких данных, в каких режимах, кто реагирует на сигнал и сколько стоит весь контур. Если на эти вопросы пока нет ответа, рано обсуждать масштабирование. Связанные разборы: [как проверить цифровой двойник производства](https://tesstech.ru/blog/tsifrovoy-dvoynik-kogda-pomogaet-proizvodstvu/) и [зачем проверять AI-модели до внедрения](https://tesstech.ru/blog/r-d-ai-resheniy-zachem-biznesu-proveryat-modeli-do-vnedreniya/). ## Проверенные источники - [NIST: измерение и оценка AI-систем](https://www.nist.gov/ai-measurement-and-evaluation) - [NIST AI RMF Core: тестирование, оценка, верификация и валидация](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) - [ISO 22400-1: показатели производственных операций](https://www.iso.org/standard/56847.html) ## Услуга по теме [Системная ИИ-трансформация](https://tesstech.ru/services/ai-transformation/) — Находим процессы, где ИИ дает измеримый результат, и сопровождаем пилот до внедрения. ## Материалы по теме - [Цифровой двойник: когда он помогает производству](https://tesstech.ru/blog/tsifrovoy-dvoynik-kogda-pomogaet-proizvodstvu/index.md) - [Почему корпоративный ИИ не знает ваш бизнес](https://tesstech.ru/blog/pochemu-korporativnyy-ii-ne-znaet-vash-biznes/index.md) - [ИИ-агент в CRM: как ограничить доступ до инцидента](https://tesstech.ru/blog/ii-agent-v-crm-kak-ogranichit-dostup/index.md)