Sandbox Gov3.id
Arsitektur teknis platform — yang sudah berjalan, dan yang masih rancangan
Halaman ini berisi spesifikasi teknis sandbox. Untuk konsep besar Gov3 — kenapa portal ini ada, siapa yang pakai — lihat Gov3; cara bergabung ada di halaman depan.
Diperbarui Oktober 2026.
Apa yang Diuji di Sini
Berbeda dari regulatory sandbox konvensional yang hanya menguji aplikasi dalam environment terisolasi, Gov3.id menguji keseluruhan ekosistem tata kelola:
- Regulasi (apa yang perlu Permen/Perpres, apa yang bisa SK)
- Struktur organisasi (siapa pegang criteria catalog, siapa approval gate)
- Model interoperabilitas (MCP federation, identitas tunggal Beo, penyimpanan dokumen Kambing)
- Pola penganggaran (PNBP, hibah, cost-sharing antar-instansi)
- Mekanisme mediasi human-AI (approval gate, override registry, confidence threshold)
- Cara kerja agen AI di birokrasi — agen mengerjakan tiket, manusia menyetujui
Yang diuji adalah arsitektur, bukan teknologi tunggal.
Yang Sudah Berjalan
| 633 portal instansi | Setiap pemerintah daerah dan K/L punya [instansi].gov3.id — satu basis kode, satu database pusat + database per portal |
| Identitas tunggal | Satu akun SSO Beo (Google atau email resmi) untuk semua portal dan layanan |
| Onboarding mandiri | Pejabat mendaftar sendiri; nama dicocokkan otomatis dengan situs resmi {slug}.go.id — lihat halaman depan |
| Agen AI per server | Setiap server platform punya agen AI yang menerima pekerjaan lewat tiket dan saling berkoordinasi |
| Layanan pertama: SAKIP AI | Pemeriksaan kelengkapan dokumen dan evaluasi SAKIP berbantuan AI bersama KemenPAN-RB — sakip.ai.id |
Prinsip Desain
- Paralel, bukan pengganti — berjalan bersamaan dengan
*.go.idexisting - Open onboarding — tanpa seleksi, tanpa surat; pendaftaran mandiri dengan akun SSO Beo
- Domain instansi sebagai unit utama — bukan domain aplikasi
- Convention over configuration — kapabilitas otomatis tersedia saat portal instansi aktif
- AI-native — layanan dapat diorkestrasi AI via MCP
- Human authority at the apex — semua output AI rekomendatif; otoritas final di pejabat berwenang
- Sandbox mencakup governance — bukan hanya teknologi
- Graduasi bertahap — tidak all-or-nothing
Struktur Domain
| Alamat | Fungsi | Status |
|---|---|---|
[instansi].gov3.id |
Portal utama instansi (mis. kemenpanrb.gov3.id, kukarkab.gov3.id) |
aktif — 633 portal |
kancil.[instansi].gov3.id |
Kancil — agen AI di portal instansi: pemandu pengguna dan asisten pengembangan aplikasi | pilot — kancil.kukarkab.gov3.id |
beo.gov3.id |
SSO — identitas tunggal untuk semua portal | aktif |
gajah.gov3.id |
Database platform (Supabase): data bersama, autentikasi, basis pengetahuan AI | aktif |
gurita.gov3.id |
Gerbang MCP + orkestrasi alur kerja: tiap layanan di gurita.gov3.id/mcp/{layanan} |
aktif |
kambing.gov3.id |
Penyimpanan dokumen federasi (WebDAV), folder per instansi | aktif |
lebah.gov3.id |
Tiket, wiki, dan repositori kode — jalur kerja manusia dan agen | aktif |
Rancangan yang belum dibangun
Arsitektur Gov3 v2 merancang protocol prefix per instansi — mcp., dav., auth., sql., kms., pnbp.[instansi].gov3.id. Prefix ini belum diterapkan: saat ini layanan disediakan terpusat (tabel di atas) dan dibedakan per instansi lewat akun, folder, dan slug instansi. Prefix akan dipasang ketika sebuah instansi butuh endpoint sendiri, misalnya menjelang graduasi.
Gov3.id sebagai Bridging TLD
Arsitektur Gov3 v2 menetapkan TLD sebagai role convention untuk production:
| Sandbox (Gov3.id) | Production | TLD Role |
|---|---|---|
kukarkab.gov3.id |
kukarkab.go.id |
Pemerintah |
cybergl.gov3.id |
cybergl.co.id |
Vendor/Swasta |
csgar.gov3.id |
csgar.ui.ac.id |
Akademik |
icw.gov3.id |
icw.or.id |
CSO/Organisasi |
Selama di sandbox, role ditandai via metadata onboarding. Saat graduasi, TLD asli instansi mengambil alih — tanpa perubahan arsitektur, hanya perpindahan domain.
Contoh nyata: di Pesut, model AI sudah dinamai dengan konvensi ini menurut pemiliknya — pesut.menpan.go.id (asisten evaluasi SAKIP, model dasar milik KemenPAN-RB) dan pesut.csgar.ui.ac.id (asisten belajar SAKIP, berjalan di server Lab UI).
Komponen Platform
Dibangun di atas komponen open-source teruji, dinamai dengan fauna Indonesia:
| Komponen | Nama | Basis Teknologi | Fungsi |
|---|---|---|---|
| Kerangka portal | phpVB | PHP 8.4 + Vue 3 + Bootstrap 5 | 633 portal dari satu basis kode — lihat phpVB |
| Identitas | Beo | SSO phpVB + Supabase Auth | Satu akun (Google atau email resmi) untuk semua layanan |
| Database | Gajah | Supabase (PostgreSQL) | Data bersama, autentikasi, basis pengetahuan AI |
| Gerbang MCP | Gurita | MCP + n8n | Registry layanan MCP, orkestrasi alur kerja antar-agen |
| Penyimpanan | Kambing | Nextcloud / WebDAV | Dokumen per instansi, berversi, dapat dibagikan |
| Pengetahuan & kerja | Lebah | Redmine + Git | Tiket, wiki, repositori — Policy Decision Records dan jejak kerja agen |
| Asisten percakapan | Kakatua | Open WebUI | Ruang percakapan dengan model AI dan alat MCP (mis. asisten evaluasi SAKIP) |
| Gerbang model AI | Pesut | LiteLLM + hub MCP | Satu pintu ke model AI dan server MCP, dipakai Kakatua dan Kancil |
| Agen portal | Kancil | Agen koding + MCP | Pemandu portal, asisten pengembangan aplikasi dari spesifikasi tiket |
| Komunikasi | Merpati | Kanal percakapan | Dukungan teknis dan notifikasi |
Kakatua dan Kancil dapat dibuka langsung dari panel samping portal, dengan akun Beo yang sama.
Belum dibangun: metering & PNBP (Semut) dan layanan geospasial (Penyu) dari rancangan awal.
Agen AI: Tiket sebagai Jalur Kerja
Setiap server platform dijaga satu agen AI (Agen Ayam, Kelinci, Lebah, Gurita, Gajah, Pesut, …). Cara kerjanya meniru birokrasi yang tertib:
- Pekerjaan masuk sebagai tiket di Lebah — berisi tujuan, batasan, dan uji terima
- Agen mengerjakan di servernya sendiri dan melaporkan hasil (commit, bukti uji) di journal tiket
- Agen saling berkoordinasi lewat kanal antar-agen melalui Gurita
- Manusia memutuskan — perubahan produksi (deploy, data) dilakukan atau disetujui admin, bukan agen
Izin alat setiap agen tertutup secara bawaan dan dibuka hanya sesuai tugasnya; agen yang menyentuh produksi bekerja dalam mode baca. Hasilnya, setiap langkah AI punya jejak: tiket, commit, dan journal — inilah traceable reasoning dalam praktik.
Aplikasi baru pun dibangun dengan pola yang sama (spesifikasi berbasis tiket): spesifikasi ditulis di tiket, Kancil membangun MVC phpVB dari spesifikasi itu, dan setiap modul menerbitkan dokumennya sendiri (/{app}/{mvc}/artefak) — readme, kontrak API, catatan rilis, dan salinan spesifikasinya.
Lifecycle: Open Entry, Gradual Graduation
| Tahap | Status | Output |
|---|---|---|
| 1. Onboarding | Portal aktif | Pendaftaran mandiri via SSO Beo; akses ke komponen platform |
| 2. Eksperimen | Pure sandbox | Output eksperimental, no implikasi hukum |
| 3. Shadow Integration | Hybrid informal | Output sandbox = referensi informal di proses resmi |
| 4. Adopsi Parsial | Hybrid formal | SK/nota dinas mengakui output sandbox sebagai input resmi |
| 5. Graduasi Platform | Production penuh | Migrasi ke TLD asli instansi (.go.id dsb) |
Sandbox tidak mati setelah graduasi — yang di-graduate adalah hasilnya, bukan sandbox-nya. Ruang eksperimen tetap hidup untuk inovasi berkelanjutan.
Perjalanan diukur via Gov 3 Maturity Index (Gov 3.1 – Gov 3.9). Detail di dokumen Maturity Index.
Orchestrated Intelligence di Sandbox
Empat pilar dan cara sandbox mengoperasionalkannya saat ini:
- Mediation Protocol — tiket sebagai approval gate: agen mengusulkan, manusia menyetujui; zona tinjauan onboarding diputuskan webmaster instansi
- Criteria Catalog — kriteria evaluasi SAKIP sebagai layanan MCP bersama, dipakai asisten AI dan asesor manusia dengan definisi yang sama
- Institutional Memory — wiki dan tiket Lebah menyimpan keputusan beserta alasannya, lintas siklus dan pergantian tim
- Traceable Reasoning — setiap pekerjaan agen meninggalkan jejak: tiket → commit → journal → bukti uji
Guardrails
Sandbox bukan tanpa aturan. Batas yang tidak boleh dilanggar:
- Tidak boleh mengurangi hak akses layanan publik
- Standar keamanan informasi tidak boleh di bawah baseline SPBE
- Harus ada rollback plan — eksperimen yang gagal dapat dikembalikan
- Data tetap comply dengan UU Perlindungan Data Pribadi
- Transparansi penuh — semua keputusan governance terdokumentasi
- Pada tahap shadow integration ke atas, output sandbox wajib diberi label untuk membedakan dari output resmi
- Human authority — semua output AI rekomendatif; keputusan final di pejabat berwenang
AI Safeguards Framework
- Least privilege — izin alat agen tertutup secara bawaan; dibuka per tugas, dan perubahan produksi tetap di tangan admin
- Purpose limitation — AI hanya mengakses data sesuai cakupan akun Beo dan peran pengguna di portal
- Non-discrimination check — workflow template memvalidasi output AI terhadap indikator fairness
- AI block classification — output yang menyentuh domain sensitif (keamanan nasional, data personal) otomatis di-block atau di-eskalasi dengan threshold lebih ketat
Teknologi Kerangka
Sandbox dijalankan di atas phpVB — framework PHP + Vue + Bootstrap yang melayani 633 portal dari satu basis kode: setiap subdomain instansi otomatis ter-routing ke konfigurasi dan database-nya sendiri, dan setiap aplikasi siap dibaca serta dijalankan oleh agen AI.
Kontak Teknis
Lab e-Gov & e-Bus Universitas Indonesia · Cyber Gov Labs
Wibisono Sastrodiwiryo — wibi@alumni.ui.ac.id
Untuk pertanyaan teknis platform: setelah onboarding, liaison teknis instansi dapat membuka tiket di Lebah.