# Pengurusan Persetujuan Dinamik untuk Penjanaan Data Sintetik dengan Formize dan AI Generatif

> **TL;DR** – Paip data sintetik moden selalunya mengabaikan keutamaan persetujuan yang berubah-ubah daripada subjek data. Dengan menyematkan orkestrasi borang masa‑nyata Formize ke dalam sintesis data yang dipacu AI generatif, organisasi dapat menangkap persetujuan terperinci, menguatkuasakannya secara automatik semasa penjanaan data, dan mengekalkan jejak audit yang tidak boleh diubah yang memenuhi [GDPR](https://gdpr.eu/), [CCPA](https://oag.ca.gov/privacy/ccpa), dan peraturan etika AI yang sedang muncul seperti [EU AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai).

---

## Mengapa Persetujuan Penting dalam Data Sintetik

Data sintetik menjanjikan analitik yang melindungi privasi, tetapi data *sumber* masih milik individu sebenar. Peraturan seperti **EU General Data Protection Regulation (GDPR)**, **California Consumer Privacy Act (CCPA)**, dan **EU AI Act** yang akan datang memerlukan bahawa sebarang penggunaan data peribadi—sama ada nyata atau sintetik—mematuhi pilihan persetujuan subjek data.

Cabaran utama:

| Cabaran | Kesan Biasa |
|-----------|----------------|
| **Skop persetujuan terperinci** | Persetujuan “ya/tidak” secara menyeluruh tidak dapat menangkap keutamaan nuansa (contoh: “benarkan data kesihatan untuk penyelidikan tetapi tidak untuk pemasaran”). |
| **Versi persetujuan** | Persetujuan berubah; versi lama mungkin menjadi tidak sah, namun paip terus menggunakan kebenaran yang lapuk. |
| **Penguatkuasaan merentasi sistem** | Paip data merentasi pelbagai alat (ETL, LLM, storan). Menguatkuasakan persetujuan merentasi semua alat mudah terdedah kepada ralat. |
| **Auditabiliti** | Pengawal selia menuntut bukti persetujuan yang tidak boleh diubah pada saat penjanaan data. |

Formize, dengan pembina borang low‑code, seni bina API‑first, dan log audit yang serasi blockchain, berada pada kedudukan unik untuk menyelesaikan masalah ini.

---

## Gambaran Seni Bina

Berikut ialah diagram Mermaid aras tinggi yang menggambarkan aliran end‑to‑end dari penangkapan persetujuan hingga penjanaan data sintetik dan penggunaan seterusnya.

```mermaid
flowchart TD
    A["Portal Subjek Data"] --> B["Borang Persetujuan Formize"]
    B --> C["Ledger Persetujuan (Tidak Boleh Diubah)"]
    C --> D["API Perkhidmatan Persetujuan"]
    D --> E["Orkestrator Data Sintetik"]
    E --> F["Model AI Generatif (LLM / Diffusion)"]
    F --> G["Stor Penyimpanan Set Data Sintetik"]
    G --> H["Pasukan Analitik & ML"]
    H --> I["Papan Pemuka Audit Peraturan"]
```

*Semua nod diletakkan dalam tanda petik seperti yang diperlukan; tiada aksara terescape digunakan.*

### Pecahan Komponen

1. **Portal Subjek Data** – UI web atau mudah alih di mana individu dapat melihat, mengubah, atau menarik balik persetujuan.
2. **Borang Persetujuan Formize** – Borang low‑code yang boleh dikonfigurasi untuk menangkap skop persetujuan, tujuan, kategori data, dan tarikh luput.
3. **Ledger Persetujuan** – Formize menulis setiap peristiwa persetujuan ke dalam log yang tidak boleh diubah (pilihan untuk dipautkan ke blockchain bagi bukti ketidakserobohan).
4. **API Perkhidmatan Persetujuan** – Mikro‑perkhidmatan ringan yang mengekspos titik akhir `GET /consent/{subjectId}` dan `POST /consent/validate`.
5. **Orkestrator Data Sintetik** – Mengatur ekstraksi data, transformasi, dan pemakanan ke dalam model generatif. Ia memanggil Perkhidmatan Persetujuan sebelum setiap kerja penjanaan.
6. **Model AI Generatif** – Sebarang LLM, model difusi, atau penyintesis tabular yang menggunakan data mentah.
7. **Stor Penyimpanan Set Data Sintetik** – Storan objek selamat dengan metadata yang memaut kembali kepada versi persetujuan yang digunakan.
8. **Pasukan Analitik & ML** – Menggunakan data sintetik untuk latihan model, ujian, atau pelaporan.
9. **Papan Pemuka Audit Peraturan** – Memvisualisasikan asal usul persetujuan, cap masa penjanaan, dan garis keturunan model.

---

## Panduan Pelaksanaan Langkah‑ demi‑Langkah

### 1. Reka Bentuk Borang Persetujuan dalam Formize

* Gunakan pembina seret‑dan‑lepas Formize untuk mencipta medan:
  * **Kategori Data** – Pilihan berbilang (contoh: “demografi”, “rekod perubatan”, “transaksi kewangan”).
  * **Tujuan Dibenarkan** – Kotak semak (contoh: “penyelidikan”, “pembangunan produk”, “pemasaran”).
  * **Tempoh Penyimpanan** – Pemilih tarikh.
  * **Syarat Dinamik** – Logik bersyarat yang memaparkan medan tambahan apabila “Data Sensitif” dipilih.

* Aktifkan **versi**: setiap kali skema borang berubah, Formize secara automatik mencipta ID versi baru (`v1`, `v2`, …). ID versi ini disimpan bersama setiap rekod persetujuan.

### 2. Tangkap Peristiwa Persetujuan

Apabila subjek menghantar borang:

```json
POST /api/v1/consent
{
  "subjectId": "user-12345",
  "formVersion": "v3",
  "consentGiven": true,
  "scopes": ["demographics", "financial"],
  "purposes": ["research"],
  "expiresAt": "2028-12-31T23:59:59Z",
  "signature": "base64‑encoded‑hash"
}
```

Formize menulis beban ini ke **Ledger Persetujuan**, yang boleh dikonfigurasi untuk:

* Menyimpan dalam pangkalan data append‑only yang tidak boleh diubah (contoh: **Cassandra** dengan kompaksi **Time‑Series**).
* Secara pilihan menerbitkan hash ke blockchain awam (contoh: **Ethereum** atau **Polygon**) untuk pengesahan luaran.

### 3. Bina API Perkhidmatan Persetujuan

Pembungkus nipis di atas SDK Formize:

```go
// consent_service.go
package consent

import (
    "net/http"
    "encoding/json"
    "github.com/formize/sdk"
)

type ConsentRequest struct {
    SubjectID string `json:"subjectId"`
    DataCategories []string `json:"dataCategories"`
    Purpose string `json:"purpose"`
}

// Validate memeriksa sama ada persetujuan subjek meliputi skop yang diminta.
func Validate(w http.ResponseWriter, r *http.Request) {
    var req ConsentRequest
    json.NewDecoder(r.Body).Decode(&req)

    consent, err := sdk.GetLatestConsent(req.SubjectID)
    if err != nil {
        http.Error(w, "Persetujuan tidak ditemui", http.StatusNotFound)
        return
    }

    // Enjin peraturan ringkas
    allowed := false
    for _, cat := range req.DataCategories {
        for _, allowedCat := range consent.Scopes {
            if cat == allowedCat {
                allowed = true
                break
            }
        }
    }

    if allowed && consent.PurposesContains(req.Purpose) && !consent.IsExpired() {
        w.WriteHeader(http.StatusOK)
        json.NewEncoder(w).Encode(map[string]bool{"allowed": true})
    } else {
        w.WriteHeader(http.StatusForbidden)
        json.NewEncoder(w).Encode(map[string]bool{"allowed": false})
    }
}
```

*Perkhidmatan ini boleh dideploy sebagai fungsi **Knative** atau kontena **Docker** di belakang pintu API.*

### 4. Integrasikan dengan Orkestrator Data Sintetik

Kebanyakan platform orkestrasi (contoh: **Airflow**, **Prefect**, **Dagster**) menyokong operator Python tersuai. Berikut ialah tugas Prefect yang mengesahkan persetujuan sebelum melancarkan kerja penjanaan.

```python
# consent_check_task.py
from prefect import task, Flow
import requests

@task
def check_consent(subject_id: str, categories: list, purpose: str):
    payload = {
        "subjectId": subject_id,
        "dataCategories": categories,
        "purpose": purpose
    }
    resp = requests.post("https://consent.service/api/v1/validate", json=payload)
    resp.raise_for_status()
    return resp.json()["allowed"]

@task
def generate_synthetic_data(subject_id: str):
    # Tempat pemanggilan model LLM atau difusi
    print(f"Menjana data sintetik untuk {subject_id}")

with Flow("synthetic-data-pipeline") as flow:
    allowed = check_consent("user-12345", ["demographics"], "research")
    generate = generate_synthetic_data("user-12345")
    generate.set_upstream(allowed, upstream_tasks=[allowed])

flow.run()
```

Jika `allowed` ialah `False`, paip dibatalkan, dan entri audit dicatat.

### 5. Simpan Metadata Penjanaan

Apabila set data sintetik disimpan, lampirkan **manifest metadata**:

```json
{
  "datasetId": "synthetic-2026-08-21-001",
  "generatedAt": "2026-08-21T14:32:10Z",
  "consentVersion": "v3",
  "subjectId": "user-12345",
  "model": "gpt‑4‑synthetic‑v1",
  "purpose": "research"
}
```

Formize boleh secara automatik menyematkan manifest ini ke dalam **metadata khusus** objek (contoh: tajuk `x-amz-meta-*` pada S3) atau menyimpannya dalam **katalog** seperti **DataHub**.

### 6. Bina Papan Pemuka Audit

Menggunakan **Grafana** atau **Superset**, visualisasikan:

* Versi persetujuan vs. versi set data sintetik.
* Bilangan set data yang dijana per tujuan.
* Peristiwa penarikan persetujuan dan impaknya ke atas paip hiliran.

Contoh kueri panel Grafana (pseudokod SQL‑like):

```sql
SELECT
  consent_version,
  COUNT(*) AS datasets_generated,
  SUM(CASE WHEN purpose = 'research' THEN 1 ELSE 0 END) AS research_datasets
FROM synthetic_dataset_store
GROUP BY consent_version
ORDER BY consent_version DESC;
```

---

## Manfaat Gelung Persetujuan Berpacu Formize

| Manfaat | Penjelasan |
|---------|------------|
| **Pematuhan Peraturan** | Pengesahan masa‑nyata memastikan hanya data dengan persetujuan terkini digunakan, memenuhi GDPR Art. 7 dan CCPA § 1798.120. |
| **Persetujuan Dinamik** | Subjek boleh mengubah keutamaan pada bila‑bila masa; jalankan paip seterusnya secara automatik menghormati keadaan baru. |
| **Kebolehkesanan Tidak Boleh Diubah** | Setiap peristiwa persetujuan dihubungkan secara kriptografi dengan set data yang dijana, membolehkan audit yang tidak boleh dipalsukan. |
| **Low‑Code yang Boleh Diskala** | Pembina visual Formize mengurangkan masa pembangunan; pasukan pematuhan bukan teknikal boleh mengurus borang secara langsung. |
| **Penggunaan Semula Merentasi Domain** | Perkhidmatan persetujuan yang sama boleh dimanfaatkan oleh analitik, latihan AI, dan pasar data pihak ketiga. |

---

## Kes Penggunaan Dunia Sebenar

### 1. Konsortium Penyelidikan Penjagaan Kesihatan

Sebuah konsortium berbilang institusi memerlukan rekod pesakit sintetik untuk latihan model AI sambil menghormati keutamaan opt‑out pesakit. Dengan melancarkan gelung persetujuan, konsortium:

* Menangkap persetujuan di portal hospital.
* Menjamin bahawa mana‑mana kohort sintetik tidak termasuk pesakit yang menarik balik persetujuan.
* Menyediakan regulator dengan laporan audit satu‑klik yang memaut setiap rekod sintetik kepada hash persetujuan.

### 2. Pemodelan Risiko Perkhidmatan Kewangan

Bank menjana data transaksi sintetik untuk ujian tekanan. Menggunakan Formize, mereka:

* Memisahkan persetujuan “pemasaran” daripada “analisis risiko”.
* Secara automatik menyekat penjanaan data sintetik untuk pelanggan yang hanya bersetuju untuk pemasaran.
* Mengurangkan pendedahan undang‑undang dan mempercepat kitaran pembangunan model.

### 3. Pembangunan Produk Teknologi Pengguna

Sebuah syarikat SaaS mengumpul telemetri penggunaan. Dengan Formize, mereka:

* Menawarkan persetujuan terperinci untuk “eksperimen ciri” vs. “iklan”.
* Menyesuaikan paip data sintetik secara dinamik apabila pengguna menukar keutamaan.
* Menyediakan papan pemuka awam yang telus memaparkan penggunaan data berasaskan persetujuan.

---

## Amalan Terbaik & Perkara yang Perlu Dielakkan

| Amalan Terbaik | Mengapa Penting |
|----------------|-----------------|
| **Versi setiap perubahan borang** | Menjamin rekod persetujuan lama tetap dipautkan kepada skema tepat yang digunakan pada masa penangkapan. |
| **Jangan simpan PII mentah dalam set data sintetik** | Data sintetik harus *diturunkan*; menyimpan pengecam asal meniadakan tujuan privasi. |
| **Hash tandatangan persetujuan dengan garam** | Mencegah serangan rainbow‑table sambil masih membolehkan pengesahan. |
| **Laksanakan “tempoh tenggang” selepas penarikan** | Membolehkan kerja‑kerja yang sedang berjalan selesai dengan lancar sebelum menghentikan penjanaan baru. |
| **Putar kunci penyulitan secara berkala untuk ledger** | Meningkatkan keselamatan log tidak boleh diubah tanpa memutuskan auditability (gunakan strategi key‑rolling). |

**Perkara yang Sering Dihindari**

* **Kod keras logik persetujuan** – Menyematkan logik persetujuan terus dalam kod model menyukarkan kemas kini. Pusatkan melalui API Perkhidmatan Persetujuan.
* **Mengabaikan tarikh luput persetujuan** – Anggap `expiresAt` sebagai tarikh akhir yang keras; jadualkan kerja automatik untuk membatalkan kebenaran.
* **Mengumpul data persetujuan berlebihan** – Kumpulkan hanya apa yang diperlukan untuk tujuan yang dimaksudkan; medan berlebihan meningkatkan risiko “data minimisation” GDPR.

---

## Arah Masa Depan

1. **Penulisan Persetujuan Dibantu AI** – Menggunakan LLM untuk mencadangkan bahasa persetujuan berdasarkan bidang kuasa, mengurangkan beban kerja perundangan.
2. **Persetujuan Terdesentralisasi Merentasi Organisasi** – Menggunakan **Decentralized Identifiers (DIDs)** dan **Verifiable Credentials** untuk berkongsi status persetujuan merentasi sempadan kepercayaan tanpa memusatkan data.
3. **Penarikan Persetujuan Masa‑Nyata melalui Webhooks** – Menolak peristiwa penarikan terus ke Orkestrator Data Sintetik untuk pemutusan paip serta‑merta.
4. **Data Sintetik Boleh Dijelaskan** – Lampirkan penjelasan asal usul (contoh: “dijana menggunakan versi persetujuan v3, tujuan penyelidikan”) pada setiap rekod sintetik untuk kebolehjelasan model hiliran.

---

## Kesimpulan

Persetujuan dinamik bukan lagi tambahan “bagus untuk ada”; ia merupakan keperluan peraturan bagi mana‑mana organisasi yang menukar data peribadi menjadi aset sintetik. Dengan menggabungkan enjin borang low‑code Formize yang tidak boleh diubah dengan paip AI generatif, perusahaan dapat:

* Menangkap persetujuan pada tahap terperinci yang dikehendaki oleh undang‑undang privasi moden.
* Menguatkuasakan persetujuan secara automatik semasa sintesis data.
* Menyediakan auditor dengan bukti kepatuhan yang tidak boleh dipalsukan.

Hasilnya ialah ekosistem data sintetik yang dipercayai, mempercepat inovasi sambil melindungi hak individu.

---

## Lihat Juga

- **Artikel GDPR EU – Artikel 7: Syarat untuk Persetujuan**  
- **Jejak Audit Berasaskan Blockchain untuk Tadbir Urus Data** (IEEE Xplore)