Энергетика без права на ошибку: контур применения ИИ для ремонтов, данных и инвестиционных программ

1. Отраслевая повестка: надежность, импортонезависимость и киберустойчивость

Российский ТЭК входит в фазу, где цифровизация перестает быть набором корпоративных инициатив и становится частью отраслевой устойчивости. В апреле 2025 года была утверждена Энергетическая стратегия Российской Федерации на период до 2050 года, а в феврале 2026 года — обновленное стратегическое направление цифровой трансформации ТЭК до 2036 года. В нем отдельно зафиксированы приоритет отечественного базового и прикладного ПО, целевой ориентир 80% российского ПО в основных производственных и управленческих процессах к 2030 году, участие компаний ТЭК в кибериспытаниях и создание отраслевого полигона для тестирования ИИ и других цифровых решений к IV кварталу 2027 года.¹²

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

Отдельный контур — КИИ. Закон №187-ФЗ регулирует безопасность критической информационной инфраструктуры, включая категорирование, реестр значимых объектов, требования безопасности, оценку и государственный контроль. Для ТЭК это особенно чувствительно: методические рекомендации по категорированию объектов КИИ прямо указывают на энергетику и топливно-энергетический комплекс как сферу применения и подчеркивают внимание к ИС, ИТКС и АСУ ТП, связанным с критическими процессами.³⁴

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

2. Где в энергетике рождается старый ИТ-контур: не только старые системы, но и старые способы управления

Старые системы в ТЭК — это не только морально устаревшая система планирования ресурсов предприятия или давно внедренная система ТОиР. Чаще это сочетание старой прикладной системы, локального Excel-файла, бумажной инструкции, файлового архива, устных договоренностей и филиального «так у нас принято».

Типовой ИТ-ландшафт крупной энергетической организации включает системы планирования ресурсов предприятия, EAM/ТОиР, SCADA и АСУ ТП, GIS-карты сетей, биллинг, системы коммерческого и технического учета, технологическое присоединение, документооборот, управление закупками, проектами, инвестиционными программами, охраной труда и промышленной безопасностью. В электроэнергетике критические процессы могут включать передачу электроэнергии, оперативно-технологическое управление, коммерческий учет, работу на оптовом и розничных рынках.⁴

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

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

3. Целевая архитектура: метаплатформа, шлюз доступа к большим языковым моделям и суверенный контур работы с большими языковыми моделями

Для ТЭК целевая AI-архитектура должна строиться вокруг пяти слоев.

Первый слой — источники данных. система планирования ресурсов предприятия, EAM/ТОиР, GIS, биллинг, СЭД, системы учета, хранилища, архивы паспортов, журналы дефектов, реестры оборудования, базы обращений потребителей, инвестиционные планы, проектная документация.

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

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

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

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

Такой подход соответствует международной логике управления рисками ИИ: рамка NIST по управлению рисками ИИ описывает управление рисками ИИ как задачу организаций, которые проектируют, разрабатывают, внедряют или используют системы ИИ, а ISO/IEC 42001 задает рамку системы менеджмента ИИ — политики, процессы, ответственность, управление рисками и возможностями.¹⁰¹¹

Для энергетики особенно важен еще один принцип: OT-контур имеет другие требования по надежности, задержкам, безопасности и влиянию на физический мир. NIST SP 800-82 описывает OT как программируемые системы и устройства, которые взаимодействуют с физической средой или управляют устройствами, влияющими на нее, и подчеркивает их особые требования к производительности, надежности и безопасности.⁹

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

4. Отраслевые сценарии: от документов до инвестиционных программ

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

Единая база знаний по регламентам и инструкциям

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

Анализ ремонтных заявок и ТОиР

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

Инвестиционные программы и контроль объектов

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

Реестры оборудования и сетевых активов

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

Аналитические справки для руководства

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

Обращения потребителей и технологическое присоединение

Большая языковая модель помогает классифицировать обращения, выявлять типовые причины задержек, готовить проекты ответов, сверять комплектность документов, выделять проблемные зоны по филиалам. При этом персональные данные и клиентские сведения требуют отдельной правовой и ИБ-проверки; в 2025 году были актуализированы требования к обезличиванию персональных данных.¹⁶

Импортозамещение прикладных систем

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

5. Разделение контуров: где облако допустимо, а где нужен внутренний контур организации или изолированный контур

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

Для госорганов и региональных ведомств отдельным ориентиром выступают государственные платформенные подходы. Официальный контур «ГосТех» позиционируется как облачное платформенное решение для федеральных и региональных органов власти, а в мае 2026 года Госдума приняла закон о технологической платформе создания, развития и эксплуатации информационных систем.¹⁵

Но для отраслевой энергетической системы это не отменяет оценки конкретного класса данных, статуса системы, КИИ-категорирования, персональных данных, требований ФСТЭК, корпоративной ИБ и промышленной безопасности.

6. Система управления применением ИИ: как не превратить большие языковые модели в неконтролируемый риск

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

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

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

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

7. Экономика эффекта: что получает бизнес, государство, регион и конечный пользователь

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

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

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

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

8. Что делать руководителю в ближайшие 90 дней

1. Утвердить карту контуров. Разделить технологический, КИИ, корпоративный, документный, клиентский, аналитический и экспериментальный контуры.
2. Провести инвентаризацию Excel-контуров. Найти файлы, которые фактически управляют ремонтами, инвестиционными программами, реестрами активов, отчетностью и статусами объектов.
3. Выбрать 3–5 безопасных сценариев применения ИИ. Начать с базы знаний, классификации ремонтных заявок, сверки отчетов филиалов, подготовки справок и анализа комплектности документов.
4. Назначить владельцев данных. Отдельно по оборудованию, сетевым активам, ремонтам, дефектам, инвестиционным объектам, обращениям, договорам и нормативным документам.
5. Запустить шлюз доступа к большим языковым моделям как обязательную точку доступа. Запретить несанкционированное подключение сотрудников к внешним инструментам ИИ для работы с корпоративными и техническими данными.
6. Создать реестр сценариев применения ИИ. Для каждого сценария указать владельца, данные, контур, модель, риски, порядок проверки и метрики.
7. Проверить импортозамещение через архитектуру. Сопоставить критичные системы с реестром российского ПО, интеграциями, программными интерфейсами, данными и планами миграции; учитывать ограничения Указа №166 по иностранному ПО на значимых объектах КИИ.⁶
8. Подготовить пилот не как демонстрацию, а как приемку процесса. Пилот должен завершиться не презентацией, а решением: масштабировать, доработать, ограничить или закрыть сценарий.

9. Риски и ограничения

Заключение

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

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

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

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

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

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