Лише 29% команд безпеки можуть регулярно звітувати про конфіденційні дані, які працівники надсилають інструментам ШІ

У цій статті наведено результати опитування Cloud Security Alliance (CSA) за 2026 рік, опубліковані у звіті DLP в епоху ШІ, замовленому компанією Jazz.

У червні та липні CSA запитала 433 фахівців з ІТ і безпеки, чи може їхня команда підготувати звіт із даними про те, скільки разів за останні 30 днів конфіденційні дані надсилали інструментам генеративного ШІ. Двадцять дев’ять відсотків відповіли, що можуть регулярно готувати такий звіт.

Цей показник був би менш важливим, якби респонденти вважали генеративний ШІ другорядним каналом. Вони назвали його головним ризиком витоку даних: 48% віднесли його до трьох основних ризиків.

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

Упевненість у видимості активності генеративного ШІ значно випереджає те, що команди можуть підтвердити

Трохи більше половини респондентів оцінили видимість активності генеративного ШІ на 4 або 5 балів із 5. Однак лише 29% могли регулярно підтверджувати цю оцінку звітом, у якому просто підраховано, скільки разів конфіденційні дані надсилали інструменту ШІ.

Джерело: Cloud Security Alliance, DLP in the AI Era (2026), n=433. Відтворено за діаграмами у звіті на сторінках 22 і 23.

Застосування засобів контролю демонструє ту саму тенденцію. Лише 22% респондентів суворо блокують передавання конфіденційних даних через канал генеративного ШІ. Для знімних носіїв, які респонденти визнали найменшим ризиком витоку даних, показник суворого блокування найвищий — 31%. Суворе блокування найчастіше застосовують до каналів, для яких використовують найстаріші засоби контролю.

Джерело: Cloud Security Alliance, DLP in the AI Era (2026), n=433. Відтворено за діаграмами у звіті на сторінках 23 і 26; стовпчики масштабовано до 100%, якщо через округлення значення в рядку становило 99% або 101%.

Поряд із результатами опитування Jazz опублікувала телеметричні дані з середовищ своїх клієнтів. Організація, середня за цими даними, використовувала 169,5 різних інструментів ШІ, з яких 9,8 були схвалені; отже, 94,2% інструментів не входили до схваленого переліку.

Чому виникає розрив: перелік інструментів не фіксує жодних подій

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

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

Щоб показати, що сталося в такому випадку, потрібні чотири факти: які конфіденційні дані було залучено, який інструмент їх отримав, через який обліковий запис їх передали та чому людина це зробила.

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

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

Кожен із наявних засобів контролю бачить лише одну точку

Опитування не виявило домінантного підходу до контролю за конфіденційними даними, які надсилають інструментам ШІ. Блокування доменів ШІ на рівні мережі, перевірка вмісту в браузері та використання лише політики прийнятного використання набрали по 21–23%, а корпоративні платформи ШІ із вбудованими засобами запобігання витоку даних — 10%.

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

Перевірка лише в одній точці також пояснює показники застосування засобів контролю. Якщо засіб не може відрізнити корпоративний обліковий запис від особистого або звичайне вставлення даних від ризикованого, йому доводиться блокувати обидва випадки або не блокувати жодного. Тоді суворе блокування перешкоджає і звичайній роботі, і ризикованим діям. На запитання про головну причину, через яку вони не перейшли до активнішого блокування, 46% респондентів відповіли, що побоюються порушити робочі процеси, а 39% зазначили, що не впевнені в точності засобів запобігання витоку даних.

Застереження, про які варто пам’ятати

Результати опитування ґрунтуються на відповідях самих респондентів, а оцінки видимості не перевіряли на відповідність фактичному охопленню. Серед респондентів переважають представники Америки (80%) та організацій із чисельністю персоналу менш як 5 000 працівників (67%), тож результати можуть не однаково добре стосуватися великих міжнародних компаній. Дані телеметрії надходять від організацій, які вирішили запровадити такий рівень видимості. Тому серед них може бути більше тих, хто вже занепокоєний неконтрольованим поширенням ШІ.

Схвалені інструменти й агенти ще більше послаблять цей перелік

Коли в схвалених SaaS-продуктах з’являються помічники на основі ШІ, на запитання, який інструмент отримав дані, часто є дві відповіді: застосунок, який відкрив працівник, і постачальник моделі ШІ, що стоїть за ним. Агенти ШІ ще більше ускладнюють ситуацію. Коли агент дістає файл і надсилає його кудись від імені працівника, питання про те, хто це зробив і навіщо, тепер частково стосується програмного забезпечення. Як зазначається в нещодавньому матеріалі Unite.AI про ін’єкцію промпту в агентів, що працюють у реальних умовах, вміст, який агент читає, може спрямувати його дії, тож його власний опис того, що він зробив, не може замінити доказів мети.

Перевірка, яку можна провести цього місяця

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

• Якими були дані та звідки вони надійшли
• Який інструмент їх отримав, зокрема інструменти поза вашим схваленим переліком
• Чи передали їх через корпоративний обліковий запис, чи через особистий
• Над чим працювала людина, коли надіслала ці дані

Якщо на перші два запитання ви швидко знаходите відповіді, а на останні два можете відповісти лише після розмови з працівником, то ваше управління охоплює перелік інструментів і майже не охоплює самі дані.