
# Диференціальна приватність у поєднанні з ШІ для безпечної автоматизації анкет  

*Ключові слова: диференціальна приватність, великі мовні моделі, анкета безпеки, автоматизація комплаєнсу, конфіденційність даних, генеративний ШІ, приватність‑зберігаючий ШІ.*  

---

## Вступ  

Анкети безпеки – це вхідні ворота до B2B SaaS‑угод. Вони вимагають точних відповідей щодо шифрування, зберігання даних, реагування на інциденти та безлічі інших контролів. Традиційно команди з безпеки, юридичного відділу й інженерії витрачають **години**, перебираючи політики, дістаючи докази з репозиторіїв документів і вручну формуючи відповіді.  

У гру входять **платформи автоматизації анкет на базі ШІ**, такі як Procurize, які використовують великі мовні моделі (LLM) для створення відповідей за секунди. Прискорення очевидне, але воно супроводжується **ризиком витоку інформації**: LLM споживають необроблений текст політик, журнали аудиту та історичні відповіді – дані, які часто є суворо конфіденційними.  

**Диференціальна приватність (DP)** пропонує математично доведений спосіб додавати контрольований шум до даних, гарантуючи, що вихід ШІ‑системи не розкриває жодного окремого запису. Інтегруючи DP у конвеєри LLM, організації можуть **зберегти переваги автоматизації ШІ**, одночасно **забезпечуючи, що власні чи регульовані дані залишаються приватними**.  

Ця стаття представляє **повний, наскрізний каркас** створення движка автоматизації анкет з DP, розглядає виклики впровадження та надає практичні рекомендації.  

---

## 1. Чому диференціальна приватність важлива для автоматизації анкет  

| Проблема | Традиційний AI‑конвеєр | Конвеєр з DP |
|----------|------------------------|--------------|
| **Витік даних** | Необроблені політики подаються безпосередньо у модель, ризикує запам’ятовуванням конфіденційних пунктів. | Шум додається на рівні токенів або вбудовувань, що запобігає запам’ятовуванню точних формулювань. |
| **Регуляторна відповідність** | Може конфліктувати з принципом “мінімізації даних” GDPR та контролями ISO 27001. | DP відповідає принципу “privacy by design”, узгоджуючись зі статтею 25 GDPR та ISO 27701. |
| **Довіра партнерів** | Партнери (постачальники, аудитори) можуть сумніватися у відповідях, згенерованих ШІ без гарантій приватності. | Сертифікований DP забезпечує прозорий журнал, який документує збереження приватності. |
| **Повторне використання моделі** | Одна LLM, навчена на внутрішніх даних, може бути використана у різних проєктах, підвищуючи ризик витоку. | DP дозволяє **одну спільну модель** обслуговувати кілька команд без крос‑забруднення. |

---

## 2. Основні концепції диференціальної приватності  

1. **ε (Епсилон)** – бюджет приватності. Менший ε — сильніша приватність, але нижча корисність. Типові значення: 0.1 (висока приватність) до 2.0 (помірна приватність).  
2. **δ (Дельта)** – ймовірність провалу приватності. Зазвичай встановлюється у дуже мале значення (наприклад, 10⁻⁵).  
3. **Механізм шуму** – шум Лапласа або Гаусса, що додається до результатів запитів (наприклад, підрахунків, вбудовувань).  
4. **Чутливість** – максимальна зміна вихідного результату, яку може викликати один запис.  

При застосуванні DP до LLM ми розглядаємо кожний **документ** (політика, опис контролю, доказ аудиту) як запис. Мета – відповісти на семантичний запит “Яка наша політика шифрування даних у спокої?” без розкриття будь‑якої точної фрази з джерела.  

---

## 3. Архітектурний план  

Нижче – діаграма Mermaid, що ілюструє потік даних у системі автоматизації анкет з DP.

```mermaid
flowchart TD
    A["User submits questionnaire request"] --> B["Pre‑processing Engine"]
    B --> C["Document Retrieval (Policy Store)"]
    C --> D["DP Noise Layer"]
    D --> E["Embedding Generation (DP‑aware encoder)"]
    E --> F["LLM Reasoning Engine"]
    F --> G["Answer Draft (with DP audit log)"]
    G --> H["Human Reviewer (optional)"]
    H --> I["Final Answer Sent to Vendor"]
    style D fill:#f9f,stroke:#333,stroke-width:2px
    style F fill:#bbf,stroke:#333,stroke-width:2px
```

