Штучний інтелект уже став буденністю для корпоративних користувачів, але те, як саме він використовується, виявляється значно менш рівномірним, ніж здається. У подкасті IBM Technology «Security Intelligence» аналітики обговорюють новий звіт LayerX Security «State of AI Usage Report 2026» і те, як він змінює уявлення про ризики в епоху генеративного ІІ. Поруч із темами відкритого коду, SymJack‑атак на AI‑агентів і нових інструментів на кшталт Chatterbox, учасники дискусії зосереджуються на тому, хто саме створює основний ризик, як ІІ «розповзається» по браузерах і конекторах, і чому підприємства починають будувати нові «рейки безпеки» навколо своїх AI‑систем.

Звіт LayerX 2026: AI живе в руках небагатьох, а не в усіх
Звіт LayerX Security «State of AI Usage Report 2026» розбиває популярний міф про те, що генеративний ІІ рівномірно пронизує всю організацію. Замість цього дослідники побачили чітку концентрацію: більшість AI‑активності — і, відповідно, ризику — припадає на відносно невелику групу «суперкористувачів».
Це важливий зсув у розумінні. Багато програм безпеки будувалися з припущення, що кожен співробітник — потенційний AI‑користувач, а отже, і джерело ризику. LayerX показує іншу картину: є ядро людей, які працюють з ІІ щодня, інтегрують його в робочі процеси, автоматизують завдання, будують складні ланцюжки дій. Саме вони генерують левову частку запитів до моделей, передають найбільші обсяги даних і найактивніше підключають нові інструменти.
Для служб безпеки це означає зміну фокусу. Замість того щоб розмазувати ресурси тонким шаром по всій організації, логічніше і ефективніше придивитися до цієї відносно невеликої, але надзвичайно активної групи. Сам LayerX у звіті прямо рекомендує: політики, моніторинг і технічні контролі варто в першу чергу будувати навколо AI‑«пауер‑юзерів», бо саме вони визначають реальний профіль ризику.
Це не означає, що решта співробітників неважливі. Але з точки зору пріоритизації зусиль — від навчання до впровадження технічних обмежень — дані підказують: спершу потрібно зрозуміти, що роблять ті, хто використовує ІІ найбільше й найглибше.
Фрагментований ІІ: розширення, конектори й «невидимий» ризик у браузері
Ще один висновок LayerX, який викликає занепокоєння в безпекових команд, — це те, як саме ІІ з’являється в корпоративному середовищі. Якщо раніше основна увага була на великих, помітних платформах — на кшталт корпоративних чат‑ботів або інтегрованих AI‑функцій у великих SaaS‑сервісах, — то тепер картина значно більш роздрібнена.
Звіт фіксує, що AI‑можливості все активніше «просочуються» в браузерні розширення, плагіни, конектори до популярних сервісів. Це можуть бути невеликі аддони для автоматичного підсумовування сторінок, генерації відповідей у веб‑пошті, перекладу, аналізу документів у хмарних сховищах. Формально це дрібні інструменти, але саме вони часто працюють із чутливими даними — від внутрішніх листувань до конфіденційних документів.
Для безпекових команд це створює дві проблеми одночасно.
По‑перше, видимість. Класичні підходи до інвентаризації застосунків і контролю доступу не завжди «бачать» розширення браузера або дрібні конектори як окремі ризикові об’єкти. Вони можуть встановлюватися користувачами самостійно, оновлюватися без централізованого контролю, змінювати політику доступу до даних через нові версії.
По‑друге, ланцюжки передачі даних. Коли ІІ вбудований у розширення, дані можуть опинятися не лише в основному корпоративному AI‑сервісі, а й у сторонніх хмарних моделях, які обслуговує розробник плагіна. Це ускладнює відповіді на базові запитання: куди саме пішли дані, які саме моделі їх обробляли, які політики зберігання й видалення діють.
Фрагментація AI‑інструментів у браузері й конекторах означає, що навіть якщо організація формально «затвердила» один чи два основні AI‑сервіси, фактичний ландшафт може бути набагато ширшим. І знову ж таки, саме «суперкористувачі» часто першими підключають такі інструменти, експериментують із ними й вбудовують у свої робочі процеси.
Чому фокус на «пауер‑юзерах» не скасовує ризики для новачків
Рекомендація LayerX зосередити політики безпеки на AI‑«пауер‑юзерах» виглядає логічною з точки зору статистики використання, але вона не означає, що менш досвідчені користувачі автоматично безпечніші. Навпаки, як зауважує аналітикиня X‑Force Sophie Cunningham, саме епізодичні або нові користувачі можуть виявитися більш вразливими до певного класу атак.
Йдеться про атаки, які експлуатують довіру до інструкцій — як у терміналі, так і в інтерфейсах AI‑інструментів. У дискусії згадуються ClickFix‑подібні сценарії, де користувача переконують скопіювати й вставити в командний рядок нібито «корисну» команду, яка насправді виконує шкідливі дії. У світі AI‑агентів це може набувати форми інструкцій, які виглядають як звичайні кроки налагодження або оптимізації, але насправді змінюють конфігурацію системи на користь атакувальника.
Досвідчені AI‑користувачі, які щодня працюють із моделями, частіше ставляться до таких інструкцій критично. Вони звикли аналізувати, що саме пропонує система, перевіряти команди, розуміти контекст. Новачки ж, які сприймають ІІ як «чарівну кнопку», можуть бути схильні просто виконувати запропоновані кроки, не замислюючись над наслідками.
Cunningham підкреслює, що саме ця різниця в поведінці робить менш досвідчених користувачів привабливою ціллю для командно‑рядкових і ClickFix‑подібних атак. Вони не обов’язково генерують найбільший обсяг AI‑трафіку, але можуть стати «вхідною точкою» для зловмисників, які шукають спосіб закріпитися в інфраструктурі.
У результаті вимальовується двошарова картина ризику. З одного боку, «пауер‑юзери» створюють системний ризик через масштаб і глибину інтеграції ІІ у свої процеси. З іншого — малодосвідчені користувачі залишаються вразливими до соціально‑інженерних сценаріїв, де ключову роль відіграє не обсяг використання, а рівень критичного мислення щодо інструкцій, які пропонує система.
Як «просунуті» користувачі змінюють саму природу ризику
Глобальний польовий CTO Red Hat Brent Holden звертає увагу на ще один аспект: те, як саме «пауер‑юзери» сприймають і використовують ІІ, змінює характер ризиків. Для багатьох розробників і аналітиків перше знайомство з генеративним ІІ відбувалося через функції автодоповнення коду або тексту. У такому режимі модель — це, по суті, «розумніша автозаміна», яка допомагає писати швидше, але не бере на себе відповідальність за весь процес.
Софістиковані користувачі, за спостереженням Holden, рухаються далі. Вони починають ставитися до ІІ як до системи, здатної виконувати завдання «під ключ»: від аналізу вимог і генерації коду до тестування, деплою й моніторингу. У такому сценарії модель — це вже не просто інструмент, а повноцінний учасник робочого процесу, який приймає рішення, ініціює дії, взаємодіє з іншими сервісами.
Це радикально змінює профіль ризику. Якщо раніше помилка моделі обмежувалася, умовно, некоректним фрагментом коду, який ще пройде через руки розробника, то тепер ІІ може:
- автоматично змінювати конфігураційні файли;
- запускати скрипти в продакшені;
- взаємодіяти з API внутрішніх систем;
- ініціювати зміни в інфраструктурі.
У такому середовищі будь‑яка вразливість — від помилки в логіці до навмисно шкідливих інструкцій — може мати значно ширший вплив. Атаки на кшталт SymJack, які націлені на AI‑кодинг‑агентів і змушують їх переписувати власні конфігурації, демонструють, наскільки небезпечним може бути поєднання автономності й довіри до системи.
Саме тому Holden наголошує: коли ІІ використовується як система, а не як «розумний редактор», безпека має враховувати весь ланцюжок дій, які модель здатна виконати. Це вимагає інших підходів до моніторингу, логування, валідації рішень і, зрештою, до того, які саме повноваження надаються AI‑агентам у продакшені.
Нові «рейки безпеки»: як підприємства будують гардрейли для ІІ
На тлі зростання автономності AI‑систем і появи атак на кшталт SymJack багато підприємств переходять від точкових обмежень до системних «рейок безпеки» — гардрейлів, які обмежують як те, що користувачі можуть ввести в систему, так і те, що система може зробити у відповідь.
Holden описує тенденцію до впровадження обмежень на обидва боки — і на вході, і на виході. На рівні інпутів це може означати фільтрацію запитів, які містять чутливі дані, спроби обійти політики доступу або інструкції, що явно суперечать правилам безпеки. На рівні аутпутів — блокування відповідей, які:
- пропонують виконати небезпечні команди;
- містять конфіденційні дані, що не мали б покидати певний контур;
- ініціюють дії, які виходять за межі дозволених повноважень агента.
У цьому контексті показовим є крок Red Hat, яка придбала технологію Chatterbox саме для того, щоб допомогти клієнтам будувати такі гардрейли навколо AI‑інструментів. Йдеться не лише про «фільтр поганих слів», а про більш складну логіку, яка враховує контекст, роль користувача, тип даних, історію взаємодій.
Chatterbox і подібні рішення дозволяють підприємствам не просто «довіряти» моделі, а обгортати її додатковим шаром політик і контролів. Це особливо важливо в середовищах, де AI‑агенти мають доступ до систем із високим рівнем критичності — від фінансових транзакцій до керування інфраструктурою.
Гардрейли також стають відповіддю на позицію великих розробників LLM, які, як у випадку з SymJack, часто класифікують подібні атаки як «соціальну інженерію», а не як фундаментальні проблеми моделі. Якщо вважати, що модель «працює як задумано», але її можна змусити виконувати шкідливі інструкції, тоді саме оточення — від інтерфейсів до політик — має взяти на себе більшу частину відповідальності за безпеку.
Баланс між контролем і продуктивністю
Усе це ставить перед підприємствами непросте завдання: як побудувати достатньо жорсткі гардрейли, щоб знизити ризики, але не задушити продуктивність, яку дають AI‑інструменти. Особливо це відчутно в роботі з «пауер‑юзерами», які часто є драйверами інновацій усередині компанії.
Якщо обмеження будуть надто суворими, найактивніші користувачі можуть почати обходити офіційні інструменти, переходячи на несанкціоновані сервіси або локальні розгортання моделей без належного моніторингу. Якщо ж контролі будуть надто м’якими, ризик витоку даних, компрометації конфігурацій або зловживання автономними агентами зростатиме разом зі швидкістю впровадження ІІ.
Дані LayerX про концентрацію використання й фрагментацію інструментів дають безпековим командам важливу підказку: замість універсальних заборон варто інвестувати в глибоке розуміння того, як саме працюють ключові групи користувачів, які інструменти вони застосовують, які дані обробляють і які дії делегують моделям.
Це відкриває шлях до більш тонких політик: наприклад, різні рівні автономності для різних ролей, диференційовані обмеження на типи даних, які можна передавати в моделі, або контекстно‑залежні перевірки для операцій із високим ризиком. Усе це потребує не лише технологій на кшталт Chatterbox, а й тісної співпраці між безпекою, розробкою й бізнес‑підрозділами.
Висновок: від «усі користуються ІІ» до «хто й як ним користується»
Звіт LayerX «State of AI Usage Report 2026» і реакція експертів показують, що дискусія про безпеку ІІ в підприємствах виходить за межі простих питань на кшталт «дозволяти чи забороняти ChatGPT». Реальний ландшафт значно складніший: AI‑можливості розповзаються по розширеннях і конекторах, використання концентрується в руках відносно невеликої групи «пауер‑юзерів», а менш досвідчені співробітники залишаються вразливими до інструкцій, які вони не звикли критично оцінювати.
На цьому тлі нові гардрейли — від фільтрації інпутів і аутпутів до спеціалізованих рішень на кшталт Chatterbox — стають не розкішшю, а необхідністю. Вони дозволяють підприємствам прийняти той факт, що ІІ дедалі частіше працює як автономна система, а не як допоміжний інструмент, і відповідно перебудувати підходи до контролю ризиків.
Ключовий зсув полягає в тому, щоб перестати мислити категоріями «усі користуються ІІ» і почати ставити точніші запитання: хто саме використовує ІІ найбільше, як саме він інтегрований у їхні робочі процеси, які інструменти вони підключають і які рішення делегують моделям. Відповіді на ці запитання, підкріплені даними на кшталт тих, що надає LayerX, стають основою для реалістичної, а не декларативної стратегії безпеки в епоху генеративного ІІ.
Джерело
Project Lightwell brings open source security into the AI era — IBM Technology


