Dari Pilot ke Produksi: Tujuh Titik Serah Terima yang Sering Bocor

Proyek AI enterprise sering tersendat bukan karena modelnya, melainkan karena serah terima saat pilot masuk ke produksi. Di tahap pilot, satu tim kecil memegang semuanya. Setelah go-live, tanggung jawab terbagi antara klien, system integrator (SI), dan penyedia infrastruktur, dan pembagian itu jarang dituliskan.

Tulisan ini untuk SI, software house, dan perusahaan solusi AI yang membawa proyek klien dari pilot ke go-live. Fokusnya fase setelah kontrak ditandatangani: apa yang perlu diserahkan, siapa yang memegangnya, dan bukti apa yang harus tersedia sebelum klien menyatakan sistem siap.

Mengapa proyek AI yang berhasil di pilot sering tersendat saat masuk produksi?

Pilot hanya membuktikan bahwa model dapat menjawab. Produksi menuntut lebih banyak: sistem harus tahan terhadap peak load, log harus tersimpan di lokasi yang jelas, setiap insiden harus punya penanggung jawab, dan klien harus dapat mengaudit. Di pilot, semua itu biasanya ditangani satu engineer SI. Setelah go-live, tidak ada yang memegangnya secara tertulis.

Pola berikut sering terlihat di proyek AI enterprise:

• Sizing GPU diambil dari pilot yang hanya melibatkan beberapa pengguna, lalu dipakai apa adanya untuk volume transaksi produksi.
• Staging dan production berjalan di environment yang sama, sehingga satu deploy percobaan dapat mengganggu layanan klien.
• Alert monitoring masuk ke email engineer yang sudah berpindah proyek.
• Snapshot berjalan, tetapi restore belum pernah diuji.
• Tidak ada yang tahu siapa yang harus memberi tahu klien jika terjadi kebocoran data di lapisan infrastruktur.

Kelimanya bukan masalah teknologi, melainkan masalah serah terima.

Titik serah terima mana yang paling sering bocor?

Ada tujuh titik yang paling rawan antara pilot dan produksi: sizing, pemisahan environment, akses, monitoring, backup dan restore, versi model, serta jalur insiden. Masing-masing memerlukan satu penanggung jawab dan satu bukti tertulis yang diserahkan sebelum go-live, bukan sesudahnya.

Titik serah terima	Yang sering terjadi	Penanggung jawab utama	Bukti yang diserahkan sebelum go-live
Sizing produksi	Sizing pilot dipakai untuk produksi tanpa diuji ulang	SI, dengan rekomendasi penyedia infrastruktur	Hasil uji beban di staging dan rencana scale up
Pemisahan staging dan production	Satu environment untuk semua kebutuhan, sehingga deploy percobaan mengganggu layanan	SI	Diagram environment dan aturan promosi dari staging ke production
Akses dan kredensial	Akun pilot pribadi masih aktif, API key dibagikan lewat aplikasi chat	SI dan klien	Daftar akses per peran, rotasi API key, akun pilot dinonaktifkan
Monitoring dan alert	Alert hanya masuk ke satu orang dan tidak ada jadwal jaga	SI untuk aplikasi, penyedia infrastruktur untuk lapisan GPU dan jaringan	Matriks alert: sinyal apa, ke siapa, dan batas waktu respons
Backup, snapshot, dan restore	Snapshot berjalan, tetapi restore belum pernah dicoba	Penyedia infrastruktur untuk mekanisme, SI untuk data aplikasi	Catatan uji restore beserta tanggal dan hasilnya
Versi model dan rollback	Model diganti tanpa catatan, output mulai bergeser (drift), dan versi lama tidak dapat dipulihkan	SI	Registri versi model dan prosedur rollback
Jalur insiden	Tidak jelas siapa menghubungi siapa, sehingga laporan ke klien terlambat	Klien sebagai pengendali, SI sebagai prosesor, penyedia infrastruktur sebagai sub-prosesor	Runbook incident response berisi nama, kanal, dan batas waktu per pihak

Apa yang berubah pada kewajiban data saat pilot masuk produksi?

Selama pilot memakai data dummy, kewajiban UU PDP terasa jauh. Begitu produksi memproses data pribadi nasabah atau pelanggan, rantai pengendali, prosesor, dan sub-prosesor berlaku penuh. PP 33/2026 diundangkan pada 16 Juli 2026 dan berlaku mulai 16 Januari 2027, sehingga proyek yang go-live saat ini akan beroperasi di bawah aturan tersebut.

Tiga hal perlu masuk ke dokumen serah terima:

