
# Prognoziniai pasitikėjimo įvertiniai su DI pagrįstu tiekėjo klausimyno atsakymais

Spartųjame SaaS pasaulyje kiekvienas naujas bendradarbiavimas prasideda **saugumo klausimynu**. Nepriklausomai nuo to, ar tai [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2) audito užklausa, [GDPR](https://gdpr.eu/) duomenų apdorojimo priedas, ar individualizuotas tiekėjo rizikos vertinimas, formų kiekis sukelia spūstį, kuris sulėtina pardavimų ciklus, padidina teisinių išlaidų sumas ir įveda žmonių klaidas.  

Kas būtų, jei jau surinktus atsakymus paverstumėte **vienu, duomenimis pagrįstu pasitikėjimo įvertiniu**? DI valdomas rizikos įvertinimo variklis gali įsisavinti neapdorotus atsakymus, svertuoti juos pagal pramonės standartus ir pateikti prognozinį įvertinimą, kuris akimirksniu nurodo, kaip saugus yra tiekėjas, kiek skubiąsias kontaktų priemones reikia imtis ir kur turėtų būti koncentruoti remonto veiksmai.

Šiame straipsnyje apžvelgiama visa **DI pagrįsta prognozinio pasitikėjimo įvertinimo** gyvavimo ciklas – nuo neapdoroto klausimyno įkėlimo iki veiksnių pritaikomų skydelių – ir parodoma, kaip platformos, tokios kaip Procurize, gali visą procesą padaryti sklandžiu, audituojamu ir mastingu.

---

## Kodėl tradicinis klausimyno valdymas nesugeba

| Problema | Verslo poveikis |
|----------|-----------------|
| **Rankinis duomenų įvedimas** | Valandų pakartotinis darbas su kiekvienu tiekėju |
| **Subjektyvi interpretacija** | Nenuoseklūs rizikos vertinimai tarp komandų |
| **Išsklaidytas įrodymų saugojimas** | Sunkumai įrodyti atitiktį auditų metu |
| **Vėluojantys atsakymai** | Prarasti sandoriai dėl lėto atsakymo laiko |

Šios problemos plačiai aprašytos esamoje tinklaraščio bibliotekoje (pvz., *Paslėptos rankinio saugumo klausimyno valdymo išlaidos*). Nors centralizavimas padeda, jis automatiškai nesuteikia įžvalgų, **kiek rizikingas** iš tiesų yra konkretus tiekėjas. Čia ir ateina rizikos įvertinimas.

---

## Pagrindinė koncepcija: nuo atsakymų iki įvertinimų

Essence prognozinio pasitikėjimo įvertinimo yra **daugiakryptis modelis**, kuris susieja klausimyno laukus su skaitine verte nuo 0 iki 100. Aukštosios vertės rodo stiprią atitikties poziciją; žemos vertės – galimas pavojus.

Svarbiausi elementai:

1. **Struktūruotas duomenų sluoksnis** – Kiekvienas klausimyno atsakymas saugomas normalizuotoje schemoje (pvz., `question_id`, `answer_text`, `evidence_uri`).
2. **Semantinis praturtinimas** – Natūralios kalbos apdorojimas (NLP) nagrinėja laisvo teksto atsakymus, išgauna susijusias politikos nuorodas ir klasifikuoja ketinimus (pvz., *„Mes šifruojame duomenis poilsio metu“* → žyma *Šifravimas*).
3. **Standartų susiejimas** – Kiekvienas atsakymas susiejamas su valdymo sistemomis, tokiomis kaip **SOC 2**, **[ISO 27001](https://www.iso.org/standard/27001)**, arba **[GDPR](https://gdpr.eu/)**. Tai sukuria **aprėpties matricą**, rodančią, kurie kontrolės elementai yra aptarti.
4. **Svertų variklis** – Kontrolės svertamos pagal tris faktorius:
   - *Kritiškumas* (verslo poveikis)
   - *Brandumas* (kaip pilnai kontrolė įgyvendinta)
   - *Įrodymų stiprumas* (ar prisijungti palaikantys dokumentai)
5. **Prognozinis modelis** – Mašininio mokymosi modelis, apmokytas pagal ankstesnius auditų rezultatus, prognozuoja, kokia tikimybė tiekėjui nepavyks artėjančio vertinimo. Išvestis – **pasitikėjimo įvertinimas**.

Visas duomenų srautas vykdomas automatiškai kiekvieną kartą, kai pateikiamas naujas klausimynas arba atnaujinamas egzistuojantis atsakymas.

---

## Žingsnis po žingsnio architektūra

Žemiau pateikiama aukšto lygio mermaid diagrama, vaizduojanti duomenų srautą nuo įkėlimo iki įvertinimo vizualizacijos.

```mermaid
graph TD
    A["Įkelti klausimyną (PDF/JSON)"] --> B["Normalizacijos paslauga"]
    B --> C["NLP praturtinimo variklis"]
    C --> D["Kontrolės susiejimo sluoksnis"]
    D --> E["Svertų ir įvertinimo variklis"]
    E --> F["Prognozinis ML modelis"]
    F --> G["Pasitikėjimo įvertinimo saugykla"]
    G --> H["Skydelis ir API"]
    H --> I["Įspėjimų ir darbo srauto automatizavimas"]
```

*Visi mazgų pavadinimai įterpti dvigubomis kabutėmis, kaip reikalaujama.*

---

## Kaip sukurti įvertinimo modelį: praktiška vadovėlis

### 1. Duomenų rinkimas ir žymėjimas

- **Istoriniai auditai** – Surinkite ankstesnių tiekėjų vertinimų rezultatus (pavyksta/nepavyksta, remonto laikas).  
- **Savybės** – Kiekvienam klausimynui sukurkite savybes, tokias kaip *kontrolės aprėpties procentas*, *vidutinio įrodymo dydžio vidurkis*, *NLP iškeltas nuotaikos tonas*, ir *laikas nuo paskutinio atnaujinimo*.
- **Žymė** – Binarinis tikslas (0 = aukšta rizika, 1 = žema rizika) arba nuolatinė rizikos tikimybė.

### 2. Modelio pasirinkimas

| Modelis | Stiprybės | Įprastas naudojimas |
|---------|-----------|---------------------|
| Logistinis regresijos modelis | Interpretuojami koeficientai | Greita bazinė linija |
| Gradientiniai sustiprintų medžių metodai (pvz., XGBoost) | Tvarko mišrius duomenų tipus, nelineariškumus | Įvertinimas gamyboje |
| Daugiasluoksiai neuroniniai tinklai su dėmesiu | Įgauna kontekstą laisvo teksto atsakymuose | Pažengusi NLP integracija |

### 3. Mokymas ir validacija

```python
import xgboost as xgb
from sklearn.model_selection import train_test_split
X_train, X_test, y_train, y_test = train_test_split(features, labels, test_size=0.2, random_state=42)

dtrain = xgb.DMatrix(X_train, label=y_train)
dtest  = xgb.DMatrix(X_test,  label=y_test)

params = {
    "objective": "binary:logistic",
    "eval_metric": "auc",
    "learning_rate": 0.05,
    "max_depth": 6
}
model = xgb.train(params, dtrain, num_boost_round=200, evals=[(dtest, "eval")], early_stopping_rounds=20)
```

Modelio **AUC** (plotų po kreive) turėtų viršyti 0,85, kad įvertinimai būtų patikimi. Svarbiausios savybės diagramoje padeda paaiškinti, kodėl įvertinimas nukrito žemiau slenksčio – tai būtina atitikties dokumentavimui.

### 4. Įvertinimo normalizavimas

Žaliąsias tikimybes (0‑1) paverčiame į 0‑100 diapazoną:

```python
def normalize_score(prob):
    return round(prob * 100, 2)
```

Dažniausiai naudojamas **70** ribinis “žalias” slenkstis; įvertinimai tarp **40‑70** sukelia **peržiūros** darbo eigą, o **žemiau 40** – **escalation** įspėjimą.

---

## Integracija su Procurize: nuo teorijos iki gamybos

Procurize jau suteikia šiuos pagrindinius komponentus:

- **Vieningą klausimyno saugyklą** – Centrinį visų klausimyno šablonų ir atsakymų saugojimą.
- **Real‑time bendradarbiavimą** – Komandos gali komentuoti, prisegti įrodymus ir stebėti versijų istoriją.
- **API‑first architektūrą** – Leidžia išorinių įvertinimo servisų gauti duomenis ir grąžinti įvertinimus.

### Integracijos šablonas

1. **Webhook** – Kai klausimynas pažymimas *Paruoštas peržiūrai*, Procurize išsiunčia webhook su klausimyno ID.  
2. **Duomenų gauti** – Įvertinimo servisas kviečia `/api/v1/questionnaires/{id}` galinį tašką, kad gautų normalizuotus atsakymus.  
3. **Įvertinimo skaičiavimas** – Servisas įvykdo ML modelį ir sukuria pasitikėjimo įvertinimą.  
4. **Rezultatų siuntimas** – Įvertinimas ir pasitikėjimo intervalas grąžinami per `POST /api/v1/questionnaires/{id}/score`.  
5. **Skydelio atnaujinimas** – Procurize UI rodo naują įvertinimą, prideda vizualinį rizikos matuoklį ir suteikia vieno spustelėjimo veiksmus (pvz., *Paprašyti papildomų įrodymų*).

Supaprastinta srauto diagrama:

```mermaid
sequenceDiagram
    participant UI as "Procurize vartotojo sąsaja"
    participant WS as "Webhook"
    participant Svc as "Įvertinimo paslauga"
    UI->>WS: Klausimyno būsena = Paruošta
    WS->>Svc: POST /score-request {id}
    Svc->>Svc: Įkelti duomenis, vykdyti modelį
    Svc->>WS: POST /score-result {score, confidence}
    WS->>UI: Atnaujinti rizikos matuoklį
```

*Visi dalyvių pavadinimai pateikti dvigubomis kabutėmis.*

---

## Realūs privalumai

| Metrika | Prieš DI įvertinimą | Po DI įvertinimo |
|---------|----------------------|-------------------|
| Vidutinis klausimyno apdorojimo laikas | 7 dienos | 2 dienos |
| Rankinio peržiūros valandų skaičius per mėnesį | 120 h | 30 h |
| Klaidingų eskalacijų dažnis | 22 % | 8 % |
| Sandorio greitis (pardavimų ciklas) | 45 dienos | 31 diena |

Tyrimas paskelbtas tinklaraštyje (*Atvejo tyrimas: Klausimyno apdorojimo laiko sumažinimas 70 %*) rodo **70 %** darbo proceso sutrumpinimą po DI pagrįsto rizikos įvertinimo įdiegimo. Ši metodika gali būti pakartojama bet kurioje organizacijoje, naudojančioje Procurize.

---

## Valdymas, auditavimas ir atitiktis

1. **Paaiškinamumas** – Kiekvienam įvertinimui išsaugomos savybių svarbos diagramos, suteikiančios auditoriams aiškų pagrindimą, kodėl tiekėjas gavo tam tikrą reitingą.  
2. **Versijų kontrolė** – Kiekvienas atsakymas, įrodymo failas ir įvertinimo revizija fiksuojami Git‑stiliaus saugykloje, užtikrinant nepakeičiamą auditų kelią.  
3. **Reguliavimo atitikimas** – Kadangi kiekviena kontrolė susiejama su standartais (pvz., SOC 2 *CC6.1*, ISO 27001 *A.12.1*, GDPR straipsniai), įvertinimo variklis automatiškai generuoja atitikties matricas, kurias reikalauja reguliuotojai.  
4. **Duomenų privatumas** – Įvertinimo servisas veikia **FIPS‑140** validuotame aplinkoje, o visi duomenys poilsiui šifruojami **AES‑256** raktų, atitinkančių GDPR ir CCPA reikalavimus.

---

## Penkių žingsnių pradžios vadovas

1. **Audituokite esamus klausimynus** – Nustatykite trūkumus kontrolės susiejime ir įrodymų rinkime.  
2. **Įgalinkite Procurize webhook’us** – Konfigūruokite *Klausimynas paruoštas* webhooką Integracijos nustatymuose.  
3. **Paleiskite įvertinimo servisą** – Naudokitės atviro kodo įvertinimo SDK, kurią teikia Procurize (prieinama „GitHub“).  
4. **Apmokykite modelį** – Įkelkite bent 200 istorinių vertinimų, kad pasiektumėte patikimą prognozavimo tikslumą.  
5. **Paleiskite pilotą ir tobulinkite** – Pradėkite su ribotu tiekėjų grupe, stebėkite įvertinimo tikslumą ir kas mėnesį koreguokite svertų taisykles.

---

## Ateities perspektyvos

- **Dinaminis svertų reguliavimas** – Naudojant sustiprinimo mokymą, automatiškai didinti svertus tiems kontrolės elementams, kurie istorijoje sukelia auditų nesėkmes.  
- **Tarpųskaitmeninis lyginimas** – Kurti pramonės lygio įvertinimo pasiskirstymus, kad tiekėjai būtų lyginami su lygiaverčiais.  
- **Zero‑Touch pirkimas** – Kombinuoti pasitikėjimo įvertinimus su kontraktų generavimo API, kad automatiškai patvirtintume žemos rizikos tiekėjus, visai pašalinant žmogaus tarpininką.  

Kai DI modeliai taps dar išmanesni ir standartai tobulės, prognozinis pasitikėjimo įvertinimas pereis nuo **pageidaujamos galimybės** prie **pagrindinio rizikos valdymo proceso** kiekvienoje SaaS organizacijoje.

---

## Paskaitykite taip pat

- [NIST SP 800‑30 Rev. 1 – Vadovas atliekant rizikos vertinimus](https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final)