Ольга Чернышева: «Единый цифровой контур — это единая логика событий, данных и ответственности»

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

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

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

1. Ольга Александровна, сегодня большинство крупных энергообъектов (производственные базы, подстанции, РП) уже оснащены видеонаблюдением, СКУД, пожарной сигнализацией и другими устройствами. Однако наличие этого оборудования часто не дает синергетического эффекта. Почему, с вашей точки зрения, набор разрозненных систем не равен эффективной системе безопасности, и какие главные «разрывы» в данных вы наблюдаете на практике?

Я бы начала с простого тезиса: наличие технических средств безопасности и наличие системы безопасности, оснащенной техническими средствами — не одно и то же. Камера может прекрасно записывать видео, СКУД — фиксировать проход, пожарная автоматика — формировать событие, но если эти данные существуют в разных интерфейсах и не складываются в единый сценарий, сотрудник остается тем самым «интеграционным модулем», который вручную сопоставляет информацию. А это и есть дополнительный человеческий фактор.

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

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

2. Какие ошибки работы с системами безопасности сегодня наиболее опасны (неправильная настройка оборудования, формальное отношение дежурного персонала, избыток ложных срабатываний или отсутствие четких регламентов реагирования)? Как ваша система помогает менять эту ситуацию?

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

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

Поэтому технологическая часть должна решать сразу несколько задач: снижать информационный шум, давать оператору контекст события, обеспечивать разграничение ролей, показывать состояние оборудования и историю событий, а при необходимости — запускать заранее заданные сценарии. В IoT-платформе Rubetek предусмотрены мониторинг состояния систем, удаленная диагностика, уровни доступа, уведомления и сценарная логика. Но даже хорошая платформа не отменяет организационную работу: для каждого критичного события должен быть определен владелец, время реакции и критерий закрытия. Технология должна не просто «увидеть проблему», а помочь организации гарантированно довести ее до результата.

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

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

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

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

4. Что именно представляет собой единый цифровой контур безопасности в вашем понимании? Обязательно ли для его создания заменять все уже установленное оборудование, или ваша платформа способна стать универсальной «надстройкой», интегрирующей разнородные системы и оборудование?

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

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

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

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

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

Реальная роль ИИ сегодня — не заменить диспетчера или инженера, а снять с него рутинную руботу. Человек физически не способен качественно анализировать десятки и сотни видеоканалов одновременно. Алгоритм может выделить нужный эпизод: проникновение в зону, появление автомобиля или человека, движение по заданному сценарию, дым или огонь, и передать оператору уже событие для проверки. Современные камеры Rubetek имеют варианты с бортовой аналитикой, то есть часть обработки можно выполнять непосредственно на устройстве.

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

6. Системы безопасности сами становятся частью критической информационной инфраструктуры (КИИ). Как вы обеспечиваете защиту своего программного и аппаратного комплекса от внешних атак, особенно при интеграции с существующими программно-аппаратными комплексами энергокомпаний?

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

Первый принцип — минимально необходимая связь всех элементов системы. Интеграция не должна превращаться в объединение всех систем в одну плоскую сеть. Сегменты, критические функции и права доступа должны быть разделены. Второй — защищенные каналы и аутентификация. В оборудовании и программно-технических комплексах Rubetek используются защищенные соединения, в том числе HTTPS/TLS в поддерживаемых сценариях, а также парольная защита. Третий — ролевое разграничение: оператор должен видеть и делать только то, что необходимо его функции. Четвертый — фиксация изменений и управляемое обновление: мы должны понимать, кто и когда изменил конфигурацию, и иметь контролируемый процесс обновления программного обеспечения.

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

7. Вы используете понятие «Человеческий фактор 2.0». Что оно означает в контексте современных электросетевых компаний и чем современные ошибки операторов и инженеров отличаются от тех, с которыми предприятия сталкивались 10–15 лет назад?

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

Теперь можно неправильно настроить зону детекции, выбрать не тот порог срабатывания, игнорировать поток уведомлений, неверно интерпретировать вывод аналитики или, наоборот, слишком сильно ей довериться. Это я и называю «человеческим фактором 2.0». Машина берет на себя рутину, а человек становится верификатором, диспетчером и тем, кто принимает решение. Его работа становится менее механической, но более ответственной.

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

8. Может ли ваша система не только фиксировать нарушение, но и автоматически инициировать бизнес-процесс реагирования на это нарушение (создавать заявку, назначать ответственного и контролировать сроки устранения)? Насколько глубоко ваша платформа готова интегрироваться в управленческие контуры заказчика?

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

Правильная модель выглядит как цепочка: событие — классификация — подтверждение — назначение ответственного — SLA — контроль исполнения — закрытие и аналитика. Где именно живет эта цепочка, зависит от архитектуры заказчика. У компании уже может быть Service Desk, ERP, система управления ремонтами или собственная платформа. В таком случае наша задача — не создавать параллельную систему учета, а передать туда событие и необходимые атрибуты через интеграционный механизм. Для направлений Rubetek предусмотрены API и возможность доработки платформы под задачи заказчика.

Часть функций контроля уже реализуется на уровне IoT-платформы: состояние оборудования, уведомления, история событий, разграничение доступа, мониторинг проблем. Более глубокий процесс — например, автоматическое создание заявки с конкретным SLA и эскалацией — должен проектироваться вместе с заказчиком. Я считаю это правильным: управленческий контур у каждой крупной компании свой. Платформа безопасности должна встраиваться в него, а не заставлять заказчика строить второй параллельный мир. Мы должны бережно относится к существующей инфраструктуре и опыту клиента.

9. Как правильно внедрять единый цифровой контур на действующем энергообъекте, чтобы сама модернизация не стала источником технологических, эксплуатационных или киберрисков? Есть ли у вас методология или типовые сценарии миграции для сетевых компаний?

Главное правило — не начинать с оборудования. Начинать нужно с сценариев и исходной точки. Мы используем поэтапный проектный подход, потому что на действующем объекте одномоментная замена инфраструктуры чаще увеличивает риски, чем снижает их.

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

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

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

10. Учитывая текущие реалии, как вы гарантируете долгосрочную поддержку, обновление алгоритмов и наличие комплектующих для систем, которые будут эксплуатироваться 10–15 лет, что является стандартным сроком для основных фондов электросетевого комплекса?

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

У Rubetek есть важное преимущество: собственные R&D-компетенции и производство в России, в Орле, полный цикл разработки аппаратной и программной части, собственная техническая поддержка и база прошивок, возможность осуществлять шеф-монтаж. Это позволяет не ждать решения зарубежного вендора, а самостоятельно обновлять ПО, корректировать алгоритмы и при необходимости перерабатывать изделие. Компания также включена в реестр организаций радиоэлектронной промышленности Минпромторга, а ряд программных и аппаратных продуктов находится в профильных российских реестрах.

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

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

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

Я бы разделила показатели на четыре группы. Первая — скорость реакции: время от возникновения события до его обнаружения, подтверждения, назначения ответственного и начала действий. Вторая — качество: доля ложных тревог, доля событий, по которым выполнен регламент, количество пропущенных инцидентов, повторяемость одинаковых нарушений. Третья — надежность самой системы: доступность оборудования и сервисов, количество отказов, среднее время диагностики и восстановления, доля проблем, выявленных дистанционно до выезда специалиста. Четвертая — операционная эффективность: количество ручных операций, число необоснованных выездов, нагрузка на диспетчерский персонал, стоимость обслуживания одного объекта.

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

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