Arsitektur RAG yang Datanya Tetap di Indonesia

RAG (retrieval-augmented generation) yang datanya tetap di Indonesia berarti setiap komponen yang menyentuh data klien diproses di dalam negeri, bukan hanya penyimpanan dokumennya. Itu mencakup model embedding, vector database, model bahasa, log, dan backup. Dalam praktik, data paling sering keluar negeri lewat komponen pendukung, bukan lewat database utama.

Panduan ini untuk system integrator, software house, dan AI builder yang membangun asisten pengetahuan, chatbot layanan pelanggan, atau pencarian dokumen untuk klien enterprise, dan perlu menjawab pertanyaan "data kami diproses di mana?" dengan jawaban yang bisa dibuktikan.

Mengapa "dokumennya disimpan di Jakarta" belum cukup?

RAG memindahkan potongan dokumen berkali-kali. Saat indexing, setiap potongan dikirim ke model embedding. Saat pengguna bertanya, pertanyaan dan potongan dokumen yang relevan dikirim ke model bahasa. Saat debugging, prompt dan respons lengkap sering tercatat di layanan tracing.

Artinya, satu pertanyaan pengguna bisa melewati beberapa layanan berbeda. Jika salah satunya berada di luar negeri, data klien ikut keluar, meskipun dokumen sumbernya tidak pernah meninggalkan Jakarta. Dengan PP 33/2026 yang berlaku 16 Januari 2027, setiap layanan itu juga perlu tercatat sebagai sub-prosesor dan disetujui klien.

Komponen RAG dan titik bocor yang sering terlewat

Apakah embedding termasuk data pribadi?

Perlakukan saja sebagai data pribadi. Embedding memang berupa vektor angka, tetapi hampir semua vector database menyimpan teks potongan aslinya di samping vektor tersebut. PP 33/2026 juga menjelaskan bahwa identifikasi bisa terjadi melalui penggabungan data, termasuk dengan data yang tersedia di domain publik. Menganggap vector database "hanya berisi angka" adalah asumsi yang sulit dipertahankan di depan tim keamanan klien.

Arsitektur referensi RAG dalam negeri

1. Ingestion. Dokumen diambil dari sistem sumber beserta metadata hak aksesnya, misalnya unit kerja, peran, atau tingkat kerahasiaan.
2. Redaksi. Data pribadi yang tidak diperlukan untuk menjawab pertanyaan, seperti NIK atau nomor rekening, disamarkan atau dihapus sebelum indexing.
3. Chunking dan embedding. Dokumen dipotong dan diubah menjadi embedding menggunakan model open-weight yang berjalan di GPU dalam negeri.
4. Penyimpanan. Embedding, teks potongan, dan metadata hak akses disimpan di vector database self-hosted pada jaringan privat, tanpa IP publik.
5. Retrieval dengan filter izin. Setiap pencarian difilter berdasarkan hak akses pengguna yang bertanya, sehingga AI tidak menampilkan dokumen yang tidak boleh ia lihat.
6. Generation. Pertanyaan dan konteks dikirim ke model open-weight melalui endpoint inference dalam negeri yang kompatibel dengan OpenAI.
7. Pemeriksaan output. Respons dicek sebelum dikirim, misalnya untuk mendeteksi data pribadi yang tidak seharusnya muncul.
8. Logging terkendali. Prompt dan respons dicatat di dalam negeri dengan masa simpan yang disepakati klien dan akses terbatas.
9. Eskalasi ke manusia. Pengguna bisa menandai jawaban yang salah, dan kasus yang berdampak pada individu diteruskan ke petugas.

Contoh kode: mengarahkan aplikasi ke inference dalam negeri

Karena endpoint inference IONext kompatibel dengan OpenAI, aplikasi yang sudah memakai OpenAI SDK cukup mengganti base URL, API key, dan nama model. Simpan ketiganya di environment variable agar kode yang sama bisa dipakai di setiap lingkungan.

import os
from openai import OpenAI

# Endpoint, key, dan nama model diambil dari environment,
# sehingga kode yang sama bisa diarahkan ke inference dalam negeri.
client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

