
# Оценяване в реално време на свежестта на доказателствата, подпомогнато от AI, за въпросници за сигурност

## Въведение

Security questionnaires са първият контакт за доверието между SaaS доставчиците и техните клиенти. Доставчиците трябва да прикрепят откъси от политики, одитни доклади, скрийншотове на конфигурации или тестови логове като **доказателства**, за да докажат съответствие. Докато генерирането на тези доказателства вече е автоматизирано в много организации, остава критичен слеп кът: **колко свежо е доказателството**?

PDF, последно обновен преди шест месеца, може да бъде прикрепен към въпросник, отговорен днес, излагайки доставчика на риск от одитни находки и подкопавайки доверието на клиента. Ръчното проверяване на свежестта е времеемко и склонно към грешки. Решението е да се позволи на **генеративен AI** и **retrieval‑augmented generation (RAG)** да оценяват, скорират и известяват за актуалността на доказателствата непрекъснато.

Тази статия представя пълен, готов за продукция, дизайн за **AI‑движим Real‑Time Evidence Freshness Scoring Engine (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 "Слой за приемане"
        A["Хранилище за документи<br/>(S3, Git, SharePoint)"] --> B[Извличач на метаданни]
        B --> C[Събитийна шина<br/>(Kafka)]
    end

    subgraph "Двигател за оценяване"
        C --> D[Оценител на свежест]
        D --> E[Хранилище за оценки<br/>(PostgreSQL)]
    end

    subgraph "Сервиз за известяване"
        D --> F[Оценител на прагове]
        F --> G[Хъб за известия<br/>(Slack, Email, PagerDuty)]
    end

    subgraph "Табло"
        E --> H[Потребителски интерфейс за визуализация<br/>(React, Grafana)]
        G --> H
    end

    style "Слой за приемане" fill:#f9f9f9,stroke:#333,stroke-width:1px
    style "Двигател за оценяване" fill:#e8f5e9,stroke:#333,stroke-width:1px
    style "Сервиз за известяване" fill:#fff3e0,stroke:#333,stroke-width:1px
    style "Табло" fill:#e3f2fd,stroke:#333,stroke-width:1px
```

*Всички етикети на възлите са в двойни кавички, за да отговарят на синтаксиса на Mermaid.*

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

1. **Хранилище за документи** – Централно хранилище за всички файлове с доказателства (PDF, DOCX, YAML, скрийншоти).  
2. **Извличач на метаданни** – Прочита времеви печати, вградени версии и OCR‑ва текстови промени.  
3. **Събитийна шина** – Публикува събития *EvidenceAdded* и *EvidenceUpdated* за потребители надолу по потока.  
4. **Оценител на свежест** – Хибриден модел, комбиниращ детерминистични хевристики (възраст, разлика във версии) и LLM‑базирано откриване на семантичен дрейф.  
5. **Хранилище за оценки** – Съхранява скоровете за всеки артефакт с исторически данни.  
6. **Оценител на прагове** – Прилага политически зададени минимални скорове (например ≥ 0.8) и генерира известия.  
7. **Хъб за известия** – Изпраща съобщения в Slack, имейл групи или инструменти за реакция (PagerDuty).  
8. **Потребителски интерфейс за визуализация** – Интерактивни топлинни карти, времеви графики и таблични изгледи за одитори и мениджъри по съответствие.

---

## Детайли на оценителния алгоритъм

Свежестният скор *S* ∈ [0, 1] се изчислява като претеглена сума:

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

| Символ | Значение | Изчисление |
|--------|----------|------------|
| **Tnorm** | Нормализиран фактор за възраст | `Tnorm = 1 - min(age_days / max_age, 1)` |
| **Vnorm** | Сходство на версии | Levenshtein разстояние между текущата и предишната версия, мащабирано към [0, 1] |
| **Snorm** | Семантичен дрейф | LLM‑генерирана сходство между последния текстов момент и последната *одобрена* версия |

Типична конфигурация на теглата: `w1=0.4, w2=0.2, w3=0.4`.

### Семантичен дрейф с LLM
1. Извлича се чист текст чрез OCR (за изображения) или вградени парсери.  
2. Препраща се към LLM (напр. Claude‑3.5, GPT‑4o) с промпт:

   ```
   Compare the two policy excerpts below. Provide a similarity score between 0 and 1 where 1 means identical meaning.
   ---
   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** | Уебхук от EFSE за обновяване на метаданните в UI‑то на въпросника. | Автоматична марка за свежест до всяко прикачено доказателство. |
| **ServiceNow** | Създаване на инцидент, когато скоровете паднат под предупредителния праг. | Безпроблемно създаване на тикет за екипа за корекция. |
| **JIRA** | Автоматично генериране на story “Update Evidence”, свързано с засегнатия въпросник. | Прозрачен работен процес за product owners. |
| **Confluence** | Вграждане на жив топлинен график чрез macro, който чете от хранилището за скорове. | Централната база знание отразява текущото състояние на съответствието. |

Всички интеграции се базират на **RESTful** крайни точки, предоставяни от EFSE API (`/evidence/{id}/score`, `/alerts`, `/metrics`). API‑то следва OpenAPI 3.1, което позволява автоматично генериране на SDK‑ове за Python, Go и TypeScript.

---

## План за внедряване

| Фаза | Етапи | Приблизителен труд |
|------|-------|--------------------|
| **1. Основи** | Деплой на хранилище за документи, събитийна шина и извличач на метаданни. | 2 седмици |
| **2. Прототип на оценител** | Изграждане на детерминистичната част (Tnorm/Vnorm) и интеграция с LLM чрез Azure OpenAI. | 3 седмици |
| **3. Известяване & Табло** | Имплементиране на оценител на прагове, хъб за известия и Grafana топлинна карта. | 2 седмици |
| **4. Куки за интеграция** | Разработване на уебхукове за Procurize, ServiceNow, JIRA. | 1 седмица |
| **5. Тестове & Тунинг** | Тест с 10 k доказателства, калибриране на теглата, добавяне на CI/CD. | 2 седмици |
| **6. Пускане** | Пилот с един продуктов ред, събиране на обратна връзка, мащабиране в цялата организация. | 1 седмица |

**CI/CD съображения**
- Използвайте **GitOps** (ArgoCD) за версииране на модели за оценяване и политически прагове.  
- Тайните за LLM API‑ключове се управляват чрез **HashiCorp Vault**.  
- Автоматични регресионни тестове гарантират, че известен документ никога не пада под здравия праг след промяна в кода.

---

## Най‑добри практики

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

---

## Възможни бъдещи подобрения

- **Мултиезичен семантичен дрейф** – Разширяване на OCR и LLM пайплайна за поддръжка на неанглийски документи (например немски GDPR приложения).  
- **Графови невронни мрежи (GNN) за контекст** – Моделиране на отношения между артефакти (PDF, който реферира тестов лог) за изчисляване на **клъстерен свежестен скор**.  
- **Прогнозиране на свежест** – Прилагане на времеви модели (Prophet, ARIMA) за предвиждане кога доказателството ще остарее и автоматично планиране на актуализации.  
- **Zero‑Knowledge доказателства** – За изключително чувствителни документи генериране на zk‑SNARK доказателства, че свежестният скор е изчислен правилно без разкриване на съдържанието.

---

## Заключение

Остарели доказателства са тихият убийца на съответствието, който изтощава доверието и увеличава разходите за одит. С внедряването на **AI‑движим Real‑Time Evidence Freshness Scoring Engine** организациите получават:

- **Видимост** – Моментални топлинни карти, показващи кои прикачени документи са изтекли.  
- **Автоматизация** – Автоматични известия, създаване на тикети и UI марки, премахващи ръчното търсене.  
- **Увереност** – Одиторите виждат живо, проверено състояние, вместо статичен, потенциално остарял пакет.  

Осъществяването на EFSE следва предвидим, модулен път, който се интегрира безпроблемно с инструменти като Procurize, ServiceNow и JIRA. Съчетаването на детерминистични хевристики и LLM‑базирана семантична оценка осигурява надеждни скорове и позволява на екипите за сигурност да бъдат една стъпка пред политическите измествания.

Започнете да измервате свежестта днес и превърнете своята библиотека с доказателства от пасивна отговорност в стратегически актив.