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

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

Это остается актуальным и сегодня, но предприятиям теперь также необходимо подумать о моделях ИИ, промптах и агентах. Можно ли восстановить эти ресурсы, и как предприятия могут убедиться в их надежности после восстановления?

«Вообще говоря, планы аварийного восстановления большинства организаций в этой области отстают от внедрения ИИ на годы», — говорит Грег Сарич, CIO компании Quest Software.

Если CIO и CISO хотят помочь своим предприятиям наверстать упущенное, они должны понять, как обновить свои планы аварийного восстановления и протестировать их на реальных инцидентах.

Катастрофа в эпоху ИИ

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

• Были ли скомпрометированы данные, используемые для обучения систем ИИ?
• Были ли они украдены?
• Были ли отравлены модели ИИ?
• Были ли скомпрометированы промпты?

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

«Если вы используете Claude, он может затрагивать вашу систему Salesforce и SharePoint, вашу систему Outlook и другие данные, которые у вас могут быть, скажем, в Snowflake, или что-то еще, где у вас есть критически важные для бизнеса данные, — поясняет Сарич, иллюстрируя, как ИИ создает сеть взаимосвязанных зависимостей. — Речь идет не только о защите этих систем, но и обо всех этих небольших пересечениях, которые он затрагивает на пути к возможности извлечения данных и последующего создания результата».

В условиях, когда ИИ все больше интегрируется в бизнес-процессы, предприятия рискуют столкнуться с остановкой работы, особенно если их команды больше не могут вернуться к ручным методам. «Если ИИ-помощник или чат-бот выйдет из строя, мы потеряем доступ к институциональным знаниям, на которые полагаются наши сотрудники», — говорит Мехди Худайги, главный специалист Deloitte по кибербезопасности ИИ.

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

Предприятие может, например, восстановить работу чат-бота, но катастрофа продолжится, если люди будут действовать на основе скомпрометированной информации, которую он предоставляет.

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

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

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

Разработка плана аварийного восстановления ИИ

Для CIO и CISO, рассматривающих, как должны развиваться их планы аварийного восстановления в ответ на ИИ, есть несколько основных шагов, которые помогут им начать:

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

  «Начните с инвентаризации активов ИИ. Если у вас ее нет, вам нужно быстро ее создать, — говорит Сарич. — Вы не сможете восстановить то, что не каталогизировали».

• Определите критичность каждого актива для бизнеса. «Все, что в работе бизнеса связано с ИИ или имеет ИИ в своей основе, должно быть приоритетом номер один или считаться высоким уровнем опасности», — говорит Крис Миллингтон, руководитель направления решений Hitachi Vantara в области данных и киберустойчивости.

  По словам Сарича, инструменты, ориентированные на клиентов, и те, которые влияют на выручку, имеют более высокий приоритет.

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

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

• Определите целевые показатели восстановления. Организации должны определить целевое время восстановления и целевую точку восстановления, отмечает Худайги. Какой объем данных и времени простоя, связанных с ИИ-ресурсами, предприятие может позволить себе потерять? Каковы последние известные доверенные версии моделей, промптов и данных?

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

  «В системах ИИ задействовано значительно больше этапов из-за присущей им сложности, просто из-за их вероятностной природы», — поясняет Худайги.

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

  При проведении тестирования предприятиям необходимо учитывать все потенциальные пробелы в своих планах аварийного восстановления и устранять их.

  «Спросите себя, что произойдет, если база знаний будет повреждена или если мы потеряем доступ к одной из больших языковых моделей, когда API будут недоступны по какой-либо причине? Что произойдет, если агент будет вести себя неожиданно или если у нас реализуются случаи потенциального компрометирования, когда мы не сможем доверять журналам? Ответы на эти вопросы помогут довольно быстро выявить пробелы», — говорит Худайги.

Когда случается катастрофа

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

Согласно недавнему исследованию Proofpoint «2026 AI and Human Risk Landscape», 42% из 1400 опрошенных специалистов по безопасности сталкивались с инцидентами, связанными с ИИ, как подозрительными, так и подтвержденными. Кроме того, 52% респондентов заявили, что не полностью уверены в способности средств защиты их организаций обнаружить скомпрометированный ИИ.

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

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

Недостающий показатель устойчивости ИИ

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

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

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