Pattern Card: Summarizing Store Visit Reports with an LLM, Data Kept in Indonesia
A pattern card for SIs: summarize field sales store visit notes and photos with an open-weight LLM hosted in Jakarta, with the key decisions and a replication checklist.
FMCG field sales teams send store visit notes and photos every day, but supervisors rarely have time to read them all. This pattern uses an open-weight LLM running in Jakarta to turn those notes and photos into structured summaries, without store data or store owners' personal data leaving Indonesia.
Status: an architecture pattern that can be built on IONext, not a project report. Systems integrators and software houses are welcome to use this card in their pitch decks.
What problem does this pattern solve?
Store visit notes are usually free text and photos. The content matters: out-of-stock items, shelf prices, competitor activity, store owner complaints. The problem is that this information is scattered across many reports and only gets read days later. An LLM can summarize every report into the same format, so supervisors immediately see which stores need follow-up.
What does the architecture look like on IONext?
The flow is simple. The sales app sends each report to a service owned by the SI, running on an ORBIT VM. That service masks personal data, then calls the IONext inference API. Results are stored in Jakarta and shown on a supervisor dashboard. IONA reads production signals after go-live.
- The client's field sales app sends text notes and photos to an endpoint owned by the SI.
- A pre-processing service on the ORBIT VM downsizes photos and masks store owners' names and phone numbers before anything enters a prompt.
- The service calls the OpenAI-compatible IONext inference API. As of October 2026, the IONext catalog includes Qwen3.8-27B, an open-weight model that accepts image input and supports structured output.
- The model returns JSON with fixed fields: finding category, summary, urgency level, and suggested next step.
- The JSON goes into a database and the original photos into object storage. Both are located in Jakarta. The supervisor dashboard reads from the database.
- IONA monitors the VM, model, and pipeline: steadily rising memory usage, a pipeline step that stalls, or a database exposed to a public IP.
What decisions does the SI need to make?
| Decision | Suggested default | Why |
|---|---|---|
| Processing location | Inference and storage in Jakarta | Notes and photos can contain store owners' personal data. Article 4 of the PDP Law classes full names, and data that combined identifies a person, as general personal data. |
| Output format | JSON with a fixed schema | The dashboard keeps working even when the model writes in a different style. |
| Personal data in prompts | Masked before reaching the model | Prompt logs do not end up storing names and phone numbers. |
| Photo size | Downsized in pre-processing | Lighter requests and fewer timeouts. |
| Dashboard access | Private, with firewall rules in ORBIT | Only supervisors need to see it. No database sits on a public IP. |
What usually goes wrong?
Three issues come up most often in a pattern like this, and all of them can be prevented at design time:
- Inconsistent output. A prompt that only asks for a "summary" produces a different format each time. Use JSON mode or structured output from day one.
- Face photos get sent along. Photos of faces can count as biometric data, which Article 4 of the PDP Law classes as specific personal data. Configure the app so sales reps photograph shelves and products only.
- Reports pile up in the afternoon. Reps usually send reports after their last visit. Use a queue so peak load does not cause failed requests.
Replication checklist
- Agree on the JSON schema with the client before writing any prompt.
- Write masking rules for store owners' names, phone numbers, and addresses.
- Set a photo rule in the app: shelves and products, no faces.
- Test the model on real, masked report samples, including blurry photos.
- Add a queue and retry to the pre-processing service.
- Set the database and dashboard to private, then check IONA's exposed resource alerts.
- Add the infrastructure provider to the client's sub-processor list. See how roles split between the SI and the infrastructure provider.
Where IONext fits
IONext provides GPUs in Jakarta, the inference API, the ORBIT workspace for VMs and pipelines, and IONA for reading production signals. The sales app, masking logic, dashboard, and client relationship remain the SI's work. IONext does not assess the quality of field data and does not replace the client's own data protection impact assessment. Certification and data location details are on the Security and Compliance page.
Next step: to explore ORBIT and IONA, create an account in the IONext Console. Systems integrators planning to apply this pattern for FMCG clients can start a partnership discussion through the IONext Partner Program.
Sources
- Law No. 27 of 2022 on Personal Data Protection, Article 4
- IONext llms.txt: model catalog and inference API capabilities, as of 12 October 2026
- Using LLMs with customer data: what the PDP Law says
- Choosing an open-weight model for Indonesian-language document extraction
This article is a general explanation and not legal advice. Consult legal counsel on the specific obligations of a given project.
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.