# Privatumo išsaugojimo sintezinių duomenų turgus su decentralizuota tapatybe

Sintezinių duomenų generavimo spartus augimas atvėrė naujas galimybes AI modelių mokymui, testavimui ir validavimui. Vis dėlto sintezinių duomenų pažadas dažnai šešėliuoja **privatumo, kilmės ir licencijavimo atitikties** klausimai. Tradiciniai turgūs remiasi centralizuotais tapatybės saugyklomis ir statiniais kontraktais, kurie gali tapti vieninteliais gedimo taškais ir trukdyti tarporganizaciniam bendradarbiavimui.

Šiame straipsnyje pristatome **kitos kartos sintezinių duomenų turgų**, sukurtą ant trijų stulpų:

1. **Decentralizuota tapatybė (DID) ir patikrinami įgaliojimai (VC)** – suteikia duomenų tiekėjams ir vartotojams suverenią kontrolę savo skaitmeninėmis tapatybėmis.  
2. **Zero‑Trust įgyvendinimas** – naudojant Formize politikų variklį, kiekvienas užklausimas vertinamas realiu laiku, nepriklausomai nuo tinklo vietos.  
3. **Dinaminis licencijavimas ir auditas** – naudojant išmaniąsias sutartis ir nekintamus audito takelius, užtikrinama, kad duomenų naudojimas atitiktų besikeičiančius reglamentus.

Pasibaigus šiam vadovui, suprasite visą procesą nuo pradžios iki pabaigos, pamatysite konkretų Mermaid diagramą, vaizduojančią architektūrą, ir sužinosite praktinius žingsnius, kaip įgyvendinti sprendimą ant Formize platformos.

---

## 1. Kodėl svarbus decentralizuotas požiūris

### 1.1 Centralizuotos tapatybės apribojimai

