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

## Вступ

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

PDF‑файл, оновлений шість місяців тому, ще може бути прикріплений до опитувальника, заповненого сьогодні, що піддає постачальника аудиторським висновкам і підриває довіру клієнтів. Ручна перевірка актуальності трудомістка та схильна до помилок. Рішення – дозволити **генеративному ШІ** та **генерації з підкріпленням пошуку (RAG)** безперервно оцінювати, скеровати та сповіщати про актуальність доказів.

У цій статті докладно описано готовий до продакшну дизайн **двигуна оцінювання актуальності доказів у реальному часі (EFSE)**, який:

1. **Інжектує** кожен доказ одразу після його надходження в сховище.  
2. **Обчислює** оцінку актуальності за допомогою часових міток, семантичного виявлення змін та оцінювання релевантності за допомогою LLM.  
3. **Активує** сповіщення, коли оцінка падає нижче порогових значень, визначених політикою.  
4. **Візуалізує** тенденції на панелі, що інтегрується з існуючими інструментами комплаєнсу (наприклад, Procurize, ServiceNow, JIRA).

Після ознайомлення з посібником у вас буде чітка дорожня карта впровадження EFSE, підвищення швидкості відповіді на опитувальники та демонстрація безперервної відповідності аудиторам.

---

## Чому актуальність доказів важлива

