Звіт CYGNVS про стійкість виявив прогалини в готовності до інцидентів, пов’язаних зі ШІ

У Звіті CYGNVS про стійкість, підготовленому CYGNVS у партнерстві з Marsh Risk, ідеться про дедалі більший розрив між використанням ШІ організаціями та їхньою здатністю керувати пов’язаними з ним інцидентами. За даними понад 9 500 опитувань, у яких респонденти самостійно оцінювали свій досвід, звіт свідчить, що 89% опитаних організацій зіткнулися з певним інцидентом, пов’язаним зі ШІ, тоді як 46% імпровізували б у разі реагування на такий інцидент.

Опублікований 13 жовтня 2026 року звіт розглядає проблему, наслідки якої стають вагомішими в міру того, як ШІ переходить від генерування контенту до виконання бізнес-процесів. Доступ агента до документів, електронної пошти та бізнес-систем може зробити його корисним. Водночас помилкову інструкцію, розкриті облікові дані або неконтрольовану послідовність дій стає складніше стримати.

Результати свідчать, що впровадження ШІ та підготовка до відновлення після збоїв у його роботі просуваються з різною швидкістю. Близько 80% організацій у вибірці використовують генеративний ШІ, проте лише одна з трьох перевіряє свої системи ШІ на стійкість до атак. Наявність комітету з управління ШІ, про яку повідомили три чверті організацій, що використовують ШІ, не обов’язково означає, що вони мають перевірені на практиці заходи операційного захисту.

Що у звіті вважають інцидентом, пов’язаним зі ШІ

Головний показник потребує контексту. У звіті використано широке визначення інцидентів, пов’язаних зі ШІ: до них зараховано шкідливі галюцинації, упередженість, дрейф моделі, витік даних, дії агентів, спрямовані на досягнення непередбачених цілей, збої у взаємодії агентів і недостатні запобіжні механізми. Причини та наслідки таких подій можуть суттєво відрізнятися.

Неточна відповідь для клієнта й розкриття агентом конфіденційної інформації належать до цієї широкої категорії, але це не рівнозначні події з погляду безпеки. Тому показник 89% слід розуміти як повідомлення про досвід зіткнення з певним інцидентом, пов’язаним зі ШІ, а не як свідчення того, що майже дев’ять із десяти організацій зазнали порушення безпеки через ШІ. У звіті також зазначено, що 16% стикаються з інцидентом, пов’язаним зі ШІ, щонайменше раз на тиждень, але не встановлено, що всі ці інциденти однаково серйозні.

Ця відмінність важлива для планування реагування. У разі шкідливого результату роботи моделі може знадобитися вилучити контент і переглянути рішення, на які він вплинув. Якщо агент діє за допомогою під’єднаних інструментів, може виникнути потреба відкликати дозволи, зберегти записи про дії та з’ясувати, які зміни відбулися в кількох системах. Типовий план реагування на вторгнення може охоплювати частину заходів у будь-якому з цих випадків, але команди все одно мають знати, які саме дії з реагування на інциденти, пов’язані зі ШІ, їм доступні та хто уповноважений їх виконувати.

Плани поширені. Плани, готові до виконання, — значно менше.

У звіті готовність розглядають крізь призму чотирьох етапів: підготовки, тренувань, реагування та звітування. На кожному з них повторюється одна й та сама проблема: розрив між наявністю документації та здатністю виконати описане в ній під тиском.

• Підготовка: 92% мають задокументовані процеси реагування на інциденти, але лише 37% мають плани реагування на атаки з використанням програм-вимагачів, а 29% — плани реагування на інциденти, пов’язані з третіми сторонами.
• Тренування: 17% не проводять штабних навчань. Ще 66% проводять їх раз на рік або раз на два роки.
• Реагування: 67% не визначили чітко відповідальних за найважливіші процеси та залежності.
• Звітування: 69% визнають, що в їхніх записах є значні прогалини щодо того, хто що зробив і коли.

Водночас понад шість із десяти організацій повідомляють, що за попередні 12 місяців кількість інцидентів зросла, а 84% переглядають плани реагування раз на рік або рідше. Ці показники характеризують різні аспекти готовності, але разом порушують практичне запитання: як швидко план застаріває, якщо описані в ньому системи, постачальники та дозволи постійно змінюються?

У разі впровадження ШІ зміни можуть стосуватися нової моделі, додаткового джерела даних або дозволу на виконання завдання, яке раніше виконували вручну. Кожна з них може змінити необхідні дії в разі збою. У плані потрібно визначити відповідального за відповідну систему, доступні засоби стримування інциденту та докази, які необхідно зберегти під час його локалізації.

Чому інфраструктура реагування потребує окремого захищеного середовища

Лише 33% опитаних організацій мають спеціальне позасмугове середовище управління, яке ШІ, що розслідують, не може ні спостерігати, ні контролювати. Архітектурна проблема проста: команді реагування потрібне місце для координації, яке залишатиметься надійним, навіть якщо уражене середовище таким не є.