1. Sub-prosesor tertulis. Menurut ringkasan RSM Indonesia atas PP 33/2026, prosesor wajib memiliki perjanjian tertulis dengan pengendali (Pasal 14), dan penunjukan sub-prosesor memerlukan persetujuan tertulis dari pengendali terlebih dahulu (Pasal 15). Jika infrastruktur GPU milik penyedia memproses data pribadi klien, penyedia tersebut perlu tercatat sebagai sub-prosesor sebelum go-live.
2. Laporan insiden ke hulu. Pasal 46 UU No. 27/2022 mewajibkan pengendali memberi tahu subjek data dan lembaga secara tertulis paling lambat 3 x 24 jam setelah terjadi kegagalan pelindungan data pribadi. Prosesor juga wajib melapor ke pengendali pada kesempatan pertama. Karena itu, batas waktu pelaporan antara penyedia infrastruktur, SI, dan klien harus lebih pendek dari 3 x 24 jam dan ditulis di runbook.
3. Lokasi log dan backup. Klien akan menanyakan di mana log disimpan, berapa lama, dan siapa yang dapat membacanya. Jawabannya harus sudah ada sebelum go-live, bukan baru dicari saat audit.

Untuk klien bank, ketentuan OJK ikut berlaku. PADK OJK No. 1 Tahun 2026 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum, yang berlaku sejak 1 Maret 2026, mengatur penggunaan penyedia jasa TI serta penempatan sistem elektronik di luar wilayah Indonesia. Pembahasan lengkapnya ada di artikel tata kelola AI perbankan OJK untuk vendor dan SI.

Bagaimana menyusun production readiness review bersama penyedia infrastruktur?

Production readiness review adalah satu sesi yang melibatkan klien, SI, dan penyedia infrastruktur untuk memeriksa daftar yang sama. Sesi ini umumnya disarankan sekitar dua minggu sebelum go-live. Setiap baris harus punya penanggung jawab dan bukti. Baris tanpa bukti berarti go-live ditunda, atau klien menandatangani penerimaan risikonya secara tertulis.

Checklist berikut dapat langsung dipakai SI:

1. Uji beban di staging dengan pola transaksi produksi, lalu sepakati rencana scale up jika peak load melampaui perkiraan.
2. Pisahkan staging dan production, termasuk API key dan akses GPU-nya.
3. Nonaktifkan akun dan API key dari masa pilot, lalu buat daftar akses per peran.
4. Susun matriks alert: sinyal yang dipantau (memory usage, error rate, antrean inference, output drift), penerimanya, dan batas waktu respons.
5. Uji restore dari snapshot, lalu catat tanggal dan hasilnya.
6. Catat versi model yang di-deploy dan siapkan prosedur rollback.
7. Tulis runbook incident response dengan nama PIC, kanal, dan batas waktu pelaporan per pihak.
8. Pastikan penyedia infrastruktur sudah tercatat sebagai sub-prosesor dan disetujui klien secara tertulis.
9. Dokumentasikan lokasi pemrosesan, lokasi log, dan masa simpan backup.
10. Sepakati first-line support: siapa yang menerima tiket pertama dari klien, dan kapan tiket dieskalasi ke penyedia infrastruktur.

Pembagian peran sebelum kickoff dibahas di Siapa Memegang Apa antara SI dan penyedia infrastruktur AI. Checklist di atas melanjutkan dari titik itu.

Siapa menghubungi siapa saat insiden terjadi di minggu pertama go-live?

Klien hampir selalu menghubungi SI lebih dulu, karena SI memegang hubungan dan aplikasinya. Karena itu SI memegang first-line support. Penyedia infrastruktur menangani lapisan GPU, jaringan, dan storage, lalu melapor ke SI beserta root cause dan langkah recovery. Klien sebagai pengendali tetap memegang keputusan pemberitahuan kepada subjek data dan lembaga.

Urutan yang sehat:

Langkah	Pihak	Yang dilakukan
1	Klien atau monitoring	Gangguan terdeteksi dan tiket masuk ke SI
2	SI	Triage: masalah ada di aplikasi, model, atau infrastruktur
3	Penyedia infrastruktur	Jika masalah di lapisan infrastruktur, menangani dan melapor ke SI sesuai batas waktu di runbook
4	SI	Merangkum dampak, root cause, dan status recovery untuk klien
5	Klien	Jika menyangkut data pribadi, memutuskan pemberitahuan sesuai Pasal 46 UU PDP

Jika urutan ini baru disusun saat insiden sudah terjadi, laporan ke klien hampir pasti terlambat.

Di mana IONext berperan

