
# Arsitektur Mikro‑layanan AI Komposabel untuk Otomatisasi Kuesioner Keamanan yang Dapat Diskalakan

Perusahaan menghadapi gelombang kuesioner keamanan, penilaian vendor, dan audit kepatuhan yang terus meningkat. Alat monolitik tradisional kesulitan mengikuti, terutama ketika harus berintegrasi dengan ekosistem produk yang beragam, mendukung permintaan multibahasa, dan menyediakan jejak audit real‑time.  

**Arsitektur mikro‑layanan komposabel**, yang dibangun di sekitar model bahasa besar (LLM) dan generasi berbantuan pengambilan (RAG), menawarkan cara menskalakan otomatisasi sambil mempertahankan fleksibilitas dan tata kelola yang dibutuhkan industri yang diatur. Dalam panduan ini kita akan:

* Menjabarkan prinsip‑prinsip desain inti yang menjaga sistem **aman, dapat diaudit, dan dapat diperluas**.  
* Menelusuri implementasi referensi yang digambarkan dengan Mermaid.  
* Menunjukkan cara setiap layanan dapat dideploy secara independen di Kubernetes, serverless FaaS, atau runtime edge.  
* Memberikan rekomendasi praktik terbaik yang konkret untuk tata kelola data, observabilitas, dan peningkatan berkelanjutan.

> **TL;DR:** Pecah platform otomatisasi kuesioner menjadi layanan‑layanan kecil yang terdefinisi dengan baik, letakkan LLM di belakang lapisan inferensi stateless, dan gunakan pipeline berbasis event untuk mempertahankan satu sumber kebenaran bagi bukti dan kontrol versi.

---

## 1. Mengapa Membuat Komposisi Daripada Membangun Monolit Raksasa?

| Pendekatan Monolitik | Mikro‑layanan Komposabel |
|----------------------|--------------------------|
| Basis kode tunggal, sulit menskalakan beban kerja spesifik (misalnya inferensi LLM). | Skala independen – inferensi AI dapat berjalan pada node GPU, sementara penyimpanan tetap pada object store yang hemat biaya. |
| Keterkaitan ketat membuat pembaruan berisiko; bug pada UI dapat menjatuhkan seluruh sistem. | Keterkaitan longgar melalui event asinkron atau API HTTP mengisolasi kegagalan. |
| Integrasi bahasa‑agnostik terbatas – sering terkunci pada satu stack. | Dukungan polyglot – setiap layanan dapat ditulis dalam bahasa yang paling cocok untuk tugasnya (Go untuk otentikasi, Python untuk orkestrasi LLM, Rust untuk pipeline throughput tinggi). |
| Audit dan kepatuhan menjadi mimpi buruk karena log saling terkait. | Penyimpanan event terpusat + audit log tidak dapat diubah menyediakan jejak yang jelas dan dapat ditanyakan bagi regulator. |

