
# Мультимодальний ШІ для видобутку доказів в анкетах безпеки

Анкети безпеки — це «ворота» кожної B2B SaaS‑угоди. Постачальникам просять надати докази — політики у PDF, схеми архітектури, фрагменти коду, журнали аудиту та навіть скріншоти панелей. Традиційно команди безпеки та відповідності витрачають **години**, перебираючи репозиторії, копіюючи файли та вручну додаючи їх у поля анкети. Результат — вузьке місце, що уповільнює цикл продажів, збільшує кількість помилок і створює прогалини в аудиті.

**Procurize** вже створив потужну уніфіковану платформу для управління анкетами, розподілу завдань та генерації відповідей за допомогою ШІ. Наступний крок — **автоматизація самого збору доказів**. Використовуючи **мультимодальний генеративний ШІ** — моделі, що розуміють текст, зображення, таблиці та код в одному конвеєрі — організації можуть миттєво знаходити потрібний артефакт для будь‑якого пункту анкети, незалежно від формату.

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

1. Чому підхід лише однієї модальності (чисті текстові LLM) не підходить для сучасних навантажень з відповідності.  
2. Архітектуру двигуна мультимодального видобутку доказів, побудованого на базі Procurize.  
3. Як навчати, оцінювати та постійно покращувати систему за допомогою технік **Generative Engine Optimization (GEO)**.  
4. Конкретний end‑to‑end приклад — від питання безпеки до автоматично прикріпленого доказу.  
5. Питання управління, безпеки та аудиту.  

> **Ключовий висновок:** Мультимодальний ШІ перетворює отримання доказів з ручної роботи у повторювану, аудиторську службу, скорочуючи час відповіді на анкети до 80 % при збереженні суворих вимог до відповідності.

---

## 1. Обмеження текстових LLM у роботі з анкетами

Сьогодні більшість автоматизації, що базується на ШІ, покладається на великі мовні моделі (LLM), які відмінно справляються **з генерацією тексту** та **семантичним пошуком**. Вони можуть витягувати положення політик, підсумовувати аудиторські звіти та навіть формувати нарративні відповіді. Однак докази відповідності рідко є лише текстовими:

| Тип доказу | Типовий формат | Складність для лише‑текстової LLM |
|------------|----------------|--------------------------------------|
| **Схеми архітектури** | PNG, SVG, Visio | Потребує розуміння зображень |
| **Файли конфігурації** | YAML, JSON, Terraform | Структуровані, часто вкладені |
| **Фрагменти коду** | Java, Python, Bash | Потрібне синтаксично‑усвідомлене вилучення |
| **Скріншоти панелей** | JPEG, PNG | Потрібно «читати» UI‑елементи, часові штампи |
| **Таблиці у PDF‑звітах** | PDF, скановані зображення | OCR + парсинг таблиць необхідні |

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

---

## 2. Архітектура двигуна мультимодального видобутку доказів

Нижче — високорівнева діаграма запропонованого двигуна, інтегрована у ядро анкети Procurize.

```mermaid
graph TD
    A["Користувач надсилає пункт анкети"] --> B["Сервіс класифікації питань"]
    B --> C["Оркестратор мульти‑модального пошуку"]
    C --> D["Текстовий векторний магазин (FAISS)"]
    C --> E["Магазин векторів зображень (CLIP)"]
    C --> F["Магазин векторів коду (CodeBERT)"]
    D --> G["Семантичне зіставлення (LLM)"]
    E --> G
    F --> G
    G --> H["Двигун ранжування доказів"]
    H --> I["Збагачення метаданими відповідності"]
    I --> J["Авто‑додавання до завдання Procurize"]
    J --> K["Перевірка людиною (HITL)"]
    K --> L["Запис у журнал аудиту"]
```

### 2.1 Основні компоненти

