Аннотация
Я подготовил и предлагаю к обсуждению методику экспресс‑аудита ИИ‑зрелости промышленного предприятия.
Методика представлена в excel (её можно получить по запросу в мой адрес): вы ставите оценки и указываете доказательства — файл считает остальное.
Каждый из 30 вопросов оценивается по двум измерениям — техническому (Т) и организационному (О). Итоговый уровень определяется по правилу узкого горлышка как минимум из технического (Т) и организационного (О) уровня, подтверждённого 20 гейтами, и ограничения по кибербезопасности ИИ‑контура. Результат аудита — уровень зрелости, разрыв между измерениями, узкое место, степень преодоления пяти барьеров масштабирования, контрольный срок закрытия гейтов и план на 12 месяцев.
Введение
10 августа 1628 года из стокгольмской гавани вышел «Ваза» — корабль, задуманный как самый мощный на Балтике. Его строили около двух лет, и всё это время король Густав II Адольф торопил строителей. Первый же порыв ветра положил его на борт, вода пошла в открытые пушечные порты, и флагман затонул в 120 метрах от берега, на глазах у города.
Самое поучительное в этой истории — не гибель корабля. Испытание на остойчивость всё‑таки провели: тридцать человек бегали от борта к борту по верхней палубе, раскачивая корпус. После третьей пробежки вице‑адмирал Клас Флеминг испытание остановил — корабль раскачивался так, что мог опрокинуться прямо у стенки. Выход в море не отменили: под давлением короля корабль отправили в плавание.
Испытание было. Измерения не было.
Отечественный пример ещё показательнее, потому что в нём нет одной роковой минуты. Есть медленное исчезновение.
Пётр I создал Балтийский флот за два десятилетия — буквально с нуля, на воле одного человека. В 1724 году в его составе числились 32 линейных корабля. Но строили быстро и из того, что было под рукой: корпуса из‑за спешки собирали большей частью из сырого леса. Такие корабли быстро гнили и теряли боеспособность. Пётр умер в 1725 году, и постройка почти остановилась. В 1728 году шведский посланник доносил в Стокгольм, что старые корабли «все гнилы» и в море можно вывести не более четырёх‑пяти. Лишь в 1732 году Анна Иоанновна учредила Воинскую морскую комиссию — фактически для того, чтобы выяснить, какой флот у страны есть на самом деле.
Флот в ведомостях был. Флота в море не было.Система, которая пережила бы своего создателя, так и не была выстроена.
История даёт уроки, которые напрямую относятся к сегодняшнему промышленному ИИ.
Первый урок: испытание без права остановить проект — это техническая процедура, а не измерение состояния. Пилоты запускаются, демонстрации проходят, слайды рисуются. Но запущенный проект тянут до конца: ни на одном этапе жизненного цикла нет процедуры, которая позволила бы без потерь сказать «нет».
Второй урок: «числится» и «боеготово» — разные величины. КПЭ выполнен: пилотов запущено столько‑то, решений «внедрено» столько‑то. А сколько из них работает в цехе каждую смену и приносит подтверждённый бухгалтерией эффект — не знает никто.
Третий урок — самый неудобный: система, которая держится на идеологе, умирает вместе с его уходом. На предприятиях это выглядит так: пришёл новый руководитель — и цифровая трансформация начинается с нуля, под его видение, с новыми подрядчиками и новой вёрсткой презентации. Предыдущие наработки не наследуются.
Нужно измерение — такое, которое можно предъявить, которое переживёт смену руководителя и имеет право сказать «нет». Эта статья — про то, чтобы вместо слов появилось измерение.
1. Почему самодиагностика не работает
Спросите руководителя предприятия, на каком уровне ИИ‑зрелости находится его компания. Почти всегда вы услышите: «Мы в числе лидеров, уже внедряем, всё ок». Этот ответ почти никогда не бывает ложью. Он бывает самооценкой. А у самооценки в теме ИИ есть четыре системных источника завышения.
Источник первый: экономика обещания
Деньги в России дороги и коротки. В таких условиях каждый лишний год ожидания окупаемости обходится предприятию слишком дорого. Деньги выделяют под окупаемость в год‑два. Поэтому её и обещают.
Фактическая картина иная. В глобальном опросе Deloitte (1854 руководителя, 2025) большинство компаний получают приемлемую отдачу от типового ИИ‑сценария только через 24–48 месяцев — при привычных для технологических инвестиций 7–12 месяцах. Окупаемость быстрее года видят лишь 6%. Между обещанием и реальностью возникает разрыв, и заполняет его отчётность: проект, получивший деньги под короткую окупаемость, обязан выглядеть успешным. Самооценка в таких условиях становится частью защиты бюджета.
Источник второй: эффект масштаба наоборот
Интуиция подсказывает: чем крупнее компания, тем больше у неё ресурсов, данных и компетенций — значит, тем выше зрелость. На практике выходит наоборот: чем больше структура, тем ниже доля пилотов, доходящих до эксплуатации.
Исследование MIT NANDA “The GenAI Divide” показало: крупные компании запускают больше всего пилотов генеративного ИИ, но хуже всех переводят их в эксплуатацию. Средние компании проходят путь от пилота до полного внедрения примерно за три месяца, крупные — за девять месяцев и дольше. Каждый дополнительный уровень согласования между пилотом и цехом добавляет месяцы на пути в эксплуатацию.
Источник третий: зрелость подменяется КПЭ
У зрелости есть метрики. Но, в отличие от выработки или простоя, её трудоёмко обосновывать в бизнес‑среде. Поэтому происходит логичное: зрелость замещают тем, что считается легко: число запущенных пилотов, число «внедрённых решений», объём освоенного бюджета. КПЭ выполнен — значит, зрелость растёт.
При этом зрелость — не абстракция, и ошибка в её оценке стоит денег. MIT CISR на выборке из 721 компании показал: предприятия на двух первых стадиях ИИ‑зрелости (а это 62%) имеют финансовые результаты ниже средних по отрасли, на третьей и четвёртой — заметно выше.
Источник четвёртый: честность требует смелости
Выносить сор из избы не хочет никто. Признать, что модель не работает, — значит признать, что деньги потрачены, а сроки сорваны. Там, где за ошибку наказывают, ошибки не исчезают — они перестают попадать в отчёты.
Эми Эдмондсон из Гарварда показала это ещё в 1996 году на больничных бригадах: команды с лучшим руководством и атмосферой фиксировали больше ошибок, а не меньше — не потому что ошибались чаще, а потому что не боялись о них говорить.
Честная самооценка требует либо личной смелости, либо процедуры, которая снимает с человека личный риск. Аудит с доказательствами и есть такая процедура.
Посмотрим на проблему в следующем разрезе: что видно снаружи, откуда это берётся, к чему ведёт и как из этого выйти.
Симптомы. Уровень зрелости приравнивают к выполнению КПЭ и не подтверждают документами. В отчётности фигурируют «внедрённые ИИ‑решения», но ни одно из них нельзя назвать с указанием цеха, смены и оператора. Экономический эффект «оценён экспертно». Причём цифры называют либо технические специалисты, которые за уточнениями отсылают в бухгалтерию, либо топ‑менеджеры, у которых уточнять не принято.
Причины. Финансирование выдаётся под обещание короткой окупаемости, и отчётность обязана это обещание подтверждать. Руководитель оценивает заявление и вложенные усилия, а не результат. Чем крупнее структура, тем дальше тот, кто оценивает, от того, кто работает «на земле».
Последствия. Деньги идут в то, что легче показать: вычислительные мощности при неразмеченных данных, новые пилоты при незакрытом первом. Предприятие годами «замерзает» на одном уровне, ежегодно отчитываясь о прогрессе. А при смене руководителя всё начинается заново. Масштаб явления подтверждают и глобальные оценки: по прогнозу Gartner, не менее 30% проектов генеративного ИИ будут остановлены после пилота к концу 2025 года — из‑за качества данных, недостаточного контроля рисков, растущих затрат и неясной ценности; по данным Deloitte, 68% компаний перевели в промышленную эксплуатацию не более трети своих экспериментов с генеративным ИИ.
Выход. Заменить самооценку измерением, у которого есть право сказать «нет»: фиксированные вопросы, доказательства, гейты, контрольные сроки и выстроенная ритмичность повторных замеров.
Проверить себя можно за минуту, честно ответив на вопросы:
1. Есть ли хотя бы одна модель в промышленной эксплуатации — не в лаборатории и не в пилоте, а в цехе, где оператор работает с ней каждую смену?
2. Есть ли утверждённый регламент запуска ИИ‑пилотов и защищённый бюджет на сопровождение и переобучение моделей на два‑три следующих года?
3. Можете ли вы показать экономический эффект, подтверждённый бухгалтерией, и полную стоимость владения моделью?
Споткнулись хотя бы на одном вопросе или поймали себя на «в целом да, но…»? Тогда пора переходить от ощущений к измерению. Как это сделать — в следующем разделе.
2. Методология аудита
2.1. Объект аудита и основной подход
Объект аудита — предприятие или выделенный производственный контур, в пределах которого существуют общий владелец, единые правила работы с данными, единый ИИ‑ландшафт и единый порядок принятия решений. Отдельный ИИ‑проект оценивается по той же логике, но его результат не переносится автоматически на уровень всего предприятия.
Это разграничение принципиально: единичный удачный проект не делает зрелой всю компанию, а зрелая в целом организация может вести конкретный проект на раннем этапе. Тип объекта фиксируется в рабочей книге и указывается в отчёте рядом с результатом.
Ранее в своих статьях я описывал пять уровней зрелости и чек‑лист восхождения по блокам «Бизнес — Данные — Команда — Инфраструктура — Культура — Процессы». Каждый из 30 вопросов аудита оценивается по двум измерениям:
• техническое состояние (Т) — что физически есть: данные, пайплайны, интеграции, модели в эксплуатации;
• организационное состояние (О) — кто за это отвечает, чем это подтверждено, встроено ли это в процесс и в мотивацию.
Каждый вопрос оценивается от 1 до 5 баллов по шкале из табл. 4, поэтому каждое измерение даёт сумму от 30 до 150 баллов. Суммы не складываются: уровень определяется по каждому измерению отдельно по границам из табл. 1, а итог равен меньшему из двух. Это правило узкого горлышка.
Сильная техника не компенсирует отсутствие владельца, а прекрасный регламент — отсутствие данных.
Таблица 1. Уровни зрелости и границы
Уровень | Баллы (по каждому измерению) | Ключевой признак | Типичная ошибка уровня |
1. Хаос | 30–59 | Отдельные энтузиасты, ИИ вне процессов | Считать красивую презентацию реализованным проектом |
2. Пилотный проект | 60–89 | Есть пилоты, нет промышленной эксплуатации | Путать «пилот запущен» с «пилот показал результат» |
3. Повторяемый процесс | 90–119 | Успех воспроизводится на втором участке | Масштабировать без переобучения под новую среду |
4. Управляемое масштабирование | 120–134 | ИИ в контуре принятия решений, MLOps работает | Пропустить момент, когда сырьё, режим или оборудование изменились, а модель осталась прежней |
5. Трансформирующий | 135–150 | ИИ меняет бизнес‑модель и продукт | Потерять людей и навыки, без которых нельзя поймать ошибку модели |
Источник: здесь и далее методика автора
Разрыв между измерениями — самостоятельный диагноз, и порой он важнее абсолютных баллов. Он считается как разность сумм Т − О; значимым считается расхождение больше 15 баллов в любую сторону (табл. 2).
Для сопоставления с международными моделями: уровни 1 и 2 примерно соответствуют первым двум стадиям модели MIT CISR (“эксперименты и подготовка”, «пилоты и формирование компетенций»), уровни 3 и 4 — третьей стадии («ИИ‑способы работы»), уровень 5 — четвёртой («готовность к будущему с ИИ»).
Отличие предлагаемой модели — в публичности, разделении технического и организационного измерений и в гейтах, которые делают условием перехода на уровень факт, а не балл.
Таблица 2. Что означает разрыв между техническим и организационным состоянием
Разрыв Т − О, баллы | Диагноз | Что произойдёт дальше |
Больше +25 | Технологическое опережение как риск | Сложность решений превышает способность организации к ним адаптироваться: высока вероятность, что проекты не дойдут до эксплуатации |
От +16 до +25 | Техника опережает управление: деньги горят | Модели есть, но их не используют в решениях; эффект не доходит до P&L, пилоты закрываются при смене приоритетов |
От −15 до +15 | Состояния сбалансированы | Рост устойчив, узкое место нужно искать внутри блоков |
Меньше −15 | Управление готово, техника не построена: упущенное время | Регламенты и роли есть, но нет данных и сред: процесс работает вхолостую |
Итоговый уровень проходит ещё два фильтра. Он не может быть выше уровня, подтверждённого гейтами, и выше уровня защищённости ИИ‑контура. Гейты выросли из статьи II: это «главные индикаторы перехода» и пункты чек‑листа восхождения, переписанные как проверяемые факты — «да» или «нет», с документом и фактом использования. Подробно они разобраны в разделе 2.3, полный перечень — в табл. 5.
Формула расчёта итогового уровня:
Итоговый уровень = МИН (уровень по Т; уровень по О; уровень по гейтам; ограничение по кибербезопасности)
Здесь уровень по гейтам — наивысший уровень, для которого закрыты все его гейты и гейты всех предыдущих уровней (раздел 2.3, табл. 5); ограничение по кибербезопасности — уровень защищённости ИИ‑контура (раздел 2.4, табл. 6).
Пример расчёта. Сумма по техническому измерению — 96 баллов (уровень 3), по организационному — 71 балл (уровень 2); разрыв Т − О = +25, то есть техника опережает управление (табл. 2). Все гейты уровня 2 закрыты, но ИИ‑контур не включён в модель угроз, поэтому уровень 3 гейтами не подтверждён: уровень по гейтам — 2. Защищённость ИИ‑контура — 16 баллов по слабейшему измерению (уровень 3). Итоговый уровень = МИН (3; 2; 2; 3) = 2. Даже если организационное измерение вырастет до 95 баллов, итог останется вторым, пока ИИ‑контур не будет включён в модель угроз.
2.2. Шесть блоков вопросов
Ядро методики — шесть блоков по пять вопросов в каждом блоке (табл. 3). Общий смысл каждого балла задаёт шкала (табл. 4), а в рабочей книге у каждого вопроса есть ещё и текстовые якоря для 1, 3 и 5 баллов — отдельно для технического и организационного состояния.
Якоря нужны, чтобы оценка не зависела от настроения оценивающего. Баллы 2 и 4 ставятся, когда состояние находится между описанными. Сумма по блоку составляет от 5 до 25 баллов по каждому измерению; уровень блока определяется по меньшему из двух измерений по границам 5–9, 10–14, 15–19, 20–22 и 23–25 баллов (уровни 1–5). Блок с наименьшим результатом — узкое место, с которого начинается план.
Инструмент бесполезен, если он измеряет только то, что удобно измерять. Поэтому каждый из 30 вопросов помечен барьером, к которому относится (столбец «Барьер» в табл. 3), и файл считает процент преодоления по каждому барьеру отдельно: сумма баллов по привязанным вопросам делится на максимально возможную (число вопросов × 5), и берётся слабейшее из двух измерений.
Таблица 3. Тридцать вопросов аудита и барьеры, к которым они относятся
№ | Вопрос | Барьер |
Блок 1. Бизнес | ||
1.1 | Существует ли формализованная ИИ-стратегия, синхронизированная с бизнес-целями? | Б4. Регуляторика и право Б5. Организация и люди |
1.2 | Кто владеет ИИ-проектом на уровне топ-менеджмента? | Б5. Организация и люди |
1.3 | Как измеряется успех ИИ-проекта? | Б5. Организация и люди |
1.4 | Выделен ли бюджет на масштабирование и сопровождение (MLOps)? | Б5. Организация и люди |
1.5 | Есть ли ранжированный реестр ИИ-задач по ROI и доступности данных? | Б4. Регуляторика и право Б5. Организация и люди |
Блок 2. Данные | ||
2.1 | Налажен ли автоматический сбор данных с оборудования? | Б1. Данные |
2.2 | Есть ли верифицированный датасет (golden dataset)? | Б1. Данные Б2. Уникальность сред |
2.3 | Создан ли единый корпоративный репозиторий данных? | Б1. Данные |
2.4 | Внедрён ли пайплайн автоматического обновления данных? | Б1. Данные Б2. Уникальность сред |
2.5 | Используются ли данные как конкурентное преимущество? | Б1. Данные |
Блок 3. Команда | ||
3.1 | Есть ли в команде представитель производства (технолог, оператор)? | Б5. Организация и люди |
3.2 | Внедрена ли роль «продакт-менеджера ИИ»? | Б5. Организация и люди |
3.3 | Создана ли постоянная команда MLOps (собственная или на основе аутсорсинга)? | Б5. Организация и люди |
3.4 | Проводятся ли семинары и обучение для операторов и менеджеров? | Б5. Организация и люди |
3.5 | Создан ли совет по ИИ при первом руководителе? | Б5. Организация и люди |
Блок 4. Инфраструктура | ||
4.1 | Определены ли требования к среде (локально/облако, GPU)? | Б3. Инфраструктура |
4.2 | Реализована ли интеграция с MES/SCADA на уровне API? | Б2. Уникальность сред Б3. Инфраструктура |
4.3 | Создан ли контур промышленной эксплуатации? | Б2. Уникальность сред Б3. Инфраструктура |
4.4 | Обеспечен ли переход на программно-определяемую архитектуру? | Б3. Инфраструктура |
4.5 | Обеспечена ли интеграция с поставщиками и клиентами? | Б3. Инфраструктура |
Блок 5. Культура | ||
5.1 | Как сотрудники относятся к ИИ? | Б5. Организация и люди |
5.2 | Фиксируются ли корректировки операторов? | Б5. Организация и люди |
5.3 | Включён ли руководитель производства в статусы по ИИ? | Б5. Организация и люди |
5.4 | Премируются ли сотрудники за рост экспертизы? | Б5. Организация и люди |
5.5 | Является ли ИИ частью корпоративной ДНК? | Б5. Организация и люди |
Блок 6. Процессы | ||
6.1 | Описан ли типовой процесс запуска пилота? | Б2. Уникальность сред |
6.2 | Разработана ли процедура отката к ручному управлению? | Б4. Регуляторика и право |
6.3 | Внедрён ли MLOps-пайплайн? | Б2. Уникальность сред |
6.4 | Встроен ли ИИ в непрерывные улучшения? | Б2. Уникальность сред |
6.5 | Участвует ли компания в разработке отраслевых стандартов по ИИ или применяет признанные стандарты? | Б4. Регуляторика и право |
Один вопрос может связываться с двумя барьерами. Это не двойной счёт, а разные проекции одного дефицита. От 80% барьер считается преодолённым, 60–79% — преодолевается и требует контроля, ниже 60% — не преодолён. Для последнего случая расчёт прямо называет переход, который барьер блокирует: Б1 «Данные» — переход 1→2, Б2 «Уникальность сред» — 2→3 и 3→4, Б3 «Инфраструктура» — 3→4, Б4 «Регуляторика и право» — 4→5, Б5 «Организация и люди» — все переходы.
Таблица 4. Шкала оценки
Балл | Состояние признака |
1 | Полное отсутствие признака |
2 | Начальная стадия: энтузиасты, ручной труд |
3 | Стандартизация: регламенты, системный подход |
4 | Масштабирование: интеграция в бизнес-процессы, MLOps |
5 | ИИ в ДНК компании: конкурентное преимущество, трансформация бизнес-модели |
2.3. Четыре предохранителя против самообмана
Анкета самооценки систематически завышает результат, поэтому в инструмент встроены четыре ограничителя.
Доказательство и факт использования. Оценка выше трёх баллов требует двух вещей: реквизитов документа или системы и подтверждения того, что документ работает. Не «у нас хорошо с данными», а «регламент №…, журнал обновления данных за последний квартал». Документ, который существует, но не применяется, балл выше трёх не даёт. Если доказательство не указано или факт использования не подтверждён, файл сам возвращает балл к трём.
«Неприменимо» — не больше одного раза в блоке. Часть вопросов на отдельных производствах действительно не имеет смысла. Отметка «Н/П» исключает вопрос из расчёта, а сумма пересчитывается к шкале 150: сумма / число учтённых вопросов × 30. Это честнее искусственной единицы и снимает возражение «у нас другая специфика». Но «Н/П» легко превращается в способ убрать неудобный вопрос, поэтому в каждом блоке допускается не более одной такой отметки. При превышении результат помечается как предварительный.
Гейты. Гейт — это факт, а не балл. На каждый отвечают «да» или «нет», с реквизитами доказательства и фактом использования; всего гейтов 20, они распределены по уровням 2–5 (табл. 5). Очевидно, что для уровня 1 гейтов нет. Пока не выполнены все гейты уровня и всех предыдущих уровней, уровень не подтверждается, какими бы высокими ни были оценки. Предприятие, набравшее баллы на уровень 4, но не закрывшее один гейт уровня 4, получает 3.
Таблица 5. Двадцать гейтов подтверждения уровня
Уровень | Гейт: что должно быть фактически | Чем подтверждается |
2. Пилотный проект | Завершён хотя бы один пилот с измеренным результатом (не демонстрация) | Протокол испытаний, акт, отчёт с цифрами |
2. Пилотный проект | У ИИ‑направления есть назначенный владелец на уровне топ‑менеджмента | Приказ о назначении |
2. Пилотный проект | Определены исполнитель и бюджет разметки данных: кто размечает, сколько это стоит, сколько занимает | Смета, договор или наряд на разметку |
3. Повторяемый процесс | Действует регламент пилотирования: как задача попадает в работу и как закрывается | Утверждённый регламент |
3. Повторяемый процесс | Существует ранжированный реестр ИИ‑задач (5 и более) с приоритетами | Реестр с датами обновления |
3. Повторяемый процесс | Есть верифицированный эталонный датасет (golden dataset) и шаблон разметки | Датасет и инструкция по разметке |
3. Повторяемый процесс | ИИ‑контур включён в модель угроз и согласован со службой ИБ | Модель угроз, согласование ИБ |
3. Повторяемый процесс | Определено, где обрабатываются промышленные данные, и соблюдён запрет на публичные ИИ‑сервисы | Регламент обработки, решение по контуру |
4. Управляемое масштабирование | Не менее 3 моделей работают в промышленной эксплуатации | Журнал эксплуатации, мониторинг |
4. Управляемое масштабирование | Есть функция MLOps (собственная, аутсорсинговая или консорциумная) и защищённый годовой бюджет на сопровождение | Штатное расписание или договор, бюджет |
4. Управляемое масштабирование | Prod‑среда отделена от dev, откат протестирован на учениях | Схема сред, протокол учений |
4. Управляемое масштабирование | Проведена проверка модели на устойчивость (отравление данных, состязательные входы) | Отчёт о тестировании |
4. Управляемое масштабирование | Решения модели журналируются, ручной откат на прежний алгоритм протестирован | Журнал решений, протокол учений |
4. Управляемое масштабирование | Модель воспроизведена не менее чем на втором участке или линии с подтверждённым результатом | Протокол со второго объекта |
4. Управляемое масштабирование | Есть процедура переобучения при смене сырья, режима или оборудования; дрейф контролируется | Регламент переобучения, журнал дрейфа |
4. Управляемое масштабирование | Юридически определена ответственность за решение ИИ‑системы: разработчик, владелец, оператор | Заключение юридической службы, регламент |
5. Трансформирующий | Бизнес‑модель, продуктовый портфель или операционная модель изменены под влиянием ИИ, эффект подтверждён | Решение совета директоров или стратегия, управленческая отчётность |
5. Трансформирующий | Предприятие участвует в отраслевой стандартизации по ИИ или документированно применяет признанные национальные и отраслевые стандарты | Состав рабочей группы или перечень применяемых стандартов |
5. Трансформирующий | Назначен руководитель направления данных и ИИ (не обязательно в должности CDAO) с полномочиями и бюджетом | Приказ, положение о функции, бюджет |
5. Трансформирующий | Изменения алгоритмов, влияющих на управление, проходят согласование и обоснование безопасности | Порядок согласования изменений |
Гейты уровня 5 сформулированы функционально, а не через названия должностей и статусы: отсутствие должности CDAO или места в отраслевой рабочей группе не означает, что предприятие не способно системно использовать ИИ. Важно, есть ли у функции данных и ИИ полномочия и бюджет и опирается ли предприятие на признанные стандарты.
Контрольный срок: право сказать «нет». Гейты не только понижают уровень — они задают ритм решений. Если ключевые гейты целевого уровня не закрыты в установленный для проекта контрольный срок, проект выносится на стратегический пересмотр. Базовый ориентир — 12 месяцев с даты аудита; для критических, капиталоёмких и регулируемых контуров срок устанавливается паспортом проекта, потому что закупки, интеграции и допуски в эксплуатацию могут занимать больше года. Решение о продолжении, изменении масштаба или остановке принимает уполномоченный коллегиальный орган с участием владельца бизнеса, производства, ИБ и финансовой функции.
2.4. Кибербезопасность
В промышленности цена ИИ‑инцидента измеряется не точностью модели, а остановленной линией. И безопасность нельзя усреднять: если она провалена, высокие баллы по остальным блокам не компенсируют провал.
Поэтому безопасность работает как ограничитель: блок из пяти вопросов, все вопросы обязательны (табл. 6). По каждому измерению сумма составляет от 5 до 25 баллов; уровень защищённости определяется по тем же границам, что и уровень блока (5–9 — уровень 1, 10–14 — 2, 15–19 — 3, 20–22 — 4, 23–25 — 5), берётся по слабейшему измерению и ограничивает итоговый уровень сверху. Защищённость на уровне 2 означает итоговый уровень не выше 2 — при любой сумме по остальным блокам.
Защищённость — не отдельная тема, а свойство всего ИИ‑контура, поэтому её оценивает та же рабочая группа в том же проходе и по тем же правилам: якоря для 1, 3 и 5 баллов, два измерения, доказательство и факт использования. Отличие одно — отметка «Н/П» здесь не допускается: у промышленного ИИ‑контура не бывает неприменимой безопасности. Для третьего уровня нужна модель угроз (гейты уровня 3 в табл. 5), для четвёртого — отчёт о проверке модели на атаки и журнал решений, по которому можно разобрать любой сбой и вернуться к ручному управлению.
Таблица 6. Вопросы блока «Кибербезопасность ИИ‑контура»
№ | Тема | Вопрос |
К.1 | Данные и модели | Защищены ли обучающие данные, веса и артефакты моделей от несанкционированного доступа и подмены? |
К.2 | Устойчивость модели | Проверяется ли модель на отравление данных, состязательные входы и промпт‑инъекции (для языковых моделей)? |
К.3 | Сегментация ИИ‑контура | Отделён ли ИИ‑контур от технологической сети АСУ ТП и исключено ли управляющее воздействие без подтверждения? |
К.4 | Поставщики и открытый код | Контролируются ли сторонние модели, веса, библиотеки и внешние API, используемые в ИИ‑решениях? |
К.5 | Инциденты и регуляторика | Есть ли реакция на инциденты с ИИ и выполняются ли требования к значимым объектам КИИ (журналирование, отчётность)? |
Роль службы ИБ. Служба ИБ — обязательный участник аудита и совладелец оценки киберрисков, а не внешний контролёр. Право ограничить переход на следующий уровень действует только при документированном несоответствии критическим требованиям безопасности.
2.5. Перспективные треки развития настоящей модели
Модель в нынешнем виде — рабочий инструмент, но не законченный. Ниже несколько направлений, в которых она будет развиваться.
2.5.1. Экономическая устойчивость ИИ‑контура
Зрелость может выглядеть высокой: данные есть, команда собрана, пилоты идут, инфраструктура развёрнута. А решение при этом остаётся экономически неустойчивым. Эффект постепенно съедают inference, переобучение, разметка, сопровождение, MLOps и человеческая проверка результатов. По отдельности каждая статья выглядит разумно, а все вместе они делают модель убыточной.
Зрелость отвечает на вопрос «способны ли мы». Экономика отвечает на другой вопрос: «можем ли мы себе это позволить». Это разные измерения, и смешивать их в одном балле нельзя. Поэтому экономический блок не будет прибавляться к шкале зрелости. Он станет отдельным статусом рядом с итоговым уровнем. Высокий уровень при неподтверждённой экономике — не повод для гордости, а сигнал: масштабирование без экономического обоснования.
2.5.2. Уровень согласия в рабочей группе
Сейчас по каждому вопросу фиксируется одна оценка. Но одна и та же «тройка» может означать разное: либо рабочая группа сразу сошлась на ней, либо оценки разошлись от двух до пяти. Цифра этих ситуаций не различает.
Поэтому в анкету предлагается добавить графу «Уровень согласия» — низкий, средний или высокий. Вопросы с низким согласием показывают, с чего начинать разбор после аудита. А если согласие по вопросу систематически низкое на разных предприятиях, значит, нужно переписать якоря.
2.5.3. Сравнение с лидерами или отраслевыми бенчмарками
Распределение предприятий по уровням в рабочей книге — экспертная оценка автора, а не результат накопленных аудитов. Отраслевое распределение предприятий по уровням и лист «Бенчмарк» появятся в рабочей книге по мере накопления аудитов.
Сравнивать металлургический комбинат с разработчиком промышленного ПО — некорректно. Цифры будут, смысла не будет. Когда наберётся достаточная отраслевая выборка, предприятие сможет сравнить свой уровень с предприятиями своей отрасли.
2.5.4. Управление программой проектов
Сейчас методика оценивает один объект: предприятие, контур или проект. Но на реальном предприятии ИИ редко живёт одним проектом. Обычно идёт сразу пять, десять или двадцать инициатив. Они находятся на разных уровнях, у разных владельцев, с разными подрядчиками и бюджетами. Каждая по отдельности может выглядеть прилично, а в систему они не складываются.
Это знакомая картина из петровского флота: кораблей в ведомости много, эскадры нет. Пилоты конкурируют за одних и тех же специалистов по данным. Каждый собирает свой датасет и строит свою инфраструктуру. Каждый отчитывается своим КПЭ. Сумма проектов оказывается дороже и слабее, чем могла бы быть.
Поэтому следующий шаг развития модели — уровень программы. Он не заменяет оценку проекта, а надстраивается над ней.
И, конечно, программа — не среднее арифметическое. Два проекта на уровне 4 и восемь на уровне 1 дают «среднюю двойку», за которой нет ни одного реального состояния. Программу характеризуют распределение проектов по уровням, доля закрытых в срок гейтов и скорость перевода пилотов в эксплуатацию.
3. Как провести аудит и что делать с результатом
3.1. Порядок работы
Аудит проводит рабочая группа. Минимальный состав и роли:
• владелец ИИ‑направления — ведёт процесс и отвечает за сбор доказательств;
• представитель производства (технолог или начальник цеха) — проверяет, как вопросы выглядят «на земле»;
• специалист АСУ ТП или ИТ — технические вопросы и интеграция;
• представитель службы ИБ — обязательный участник и совладелец оценки киберрисков;
• представитель финансовой службы — подтверждает экономический эффект и стоимость сопровождения моделей;
• представитель юридической службы — вопросы ответственности и регуляторики.
Механика работы следующая: сначала подготовка, затем оценки, затем результат и план.
По шагам в рабочей книге это выглядит так:
1. Заранее соберите фактуру: приказы, регламенты, журналы эксплуатации, акты. Именно это делает процесс реальным: за столом группа оценивает, а не «ищет документы в собственных телефонах».
2. Лист «Итог»: укажите объект и тип объекта аудита.
3. Лист «Аудит (60)»: 30 вопросов (60 оценок) с доказательствами и фактом использования. Оценки ставятся по якорям, а не по ощущению; спорные вопросы получают меньший из предложенных баллов.
4. Лист «Кибербез (5)»: пять вопросов в двух измерениях.
5. Лист «Гейты»: 20 ответов «да/нет» с доказательствами.
6. Лист «Итог»: уровень по баллам, по гейтам и по безопасности, итоговый уровень, разрыв Т − О, профиль по блокам, узкое место. Листы «Барьеры» и «План»: слабейший барьер и план на 12 месяцев с ответственными и сроками.
7. Лист «Паспорт и сроки»: класс контура (стандартный или критический, по паспорту проекта) и контрольный срок закрытия гейтов.
8. Лист «Динамика»: зафиксируйте дату — это нулевая точка, к которой вы вернётесь через квартал или полгода, в зависимости от скорости ваших бизнес‑процессов.
Что даёт рабочая книга на выходе
• два числа — техническое и организационное состояние — и разрыв между ними;
• итоговый уровень зрелости с учётом гейтов и ограничения по кибербезопасности;
• узкое место — блок с наименьшим результатом, то есть точку приложения «первого рубля»;
• процент преодоления по каждому из пяти барьеров и блокируемый переход;
• контрольную дату закрытия гейтов и статус проекта;
• план на 12 месяцев: приоритет по величине разрыва, ответственный, срок;
• динамику: повторный аудит через квартал или полгода в тех же полях.
3.2. Что делать "в понедельник"
Инструмент не имеет ценности, если после него не меняется ни одно решение.
Три шага, ни один из них не требует отдельного бюджета и множественных циклов согласований.
Шаг первый: получить цифру и не спорить с ней. Провести аудит с доказательствами и зафиксировать дату. Первая цифра почти всегда ниже ожидаемой. Это не ошибка методики, а её назначение.
Шаг второй: закрыть не самое слабое, а самое блокирующее. Соблазн — улучшать то, что и так неплохо: это быстрее и красивее в отчёте. Правильная логика противоположна: первым закрывается барьер, который блокирует ближайший переход. Если барьер данных преодолён меньше чем наполовину, любые инвестиции в вычислительные мощности — это пушки для корабля без балласта.
Шаг третий: сделать гейты условием финансирования. Следующий транш на ИИ‑проект выделяется только при закрытых гейтах текущего уровня. Если к контрольной дате гейты не закрыты, проект выносится на стратегический пересмотр коллегиальным органом: продолжить, изменить масштаб или остановить. Гейты становятся не только диагностическим, но и финансовым фильтром.
Так измерение становится системой, которая переживёт смену руководителя.
3.3. Ограничения методики и план валидации
Методика не лишена ограничений, и их важно проговорить.
Во‑первых, аудит по‑прежнему остаётся самооценкой. Доказательства и гейты сужают пространство для завышения, но не устраняют его: документ может существовать формально, а решение рабочей группы — зависеть от того, кто в ней старший по должности.
Во‑вторых, границы уровней, пороги блоков, перечень гейтов откалиброваны экспертно — на опыте автора и предложенной им модели.
В‑третьих, все вопросы имеют равный вес. Отраслевые поправки в рабочей книге справочные и в расчёт уровня не входят.
В‑четвёртых, отсутствует межотраслевая калибровка. Результаты предприятий разных отраслей без калибровки сопоставляются с осторожностью.
В‑пятых, связь итогового уровня с внешними результатами пока не проверена — ни на доле моделей в эксплуатации, ни на подтверждённом эффекте, ни на выживаемости проектов после смены руководства.
Проверка надёжности и валидности — следующий шаг развития методики.
Инструмент не заменяет технический аудит данных и моделей и инвестиционный анализ проекта: он показывает, нужны ли они и с чего начать. Ценность модели в том, что это открытый и прозрачный инструмент расчёта: при небольшой настройке он позволяет измерять и другие трансформационные процессы, вызванные внедрением новых технологий.
Заключение: измерение важнее уверенности
«Вазу» подняли со дна в 1961 году, через 333 года. Сегодня он стоит в Стокгольме — самое дорогое в истории напоминание о том, что испытание без права остановить проект — это не испытание, а ритуал.
Петровский флот восстановили не энтузиазмом одного человека, а комиссией, штатами и регулярной работой. Систему пришлось строить после того, как её отсутствие стало очевидным. Дороже и позже, чем могло бы быть.
Промышленный ИИ сегодня проходит ту же фазу. Измерение становится системой тогда, когда у него есть доказательства, бюджет, безопасность, понимание экономики и дата, к которой нужно принять решение о продолжении. Без этого методика остаётся диагностикой. С этим — превращается в управленческий контур, который работает независимо от того, кто именно возглавляет предприятие в данный момент.
Ответьте на вопросы честно. Лучший результат этой статьи — одно неудобное число и один закрытый гейт. С этого места уже можно строить.
Если нужен взгляд со стороны — приходите. Проведём экспресс‑аудит текущей зрелости вместе с вашей рабочей группой, соберём доказательную базу, найдём барьер, который держит вас на текущем уровне и составим план, который переживёт смену руководителя.
Рабочую книгу Excel можно получить по запросу в мой адрес.
