Document AI and OCR for Customer Documents, Without Data Leaving Indonesia

Document AI for customer documents can be built so that every stage of processing stays in Indonesia: storage, OCR, extraction with open-weight models, validation, down to the logs. What decides this is not only the location of the server, but whether every supporting component, including logging, tracing and fallback, also runs onshore.

This article is an architecture pattern that system integrators, software houses, and internal AI teams can build on IONext to automate onboarding, KYC, or document verification for banks, multifinance, insurance, and state-owned enterprises. It is not a case study of a specific project.

What problem does Document AI solve for customer documents?

Document AI turns photos and PDFs of customer documents, such as the KTP (national ID), NPWP tax ID, family card, payslip and bank statement, into structured data that can be validated and loaded into core systems. The issue is that these documents contain personal data, and part of it is personal financial data, which under the PDP Law is classified as specific personal data.

Operations teams usually retype document contents by hand. Many then reach for a global OCR or LLM API because it is easy to wire up. This is where projects often stall at the client's risk and compliance desk, not at the technical desk.

As of October 2026, three bases usually come up from clients:

• Law No. 27/2022 (the PDP Law), Article 4(2) includes "personal financial data" in specific personal data.
• PDP Law Article 34 requires the controller to run a data protection impact assessment (DPIA) for high-risk processing, including processing of specific personal data, large-scale processing, and the use of new technology.
• POJK No. 11/POJK.03/2022 requires commercial banks to place their electronic systems in Indonesia. Placement abroad is only for certain criteria and with OJK approval.

For the transfer of personal data abroad, also read IONext's review of the impact of PP 33/2026 on AI projects.

What does the architecture look like on IONext?

The pattern has seven layers, all running on IONext infrastructure in Jakarta: document storage, pre-processing, OCR and layout analysis, extraction with an LLM or vision-language model, rule validation, a human review queue, and observability. No layer calls a service abroad.

Layer	Function	Common components	On IONext
1. Ingest	Receive photos or PDFs from the app, portal, or branch scanner	Private bucket, encryption, signed upload URL	S3-compatible object storage in Indonesia
2. Pre-processing	Rotate, deskew, split pages, classify document type	OpenCV, a lightweight classifier	VM or Kubernetes on ORBIT
3. OCR and layout	Read text, tables and field positions	PaddleOCR (PP-OCRv5, PP-StructureV3), Docling	GPU VM, see IONext GPU options
4. Extraction	Turn text or image into JSON against a schema	Open-weight LLM via an OpenAI-compatible API, or a vision-language model such as Granite-Docling	Managed inference, or a self-hosted model on a GPU VM
5. Validation	Check NIK 16-digit format, date consistency, statement opening and closing balance	A rule engine in application code	The SI's own application
6. Human review	Low-confidence fields go to an operator queue	Internal review app	Private network, no export to spreadsheet
7. Observability	Monitor resources, models and pipeline, detect publicly exposed resources	IONA and the ORBIT topology view	Logs stored in Indonesia

ORBIT is the workspace for building and running infrastructure, pipelines and models. Its topology view shows which resources are public and which are private. IONA reads signals from the infrastructure, models and pipeline, flags resources that are exposed when they should be private, and recommends VM and model configurations per use case.

If your application already uses the OpenAI SDK, the extraction step can be pointed at IONext's endpoint. The how is covered in the OpenAI-compatible API guide.

Which infrastructure decisions matter most?

Three decisions most affect compliance and operating cost: classic OCR or vision-language model, which GPU to use, and where the logs are stored. The third is the one most often forgotten, even though OCR logs contain the customer document content as text.

Classic OCR, VLM, or both. A hybrid pattern is usually the safest for customer documents.

Approach	Best for	Main risk
Classic OCR + text LLM	KTP, NPWP, forms with fixed layout	Long tables like a bank statement need extra layout analysis
Vision-language model directly	Varied documents, low-quality photos	The model may fill in a field that is actually unreadable
Hybrid: OCR first, VLM for hard cases	A mix of document types in one onboarding flow	More components to monitor

GPU choice. As of October 2026, IONext's fleet uses the NVIDIA L40S 48GB and the NVIDIA RTX PRO 6000 Blackwell Server Edition 96GB. An OCR pipeline with small models generally fits the 48GB class. The 96GB class leaves room for a larger vision-language model or several models on one GPU. Measure with the client's own documents before choosing.

Log residency. Store application logs, tracing and evaluation results in Indonesia, and mask the NIK and account number before they reach the log.

What usually breaks?