**Опис ключових компонентів**

* **Pre‑processing Engine** – нормалізує анкету, витягує заповнювачі (наприклад, `[COMPANY_NAME]`).  
* **Document Retrieval** – витягує релевантні розділи політик з контрольованого сховища знань (Git, Confluence тощо).  
* **DP Noise Layer** – застосовує Гаусів шум до токен‑вбудовувань, обмежуючи внесок кожного документа.  
* **DP‑aware Encoder** – трансформер‑енкодер, доопрацьований на шумових вбудовуваннях для отримання стійких представлень.  
* **LLM Reasoning Engine** – підконтрольна LLM (Claude, GPT‑4 або самостійно розгорнута open‑source модель), що працює з DP‑захищеними вбудовуваннями.  
* **Answer Draft** – генерує markdown‑відповідь та додає **журнал приватності** (ε, δ, timestamp).  
* **Human Reviewer** – необов’язковий етап контролю; reviewer бачить журнал, оцінює ризик перед затвердженням.  

---

## 4. Покроковий посібник з впровадження  

### 4.1. Створення сховища політик, контрольованого версіями  

* Використовуйте Git або спеціальне сховище комплаєнсу (наприклад, HashiCorp Vault) для зберігання **структурованих об’єктів політик**:  

```json
{
  "id": "policy-enc-at-rest",
  "title": "Data Encryption at Rest",
  "content": "All customer data is encrypted using AES‑256‑GCM with rotating keys every 90 days.",
  "last_updated": "2025-09-20"
}
```

* Позначте кожний об’єкт **рівнем чутливості** (public, internal, confidential).  

### 4.2. Пошук релевантних документів  

* Реалізуйте **семантичний пошук** (векторне порівняння) за допомогою вбудовувань стандартного енкодера (наприклад, OpenAI `text-embedding-3-large`).  
* Обмежте результати максимумом **k = 5** документів, щоб обмежити чутливість DP.  

### 4.3. Застосування диференціальної приватності  

1. **Шум на рівні токенів**  
   * Перетворіть кожний документ у токени.  
   * До кожного токен‑вбудовування **eᵢ** додайте Гаусів шум:  

   \[
   \tilde{e}_i = e_i + \mathcal{N}(0, \sigma^2)
   \]

   де \(\sigma = \frac{\Delta f \sqrt{2 \ln (1.25/\delta)}}{\varepsilon}\) і \(\Delta f = 1\) для токенової чутливості.  

2. **Кліпування**  
   * Кліпуйте L2‑норму кожного вбудовування до фіксованого порогу **C** (наприклад, C = 1.0) перед додаванням шуму.  

3. **Облік приватності**  
   * Використовуйте Rényi DP (RDP) accountant для відстеження кумулятивного ε протягом дня.  

### 4.4. Доопрацювання DP‑захищеного енкодера  

* Навчіть невеликий трансформер‑енкодер (2‑4 шари) на **шумових вбудовуваннях**, оптимізуючи задачу прогнозування наступного речення всередині корпусу політик.  
* Цей крок підвищує стійкість моделі до шуму, зберігаючи релевантність відповідей.  

### 4.5. Запит до LLM  

* Оточіть шумові вбудовування у **prompt RAG**:  

```
You are a compliance assistant. Use the following policy excerpts (noise‑protected) to answer the question exactly.

Question: What encryption algorithm does the company use for data at rest?
Policy Excerpts:
1. "... AES‑256‑GCM ..."
2. "... rotating keys ..."
...
Provide a concise answer without revealing the raw policy text.
```

* Встановіть **temperature = 0** для детермінованих виходів, зменшуючи варіативність, яка могла б підвищити ризик витоку.  

### 4.6. Генерація журналу аудиту  

* Після формування відповіді додайте JSON‑блок:  

```json
{
  "privacy_budget": {"epsilon": 0.5, "delta": 1e-5},
  "timestamp": "2025-10-12T14:32:10Z",
  "documents_used": ["policy-enc-at-rest", "policy-key-rotation"]
}
```

* Цей журнал зберігається разом із відповіддю для подальшого аудиту комплаєнсу.  

### 4.7. Людський перегляд та цикл зворотного зв’язку  

