Воздушный зазор был иллюзией и до ИИ: что меняется, когда в контуре живут модели и агенты

В июне 2025 года на itsec.ru вышла статья «Киберустойчивость в энергетике: как избежать иллюзий». Я прочитал её с редким для отраслевых текстов чувством: согласен почти со всем. И именно поэтому хочу её продолжить, а не пересказать.

Тезисы статьи коротко. Абсолютная изоляция цифровых систем в современном мире иллюзия. Защита должна закладываться на этапе проектирования, а не прикручиваться потом. Требования делятся на mission critical, где на кону безопасность людей, экологии и государства, и business critical, где речь о прибыли и эффективности. В комиссии по расследованию системных аварий по Постановлению 846 не включают в обязательном порядке ИТ- и ИБ-специалистов. Понятийный аппарат разрознен: кибериммунность, конструктивная безопасность, киберустойчивость живут параллельно. Крупным энергокомпаниям нужны центры компетенций на 10–15 человек на стыке энергетики, ИТ и ИБ.

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

С чем я согласен, и почему это не новость

Про иллюзорность воздушного зазора я писал в 2012 году, когда разбирал Stuxnet: сегментация АСУ ТП перестала быть опцией. Stuxnet пришёл в изолированную сеть на флешке. С тех пор список способов пересечь зазор только рос: ноутбук подрядчика, VPN для обслуживания от вендора, 4G-модем в шкафу автоматики, который поставили на время пусконаладки и забыли. В 2021 году Colonial Pipeline показал, что технологический контур можно остановить, вообще не заходя в него: достаточно уронить корпоративную часть, от которой он зависит.

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

Этот вывод для 2025 года был верен. Для 2026 года он неполон.

Что изменилось: в контуре появился участник, который принимает решения

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

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

Два следствия, которые я считаю главными.

• Зазор защищал от кода извне. Модель атакуют данными изнутри. Отравление обучающей выборки и тихая подмена телеметрии на входе не требуют ни флешки, ни VPN. Подменённые показания с датчика выглядят для периметра как штатный трафик, а модель на их основе принимает решение, которое для оборудования разрушительно. Я подробно разбирал этот класс атак в заметке ИИ на производстве и атаки нового поколения, здесь повторю только вывод: линия защиты проходит через происхождение данных и контроль аномалий до модели, а не через антивирус.

• Агент перестаёт быть интерфейсом и становится субъектом действий. Пока в контуре стоял человек-оператор, инструкция из письма подрядчика проходила через его голову. Агент, которому дали доступ к системе заявок или к подготовке уставок, читает то же письмо и выполняет инструкцию, если она сформулирована как часть задачи. Это называется промпт-инъекцией, и для агента в технологическом контуре она означает путь вокруг зазора, который прокладывается текстом, а не кодом.

Mission critical и business critical: модель переходит границу незаметно

Деление автора на два типа требований мне нравится, потому что оно даёт собственнику понятный язык для разговора о деньгах. Mission critical закрывается обязательно и до конца, business critical взвешивается против экономики.

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

Отсюда правило, которое я предлагаю добавить к его делению: классифицировать не систему, а путь решения. Куда доходит выход модели, какие действия совершаются по нему автоматически, где стоит человек и где стоит детерминированный предохранитель, который модель переехать не может. Если выход модели доходит до исполнительного механизма, система mission critical, что бы ни было написано в её паспорте. Предохранитель при этом живёт вне контура ИИ, в контроллере или в релейной защите, и это ровно то место, где security by design из его статьи и защита ИИ из моей встречаются.

Безопасность на этапе проектирования: что это означает для модели

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

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

Здесь у меня для автора хорошая новость про терминологический разнобой, который он справедливо критикует. Для ИИ-контура регулятор уже начал закрывать его не терминами, а мерами. Методический документ ФСТЭК к приказу 117, выпущенный в апреле 2026 года, содержит отдельный раздел про защиту информации при использовании ИИ: изоляция среды разработки, контроль целостности обучающих данных и модели, журналирование, тестирование на промпт-инъекции. Формально документ для государственных систем, но направление для КИИ он задал. Я разбирал этот сдвиг в заметке 187-ФЗ девять лет спустя, и к самому разделу про ИИ ещё вернусь отдельно.

Постановление 846: в комиссии нет ИБ, а на объекте нет журнала модели

