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

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

А що, якщо кожне питання могло **миттєво маршрутизуватися** до точної особи (або AI‑ассистента), що володіє необхідними знаннями, одночасно відображаючи підтверджуючі докази з живого графа знань?  

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

* **Класифікація питань за субсекунди** — система розуміє підлеглий намір питання (наприклад, “шифрування в спокої”, “процес реагування на інциденти”, “місце зберігання даних”), а не лише базується на пошуку ключових слів.  
* **Динамічний підбір експертів** — використовуючи профілі навичок, метрики навантаження та історичну якість відповідей, IBARE обирає найвідповіднішого експерта (SME), AI‑ассистента або їх гібридну пару.  
* **Контекстуальне отримання доказів** — рішення про маршрутизацію збагачується релевантними уривками політик, аудиторськими артефактами та версійними доказами, отриманими з федеративного графа знань.  
* **Зворотний зв’язок у реальному часі** — кожне відповідане питання повертається в модель, покращуючи виявлення намірів та ранжування експертів для майбутніх опитувальників.  

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

---

## 1. Чому намір, а не ключові слова?

Більшість існуючих інструментів автоматизації опитувальників базуються на простій маршрутизації за ключовими словами або правилами:

```python
if "encryption" in question → assign to Security Engineer
if "GDPR" in question → assign to Data Privacy Lead
```

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

**Виявлення намірів** йде далі, інтерпретуючи *що саме потрібне запитувачу*:

| Приклад питання | Призначення за ключовими словами | Призначення за наміром |
|------------------|----------------------------------|------------------------|
| “Чи шифруєте ви резервні копії під час передачі?” | Інженер резервного копіювання (ключове слово: “backup”) | Інженер безпеки (намір: “шифрування даних під час передачі”) |
| “Як ви справляєтеся з інцидентом шкідливого ПЗ типу ransomware?” | Керівник реагування на інциденти (ключове слово: “ransomware”) | Керівник реагування на інциденти **плюс** Інженер безпеки (намір: “процес реагування на ransomware”) |
| “Які договірні положення охоплюють резидентність даних для клієнтів ЄС?” | Юрисконсульт (ключове слово: “EU”) | Керівник відповідності (намір: “положення договору про резидентність даних”) |

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

---

## 2. Архітектура високого рівня

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

```mermaid
flowchart TD
    subgraph Frontend
        UI[User Interface] -->|Submit Question| API[REST / GraphQL API]
    end

    subgraph Core
        API --> Intent[Intent Detection Service]
        Intent --> KG[Dynamic Knowledge Graph]
        Intent --> Skills[SME Skill‑Profile Service]
        KG --> Evidence[Evidence Retrieval Service]
        Skills --> Ranking[Expert Ranking Engine]
        Evidence --> Ranking
        Ranking --> Router[Routing Engine]
    end

    subgraph Workers
        Router -->|Assign| SME[Subject‑Matter Expert / AI Assistant]
        SME -->|Answer| Feedback[Feedback Collector]
        Feedback --> KI[Knowledge‑Graph Ingestion]
        Feedback --> Model[Model Retraining Loop]
    end

    classDef external fill:#f9f9f9,stroke:#333,stroke-width:1px;
    class UI,API,SME external;
```

**Ключові компоненти**

| Компонент | Відповідальність |
|-----------|-------------------|
| **Служба виявлення намірів** | Перетворює необроблений текст питання у багатокласовий вектор намірів за допомогою донавченої трансформер‑моделі (наприклад, RoBERTa‑large). |
| **Динамічний граф знань (KG)** | Зберігає сутності, такі як політики, докази, контрольні заходи та їх взаємозв'язки. Постійно збагачується на основі відповіданих питань. |
| **Служба профілів навичок SME** | Підтримує профіль кожного людського експерта та AI‑ассистента, включаючи експертизу в галузі, сертифікати, поточне навантаження та оцінки якості відповідей. |
| **Служба отримання доказів** | Запитує KG щодо найрелевантніших документів (уривки політик, журнали аудиту, версійні артефакти) згідно наміру. |
| **Двигун ранжування експертів** | Поєднує схожість намірів, відповідність навичок експертів, доступність та історичну затримку, створюючи упорядкований список кандидатів. |
| **Двигун маршрутизації** | Вибирає найкращих кандидатів, створює задачу в центрі співпраці та сповіщає виконавців. |
| **Збирач зворотного зв’язку** | Фіксує остаточну відповідь, пов’язані докази та оцінку задоволеності. |
| **Імпорт у граф знань** | Додає нові докази та оновлення зв’язків назад у KG, замкнувши цикл. |
| **Цикл перенавчання моделі** | Періодично перенавчає модель намірів з використанням нових маркованих даних для підвищення точності. |

