
# Адаптивна контекстуалізація ризику для анкет постачальників з інтелектом про загрози в реальному часі

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

Зустрічайте **адаптивну контекстуалізацію ризику** (ARC) — генеративно‑ШІ‑орієнтовану платформу, яка **впроваджує інтелект про загрози в реальному часі (TI) у конвеєр генерації відповідей**. ARC не просто копіює статичний текст політик; вона **оцінює поточний ландшафт ризиків**, коригує формулювання відповідей і додає актуальні докази — і все це без жодного рядка коду, написаного людиною.

У цій статті ми розглянемо:

* Пояснення основних концепцій ARC і чому традиційні інструменти, що базуються лише на ШІ, не підходять.
* Огляд архітектури «від початку до кінця», зосереджений на точках інтеграції із потоками інтелекту про загрози, графами знань та LLM.
* Практичні шаблони впровадження, включно з **діаграмою Mermaid** потоків даних.
* Питання безпеки, аудиту та комплаєнсу.
* Конкретні кроки для команд, готових впровадити ARC у свій існуючий центр комплаєнсу (наприклад, Procurize).

---

## 1. Чому традиційні ШІ‑відповіді не влучають у ціль

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

| Сценарій збою | Приклад |
|--------------|---------|
| **Застарілі докази** | Платформа посилається на звіт SOC 2 постачальника хмари за 2022 р., хоча критичний контроль був вилучений у поправці 2023 р. |
| **Брак контексту** | У анкеті замовника запитується захист від “шкідливого ПЗ, що експлуатує CVE‑2025‑1234”. Відповідь посилається на загальну політику антивірусу, ігноруючи нововиявлений CVE. |

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

---

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

ARC базується на трьох стовпах:

1. **Поточний потік інтелекту про загрози** – безперервне надходження даних про CVE, бюлетені про вразливості та галузеві канали (наприклад, ATT&CK, STIX/TAXII).
2. **Динамічний граф знань** – граф, який поєднує положення політик, артефакти доказів та TI‑сутності (вразливості, актори, техніки атак) у версіонованих зв’язках.
3. **Генеративний контекстуальний движок** – модель Retrieval‑Augmented Generation (RAG), яка під час запиту отримує найбільш релевантні вузли графа та формує відповідь з посиланням на дані TI в реальному часі.

Ці компоненти працюють у **закритому зворотному циклі**: нові оновлення TI автоматично ініціюють переоцінку графа, що впливає на наступну генерацію відповіді.

---

## 3. Архітектура «від початку до кінця»

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

```mermaid
flowchart LR
    subgraph "Шар інтелекту про загрози"
        TI["\"Поточний інтелект про загрози\""] -->|Імпорт| Parser["\"Парсер і нормалізатор\""]
    end

    subgraph "Шар графа знань"
        Parser -->|Збагачення| KG["\"Динамічний граф знань\""]
        Policies["\"Сховище політик та доказів\""] -->|Зв’язок| KG
    end

    subgraph "RAG‑движок"
        Query["\"Запит анкети\""] -->|Отримати| Retriever["\"Граф‑ретривер\""]
        Retriever -->|Топ‑K вузлів| LLM["\"Генеративний LLM\""]
        LLM -->|Скластити відповідь| Answer["\"Контекстуальна відповідь\""]
    end

    Answer -->|Публікація| Dashboard["\"Панель комплаєнсу\""]
    Answer -->|Аудиторський журнал| Audit["\"Незмінний журнал аудиту\""]
```

### 3.1. Надходження інтелекту про загрози

* **Джерела** – NVD, MITRE ATT&CK, офіційні бюлетені постачальників, кастомні канали.
* **Парсер** – уніфікує різнорідні схеми у **загальну онтологію TI** (наприклад, `ti:Vulnerability`, `ti:ThreatActor`).
* **Оцінка** – присвоює **риск‑бал** за CVSS, рівень експлуатації та релевантність для бізнесу.

### 3.2. Збагачення графа знань

* Вузли представляють **положення політик**, **доказові артефакти**, **системи**, **вразливості** та **техніки атак**.
* Ребра описують відносини типу `covers`, `mitigates`, `impactedBy`.
* **Версіонування** – кожна зміна (оновлення політики, новий доказ, нова TI‑запис) створює нову знімок графа, що дозволяє виконувати запити “у часі” для аудиту.

### 3.3. Retrieval‑Augmented Generation

1. **Запит** – поле анкети трансформується у природномовний запит (наприклад, “Опишіть, як ми захищаємося від атак типу ransomware на Windows‑сервери”).
2. **Ретривер** – виконує **запит до графа**, який:
   * Шукає політики, що `mitigate` відповідну `ti:ThreatTechnique`.
   * Підібирає останні докази (наприклад, журнали EDR), пов’язані з цими контролями.
3. **LLM** – отримує вузли графа як контекст разом із оригінальним запитом і генерує відповідь, яка:
   * **Цитує** точний пункт політики та ID доказу.
   * **Посилається** на актуальний CVE або техніку загрози, відображаючи її CVSS‑бал.
4. **Пост‑процесор** – форматує відповідь згідно шаблону анкети (markdown, PDF тощо) та застосовує **фільтри конфіденційності** (наприклад, редагування внутрішніх IP‑адрес).

---

## 4. Створення конвеєра ARC у Procurize

Procurize вже пропонує **центральне сховище**, розподіл завдань та хук‑інтеграції. Щоб вбудувати ARC:

