Ссылка на оригинал

ИИ в АСУ ТП — круто. Осталось сделать так, чтобы он ничего не сломал

В декабре 2025 года CISA и австралийский ACSC совместно с центром безопасности искусственного интеллекта NSA (NSA AISC), FBI, канадским Cyber Centre, немецким BSI и национальными центрами кибербезопасности Нидерландов, Новой Зеландии и Великобритании выпустили документ Principles for the Secure Integration of Artificial Intelligence in Operational Technology.

Документ посвящён вопросу о том, что делать, если искусственный интеллект начинает появляться не в очередном чат-боте для отдела продаж, а рядом с промышленной автоматизацией, SCADA, контроллерами, технологическими защитами и процессами, где ошибка программы иногда заканчивается не сообщением «что-то пошло не так», а вполне физическими последствиями.

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

Если совсем коротко, то главная мысль документа примерно такая:

Чем ближе ИИ находится к управлению физическим процессом, тем меньше ему можно верить на слово и тем важнее понимать, что произойдёт, когда он ошибётся. Причём не «если», а именно «когда».

Нужен ли вообще здесь ИИ

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

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

Перед внедрением предлагается сравнить ИИ с обычными, уже проверенными решениями и посмотреть на:

  • точность и производительность;
  • сложность;
  • стоимость;
  • влияние на функциональную безопасность;
  • новые сетевые связи;
  • требования к данным;
  • способность организации сопровождать такую систему годами.

То есть если задачу нормально решает детерминированный алгоритм, то заменить его нейросетью только ради красивого слайда «мы внедрили ИИ» — вообще не технологический прогресс, а скорее просто новый способ добавить в систему ещё несколько неизвестных состояний отказа.

В документе приводится вымышленный пример оценки возможности использовать ИИ для прогнозного технического обслуживания промышленного генератора. В нём формулируются проблема, цель и риск, определяются заинтересованные стороны, требования к данным, производительности, безопасности и сети, а также показатели успеха. Такая оценка нужна до выбора технологии, чтобы понять, действительно ли ИИ подходит для задачи лучше уже проверенных решений.

Чем ближе к железу, тем веселее

Авторы раскладывают возможные применения ИИ по модели Purdue.

На нижних уровнях — рядом с датчиками, контроллерами и технологическим процессом — преимущественно используются предиктивные модели машинного обучения. Например, для обнаружения аномалий, прогнозирования состояния оборудования, обработки телеметрии и поддержки оператора. Большие языковые модели и ИИ-агенты предполагается в основном держать выше, в корпоративном контуре, где они работают с данными, уже выведенными из технологической сети.

Это важное разделение: на корпоративном уровне результат модели обычно можно проверить до передачи в технологический контур. На нижних уровнях, особенно при участии ИИ в локальном управлении, ошибка может непосредственно повлиять на физический процесс. Поэтому документ довольно осторожно относится к активному управлению со стороны ИИ и рекомендует ограничивать такие сценарии, особенно без участия человека.

Иными словами, идея дать языковой модели доступ в систему управления OT-процессом, потому что она хорошо понимает естественный язык, пока остаётся примерно на том же уровне инженерной зрелости, что и пароль admin/admin на внешнем интерфейсе.

Корм для модели

Следующая проблема — это данные АСУ ТП.

Для промышленного ИИ нужны телеметрия, архивы, события, конфигурации, технологические схемы, журналы обслуживания, данные о режимах работы и много чего ещё. Документ отдельно делит данные на две категории.

  1. Инженерные данные:
  • сетевые схемы;
  • перечни оборудования;
  • логические схемы;
  • последовательности технологических операций;
  • сведения о защитах;
  • документация по безопасности.

Такие данные и без всякого ИИ представляют большую ценность для атакующего. Если отдать их внешнему поставщику модели, загрузить в облако или начать использовать в плохо контролируемой цепочке обучения, поверхность атаки становится шире.

  1. Технологическая телеметрия:
  • напряжения;
  • токи;
  • температуры;
  • давления;
  • расходы;
  • частота;
  • вибрация.

Эти значения, как правило, недолговечны, однако если на них обучается или дообучается модель, данные получают вторую жизнь. То есть если появляется ещё одно место, куда эти данные отправляются и где хранятся, то оно, соответственно, тоже должно быть защищено.

Внедрение ИИ меняет не только способы обработки данных, но и их жизненный цикл. Раньше измерение температуры могло быть просто точкой в архиве. Теперь оно может оказаться частью набора для обучения, копией у подрядчика, входом в удалённую службу и статистическим следом в модели.

Плохие данные

