# שוק נתונים סינתטיים שמגן על פרטיות עם זהות מבוזרת

הצמיחה המהירה של יצירת נתונים סינתטיים פתחה אפשרויות חדשות לאימון, בדיקה ואימות מודלים של AI. עם זאת, ההבטחה של נתונים סינתטיים מלווה לעיתים קרובות בדאגות סביב **פרטיות, מקוריות וציות לרישוי**. שווקים מסורתיים מסתמכים על מאגרי זהות מרכזיים וחוזים סטטיים, שעלולים להפוך לנקודות כשל יחידות ולפגוע בשיתוף פעולה בין‑ארגוני.

במאמר זה אנו מציגים **שוק נתונים סינתטיים דור הבא** המבוסס על שלושה עמודי תווך:

1. **זהות מבוזרת (DID) ואישורים ניתנים לאימות (VC)** – מעניקה לספקי הנתונים ולצרכנים שליטה ריבונית על זהותם הדיגיטלית.  
2. **אכיפת אפס‑אמון** – מנצלת את מנוע המדיניות של Formize כדי להעריך כל בקשה בזמן אמת, ללא תלות במיקום הרשת.  
3. **רישוי דינמי וביקורת** – משתמשת בחוזים חכמים ובמסילות ביקורת בלתי ניתנות לשינוי כדי להבטיח שהשימוש בנתונים תואם לתקנות המתפתחות.

בסיום המדריך תבינו את זרימת הקצה‑לקצה, תראו דיאגרמת Mermaid קונקרטית של הארכיטקטורה, ותלמדו צעדים מעשיים ליישום הפתרון על גבי Formize.

---

## 1. למה גישה מבוזרת חשובה

### 1.1 מגבלות של זהות מרוכזת

| בעיה | מודל מסורתי | מודל מבוזר |
|------|--------------|------------|
| **נקודת כשל יחידה** | שרת אימות מרכזי עלול להיפרץ. | הזהות מתארחת ברשומה מבוזרת; אין יעד יחיד. |
| **סילואים של נתונים** | כל ארגון מתחזק ספריית משתמשים משלו. | DIDs ניתנים לפתרון גלובלי, מאפשרים פדרציה חלקה. |
| **חיכוך רגולטורי** | בקשות נושא נתונים לפי GDPR דורשות תיאום ידני בין מערכות. | ניתן לבטל אישורים מיידית, ממלאים את “זכות ההשכחה”. |

### 1.2 מושגי יסוד של DID