def jawab(pertanyaan: str, konteks: list[str]) -> str:
    isi_konteks = "\n\n".join(konteks)
    resp = client.chat.completions.create(
        model=os.environ["LLM_MODEL"],
        messages=[
            {"role": "system", "content": "Jawab hanya berdasarkan konteks. Jika jawabannya tidak ada di konteks, katakan tidak tahu."},
            {"role": "user", "content": f"Konteks:\n{isi_konteks}\n\nPertanyaan: {pertanyaan}"},
        ],
        temperature=0.2,
    )
    return resp.choices[0].message.content

Pastikan model embedding juga diarahkan ke endpoint dalam negeri. Ini titik yang paling sering terlewat saat migrasi.

Bagaimana memilih model untuk RAG?

Mulai dari kebutuhan kasus penggunaan, bukan dari model yang paling sering dibicarakan. Empat pertanyaan yang paling menentukan:

• Bahasa. Seberapa baik model menjawab dalam Bahasa Indonesia, termasuk istilah teknis dan singkatan internal klien?
• Panjang konteks. Berapa banyak potongan dokumen yang perlu dimasukkan dalam satu pertanyaan?
• Tool calling. Apakah asisten hanya menjawab, atau juga perlu memanggil sistem lain?
• Kebutuhan GPU. Apakah model muat di satu GPU, atau butuh konfigurasi yang lebih besar? Spesifikasi GPU yang tersedia ada di halaman GPU.

Per Oktober 2026, model open-weight yang tersedia di IONext adalah Qwen3.8-27B, Gemma4-31B-IT, dan DeepSeek-V4-Flash-0731. Daftar terbaru selalu tersedia di ionext.ai.

Sepuluh pertanyaan untuk design review

• Di mana setiap komponen pipeline memproses data, termasuk embedding, tracing, dan backup?
• Apakah semua layanan pihak ketiga sudah tercatat sebagai sub-prosesor dan disetujui klien secara tertulis?
• Data pribadi apa yang disamarkan sebelum indexing, dan mengapa sisanya tetap diperlukan?
• Apakah hak akses dari sistem sumber ikut terbawa dan dipakai saat retrieval?
• Apakah vector database dan endpoint model hanya bisa diakses dari jaringan privat?
• Berapa lama prompt dan respons disimpan, dan siapa yang bisa membacanya?
• Apakah dataset evaluasi memakai data produksi, dan di mana dataset itu disimpan?
• Bagaimana pengguna melaporkan jawaban yang salah, dan siapa yang menindaklanjuti?
• Jika terjadi insiden, log apa yang tersedia untuk investigasi dalam hitungan jam?
• Apakah informasi di atas sudah terdokumentasi dalam format yang bisa dipakai klien untuk DPIA?

Kesalahan yang paling sering terjadi

• Model bahasa di dalam negeri, embedding di luar negeri. Tim memindahkan model bahasa, tetapi lupa bahwa setiap potongan dokumen juga dikirim ke API embedding.
• Tracing prototyping terbawa ke produksi. Integrasi tracing yang diaktifkan saat eksperimen tetap mengirim prompt lengkap ke layanan eksternal setelah go-live.
• Vector database terbuka ke internet. Database dibuka lewat IP publik agar mudah diakses saat development, lalu tidak pernah ditutup.
• Data produksi di notebook pribadi. Sampel pertanyaan nyata disalin untuk evaluasi dan berakhir di laptop atau akun cloud engineer.
• Backup lintas region. Snapshot otomatis direplikasi ke region lain karena pengaturan bawaan penyedia cloud.

Di mana IONext berperan

IONext menyediakan komponen yang dibutuhkan pipeline RAG di dalam negeri: virtual machine dan managed Kubernetes untuk parser dan vector database, object storage kompatibel S3 dan block storage yang sepenuhnya berada di Indonesia, serta inference melalui API yang kompatibel dengan OpenAI untuk model open-weight.

Di ORBIT, status publik atau privat setiap resource terlihat dari tampilan topologi, dan aturan akses bisa diperbaiki dari tempat yang sama, sehingga vector database yang tidak sengaja terbuka ke internet publik lebih cepat ketahuan. IONA menandai resource yang terekspos padahal seharusnya tidak, dan membantu merekomendasikan konfigurasi VM dan model yang sesuai kasus penggunaan. Nomor sertifikat ISO 27001 dan lokasi data center ada di halaman Keamanan dan Kepatuhan. Tim bisa mendaftar dan mencobanya langsung. System integrator yang membawa proyek seperti ini ke klien perbankan, BUMN atau pemerintah bisa bekerja sama lewat Program Mitra IONext untuk system integrator.