Коротка відповідь: які дані можна передавати AI
Передавайте лише той мінімальний фрагмент, який справді потрібен для дозволеної задачі, через схвалений компанією продукт і робочий акаунт. Публічний текст зазвичай можна використовувати у звичайному сценарії; внутрішні, комерційно чутливі та персональні дані спочатку потребують класифікації, мінімізації й рішення про допустимий контур.
Ім’я, телефон або номер замовлення не можна вважати безпечними лише тому, що їх замінили зірочками. Якщо людину, клієнта або угоду можна відновити за поєднанням залишених деталей чи окремою таблицею відповідностей, дані не стали анонімними. За невизначеності передавання зупиняється до оцінки власником даних, безпекою або профільним фахівцем.
Публічні дані
Передавайте лише актуальний матеріал без прихованих коментарів, історії змін і зайвих файлів.
Внутрішні дані
Скоротіть контекст і використовуйте схвалений корпоративний контур зі зрозумілим зберіганням.
Персональні дані
Спочатку визначте мету й підставу обробки; застосуйте мінімізацію та потрібні захисні заходи.
Секрети й доступи
Ключі, паролі, токени та production-конфігурація не передаються у промпт або спільний проєкт.
Невизначена категорія
Не вгадуйте: зупиніть сценарій і передайте рішення відповідальному.
Які ризики з’являються під час використання AI
Дані можуть потрапити в історію особистого акаунта, журнал інтеграції, підключений зовнішній сервіс або результат, який працівник надішле не тому адресату. Модель також здатна розкрити зайвий контекст у відповіді або виконати дію через інструмент із надмірними правами.
Тому захист не зводиться до питання, чи навчається модель на запитах. Потрібно бачити повний шлях інформації до, під час і після AI-операції.
Передача
Які поля й файли йдуть постачальнику або підключеному сервісу.
Зберігання
Де залишаються запити, відповіді, файли, кеш і технічні журнали.
Доступ
Хто бачить історію, проєкти, ключі та результати.
Дія
Що AI може прочитати, створити, змінити, надіслати або видалити.
Вивід
Чи не містить відповідь приховані дані, хибні факти або заборонену інформацію.
Проведіть інвентаризацію та класифікацію даних
До вибору інструмента складається коротка карта: які дані існують, де зберігаються, хто відповідає й для якої AI-задачі вони потрібні. Один документ може одночасно містити публічну інформацію, комерційну таємницю й персональні дані.
Категорії пов’язуються з дозволеними діями. Публічний текст можна обробляти у звичайному сценарії, а договори, клієнтські бази чи медичні відомості потребують окремої оцінки та архітектури.
Публічні
Уже опубліковані матеріали без додаткових обмежень.
Внутрішні
Процеси й документи, розкриття яких створює операційну шкоду.
Комерційно чутливі
Ціни, стратегія, вихідний код, договори й непублічні показники.
Персональні
Інформація, що стосується визначеної або визначуваної людини.
Спеціально регульовані
Категорії, для яких діють додаткові договірні або правові вимоги.
Мінімізуйте контекст до необхідного
Найнадійніший спосіб зменшити наслідки витоку — не передавати зайве. Для класифікації звернення часто не потрібні повне ім’я, телефон і вся історія клієнта. Для перевірки структури документа можуть не знадобитися реальні суми й реквізити.
Мінімізація має відбуватися до відправлення в модель. Прохання в промпті «не використовувати персональні дані» не видаляє вже передану інформацію.
Знеособлення, псевдонімізація й анонімізація
Видалення імені й телефона не завжди робить набір анонімним. Посада, рідкісне місто, дата події та зміст листування можуть разом знову вказувати на конкретну людину. Тому спочатку визначається, які ознаки дозволяють ідентифікацію прямо або через поєднання полів.
Псевдонімізація замінює ідентифікатори кодами, але зберігає можливість зворотного зіставлення в окремій захищеній системі. Європейська рада із захисту даних підкреслює: такі дані все ще стосуються визначуваної людини й залишаються персональними. Анонімізація прагне розірвати зв’язок із людиною, але її не можна оголосити досягнутою лише заміною кількох рядків.
Видалення прямих ідентифікаторів
Ім’я, телефон, email, адреса, номер документа та ідентифікатор акаунта.
Узагальнення
Точний вік або дата замінюються діапазоном, конкретна локація — ширшою областю.
Маскування
Частина значення приховується, якщо повний ідентифікатор не потрібен для задачі.
Псевдонім
Робочий код зберігається окремо від таблиці відповідностей.
Перевірка контексту
Оцінюється можливість упізнати людину за залишеними ознаками та зовнішніми даними.
Приклад: як підготувати звернення клієнта для AI-класифікації
Припустімо, AI має визначити тему звернення й підготувати чернетку маршруту. Для цього зазвичай не потрібні ім’я, телефон, email, точна адреса, повний номер замовлення та вся історія покупок. На боці бізнесу зберігається зв’язок із клієнтом, а в дозволений AI-контур передається мінімальний текст і технічний псевдонім.
Перед запуском команда перевіряє, чи не розкривають особу рідкісний товар, дата, населений пункт або зміст скарги. Відповідь моделі повертається як пропозиція категорії, а не як незворотна дія: фінансово значущі й чутливі випадки приймає людина.
Залишити
Лише текст, потрібний для визначення теми, та дозволені ознаки процесу.
Замінити
Ідентифікатори — випадковим кодом без значення для зовнішнього сервісу.
Зберігати окремо
Таблицю відповідностей — усередині контрольованої системи, не поруч із запитом.
Перевірити
Вивід на зайві дані, хибну категорію та потребу людської ескалації.
Перевірте постачальника й конкретний продукт
Один бренд може пропонувати споживчий чат, командний продукт і API з різними умовами. Перевіряються актуальні договори, використання даних, строки зберігання, регіон обробки, видалення, права адміністратора, журналювання, підключені функції й сторонні інтеграції.
Наприклад, Anthropic окремо описує зберігання для комерційних продуктів та API, а також винятки для функцій з іншим строком або спеціальних угод. Ці умови потрібно перевіряти на дату впровадження, а не переносити зі старого огляду.
Обмежте права й розділіть контури
AI отримує лише ті джерела й дії, що потрібні конкретному сценарію. Тестовий помічник не повинен мати доступ до всієї CRM, а інструмент підготовки листа — право автоматично надсилати його клієнту.
Для чутливих процесів використовуються окремі проєкти, робочі акаунти, ключі, середовища й журнали. Особисті підписки працівників не стають корпоративною архітектурою за замовчуванням.
Мінімальні права
Читання потрібної області замість повного доступу до системи.
Розділення середовищ
Тестові дані й sandbox до підключення production.
Підтвердження
Людина приймає дію з фінансовим, правовим або репутаційним ефектом.
Секрети
Ключі не потрапляють у промпти, документи й спільні інструкції.
Відкликання доступу
Права видаляються при зміні ролі, завершенні проєкту або інциденті.
Логи мають допомагати розслідуванню, а не створювати новий витік
Для контролю потрібні вхід, версія інструкції, результат, дія й помилка. Але технічний журнал не повинен безконтрольно дублювати повний чутливий документ. Рівень деталізації та строк зберігання обираються під ризик і необхідність розслідування.
Доступ до логів обмежується, а вивантаження й аналітичні панелі проходять ту саму класифікацію даних, що й основний процес.
Що робити при помилковій передачі даних
Працівник має знати один зрозумілий канал повідомлення про інцидент без страху приховати помилку. Відповідальний фіксує, які дані, куди, яким акаунтом і через яку функцію були передані, потім обмежує подальший доступ і перевіряє доступні способи видалення.
Подальші дії залежать від договорів, категорії даних і застосовного права. Матеріал не замінює юридичну чи профільну консультацію, але процес реакції має бути визначений до першого інциденту.
Зупинити
Вимкнути сценарій, ключ або інтеграцію, якщо передача триває.
Зафіксувати
Час, дані, продукт, акаунт, отримувачів і виконані дії.
Обмежити
Відкликати посилання, доступи й скомпрометовані секрети.
Оцінити
Ризик для людей і бізнесу разом із відповідальними фахівцями.
Виправити
Оновити правила, навчання й технічні обмеження за реальною причиною.
Мінімальна політика безпечного використання AI
Коротка робоча політика краща за великий документ, який ніхто не застосовує. Вона перелічує схвалені інструменти й акаунти, категорії даних, дозволені сценарії, обов’язкову перевірку, правила підключення сервісів і шлях повідомлення про помилку.
Політика переглядається при появі нового продукту, інтеграції, категорії даних або автономної дії. Відповідальність за професійний результат залишається у людини й процесу компанії.