Як не допустити передачі корпоративних секретів у публічні ШІ-сервіси

Одного фільтра, який перехопить кожен пароль чи фрагмент коду, не існує. Робочий захист складається з трьох частин: дозволеного корпоративного ШІ-інструмента, зрозумілих правил для працівників і технічного контролю конкретних каналів. Системи запобігання витоку даних (DLP, Data Loss Prevention) вміють перевіряти і блокувати частину дій на керованих пристроях. Але вони не гарантують, що розпізнають будь-який секрет, і не контролюють особистий телефон працівника.

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

Після статті ви зможете визначити, які класи даних захищати, які канали реально закривають технічні засоби, як запустити пілот без зупинки роботи команди і що робити, якщо секрет уже пішов назовні. Як приклад DLP ми розбираємо Microsoft Purview за його документацією станом на дослідження від 11.10.2026. Можливості інших систем перевіряйте за їхньою документацією.

Типовий шлях витоку

Почнемо з навчального прикладу. Він вигаданий і показує механіку, а не реальний інцидент.

Розробник ловить помилку в інтеграції з платіжним сервісом. Щоб швидше розібратися, він копіює шматок конфігураційного файлу і вставляє його в публічний чат-бот з питанням «чому падає запит». У фрагменті разом з кодом опиняється робочий API-ключ. Відповідь корисна, проблему розв'язано за п'ять хвилин. А ключ тепер лежить у сервісі, з яким компанія не має договору і умови якого визначає особистий акаунт розробника.

Ніхто тут не мав поганого наміру. Саме тому такі витоки складно помітити: вони виглядають як звичайна робота. Типових каналів чотири.

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

Завантаження файлу. Договір, вивантаження з CRM чи презентація для клієнта завантажуються цілим файлом, щоб модель «прочитала все».

Розширення браузера. Розширення з функціями ШІ можуть отримувати доступ до вмісту сторінок, з якими працює співробітник. Працівник може навіть не усвідомлювати, що дані кудись передаються.

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

Які дані захищаємо

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

Секрети доступу виділено окремо не випадково. Їх не можна «трохи знеособити», а після витоку їх можна лише відкликати і замінити. Найкращий захист тут архітектурний: зберігання ключів у сховищі секретів зменшує шанс скопіювати їх разом із конфігурацією. Однак значення все ще може потрапити в лог, змінну середовища чи вивід команди, тому сховище не замінює контролю цих каналів. Детальніше про те, які персональні дані допустимо передавати в ШІ і на якій підставі, йдеться в нашій статті про GDPR і HIPAA.

Що реально вміє DLP

DLP-політика описує п'ять речей: на якому пристрої вона діє, в якому застосунку чи браузері, яку дію контролює, як розпізнає чутливий вміст і як реагує. Розберемо їх на прикладі функції Microsoft Purview, що обмежує вставку чутливого вмісту в браузер.

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

Браузер. Сторінка сценарію Microsoft перелічує Edge, Chrome і Firefox для Windows/macOS та Safari для macOS, водночас примітки про розширення Chrome/Firefox стосуються Windows. Цей стислий список не доводить однакових умов роботи на всіх платформах. Звірте матрицю підтримки для своєї ОС і перевірте вставку в кожному браузері; лише відсутність Windows-розширення на Mac не доводить, що macOS-сценарій не підтримується.

Тип дії. Вставка в браузер лише одна з контрольованих дій. Довідник політик DLP перелічує й інші дії на пристроях: завантаження файлів через браузер, копіювання в буфер обміну, друк, копіювання на знімні носії й мережеві папки, передачу через Bluetooth і віддалений робочий стіл. Кожну дію налаштовують окремо. Контроль вставки не означає контролю будь-якого тексту в будь-якому застосунку.

Розпізнавання вмісту. Правило для вставки в браузер спрацьовує за умовою «вміст містить» вибрані типи чутливої інформації. Перевірка відбувається в момент вставки і не залежить від мітки файлу, з якого скопійовано текст. Для Paste to Browser довідник окремо вказує: підтримуються типи чутливої інформації (SIT), а не мітки конфіденційності; текст коротший за 30 символів не оцінюється; класифікуються лише перші 4 МБ тексту. Практичний висновок: система знайде те, для чого є відповідний тип чутливої інформації. Внутрішній код без характерних шаблонів чи пароль, який не схожий на жоден відомий формат, класифікатор може пропустити. Обіцяти розпізнавання будь-якого коду або пароля не можна.

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

