
# Nepromenjivi registar dokaza generiranog umjetnom inteligencijom za sigurne revizije upitnika

U eri brze digitalne transformacije, sigurnosni upitnici postali su usko grlo za SaaS dobavljače, financijske institucije i svaku organizaciju koja razmjenjuje dokaze usklađenosti s partnerima. Tradicionalni ručni tokovi rada podložni su greškama, spori su i često nedostaje im transparentnost koju traže revizori. AI platforma Procurize već automatizira generiranje odgovora i sastavljanje dokaza, ali bez pouzdane sloja porijekla, sadržaj proizveden AI‑om i dalje može izazvati sumnje.

Predstavljamo **Nepromjenjivi registar dokaza generiranog umjetnom inteligencijom (IAEEL)** – kriptografski zatvoren revizijski trag koji bilježi svaki AI‑generirani odgovor, izvorne dokumente, kontekst prompta i verziju modela koji je proizveo odgovor. Zaključavanjem ovih zapisa u strukturu samo za dopunjavanje, organizacije dobivaju:

* **Dokaz o nepromjenjivosti** – svaka naknadna izmjena odmah se otkriva.
* **Potpuna ponovljivost** – revizori mogu ponovno pokrenuti isti prompt nad točnom snimkom modela.
* **Regulatorna usklađenost** – zadovoljava rastuće zahtjeve za porijeklo dokaza u [GDPR‑u](https://gdpr.eu/), [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), [ISO 27001](https://www.iso.org/standard/27001) i drugim okvirima.
* **Odgovornost timova** – svaki unos potpisuje odgovorni korisnik ili servisni račun.

U nastavku prolazimo kroz konceptualne osnove, tehničku arhitekturu, praktični vodič za implementaciju i strateške prednosti uvođenja nepromjenjivog registra za automatizaciju upitnika potpomognutu AI‑jem.

---

## 1. Zašto je nepromjenjivost važna kod AI‑generiranih dokaza

| Izazov | Tradicionalni pristup | Rizik bez nepromjenjivosti |
|--------|----------------------|----------------------------|
| **Povratljivost** | Ručni dnevnici, tablice | Izgubljene poveznice između odgovora i izvora, teško dokazati autentičnost |
| **Odmak verzija** | Ad‑hoc ažuriranja dokumenata | Revizori ne mogu provjeriti koju je verzija korištena za određeni odgovor |
| **Regulatorni nadzor** | “Objašnjivost” na zahtjev | Kazne za neusklađenost ako se ne može demonstrirati porijeklo |
| **Interna upravljačka struktura** | Email lanac, neformalni bilješke | Nema jedinstvenog izvora istine, odgovornost je nejasna |

AI modeli su deterministički jedino kada su **prompt**, **snimka modela** i **ulazni podaci** fiksirani. Ako se bilo koja od tih komponenti promijeni, izlaz se može razlikovati, što narušava lanac povjerenja. Kriptografskim učvršćivanjem svake komponente, registar jamči da je odgovor koji ste danas predstavili isti odgovor koji revizor može provjeriti sutra, bez obzira na buduće promjene.

---

## 2. Osnovni blokovi registra

### 2.1 Merkle‑stablo zasnovano na logu koji se samo dopunjuje

Merkle‑stablo agregira popis zapisa u jedinstveni korijenski hash. Svaki novi unos dokaza postaje list‑čanik; stablo se ponovno izračunava, stvarajući novi korijenski hash koji se objavljuje u vanjskom nepromjenjivom spremištu (npr. javni blockchain ili permissioned distribuirani registar). Rezultirajuća struktura izgleda ovako:

```
leaf = hash(timestamp || userID || modelID || promptHash || evidenceHash)
```

Korijenski hash djeluje kao **obveza** prema cijeloj povijesti. Bilo koja izmjena lista mijenja korijen, čineći manipulaciju očiglednom.

### 2.2 Kriptografski potpisi

Svaki unos potpisuje se privatnim ključem izvornog servisnog računa (ili korisnika). Potpis štiti od lažiranih unosa i pruža neodbijanje.

### 2.3 Snapshot dohvaćanja pojačanog generiranjem (RAG)

AI‑generirani odgovori ovise o dohvaćenim dokumentima (politike, ugovori, prethodni revizijski izvještaji). RAG cjevovod bilježi:

* **ID‑ove dokumenata** (nepromjenjivi hash izvorne datoteke)
* **Upit za dohvat** (točan vektorski upit)
* **Vremensku oznaku verzije dokumenta**

Skladištenjem ovih identifikatora osiguravamo da, ako se temeljni dokument politike ažurira, registar i dalje pokazuje točnu verziju korištenu za odgovor.

### 2.4 Fiksiranje verzije modela

Modeli se verzioniraju semantičkim oznakama (npr. `v1.4.2‑2025‑09‑01`). Registar pohranjuje hash datoteke težina modela, jamčeći da se isti model može ponovo učitati za verifikaciju.

---

## 3. Pregled arhitekture sustava

```mermaid
graph LR
    A["Korisnik / Servis"] --> B["Procurize AI Engine"]
    B --> C["RAG Retrieval Layer"]
    B --> D["LLM Prompt Engine"]
    D --> E["Answer Generator"]
    E --> F["Evidence Packaging"]
    F --> G["Ledger Writer"]
    G --> H["Merkle Tree Service"]
    H --> I["Immutable Store (Blockchain / DLT)"]
    G --> J["Audit API"]
    J --> K["Auditor Front‑End"]
```

*Tok*: Zahtjev pokreće AI engine, koji dohvaća relevantne dokumente (C), sastavlja prompt (D), generira odgovor (E), pakira ga s metapodacima izvora (F) i zapisuje potpisani unos u registar (G). Merkleeova usluga (H) ažurira korijenski hash, koji se pohranjuje nepromjenjivo (I). Revizori kasnije upituju registar putem Audit API‑ja (J) i pregledavaju reproducibilni paket dokaza (K).

---

## 4. Implementacija registra – korak po korak

### 4.1 Definirajte shemu dokaza

```json
{
  "timestamp": "ISO8601",
  "user_id": "uuid",
  "model_id": "string",
  "model_hash": "sha256",
  "prompt_hash": "sha256",
  "evidence_hash": "sha256",
  "retrieved_docs": [
    {
      "doc_id": "sha256",
      "doc_version": "ISO8601",
      "retrieval_query": "string"
    }
  ],
  "answer_text": "string",
  "signature": "base64"
}
```

Sva polja su nepromjenjiva nakon zapisivanja.

### 4.2 Generirajte kriptografske materijale

```goat
import (
    "crypto/sha256"
    "crypto/ed25519"
    "encoding/base64"
)

func hash(data []byte) []byte {
    h := sha256.Sum256(data)
    return h[:]
}

// Primjer: izračun list‑hasha
leaf := hash([]byte(timestamp + userID + modelID + promptHash + evidenceHash))
```

*(Kodni blok koristi oznaku `goat` u skladu s predpisom; stvarna implementacija može biti u bilo kojem jeziku.)*

### 4.3 Zapišite u log koji se samo dopunjuje

1. Serializirajte zapis dokaza u JSON.
2. Izračunajte list‑hash.
3. Dodajte listu lokalnom Merkle‑stablu.
4. Rekalkulirajte korijenski hash.
5. Pošaljite korijenski hash u nepromjenjivo spremište putem transakcije.

### 4.4 Sidrite korijenski hash

Za javnu provjerljivost možete:

* Objaviti korijenski hash na javnom blockchainu (npr. podaci transakcije na Ethereum‑u).
* Koristiti permissioned DLT poput Hyperledger Fabric za internu usklađenost.
* Pohraniti hash u oblačni servis s nepromjenjivim pohranom (AWS S3 Object Lock, Azure Immutable Blob).

### 4.5 Verifikacijski tok za revizore

1. Revizor upiti **Audit API** uz ID upitnika.
2. API vraća povezani zapis registra i Merkle dokaz (lista susjednih hash‑ova).
3. Revizor ponovno izračuna list‑hash, prolazi Merkle put i uspoređuje rezultat s korijenskim hashom koji je sidren.
4. Ako dokaz valja, revizor može preuzeti točne izvorne dokumente (preko nepromjenjivih `doc_id` veza) i učitati fiksirani model kako bi reproducirao odgovor.

---

## 5. Primjeri iz stvarnog svijeta

| Scenarij | Korist registra |
|----------|-----------------|
| **Procjena rizika dobavljača** | Automatski dokaz da je svaki odgovor nastao iz točno one verzije politike koja je bila aktivna u trenutku zahtjeva. |
| **Regulatorna inspekcija (npr. [GDPR](https://gdpr.eu/) Art. 30)** | Demonstrira potpune zapise obrade podataka, uključujući AI‑generirane odluke, čime zadovoljava zahtjeve “vođenja evidencije”. |
| **Interni pregled incidenta** | Neomogućeni logovi omogućuju timovima za post‑mortem da prate podrijetlo potencijalno neispravnog odgovora bez brige o manipulaciji. |
| **Suradnja između tvrtki** | Federirani registri omogućuju više partnera da potvrde zajedničke dokaze bez izlaganja cijelih dokumenata. |

---

## 6. Strateške prednosti za poduzeća

### 6.1 Pojačano povjerenje

Dionici—klijenti, partneri, revizori—vide transparentan, nepromjenjiv lanac porijekla. To smanjuje potrebu za ručnim razmjenama dokumenata, ubrzavajući pregovore o ugovorima i do 40 % prema benchmark studijama.

### 6.2 Smanjenje troškova

Automatizacija zamjenjuje sate ručnog prikupljanja dokaza. Registar dodaje zanemariv trošak (hash‑iranje i potpisivanje su mikrosekundne operacije) ali eliminira skupe cikluse revizije.

### 6.3 Priprema za budućnost

Regulatorna tijela sve više zahtijevaju *“Proof‑of‑Compliance”* standarde koji traže kriptografske dokaze. Implementacijom nepromjenjivog registra danas, organizacija je ispred nadolazećih propisa.

### 6.4 Usklađenost s privatnošću podataka

Budući da registar pohranjuje samo hash‑ove i metapodatke, povjerljiv sadržaj nije izložen na nepromjenjivom mjestu. Osjetljivi dokumenti ostaju iza kontrola pristupa, dok porijeklo ostaje javno provjerljivo.

---

## 7. Uobičajene zamke i kako ih izbjeći

| Zamka | Kako je izbjegavati |
|--------|----------------------|
| **Pohranjivanje sirovih dokumenata u registar** | Pohranjujte samo hash‑ove dokumenata; stvarne datoteke držite u sigurnom, verzioniranom repozitoriju. |
| **Zanemarivanje verzioniranja modela** | Nametnite CI/CD cjevovod koji svaku verziju modela označava hash‑om i registrira u registar modela. |
| **Slabo upravljanje ključevima** | Koristite HSM‑ove ili cloud KMS za zaštitu privatnih ključeva. Redovito rotirajte ključeve i vodite popis opozvanih ključeva. |
| **Užesi u performansama kod Merkle ažuriranja** | Grupirajte više list‑unosaka u jednu rekonstrukciju stabla ili upotrijebite sharded Merkle forest za visoku propusnost. |

---

## 8. Pogled u budućnost: Integracija Zero‑Knowledge Proofs

Dok Merkle‑bazirana nepromjenjivost pruža snažnu integritetu, nadolazeći **Zero‑Knowledge Proofs (ZKP‑ovi)** mogu omogućiti revizorima da potvrde da odgovor zadovoljava pravila usklađenosti *bez* otkrivanja podataka. Mogući nastavak IAEEL‑a mogao bi:

1. Generirati zk‑SNARK koji dokazuje da odgovor ispunjava skup pravila usklađenosti.
2. Sidrati hash dokaza uz korijenski hash registra.
3. Dati revizorima mogućnost provjere usklađenosti bez pristupa vlasničkim tekstovima politika.

Ovaj pravac usklađen je s propisima o privatnosti i otvara nove poslovne modele za sigurno dijeljenje dokaza među konkurentima.

---

## 9. Zaključak

Nepromjenjivi registar dokaza generiranog umjetnom inteligencijom pretvara AI‑potpomognutu automatizaciju upitnika iz alata za ubrzanje u **motor povjerenja**. Bilježeći svaki prompt, model, dohvat i odgovor u kriptografski zatvorenom obliku, organizacije ostvaruju:

* Auditable, nepromjenjive tragove dokaza.
* Neometanu regulatornu usklađenost.
* Brže i pouzdanije procjene rizika dobavljača.

Uvođenje IAEEL‑a zahtijeva disciplinirano verzioniranje, solidnu kriptografiju i integraciju s nepromjenjivim spremištem, ali nagrada — smanjenje trenja pri reviziji, jače povjerenje dionika i priprema za buduće usklađenosti — čini ga strateškim imperativom za svakog modernog pružatelja SaaS‑usluga usmjerenog na sigurnost.

---

## <span class='highlight-content'>Pogledajte</span> također

- [NIST SP 800‑53 Revizija 5 – Kontrole sigurnosti i privatnosti za savezne informacijske sustave i organizacije](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
- [ISO/IEC 27001:2022 – Zahtjevi sustava upravljanja informacijskom sigurnošću](https://www.iso.org/standard/75652.html)
- [Microsoft Azure Confidential Ledger – U potpunosti upravljani nepromjenjivi registar usluge](https://learn.microsoft.com/azure/confidential-ledger/)