* Переглядач бачить як відповідь, так і журнал приватності. Якщо ε надто високий (наприклад, > 1.0), переглядач може запросити **перезапуск** з посиленим шумом.  
* Зворотний зв’язок (прийнято/відхищено) передається в RDP‑accountant для динамічної адаптації графіку шуму.  

---

## 5. Трейд‑офф між продуктивністю та приватністю  

| Метрика | Висока приватність (ε = 0.2) | Збалансовано (ε = 0.5) | Низька приватність (ε = 1.0) |
|---------|----------------------------|------------------------|-----------------------------|
| **Точність відповіді** | 78 % (суб’єктивно) | 92 % | 97 % |
| **Масштаб шуму (σ)** | 4.8 | 1.9 | 0.9 |
| **Навантаження** | +35 % затримка | +12 % затримка | +5 % затримка |
| **Відповідність регуляциям** | Сильна (GDPR, CCPA) | Адекватна | Мінімальна |

Для більшості команд SaaS‑комплаєнсу оптимальним є **ε ≈ 0.5**, що забезпечує майже людську точність і безпечну правову позицію.  

---

## 6. Реальний приклад: Пілотний проект DP у Procurize  

* **Контекст** – фінтех‑клієнт вимагав 30+ анкет безпеки щомісяця.  
* **Впровадження** – інтегровано DP‑захищений RAG у движок Procurize. Встановлено ε = 0.45, δ = 10⁻⁵.  
* **Результат**  

  * **Час реакції** скоротився з **4 днів** до **менше 3 годин**.  
  * **Журнали аудиту** не показали випадків, коли модель відтворювала буквальні фрагменти політик.  
  * **Аудит комплаєнсу** присвоїв “Privacy‑by‑Design” відзнаку від юридичного підрозділу клієнта.  

* **Висновки**  

  * **Контроль версій документів** – критично важливий; гарантії DP діють лише щодо даних, які подаються в систему.  
  * **Людський перегляд** лишається необхідним; 5‑хвилинна перевірка зменшила кількість хибних позитивів на 30 %.  

---

## 7. Контрольний список кращих практик  

- [ ] **Каталогізуйте всі політики** у сховищі з контролем версій.  
- [ ] **Класифікуйте чутливість** та задайте індивідуальний бюджет приватності для кожного документу.  
- [ ] **Обмежте розмір набору результатів (k)** для зниження чутливості.  
- [ ] **Застосовуйте кліпування** перед додаванням шуму DP.  
- [ ] **Використовуйте DP‑захищений енкодер** для підвищення точності LLM.  
- [ ] **Налаштуйте детерміновані параметри LLM** (temperature = 0, top‑p = 1).  
- [ ] **Записуйте журнали аудиту** для кожної згенерованої відповіді.  
- [ ] **Інтегруйте комплаєнс‑рев’ю** для відповідей з високим ризиком.  
- [ ] **Моніторьте кумулятивний ε** за допомогою RDP‑accountant та регулярно ротируйте ключі.  
- [ ] **Проводьте періодичні тести на витік** (наприклад, membership inference), щоб підтвердити гарантії DP.  

---

## 8. Перспективи розвитку  

1. **Приватне федеративне навчання** – поєднання DP з федеративними оновленнями від кількох підрозділів, дозволяючи глобальну модель без центрального збору даних.  
2. **Докази з нульовим розкриттям (ZKP) для аудиту** – видача ZKP, що відповідь відповідає бюджету приватності без розкриття самих параметрів шуму.  
3. **Адаптивне планування шуму** – використання reinforcement learning для динамічного підбору ε в залежності від довіри до відповіді.  

---

## 9. Висновок  

Диференціальна приватність трансформує процес обробки анкет безпеки з **високоризикового ручного завдання** у **приватний, керований ШІ‑процес**. При правильному проектуванні етапів пошуку, внесення шуму та LLM‑роздуму, організації можуть **зберегти комплаєнс, захистити власні політики і прискорити укладання угод** — при цьому аудиторам надаються перевірені журнали приватності.  

Впровадження DP‑заснованого движка автоматизації вже не експеримент, а **необхідна інвестиція** для підприємств, які мають збалансувати швидкість і суворі вимоги щодо захисту даних.  

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

---

## Дивіться також  

- NIST Differential Privacy Engineering Framework  
- OpenAI’s Guide to Privacy‑Preserving LLMs  
- Google’s Research on Differentially Private Semantic Search  
- ISO/IEC 27701:2024 – Privacy Information Management System