Belajar 9router - Compliance & Auditability
Episode 14 of 23

Belajar 9router - Compliance & Auditability

Episode ini mengubah log menjadi bukti: mengaudit keputusan rute dan pemakaian model, mencatat evaluasi kebijakan dan access history, serta menangani compliance data residency dan privacy dengan enkripsi dan retensi yang teratur.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

Episode 13 membuat gateway tahan banting: input di-guard, konten dimoderasi, PII diredaksi, dan provider dilindungi. Tapi kalian belum bisa membuktikan semua itu terjadi. Saat auditor bertanya "request siapa yang sempat memanggil tool pembayaran?", atau regulator menuntut "di negara mana data model pengguna kami diproses?", jawaban "insyaallah aman" tidak cukup.

Episode 14 mengubah perilaku yang sudah kalian bangun menjadi jejak yang bisa dipertanggungjawabkan. Kita akan mengaktifkan audit log untuk keputusan rute dan pemakaian model, mencatat evaluasi kebijakan dan access history, lalu membahas pertimbangan compliance: data residency, privacy, enkripsi, dan retensi.

Audit Log sebagai Sumber Kebenaran

Audit log bukan sekadar log biasa. Log operasional menjawab "apa yang terjadi sekarang", sedangkan audit log menjawab "siapa melakukan apa, kapan, lewat rute mana, dan bagaimana keputusan diambil" dengan konteks yang cukup untuk investigasi pasca-kejadian. Setelah menulis konfigurasi audit, jalankan 9router audit enable untuk mengaktifkannya. 9router mencatat peristiwa penting secara terstruktur:

Mengaktifkan audit log
audit:
  enabled: true
  destination: stdout
  events:
    - auth_event
    - route_decision
    - policy_evaluation
    - tool_invocation
    - guardrail_trigger
    - cache_hit
  redact:
    - authorization
    - api_key
    - prompt_content

Perhatikan redact di sini: isi prompt sengaja tidak ikut dicatat kecuali memang dibutuhkan, karena data yang tidak pernah tersimpan adalah data yang tidak bisa bocor. Setiap entri punya format standar sehingga bisa dikonsumsi SIEM, diparsing, dan digabungkan dengan log infra lain.

Contoh entri audit log
{
  "ts": "2026-08-03T09:15:22Z",
  "event": "route_decision",
  "request_id": "req_9f2c1a",
  "consumer": "mobile-app",
  "region": "ap-southeast",
  "route": "chat-general",
  "selected_model": "gpt-4o-mini",
  "provider": "openai-prod",
  "tokens_in": 412,
  "tokens_out": 96,
  "latency_ms": 743,
  "policy_version": "v42"
}

Mengaudit Keputusan Rute dan Pemakaian Model

Keputusan routing harus bisa dijelaskan ulang. Mengapa request ini jatuh ke gpt-4o dan bukan gpt-4o-mini? Jawabannya ada di entri route_decision: route yang dipilih, model, provider, dan policy_version yang berlaku saat itu. Versi kebijakan penting karena keputusan lama harus bisa diaudit dengan aturan yang sama seperti saat kejadian.

Telusuri keputusan rute per request
9router audit query --event route_decision --consumer mobile-app --since 24h
9router audit show --request-id req_9f2c1a

Pemakaian model dirangkum menjadi metrik yang bisa diagregasi untuk laporan biaya dan kapasitas: total token per model, per provider, dan per consumer. Data ini juga menjadi dasar cost attribution — mengetahui unit bisnis mana yang menghabiskan anggaran AI paling besar.

Rangkuman pemakaian model
9router audit summary --by model --window 7d
9router audit export --format csv --window 30d

Mencatat Evaluasi Kebijakan dan Guardrail

Salah satu nilai audit log terbesar: membuktikan bahwa kebijakan memang dievaluasi pada setiap request. Entri policy_evaluation mencatat kebijakan mana yang aktif, hasilnya (lolos, ditolak, diredaksi), dan alasan. Ini penting untuk audit compliance dan juga untuk tuning — kalau banyak request diblokir, kalian tahu ada kebijakan yang terlalu ketat.

Contoh evaluasi kebijakan
{
  "event": "policy_evaluation",
  "request_id": "req_a71b9d",
  "policy": "content-safety",
  "guard": "pii-scrub",
  "entity": "credit_card",
  "action": "redact",
  "result": "allowed_with_redaction"
}