- **DID (מזהה מבוזר)** – מחרוזת ייחודית גלובלית, דמוית URL (`did:example:123456789abcdefghi`) שמפנה למסמך DID המכיל מפתחות ציבוריים ונקודות שירות.  
- **אישור ניתנת לאימות** – הצהרות חתומות קריפטוגרפית (למשל, “ספק נתונים – יוצר נתונים סינתטיים מוסמך”) שניתן להציג ולוודא מבלי לחשוף נתונים אישיים.  
- **חשיפה נבחרת** – הוכחות אפס‑ידע מאפשרות למחזיק להוכיח תכונות (למשל, מוסמך לפי [ISO 27001](https://www.iso.org/standard/27001)) מבלי לחשוף את כל האישור.  

הפרימיטיבים הללו מעניקים לכל משתתף בשוק **זהות ריבונית (SSI)**, תנאי מקדים להחלפת נתונים שמגנה על פרטיות.

---

## 2. אכיפת אפס‑אמון עם Formize

מנוע זרימת העבודה של Formize מתייחס **לכל אינטראקציה כלא אמינה** עד שיוכח אחרת. הפלטפורמה מעריכה מדיניות המוגדרת ב‑DSL ברמה גבוהה שיכולה להתייחס למאפייני DID, הוכחות אישורים, וציוני סיכון בזמן אמת.

### 2.1 דוגמת מדיניות

```yaml
policy:
  name: "SyntheticDataAccessPolicy"
  description: "Allow access only if consumer holds a valid DataConsumer credential and the request originates from a zero‑trust edge node."
  conditions:
    - did:consumer.hasCredential("DataConsumer")
    - edgeNode.trustScore > 0.85
    - request.purpose in ["modelTraining", "testing"]
  actions:
    - grantAccess
    - logEvent
```

כאשר בקשה מגיעה, Formize:

1. **פותר** את ה‑DID של הצרכן ומוריד את קבוצת ה‑VC העדכנית.  
2. **מאמת** חתימות קריפטוגרפיות וכל הוכחות אפס‑ידע.  
3. **מוערך** את המדיניות מול הקשר דינמי (ציון אמון של צומת הקצה, מטרת הבקשה, וכו').  
4. **מבצע** את הפעולות המוגדרות (מתן גישה, רישום אירוע, סימון מים אופציונלי).  

מאחר שהמדיניות **דקלרטיבית ומגודרת**, עדכוני רגולציה ניתנים לפריסה מיידית בכל השוק.

---

## 3. זרימת שוק מקצה לקצה

הדיאגרמה שלהלן מציגה ברמה גבוהה את האינטראקציה בין ספקי הנתונים, צרכנים, מערכת ה‑DID, ומנוע האפס‑אמון של Formize.

```mermaid
graph LR
    subgraph "שכבת זהות"
        DIDProvider["\"רשימת DID\""]
        VCIssuer["\"מוציא אישורים ניתנים לאימות\""]
    end

    subgraph "ליבת השוק"
        FormizeEngine["\"מנוע אפס‑אמון של Formize\""]
        SmartContract["\"חוזה חכם לרישוי\""]
        DataLake["\"אגם נתונים סינתטיים\""]
    end

    subgraph "משתתפים"
        Provider["\"ספק נתונים\""]
        Consumer["\"צרכן נתונים\""]
        EdgeNode["\"צומת קצה אפס‑אמון\""]
    end

    Provider -->|רושם DID| DIDProvider
    Provider -->|מקבל אישור| VCIssuer
    Consumer -->|רושם DID| DIDProvider
    Consumer -->|מקבל אישור| VCIssuer

    Provider -->|מפרסם מטא‑נתונים| SmartContract
    Provider -->|אוחסן נתונים| DataLake

    Consumer -->|מבקש גישה| EdgeNode
    EdgeNode -->|מעביר בקשה| FormizeEngine
    FormizeEngine -->|פותר DID ואישורים| DIDProvider
    FormizeEngine -->|מוערך מדיניות| SmartContract
    FormizeEngine -->|מאשר/דוחה| EdgeNode
    EdgeNode -->|מספק נתונים| Consumer
```

**נקודות מפתח מהדיאגרמה**

- **כל המשתתפים מחזיקים DID** המאוחסן ברשומה מבוזרת.  
- **אישורים ניתנים לאימות** ניתנים על‑ידי גורמים מהימנים (לדוגמה, מבקרי ISO, גופים רגולטוריים) ומצורפים ל‑DID.  
- **Formize** משמש כנקודת החלטה של מדיניות, ומושך נתוני זהות בזמן אמת.  
- **חוזים חכמים** מאכילים תנאי רישוי (למשל, מגבלות שימוש, סעיפי ביטול) והם בלתי ניתנים לשינוי בשרשרת.

---

## 4. יישום השוק על Formize

### 4.1 דרישות מוקדמות

| רכיב | כלי מומלץ |
|------|-----------|
| רשימת DID | **Ceramic**, **ION**, או **Hyperledger Indy** |
| מוציא אישורים ניתנים לאימות | **Trinsic**, **Veramo**, או PKI מותאם |
| מופע Formize | Formize SaaS בענן או פריסה עצמאית ב‑Docker |
| פלטפורמת חוזים חכמים | **Ethereum**, **Polygon**, או **Hyperledger Fabric** |
| אחסון | מאגר אובייקטים מוצפן (למשל AWS S3 עם SSE‑KMS) |

### 4.2 מדריך שלב‑אחר‑שלב

1. **יצירת DIDs לכל הצדדים**  
   ```bash
   curl -X POST https://did-registry.example.com/dids \
        -d '{"method":"ion","keyType":"Ed25519"}'
   ```
   שמרו את ה‑URI של ה‑DID שהוחזר בארנק של כל משתתף.

2. **הנפקת אישורים ניתנים לאימות**  
   ```json
   {
     "type": ["VerifiableCredential", "DataProviderCredential"],
     "issuer": "did:example:issuer123",
     "credentialSubject": {
       "id": "did:example:provider456",
       "role": "SyntheticDataProvider",
       "certifications": ["ISO27001", "GDPRCompliant"]
     },
     "proof": { /* cryptographic proof */ }
   }
   ```

3. **פרסום מטא‑נתונים של הנתונים בחוזה חכם**  
   ```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. **הגדרת מדיניות Formize** (כפי שמופיע בסעיף 2.1) והעלאתה דרך ממשק המשתמש של Formize או ה‑API.

5. **זרימת בקשת הצרכן**  
   - הצרכן חותם בקשה עם המפתח הפרטי שלו.  
   - צומת הקצה מעביר את הבקשה ל‑Formize.  
   - Formize פותר את ה‑DID של הצרכן, מאמת את ה‑VC, בודק את המדיניות, ומחזיר **access token** חתום על‑ידי Formize.  
   - צומת הקצה משתמש בטוקן כדי לשאוב את הנתונים הסינתטיים המוצפנים מ‑Data Lake, מפענח אותם מקומית, ורושם את העסקה בבלוקצ'יין.

6. **ביטול וביקורת**  
   - אם אישור מבוטל (למשל, ספק מאבד תעודה), המוציא מעדכן את מסמך ה‑DID. הערכה הבאה של Formize תדחה אוטומטית גישה נוספת.  
   - כל ההחלטות נרשמות במסלול ביקורת בלתי ניתן לשינוי, הניתן לחיפוש דרך לוח המחוונים האנליטי המובנה של Formize.

### 4.3 דוגמת קריאת API של Formize

```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..." }
}
```

תשובה (אישור):

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

---

## 5. יתרונות ציות

| רגולציה | איך השוק מסייע |
|----------|----------------|
| **[GDPR](https://gdpr.eu/)** | SSI מאפשרת לנושאי הנתונים למשוך את ההסכמה מיידית; אישורים ניתנים לביטול מספקים “זכות להישכח”. |
| **[CCPA](https://oag.ca.gov/privacy/ccpa)** | יומני ביקורת שקופים מספקים “רשומת גילויים”. |
| **[HIPAA](https://www.hhs.gov/hipaa/index.html)** | הצפנה מקצה‑לקצה וצמתים אפס‑אמון מבודדים נתונים רגישים הקשורים ל‑PHI. |
| **[EU AI Act Compliance](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)** | רישוי דינמי מבטיח שמודלים AI בעלי סיכון גבוה משתמשים רק בנתונים סינתטיים מוסמכים. |

מאחר שהמדיניות היא **קוד‑ראשון** ומגודרת, צוותי הציות יכולים למפות כל תקנה לכל כלל ספציפי, מה שמפשט ביקורות ומפחית סיכון משפטי.

---

## 6. שיפורים עתידיים

1. **AI‑Driven Risk Scoring** – אינטגרציה של מודלים מבוססי LLM להערכת סיכון שמעדכנים את ציון האמון של צמתי הקצה בזמן אמת על‑בסיס מודיעין אי‑האי.  
2. **Cross‑Chain Interoperability** – אפשרות לחוזי רישוי על מספר בלוקצ'אינים (לדוגמה, parachains של Polkadot) להרחבה גלובלית.  
3. **Marketplace Reputation System** – שימוש באישורים ניתנים לאימות להנפקת תגי מוניטין שמדולגים עם הזמן אלא אם כן מתחדשים.  
4. **Zero‑Knowledge Data Provenance** – שימוש ב‑zk‑SNARKs כדי להוכיח שמערך נתונים סינתטי נוצר ממקור מסוים מבלי לחשוף את המקור עצמו.  

---

## 7. סיכום

על‑ידי שילוב **זהות מבוזרת**, **אכיפת אפס‑אמון**, ו‑**מנוע המדיניות הגמיש של Formize**, ארגונים יכולים להשיק **שוק נתונים סינתטיים שמגן על פרטיות** שמסוגל להתרחב מעבר לגבולות, לעמוד ברגולציות, ולהגן על נושאי הנתונים. הארכיטקטורה מבטלת צווארי בקבוק מרכזיים, מאפיינת רישוי אוטומטי, ומספקת מסלול ביקורת בלתי ניתן לשינוי – מרכיבים מרכזיים לצינור AI אמין בעידן של שיתוף נתונים אחראי.

---

## ראה גם

- [Decentralized Identifiers (DIDs) – W3C Recommendation](https://www.w3.org/TR/did-core/) – **מזהים מבוזרים (DIDs) – המלצת W3C**  
- Formize Zero‑Trust Workflow Engine Documentation – **תיעוד מנוע זרימת העבודה של אפס‑אמון של Formize**  
- [Verifiable Credentials Data Model 2.0 – W3C](https://www.w3.org/TR/vc-data-model/) – **מודל נתוני אישורים ניתנים לאימות 2.0 – W3C**  
- Synthetic Data Governance – NIST AI Risk Management Framework – **ממשל נתונים סינתטיים – מסגרת ניהול סיכוני AI של NIST**