Use Cases

    Pattern Card: Merangkum Laporan Kunjungan Toko dengan LLM, Data Tetap di Indonesia

    Pattern card untuk SI: merangkum catatan dan foto kunjungan toko tim sales lapangan dengan LLM open-weight di Jakarta, lengkap dengan keputusan dan checklist.

    Tim sales lapangan FMCG mengirim catatan dan foto kunjungan toko setiap hari, tetapi supervisor jarang sempat membaca semuanya. Pola ini memakai LLM open-weight yang berjalan di Jakarta untuk mengubah catatan dan foto itu menjadi ringkasan terstruktur, tanpa data toko dan data pemiliknya keluar Indonesia.

    Status: pola arsitektur yang dapat dibangun di IONext, bukan laporan proyek. System integrator dan software house boleh memakai kartu ini di pitch deck mereka.

    Masalah apa yang diselesaikan pola ini?

    Catatan kunjungan toko biasanya berupa teks bebas dan foto. Isinya penting: stok kosong, harga di rak, aktivitas kompetitor, keluhan pemilik toko. Masalahnya, informasi tersebut tersebar di banyak laporan dan baru terbaca beberapa hari kemudian. LLM bisa merangkum setiap laporan ke format yang sama, sehingga supervisor dapat langsung mengetahui toko mana yang memerlukan tindak lanjut.

    Seperti apa arsitekturnya di IONext?

    Alur laporan kunjungan toko: aplikasi sales, pre-processing dan masking, inference API, database dan object storage di Jakarta, dashboard supervisor, dipantau IONA

    Alurnya sederhana. Aplikasi sales mengirim laporan ke service milik SI yang berjalan di VM ORBIT. Service itu menyamarkan data pribadi, lalu memanggil inference API IONext. Hasilnya disimpan di Jakarta dan tampil di dashboard supervisor. IONA membaca sinyal production setelah go-live.

    1. Aplikasi sales lapangan milik klien mengirim catatan teks dan foto ke endpoint milik SI.
    2. Service pre-processing di VM ORBIT mengecilkan ukuran foto dan menyamarkan nama serta nomor telepon pemilik toko sebelum masuk prompt.
    3. Service memanggil inference API IONext yang kompatibel dengan OpenAI. Per Oktober 2026, katalog IONext memuat Qwen3.8-27B, model open-weight yang menerima input gambar dan mendukung structured output.
    4. Model mengembalikan JSON dengan field tetap: kategori temuan, ringkasan, tingkat urgensi, dan usulan next step.
    5. JSON masuk database, foto asli masuk object storage. Keduanya berada di Jakarta. Dashboard supervisor membaca dari database.
    6. IONA memantau VM, model, dan pipeline: memory usage yang terus naik, step pipeline yang "macet", atau database yang terekspos ke IP publik.

    Keputusan apa yang perlu diambil SI?

    Keputusan Default yang disarankan Alasannya
    Lokasi pemrosesan Inference dan storage di Jakarta Catatan dan foto bisa memuat data pribadi pemilik toko. Pasal 4 UU PDP memasukkan nama lengkap dan data yang dikombinasikan untuk mengenali seseorang sebagai data pribadi umum.
    Format output JSON dengan skema tetap Dashboard tetap berfungsi meskipun model menulis dengan gaya berbeda.
    Data pribadi di prompt Disamarkan sebelum masuk model Log prompt tidak ikut menyimpan nama dan nomor telepon.
    Ukuran foto Dikecilkan saat pre-processing Request lebih ringan sehingga timeout lebih jarang terjadi.
    Akses dashboard Private, dengan firewall rule di ORBIT Hanya supervisor yang perlu mengaksesnya. Tidak ada database di IP publik.

    Apa yang biasanya "macet"?

    Tiga hal paling sering muncul di pola seperti ini, dan semuanya bisa dicegah sejak desain:

    • Output tidak konsisten. Prompt yang hanya meminta "ringkasan" menghasilkan format berbeda tiap kali. Gunakan JSON mode atau structured output sejak hari pertama.
    • Foto wajah ikut terkirim. Foto wajah bisa masuk kategori data biometrik, yang menurut Pasal 4 UU PDP termasuk data pribadi spesifik. Atur aplikasi supaya sales memotret rak dan produk saja.
    • Laporan menumpuk di sore hari. Tim sales biasanya mengirim laporan setelah kunjungan terakhir. Gunakan antrean (queue) supaya peak load tidak membuat request gagal.

    Checklist replikasi

    1. Sepakati skema JSON dengan klien sebelum menulis prompt.
    2. Tulis aturan masking untuk nama, nomor telepon, dan alamat pemilik toko.
    3. Tetapkan aturan foto di aplikasi: rak dan produk, tanpa wajah.
    4. Uji model dengan sampel laporan asli yang sudah disamarkan, termasuk foto buram.
    5. Pasang queue dan retry di service pre-processing.
    6. Atur database dan dashboard ke private, lalu periksa peringatan exposed resource di IONA.
    7. Masukkan penyedia infrastruktur ke daftar sub-prosesor klien. Lihat pembagian peran SI dan penyedia infrastruktur.

    Di mana IONext berperan

    IONext menyediakan GPU di Jakarta, inference API, workspace ORBIT untuk VM dan pipeline, serta IONA untuk membaca sinyal production. Aplikasi sales, logika masking, dashboard, dan hubungan dengan klien tetap dikerjakan SI. IONext tidak menilai kualitas data lapangan dan tidak menggantikan penilaian dampak pelindungan data pribadi milik klien. Detail sertifikasi dan lokasi data ada di halaman Keamanan dan Kepatuhan.

    Langkah berikutnya: untuk mengeksplorasi ORBIT dan IONA, buat akun di IONext Console. System integrator yang berencana menerapkan pola ini bagi klien FMCG dapat mengajukan diskusi kemitraan melalui Program Mitra IONext.

    Sumber

    Artikel ini merupakan penjelasan umum dan bukan nasihat hukum. Konsultasikan kewajiban spesifik proyek 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.

    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.

    Artikel terkait

    Lihat semua artikel