# Generatyvinio DI valdoma realaus laiko atitikties žinių grafas su automatinio gijimo varikliu

SaaS įmonių atitikties specialistai turi susidoroti su nuolat besikeičiančiais reglamentais, vidiniais politikos atnaujinimais ir nuolatiniu spaudimu greitai atsakyti į saugumo klausimynus. Tradicinės žinių bazės pasensta jau tada, kai paskelbiamas naujas reglamentas arba pertvarkomas sutarties punktas. Tai lemia rankinį, klaidų linkusį duomenų paieškos, versijų neatitikimų ir vėluojančių atsakymų ciklą.

**Realiojo laiko automatinio gijimo atitikties žinių grafas**, kurį maitina generatyvus DI, paverčia šį reaktyvų procesą į proaktyvią, savęs taisančią sistemą. Variklis nuolat įrašo reguliavimo srautus, vidinius politikos saugyklas ir išorinius rizikos šaltinius; aptinka nuokrypius; generuoja remiančius veiksmus ir atnaujina grafiką be žmogaus įsikišimo, išlaikydamas skaidrų audito taką.

Žemiau apžvelgiame problemos sritį, pagrindinę architektūrą, įgyvendinimo žingsnius ir kiekybinę naudą, kurią suteikia ši technologija.

## 1. Kodėl esamos priemonės nepatenkina poreikių

