Sebagian besar hambatan implementasi AI di perusahaan bukan masalah kemampuan model. Masalahnya ada pada urutan pengambilan keputusan. Panduan ini menjelaskan urutan yang dipakai perusahaan untuk menentukan batas antara frontier AI, enterprise cloud, private environment, dan on-prem, berdasarkan klasifikasi data, profil risiko, use case, dan kewajiban regulasi.
Prinsip utama: model mengikuti klasifikasi data. Bukan data yang dipaksa mengikuti model.
Lima pola yang membuat proyek AI korporat berhenti di pilot
- Mulai dari memilih model. Diskusi dibuka dengan perbandingan vendor, sebelum ada yang tahu data apa yang akan masuk ke sistem.
- Satu solusi untuk semua data. Satu langganan enterprise dianggap cukup untuk seluruh kelas data, dari brosur publik sampai kontrak.
- Melarang tanpa menyediakan. Akses AI diblokir di jaringan kantor, pemakaian berpindah ke perangkat pribadi dan tidak lagi terlihat.
- Menganggap on-prem otomatis aman. Model berjalan di server sendiri, sementara tools, connector, dan logging tetap membuka jalur keluar data.
- Pilot tanpa kriteria produksi. Pilot berjalan mulus, lalu berhenti karena tidak pernah ada definisi lulus dari sisi security, kualitas, dan nilai bisnis. Koreksinya satu: tetapkan batas data lebih dulu, lalu pilih model yang boleh berada di dalam batas itu.
Urutan keputusan yang benar
Pemilihan model adalah hasil akhir dari proses risk-based architecture, bukan langkah pertama.
| Langkah | Pertanyaan yang dijawab | Pemilik jawaban |
|---|---|---|
| 1. Data | Data apa yang masuk, dari mana, siapa pemiliknya | Data owner unit |
| 2. Classification | Seberapa sensitif data itu menurut kebijakan perusahaan | Data owner dan security |
| 3. Risk | Apa konsekuensi bila data bocor atau jawaban salah | CISO dan risk |
| 4. Use case | Pekerjaan apa yang dibantu dan berapa nilainya | Business owner |
| 5. Architecture | Batas dan kontrol apa yang dibutuhkan | Arsitek dan security |
| 6. Model | Model dan environment mana yang memenuhi batas itu | CIO dan procurement |
Kesalahan yang paling mahal adalah membeli lisensi untuk seluruh karyawan sebelum klasifikasi data selesai. Biaya yang muncul kemudian bukan hanya biaya lisensi, melainkan biaya menata ulang proses yang terlanjur berjalan di atas asumsi yang salah.
Klasifikasi data menentukan batas AI
Skema berikut adalah reference scheme, bukan klasifikasi hukum universal. Selaraskan penamaannya dengan kebijakan keamanan informasi yang sudah berlaku di perusahaan.
| Kelas | Contoh isi | Pola arsitektur default |
|---|---|---|
| Public | Website, brosur publik, regulasi yang sudah terbit | Frontier atau enterprise AI yang sudah disetujui |
| Internal | SOP umum, manual kerja, materi pelatihan | Enterprise-controlled AI environment |
| Confidential | Kontrak, data keuangan, data pelanggan | Private atau tightly controlled environment |
| Restricted | Workload sangat sensitif atau diatur regulator | On-prem atau isolated bila terjustifikasi |
Klasifikasi bukan deployment rule otomatis. Rute akhir tetap memerlukan review legal dan compliance, security architecture review, pengecekan kewajiban kontraktual, serta persyaratan khusus sektor.
Kasus batas yang selalu muncul: dokumen campuran. Satu proposal dapat berisi profil perusahaan yang publik sekaligus struktur harga yang rahasia. Aturan praktis: kelas dokumen mengikuti bagian paling sensitif di dalamnya, kecuali dokumen dipecah lebih dulu.
Corporate AI sebagai sistem kontrol
Bukan satu chatbot, dan bukan satu model untuk semua jenis data. Enam lapisan berikut selalu ada. Yang berbeda hanya seberapa banyak lapisan dikelola sendiri dan seberapa banyak diserahkan ke penyedia.
- Pengguna dan aplikasi. Karyawan, aplikasi internal, automated workflow, dan service account.
- Identity dan access. SSO, MFA, RBAC, dan identitas layanan yang terpisah.
- AI gateway. DLP, deteksi PII, policy enforcement, audit log, rate limit, dan routing.
- Model environment. Frontier, enterprise, private, atau local.
- Knowledge layer. Retrieval, authorization-aware search, grounding, dan rujukan sumber.
- Sumber data. Dokumen, basis data, dan aplikasi bisnis.
Layer 1: AI tidak boleh punya privilege lebih
Akses model dan akses knowledge mengikuti identity, role, dan authorization boundary yang sama atau lebih ketat dibanding sistem sumbernya.
- Autentikasi setiap pengguna dan aplikasi, termasuk service account.
- Terapkan least privilege pada akses model maupun akses knowledge base.
- Pertahankan permission sistem sumber sehingga AI tidak membuka data yang tertutup di aplikasi aslinya.
- Pisahkan identitas admin, pengguna, dan layanan.
- Catat keputusan akses, bukan hanya hasil akhirnya.
Uji cepat: ambil satu dokumen yang hanya boleh dibaca direksi, masukkan ke knowledge layer, lalu ajukan pertanyaan tentang isinya memakai akun staf biasa. Bila isinya muncul, desain otorisasi belum selesai.
Layer 2: kendalikan akses, jangan hanya memblokir
Gateway adalah titik kontrol tempat setiap request diperiksa, dicatat, lalu diarahkan ke environment yang sesuai kelas datanya. Pemblokiran total tanpa alternatif resmi mendorong pemakaian berpindah ke kanal yang tidak terlihat. Alur yang dijalankan gateway: verifikasi identitas dan role, deteksi data sensitif pada prompt, penerapan policy berupa allow, deny, atau redact, pencatatan keputusan, lalu routing ke environment tujuan. AI gateway di sini adalah pola arsitektur, bukan produk tertentu dan bukan standar wajib.
Layer 3: satu model tidak cocok untuk semua kelas data
| Kelas data | Deployment | Contoh use case |
|---|---|---|
| Public | Approved frontier atau enterprise SaaS | Riset pasar, penulisan materi publik |
| Internal | Enterprise AI dengan controlled RAG | Asisten SOP, tanya jawab internal |
| Confidential | Private endpoint atau private cloud | Analisis kontrak, review keuangan |
| Restricted | On-prem atau isolated bila terjustifikasi | Workload yang diatur regulator sektor |
Beberapa penyedia besar menyatakan bahwa untuk produk bisnis dan akses API mereka, input dan output pelanggan tidak dipakai melatih foundation model secara default. Pernyataan ini berbeda antar produk, paket, dan pengaturan akun, serta dapat berubah. Verifikasi ulang plan, region, retensi, fitur yang aktif, dan isi kontrak sebelum keputusan produksi, lalu catat tanggal verifikasinya.
RAG bukan training
RAG memberi model akses ke informasi relevan pada saat inference. Dokumen baru masuk ke knowledge layer, dan itu tidak sama dengan melatih ulang foundation model. Alurnya: pertanyaan pengguna, pengecekan identitas dan hak akses, pencarian dokumen relevan, penyusunan konteks, pembentukan jawaban, lalu jawaban beserta rujukan sumbernya. Konsekuensi praktisnya: ketika SOP berubah, yang diperbarui adalah sumber dan indeksnya, bukan modelnya. Kualitas jawaban menjadi urusan pemilik dokumen, bukan hanya urusan tim teknis. Dokumen usang menghasilkan jawaban usang.
Amankan seluruh pipeline, bukan hanya model
RAG menambah komponen baru yang juga membutuhkan otorisasi, isolasi, monitoring, dan pengujian tersendiri. Lima pertanyaan kontrol yang perlu dijawab:
- Source auth. Apakah pengguna memang berhak mengambil dokumen ini?
- Index access. Bisakah satu tim mengambil konten terbatas milik tim lain melalui indeks yang sama?
- Prompt injection. Bisakah isi dokumen yang diambil mengubah perilaku model atau memicu tools?
- Output control. Apakah jawaban berpotensi menampilkan informasi di luar hak akses peminta?
- Audit. Bisakah direkonstruksi siapa mengakses apa dan kapan?
Lokal tidak otomatis berarti aman
Model bisa berjalan di server sendiri, tetapi data tetap dapat keluar melalui jalur lain. Jalur keluar yang paling sering terlewat: API pihak ketiga, akses web atau browser, telemetry, central logging, connector dan plugin, serta cloud storage. Audit seluruh aliran data, bukan hanya lokasi model. Security boundary mencakup model, tools, credential, jalur jaringan, connector, log, dan titik persetujuan manusia.
Dari menjawab menjadi bertindak
Semakin besar kemampuan agent mengakses tools dan melakukan aksi, semakin ketat kontrol yang dibutuhkan. Tingkatannya: read untuk mencari dan meringkas, write untuk menyusun draf dan memperbarui record, send untuk mengirim email dan publikasi, lalu execute untuk menjalankan kode dan memicu workflow. Control set untuk agent berotonomi tinggi: least privilege dan credential bercakupan sempit, batas transaksi dan batas nilai, allowlist dan denylist tools, sandbox untuk eksekusi berisiko, persetujuan manusia untuk aksi kritis, serta audit log rinci dan prosedur insiden.
AI governance bukan tugas tim IT saja
Corporate AI membutuhkan decision rights lintas fungsi: CIO atau CTO untuk teknologi dan platform, CISO untuk keamanan dan pelindungan data, legal dan compliance untuk kesesuaian regulasi, tim data dan AI untuk implementasi, business owner untuk nilai dan akuntabilitas, serta risk dan audit untuk tinjauan independen. Governance harus menjawab empat pertanyaan: layanan AI mana yang berstatus disetujui, data dan use case apa yang dilarang atau dibatasi, siapa pemilik risiko model dan risiko penyedia, serta bagaimana insiden, perubahan, dan penilaian berkala ditangani. NIST AI RMF memakai fungsi Govern, Map, Measure, dan Manage. ISO/IEC 42001 mendefinisikan sistem manajemen AI yang dapat disertifikasi.
Konteks Indonesia
UU PDP mengatur transfer Data Pribadi ke luar wilayah Indonesia dengan persyaratan tertentu. Ini berbeda dengan klaim data-localization menyeluruh yang sering beredar di ruang rapat. Urutan pada Pasal 56 secara ringkas:
- Transfer diperbolehkan sepanjang memenuhi ketentuan undang-undang.
- Pastikan negara tujuan memiliki tingkat pelindungan yang setara atau lebih tinggi.
- Bila tidak terpenuhi, harus ada pelindungan yang memadai dan mengikat.
- Bila kedua hal di atas tidak terpenuhi, diperlukan persetujuan subjek data. Untuk sektor yang diatur, tambahkan tinjauan sektoral di atas kewajiban umum UU PDP. Sebagai contoh, OJK menerbitkan Tata Kelola Kecerdasan Artifisial Perbankan Indonesia pada 29 April 2025 sebagai acuan minimal pengembangan dan penerapan AI yang bertanggung jawab di perbankan. Bank Indonesia juga menekankan governance, oversight, dan mitigasi risiko dalam adopsi AI. Yang perlu dicatat tim: region pemrosesan yang ditawarkan penyedia, lokasi penyimpanan log dan telemetry, serta ada atau tidaknya subprosesor di yurisdiksi lain. Tiga hal ini yang paling sering luput ketika perusahaan hanya memeriksa lokasi server model. Interpretasi hukum final tetap ditinjau legal dan compliance perusahaan.
Shadow AI: kumpulkan fakta sebelum menyimpulkan
Bila karyawan sudah memakai layanan AI eksternal, perlakukan sebagai discovery dan penilaian insiden. Enam fakta yang dikumpulkan lebih dulu: siapa penggunanya, layanan apa yang dipakai (consumer, enterprise, atau API), jenis data apa yang dimasukkan, periode dan frekuensinya, pengaturan training dan retensi pada akun tersebut, serta terms dan status perjanjian pemrosesan data. Bedakan empat status data yang sering dicampur: processed (diproses untuk menjalankan layanan), stored (disimpan penyedia), retained (ditahan untuk periode tertentu), dan used for training (dipakai melatih model). Status terakhir adalah yang paling sering diasumsikan tanpa bukti.
Jalan dari discovery ke produksi
Program yang berhasil hampir selalu berjalan dalam tiga fase selama sembilan puluh hari. Discover untuk memetakan pemakaian dan data, Pilot untuk menguji satu use case berisiko rendah sampai sedang, lalu Control dan Scale untuk memutuskan kelayakan produksi. Enam output yang diharapkan pada hari ke-90:
- AI inventory
- Matriks klasifikasi data
- Use case register dengan prioritas yang disepakati
- Satu arsitektur pilot yang berjalan dengan kontrol terpasang
- Risk and control register
- Keputusan produksi yang tertulis beserta alasannya Jangan membuka program dengan autonomous agent atau rencana melatih foundation model dari nol.
Kelayakan produksi dinilai sebagai sistem bisnis
Pilot yang berhasil belum tentu layak produksi. Penilaiannya mencakup keamanan, kualitas jawaban, risiko, operasi, dan nilai yang terukur. Pilot tanpa kriteria kelulusan yang ditulis sebelum pilot dimulai akan selalu terasa berhasil. Urutan yang dipegang sepanjang program tetap sama: data, classification, risk, use case, architecture, model.
Langkah berikutnya
Dokumen ini adalah kerangka keputusannya. Eksekusi langkah demi langkahnya ada di Corporate AI Enablement Handbook, yang memuat prosedur per fase, worksheet klasifikasi data, matriks seleksi use case, rubrik evaluasi kualitas beserta ambang kelulusannya, use case korporat Indonesia per sektor, risk register, dan lembar sign-off produksi. Handbook tersebut dipakai sebagai materi pada program pelatihan dan pendampingan AI korporat kayadigital.ai, yang tersedia dalam bentuk kelas satu hari untuk tim internal maupun pendampingan program 90 hari. Untuk membahas kebutuhan perusahaan Anda, hubungi melalui Instagram @kayadigital.ai atau portal kayadigital.site. - DM untuk Inquiry, Konsultasi dan pertanyaan lebih lanjut.
Kami juga menyediakan Training Coaching Workshop untuk Fundamental AI
Rujukan primer
Diperiksa pada 12 September 2026. Kebijakan penyedia dan ketentuan regulasi dapat berubah, sehingga verifikasi ulang diperlukan sebelum keputusan produksi.
- UU 27/2022 tentang Pelindungan Data Pribadi, Pasal 56
- OJK, Tata Kelola Kecerdasan Artifisial Perbankan Indonesia (29 April 2025)
- Bank Indonesia, penguatan tata kelola adopsi AI bank sentral (24 Juli 2026)
- NIST, AI Risk Management Framework Core
- ISO/IEC 42001:2023, AI management systems
- OpenAI, business data privacy dan enterprise privacy
- Anthropic, kebijakan penggunaan data pada produk komersial
- Microsoft, data, privacy, dan security untuk Foundry Models yang dijual Azure
- Google Cloud, data governance dan generative AI
- Google Cloud, generative AI with RAG reference architectures Playbook ini adalah reference architecture dan materi edukasi, bukan legal opinion maupun persetujuan kepatuhan sektoral. Implementasi final tetap melalui security architecture review, tinjauan privasi dan hukum, uji tuntas penyedia, serta regulasi sektor yang berlaku.