Перед тим як писати внутрішню інструкцію з налаштування, перевірте свою конфігурацію: операційні системи працівників, браузери, ліцензію і наявність потрібного розширення. Перевірка Edge на Windows не доводить, що те саме налаштування працює в Safari на Mac: потрібен окремий тест підтримуваної конфігурації, а не обов’язково окрема політика.

Таблиця меж контролю

Ця таблиця є навчальною і показує три різні канали та реальну межу технічного захисту.

Останній рядок найважливіший. Якщо працівник може відкрити договір на особистому телефоні, жодна DLP-політика на робочому ноутбуці не завадить йому передати текст далі. Захист тут переходить з рівня «перехопити дію» на рівень «хто і з якого пристрою взагалі має доступ до оригіналу».

Як не зупинити роботу команди

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

Дозволений інструмент. Дайте працівникам корпоративний ШІ-сервіс з бізнесовими умовами обробки даних. Наприклад, OpenAI зазначає, що за замовчуванням не навчає моделі на бізнес-даних клієнтів, а умови споживчого акаунта не переносяться на корпоративні продукти. Наявність такого інструмента робить маршрут даних зрозумілим: є місце, куди можна, і місця, куди не можна. Що саме перевірити в договорі і налаштуваннях корпоративного тарифу, розібрано в нашій статті про навчання корпоративного ШІ на даних компанії.

Групи доменів з різною реакцією. Документація Purview пропонує два підходи: загальна дія «аудит» з винятками «блокувати» для ризикованих сайтів або загальна дія «блокувати» з винятками «аудит» для довірених. Домен сам по собі може не розрізняти корпоративний та особистий акаунти одного сервісу. Дозвіл для домену поєднують із контролем робочого облікового запису або іншим підтвердженим способом розмежування.

Обґрунтовані винятки. Деяким командам потрібен доступ до сервісів, які для інших заблоковані. Оформлюйте винятки на групу і на строк, з власником, а не постійним дозволом «для своїх».

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

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

Пілот і хибні спрацьовування

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

Крок 1. Аудит без блокування. Увімкніть політику в режимі аудиту для обмеженої групи пристроїв. Подивіться, які події вона фіксує, на яких сайтах і з якими типами даних.

Крок 2. Тестові приклади. Підготуйте набір штучних даних: вигадані ключі у форматах, які використовує компанія, фіктивні персональні дані, фрагменти коду без реальних секретів. Перевірте на керованих пристроях у кожному підтримуваному браузері, що спрацьовує, а що ні. Справжні секрети для тестів не використовують.

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

Після пілоту запишіть, що політика не ловить. Цей перелік так само важливий, як перелік того, що вона ловить: він показує, де потрібні організаційні заходи.

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

Що робити після витоку

Якщо секрет уже передано сторонньому сервісу, саме видалення чату не відновлює його секретність. Відкликання доступу має пріоритет; паралельно використайте доступні механізми видалення даних і погоджений канал звернення до постачальника.

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

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

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

Виправити процес. З'ясуйте, чому секрет взагалі був у тексті, який можна скопіювати. Чи можна перенести його в сховище секретів? Чи був у працівника дозволений інструмент для цієї задачі? Чи потрібна нова DLP-політика для цього формату ключа? Мета розбору в тому, щоб наступного разу шлях витоку не існував, а не в пошуку винного.

Що зробити найближчим часом:

1. Складіть перелік класів даних і для кожного запишіть правило щодо ШІ-сервісів.
2. Перенесіть секрети доступу з конфігураційних файлів у сховище секретів там, де це ще не зроблено.
3. Дайте працівникам дозволений корпоративний ШІ-інструмент і поясніть, що в нього можна передавати.
4. Перевірте пристрої, браузери, ліцензії і розширення, на яких реально працюватиме DLP.
5. Запустіть пілот в режимі аудиту на тестових даних і запишіть, що політика ловить, а що ні.
6. Затвердьте порядок дій після витоку: хто обмежує доступ, хто відкликає секрети, хто збирає факти і хто відповідає за виправлення процесу.

Часті питання