IONext berperan sebagai penyedia infrastruktur di bawah system integrator. IONext menyediakan GPU, managed inference melalui API yang kompatibel dengan OpenAI, dan hosting model open-weight, dengan pemrosesan dan penyimpanan di Jakarta. GPU yang tersedia adalah NVIDIA RTX PRO 6000 Blackwell Server Edition 96 GB dan NVIDIA L40S 48 GB, sebagaimana dijelaskan di halaman GPU IONext.

Untuk fase pilot ke produksi, IONext dapat menyerahkan:

• Sertifikat ISO/IEC 27001:2022 dari TÜV NORD (nomor 01 07 E 26000410) yang dapat dilampirkan SI pada dokumen sub-prosesor. Detailnya ada di halaman keamanan dan kepatuhan IONext.
• Project dan environment terpisah untuk staging dan production di ORBIT, serta snapshot dan restore dari workspace yang sama. IONA membaca sinyal dari workload yang berjalan dan menjelaskan artinya, sementara keputusan tetap di tangan tim. Cara kerjanya dibahas di sinyal production yang dibaca IONA.
• Penagihan dalam Rupiah melalui badan hukum Indonesia, PT Data Awan Nusantara.

Beberapa hal bukan bagian dari peran IONext: arsitektur aplikasi, pemilihan model, hubungan dengan klien, dan first-line support kepada klien. Semuanya tetap peran SI. IONext juga tidak menggantikan DPIA atau keputusan hukum klien sebagai pengendali data pribadi. Infrastruktur di dalam negeri menyederhanakan pertanyaan transfer data ke luar negeri, tetapi tidak otomatis membuat proyek patuh UU PDP.

Sedang menyiapkan go-live untuk klien di sektor yang diatur ketat? Susun production readiness review bersama IONext lewat Program Mitra, atau coba ORBIT dan IONA langsung melalui pendaftaran mandiri di console IONext.

Pertanyaan yang sering diajukan

Kapan production readiness review sebaiknya dilakukan? Sekitar dua minggu sebelum go-live. Waktu itu cukup untuk menjalankan uji restore, memperbaiki matriks alert, dan memperoleh persetujuan tertulis klien atas sub-prosesor. Jika dilakukan sehari sebelum go-live, temuan apa pun cenderung ditunda dan jarang dikerjakan.

Apakah hasil uji beban di pilot cukup untuk sizing produksi? Biasanya tidak. Pilot jarang meniru pola transaksi, panjang dokumen, atau jumlah pengguna produksi. Ulangi uji beban di staging dengan pola yang mendekati produksi, lalu sepakati rencana scale up dengan penyedia infrastruktur.

Apakah penyedia GPU perlu dicatat sebagai sub-prosesor? Jika infrastruktur penyedia memproses data pribadi klien atas nama SI, penyedia tersebut berperan sebagai sub-prosesor. Penunjukannya memerlukan persetujuan tertulis dari klien sebagai pengendali, dan sebaiknya sudah tercatat sebelum go-live.

Siapa yang bertanggung jawab jika insiden terjadi di lapisan GPU? Penyedia infrastruktur menangani dan melaporkan insiden di lapisannya kepada SI, lalu SI meneruskannya ke klien. Klien sebagai pengendali memutuskan pemberitahuan kepada subjek data dan lembaga, paling lambat 3 x 24 jam menurut Pasal 46 UU PDP. Batas waktu antarpihak harus tertulis di kontrak dan runbook.

Sumber

• UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi, Pasal 46
• PwC Indonesia, "Government Regulation 33/2026 on Personal Data Protection: key changes and action points", Oktober 2026
• RSM Indonesia, "PP 33/2026: Six Implementation Priorities before 16 January 2027", September 2026
• OJK, Abstrak PADK OJK No. 1 Tahun 2026 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum
• Siapa Memegang Apa: Pembagian Peran System Integrator dan Penyedia Infrastruktur AI di Proyek Klien
• PP 33/2026: Dampak untuk Proyek AI
• Setelah Go-Live: Sinyal Production yang Dibaca IONA dan Siapa yang Bertindak
• Keamanan dan Kepatuhan IONext

Tulisan ini berisi informasi umum, bukan nasihat hukum. Untuk kebutuhan kepatuhan, rujuklah naskah resmi peraturan dan konsultasikan dengan penasihat hukum.

IONext adalah infrastruktur AI berdaulat yang di-host di Indonesia, dioperasikan oleh PT Data Awan Nusantara di Jakarta. IONext menyediakan GPU as a Service, managed inference melalui API yang kompatibel dengan OpenAI, dan hosting model open-weight, bersertifikat ISO/IEC 27001:2022 oleh TÜV NORD.