Классическое машинное обучение любит фразу «мусор на входе — мусор на выходе». В АСУ ТП мусор на выходе иногда влияет на реальное оборудование. Документ отдельно рассматривает проблемы качества данных, отравления данных и дрейфа модели.

То есть если промышленный объект меняется (оборудование стареет, режимы перестраиваются, появляются новые уставки, меняется сырьё, ремонтируются агрегаты, модернизируются системы управления), то модель, обученная два года назад, может продолжать выдавать сверхточный результат с шестью знаками после запятой. Просто этот результат уже будет всё хуже соответствовать реальности.

Получается несколько сценариев с похожим итогом:

  • данные намеренно подменили → неправильный результат;

  • процесс постепенно изменился → неправильный результат;

  • модель не видела редкий аварийный режим → неправильный результат.

В первом случае это инцидент кибербезопасности. Во втором — эксплуатационная проблема. В третьем — проблема качества модели и полноты испытаний. Но оператору и технологическому процессу, в общем-то, всё равно, как именно назывался отдел, который должен был это предотвратить, так как результат один: система выдала неправильную рекомендацию или неправильное управляющее воздействие. Получается, безопасность ИИ, кибербезопасность и эксплуатационная надёжность начинают постепенно сливаться в одну инженерную задачу.

Производители

Отдельный раздел документа посвящён поставщикам оборудования, что как будто бы особенно актуальная история на ближайшие годы. В документе говорится, что некоторые OT-устройства уже поставляются со встроенным ИИ, а возможности таких устройств будут становиться всё более сложными. На практике это означает, что ИИ не обязательно появится на объекте как отдельный проект с торжественным запуском, бюджетом и табличкой «AI». Он вполне может приехать с очередным обновлением или в составе:

  • SCADA;
  • инженерного программного обеспечения;
  • средства диагностики;
  • интеллектуального устройства;
  • облачной системы мониторинга;
  • новой прошивки оборудования.

И тогда возникают довольно практичные вопросы.

  • Что за модель там используется?
  • Где она выполняется?
  • Нужно ли устройству постоянное соединение с интернетом?
  • Куда уходят технологические данные?
  • Использует ли производитель их для обучения своих моделей?
  • Что произойдёт, если удалённая служба станет недоступна?
  • Можно ли функцию ИИ отключить?
  • Кто и как сообщит владельцу объекта, если выяснится, что модель способна выдавать опасные рекомендации?

Документ прямо рекомендует требовать от производителей прозрачности, описания цепочки поставок программных компонентов, правил использования данных и возможности отключать функции ИИ силами самого владельца объекта. Последний пункт кажется довольно логичным. Если устройство без согласия владельца самостоятельно общается с облаком, использует неизвестную модель и не позволяет отключить «интеллектуальную» функцию, то это уже как будто бы не дополнительная возможность продукта.

Лучший канал из ИИ в АСУ ТП — тот, которого нет

Одна из самых практичных рекомендаций документа — по возможности не давать внешней системе ИИ постоянный путь внутрь технологической сети. То есть данные выводятся наружу, но сама система ИИ не получает постоянного доступа обратно. А там, где возможно, должна использоваться однонаправленная передача, промежуточные хранилища и контролируемые точки обмена.

Логика очень простая: если системе нужно только анализировать телеметрию и советовать оператору, ей обычно вообще незачем иметь возможность что-либо слать обратно. А если такая возможность всё-таки нужна, это уже отдельное решение, которое должно иметь отдельное обоснование, так как компрометация внешней ИИ-системы не должна автоматически превращаться в новый маршрут атаки на АСУ ТП.

Человек в контуре

Документ много говорит об участии человека в принятии критичных решений. То есть чем сильнее ИИ способен влиять на технологический процесс, тем важнее должны быть точки, где действие можно проверить, подтвердить или остановить. Но есть нюансик…

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

  • понятные границы полномочий ИИ;
  • независимые источники данных;
  • заранее определённые безопасные пределы;
  • возможность отклонить рекомендацию;
  • понятные признаки отказа модели;
  • журналы решений;
  • процедуры работы без ИИ.

Последний пункт в документе подчеркнут отдельно через проблему утраты навыков. Если персонал годами доверяет автоматической рекомендации, то в аварийной ситуации может внезапно выясниться, что система уже не работает, а люди постепенно разучились работать без неё.

Испытания

