
# AI‑Керований движок маршрутизації за інтенцією для спільної роботи над опитувальниками постачальників у реальному часі

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

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

> **Ключові висновки**
> - Визначення інтенції перетворює сирий текст опитувальника у структуровані бізнес‑інтенції.
> - Динамічний граф знань зв’язує інтенції з власниками, доказовими артефактами та версіями політик.
> - Маршрутизація у реальному часі використовує оцінку впевненості LLM та балансування навантаження.
> - Цикли безперервного навчання уточнюють інтенції та політики маршрутизації на основі аудиторських даних після подачі.

---

## 1. Від тексту до інтенції – шар семантичного парсингу

Перший крок IBRE – перетворити вільно сформульоване питання (наприклад, *«Чи шифруєте ви дані у спокої?»*) у **канонічну інтенцію**, яку система може обробити. Це досягається двохетапним конвеєром:

1. **Видобування сутностей на базі LLM** – легка LLM (наприклад, Llama‑3‑8B) видобуває ключові сутності: *шифрування*, *дані у спокої*, *обсяг*, *рамкова нормативна база*.
2. **Класифікація інтенції** – видобуті сутності передаються до тонко налаштованого класифікатора (на базі BERT), який зіставляє їх з таксономією **~250 інтенцій** (наприклад, `EncryptDataAtRest`, `MultiFactorAuth`, `IncidentResponsePlan`).