Model **Komposabel** mengadopsi filosofi *“Anda membangun apa yang Anda butuhkan, dan mengganti apa yang tidak Anda butuhkan”*. Model ini cocok dengan sifat dinamis kuesioner keamanan, di mana kerangka kontrol baru (misalnya [ISO 27001 Rev 2](https://www.iso.org/standard/27001)) muncul secara reguler dan tim harus cepat beradaptasi.

---

## 2. Pilar Arsitektural Inti

1. **API Gateway Stateless** – titik masuk untuk UI, konektor SaaS, dan alat eksternal. Menangani otentikasi, validasi permintaan, dan throttling.  
2. **Mikro‑layanan Spesifik Domain** – masing‑masing mengenkapsulasi konteks terbatas:
   * **Layanan Kuesioner** – menyimpan metadata kuesioner, versioning, dan penugasan tugas.  
   * **Layanan Bukti** – mengelola artefak (kebijakan, screenshot, log audit) di object store yang tidak dapat diubah.  
   * **Layanan Orkestrasi AI** – menyusun prompt, menjalankan pipeline RAG, dan mengembalikan draft jawaban.  
   * **Layanan Deteksi Perubahan** – memantau pembaruan bukti, memicu evaluasi ulang jawaban yang terdampak.  
   * **Layanan Notifikasi** – mengirimkan event ke Slack, Teams, atau email kepada pemangku kepentingan.  
3. **Event Bus (Kafka / Pulsar)** – menjamin pengiriman *at‑least‑once* dari event domain (misalnya `EvidenceUploaded`, `AnswerDrafted`).  
4. **Stack Observabilitas** – jejak OpenTelemetry lintas layanan, metrik Prometheus, dan log Loki.  
5. **Engine Policy‑as‑Code** – mengevaluasi aturan kepatuhan (ditulis dalam Rego atau OPA) sebelum jawaban ditandai “final”.  

Semua layanan berkomunikasi via **gRPC** (untuk latency rendah) atau **REST** (untuk integrasi eksternal). Desain ini mendorong *pipa bodoh, endpoint pintar*—logika bisnis berada di tempat yang tepat, sementara bus hanya mengangkut pesan.

---

## 3. Alur Data – Dari Pertanyaan ke Jawaban yang Dapat Diaudit

Berikut diagram Mermaid yang memvisualisasikan siklus hidup permintaan yang tipikal.

```mermaid
flowchart TD
    subgraph UI["Antarmuka Pengguna"]
        UI1["\"Web UI\""] -->|Submit questionnaire| AG["\"API Gateway\""]
    end

    AG -->|Auth & Validate| QMS["\"Questionnaire Service\""]
    QMS -->|Fetch template| AIOS["\"AI Orchestration Service\""]
    AIOS -->|Retrieve relevant evidence| ES["\"Evidence Service\""]
    ES -->|Evidence objects| AIOS
    AIOS -->|Generate draft answer| RAG["\"RAG Pipeline\""]
    RAG -->|LLM output| AIOS
    AIOS -->|Store draft| QMS
    QMS -->|Emit AnswerDrafted| EB["\"Event Bus\""]
    EB -->|Trigger| CDS["\"Change‑Detection Service\""]
    CDS -->|Re‑run if evidence changed| AIOS
    CDS -->|Emit AnswerUpdated| EB
    EB -->|Notify| NS["\"Notification Service\""]
    NS -->|Push to Slack/Email| UI

    style UI fill:#f9f,stroke:#333,stroke-width:2px
    style AG fill:#bbf,stroke:#333,stroke-width:1px
    style QMS fill:#bfb,stroke:#333,stroke-width:1px
    style AIOS fill:#ffb,stroke:#333,stroke-width:1px
    style ES fill:#fbb,stroke:#333,stroke-width:1px
    style RAG fill:#fdd,stroke:#333,stroke-width:1px
    style CDS fill:#ddf,stroke:#333,stroke-width:1px
    style NS fill:#cfc,stroke:#333,stroke-width:1px
```

**Momen kunci dalam alur**:

1. **Pengguna mengirim** kuesioner baru atau memilih yang sudah ada.  
2. **API Gateway** memvalidasi JWT, memeriksa rate limit, lalu meneruskan ke Layanan Kuesioner.  
3. **Layanan Kuesioner** mengambil template kuesioner dan memposting event ke Layanan Orkestrasi AI.  
4. **Orkestrasi AI** melakukan *langkah pengambilan*—ia menanyakan Layanan Bukti untuk semua artefak yang relevan dengan kontrol saat ini (menggunakan kesamaan vektor atau pencocokan kata kunci).  
5. Konteks yang diambil, bersama dengan template prompt, dimasukkan ke **pipeline RAG** (misalnya `openAI/gpt‑4o‑preview`).  
6. Draft jawaban disimpan kembali di Layanan Kuesioner, ditandai *“pending review.”*  
7. **Layanan Deteksi Perubahan** memantau upload bukti baru. Jika sebuah kebijakan diperbarui, ia memicu kembali pipeline RAG untuk jawaban yang terdampak.  
8. Peninjau akhir menerima atau mengedit draft; setelah diterima, **Engine Policy‑as‑Code** memvalidasi bahwa jawaban memenuhi semua aturan sebelum mencatatnya ke audit log yang tidak dapat diubah.  

---

## 4. Detail Implementasi

### 4.1. API Gateway (Envoy + OIDC)

* **Routing** – `POST /questionnaires/:id/answers` → `questionnaire-service`.  
* **Keamanan** – Menegakkan scope (`questionnaire:write`).  
* **Rate limiting** – 100 permintaan/menit per tenant untuk melindungi biaya LLM downstream.

### 4.2. Layanan Kuesioner (Go)

```go
type Questionnaire struct {
    ID          string            `json:"id"`
    Version     int               `json:"version"`
    Controls    []Control        `json:"controls"`
    Drafts      map[string]Answer `json:"drafts"` // key = control ID
    AssignedTo  map[string]string `json:"assigned_to"` // userID
}
```

* Menggunakan **PostgreSQL** untuk data relasional, **EventStoreDB** untuk event domain.  
* Menyediakan metode gRPC `GetTemplate`, `SaveDraft`, `FinalizeAnswer`.

### 4.3. Layanan Bukti (Python + FastAPI)

* Menyimpan berkas di **MinIO** atau **AWS S3** dengan enkripsi tingkat bucket.  
* Mengindeks konten di **Qdrant** (database vektor) untuk pencarian kesamaan.  
* Menyediakan endpoint `POST /search` yang menerima kueri dan mengembalikan ID artefak top‑k.

### 4.4. Layanan Orkestrasi AI (Python)

```python
def generate_answer(question: str, evidence_ids: List[str]) -> str:
    evidence = fetch_evidence(evidence_ids)
    context = "\n".join(evidence)
    prompt = f"""You are a compliance specialist.
    Using the following evidence, answer the question concisely:\n{context}\n\nQuestion: {question}"""
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role":"system","content":prompt}]
    )
    return response.choices[0].message.content
```

* **RAG** – Menggabungkan pencarian vektor dengan *system prompt* yang menginstruksikan model untuk menyebutkan ID bukti.  
* **Caching** – Menyimpan respons yang dihasilkan selama 24 jam untuk menghindari panggilan LLM berulang.

### 4.5. Layanan Deteksi Perubahan (Rust)

* Berlangganan pada event `EvidenceUploaded`.  
* Menghitung **hash** artefak baru dan menjalankan **diff** terhadap bukti yang sudah terhubung ke setiap kontrol.  
* Jika diff melebihi ambang yang dapat dikonfigurasi, mempublikasikan `AnswerRequiresRegen`.

### 4.6. Layanan Notifikasi (Node.js)

* Mendengarkan `AnswerDrafted`, `AnswerFinalized`, `AnswerRequiresRegen`.  
* Memformat blok Slack, Adaptive Card Teams, atau templat email.  
* Mendukung **deduplication** – hanya memberi notifikasi sekali per perubahan per kuesioner.

---

## 5. Keamanan & Tata Kelola

| Kekhawatiran | Mitigasi |
|--------------|----------|
| **Kebocoran Data** – Prompt LLM dapat berisi teks kebijakan sensitif. | Gunakan **inferensi LLM on‑prem** (misalnya Llama 3.2) di dalam VPC. Masking PII sebelum mengirim ke API eksternal. |
| **Akses Bukti Tidak Sah** | Terapkan kontrol akses halus menggunakan kebijakan OPA pada Layanan Bukti. |
| **Drift Model** – Jawaban menurun seiring waktu. | Jadwalkan **evaluasi periodik** terhadap korpus benchmark dan perbarui template prompt. |
| **Auditability** | Setiap transisi status dicatat dalam event log yang tidak dapat diubah dan disimpan di **WORM S3**. |
| **Kepatuhan GDPR/CCPA** | Implementasikan alur kerja **right‑to‑be‑forgotten** yang menghapus bukti spesifik pengguna dari DB vektor dan object store ([GDPR](https://gdpr.eu/)). |
| **Kepatuhan ISO 27001** | Validasi bahwa retensi bukti, enkripsi, dan kebijakan kontrol‑akses selaras dengan standar ISO 27001. |
| **HIPAA / SOC 2** | Untuk penyedia layanan kesehatan atau SaaS, perpanjang aturan OPA untuk menegakkan perlindungan yang diperlukan. |

---

## 6. Strategi Skalasi

1. **Horizontal Pod Autoscaling (HPA)** – Menskalakan pod Orkestrasi AI berdasarkan pemanfaatan GPU (`nvidia.com/gpu`).  
2. **Queue yang Dapat Ditingkatkan** – Gunakan partisi Kafka untuk memisahkan tenant dengan beban tinggi.  
3. **Pengurangan Cold‑Start** – Pertahankan pool kontainer warm untuk server inferensi LLM (misalnya menggunakan **KEDA** dengan scaler khusus).  
4. **Kontrol Biaya** – Terapkan **budget token** per tenant; throttling atau penagihan otomatis atas penggunaan berlebih.

---

## 7. Observabilitas & Perbaikan Berkelanjutan

* **Tracing Terdistribusi** – Span OpenTelemetry dari permintaan UI → API Gateway → Orkestrasi AI → RAG → Layanan Bukti.  
* **Metrik** – `answer_draft_latency_seconds`, `evidence_upload_bytes`, `llm_token_usage`.  
* **Aggregasi Log** – Log JSON terstruktur dengan `request_id` yang dipropagasikan lintas layanan.  
* **Loop Umpan Balik** – Setelah jawaban difinalisasi, kumpulkan komentar reviewer (`review_score`). Masukkan ke dalam model **reinforcement learning** yang menyesuaikan suhu prompt atau memilih sumber bukti alternatif.

---

## 8. Jalur Migrasi Langkah‑ demi‑Langkah untuk Tim yang Sudah Ada

| Tahap | Tujuan | Aktivitas |
|-------|--------|-----------|
| **0 – Penemuan** | Memetakan alur kerja kuesioner saat ini. | Identifikasi sumber data, definisikan taksonomi kontrol. |
| **1 – Membangun Fondasi** | Deploy API Gateway, otentikasi, dan layanan dasar. | Containerize `questionnaire-service` dan `evidence-service`. |
| **2 – Memperkenalkan AI** | Jalankan RAG pada kuesioner pilot. | Gunakan LLM sandbox, verifikasi draft secara manual. |
| **3 – Automasi Berbasis Event** | Hubungkan pipeline Deteksi Perubahan. | Aktifkan auto‑regen pada pembaruan bukti. |
| **4 – Penguatan Tata Kelola** | Tambahkan kebijakan OPA, audit log tidak dapat diubah. | Beralih ke LLM produksi (on‑prem). |
| **5 – Skalasi & Optimasi** | Autoscale pod GPU, terapkan kontrol biaya. | Deploy stack observabilitas, tetapkan SLO. |

Dengan mengadopsi arsitektur komposabel secara inkremental, tim menghindari risiko “big‑bang” dan dapat menunjukkan ROI awal (biasanya **pengurangan 30‑50 %** waktu penyelesaian kuesioner).

---

## 9. Memastikan Masa Depan Stack

* **Federated Learning** – Melatih adaptor ringan pada data tiap tenant tanpa memindahkan bukti mentah ke luar, meningkatkan relevansi jawaban sambil menghormati kedaulatan data.  
* **Service Mesh Zero‑Trust** – Gunakan **Istio** atau **Linkerd** dengan mutual TLS untuk mengamankan trafik antar layanan.  
* **Tata Kelola Semantik** – Perluas engine Policy‑as‑Code untuk memvalidasi tidak hanya konten jawaban tetapi juga **kesamaan semantik** antara bukti dan bahasa kontrol.  
* **Traceability Generatif** – Simpan suhu LLM, top‑p, dan prompt sistem bersamaan dengan tiap jawaban untuk inspeksi forensik.

---

## 10. Kesimpulan

Arsitektur mikro‑layanan komposabel mengubah otomatisasi kuesioner keamanan dari **tugas manual yang menyiksa** menjadi **mesin yang dapat diskalakan, dapat diaudit, dan terus berkembang**. Dengan memisahkan tanggung jawab, memanfaatkan LLM melalui lapisan RAG yang stateless, dan menghubungkan semuanya dengan backbone berbasis event, organisasi dapat:

* Menanggapi penilaian vendor dalam menit, bukan hari.  
* Menjaga bukti kepatuhan selalu mutakhir dengan deteksi perubahan otomatis.  
* Menyediakan regulator jejak audit yang jelas dan tidak dapat diubah.  

Mulailah dengan skala kecil, iterasikan dengan cepat, dan biarkan filosofi mikro‑layanan memandu Anda menuju masa depan di mana kepatuhan menjadi **fitur**, bukan hambatan.

---

## Lihat Juga

- ["OPA Kebijakan sebagai Kode untuk Mikro‑layanan"](https://www.openpolicyagent.org/docs/latest/policy-language/)