Для промышленного применения мало показать красивую метрику на отложенной выборке. Документ предлагает инженерный путь: сначала испытательная среда, затем — всё более реалистичные стенды, при необходимости — испытания с реальным оборудованием в контуре, и только после достаточной проверки — переход к производственной системе. Проверять при этом нужно далеко не только точность, а, например:

  • задержки;
  • совместимость с существующим оборудованием;
  • ложные срабатывания;
  • пропуски событий;
  • поведение на неизвестных режимах;
  • деградацию модели со временем;
  • последствия потери связи;
  • повреждение или подмену входных данных;
  • нагрузку на сеть;
  • безопасное отключение системы.

Для АСУ ТП это органичный подход, а вот для ИИ часть состояний отказа менее очевидна и именно поэтому испытаний ему нужно не меньше, а местами даже больше.

Если новое устройство РЗА или контроллер никто в здравом уме не станет ставить на объект только потому, что разработчик показал хороший график на презентации, то почему с нейросетью должно быть иначе?

Наблюдать надо ещё и за самим ИИ

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

То есть модель становится ещё одним объектом технического контроля. Ситуация довольно ироничная: мы поставили ИИ, чтобы он обнаруживал аномалии, а потом ставим ещё один механизм, чтобы обнаруживать аномалии уже в работе самого ИИ.

Чтобы расследование в дальнейшем не превратилось в археологию, авторы отдельно рекомендуют:

  • отслеживать исходящий трафик;
  • контролировать обращения к данным;
  • проводить проверки устойчивости к атакам;
  • наблюдать за дрейфом модели;
  • отличать действия ИИ в журналах от действий пользователей и обычных технических учётных записей.

Если ИИ будет ломаться

Авторы предлагают заранее проектировать отказ системы ИИ и сразу иметь ответы на вопросы:

  • Что произойдёт, если ИИ недоступен?
  • Что произойдёт, если модель начнёт ошибаться?
  • Как обнаружится дрейф?
  • Как система выводится из контура?
  • Можно ли вернуться к обычной автоматике?
  • Сохраняется ли ручное управление?
  • Что увидит оператор?
  • Как это попадёт в план реагирования на инциденты?

То есть ИИ должен уметь не только работать, но и корректно не работать. Для промышленной автоматизации это стандартная инженерная логика, где отказ компонента сам по себе не должен превращаться в неконтролируемый отказ всей системы. Поэтому документ рекомендует предусматривать возврат к традиционной автоматике или ручному управлению и включать отказы ИИ в существующие процедуры функциональной безопасности и реагирования на киберинциденты.

Доверие — штука приятная, но безопасное состояние при потере этого доверия как будто бы полезнее.

А что по стандартам?

Авторы отдельно признают проблему: существующие международные технические стандарты по ИИ в основном ориентированы на применение ИИ в информационных системах, а не в промышленной автоматизации. Поэтому готового стандарта вида «IEC 62443, только полностью про ИИ» пока нет — это уже практический вывод из описанной авторами ситуации, а не буквальная формулировка документа.

Документ предлагает накладывать требования к ИИ на уже существующие процессы кибербезопасности и функциональной безопасности, а для специфических угроз ИИ использовать дополнительные материалы NIST, MITRE ATLAS, ETSI и других организаций.

Получается примерно такая конструкция:

безопасность ИИ + кибербезопасность АСУ ТП + функциональная безопасность = безопасность АСУ ТП с компонентами ИИ

И связи между этими тремя областями пока описаны заметно хуже, чем каждая область по отдельности. То есть довольно легко написать в требованиях, чтобы модель была защищена от отравления данных, но гораздо сложнее ответить, что конкретно произойдёт с технологическим процессом, если отравление всё-таки случится, какая защита это обнаружит, какой будет безопасная реакция и какое требование существующей системы безопасности должно это покрывать?

В сухом остатке

Principles for the Secure Integration of Artificial Intelligence in Operational Technology хорош своей довольно приземлённой инженерной мыслью: ИИ в промышленности надо перестать воспринимать как волшебную коробку и начать воспринимать как ещё один потенциально отказывающий компонент сложной системы, к которому люди очень быстро привыкают и которому начинают доверять. Компонент же, в свою очередь:

  • зависит от данных;
  • может деградировать со временем;
  • может вести себя недетерминированно или непредсказуемо за пределами проверенных режимов;
  • может требовать внешней инфраструктуры;
  • плохо объясняет свои ошибки;
  • добавляет новые пути атаки.

Основной вопрос, которым стоит задаться перед внедрением ИИ-системы в область АСУ ТП: «Что произойдёт с технологическим процессом, если модель ошибётся, сломается или её поведение сможет изменить атакующий?». И если ответ на вопрос звучит как «ну, надеемся, такого не случится», то, возможно, ИИ пока рановато давать доступ к реальному объекту.