Отриманий об’єкт інтенції містить:
- `intent_id`
- `confidence_score`
- `linked_policy_refs` (**[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)**, **[ISO 27001](https://www.iso.org/standard/27001)**, внутрішні ідентифікатори політик)
- `required_evidence_types` (файл конфігурації, журнал аудиту, третя сторона)

**Чому інтенція важлива:**  
Інтенції слугують *стабільним контрактом* між змістом опитувальника та подальшим робочим процесом. Навіть якщо формулювання змінюється (“Чи ваші дані шифруються під час зберігання?” vs. “Використовуєте ви шифрування для даних у спокої?”) система розпізнає ту саму інтенцію, забезпечуючи послідовність маршрутизації.

---

## 2. Граф знань як контекстуальний каркас

**База графа властивостей** (Neo4j або Amazon Neptune) зберігає взаємозв’язки між:

- **Інтенції** ↔ **Власники** (інженери безпеки, юридичні консультанти, продуктові лідери)
- **Інтенції** ↔ **Доказові артефакти** (політики, знімки конфігурації)
- **Інтенції** ↔ **Регуляторні рамки** (**SOC 2**, **ISO 27001**, **[GDPR](https://gdpr.eu/)**)
- **Власники** ↔ **Навантаження та доступність** (черга завдань, часовий пояс)

Кожна мітка вузла – рядок у подвійних лапках, що відповідає синтаксису Mermaid для майбутніх візуалізацій.

```mermaid
graph LR
    "Intent: EncryptDataAtRest" -->|"owned by"| "Owner: Security Engineer"
    "Intent: EncryptDataAtRest" -->|"requires"| "Evidence: Encryption Policy"
    "Intent: EncryptDataAtRest" -->|"complies with"| "Regulation: ISO 27001"
    "Owner: Security Engineer" -->|"available"| "Status: Online"
    "Owner: Security Engineer" -->|"workload"| "Tasks: 3"
```

Граф **динамічний** — кожного разу, коли завантажується новий опитувальник, вузол інтенції або прив'язується до існуючого, або створюється на льоту. Ребра власності переобчислюються за допомогою **алгоритму двочастинного зіставлення**, який балансуватиме експертизу, поточне навантаження та **[SLA](https://www.ibm.com/think/topics/service-level-agreement)**‑требування.

---

## 3. Механіка маршрутизації в реальному часі

Коли надходить пункт опитувальника:

1. **Визначення інтенції** дає інтенцію з оцінкою впевненості.
2. **Пошук у графі** отримує всіх кандидат‑власників та відповідні докази.
3. **Модуль оцінки** розраховує:
   - **Відповідність експертизі** (`expertise_score`) — на основі історичної якості відповідей.
   - **Доступність** (`availability_score`) — реальний статус через API присутності Slack/Teams.
   - **Терміновість SLA** (`urgency_score`) — виходить із дедлайну опитувальника.
4. **Сумарна оцінка маршрутизації** = зважена сума (конфігурована через policy‑as‑code).

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

Якщо оцінка впевненості нижча за поріг (наприклад, 0.65), завдання переходить у **чергу перевірки людиною**, де керівник комплаєнсу підтверджує інтенцію перед розподілом.

### Приклад рішення про маршрутизацію

| Власник | Експертність (0‑1) | Доступність (0‑1) | Терміновість (0‑1) | Сумарний бал |
|---------|--------------------|-------------------|--------------------|--------------|
| Alice (Sec Eng) | 0.92 | 0.78 | 0.85 | **0.85** |
| Bob (Legal) | 0.68 | 0.95 | 0.85 | 0.79 |
| Carol (Prod) | 0.55 | 0.88 | 0.85 | 0.73 |

Alice миттєво отримує завдання, а система журналює рішення для аудиту.

---

## 4. Цикли безперервного навчання

IBRE не залишається статичним. Після завершення опитувальника платформа засвоює **зворотний зв’язок після подачі**:

- **Оцінка точності відповіді** — аудитори оцінюють релевантність відповіді.
- **Виявлення пропусків у доказах** — якщо використані докази застарілі, система маркирує вузол політики.
- **Метрики продуктивності власника** — відсоток успішних відповідей, середній час реакції, кількість переадресувань.

Ці сигнали живлять два навчальні конвеєри:

1. **Уточнення інтенції** — помилкові класифікації запускають напівавтоматичне пере навчання класифікатора.
2. **Оптимізація політик маршрутизації** — за допомогою підкріплювального навчання (RL) оновлюються ваги експертизи, доступності та терміновості для максимізації дотримання SLA та якості відповідей.

Результат — **само‑оптимізуючий движок**, що покращується з кожним циклом опитувальника.

---

## 5. Ландшафт інтеграції

IBRE спроектовано як **мікросервіс**, що підключається до існуючих інструментів:

| Інтеграція | Призначення | Приклад |
|------------|-------------|---------|
| Slack / Microsoft Teams | Сповіщення в реальному часі та прийом завдань | `/procure assign @alice` |
| Jira / Asana | Створення тикетів для збору складних доказів | Авто‑створення тикету *Evidence Collection* |
| Управління документами (SharePoint, Confluence) | Отримання актуальних політик | Завантаження останньої версії політики шифрування |
| CI/CD‑конвеєри (GitHub Actions) | Запуск перевірок комплаєнсу після релізу | Запуск тесту policy‑as‑code після кожної збірки |

Уся комунікація здійснюється через **mutual TLS** та **OAuth 2.0**, гарантуючи, що конфіденційні дані опитувальника не залишають безпечного периметра.

---

## 6. Аудитований журнал та переваги комплаєнсу

Кожне рішення про маршрутизацію генерує незмінний запис у JSON:

```json
{
  "question_id": "Q-2025-437",
  "intent_id": "EncryptDataAtRest",
  "assigned_owner": "alice@example.com",
  "routing_score": 0.85,
  "timestamp": "2025-12-11T14:23:07Z",
  "evidence_links": [
    "policy://encryption/2025-09",
    "artifact://config/production/db"
  ],
  "confidence": 0.93
}
```

Зберігання цього JSON у **додатковому журналу** (наприклад, Amazon QLDB або блокчейн‑журналі) задовольняє вимоги **SOX** та **GDPR** щодо простежуваності. Аудитори можуть відтворити точну причину кожної відповіді, що суттєво скорочує цикл запитів на докази під час **[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)**‑аудитів.

---

## 7. Реальний вплив – коротке кейс‑стаді

**Компанія:** FinTech SaaS «SecurePay» (серія C, 200 співробітників)  
**Проблема:** Середній час відповіді на опитувальники – 14 днів, 30 % пропущених SLA.  
**Впровадження:** Запущено IBRE з 200‑вузловим графом знань, інтеграцією Slack та Jira.  
**Результати (90‑денної пілотини):**

| Показник | До | Після |
|----------|----|-------|
| Середній час відповіді | 14 днів | 2,3 дня |
| Дотримання SLA | 68 % | 97 % |
| Ручна робота з маршрутизації (годин/тиждень) | 12 год | 1,5 год |
| Аудиторські знахідки щодо відсутніх доказів | 5 за аудит | 0,8 за аудит |

ROI розраховано як **6,2×** за перші шість місяців, головно за рахунок скорочення втрат у швидкості укладання угод і зниження витрат на аудиторські виправлення.

---

## 8. Перспективні напрямки

1. **Федерація інтенцій між орендарями** – дозволити кільком замовникам спільно використовувати визначення інтенцій, зберігаючи ізольованість даних, за рахунок федеративного навчання.
2. **Перевірка Zero‑Trust** – поєднати гомоморфне шифрування з маршрутизацією інтенцій, щоб навіть движок не бачив конфіденційного змісту питання.
3. **Прогнозування SLA** – використати часові ряди для передбачення піків завантаження (наприклад, після запуску продукту) і автоматично масштабувати потужності маршрутизації.

---

## 9. Як розпочати роботу з IBRE

1. **Увімкніть движок інтенцій** у Procurize → Налаштування → AI‑модулі.  
2. **Визначте таксономію інтенцій** (або імпортуйте стандартну).  
3. **Прив’яжіть власників**, зіставивши облікові записи користувачів з мітками інтенцій.  
4. **Підключіть джерела доказів** (зберігання документів, артефакти CI/CD).  
5. **Запустіть пілотний опитувальник** і спостерігайте за панеллю маршрутизації.

Покроковий посібник доступний у **Центрі допомоги Procurize** у розділі *AI‑Driven Routing*.

---

## <span class='highlight-content'>Дивіться також</span>
- [Zero‑Trust Architecture for AI‑Driven Automation – NIST SP 800‑207](https://csrc.nist.gov/publications/detail/sp/800-207/final)