| Вплив | Опис |
|--------|-------------|
| **Регуляторний ризик** | Багато стандартів ([ISO 27001](https://www.iso.org/standard/27001), [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), [GDPR](https://gdpr.eu/)) вимагають «поточних» доказів. Застарілі документи можуть призвести до невідповідностей. |
| **Довіра клієнтів** | Потенційні клієнти запитують: «Коли цей доказ був останній раз верифікований?» Низька оцінка актуальності стає перепоною у переговорах. |
| **Операційна ефективність** | Команди витрачають 10‑30 % робочого тижня на пошук та оновлення застарілих доказів. Автоматизація звільняє цей ресурс. |
| **Готовність до аудиту** | Видимість у реальному часі дозволяє аудиторам бачити живий знімок, а не статичний, можливо застарілий пакет. |

Традиційні панелі комплаєнсу показують **які** докази існують, а не **наскільки вони свіжі**. EFSE заповнює цю прогалину.

---

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

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

```mermaid
graph LR
    subgraph Ingestion Layer
        A["Document Store<br/>(S3, Git, SharePoint)"] --> B[Metadata Extractor]
        B --> C[Event Bus<br/>(Kafka)]
    end

    subgraph Scoring Engine
        C --> D[Freshness Scorer]
        D --> E[Score Store<br/>(PostgreSQL)]
    end

    subgraph Alerting Service
        D --> F[Threshold Evaluator]
        F --> G[Notification Hub<br/>(Slack, Email, PagerDuty)]
    end

    subgraph Dashboard
        E --> H[Visualization UI<br/(React, Grafana)]
        G --> H
    end

    style Ingestion Layer fill:#f9f9f9,stroke:#333,stroke-width:1px
    style Scoring Engine fill:#e8f5e9,stroke:#333,stroke-width:1px
    style Alerting Service fill:#fff3e0,stroke:#333,stroke-width:1px
    style Dashboard fill:#e3f2fd,stroke:#333,stroke-width:1px
```

*Усі мітки вузлів взяті в подвійні лапки, щоб відповідати вимогам синтаксису Mermaid.*

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

1. **Document Store** – центральне сховище для всіх файлів доказів (PDF, DOCX, YAML, скріншоти).  
2. **Metadata Extractor** – аналізує часові мітки файлів, вбудовані теги версій і OCR‑змінений текст.  
3. **Event Bus** – публікує події *EvidenceAdded* та *EvidenceUpdated* для споживачів низу.  
4. **Freshness Scorer** – гібридна модель, що поєднує детерміністичні евристики (вік, відмінність версій) та LLM‑засноване семантичне виявлення відхилень.  
5. **Score Store** – зберігає оцінки по‑артефактно з історичними даними про тренди.  
6. **Threshold Evaluator** – застосовує політикою визначені мінімальні оцінки (наприклад, ≥ 0.8) та генерує сповіщення.  
7. **Notification Hub** – надсилає миттєві повідомлення у Slack‑канали, електронну пошту або інструменти реагування (PagerDuty).  
8. **Visualization UI** – інтерактивні теплові карти, часові діаграми та деталізовані таблиці для аудиторов та менеджерів комплаєнсу.

---

## Детальний алгоритм оцінювання

Оцінка актуальності *S* ∈ [0, 1] обчислюється як зважена сума:

```
S = w1·Tnorm + w2·Vnorm + w3·Snorm
```

| Символ | Пояснення | Формула |
|--------|-----------|---------|
| **Tnorm** | Нормалізований фактор віку | `Tnorm = 1 - min(age_days / max_age, 1)` |
| **Vnorm** | Схожість версій | Відстань Левенштейна між поточним і попереднім рядком версії, масштабована до [0, 1] |
| **Snorm** | Семантичний дрейф | Оцінка схожості, згенерована LLM, між останнім текстовим сніпетом та останнім *затвердженим* сніпетом |

Типова конфігурація ваг: `w1=0.4, w2=0.2, w3=0.4`.

**Семантичний дрейф за допомогою LLM**  
1. Витяг тексту за допомогою OCR (для зображень) або нативних парсерів.  
2. Надсилаємо LLM (наприклад, Claude‑3.5, GPT‑4o) запит:

   ```
   Порівняй два уривки політики, наведених нижче. Подай оцінку схожості від 0 до 1, де 1 означає ідентичне значення.
   ---
   Excerpt A: <previous approved version>
   Excerpt B: <current version>
   ```

3. LLM повертає числову оцінку, що стає *Snorm*.

**Пороги**  
- **Критично**: S < 0.5 → Потрібно негайне усунення.  
- **Попередження**: 0.5 ≤ S < 0.75 → Оновити протягом 30 днів.  
- **Здорово**: S ≥ 0.75 → Дії не потрібні.

---

## Інтеграція з існуючими платформами комплаєнсу

| Платформа | Точка інтеграції | Перевага |
|-----------|------------------|----------|
| **Procurize** | Webhook EFSE для оновлення метаданих доказу в UI опитувальника. | Автоматична індикаторка актуальності поруч із кожним прикріпленням. |
| **ServiceNow** | Створення інцидентних тикетів, коли оцінка падає нижче порогу попередження. | Безшовна система тикетів для команд усунення. |
| **JIRA** | Автоматичне створення історій “Оновити доказ”, пов’язаних з уразливим опитувальником. | Прозорий робочий процес для власників продукту. |
| **Confluence** | Вбудовування живої теплової карти через macro, що читає дані зі Score Store. | Центральна база знань відображає актуальний стан комплаєнсу у реальному часі. |

Всі інтеграції спираються на **REST‑API** EFSE (`/evidence/{id}/score`, `/alerts`, `/metrics`). API відповідає OpenAPI 3.1, що дозволяє автоматично генерувати SDK для Python, Go та TypeScript.

---

## Дорожня карта впровадження

| Фаза | Ключові етапи | Приблизний обсяг |
|------|---------------|-------------------|
| **1. Основи** | Запуск Document Store, Event Bus, Metadata Extractor. | 2 тижні |
| **2. Прототип скори** | Реалізація детерміністичних Tnorm/Vnorm, підключення LLM через Azure OpenAI. | 3 тижні |
| **3. Сповіщення та панель** | Реалізація Threshold Evaluator, Notification Hub, теплової карти Grafana. | 2 тижні |
| **4. Хуки інтеграції** | Розробка Webhook‑ів для Procurize, ServiceNow, JIRA. | 1 тиждень |
| **5. Тестування та налаштування** | Навантажувальне тестування на 10 к доказів, калібрування ваг, CI/CD. | 2 тижні |
| **6. Запуск** | Пілотний проект у одній продуктовій лінії, збір зворотного зв’язку, масштабування на всю організацію. | 1 тиждень |

**Розгляди CI/CD**  
- **GitOps** (ArgoCD) для контролю версій моделей оцінки та порогових політик.  
- Секрети API ключів LLM керуються **HashiCorp Vault**.  
- Автоматизовані регресійні тести гарантують, що відомий «хороший» документ не падає нижче здорового порогу після змін коду.

---

## Кращі практики

1. **Тегуйте докази метаданими версії** – заохочуйте авторів додавати заголовок `Version: X.Y.Z` у кожен документ.  
2. **Визначте максимальний вік за політикою** – для ISO 27001 це може бути 12 місяців, для SOC 2 – 6 місяців; зберігайте обмеження у конфігураційній таблиці.  
3. **Періодичне донавчання LLM** – тонке налаштування LLM на вашій внутрішній політиці зменшує ризик галюцинацій.  
4. **Аудит‑трейл** – логуйте кожну подію оцінки; зберігайте дані мінімум 2 роки для аудиту.  
5. **Людина у циклі** – коли оцінка падає у критичний діапазон, вимагайте підтвердження від офіцера комплаєнсу перед автоматичним закриттям.

---

## Майбутні удосконалення

- **Багатомовний семантичний дрейф** – розширення OCR та LLM‑конвеєрів для підтримки не‑англійських доказів (наприклад, німецькі додатки до GDPR).  
- **Контекстуалізація за допомогою графових нейронних мереж (GNN)** – моделювання взаємозв’язків між артефактами (наприклад, PDF, що посилається на журнал тесту) для розрахунку **кластерної оцінки актуальності**.  
- **Прогнозування актуальності** – застосування часових моделей (Prophet, ARIMA) для передбачення, коли доказ стане застарілим, і проактивне планування оновлень.  
- **Перевірка нульових знань (zk‑SNARK)** – для надзвичайно конфіденційних доказів створювати докази того, що оцінка актуальності обчислена правильно без розкриття самого документа.

---

## Висновок

Застарілі докази – це «тихий вбивця» комплаєнсу, який підриває довіру та підвищує витрати на аудит. Впровадження **двигуна оцінювання актуальності доказів у реальному часі, керованого ШІ**, надає:

- **Видимість** – миттєві теплові карти, що показують, які прикріплення треба оновити.  
- **Автоматизація** – автоматичні сповіщення, створення тикетів та індикатори UI, що усувають ручні пошуки.  
- **Гарантії** – аудитори отримують живий, верифікований стан комплаєнсу замість статичного пакету.

Впровадження EFSE слідує передбачуваній, модульній дорожній карті та безшовно інтегрується з інструментами типу Procurize, ServiceNow та JIRA. Поєднуючи детерміністичні евристики та LLM‑заснований семантичний аналіз, система забезпечує надійні оцінки та дозволяє командам безпеки залишатися на крок попереду політичних змін.

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