Найбезпечніший запит до AI — не той, де довше попередження про конфіденційність. Це запит, до якого взагалі не потрапили зайві дані.
Тому захист інформації починається до звернення до моделі. Система має визначити тип даних, права користувача, потрібні поля, місця появи копій і строк їх видалення.
Спочатку намалюйте повний шлях даних
Позначте шлях від системи-джерела до користувача: тимчасові файли, черги, prompts, знайдені фрагменти, відповіді моделі, логи, аналітику й екран перевірки людиною. Надійний договір із постачальником не захищає забутий експорт на ноутбуці розробника.
Рекомендації ICO щодо безпеки AI та мінімізації даних радять документувати переміщення і зберігання персональної інформації та видаляти проміжні файли, коли вони більше не потрібні.
Для кожного компонента вкажіть власника, мету, категорії даних, розташування, строк зберігання, субпідрядників і спосіб видалення.
Класифікуйте дані до prompt
Невеликій компанії не потрібна громіздка схема. Для роботи часто достатньо чотирьох рівнів: публічні, внутрішні, конфіденційні та обмежені дані.
- Публічні дані можна передавати схваленим інструментам під звичайним контролем.
- Внутрішні потребують корпоративного облікового запису й правил зберігання.
- Конфіденційні потребують описаного сценарію, власника й мінімальних прав.
- Обмежені дані — паролі, вихідні документи особи або захищена медична інформація — блокуються без спеціально схваленої архітектури.
Мінімізуйте контекст, а не лише базу
Право працівника бачити всю картку клієнта ще не означає, що її повністю треба надсилати моделі. Виберіть поля для конкретного завдання, решту приберіть до пошуку й генерації.
NIST AI RMF відносить мінімізацію, деідентифікацію та агрегацію до методів підтримки приватності в AI-системах. Конкретний контроль залежить від сценарію й вимог до точності.
Для відповіді про доставку можуть бути потрібні номер замовлення й поточний статус. Історія адрес, платіжні нотатки та сторонні звернення лише збільшують ризик.
Залиште авторизацію поза моделлю
Модель може припустити, який запис релевантний. Детермінований код застосунку має вирішити, чи може поточний користувач його читати.
Це особливо важливо під час підключення AI до CRM. Зберігайте обмеження за компанією, роллю та конкретним записом. Семантична близькість не є дозволом.
Використовуйте окремі сервісні облікові записи, короткоживучі ключі, вузькі API scopes і явні переліки дозволених інструментів. Не розміщуйте секрети в prompts і системних інструкціях.
Редагуйте й токенізуйте дані заздалегідь
Редагування має виконуватися окремим контрольованим етапом. Знайдіть email, телефони, номери рахунків і сторони договору, а потім видаліть або замініть їх, якщо оригінальні значення не потрібні завданню.
Токенізація корисна, коли треба зберегти зв'язки. Модель працює зі стабільним псевдонімом, а захищений сервіс повертає справжнє значення лише після перевірки.
OWASP про розкриття чутливої інформації рекомендує очищення даних, суворий контроль доступу, обмеження джерел і зрозумілі строки зберігання. Інструкція в prompt сама по собі не є захисним контуром.
Вважайте RAG новою копією знань компанії
RAG-система створює індекси, embeddings, фрагменти й метадані. Ці похідні активи можуть розкривати ту саму інформацію, що й вихідні документи.
Переносьте права джерела в ingestion і retrieval. Розділяйте клієнтів, виключайте застарілі документи, зберігайте ідентифікатори джерел і перевіряйте, що користувач не отримує фрагмент закритого для нього запису.
Дані з конвеєра обробки документів також мають пройти перевірку полів і життєвого циклу до індексації.
Обирайте постачальника за поведінкою даних
З'ясуйте, де обробляються і зберігаються prompts, файли, embeddings, відповіді та логи захисту від зловживань. Перевірте типове зберігання, використання для навчання, регіон, шифрування, видалення, аудит доступу, повідомлення про інциденти й перелік субпідрядників.
Зафіксуйте конкретний тариф і конфігурацію API. Споживчий чат, корпоративний простір та API одного постачальника можуть мати різні умови.
Вимоги закону залежать від країни й категорії даних. Для персональної або регульованої інформації долучайте відповідального фахівця з приватності чи юриста до запуску.
Робіть логи корисними, але не небезпечними
Логи мають показати, хто використав систему, яке джерело відкрито, який інструмент викликано, чи було підтвердження людини і яка версія працювала. Для цього не обов'язково безстроково зберігати кожен сирий prompt.
Відокремте операційні метадані від чутливого вмісту. Маскуйте значення, обмежуйте доступ, задайте строки за метою й перевіряйте видалення. Ті самі правила діють для резервних копій та аналітичних експортів.
Інструментарій ICO з управління AI рекомендує картувати потоки, призначати технічні й операційні ролі, контролювати зміни та проводити ризик-орієнтовані аудити.
Підготуйте практичний план інциденту
NIST Privacy Framework допомагає пов'язати ризики приватності обробки даних з наявними практиками безпеки та управління AI.
- відкликати уражений сервісний обліковий запис або API-ключ;
- вимкнути конкретний інструмент чи процес;
- зберегти мінімально достатні докази;
- визначити джерела, prompts, відповіді, логи й одержувачів;
- виконати договірні та юридичні процедури повідомлення;
- виправити межу довіри й додати регресійний тест.
Як я відокремлюю секрети від автоматизації публікацій
У багатомовному конвеєрі публікацій bearer token використовується лише під час завантаження та викликів API статей. Він не потрапляє до payload статті, журналу Trello, звіту Slack або згенерованого вихідного файла.
Публічний каталог читається окремо для пошуку дублів і внутрішніх посилань. Права запису з'являються лише на точних кроках завантаження, створення чернетки й повного оновлення, а кожна відповідь перевіряється до продовження.
Це невеликий приклад, але принцип масштабується: робочий контекст проходить процесом, а паролі і сторонні записи — ні.
Запитання та відповіді
Чи можна працівникам вставляти конфіденційні дані в корпоративний AI?
Лише якщо компанія схвалила саме цей продукт, категорію даних і сценарій. Корпоративна підписка не замінює класифікацію, мінімізацію та права доступу.
Чи достатньо шифрування?
Ні. Шифрування захищає окремі стани й канали, але не заважає дозволеному процесу надіслати зайві дані або повернути їх не тому користувачеві.
Чи треба зберігати кожен prompt для аудиту?
Не завжди. Зберігайте мінімум доказів для експлуатації, безпеки й вимог закону, а чутливі payloads обмежуйте окремим строком.
Чи безпечні embeddings, оскільки це не звичайний текст?
Ні. Вважайте embeddings та індекси похідними чутливими активами. Обмежуйте доступ і тестуйте retrieval за правами джерела.
З чого почати малому бізнесу?
Опишіть один процес, класифікуйте дані, приберіть зайві поля, призначте власника й перевірте звичайний доступ і спробу отримати чужий запис.