
# Прогнозна оркестрація комплаєнсу з ШІ – Передбачення прогалин у питаннях перед їх надходженням

У швидкозмінному світі SaaS опитувальники безпеки стали фактичними вартовими на кожному етапі продажу, оцінці ризиків постачальників та регуляторному аудиті. Традиційна автоматизація зосереджується на **отриманні** правильного відповіді з бази знань у момент, коли задається питання. Хоча така «реактивна» модель економить час, вона залишає два критичні болючі місця:

1. **Сліпі ділянки** – відповіді можуть бути відсутніми, застарілими або неповними, змушуючи команди шукати докази в останню хвилину.  
2. **Реактивні зусилля** – команди реагують *після* отримання опитувальника, а не підготовуються заздалегідь.

А що, якби ваша платформа комплаєнсу могла **передбачати** ці прогалини *до* того, як опитувальник потрапить у вашу скриньку? Це й є обіцянка **Прогнозної оркестрації комплаєнсу** — робочого процесу, керованого ШІ, який безперервно моніторить політики, сховища доказів і сигнали ризику, а потім проактивно генерує або оновлює потрібні артефакти.

У цій статті ми розглянемо:

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

---

## 1. Чому прогноз краще, ніж отримання

| Аспект | Реактивне отримання | Прогнозна оркестрація |
|--------|--------------------|--------------------------|
| **Час** | Відповідь генерується **після** надходження запиту. | Докази готуються **заздалегідь**. |
| **Ризик** | Високий – відсутність або застарілі дані можуть призвести до провалів у комплаєнсі. | Низький – безперервна валідація вчасно виявляє прогалини. |
| **Зусилля** | Пікові навантаження під час кожного опитувальника. | Стійкі, автоматизовані зусилля, розподілені у часі. |
| **Довіра стейкхолдерів** | Змішана – останні виправлення підірвають довіру. | Висока – задокументований, аудитований слід проактивних дій. |

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

---

## 2. Основні архітектурні компоненти

Нижче — високорівнева схема прогнозного двигуна комплаєнсу. Діаграму створено за допомогою Mermaid, який є кращим вибором, ніж GoAT.

```mermaid
graph TD
    A["Сховище політик та доказів"] --> B["Детектор змін (Diff Engine)"]
    B --> C["Модель ризику за часовими рядами"]
    C --> D["Двигун прогнозування прогалин"]
    D --> E["Проактивний генератор доказів"]
    E --> F["Шар оркестрації (Procurize)"]
    F --> G["Панель комплаєнсу"]
    H["Зовнішні сигнали"] --> C
    I["Зворотний зв'язок користувачів"] --> D
```