1. **Сервіс класифікації питань** — використовує досягнуту LLM для маркування вхідних пунктів анкети типами доказів (наприклад, «схема мережі», «політика безпеки PDF», «Terraform‑план»).  
2. **Оркестратор мульти‑модального пошуку** — пересилає запит до відповідних векторних магазинів згідно з класифікацією.  
3. **Векторні магазини**  
   * **Текстовий магазин** — індекс FAISS, створений з усіх політик, аудиторських звітів та markdown‑файлів.  
   * **Магазин зображень** — вектори CLIP, згенеровані з усіх діаграм, скріншотів та SVG у сховищі документів.  
   * **Магазин коду** — вбудовування CodeBERT для всіх вихідних файлів, конфігурацій CI/CD та IaC‑шаблонів.  
4. **Шар семантичного зіставлення** — трансформер, що об’єднує вектор запиту з вектором кожної модальності, повертаючи ранжований список кандидат‑артефактів.  
5. **Двигун ранжування доказів** — застосовує **GEO‑гістику**: актуальність, статус у системі контролю версій, релевантність тегів відповідності та оцінка довіри LLM.  
6. **Збагачення метаданими відповідності** — додає SPDX‑ліцензії, часові штампи аудиту та теги захисту даних до кожного артефакту.  
7. **Перевірка людиною (HITL)** — інтерфейс у Procurize показує топ‑3 пропозиції; рецензент може схвалити, замінити або відхилити.  
8. **Запис у журнал аудиту** — кожне автододавання фіксується з криптографічним хешем, підписом рецензента та оцінкою AI, задовольняючи вимоги SOX та [GDPR](https://gdpr.eu/).

### 2.2 Конвеєр інжестії даних

1. **Кравлер** сканує корпоративні файлові сховища, Git‑репозиторії, хмари.  
2. **Препроцесор** виконує OCR сканованих PDF (Tesseract), витягує таблиці (Camelot) та конвертує файли Visio у SVG.  
3. **Ембеддер** генерує вектори для кожної модальності та зберігає їх разом із метаданими (шлях файлу, версія, власник).  
4. **Інкрементальне оновлення** — мікросервіс‑watchdog ре-ембедує лише змінені активи, підтримуючи векторні магазини актуальними в майже реальному часі.

---

## 3. Generative Engine Optimization (GEO) для видобутку доказів

**GEO** — це системний підхід до налаштування всієї AI‑платформи (а не лише мовної моделі), щоб покращити головний KPI (час відповіді на анкету), зберігаючи якість відповідності.

| Фаза GEO | Мета | Ключові метрики |
|----------|------|-----------------|
| **Якість даних** | Забезпечити, щоб ембеддинги відображали актуальний стан відповідності | % активів оновлених < 24 год |
| **Промпт‑інжиніринг** | Створювати запити, що спрямовують модель до правильної модальності | Оцінка довіри пошуку |
| **Калібрування моделі** | Узгодити пороги довіри з рівнем прийняття рецензентів | Рівень хибнопозитивних < 5 % |
| **Зворотний зв’язок** | Захоплювати дії рецензентів для донастроювання класифікації та ранжування | Середній час до схвалення (MTTA) |
| **Безперервна оцінка** | Проводити нічні A/B‑тести на валідаційному наборі історичних питань | Скорочення середнього часу відповіді |

### 3.1 Приклад промпту для мульти‑модального пошуку

```
[QUESTION] Provide the most recent [SOC 2] Type II audit report covering data encryption at rest.

[CONTEXT] Retrieve a PDF document that includes the relevant audit section. Return the document ID, page range, and a brief excerpt.

[MODALITY] text
```

Оркестратор парсить тег `[MODALITY]` і запитує **текстовий магазин** лише, що значно зменшує шум від зображень чи коду.

### 3.2 Адаптивні пороги

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

---

## 4. End‑to‑End приклад: від питання до автододаного доказу

### 4.1 Питання

> *«Додайте схему, що показує потік даних клієнта від інжесту до зберігання, включаючи точки шифрування.»*

### 4.2 Покроковий процес

| Крок | Дія | Результат |
|------|-----|-----------|
| 1 | Користувач створює новий пункт анкети в Procurize. | ID пункту `Q‑2025‑1123`. |
| 2 | Сервіс класифікації позначає запит як `evidence_type: network diagram`. | Модальність = **зображення**. |
| 3 | Оркестратор надсилає запит у CLIP‑магазин зображень. | Отримано 12 кандидат‑векторів. |
| 4 | Шар семантичного зіставлення обчислює косинусну схожість між вектором запиту та кожним вектором. | Топ‑3 оцінки: 0,92; 0,88; 0,85. |
| 5 | Двигун ранжування оцінює актуальність (останнє змінено 2 дн., тег «encryption») | Остаточний вибір: діаграма `arch‑data‑flow‑v3.svg`. |
| 6 | UI HITL показує діаграму з прев’ю, метаданими (автор, версія, хеш). | Рецензент клацає **Схвалити**. |
| 7 | Система автоматично додає діаграму до `Q‑2025‑1123` та записує журнал аудиту. | Журнал показує довіру AI 0,91, підпис рецензента, час. |
| 8 | Модуль генерації відповіді формує нарратив, що посилається на діаграму. | Відповідь готова до експорту. |

Загальний час від кроку 1 до кроку 8 — **≈ 45 секунд**, у порівнянні з типово **15‑20 хвилин** ручного пошуку.

---

## 5. Управління, безпека та аудиторський слід

Автоматизація обробки доказів піднімає ряд важливих питань:

1. **Витік даних** — сервіси ембеддингу мають працювати у **Zero‑Trust VPC** з жорсткими IAM‑ролями. Жодні векторні дані не покидають корпоративну мережу.  
2. **Контроль версій** — кожен артефакт зберігається разом з **Git‑хешем** (або версією об’єкта сховища). При оновленні документу старі ембеддинги автоматично анулюються.  
3. **Пояснюваність** — двигун ранжування логічно фіксує оцінки схожості та ланцюжок промптів, що дозволяє відповідальним особам простежити *чому* був обраний конкретний файл.  
4. **Відповідність нормативам** — додавання SPDX‑ідентифікаторів та категорій обробки згідно [GDPR](https://gdpr.eu/) до кожного артефакту забезпечує вимоги до походження доказів для [ISO 27001](https://www.iso.org/standard/73906.html) Annex A.  
5. **Політики збереження** — автоматичні роботи **purge** очищають ембеддинги документів, які старші за встановлену політику зберігання, запобігаючи накопиченню застарілих доказів.

---

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

### 6.1 Мульти‑модальне отримання як сервіс (RaaS)

Відкрити оркестратор via **GraphQL API**, щоб інші внутрішні інструменти (наприклад, автоматичні перевірки відповідності у CI/CD) могли запитувати докази без проходження повного UI анкети.

### 6.2 Інтеграція з радаром регуляторних змін

Поєднати двигун з **Regulatory Change Radar** у Procurize. При виявленні нових нормативів автоматично перекласифікувати уразливі питання та ініціювати новий пошук доказів, гарантувавши актуальність прикріплених артефактів.

### 6.3 Федероване навчання між організаціями

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

---

## 7. Висновок

Анкети безпеки залишатимуться фундаментальним інструментом управління ризиками постачальників, проте ручна робота зі збіркою доказів стає все менш прийнятною. Завдяки **мультимодальному ШІ** — поєднанню розуміння тексту, зображень та коду — Procurize може перетворити збір доказів у автоматизовану, аудиторську службу. Використання **Generative Engine Optimization** гарантує постійне підвищення якості, узгоджуючи довіру AI з очікуваннями людей та нормативними вимогами.

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

---

## <span class='highlight-content'>Дивитися</span> також

- [Мультимодальний пошук з CLIP та FAISS – до масштабного корпоративного пошуку](https://arxiv.org/abs/2103.00020)  
- [Generative Engine Optimization: Framework for Continuous AI Improvement](https://www.mitre.org/publications/technical-papers/generative-engine-optimization)  
- [Zero‑Trust Architecture for AI‑Powered Compliance Platforms](https://cloud.google.com/solutions/zero-trust-ai)  
- [ISO 27001 Annex A – вимоги до управління доказами](https://www.iso.org/standard/73906.html)