| Problema | Tradicinis modelis | Decentralizuotas modelis |
|----------|-------------------|--------------------------|
| **Vienas gedimo taškas** | Centralus autentifikacijos serveris gali būti pažeistas. | Tapatybė gyvena paskirstytoje knygoje; nėra vienintelės taikinio vietos. |
| **Duomenų silo** | Kiekviena organizacija prižiūri savo naudotojų katalogą. | DID yra globaliai išsprendžiami, leidžiantys sklandžią federaciją. |
| **Reguliavimo trintis** | Užklausos, susijusios su [GDPR](https://gdpr.eu/), reikalauja rankinio koordinavimo tarp sistemų. | Patikrinami įgaliojimai gali būti atšaukti akimirksniu, tenkinant „teisę būti pamirštam“. |

### 1.2 Pagrindinės DID koncepcijos

- **DID (Decentralizuotas identifikatorius)** – globaliai unikalus, URL‑panašus eilutė (`did:example:123456789abcdefghi`), kuri išsprendžiama į DID dokumentą, turintį viešuosius raktus ir paslaugų galinius taškus.  
- **Patikrinamas įgaliojimas (Verifiable Credential)** – kriptografiškai pasirašyti teiginiai (pvz., „Duomenų tiekėjas – sertifikuotas sintezinių duomenų generatorius“), kuriuos galima pateikti ir patikrinti neatskleidžiant asmeninių duomenų.  
- **Selektiškas atskleidimas** – nulinio žinojimo įrodymai leidžia turėtojui įrodyti atributus (pvz., „[ISO 27001](https://www.iso.org/standard/27001) sertifikuotas“), neatskleidžiant viso įgaliojimo.

Šie primityvai suteikia kiekvienam turgaus dalyviui **savarankišką tapatybę (SSI)** – būtinybę privatumo išsaugojimo duomenų mainams.

---

## 2. Zero‑Trust įgyvendinimas su Formize

Formize darbo srauto variklis traktuoja **kiekvieną sąveiką kaip nepatikimą**, kol neįrodyta priešinga. Platforma vertina politiką, išreikštą aukšto lygio DSL, kuri gali kreiptis į DID atributus, įgaliojimo įrodymus ir realaus laiko rizikos balus.

### 2.1 Politikos pavyzdys

```yaml
policy:
  name: "SyntheticDataAccessPolicy"
  description: "Leisti prieigą tik tada, kai vartotojas turi galiojantį DataConsumer įgaliojimą ir užklausa ateina iš zero‑trust krašto mazgo."
  conditions:
    - did:consumer.hasCredential("DataConsumer")
    - edgeNode.trustScore > 0.85
    - request.purpose in ["modelTraining", "testing"]
  actions:
    - grantAccess
    - logEvent
```

Kai gaunama užklausa, Formize:

1. **Išsprendžia** vartotojo DID ir atsiunčia naujausią VC rinkinį.  
2. **Patikrina** kriptografines parašas ir bet kokius nulinio žinojimo įrodymus.  
3. **Įvertina** politiką pagal dinaminį kontekstą (krašto mazgo patikimumo balas, užklausos tikslas ir t.t.).  
4. **Vykdo** apibrėžtas veiksmus (prieigos suteikimas, audito įrašas, pasirinktinis vandens ženklas).

Kadangi politikos yra **deklaratyvios ir versijuojamos**, reguliavimo atnaujinimai gali būti iškart paskleisti visame turguje.

---

## 3. Visas procesas nuo pradžios iki pabaigos

Žemiau pateikta aukšto lygio Mermaid diagrama, kuri iliustruoja sąveiką tarp duomenų tiekėjų, vartotojų, DID ekosistemos ir Formize zero‑trust variklio.

```mermaid
graph LR
    subgraph "Identity Layer"
        DIDProvider["\"DID Registry\""]
        VCIssuer["\"Verifiable Credential Issuer\""]
    end

    subgraph "Marketplace Core"
        FormizeEngine["\"Formize Zero‑Trust Engine\""]
        SmartContract["\"Licensing Smart Contract\""]
        DataLake["\"Synthetic Data Lake\""]
    end

    subgraph "Participants"
        Provider["\"Data Provider\""]
        Consumer["\"Data Consumer\""]
        EdgeNode["\"Zero‑Trust Edge Node\""]
    end

    Provider -->|register DID| DIDProvider
    Provider -->|obtain VC| VCIssuer
    Consumer -->|register DID| DIDProvider
    Consumer -->|obtain VC| VCIssuer

    Provider -->|publish metadata| SmartContract
    Provider -->|store data| DataLake

    Consumer -->|request access| EdgeNode
    EdgeNode -->|forward request| FormizeEngine
    FormizeEngine -->|resolve DID & VCs| DIDProvider
    FormizeEngine -->|evaluate policy| SmartContract
    FormizeEngine -->|grant/deny| EdgeNode
    EdgeNode -->|deliver data| Consumer
```

**Svarbiausi išskyrimai iš diagramos**

- **Visi dalyviai turi DID**, saugomą decentralizuotoje registre.  
- **Patikrinami įgaliojimai** išduoda patikimos institucijos (pvz., ISO auditoriai, reguliavimo institucijos) ir priskiriami DID.  
- **Formize** veikia kaip politikų sprendimų taškas, realiu laiku gaunant tapatybės duomenis.  
- **Išmaniosios sutartys** įgyvendina licencijavimo sąlygas (pvz., naudojimo limitus, atšaukimo nuostatas) ir yra nekintamos grandinėje.

---

## 4. Turgaus įgyvendinimas ant Formize

### 4.1 Reikalingi komponentai

| Komponentas | Rekomenduojama priemonė |
|-------------|------------------------|
| DID registras | **Ceramic**, **ION** arba **Hyperledger Indy** |
| VC išdavėjas | **Trinsic**, **Veramo** arba savarankiškas PKI |
| Formize instancija | Debesų pagrindu veikianti Formize SaaS arba savarankiškai valdomas Docker konteineris |
| Išmaniosios sutarties platforma | **Ethereum**, **Polygon** arba **Hyperledger Fabric** |
| Saugojimas | Šifruota objektų saugykla (pvz., AWS S3 su SSE‑KMS) |

### 4.2 Žingsnis po žingsnio vadovas

1. **Sukurkite DID visoms šalimoms**  
   ```bash
   curl -X POST https://did-registry.example.com/dids \
        -d '{"method":"ion","keyType":"Ed25519"}'
   ```
   Gautą DID URI saugokite kiekvieno dalyvio piniginėje.

2. **Išduokite patikrinamus įgaliojimus**  
   ```json
   {
     "type": ["VerifiableCredential", "DataProviderCredential"],
     "issuer": "did:example:issuer123",
     "credentialSubject": {
       "id": "did:example:provider456",
       "role": "SyntheticDataProvider",
       "certifications": ["ISO27001", "GDPRCompliant"]
     },
     "proof": { /* cryptographic proof */ }
   }
   ```

3. **Publikuokite duomenų metaduomenis į išmaniąją sutartį**  
   ```solidity
   struct DataAsset {
       string did;          // Provider DID
       string cid;          // Content identifier (IPFS hash)
       uint256 price;       // Token price
       uint256 expiry;      // Unix timestamp
       bytes32 licenseHash; // SHA‑256 of license terms
   }
   ```

4. **Apibrėžkite Formize politiką** (kaip parodyta 2.1 skyriuje) ir įkelkite ją per Formize UI arba API.

5. **Vartotojo užklausos srautas**  
   - Vartotojas pasirašo užklausą savo privačiu raktu.  
   - Krašto mazgas persiunčia užklausą Formize.  
   - Formize išsprendžia vartotojo DID, patikrina VCs, tikrina politiką ir grąžina **prieigos tokeną**, pasirašytą Formize.  
   - Krašto mazgas naudoja tokeną, kad gautų šifruotus sintezinius duomenis iš Data Lake, juos iššifruoja lokaliai ir įrašo transakciją į blokų grandinę.

6. **Atšaukimas ir auditas**  
   - Jei įgaliojimas atšaukiamas (pvz., tiekėjas praranda sertifikatą), išdavėjas atnaujina DID dokumentą. Formize kitą kartą įvertinant politiką automatiškai atmes prieigą.  
   - Visi sprendimai įrašomi nekintamame audito takelyje, kurį galima peržiūrėti per Formize integruotą analitikos skydelį.

### 4.3 Pavyzdinis Formize API kvietimas

```http
POST /api/v1/policy/evaluate HTTP/1.1
Host: api.formize.io
Authorization: Bearer <service‑token>
Content-Type: application/json

{
  "requestId": "req-2026-09-19-001",
  "consumerDid": "did:example:consumer789",
  "resourceCid": "bafybeigdyrzt5...",
  "purpose": "modelTraining",
  "edgeNodeId": "edge-01",
  "proof": { "type": "JwtProof", "jwt": "eyJhbGci..." }
}
```

Atsakymas (leidimas):

```json
{
  "decision": "grant",
  "accessToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "auditId": "audit-2026-09-19-001"
}
```

---

## 5. Atitikties privalumai

| Reguliavimas | Kaip turgus padeda |
|--------------|--------------------|
| **[GDPR](https://gdpr.eu/)** | SSI leidžia duomenų subjektams akimirksniu atšaukti sutikimą; atšaukiami VCs tenkina „teisę būti pamirštam“. |
| **[CCPA](https://oag.ca.gov/privacy/ccpa)** | Skaidri audito žurnalo sistema suteikia „atskleidimo įrašą“. |
| **[HIPAA](https://www.hhs.gov/hipaa/index.html)** | End‑to‑end šifravimas ir zero‑trust krašto mazgai izoliuoja PHI susijusius sintezinius duomenis. |
| **[ES AI Aktas](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)** | Dinaminis licencijavimas užtikrina, kad aukštos rizikos AI modeliai naudotų tik sertifikuotus sintezinius duomenis. |

Kadangi politikos yra **kodo pavidalo** ir versijuojamos, atitikties komandos gali susieti kiekvieną reglamentą su konkrečiu politikos reguliavimu, supaprastindamos auditus ir sumažindamos teisinę riziką.

---

## 6. Ateities patobulinimai

1. **AI pagrįstas rizikos įvertinimas** – integruoti LLM‑pagrindžius rizikos modelius, kurie dinamiškai koreguoja krašto mazgo patikimumo balus pagal realaus laiko grėsmių informaciją.  
2. **Tarpų grandinės interoperabilumas** – leisti licencijavimo sutartims veikti keliuose blokų grandinėse (pvz., Polkadot parachain) siekiant pasaulinio pasiekiamumo.  
3. **Turgaus reputacijos sistema** – naudoti patikrinamus įgaliojimus reputacijos ženkliukų išdavimui, kurie nusidėvi laikui bėgant, jei nėra atnaujinami.  
4. **Zero‑knowledge duomenų kilmės įrodymas** – naudoti zk‑SNARK, kad įrodytumėte, jog sintezinis duomenų rinkinys kilęs iš konkretaus šaltinio, neatskleidžiant paties šaltinio.

---

## 7. Išvada

Sujungdami **decentralizuotą tapatybę**, **zero‑trust įgyvendinimą** ir **Formize lankstų politikų variklį**, organizacijos gali sukurti **privatumo išsaugojimo sintezinių duomenų turgų**, kuris plečiasi per sienas, atitinka reguliavimą ir saugo duomenų subjektus. Architektūra pašalina centralizuotus butelius, automatizuoja licencijavimą ir suteikia nekintamą audito takelį – pagrindinius elementus patikimiems AI duomenų mainams atsakingo duomenų dalijimosi eroje.

---

## Žiūrėti taip pat

- [Decentralizuoti identifikatoriai (DIDs) – W3C rekomendacija](https://www.w3.org/TR/did-core/)  
- Formize Zero‑Trust darbo srauto variklio dokumentacija  
- [Patikrinamų įgaliojimų duomenų modelis 2.0 – W3C](https://www.w3.org/TR/vc-data-model/)  
- Sintezinių duomenų valdymas – NIST AI rizikos valdymo struktūra