RAG Architecture That Keeps Data in Indonesia

RAG (retrieval-augmented generation) that keeps data in Indonesia means every component that touches client data is processed onshore, not just where the documents are stored. That includes the embedding model, the vector database, the language model, logs, and backups. In practice, data most often leaves the country through a supporting component, not through the primary database.

This guide is for system integrators, software houses, and AI builders building a knowledge assistant, a customer service chatbot, or document search for enterprise clients, who need to answer "where is our data processed?" with an answer they can prove.

Why isn't "the documents are stored in Jakarta" enough?

RAG moves document chunks several times over. During indexing, every chunk is sent to an embedding model. When a user asks a question, that question and the relevant chunks are sent to a language model. During debugging, the full prompt and response are often logged by a tracing service.

That means a single user question can pass through several different services. If any one of them sits abroad, client data leaves the country with it, even if the source documents never left Jakarta. With PP 33/2026 taking effect on 16 January 2027, each of those services also needs to be recorded as a sub-processor and approved by the client.

RAG components and the leak points teams miss

Does an embedding count as personal data?

Treat it as personal data. Embeddings are numeric vectors, but nearly every vector database also stores the original chunk text alongside the vector. PP 33/2026 also states that identification can happen through combining data, including data available in the public domain. Treating a vector database as "just numbers" is an assumption that will not hold up in front of a client's security team.

A reference architecture for onshore RAG

1. Ingestion. Documents are pulled from source systems along with their access-control metadata, such as business unit, role, or confidentiality level.
2. Redaction. Personal data not required to answer questions, such as national ID numbers or account numbers, is masked or removed before indexing.
3. Chunking and embedding. Documents are split and turned into embeddings using an open-weight model running on an onshore GPU.
4. Storage. Embeddings, chunk text, and access-control metadata are stored in a self-hosted vector database on a private network, with no public IP.
5. Retrieval with a permission filter. Every search is filtered against the requesting user's access rights, so the AI never surfaces a document the user is not allowed to see.
6. Generation. The question and its context are sent to an open-weight model through an onshore, OpenAI-compatible inference endpoint.
7. Output check. The response is checked before it is sent, for example to catch personal data that should not appear.
8. Controlled logging. Prompts and responses are logged onshore, with a retention period the client has agreed to and restricted access.
9. Escalation to a human. Users can flag a wrong answer, and cases affecting an individual are routed to a person.

Code example: pointing an app at onshore inference

Because IONext's inference endpoint is OpenAI-compatible, an application already built on the OpenAI SDK only needs a different base URL, API key, and model name. Keep all three in environment variables so the same code can be pointed at any environment.

import os
from openai import OpenAI

# Endpoint, key, and model name come from the environment,
# so the same code can be pointed at onshore inference.
client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

def answer(question: str, context: list[str]) -> str:
    context_text = "\n\n".join(context)
    resp = client.chat.completions.create(
        model=os.environ["LLM_MODEL"],
        messages=[
            {"role": "system", "content": "Answer only from the context. If the answer isn't in the context, say you don't know."},
            {"role": "user", "content": f"Context:\n{context_text}\n\nQuestion: {question}"},
        ],
        temperature=0.2,
    )
    return resp.choices[0].message.content

Make sure the embedding model is pointed at an onshore endpoint too. That's the step most often missed during migration.

How to choose a model for RAG

Start from the use case, not from whichever model gets talked about most. Four questions matter most:

• Language. How well does the model answer in Bahasa Indonesia, including technical terms and a client's internal abbreviations?
• Context length. How many document chunks need to fit into a single question?
• Tool calling. Does the assistant only answer, or does it also need to call other systems?
• GPU footprint. Does the model fit on a single GPU, or does it need a larger configuration? Available GPU specs are on the GPU page.

As of October 2026, the open-weight models available on IONext are Qwen3.8-27B, Gemma4-31B-IT, and DeepSeek-V4-Flash-0731. The current list is always available at ionext.ai/en.

Ten questions for a design review

• Where does each pipeline component process data, including embedding, tracing, and backup?
• Are all third-party services recorded as sub-processors and approved by the client in writing?
• What personal data is masked before indexing, and why is the rest still needed?
• Do access rights from the source system carry through and get applied at retrieval time?
• Are the vector database and model endpoint reachable only from a private network?
• How long are prompts and responses retained, and who can read them?
• Does the evaluation dataset use production data, and where is that dataset stored?
• How do users report a wrong answer, and who follows up?
• If an incident happens, what logs are available for investigation within hours?
• Is all of the above documented in a format the client can use for a DPIA?

The most common mistakes

• Language model onshore, embedding model abroad. Teams move the language model but forget that every document chunk is also sent to an embedding API.
• Prototyping tracing carried into production. A tracing integration switched on during experimentation keeps sending full prompts to an external service after go-live.
• A vector database open to the internet. The database is opened over a public IP for easier access during development, and it's never closed again.
• Production data on a personal notebook. Real question samples get copied for evaluation and end up on an engineer's laptop or personal cloud account.
• Cross-region backup. Automatic snapshots get replicated to another region because of a cloud provider's default setting.

Where IONext fits

IONext provides the components an onshore RAG pipeline needs: virtual machines and managed Kubernetes for the parser and vector database, S3-compatible object storage and block storage held entirely within Indonesia, and inference through an OpenAI-compatible API for open-weight models.

In ORBIT, every resource's public or private status is visible from the topology view, and access rules can be fixed from the same place, so a vector database accidentally opened to the public internet gets caught faster. IONA flags resources that are exposed when they should not be, and helps recommend the VM and model configuration that fits the use case. The ISO 27001 certificate number and data center location are on the Security and Compliance page. Teams can sign up and try it directly. System integrators taking this kind of project to bank, BUMN or government clients can work with IONext through the IONext Partner Program for system integrators.