* **Сховище політик та доказів** – централізоване сховище (git, S3, БД) з політиками **[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)**, **[ISO 27001](https://www.iso.org/standard/27001)**, **[GDPR](https://gdpr.eu/)** та супутні артефакти (скріншоти, логи, сертифікати).  
* **Детектор змін** – безперервний diff‑engine, який виявляє будь‑які зміни в політиках або доказах.  
* **Модель ризику за часовими рядами** – навчається на історичних даних опитувальників і прогнозує ймовірність запиту кожного контролю в найближчому майбутньому.  
* **Двигун прогнозування прогалин** – поєднує ризикові оцінки зі сигналами змін, щоб визначити «вразливі» контролі, які не мають свіжих доказів.  
* **Проактивний генератор доказів** – використовує Retrieval‑Augmented Generation (RAG) для створення наративних доказів, автоматично додає версіоновані файли та зберігає їх назад у сховищі.  
* **Шар оркестрації** – надає згенерований контент через API Procurize, роблячи його миттєво доступним при надходженні опитувальника.  
* **Зовнішні сигнали** – потоки загроз, оновлення регуляторних вимог та аудиторські тренди, які збагачують модель ризику.  
* **Зворотний зв'язок користувачів** – аналітики підтверджують або виправляють автогенеровані відповіді, повертаючи супервізійні сигнали для покращення моделі.

---

## 3. Дані‑основа – паливо для прогнозу

### 3.1 Історичний корпус опитувальників

Потрібно мінімум **12 місяців** відповілених опитувальників для навчання якісної моделі. Кожен запис має включати:

* Ідентифікатор питання (наприклад, “SOC‑2 CC6.2”)  
* Категорію контролю (доступ, шифрування тощо)  
* Часову позначку відповіді  
* Використану версію доказу  
* Результат (прийнято, вимагалося уточнення, відхилено)

### 3.2 Історія версій доказів

Кожний артефакт має бути підконтрольним у системі версіонування. Метадані у стилі Git (хеш коміту, автор, дата) дозволяють Diff Engine зрозуміти *що* змінилося і *коли*.

### 3.3 Зовнішній контекст

* **Регуляторні календарі** – майбутні оновлення **[GDPR](https://gdpr.eu/)**, ревізії **[ISO 27001](https://www.iso.org/standard/27001)**.  
* **Попередження про інциденти у галузі** – сплески ransomware підвищують ймовірність запитань щодо реагування на інциденти.  
* **Оцінки ризику постачальників** – внутрішній ризиковий рейтинг запитальника може схиляти модель до більш ретельних відповідей.

---

## 4. Побудова прогнозного двигуна

Нижче практичний план впровадження, орієнтований на команду, що вже використовує Procurize.

### 4.1 Налаштування безперервного моніторингу дифів

```bash
# Приклад використання git diff для виявлення змін у доказах
while true; do
  git fetch origin main
  changes=$(git diff --name-only origin/main HEAD -- evidence/)
  if [[ -n "$changes" ]]; then
    curl -X POST http://orchestrator.local/diff-event \
      -H "Content-Type: application/json" \
      -d "{\"files\": \"$changes\"}"
  fi
  sleep 300  # запуск кожні 5 хвилин
done
```

*Скрипт надсилає webhook у шар оркестрації щоразу, коли змінюються файли доказів.*

### 4.2 Навчання моделі ризику за часовими рядами

```python
from prophet import Prophet
import pandas as pd

# Завантажуємо історичні дані запитів
df = pd.read_csv('questionnaire_log.csv')
df['ds'] = pd.to_datetime(df['request_date'])
df['y'] = df['request_count']  # кількість разів, коли контроль був запитаний

m = Prophet(yearly_seasonality=True, weekly_seasonality=False)
m.fit(df[['ds','y']])

future = m.make_future_dataframe(periods=30)
forecast = m.predict(future)
forecast[['ds','yhat']].tail()
```

*`yhat` — прогнозована ймовірність для кожного дня протягом наступного місяця.*

### 4.3 Логіка прогнозування прогалин

```python
def forecast_gaps(risk_forecast, evidences):
    gaps = []
    for control, prob in risk_forecast.items():
        if prob > 0.7:  # поріг високого ризику
            latest = evidences.get_latest_version(control)
            if latest.is_stale(days=30):
                gaps.append(control)
    return gaps
```

Функція повертає список контролів, які ймовірно будуть запитані і у яких докази застарілі.

### 4.4 Автогенерація доказів за допомогою RAG

Procurize вже має RAG‑endpoint. Приклад запиту:

```json
POST /api/v1/rag/generate
{
  "control_id": "CC6.2",
  "evidence_context": ["останній аудит SOC2", "журнали доступу за вересень 2024"],
  "temperature": 0.2,
  "max_tokens": 500
}
```

Відповідь — markdown‑фрагмент, готовий для включення в опитувальник, із заповненими полями для прикріплення файлів.

### 4.5 Інтеграція в UI Procurize

Додати нову панель **«Прогнозні пропозиції»** у редактор опитувальника. При відкритті нового опитувальника бек‑енд викликає:

```bash
GET /api/v1/predictive/suggestions?project_id=12345
```

і отримує:

```json
{
  "suggestions": [
    {
      "control_id": "CC6.2",
      "generated_answer": "Наші привілейовані облікові записи захищені багатофакторною автентифікацією…",
      "evidence_id": "evidence-2024-09-15-abcdef",
      "confidence": 0.92
    },
    ...
  ]
}
```

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

---

## 5. Вимірювання бізнес‑впливу

| Показник | До впровадження прогнозного двигуна | Через 6 міс. |
|----------|--------------------------------------|---------------|
| Середній час обороту опитувальника | 12 днів | **4 дні** |
| Відсоток відповідей зі застарілими доказами | 28 % | **5 %** |
| Овертайм інженерів за квартал | 160 годин | **45 годин** |
| Рівень провалів аудиту (прогалини у доказах) | 3,2 % | **0,4 %** |
| NPS серед зацікавлених сторін | 42 | **71** |

Дані отримані під час пілотного проєкту в середній SaaS‑компанії (≈ 250 співробітників). Скорочення ручної праці привело до оціненої економії **280 тис. $** у перший рік.

---

## 6. Управління та аудитованість

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

* Версію моделі, використану для кожної автогенерованої відповіді.  
* Час прогнозу та відповідний ризиковий бал.  
* Дії людини (прийнято/відхилено, редагування).  

Звіт у форматі CSV/JSON можна приєднувати безпосередньо до аудиторських пакетів, задовольняючи вимоги регуляторів щодо «пояснюваного ШІ» у рішеннях комплаєнсу.

---

## 7. План запуску – 4‑тижневий спринт

| Тиждень | Мета | Результат |
|--------|------|-----------|
| 1 | Завантажити історичні дані опитувальників та сховище доказів у data lake. | Нормалізований CSV + сховище доказів у Git. |
| 2 | Реалізувати webhook моніторингу діфів та базову модель ризику (Prophet). | Запущений webhook + ноутбук з прогнозом ризику. |
| 3 | Побудувати двигун прогнозу прогалин і підключити до RAG‑API Procurize. | API `/predictive/suggestions`. |
| 4 | UI‑поліпшення, цикл зворотного зв'язку, пілот з 2‑ма командами. | Панель «Прогнозні пропозиції», дашборд моніторингу. |

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

---

## 8. Подальші напрямки

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

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