
# Dynamické obohacovanie znalostného grafu pre kontextualizáciu dotazníkov v reálnom čase

## Úvod

Bezpečnostné dotazníky a audity súladu sa stali úzkym hrdlom v každej rýchlo rastúcej SaaS organizácii. Tímy strávia nespočetné hodiny hľadaním správnej klauzuly politiky, získavaním dôkazov z úložísk dokumentov a prepisovaním tej istej odpovede pre každý nový požiadavok od dodávateľa. Zatiaľ čo veľké jazykové modely (LLM) môžu generovať návrhy odpovedí, často im chýba **regulačná nuansa**, ktorá sa mení deň za dňom – nové usmernenia Európskej rady pre ochranu údajov (EDPB), aktualizovaný [NIST CSF](https://www.nist.gov/cyberframework) (napr. NIST SP 800‑53) alebo čerstvo publikovaná [ISO 27001](https://www.iso.org/standard/27001) amendová.

**Procurize** rieši tento problém pomocou **Enginu dynamického obohacovania znalostného grafu (DKGEE)**. Engine neustále konzumuje regulačné kanály v reálnom čase, mapuje ich na jednotný znalostný graf a poskytuje kontextuálne dôkazy, ktoré sú okamžite dostupné v používateľskom rozhraní pre tvorbu dotazníkov. Výsledkom je *jediný zdroj pravdy*, ktorý sa automaticky vyvíja, skracuje čas odpovede z dní na minúty a zaručuje, že každá odpoveď odráža najnovší postoj k súladu.

V tomto článku sa budeme venovať:

1. Vysvetlíme, prečo je dynamický znalostný graf chýbajúcim článkom medzi AI‑generovanými návrhmi a audit‑pripravenými odpoveďami.  
2. Prejdeme architektúru, dátový tok a hlavné komponenty DKGEE.  
3. Ukážeme, ako integrovať engine s existujúcimi vrstvami správy úloh a komentárov v Procurize.  
4. Predstavíme prípadovú štúdiu z reálneho sveta s merateľnou návratnosťou investícií.  
5. Ponúkneme praktické odporúčania pre tímy, ktoré chcú engine adoptovať už dnes.

---

## 1. Prečo statická databáza zlyháva

| Problém | Statická databáza | Dynamický znalostný graf |
|---------|-------------------|--------------------------|
| **Regulačné aktualizácie** | Vyžaduje manuálny import; aktualizácie zaostávajú o týždeň. | Automatické prijímanie kanálov; aktualizácie v priebehu minút. |
| **Mapovanie naprieč rámcami** | Ručne vytvorené mapovacie tabuľky sa rýchlo nezhodujú. | Vzťahy založené na grafe zostávajú konzistentné, keď sa objavia nové uzly. |
| **Vyhľadávanie kontextuálnych dôkazov** | Vyhľadávanie podľa kľúčových slov prináša šumivé výsledky. | Sémantické prechádzanie grafom poskytuje presné dôkazy s vyznačením pôvodu. |
| **Auditovateľnosť** | Žiadny automatický záznam zmien. | Zabudované verzovanie a linie pre každý uzol. |

Statické úložisko môže uchovávať politiky, ale nedokáže *pochopiť*, ako nová regulácia – napríklad článok GDPR – mení interpretáciu existujúcej ISO klauzuly. DKGEE to rieši **modelovaním regulačného ekosystému ako grafu**, kde každý uzol predstavuje klauzulu, usmernenie alebo dôkazový artefakt a hrany kodifikujú vzťahy ako *„vyžaduje“*, *„prepíše“* alebo *„mapuje‑na“*. Keď pribudne nová regulácia, graf sa **inkrementálne obohacuje**, zachováva históriu a dopad na existujúce odpovede je okamžite viditeľný.

---

## 2. Prehľad architektúry

Nižšie je vysokúrovňový Mermaid diagram, ktorý vizualizuje potrubie DKGEE.

```mermaid
graph TD
    A["Regulatory Feed Collectors"] --> B["Ingestion Service"]
    B --> C["Normalization & Entity Extraction"]
    C --> D["Graph Updater"]
    D --> E["Dynamic Knowledge Graph"]
    E --> F["Contextual Retrieval Engine"]
    F --> G["Procurize UI (Questionnaire Builder)"]
    G --> H["LLM Draft Generator"]
    H --> I["Human‑in‑the‑Loop Review"]
    I --> J["Final Answer Storage"]
    J --> K["Audit Trail & Versioning"]
```

### 2.1 Hlavné komponenty

1. **Regulatory Feed Collectors** – Pripojenia k oficiálnym zdrojom (EU Official Journal, NIST RSS, ISO aktualizácie), komunitným kanálom (GitHub‑uvedené pravidlá súladu) a zmenám politík špecifických pre dodávateľov.  
2. **Ingestion Service** – Ľahká mikro‑služba napísaná v **Go**, ktorá overuje payloady, detekuje duplikáty a posiela surové dáta do Kafka témy.  
3. **Normalization & Entity Extraction** – Využíva **spaCy** a modely **Hugging Face** na rozpoznávanie pomenovaných entít špeciálne vyladených na právny text.  
4. **Graph Updater** – Vykonáva **Cypher** príkazy proti **Neo4j** inštancii, vytvára alebo aktualizuje uzly a hrany a zároveň zachováva verziovaciu históriu.  
5. **Dynamic Knowledge Graph** – Ukladá celý regulačný ekosystém. Každý uzol má vlastnosti: `id`, `source`, `text`, `effectiveDate`, `version`, `confidenceScore`.  
6. **Contextual Retrieval Engine** – Služba typu **RAG**, ktorá prijme dotaz z dotazníka, vykoná **sémantickú traversáciu grafu**, zoradí kandidátske dôkazy a vráti JSON payload.  
7. **Procurize UI Integration** – Front‑end spotrebuje payload a zobrazuje návrhy priamo pod každou otázkou, s inline komentármi a tlačidlami „Apply to Answer“.  
8. **LLM Draft Generator** – Model **GPT‑4‑Turbo**, ktorý používa získané dôkazy ako podklad pre tvorbu prvého návrhu odpovede.  
9. **Human‑in‑the‑Loop Review** – Recenzenti môžu návrh prijať, upraviť alebo odmietnuť; všetky akcie sa zaznamenávajú pre auditovateľnosť.  
10. **Final Answer Storage & Audit Trail** – Odpovede sa ukladajú do nemeniteľnej knihy (napr. **AWS QLDB**) s kryptografickým hashom, ktorý odkazuje na konkrétny snapshot grafu použitého pri generovaní.

---

## 3. Tok dát – od kanálu po odpoveď

1. **Príchod kanálu** – Publikovaná revízia NIST SP 800‑53. Feed Collector stiahne XML, prevedie ho na JSON a pošle do Kafka.  
2. **Extrakcia** – Entity Extraction označí každú kontrolu (`AC‑2`, `AU‑6`) a priradené usmernenia.  
3. **Mutácia grafu** – `MERGE` Cypher príkazy pridajú nové uzly alebo aktualizujú `effectiveDate` existujúcich. Hrana `OVERWRITES` spojuje novú kontrolu so staršou verziou.  
4. **Vytvorenie snapshotu** – Temporal plugin Neo4j zachytí snapshot ID (`graphVersion=2025.11.12.01`).  
5. **Prompt otázky** – Analytik otvorí dotazník a pýta sa „Ako riadite provisioning účtov?“  
6. **Contextual Retrieval** – Engine vyhľadá v grafe uzly spojené s `AC‑2` **a** filtrované podľa domény spoločnosti (`SaaS`, `IAM`). Vráti dva výňatky z politiky a jeden výňatok z nedávnej auditnej správy.  
7. **LLM Draft** – LLM dostane prompt + získané dôkazy a vygeneruje stručnú odpoveď s citáciou ID dôkazov.  
8. **Ľudská revízia** – Analytik overí citácie, pridá komentár o nedávnej interné zmeny procesu a schváli.  
9. **Audit log** – Systém zapíše ID snapshotu grafu, ID uzlov dôkazov, verziu LLM a ID používateľa recenzenta.  

Všetky kroky pre typickú položku dotazníka trvajú **pod 30 sekúnd**.

---

## 4. Sprievodca implementáciou

### 4.1 Predpoklady

| Položka | Odporúčaná verzia |
|---------|-------------------|
| Neo4j | 5.x (Enterprise) |
| Kafka | 3.3.x |
| Go | 1.22 |
| Python | 3.11 (pre spaCy & RAG) |
| LLM API | OpenAI GPT‑4‑Turbo (alebo Azure OpenAI) |
| Cloud | AWS (EKS pre služby, QLDB pre audit) |

### 4.2 Krok za krokom

1. **Nasadiť Neo4j klaster** – Povoliť pluginy **Temporal** a **APOC**. Vytvoriť databázu `regulatory`.  
2. **Vytvoriť Kafka témy** – `regulatory_raw`, `graph_updates`, `audit_events`.  
3. **Konfigurovať Feed Collectors** – Použiť oficiálny RSS EU Gazette, JSON feed NIST a GitHub webhook pre komunitne udržiavané SCC pravidlá. Uložiť poverenia v **AWS Secrets Manager**.  
4. **Spustiť Ingestion Service** – Dockerizovať Go službu, nastaviť env `KAFKA_BROKERS`. Monitorovať pomocou **Prometheus**.  
5. **Nasadiť Entity Extraction** – Vytvoriť Python Docker image s `spaCy>=3.7` a custom právny NER model. Odoberať `regulatory_raw` a publikovať normalizované entity do `graph_updates`.  
6. **Graph Updater** – Napísať stream‑processor (napr. **Kafka Streams** v Jave), ktorý konzumuje `graph_updates`, tvorí Cypher dotazy a vykonáva ich v Neo4j. Každú mutáciu označiť korelačným ID.  
7. **RAG Retrieval Service** – Exponovať FastAPI endpoint `/retrieve`. Implementovať sémantickú podobnosť pomocou **Sentence‑Transformers** (`all-MiniLM-L6-v2`). Služba vykoná dvojkrokové traversovanie: **Question → Relevant Control → Evidence**.  
8. **Integrácia s Procurize UI** – Pridať React komponent `EvidenceSuggestionPanel`, ktorý volá `/retrieve` pri zameraní poľa otázky. Zobraziť výsledky s checkboxmi „Insert“.  
9. **LLM Orchestration** – Použiť OpenAI **Chat Completion** endpoint, preniesť získané dôkazy ako systémové správy. Zachytiť `model` a `temperature` pre budúcu reprodukovateľnosť.  
10. **Audit Trail** – Napísať Lambda funkciu, ktorá zachytí každý `answer_submitted` event, zapíše záznam do QLDB s SHA‑256 hashom odpovede a odkazom na snapshot grafu (`graphVersion`).  

### 4.3 Najlepšie praktiky

- **Pevné verzovanie** – Vždy ukladať presnú verziu LLM a ID snapshotu grafu ku každej odpovedi.  
- **Uchovávanie dát** – Ukladať surové regulačné kanály minimálne **7 rokov** kvôli auditným požiadavkám.  
- **Bezpečnosť** – Šifrovať Kafka streamy pomocou TLS, povoliť rolové riadenie prístupu v Neo4j a obmedziť zápisy do QLDB len na audit Lambda.  
- **Monitorovanie výkonu** – Nastaviť alarmy na latenciu Retrieval Engine; cieľ < 200 ms na dotaz.  

---

## 5. Skutočný dopad: prípadová štúdia

**Spoločnosť:** SecureSoft, stredne veľký SaaS poskytovateľ pre zdravotnícke dáta.

| Metrika | Pred DKGEE | Po DKGEE (3‑mesačné obdobie) |
|---------|------------|------------------------------|
| Priemerný čas na odpoveď na položku dotazníka | 2,8 hodiny | 7 minút |
| Manuálna práca na hľadanie dôkazov (osobné hodiny) | 120 h/mesiac | 18 h/mesiac |
| Počet regulačných nezhôd objavených v auditoch | 5 ročne | 0 (žiadne nezhody) |
| Spokojnosť tímu súladu (NPS) | 28 | 72 |
| ROI (založené na úsporách práce) | — | ~ 210 tis. USD |

**Kľúčové faktory úspechu**

1. **Okamžitý regulačný kontext** – Keď NIST aktualizoval SC‑7, graf odoslal upozornenie priamo v UI a tím mohol okamžite revíziu súvisiacich odpovedí.  
2. **Pôvod dôkazov** – Každá odpoveď zobrazovala klikateľný odkaz na konkrétnu klauzulu a verziu, čím spĺňala požiadavky auditorov okamžite.  
3. **Redukcia duplicít** – Graf odstránil duplicitné úložiská dôkazov naprieč produktovými líniami, čím znížil náklady na úložisko o **30 %**.  

SecureSoft plánuje rozšíriť engine na **posúdenia vplyvu na ochranu osobných údajov (PIA)** a integrovať ho do svojho **CI/CD pipeline**, aby pri každom nasadení automaticky validoval politiku súladu.

---

## 6. Často kladené otázky

**Q1: Funguje engine aj s reguláciami v iných jazykoch?**  
Áno. Dátová pipeline obsahuje viacjazyčné modely; môžete pridať kolektory pre japonské APPI, brazílske LGPD a podobne, pričom graf si zachováva jazykové značky pre každý uzol.

**Q2: Ako riešime protichodné regulácie?**  
Automaticky sa vytvárajú hrany `CONFLICTS_WITH`, keď dva uzly majú prekrývajúci rozsah, ale odlišné požiadavky. Retrieval Engine radí dôkazy podľa `confidenceScore`, ktorý zohľadňuje hierarchiu regulácií (napr. GDPR > národný zákon).

**Q3: Je systém viazaný na jedného dodávateľa?**  
Všetky hlavné komponenty sú postavené na open‑source technológiách (Neo4j, Kafka, FastAPI). Iba LLM API je tretia strana, ale môžete ho nahradiť akýmkoľvek modelom, ktorý spĺňa špecifikáciu OpenAI‑compatible endpoint.

**Q4: Aká je politika uchovávania dát pre graf?**  
Odporúčame **time‑travel** prístup: uchovávajte každú verziu uzla neustále (ako immutable snapshots) a staršie snapshoty archivujte do studeného úložiska po 3 rokoch, pričom si zachováte najnovší aktívny pohľad pre denné dotazy.

---

## 7. Začnite ešte dnes

1. **Pilotujte Ingestion Layer** – Vyberte jeden regulačný zdroj (napr. [ISO 27001](https://www.iso.org/standard/27001)) a streamujte ho do testovacej Neo4j inštancie.  
2. **Spustite Sample Retrieval** – Použite priložený Python skript `sample_retrieve.py` na dotaz „Politika uchovávania dát pre zákazníkov EU“. Skontrolujte vrátené dôkazové uzly.  
3. **Integrujte do sandboxového dotazníka** – Nasadiť UI komponent v staging prostredí Procurize. Nech pár analytikov vyskúša workflow „Apply evidence“.  
4. **Meranie** – Zaznamenajte základné metriky (čas na odpoveď, počet manuálnych vyhľadávaní) a porovnajte po dvoch týždňoch používania.  

Ak potrebujete hands‑on workshop, kontaktujte tím **Procurize Professional Services** pre **30‑dňový akceleračný balík**.

---

## 8. Budúce smerovanie

- **Federované znalostné grafy** – Umožniť viacerým organizáciám zdieľať anonymizované mapovania regulácií, pričom sa zachová suverenita dát.  
- **Zero‑Knowledge Proof audity** – Audítori budú môcť overiť, že odpoveď spĺňa reguláciu, bez odhalenia samotných dôkazov.  
- **Predikcia regulačných zmien** – Kombinovať graf s časovými modelmi na odhad budúcich regulácií a proaktívne navrhovať úpravy politík.  

Dynamický znalostný graf nie je statické úložisko; je to **živý engine súladu**, ktorý rastie spolu s regulačným prostredím a poháňa AI‑driven automatizáciu vo veľkom meradle.

---

## <span class='highlight-content'>Pozri</span> tiež

- [Dynamické obohacovanie znalostného grafu pre kontextualizáciu dotazníkov v reálnom čase (Video prehľad)](https://www.youtube.com/watch?v=example)