
# Движок підказок на основі онтології для уніфікації анкет безпеки

> **TL;DR** – Движок підказок, орієнтований на онтологію, створює семантичний міст між конфліктними стандартами відповідності, дозволяючи генеративному ШІ виготовляти уніфіковані, аудиторо‑придатні відповіді на будь‑яку анкету безпеки, зберігаючи контекстну релевантність і регулятивну точність.

---

## 1. Чому потрібен новий підхід

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

| Фреймворк | Типове питання | Приклад відповіді |
|-----------|----------------|-------------------|
| **[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)** | *Опишіть шифрування даних у спокої.* | “Всі дані клієнтів зашифровано за допомогою AES‑256…” |
| **[ISO 27001](https://www.iso.org/standard/27001)** | *Як ви захищаєте збережену інформацію?* | “Ми впроваджуємо шифрування AES‑256…” |
| **[GDPR](https://gdpr.eu/)** | *Поясніть технічні засоби захисту персональних даних.* | “Дані зашифровано за допомогою AES‑256 і ротуються щоквартально.” |

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

**Онтологічний движок підказок** вирішує проблему в корені: він створює **одне, формальне представлення** концепцій відповідності, а потім **відображає** мову кожної анкети на цю спільну модель. ШІ розуміє лише один «канонічний» запит, поки онтологія виконує важку роботу з перекладом, версіонуванням і обґрунтуванням.

---

## 2. Основні компоненти архітектури

Нижче – високорівневий вигляд рішення у вигляді діаграми Mermaid. Усі мітки вузлів взяті в подвійні лапки, як того вимагає синтаксис.

```mermaid
graph TD
    A["Regulatory Ontology Store"] --> B["Framework Mappers"]
    B --> C["Canonical Prompt Generator"]
    C --> D["LLM Inference Engine"]
    D --> E["Answer Renderer"]
    E --> F["Audit Trail Logger"]
    G["Evidence Repository"] --> C
    H["Change Detection Service"] --> A
```

1. **Regulatory Ontology Store** – граф знань, який фіксує концепції (наприклад, *encryption*, *access control*), їхні взаємозв’язки (*requires*, *inherits*) та юрисдикційні атрибути.  
2. **Framework Mappers** – легковагові адаптери, що аналізують вхідні елементи анкети, ідентифікують відповідні онтологічні вузли та додають оцінки впевненості.  
3. **Canonical Prompt Generator** – формує єдиний, контекстно‑насичений запит для LLM, використовуючи нормалізовані визначення онтології та пов’язані докази.  
4. **LLM Inference Engine** – будь‑яка генеративна модель (GPT‑4o, Claude 3 тощо), яка генерує відповідь у природному мовленні.  
5. **Answer Renderer** – форматувує вихід LLM у потрібну структуру анкети (PDF, markdown, JSON).  
6. **Audit Trail Logger** – зберігає рішення про маппінг, версію запиту та відповідь LLM для перевірки відповідності та майбутнього навчання.  
7. **Evidence Repository** – сховище політик, аудиторських звітів та посилань на артефакти, що цитуються у відповідях.  
8. **Change Detection Service** – стежить за оновленнями стандартів або внутрішніх політик і автоматично розповсюджує зміни через онтологію.

---

## 3. Побудова онтології

### 3.1 Джерела даних

| Джерело | Приклад сутностей | Метод видобутку |
|--------|-------------------|-----------------|
| **ISO 27001 Annex A** | “Cryptographic Controls”, “Physical Security” | Правил‑базований парсинг пунктів ISO |
| **SOC 2 Trust Services Criteria** | “Availability”, “Confidentiality” | Класифікація NLP на документації SOC |
| **GDPR Recitals & Articles** | “Data Minimisation”, “Right to Erasure” | Витяг сутностей‑відношень за допомогою spaCy + власних патернів |
| **Внутрішнє сховище політик** | “Company‑wide Encryption Policy” | Прямий імпорт з YAML/Markdown файлів політик |

Кожне джерело додає *вузли концепцій* (`C`) та *зв’язки* (`R`). Наприклад, **“AES‑256”** – це *техніка* (`C`), яка *реалізує* контроль “Data at Rest Encryption” (`C`). Зв’язки анотовані даними про походження (джерело, версія) та рівень впевненості.

### 3.2 Правила нормалізації

Щоб уникнути дублювання, концепції **канонічуються**:

| Необроблений термін | Канонічна форма |
|---------------------|-----------------|
| “Encryption at Rest” | `encryption_at_rest` |
| “Data Encryption” | `encryption_at_rest` |
| “AES‑256 Encryption” | `aes_256` (підтип `encryption_algorithm`) |

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

### 3.3 Стратегія версіонування

Стандарти постійно змінюються; онтологія застосовує **семантичне версіонування** (`MAJOR.MINOR.PATCH`). При появі нової статті відбувається *мінорне* оновлення, що ініціалізує повторну оцінку всіх залучених запитів. Журнал аудиту фіксує точну версію онтології, використану у кожній відповіді, забезпечуючи простежуваність.

---

## 4. Генерація підказок на практиці

### 4.1 Від анкети до вузла онтології

Коли постачальник отримує запит типу:

> *“Do you encrypt backups stored off‑site?”*  

**Framework Mapper** виконує пошук схожості проти онтології і повертає вузол `encryption_at_rest` з впевненістю 0.96. Додатково виділяються атрибути‑модифікатори (“backups”, “off‑site”) як *теги*.

### 4.2 Канонічний шаблон підказки

Один універсальний шаблон виглядає так (псевдо‑код):

```
You are an expert compliance officer. Answer the following question using the company's documented controls.

Question: {{question_text}}
Relevant Control(s): {{ontology_node_names}}
Evidence Links: {{evidence_urls}}
Formatting: Provide a concise answer (max 150 words) and attach a bullet‑point list of supporting artifacts.
```

Система підставляє знайдені вузли онтології та отримує актуальні URL доказів із **Evidence Repository**. Оскільки базовий контроль однаковий для всіх фреймворків, LLM отримує **послідовний контекст**, що усуває варіації, спричинені різними формулюваннями.

### 4.3 Приклад виходу LLM

> **Відповідь:** Так, всі резервні копії, розташовані поза місцем зберігання, зашифровано за допомогою AES‑256 з унікальним ключем для кожного набору резервних даних. Ключі шифрування керуються у нашому сховищі HSM і ротуються щоквартально.  
> **Підтримуючі артефакти:**  
> - *Backup Encryption Policy* – `https://repo.company.com/policies/backup-encryption.pdf`  
> - *HSM Key Rotation Log* – `https://repo.company.com/audit/hsm-rotation.json`

**Answer Renderer** потім форматує цей текст у специфічну структуру анкети (наприклад, таблицю для ISO, вільне поле для SOC 2).

---

## 5. Переваги порівняно з традиційним налаштуванням підказок

| Показник | Традиційне налаштування підказок | Движок на базі онтології |
|----------|----------------------------------|---------------------------|
| **Масштабованість** | Одна підказка на фреймворк → лінійне зростання | Єдина канонічна підказка → стабільна |
| **Консистентність** | Різні формулювання у різних фреймворках | Єдина відповідь, згенерована з одного джерела |
| **Аудиторська прозорість** | Ручне відстеження версій підказок | Автоматичний журнал версії онтології та аудиту |
| **Адаптивність** | Потрібне пере‑навчання для кожного оновлення стандарту | Change detection автоматично розповсюджує зміни через онтологію |
| **Витрати на підтримку** | Високі – десятки файлів підказок | Низькі – один шар маппінгу та граф знань |

У реальних тестах у Procurize двигун на основі онтології скоротив **середній час генерації відповіді** з 7 секунд (налаштування підказок) до 2 секунд, при цьому **покращивши схожість між фреймворками** (зростання BLEU‑score на 18 %).

---

## 6. Поради щодо впровадження

1. **Почніть з малого** – заповніть онтологію найчастіше використовуваними контролями (шифрування, контроль доступу, логування) перед розширенням.  
2. **Використовуйте готові графи** – проєкти типу **Schema.org**, **OpenControl** та **CAPEC** пропонують готові словники, які можна розширювати.  
3. **Обирайте графову БД** – Neo4j або Amazon Neptune ефективно обробляють складні обходи та версіонування.  
4. **Інтегруйте CI/CD** – розглядайте зміни онтології як код; автоматизуйте тести, що перевіряють точність маппінгу за набором прикладів анкет.  
5. **Людина у циклі** – створіть інтерфейс для аналітиків безпеки, які підтверджують чи коригують маппінги, що підсилює навчання нечіткого збігу.

---

## 7. Майбутні розширення

- **Федералізована синхронізація онтологій** – компанії можуть ділитися анонімізованими частинами своїх онтологій, створюючи спільну базу знань щодо відповідності.  
- **Шар пояснювального ШІ** – прикріплювати графи причинно‑наслідкових зв’язків до кожної відповіді, візуалізуючи, які саме вузли онтології внесли свій вклад у кінцевий текст.  
- **Інтеграція Zero‑Knowledge Proofs** – для надзвичайно регульованих галузей вбудовувати zk‑SNARK доказування, що підтверджує правильність маппінгу без розкриття конфіденційних політик.

---

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

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

- **Виключити дублювання ручної роботи** між різними фреймворками.  
- **Гарантувати послідовність і аудиторську придатність** відповідей.  
- **Швидко реагувати** на регулятивні зміни з мінімальними витратами розробки.  

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

---

## <span class='highlight-content'>Дивіться</span> Also

- [OpenControl GitHub Repository](https://github.com/opencontrol) – Відкриті політики‑як‑код та визначення контролів відповідності.  
- [MITRE ATT&CK® Knowledge Base](https://attack.mitre.org) – Структурована таксономія технік противника, корисна для побудови безпекових онтологій.  
- [ISO/IEC 27001:2025 Standard Overview](https://www.iso.org/standard/82875.html) – Огляд останньої версії стандарту управління інформаційною безпекою.