Здесь есть новость, которой на момент его статьи ещё не было. С 1 января 2026 года Постановление 846 заменено Постановлением 1489 от 29 сентября 2025 года: правила теперь охватывают не только аварии, но и инциденты, комиссии обязаны сохранять осциллограммы, регистрограммы, файлы параметрирования и записи переговоров, а электронные материалы хранятся не меньше семи лет. Но ИТ- и ИБ-специалисты в обязательном составе комиссий так и не появились, и компьютерная атака как возможная причина аварии в правилах по-прежнему не упоминается. Его замечание осталось в силе при новом документе.

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

Если этого нет, авария, вызванная подменённой телеметрией, выглядит как «модель ошиблась», а ошибка модели выглядит как «оператор не проверил». Расследование закрывается на человеке, причина остаётся в контуре, и через полгода повторяется. Для агентов я описывал эту логику в заметке про наблюдаемость роя агентов: единица наблюдения смещается с запроса на пару «намерение и действие», и записывать нужно попытки, а не только успехи. В технологическом контуре это правило становится требованием к расследованию, а не к эксплуатации.

Кадры: центр компетенций и что делать остальным

С центрами компетенций на 10–15 человек для крупных энергокомпаний спорить не буду, это рабочая модель, и шесть лет сотрудничества вендора с Центром НТИ МЭИ, на которые опирается автор, весят больше моих наблюдений. Добавлю только то, что вижу со своей стороны рынка.

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

Три иллюзии, которые я бы добавил в его список

Статья называется «как избежать иллюзий», и список иллюзий в ней точный. Для 2026 года я бы добавил три.

1. «Модель это просто программа, ИБ проверит её как любое ПО». Анализ кода и уязвимостей библиотек нужен, но поведение модели живёт не в коде, а в данных. Проверка модели это проверка выборки, процесса обучения и реакции на искажённые входы.

2. «Агент работает по регламенту, значит он предсказуем». Регламент агента написан на естественном языке и выполняется моделью, которая читает ещё и входные данные. Регламент можно переписать письмом, если агент читает почту. Предсказуемость агента обеспечивается ограничением прав и предохранителями, а не текстом инструкции.

3. «Модель локальная, значит зазор защищает и от ИИ-угроз». Локальность защищает данные от утечки наружу, я об этом писал в заметке про локальный ИИ. От отравления изнутри и от инъекции через входные данные локальность не защищает никак. Это разные угрозы с разными мерами.

Честные оговорки

• Я не из энергетики. Мой опыт это промышленность, ритейл и B2B, и про релейную защиту, отраслевой регулятор и кадры в энергокомпаниях автор знает глубже. Моё дополнение касается ИИ и данных в контуре, и там я опираюсь на собственные проекты.

• ИИ в АСУ ТП пока чаще советует, чем управляет. Случаи, когда выход модели доходит до исполнительного механизма, минуя человека, сегодня редкость. Но дрейф в ту сторону идёт по описанному выше пути, и классифицировать пути решений нужно до того, как ограничитель расширили в третий раз.

• Регуляторика по ИИ в КИИ формируется. Раздел в методическом документе ФСТЭК написан для государственных систем. Я ожидаю переноса подхода на значимые объекты КИИ, но это ожидание, а не факт, и строить на нём бюджет рано.

• Спор с автором здесь отсутствует. Всё, что написано выше, дополняет его текст, а не опровергает. Если где-то я его неверно понял, буду рад поправке.

Если коротко

• Воздушный зазор был иллюзией и до ИИ: флешка, подрядчик, VPN вендора и зависимость от корпоративной сети пересекали его всегда.
• В 2026 году внутри контура появился участник, который принимает решения по данным, а не по коду. Данные проходят зазор легально, и атакуют модель именно ими.
• Деление на mission critical и business critical для ИИ нужно применять к пути решения, а не к системе: куда доходит выход модели и где стоит предохранитель, который она не может переехать.
• Security by design для модели означает контроль данных, изоляцию обучения, целостность модели и журнал запросов и ответов. Регулятор уже описал это мерами в методичке к приказу ФСТЭК 117.
• Комиссии по расследованию аварий нужны не только ИБ-специалисты, но и зафиксированные версия модели, выборка, входы и решения, иначе причина останется в контуре.
• Для среднего предприятия кадровый дефицит решается конструкцией ответственности, а не центром компетенций на 15 человек.

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