Уявімо агента, який має доступ до спільних документів і корпоративних систем обміну повідомленнями. Якщо фахівці, що реагують на інцидент, розмістять нотатки про розслідування й плани стримування в тих самих системах, дозволи агента можуть надати йому доступ до перебігу реагування. Це не означає, що кожен агент зі збоями намагатиметься приховати свої дії. Це означає, що архітектура реагування не має залежати від правильної роботи ураженої системи.

CYGNVS пропонує платформу для координації команд із безпеки, керівників компаній і зовнішніх фахівців. Її Центр управління інцидентами, пов’язаними зі ШІ містить спеціалізовані плани реагування, сценарії навчань і рекомендації щодо реагування. За словами компанії, середовище працює незалежно від корпоративних систем єдиного входу, електронної пошти та інфраструктури клієнтів.

До позасмугових можливостей належать окремі облікові записи користувачів і режим Isolate Mode, який обмежує робочий простір для реагування на інцидент колом уповноважених учасників. Компанія також згадує історичні знімки та цифрові сертифікати доступу з підписом, призначені для документування дій у відповідь на інцидент. Це інструменти для координації та управління доказами; їхня ефективність і далі залежить від того, як організації налаштовують доступ, розподіляють відповідальність і відпрацьовують їх використання.

До навчань потрібно залучати тих, хто ухвалює рішення

Лише 15% організацій, охоплених звітом, проводять повноцінні міжфункціональні навчання за сценаріями, залучаючи юридичні служби, керівників і фахівців із комунікацій. Майже половина й досі розглядає такі навчання переважно як вправи для команд безпеки та ІТ, долучаючи інші підрозділи за потреби.

Унаслідок цього важливі рішення відпрацьовують недостатньо. Команда безпеки може мати змогу вимкнути інтеграцію, але зупинити сервіс, яким користуються клієнти, може бути дозволено лише за погодженням керівника бізнес-напряму. Юридичній службі та команді комунікацій може знадобитися оцінити, що можна повідомляти, поки розслідування не завершене. Відпрацювання таких процедур передавання відповідальності допомагає виявити брак повноважень і суперечливі припущення.

Ще одна залежність — зовнішні постачальники послуг. Хоча 88% респондентів повідомляють, що мають плани кризових комунікацій, понад чотири з десяти ще не залучили зовнішніх фахівців, на яких спираються ці плани. Списки контактів і договірні домовленості — це практичні складники готовності, особливо коли під час масштабного інциденту кільком організаціям можуть знадобитися ті самі фахівці.

Як інтерпретувати результати бенчмарку

Згідно з описом методології, опитування охопило понад 9 500 респондентів; їхні відповіді збирали з січня 2023 року до вересня 2026 року в 21 галузі в країнах Азії, Європи та Північної Америки. Респонденти самостійно надавали відповіді; їх анонімізували й аналізували в сукупності. До набору даних увійшли організації, у яких протягом попередніх 24 місяців стався критичний кіберінцидент або інцидент, пов’язаний зі штучним інтелектом, а також ті, у яких таких інцидентів не було.

Це результати опитувань, зібраних протягом кількох років, а не одне нове опитування 9 500 окремих компаній. Опублікований опис методології не підтверджує, що вибірка є ймовірнісною та репрезентативною для всіх організацій, і не вказує розмір вибірки для кожного виділеного результату. Наведені відсотки — корисні показники в межах цього набору даних, але їх не слід сприймати як точні оцінки поширеності інцидентів у всіх організаціях.

Згідно зі звітом, організації, у яких нещодавно сталися критичні інциденти, за низкою показників зазвичай демонструють вищий рівень готовності. Цей зв’язок дає підстави вивчати, що саме змінили такі організації, але сам собою не доводить, що поліпшення стало наслідком пережитого інциденту. CYGNVS також продає програмне забезпечення для управління реагуванням, тому під час оцінювання її рекомендацій важливо враховувати комерційну зацікавленість компанії.

Як перетворити результати на практичні зміни

Разом зі звітом CYGNVS представляє функцію Resilience Benchmark, яка, за словами компанії, дає змогу клієнтам порівнювати рівень готовності за галуззю, розміром і географічним розташуванням. Організації, які не є клієнтами компанії, можуть безкоштовно пройти оцінювання та отримати персоналізований бенчмарковий звіт. Звіт і оцінювання доступні в ресурсному центрі CYGNVS із питань стійкості.

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

У міру того як організації розширюють повноваження систем штучного інтелекту, готовність до реагування має зростати відповідно. У звіті CYGNVS Resilience Benchmark Report чітко показано цей розрив. Щоб його подолати, командам потрібно перетворити письмові наміри на рішення та засоби контролю, які вони вже відпрацювали на практиці.