What breaks most often is not OCR accuracy, but the side data paths. Customer data leaves through supporting services installed without review: error tracking, LLM tracing, or a fallback to a foreign API when the local queue is full. The second problem is a model that "invents" the content of an unreadable field.

1. Silent fallback. The code calls a global API when the local endpoint is slow. Turn the cross-border fallback off in configuration, not just in the documentation.
2. Logs containing document text. Raw OCR text is sent along to a SaaS observability service abroad.
3. Field hallucination. A VLM fills in a blurred date of birth or account number. Force a null value for unreadable fields and route them to human review.
4. A new bank statement layout. Every bank has a different layout. Prepare an evaluation set per format and re-run it whenever the model changes.
5. An exposed bucket or vector store. A resource made public during testing and forgotten. The ORBIT topology view and IONA alerts help find it.
6. Unlimited retention. Original images and extraction results are kept forever. Set a retention period together with the client as data controller.
7. A late DPIA. The impact assessment is only run after the system is built, then finds a data flow that must be reworked.

Replication checklist for system integrators

Use this checklist when writing the proposal and at kickoff. Every line needs an owner: the client, the SI, or the infrastructure provider. How that division of roles works is covered in more detail in who holds what in an AI project.

• A list of document types and fields to extract, marked where they are specific personal data
• DPIA started before the final design, led by the client as controller
• A data flow map: every component, its location, and whether it calls an external service
• All storage (original documents, OCR results, logs, backups) in Indonesia
• Fallback to a foreign API disabled in configuration
• NIK and account number masked in logs and tracing
• Output JSON schema with null for unreadable fields
• A confidence threshold and a human review queue
• An evaluation set per document type and per bank format
• Retention period and deletion procedure agreed in writing
• A sub-processor list, including the infrastructure provider, ready for the contract annex
• Infrastructure provider certification evidence attached (see the Security and Compliance page)

Where IONext fits

IONext provides the infrastructure layer for this pattern: GPU as a Service, managed inference through an OpenAI-compatible API, open-weight model hosting, object storage, and Kubernetes, all in Indonesia. ORBIT is used to build and run the pipeline, IONA to monitor and flag exposed resources.

The boundary also needs to be stated clearly. IONext does not write the KYC application, does not set business validation rules, and does not replace the client's DPIA. Infrastructure certification does not automatically make the client system PDP-compliant. Compliance still depends on the application design, contracts and processes run by the SI and the client.

To try ORBIT and IONA, create an account on the IONext console. For SIs preparing a Document AI proposal for a client, talk to us through the IONext Partner Program.

Frequently asked questions

Do KTP photos and bank statements count as specific personal data? Bank statements and payslips generally fall under "personal financial data", which under PDP Law Article 4(2) is specific personal data. The KTP holds general personal data and can carry a face photo. Processing for biometric face matching falls in the specific category. Confirm the final classification with the client's legal team.

Is storing documents in Jakarta and then calling a foreign OCR API enough? No. When the image or text is sent to an API abroad, a transfer of personal data outside Indonesian jurisdiction occurs, with additional obligations for the controller. For banks, POJK 11/2022 also governs the placement of electronic systems in Indonesia.

Is an open-weight model accurate enough for Indonesian-language documents? It depends on the document type and photo quality. Libraries such as PaddleOCR support many Latin-script languages, and an open-weight LLM can be guided with a strict output schema. A defensible answer only comes from evaluation with the client's own document samples.

Sources

• Law No. 27 of 2022 on Personal Data Protection, JDIH Ministry of Finance
• Law No. 27 of 2022, article text on Pasal.id
• POJK No. 11/POJK.03/2022 on Information Technology by Commercial Banks
• POJK 11/POJK.03/2022 summary, OJK
• Bisnis.com: POJK on IT Operators, Data Centers Reorganized (31 July 2022)
• PaddleOCR 3.0 Technical Report, arXiv 2507.05595
• PaddleOCR 3.x documentation
• IBM Granite-Docling, DBTA (September 2025)
• IONext Signals: RAG Architecture That Keeps Data in Indonesia
• IONext Signals: Using an LLM on customer data, what the PDP Law requires
• IONext: Security and Compliance

This article is a general explanation and not legal advice. Consult your legal advisor on the application of the PDP Law, PP 33/2026 and POJK.

IONext is sovereign AI infrastructure hosted in Indonesia, operated by PT Data Awan Nusantara in Jakarta. IONext provides GPU as a Service, managed inference through an OpenAI-compatible API, and open-weight model hosting, certified to ISO/IEC 27001:2022 by TÜV NORD.