| Iššūkis | Įprastas požiūris | Paslėpta kaina |
|-----------|------------------|--------------|
| Reguliavimo kaita | Rankinis politikos peržiūrėjimas kas ketvirtį | Valstybininkų valandų laikas, praleistos terminai |
| Daugelio standartų suderinimas ([ISO 27001](https://www.iso.org/standard/27001), [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), [GDPR](https://gdpr.eu/), [CCPA](https://oag.ca.gov/privacy/ccpa)) | Atskirų skaičiuoklių naudojimas kiekvienam standartui | Dviguba pastanga, nesuderinamumas |
| Įrodymų šviežumas | Rankiniai žymėjimai „paskutinį kartą patikrinta“ | Pasenę įrodymai sukelia audito išvadas |
| Klausimyno atsako greitis | Kopijavimas iš politikos dokumento | Žmogaus klaidos, trūksta atsekamumo |

Net ir sudėtingi RAG (retrieval‑augmented generation) kanalai teisingai atsako į klausimus tik tuomet, kai pagrindinis žinių grafas yra **šviežias**. Kai šaltinių duomenys pasikeičia, grafas tampa našta, o ne turtu.

## 2. Pagrindinė koncepcija: automatinio gijimo žinių grafas

Automatinio gijimo žinių grafas – tai dinaminis atitikties objektų (reglamentai, kontrolės priemonės, politikos, įrodymų artefaktai) grafas, kuris **savęs koreguoja**, kai pasikeičia bet kuri viršutinė duomenų sritis. Variklis atlieka tris nuolatines ciklines operacijas:

1. **Aptikti** – stebėti šaltinių saugyklas ir reguliavimo srautus dėl naujų, ištrintų arba modifikuotų elementų.  
2. **Diagnozuoti** – naudoti generatyvų LLM, kad įvertintų poveikį žemiau esančioms mazgoms (pvz., naujas GDPR straipsnis veikia duomenų išsaugojimo politiką).  
3. **Remontuoti** – automatiškai generuoti atnaujintus politikos fragmentus, įrodymų nuorodas ir versijuotus grafiko pakeitimus.

Visi veiksmai įrašomi į nekintamą ledgerį, suteikdami visišką paaiškinamumą auditoriams.

## 3. Architektūros apžvalga

```mermaid
graph LR
    subgraph Išoriniai šaltiniai
        R[Reguliavimo srauto API] -->|JSON| D[Keitimų detektorius]
        P[Vidinio politikos saugykla] -->|Git| D
        V[Tiekėjų rizikos srautas] -->|CSV| D
    end
    D -->|įvykiai| I[Įtakos analizatorius]
    I -->|LLM užklausų| L[Generatyvinis LLM]
    L -->|siūlomi atnaujinimai| M[Mutacijų variklis]
    M -->|grafiko operacijos| G[Atitikties žinių grafas]
    G -->|užklausos| Q[Real‑time klausimyno paslauga]
    G -->|audito įvykiai| A[Nekeičiamas užrašų sąrašas]
    style D fill:#f9f,stroke:#333,stroke-width:2px
    style L fill:#bbf,stroke:#333,stroke-width:2px
    style G fill:#bfb,stroke:#333,stroke-width:2px
```

### Pagrindiniai komponentai

| Komponentas | Atsakomybė |
|-----------|----------------|
| **Keitimų detektorius** | Stebi webhooks arba periodiškai tikrina duomenų šaltinius; normalizuoja keitimo įvykius į vieningą schemą. |
| **Įtakos analizatorius** | Peržvelgia grafiką, kad rastų paveiktus mazgus; sukuria priklausomybės žemėlapį kiekvienam pasikeitimui. |
| **Generatyvinis LLM** | Gautą struktūruotą užklausą apie nuokrypį paverčia projektais politikos nuostatomis, įrodymų fragmentais arba remiantiniais veiksmais. |
| **Mutacijų variklis** | Patikrina LLM išvestį pagal politikos‑kaip‑kodas taisykles, taiko versijuotus atnaujinimus ir įrašo į grafą. |
| **Nekeičiamas užrašų sąrašas** | Saugo kiekvieną mutaciją su laiko žyme, kilmės šaltiniu ir LLM pasitikėjimo rodikliais auditoriui. |
| **Real‑time klausimyno paslauga** | Teikia atnaujintus atsakymus per API arba UI, garantuodama, kad kiekvienas atsakymas atspindi naujausią grafiko būseną. |

## 4. Žingsnis po žingsnio įgyvendinimo vadovas

### 4.1. Sukurti pradinį žinių grafiką

1. **Schemos projektavimas** – Apibrėžkite mazgų tipus: `Regulation`, `Control`, `Policy`, `Evidence`, `Question`, `Vendor`. Nustatykite santykius, pvz., `enforces`, `references`, `covers`, `produces`.  
2. **Duomenų įkėlimas** – Naudokite ETL kanalus (Apache NiFi, Airbyte) įkelti esamus politikos dokumentus, reguliavimo katalogus (pvz., [NIST CSF](https://www.nist.gov/cyberframework), [ISO/IEC 27001 Information Security Management](https://www.iso.org/isoiec-27001-information-security.html)) ir įrodymų saugyklas į grafiką.  
3. **Versijavimas** – Saugojame kiekvieną mazgo versiją kaip atskirą mazgą su `validFrom` ir `validTo` laiko žymomis.

### 4.2. Nustatyti realaus laiko keitimų aptikimą

- **Reguliavimo API** – Prenumeruokite RSS/JSON srautus iš ES Komisijos, NIST ir Cloud Security Alliance (STAR).  
- **Vidiniai Git hooks** – Sugeneruokite webhook'ą, kai įvyksta įsipareigojimų saugyklos komitai.  
- **Rizikos srautų jungikliai** – Nuolat gaukite tiekėjų rizikos balus iš SaaS saugumo platformų.

Visi įvykiai normalizuojami į `ChangeEvent` struktūrą, kurią sudaro `entityId`, `changeType`, `newValue` ir `source`.

### 4.3. Įtakos analizės logika

```python
def impacted_nodes(event):
    # Retrieve the node that changed
    changed = graph.get_node(event.entityId)
    # Compute transitive closure of dependent nodes
    return graph.traverse(changed, edge_type="covers")
```

Ši funkcija grąžina politikos arba įrodymų mazgus, kuriems gali tekti atlikti pataisymus.

### 4.4. LLM užklausų (prompt) kūrimas

Sudarykite deterministinį šabloną:

```
You are an expert compliance analyst. A change has been detected:
Entity: {entity_type} "{entity_name}"
Change: {change_description}
Affected policies: {list_of_policies}
Provide:
1. Revised policy clause (max 3 sentences)
2. Updated evidence suggestion
3. Confidence score (0‑100)
```

Užpildytą šabloną perdavėkite fine‑tuned LLM (pvz., Claude‑3.5 arba GPT‑4o) per API kvietimą.

### 4.5. Patikrinimas ir mutacija

1. **Taisyklių variklis** – Įsitikinkite, kad LLM projekto tekstas nesukelia konfliktų su nekintamomis kontrolėmis (pvz., „šifravimas ramybės būsenoje turi būti ≥ 256 bitų“).  
2. **Žmogaus peržiūra (nebūtina)** – Projekto juodraštis pateikiamas peržiūros sąsajoje; atitikties pareigūnas gali patvirtinti, redaguoti arba atmesti.  
3. **Pridėti mutaciją** – Variklis sukuria naują versijos mazgą, atnaujina kraštus ir įrašo audito įrašą:

```json
{
  "mutationId": "m-2026-06-15-001",
  "timestamp": "2026-06-15T08:12:34Z",
  "source": "Regulatory Feed API",
  "llmModel": "Claude‑3.5",
  "confidence": 92,
  "previousNodeId": "policy-123",
  "newNodeId": "policy-124"
}
```

### 4.6. Pateikti realaus laiko atsakymus

Klausimyno mikroservisas užklausia grafiką dėl naujausių `Policy` mazgų, susijusių su `Question`. Kadangi mutacijos yra momentinės, atsakymas visuomet yra aktualus.

```graphql
query GetAnswer($questionId: ID!) {
  question(id: $questionId) {
    text
    answers {
      policy {
        content
        version
        effectiveDate
      }
      evidence {
        url
        verificationStatus
      }
    }
  }
}
```

## 5. Kiekybinės naudos matavimas

| Rodiklis | Prieš automatinį gijimą | Po įgyvendinimo |
|----------|------------------------|-----------------|
| Vidutinis politikos atnaujinimo laikas | 4 savaitės | < 2 valandos |
| Klausimyno atsako laikas | 5 dienos per užklausą | < 30 minučių |
| Rankinis audito darbo krūvis | 40 valandų per ketvirtį | 8 valandos per ketvirtį |
| Politikos nuokrypių aptikimo tikslumas | 70 % (rankinis) | 96 % (automatizuotas) |
| Auditoriaus pasitikėjimo indeksas | 78 % | 94 % |

Variklis ne tik sumažina veiklos išlaidas, bet ir padidina pasitikėjimo lygį, kurį potencialūs klientai mato SaaS patikimumo puslapyje – tiesiogiai veikiant konversijų rodiklius.

## 6. Realūs naudojimo atvejai

1. **[GDPR](https://gdpr.eu/) 30 straipsnio atnaujinimas** – Kai ES pridėjo naują įrašų saugojimo reikalavimą, keitimų detektorius pažymi susijusį `Regulation` mazgą. Įtakos analizatorius suranda `DataRetentionPolicy` mazgą, LLM sukuria naują nuostatomą, o mutacijų variklis įrašo atnaujinimą. Kitas klausimyno atsakas automatiškai rodo atnaujintą saugojimo grafiką.

2. **[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2) kontrolės peržiūra** – Debesų tiekėjas pakeičia šifravimo standartą. Automatinio gijimo variklis atnaujina `EncryptionPolicy` mazgą ir prideda naujas įrodymų nuorodas į atnaujintus sertifikatus, panaikinant rankinį politikos perrašymą.

3. **Tiekėjo rizikos įvertinimo šuolis** – Kritinis tiekėjas patiria saugumo įvykį, todėl jo rizikos balas staiga sumažėja. Grafas atnaujina `Vendor` mazgą, perduoda riziką susijusioms `Control` mazgoms ir išsiunčia realaus laiko įspėjimą pardavimų komandai, kad būtų pareikštas naujas saugumo klausimynas.

## 7. Valdymas ir paaiškinamumas

Kiekviena automatinio gijimo mutacija saugoma nekintamame ledger’yje (pvz., Hyperledger Fabric). Auditoriai gali patikrinti:

```mermaid
graph TD
    L[Ledger] -->|turi| M[Mutacijų įrašai]
    M -->|susieja| P[Politikos versijos]
    M -->|susieja| E[Įrodymų artefaktai]
```

Ledgeris fiksuoja:

- **Keitimo šaltinį** (reglamentų srautas, vidinis komitas).  
- **LLM užklausą** ir **modelio versiją**.  
- **Pasitikėjimo rodiklį** ir **žmogaus peržiūros būseną**.  

Šie duomenys patenkina įrodymų reikalavimus **SOC 2**, **ISO 27001** ir vidiniams atitikties standartams.

## 8. Geriausios praktikos sėkmingam paleidimui

1. **Pradėti nuo mažumo** – Pilotinis projektas su vienu reglamentu (pvz., GDPR) prieš plečiant mastą.  
2. **Fine‑tuning** – Naudokite savo politikos rinkinius, kad pagerintumėte domeno tikslumą.  
3. **Politikos‑kaip‑kodas** – Įgyvendinkite taisykles, kurios neleidžia LLM generuoti prieštaringų nuostatų.  
4. **Vartotojų vaidmenų peržiūra** – Leiskite vyresniems atitikties pareigūnams patvirtinti didelės įtakos pakeitimus.  
5. **Stebėti pasitikėjimo rodiklius** – Automatiškai atmesti juodraščius, kurių pasitikėjimo indeksas žemiau konfigūruoto slenksčio (pvz., 80 %).  
6. **Nuolatinis mokymas** – Periodiškai mokyti LLM su patvirtintomis mutacijomis, kad sumažėtų „halucinacijų“ skaičius.

## 9. Ateities perspektyvos

Automatinio gijimo žinių grafas yra esminis sluoksnis kelioms kitoms inovatyvioms galimybėms:

- **Prognozuojama spragų analizė** – Derinant grafiką su laiko eilučių modeliu, galima prognozuoti reguliavimo spragas dar prieš jas patiriant.  
- **Interaktyvios „Mermaid“ informacinės lentelės** – Realiojo laiko vizualizacijos apie nuokrypių poveikį vadovų prezentacijoms.  
- **Zero‑knowledge patvirtinimas** – Įrodyti, kad politika atitinka reglamentą be pačios politikos atskleidimo, ypač svarbu konfidencialiems tiekėjų klausimynams.  
- **Federuotas mokymasis tarp įmonių** – Dalintis nuokrypių aptikimo modeliais neskelbiant nuosavų politikų, spartinant visos pramonės atitikties higieną.

Kadangi reglamentai tampa vis smulkesni, o poreikis skubiai atsakyti į klausimynus auga, automatinio gijimo variklis pereis iš optimizavimo priemonės į būtinybę.