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

## Чому довірчі значки важливі в сучасних процесах закупівель

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

Проте зростання **AI‑заснованих движків оцінювання** принесло нову проблему: **непрозорість**. Керівники неохоче довіряють значку, коли не бачать *як* було отримано підґрунтову оцінку. Регуляторні рамки, такі як [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), [ISO 27001](https://www.iso.org/standard/27001) та нові рекомендації з етики AI, зараз вимагають **пояснюваності** автоматизованих рішень про ризик. Саме тут стає необхідним **Explainable AI Trust Badge Engine**.

## Основні поняття

| Концепція | Опис |
|-----------|------|
| **Графові нейронні мережі (GNNs)** | Нейронні моделі, що працюють безпосередньо з графовими даними, вловлюючи взаємозв’язки між постачальниками, контрактами, сертифікатами та інцидентами. |
| **Explainable AI (XAI)** | Техніки, що виявляють логіку, що стоїть за виходом моделі, наприклад SHAP‑значення, GNNExplainer або контр‑фактичні графи. |
| **Оцінка в реальному часі** | Безперервне споживання потоків подій (наприклад, нові інциденти безпеки, оновлення політик) з миттєвим оновленням оцінок та значків. |
| **Довірчий значок** | Компактний візуальний артефакт (іконка + оцінка + коротке пояснення), який відображається у профілях постачальника, на сторінках довіри чи в маркетплейсах. |

## Огляд архітектури

Нижче — схематичний діаграм високого рівня системи. Він об’єднує інжести даних, граф знань, движок оцінювання GNN, шар XAI та сервіс генерації значка.

```mermaid
graph LR
    A["Потік подій (Інциденти безпеки, Зміни політик)"] --> B["Стрім‑процесор (Kafka/Flink)"]
    B --> C["Сховище графу знань у реальному часі (Neo4j)"]
    C --> D["Сервіс оцінювання GNN"]
    D --> E["Шар пояснюваності (GNNExplainer)"]
    E --> F["Сервіс генерації значка"]
    F --> G["Сторінка довіри постачальника"]
    D --> H["Зберігання оцінок (Time‑Series DB)"]
    H --> I["Сервіс аудиту комплаєнсу"]
    subgraph Edge Layer
        J["Edge Node (Низькочасова оновлення оцінки)"] --> D
    end
```

### Огляд потоку даних

1. **Потік подій** – Сповіщення про інциденти, результати аудитів та оновлення політик надходять у високопродуктивну платформу потокової обробки (Kafka або Pulsar).  
2. **Стрім‑процесор** – Ре‑часове збагачення (наприклад, перевірка репутації IP) нормалізує події та записує їх у **граф знань**.  
3. **Сховище графу знань** – Вузли представляють постачальників, сертифікати, контракти та інциденти; ребра фіксують взаємозв’язки типу «постачає», «обмінюється даними», «порушив».  
4. **Сервіс оцінювання GNN** – Графова згорткова мережа (GCN) або мережа графового уваги (GAT) обробляє граф і обчислює **оцінку ризику** для кожного постачальника.  
5. **Шар пояснюваності** – За допомогою **GNNExplainer** виділяються найвпливовіші під‑графи та внесок ознак, які призвели до оцінки.  
6. **Сервіс генерації значка** – Об’єднує оцінку, стислий текстовий коментар та візуальні індикатори (колір, іконка) у **довірчий значок**.  
7. **Сторінка довіри постачальника** – Значок подається через CDN і автоматично оновлюється під час зміни оцінки.  
8. **Сервіс аудиту комплаєнсу** – Зберігає повне пояснення та походження даних для аудиту, задовольняючи нормативні вимоги щодо прозорості.

## Графові нейронні мережі для ризику постачальників

### Чому саме GNN?

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

- **Виявлення непрямого ризику** (наприклад, коли підрядник постачальника зазнав порушення).  
- **Навчання на структурних патернах** (наприклад, кластери постачальників, що користуються спільним дата‑центром).  
- **Адаптації до змін топології** у міру додавання нових контрактів чи інцидентів.

### Вибір моделі

| Модель | Переваги | Типове застосування |
|--------|----------|----------------------|
| **GCN (Graph Convolutional Network)** | Швидке навчання, підходить для однорідних графів | Базове оцінювання ризику з обмеженою кількістю типів ребер |
| **GAT (Graph Attention Network)** | Навчає вагу важливості для кожного ребра | Гетерогенні графи зі змінною силою зв’язків |
| **RGCN (Relational GCN)** | Чисто обробляє кілька типів ребер | Складні регуляторні графи (SOC 2, GDPR, ISO 27001) |

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

## Техніки пояснюваності

### GNNExplainer

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

```mermaid
graph TD
    A["Цільовий постачальник"] --> B["Ребро інциденту (Витік даних)"]
    A --> C["Ребро сертифікату (ISO 27001)"]
    B --> D["Кореневий вузол (Третій‑сторонній софт)"]
    C --> E["Вузол комплаєнсу (Аудит пройдено)"]
    style B fill:#ffdddd,stroke:#ff0000,stroke-width:2px
    style C fill:#ddffdd,stroke:#00aa00,stroke-width:2px
```

Червоне ребро підкреслює недавній інцидент, який знизив оцінку **‑30 балів**, а зелене – сертифікат ISO 27001, який підвищив її **+20 балів**. Така візуальна аргументація відображається при наведенні курсора на значок.

### SHAP для ознак вузлів

Для пояснень на рівні ознак (наприклад, «Кількість відкритих тикетів», «Середній час виправлення уразливостей») розраховуються **SHAP‑значення** для кожного вузла. Три головні чинники відображаються у вигляді маркованих пунктів під значком:

- **Відкриті тикети високої критичності:** –15 пт  
- **Середня затримка патчів < 24 год:** +10 пт  
- **Відповідність резиденції даних:** +5 пт  

## Конвеєр оцінювання в реальному часі

| Етап | Технологія | Цільова затримка |
|------|------------|-------------------|
| Інжестія | Kafka + Flink | < 1 с |
| Оновлення графу | Neo4j Streams | < 500 мс |
| Оцінювання | PyTorch‑Geometric (GPU) | 200 мс за пакет |
| Пояснюваність | GNNExplainer (CPU) | 100 мс |
| Генерація значка | Node.js + SVG | < 50 мс |
| CDN‑розповсюдження | CloudFront / Akamai | Субсекундно |

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

## Заходи збереження конфіденційності

1. **Диференціальна конфіденційність:** Додавання контрольованого шуму до агрегованих ознак вузлів гарантує, що окремі деталі інциденту не можна відтворити зі значка.  
2. **Федеративне навчання:** Якщо кілька SaaS‑провайдерів діляться спільним графом знань, навчання може виконуватись локально на кожному edge‑вузлі, а оновлення моделі — обмінюватись. Це зменшує переміщення даних і відповідає вимогам локальності даних.  
3. **Докази з нульовим розкриттям (ZKP):** ZKP може підтвердити, що оцінка значка задовольняє політику (наприклад, «оцінка > 70») без розкриття самої графової структури, що корисно під час конфіденційних переговорів з постачальниками.

## Переваги для зацікавлених сторін

| Зацікавлена сторона | Надана цінність |
|----------------------|-----------------|
| **Команди закупівель** | Миттєва візуальна довіра, скорочення часу на заповнення анкет від днів до хвилин. |
| **Офіцери комплаєнсу** | Повний журнал аудиту, пояснювальна аргументація, відповідність [GDPR](https://gdpr.eu/) та етичним рекомендаціям AI. |
| **Постачальники** | Прозора зворотна зв’язок, можливість поліпшити конкретні фактори ризику. |
| **Лідери безпеки** | Безперервний моніторинг, раннє виявлення ризиків у ланцюжку постачання. |

## План впровадження

1. **Моделювання даних** – Визначити типи вузлів (Постачальник, Сертифікат, Інцидент, Контракт) та семантику ребер. Наповнити початковий граф даними з існуючих репозиторіїв політик та зовнішніх джерел.  
2. **Вибір архітектури GNN** – Прототипувати GCN, GAT та RGCN; провести бенчмарк на історичних даних про інциденти; обрати модель з найвищим ROC‑AUC та кращими метриками пояснюваності.  
3. **Створення шару пояснюваності** – Інтегрувати GNNExplainer; зберігати під‑графи та SHAP‑значення у легковажному сховищі ключ‑значення (Redis).  
4. **Розробка сервісу значка** – Спроектувати SVG‑шаблони з кольоровим кодуванням (зелений = низький ризик, червоний = високий ризик). Використовувати безсерверну функцію (AWS Lambda) для складання даних значка за запитом.  
5. **Розгортання реального конвеєра** – Налаштувати теми Kafka, Flink‑завдання та Neo4j Streams. Встановити моніторинг (Prometheus + Grafana) для контролю SLA латентності.  
6. **Посилення безпеки** – Включити TLS скрізь, застосувати контроль доступу за ролями у Neo4j, активувати диференціальну конфіденційність для агрегованих ознак.  
7. **Пілот і ітерації** – Запустити пілот з 10 постачальниками, отримати зворотний зв’язок щодо зрозумілості значка, уточнити формулювання пояснень та поріг оцінок.  

## Реальний сценарій: швидка реакція на інцидент

*Компанія X* отримує **нуль‑день експлойт**, що впливає на популярну SaaS‑платформу. За кілька хвилин команда безпеки публікує інцидент у потоковій системі. Граф оновлюється, зв’язуючи експлойт із усіма постачальниками, що інтегрували уражений компонент. Сервіс оцінювання GNN пересчитає оцінки, і **довірчий значок постачальника Y** падає з **Gold (85 пт)** до **Amber (62 пт)**. Підказка значка показує:

- **Ребро інциденту:** «Нуль‑день експлойт у спільному компоненті» (**‑30 пт**)  
- **Ребро сертифікату:** «ISO 27001 (активний)» (**+20 пт**)  
- **Ознака:** «Відкритих тикетів = 3» (**‑5 пт**)  

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

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

- **Безперервне навчання:** Застосувати підкріплювальне навчання, де зворотний зв’язок щодо значків (апеляція постачальника, результат аудиту) коригує ваги моделі.  
- **Стандартизація між галузями:** Внести внесок у відкриту **специфікацію довірчого значка (Trust Badge Specification, TBS)**, щоб забезпечити портативність значків між різними маркетплейсами.  
- **Багатомодальний доказ:** Поєднати текстові політики, журнали та навіть скріншоти за допомогою моделей «зір‑мова», збагачуючи ознаки вузлів.  
- **Розгортання на edge‑пристроях:** Запускати весь конвеєр на edge‑пристроях для наднизькочасових середовищ, таких як локальні дата‑центри.  

## Висновок

**Explainable AI Trust Badge Engine** заповнює розрив між потужними моделями оцінки ризику та людською потребою в прозорості. Використовуючи графові нейронні мережі, XAI‑техніки та реаль‑часові потоки, організації можуть видавати довірчі значки, що не лише прискорюють процес закупівель, а й задовольняють суворі вимоги комплаєнсу. Наведена архітектура є дорожньою картою для створення системи значків, яка еволюціонує разом зі швидко змінною загрозливою екосистемою, гарантуючи, що кожна оцінка постачальника є **точною** та **відповідальною**.