---

## 3. Детальний розгляд реального сценарію

**Сценарій:** Інженер з продажу отримує запит від потенційного корпоративного клієнта:

> “Чи можете ви надати деталі про те, як ви ізолюєте дані клієнтів у мульти‑тенантному середовищі та які механізми шифрування ви використовуєте для даних у спокої?”

### Крок 1 – Подання

Інженер вставляє питання у інтерфейс Procurize. UI надсилає POST‑запит до API з необробленим текстом.

### Крок 2 – Витяг наміру

Служба виявлення намірів пропускає текст через донавчену трансформер‑модель, яка повертає розподіл ймовірностей за таксономією у 120 намірів. Для цього питання три найвищі наміри:

1. **Ізоляція тенантів** – 0.71  
2. **Шифрування‑в‑спокої** – 0.65  
3. **Резидентність даних** – 0.22  

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

### Крок 3 – Запит до графа знань

KG отримує вектор намірів і виконує **семантичний пошук схожості** (за допомогою векторних ембеддінг документів). Повертає:

| Документ | Оцінка релевантності |
|----------|----------------------|
| “[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2) – System‑Level Control 5.3: Tenant Isolation” | 0.84 |
| “[ISO 27001](https://www.iso.org/standard/27001) Annex A.10: Cryptographic Controls” | 0.78 |
| “Internal Whitepaper: Multi‑Tenant Architecture v2.4” | 0.66 |

Найбільш релевантні артефакти упакуються у **пакети доказів**.

### Крок 4 – Підбір експертів

Служба профілів навичок шукає всіх експертів з тегами **Хмарна архітектура**, **Безпека**, **Відповідність**. Кожен профіль порівнюється з вектором наміру; одночасно враховуються:

* **Поточне навантаження** (відкриті задачі, довжина черги)  
* **Оцінка якості відповідей** (середня за минулі анкети)  
* **Тайм‑зона** (для мінімізації затримки)

Топовий кандидат – **Олексій Пател, старший інженер з безпеки хмари** (композитний бал 0.92). Також пропонується AI‑ассистент **CryptoBot** з балом 0.87.

### Крок 5 – Маршрутизація та сповіщення

Двигун маршрутизації створює **завдання співпраці**, яке містить:

* Оригінальне питання  
* Визначені наміри  
* Пакет доказів (посилання на завантаження)  
* Пропозицію AI‑ассистента (необов’язково)  

Олексій отримує push‑сповіщення у Slack та в UI Procurize, а CryptoBot запускається у фоновому режимі, готовий доповнити відповідь.

### Крок 6 – Складання відповіді

Олексій переглядає докази, додає контекст про останні оновлення платформи, і викликає CryptoBot, щоб автоматично згенерувати абзац про алгоритм шифрування (AES‑256‑GCM). Об’єднана відповідь редагується, затверджується та надсилається.

### Крок 7 – Зворотний зв’язок

Замовник позначає відповідь як **“повністю задовільну”**. Збирач зворотного зв’язку реєструє:

* Текст відповіді  
* Ідентифікатори використаних доказів  
* Оцінку задоволеності (5/5)  

Імпорт у граф знань додає новий вузол **“Answer‑2025‑10‑21‑001”**, зв’язаний з оригінальним питанням, доказами та намірами. Цей вузол буде врахований у майбутніх подібних пошуках.

### Крок 8 – Оновлення моделі

Нові марковані дані (питання + підтверджені наміри + відповідь) додаються до **pipeline** навчання. Після накопичення 1 000 взаємодій модель перенавчається, підвищуючи точність у виявленні складних намірів, наприклад **“керування ключами у мульти‑тенантному середовищі”**.

---

## 4. Основні технічні складові

### 4.1 Модель виявлення намірів

* **Архітектура:** RoBERTa‑large, донавчена на власному наборі з 50 тис. анотованих речень анкети.  
* **Функція втрат:** бінарна крос‑ентропія для багатокласової класифікації.  
* **Аугментація навчання:** зворотний переклад для багатомовної стійкості (англійська, німецька, японська, іспанська).  
* **Продуктивність:** Macro‑F1 = 0.91 на валідаційному наборі; середня затримка ≈ 180 мс за запит.

### 4.2 Платформа графа знань

* **Двигунок:** Neo4j 5.x з вбудованими індексами векторної схожості (через бібліотеку **Neo4j Graph Data Science**).  
* **Схема:**  
  * **Типи сутностей:** `Policy`, `Control`, `Evidence`, `Question`, `Answer`, `Expert`.  
  * **Відношення:** `VALIDATES`, `EVIDENCES`, `AUTHORED_BY`, `RELATED_TO`.  
* **Версіонування:** Кожен артефакт має властивість `version` та мітку часу `valid_from`, що дає можливість **аудиту в часі**.

### 4.3 Служба профілів навичок

* **Джерела даних:** HR‑каталог (навички, сертифікати), система тикетів (час виконання задач), оцінки якості (після відповіді).  
* **Генерація ембеддінг:** FastText‑ембеддінги фраз навичок, конкатеновані з вектором навантаження.  
* **Формула ранжування:**  

```
score = α * intent_similarity
      + β * expertise_match
      + γ * availability
      + δ * historical_quality
```

де α=0.4, β=0.35, γ=0.15, δ=0.10 (тюнінг через Bayesian optimization).

### 4.4 Оркестрація мікросервісів

Усі сервіси упаковані в Docker‑контейнери та координуються Kubernetes з **Istio** для спостереження. Асинхронна комунікація – NATS JetStream для низьколатентних подій.

### 4.5 Безпека та конфіденційність

* **Zero‑Knowledge Proofs (ZKP):** Для надзвичайно чутливих доказів (наприклад, внутрішні результати пенетраційного тесту) KG зберігає лише ZKP‑коміти; сам файл залишаєcь зашифровано у зовнішньому сховищі (AWS KMS) і розшифровується лише для призначеного експерта.  
* **Диференціальна приватність:** На етапі навчання модель отримує каліброване шумове додавання Лапласа до агрегованих градієнтів, захищаючи вміст окремих питань.  
* **Аудит‑лог:** Кожне рішення про маршрутизацію, пошук доказів і редагування відповіді журналюється у незмінному реєстрі (Hyperledger Fabric), задовольняючи вимоги **SOC 2** щодо трасованості.

---

## 5. Кількісний оцінка бізнес‑впливу

| Показник | До впровадження (ручне) | Після впровадження IBARE |
|----------|--------------------------|---------------------------|
| Середній час обробки анкети (дні) | 12 | 3.4 (‑71,7 %) |
| Середній час першого призначення (год) | 6.5 | 0.2 (‑96,9 %) |
| Точність відповіді (переглядів) | 18 % відповідей потребують правки | 4 % |
| Оцінка задоволеності SME (шкала 1‑5) | 3.2 | 4.6 |
| Кількість виявлених недоліків у аудитах, пов’язаних з обробкою анкет | 7 на рік | 1 на рік |

Пілотний запуск у трьох SaaS‑клієнтів протягом шести місяців продемонстрував **чистий ROI = 4.3×**, переважно завдяки скороченню циклів продажу та зниженню юридичних витрат.

---

## 6. Перелік дій для команд

1. **Визначити таксономію намірів** – узгодити з безпекою, юридичним відділом та продуктовими командами ≈ 100‑150 намірів.  
2. **Зібрати навчальні дані** – анотувати щонайменше 10 к історичних питань з відповідними намірами.  
3. **Створити профілі навичок** – підключити дані HR, Jira та внутрішні опитування; нормалізувати опис навичок.  
4. **Розгорнути граф знань** – імпортувати існуючі політики, докази та їх історію змін.  
5. **Інтегрувати з центром співпраці** – підключити routing‑engine до Slack, Teams або кастомного UI.  
6. **Налаштувати зворотний зв’язок** – збирати рейтинги задоволеності та автоматично додавати їх у pipeline перенавчання.  
7. **Моніторити KPI** – налаштувати Grafana‑дашборди для затримок, успішності маршрутизації та дрейфу моделі.

---

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

### 7.1 Багатомодальна виявлення намірів  

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

### 7.2 Федеративні графи знань  

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

### 7.3 Автоматичне створення профілів експертів  

Використовувати LLM‑моделі для синтезу початкових профілів нових співробітників на основі їх резюме, зменшуючи час на онбординг.

---

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

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

* **Скоротити час відповіді** з тижнів до годин,  
* **Підвищити якість** за рахунок точного підбору знань,  
* **Масштабувати співпрацю** у розподілених командах, та  
* **Зберегти аудиторську прозорість**, задовольняючи вимоги регуляторів і клієнтів.

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