| Крок | Дія | Інструменти / API |
|------|-----|-------------------|
| 1 | **Підключити потоки TI** | Використати `Integration SDK` Procurize для реєстрації веб‑хук‑кінцевих точок NVD та ATT&CK. |
| 2 | **Запустити графову БД** | Розгорнути Neo4j (або Amazon Neptune) як керовану службу; надати GraphQL‑кінцеву точку для ретриверу. |
| 3 | **Створити завдання збагачення** | Планувати нічні завдання, які запускають парсер, оновлюють граф і маркують вузли `last_updated`. |
| 4 | **Налаштувати модель RAG** | Використати OpenAI `gpt‑4o‑r` з плагіном Retrieval або розгорнути open‑source LLaMA‑2 з LangChain. |
| 5 | **Інтегрувати в UI анкети** | Додати кнопку «Генерувати AI‑відповідь», що ініціює RAG‑конвеєр і відображає результат у панелі попереднього перегляду. |
| 6 | **Аудиторський журнал** | Записувати згенеровану відповідь, ідентифікатори отриманих вузлів та версію TI у незмінний журнал Procurize (наприклад, AWS QLDB). |

---

## 5. Питання безпеки та комплаєнсу

### 5.1. Конфіденційність даних

* **Zero‑Knowledge Retrieval** – LLM не отримує сирі файли доказів; лише їхні підсумкові метадані (хеш, мета‑дані) передаються до моделі.
* **Фільтрація виводу** – Детерміністичний рушій знімає PII та внутрішні ідентифікатори перед тим, як відповідь потрапить до запитувача.

### 5.2. Пояснюваність

* Кожна відповідь супроводжується **панеллю трасування**:
  * **Пункт політики** – ID, дата останньої редакції.
  * **Доказ** – посилання на збережений артефакт, хеш версії.
  * **Контекст TI** – CVE‑ID, рівень небезпеки, дата публікації.

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

### 5.3. Управління змінами

Оскільки граф знань версіонується, система може автоматично виконати **аналіз впливу змін**:

* При оновленні політики (наприклад, новий контроль ISO 27001) система виявляє всі поля анкети, що раніше посилаються на змінений пункт.
* Ці поля помічаються для **перегенерації**, гарантуючи, що бібліотека комплаєнсу ніколи не відстає.

---

## 6. Реальний вплив – коротка оцінка ROI

| Показник | Ручний процес | Процес з ARC |
|----------|----------------|--------------|
| Середній час на поле анкети | 12 хв | 1,5 хв |
| Показник людської помилки (неточне посилання) | ~8 % | <1 % |
| Аудиторські знахідки, пов’язані зі старими доказами | 4 за рік | 0 |
| Час інкорпорації нового CVE (наприклад, CVE‑2025‑9876) | 3‑5 днiв | <30 секунд |
| Підтримувані нормативи | SOC 2, ISO 27001 | SOC 2, ISO 27001, **GDPR**, **PCI‑DSS**, HIPAA (за потребою) |

Для середньої SaaS‑компанії, що обробляє **200 запитів на анкети щоквартально**, ARC може скоротити **≈ 400 годин** ручної роботи, що відповідає **≈ 120 тис. $** заощаджень (при $300/год). Підвищена довіра також скорочує цикл продажів, потенційно збільшуючи ARR на 5‑10 %.

---

## 7. План впровадження на 30 днів

| День | Етап |
|------|------|
| 1‑5 | **Воркшоп вимог** – визначити критичні категорії анкет, існуючі політики та бажані потоки TI. |
| 6‑10 | **Налаштування інфраструктури** – розгорнути керовану граф‑БД, створити безпечний конвеєр надходження TI (використати секрет‑менеджер Procurize). |
| 11‑15 | **Моделювання даних** – зіставити пункти політик із вузлами `compliance:Control`, артефакти – `compliance:Evidence`. |
| 16‑20 | **Прототип RAG** – зібрати просту ланцюжок LangChain, що отримує вузли графа та звертається до LLM. Протестувати 5 типових запитів. |
| 21‑25 | **Інтеграція UI** – додати кнопку «Генерувати AI‑відповідь» у редакторі анкет Procurize; вбудувати панель трасування. |
| 26‑30 | **Пілотний запуск та рев’ю** – запустити конвеєр на реальних запитах, зібрати зворотний зв'язок, налаштувати оцінки релевантності та завершити журнал аудиту. |

Після успішного пілоту розширте ARC на всі типи анкет (SOC 2, ISO 27001, GDPR, PCI‑DSS) та починайте вимірювати покращення KPI.

---

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

* **Федеративний інтелект про загрози** – поєднання внутрішніх SIEM‑триггерів з зовнішніми потоками для створення «компані‑специфічного» контексту ризику.
* **Цикл навчання підкріпленням** – нагороджувати LLM за відповіді, що отримують позитивний фідбек від аудиторів, поступово підвищуючи якість формулювань та посилань.
* **Багатомовна підтримка** – інтегрувати шар перекладу (Azure Cognitive Services) для автоматичного локалізування відповідей, зберігаючи цілісність доказів.
* **Докази з нульовим розголошенням** – надавати криптографічні докази того, що відповідь сформована на основі актуальних даних, без розкриття самих даних.

---

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

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

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

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

---

## Дивіться також
- [AWS QLDB – Незмінний журнал для аудиту](https://aws.amazon.com/qldb/)