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, ISO 27001, внутрішні ідентифікатори політик)
• required_evidence_types (файл конфігурації, журнал аудиту, третя сторона)

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

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

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

• Інтенції ↔ Власники (інженери безпеки, юридичні консультанти, продуктові лідери)
• Інтенції ↔ Доказові артефакти (політики, знімки конфігурації)
• Інтенції ↔ Регуляторні рамки (SOC 2, ISO 27001, GDPR)
• Власники ↔ Навантаження та доступність (черга завдань, часовий пояс)

Кожна мітка вузла – рядок у подвійних лапках, що відповідає синтаксису 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‑требування.

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

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

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

Власник з найвищою сумарною оцінкою отримує автоматично згенероване завдання в Procurize, попередньо заповнене:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кожне рішення про маршрутизацію генерує незмінний запис у 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‑аудитів.

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

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

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.

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

• Zero‑Trust Architecture for AI‑Driven Automation – NIST SP 800‑207