Sistem berbeda. Tata kelolanya juga.
Ini bukan dokumen melawan AI. Ini dokumen melawan menyamakan perilaku sistem yang berbeda di bawah satu label.
Di tahun-tahun terakhir, “AI” menjadi label tunggal yang menutupi keragaman perilaku sistem. Saat semua disebut dengan kata yang sama, percakapan tentang keandalan, biaya, dan risiko kehilangan ketelitian.
Manifesto ini adalah cara berpikir untuk decision maker yang harus mengadopsi AI dengan kontrol penuh. Bukan brosur produk.
AI is not one thing.
Di dalam payung kata “AI” terdapat perilaku sistem yang berbeda. Ada yang menjalankan aturan secara persis (workflow, validator, rule engine). Ada yang menafsirkan konteks dari data (LLM, klasifikasi konten). Ada yang menjawab dengan merujuk dokumen sumber (RAG, knowledge grounding). Ada yang menjalankan rangkaian langkah adaptif (agent, multi-step orchestration). Dan ada manusia yang harus mengambil keputusan akhir di tempat yang berdampak. Masing-masing membawa karakteristik operasional dan permukaan risiko yang berbeda.
Saat satu kategori dipakai untuk semuanya, klasifikasi tidak hanya tidak akurat. Klasifikasi melemahkan tata kelola. Sistem aturan-pasti yang dilabel “AI” tidak diaudit dengan ketelitian yang sesuai. Model yang menafsirkan diperlakukan sebagai workflow dan tidak mendapat evaluasi yang sesuai dengan sifatnya.
Yang gagal bukan teknologinya. Yang gagal kerangka untuk menggambarkannya.
Yang melemahkan governance bukan teknologinya. Yang melemahkannya adalah menyebut semua satu kategori.
Behavior is the unit, not technology.
Daftar teknologi (LLM, rule engine, workflow, agent, retrieval system) sering dipakai sebagai kategori. Itu cara berpikir vendor. Cara berpikir arsitek dan operations leader: bagaimana sistem berperilaku di bawah beban, bukan bagaimana sistem dipasarkan.
Sistem yang menjalankan aturan
Aturan ditulis, sistem menjalankan. Hasil yang sama untuk input yang sama. Tidak ada interpretasi.
Cocok ketika ketepatan lebih penting dari fleksibilitas. Gagal saat aturan-nya yang keliru ditulis, atau saat ada kasus yang tidak terpikirkan.
Validasi PPN, posting ke ERP, batch reconciliation, scheduled job, tax calculation.
- Workflow engine
- Rule engine
- Validator dokumen
- Pipeline kalkulasi
Sistem yang menafsirkan
Sistem mengenali pola dari data. Hasilnya tidak selalu identik untuk input yang sama, karena ada elemen interpretasi.
Cocok ketika konteks input bervariasi dan manusia bersedia me-review output. Gagal saat output diasumsikan eksak atau tidak dimonitor kualitasnya.
Ringkasan rapat, klasifikasi dokumen, ekstraksi data dari teks bebas, sentiment customer feedback.
- LLM
- Classifier ML
- Generasi konten
- Sentiment scoring
Sistem yang menjawab dengan rujukan
Setiap jawaban di-link ke dokumen sumber. Sistem mencari dulu di basis pengetahuan, kemudian merangkai jawaban dari sumber yang dikutip.
Cocok ketika sumber kebenaran ada di basis pengetahuan internal dan jawaban harus dapat ditelusuri. Gagal saat sumber tidak terkurasi atau usang.
Policy lookup di legal, customer support knowledge base, compliance regulasi, internal helpdesk.
- RAG
- Vector search
- Knowledge grounding
- Citation-aware QA
Sistem yang menjalankan rangkaian langkah
Sistem merencanakan langkah, memilih tool yang dipakai di tiap langkah, dan beradaptasi tergantung hasil. Bisa keluar dari skrip.
Cocok untuk workflow yang langkah-langkahnya tergantung kondisi yang muncul di runtime. Gagal saat tidak ada batas atau guardrail yang menjaga keluar dari koridor.
Multi-step research, customer onboarding adaptif, incident remediation, complex tier-2 support.
- Multi-step agent
- Function calling chain
- Workflow adaptif
Empat ini bukan eksklusif. Sistem enterprise nyata memadukan semuanya, dengan manusia sebagai lapisan kelima yang muncul di pengecualian dan keputusan berdampak tinggi (kredit, klinis, finansial, hukum).
Operational diagnostics.
Pertanyaan vendor adalah “AI apa yang dipakai”. Pertanyaan arsitek dan operations lead adalah “perilaku apa yang dibutuhkan beban kerja ini”. Enam pertanyaan diagnostik menggantikan satu perdebatan kategori.
Enam pertanyaan operasional menentukan arsitektur, jauh sebelum perdebatan tentang vendor dan model dimulai.
Hybrid is not compromise. Hybrid is architecture.
Sistem enterprise tidak monolitik. Mereka hybrid by design. Bukan kompromi antara opsi, melainkan kondisi arsitektural yang sesuai dengan keragaman beban kerja.
Mayoritas kegagalan operasional di lingkungan enterprise tidak berasal dari teknologi yang dipilih. Kegagalan berasal dari memaksa satu perilaku ke dalam konteks yang menuntut perilaku lain. LLM untuk validasi PPN. Rule engine untuk normalisasi nama vendor. Agent untuk approval kredit tanpa review manusia.
Ambil contoh pemrosesan invoice di finance. Validasi format dan perhitungan PPN adalah pekerjaan untuk sistem aturan-pasti. Normalisasi nama vendor yang ditulis berbeda di tiap invoice adalah pekerjaan untuk sistem yang menafsirkan. Pencocokan dengan kebijakan procurement yang tersebar di banyak dokumen adalah pekerjaan untuk sistem yang menjawab dengan rujukan. Eskalasi pengecualian ke approver dan tim audit adalah pekerjaan manusia.
Empat perilaku, satu workflow. Tugas arsitek bukan memilih satu perilaku unggul. Tugasnya menentukan batas di antara perilaku, dan menyusun orkestrasi yang menghubungkannya.
Governance follows behavior.
Tata kelola tanpa pembedaan perilaku sistem menjadi teater tata kelola.
Bayangkan auditor datang dan minta laporan tentang setiap kali AI dipakai dalam enam bulan terakhir. Untuk sistem aturan-pasti, jawabannya gampang: replay log, hasil identik. Untuk sistem yang menafsirkan, jawabannya lebih dalam: log alasan, versi model yang dipakai saat itu, dan contoh output. Dua kebutuhan governance yang berbeda dari satu permintaan yang sama.
Risiko operasional tidak seragam. Sistem yang menjalankan aturan dan sistem yang menafsirkan membawa permukaan risiko, metode pemantauan, dan kebutuhan oversight yang berbeda. Memberlakukan kontrol identik pada keduanya tidak membuat lingkungan lebih aman. Hanya membuat dokumen kepatuhan lebih panjang.
Lihat status di tiap langkah. Log dapat dibaca apa adanya.
Pantau kualitas output dari waktu ke waktu. Periksa contoh berkala untuk deteksi penyimpangan.
Replay byte demi byte. Bukti hitam-putih.
Catat alasan, konteks input, versi model dan provider. Simpan contoh untuk re-evaluasi.
Aturan yang salah ditulis, atau kasus yang tidak terpikir.
Output ngarang, terpengaruh data baru, atau perintah yang sengaja disusupkan.
Daftar test case yang menutupi setiap cabang.
Evaluasi statistik berkala, simulasi serangan, regresi terjadwal.
Tangani pengecualian di batas aturan.
Review contoh berkala. Eskalasi keputusan klinis, finansial, atau hukum.
Validasi syarat sebelum sistem berjalan.
Saring input sebelum sampai ke AI. Saring output sebelum sampai ke user.
Monago menyediakan governance layer yang sesuai dengan perilaku, bukan satu set kontrol seragam yang menyamarkan perbedaan operasional.
What we will not do.
Kami tidak akan menyatukan perilaku sistem yang berbeda di bawah satu kategori “AI” untuk memudahkan procurement.
Kami tidak akan menerapkan kontrol tata kelola yang seragam pada sistem dengan permukaan risiko yang berbeda.
Kami tidak akan menyembunyikan provider, versi, atau lineage arsitektural dari pihak yang harus mengauditnya.
Kami tidak akan mengoptimalkan demo dengan mengorbankan jejak operasional yang dapat diandalkan.
Infrastruktur untuk sistem yang sebenarnya.
Sistem perusahaan tidak monolitik. Kami merancang governance yang mengikuti perilakunya.
Sistem aturan-pasti di mana ketepatan dibutuhkan. Sistem yang menafsirkan di mana konteks ambigu. Sistem yang menjawab dengan rujukan di mana sumber penting. Sistem yang menjalankan rangkaian langkah di mana keputusan tergantung situasi. Manusia di mana akuntabilitas absolut.
Governance yang dibangun di atas pembedaan ini bertahan saat diaudit, saat regulasi berubah, dan saat arsitektur berkembang.