Demikian juga guardrail_trigger mencatat kapan prompt_injection atau moderation-in memblokir request. Jumlah blokir yang mencurigakan — misalnya naik mendadak dari satu IP — adalah sinyal yang harus ditindaklanjuti, dan berkat audit log, sinyal itu punya bukti.

Access History dan Trails Kredensial

Audit juga mencatat siapa yang mengakses apa. auth_event mencatat keberhasilan dan kegagalan autentikasi; tool_invocation mencatat tool mana yang dipanggil, oleh consumer mana, dan dengan argumen apa. Akses ke panel admin gateway dan perubahan konfigurasi juga harus masuk log — siapa yang mengubah rate limit, kapan, dari versi apa ke versi apa.

Membatasi siapa yang bisa melihat audit
audit:
  access_control:
    viewers: [security-team, compliance-team]
    immutable: true
    export_require_mfa: true

Set immutable: true membuat entri audit tidak bisa diedit atau dihapus — dasar dari integritas bukti. Akses ke log dibatasi pada tim tertentu, dan ekspor data wajib lewat MFA. Pola ini mengikuti prinsip least privilege dari episode 11, diterapkan pada bukti itu sendiri.

Warning

Waspadai aturan retensi: menyimpan log selamanya bisa melanggar regulasi privacy, sementara menghapus terlalu cepat merusak kemampuan investigasi. Tentukan retensi yang selaras dengan kebijakan kalian, lalu otomatiskan rotasi dan penghapusan.

Data Residency dan Privacy

Kesadaran bahwa "log ada di satu server" tidak lagi cukup ketika data lintas negara. Data residency menuntut data diproses di region yang disetujui — misalnya data warga Eropa harus tetap di Eropa. 9router mendukung region pinning: memaksa rute tertentu hanya memakai provider yang berlokasi di region yang diizinkan.

Memaksa pemrosesan di region tertentu
residency:
  region: eu-central
  enforce: true
  providers_allowed: [azure-eu]
  deny_cross_border: true
  audit_events: true

Dengan enforce: true, request yang secara konfigurasi jatuh ke provider di luar region yang diizinkan akan ditolak — bukan sekadar dicatat. Kombinasikan dengan aturan ABAC dari episode 12 (request.region != eu ditolak) sehingga kebijakan residency berlaku konsisten di lapisan routing dan lapisan request.

Enkripsi data at rest
storage:
  encryption: aes-256
  kms_key_ref: kms/9router-audit
  retention:
    audit_log: 90d
    request_meta: 30d
  pii_tokenization: true

Enkripsi at rest memastikan file log dan metadata tidak terbaca meski media penyimpanan dicuri. Data PII yang lolos ke metadata — jika ada — di-tokenize sehingga tidak dalam bentuk asli. Gabungan residency pinning, enkripsi, dan retensi otomatis adalah garis besar kepatuhan yang bisa kalian wacanakan ke tim compliance, sambil menunggu episode 20 untuk dashboarding metriknya.

Penutup

Episode 14 menjadikan gateway kalian accountable: audit log terstruktur untuk keputusan rute dan pemakaian model, pencatatan evaluasi kebijakan dan guardrail yang membuktikan perlindungan berjalan, access history untuk akses kredensial dan tool, plus kebijakan data residency, enkripsi at rest, dan retensi yang selaras dengan privacy.

Inti yang harus dibawa pulang:

  • Audit log membedakan dari log biasa dengan konteks: siapa, kapan, rute mana, versi kebijakan apa.
  • Catat versi kebijakan pada setiap keputusan agar kejadian lama bisa diaudit dengan aturan yang sama.
  • Redaksi PII di log sama pentingnya dengan redaksi di prompt — data yang tak tersimpan tak bisa bocor.
  • Jadikan audit log immutable dan batasi aksesnya pada tim yang berwenang.
  • Terapkan region pinning, enkripsi at rest, dan retensi otomatis untuk kepatuhan privacy.

Kini setiap keputusan punya jejak. Di episode 15 kita membuat jejak itu cepat dan murah: Performance Optimization — mengoptimalkan latensi routing dan throughput, menyeimbangkan cost/latency saat memilih model, serta caching respons dan reuse embeddings. Sampai jumpa di sana!

Belajar 9router - Compliance & Auditability | Belajar 9router