Who Owns What: Splitting Roles Between System Integrators and AI Infrastructure Providers in Indonesia

Every enterprise AI project in Indonesia has three parties. The client decides what happens to the data. The system integrator owns the solution and the client relationship. The infrastructure provider owns compute, where processing happens, and security at the lower layers. Projects rarely fail inside one of those roles. They fail at the handoffs between them.

This article is for system integrators, software houses and AI delivery teams building for enterprise clients in Indonesia, including regional and international firms entering the market. It draws on a project IONext supported with one of its system integrator partners: document authenticity verification for the compliance team of an Indonesian listed group. The client and the partner are not named.

Why role splits now have to be written down in Indonesia

Indonesia's Personal Data Protection Law (UU PDP, Law No. 27 of 2022) has applied in full since 17 October 2024. Its implementing regulation, Government Regulation No. 33 of 2026 (PP 33/2026), was enacted on 16 July 2026 and takes effect on 16 January 2027. From that date, the question is no longer only what the law requires, but how an organisation proves it.

For readers familiar with GDPR, the structure will look recognisable:

Data controller (Pengendali Data Pribadi): the client, which decides the purpose of processing.
Data processor (Prosesor Data Pribadi): usually the system integrator that builds and runs the AI system on the client's behalf.
Sub-processors: any third-party service in the architecture that touches personal data, such as a GPU cloud, a model API, a vector database service or a logging platform.

PP 33/2026 sets minimum contents for processor agreements and requires the controller's written approval before a sub-processor is used (Articles 14 and 15). In practice, choices such as "whose GPUs run the model" or "where the logs live" are no longer internal engineering decisions. They have to be recorded, approved by the client and shown on audit.

Two local specifics matter for foreign providers. First, transferring personal data outside Indonesian jurisdiction is allowed only under conditions (UU PDP Article 56, with a tiered mechanism in PP 33/2026 Article 165). Second, as of October 2026 the data protection authority has not yet been formed, so the adequacy list and standard contractual clauses that would make cross-border transfers routine are not yet available. Offshore model APIs are not banned, but they currently carry the most open questions. Breach notification to data subjects and the authority is due within 3 x 24 hours (UU PDP Article 46).

Case study: compliance document verification

As of October 2026 the project is at pilot design. This section describes how the work was run, not its results.

The client is an Indonesian listed group with many subsidiaries. Its compliance team is small, while the documents it must check arrive from every entity: vendor legal documents (tax ID, business registration, deeds, certificates), bank references, receipts, reimbursement claims and vendor proposals as PDFs. Verification was manual, so it was slow and results varied between reviewers.

The steps below show who held the decision at each stage.

The client set the order of priorities. The partner proposed three use cases: pattern detection in whistleblowing reports, vendor and employee conflict-of-interest checks, and document authenticity verification. The partner recommended starting with the first or second. The client chose document verification first, reasoning that once document reading is solid, the other two become easier. The partner reordered its plan around that logic.
Data scope was limited from the start. The pilot covers Indonesian entities only. Overseas subsidiaries were deferred because the client did not want to take on cross-jurisdiction data questions yet. That is an infrastructure decision, made at scoping, before any code was written.
An NDA came before any sample data changed hands. The NDA template was adapted for a listed company with a group-of-companies clause. Sample documents were shared only once it was in force.
A working session on real data, not a pitch. The client asked for a workshop that processed its own documents, so the compliance team could see how the system works from day one. The partner prepared a four-layer pipeline:
- structural: PDF metadata and edit traces
- visual: inconsistencies in signatures, stamps and letterheads
- content: OCR and an LLM checking internal consistency, such as amounts written in figures and in words
- external: matching against public registries
The output for reviewers is an authenticity score, suspicious areas marked directly on the PDF, and a plain-language explanation.
The client's IT team met the infrastructure team directly. IT asks different questions from compliance: where processing happens, audit logs, observability, security certification, and how open-weight models can be audited. Infrastructure questions were not answered with estimates. IONext's infrastructure team answered them with documents, including the ISO/IEC 27001:2022 certificate.
Open questions were logged as debt, not hidden. Four of them: what false-positive rate is acceptable and who reviews flagged results, how to verify documents with no reference database, whether verification can run before documents enter the finance system, and how the client can eventually maintain and extend the system itself.

Five of the six steps sit with the client or the system integrator; the infrastructure provider steps in when a question needs evidence.

The lesson: the decisions that matter most, such as use-case order, data boundaries and processing location, are made in the first few weeks. They come out of conversations between the client and the system integrator, while the infrastructure provider answers the questions only it can answer.

Explore the role split

Pick one of the six steps above to see who holds the decision, what gets handed to the other party, and what has to close out before the next step.

Client

Data controller

System integrator

Processor

Infrastructure provider

Sub-processor*

Step 1 · Discovery

The client sets the priority

The partner proposed three use cases. The client chose document verification first, reasoning that solid document reading unlocks the other two, and the partner reordered its plan around that logic.

Checkpoint before moving on

Document verification set as the first use case.
Reasoning and delivery order agreed together.

Handoff point

Priority decision → delivery plan

The system integrator carries the client decision into the delivery order and records the reasoning.

What this step must produce

A prioritized use-case list with the business reasoning the client signed off on.

Step 1 of 6
Active roles: Client + system integrator

* Applies when this service processes the client's personal data (PP 33/2026, Articles 14 and 15).

What we would do differently

Four things we and the partner would change on the next project:

Bring the client's IT and security team in from the first meeting. Here, IT joined only briefly at the start, yet their questions decide when a pilot is allowed to run.
Have a group-company NDA template ready. Listed companies with many subsidiaries need a group clause, and adding it mid-way costs time.
Lock the workshop date when the NDA is signed. The workshop in this project slipped from its first target. A date agreed alongside the NDA protects momentum and the client's budget cycle.
Ask which capability unblocks the rest. The client saw first that document reading is the foundation for the other two use cases. The partner should have asked that question in the first discovery session.

Who owns what

The table maps project activities to the three roles. The last column is what has to be handed to another party, because that is where projects usually stall.

Activity	Client (controller)	System integrator (processor)	Infrastructure provider (sub-processor)	Handoff
Purpose and legal basis for processing	Decides	Gives technical input	Not involved	Data types and purposes to the SI
Use-case priority and scope	Decides	Proposes and tests feasibility	States capacity limits	Data boundaries by entity and region
Solution architecture and model choice	Approves	Designs	Provides available models and GPUs	Sub-processor list with locations to the client
Infrastructure sizing	Approves budget	Supplies the workload profile	Recommends configuration	Workload profile from SI to provider
Processing, log and backup location	Approves	Documents	Guarantees physical location and supplies evidence	Location evidence and certificate to the client
Application security and access	Sets policy	Builds and runs	Secures network and hardware layers	Security review results to client IT
Input for the DPIA	Prepares and signs	Prepares the information pack	Supplies infrastructure detail	DPIA pack to the controller
Day-to-day operations and user support	Reports issues	First line	Escalation for infrastructure issues	Agreed escalation path and contacts
Data protection incident	Notifies data subjects and the authority	Reports to the client at the first opportunity	Reports to the SI and supplies logs	Logs and timeline, well inside 3 x 24 hours
Billing	Pays	Bills for the solution	Bills for infrastructure, directly or via the SI	Billing structure agreed upfront

Handoffs that most often break

Sizing treated as the infrastructure provider's job alone. A provider cannot size GPUs without a workload profile from the system integrator. What matters is not how many users log in, but how many requests the GPU processes at the same moment. For knowledge assistants, the heaviest load often comes from ingesting the document corpus at the start, not from daily chat.
Logging and tracing left off the sub-processor list. The model runs in Indonesia, but a tracing service switched on during prototyping still sends full prompts offshore.
Sample data leaking before the NDA applies. Example documents get sent by email or personal chat to speed up a workshop, and are never deleted.
Incident escalation without names or numbers. Everyone agrees to "keep each other informed", but nobody knows who calls whom when something breaks outside office hours.
Billing structure discussed only after go-live. The client is surprised by two invoices from two legal entities, or procurement rejects them because the infrastructure vendor is not registered.

Pre-kickoff checklist

Controller, processor and sub-processor roles written into the contract or an addendum.
A complete sub-processor list, including model, embedding, vector database, logging and backup, with processing locations.
The client's written approval of that sub-processor list.
Pilot data boundaries agreed: entities, regions and document types.
An NDA in force before sample data is shared, with rules for storing and deleting samples.
The workload profile handed from SI to infrastructure provider before sizing.
A Q&A session between client IT and the infrastructure team scheduled before build.
An incident escalation path with names, contacts and a reporting deadline to the client.
Billing structure, currency and tax documents agreed with the client's procurement team.

Where IONext fits

IONext sits underneath the system integrator, not beside it. The client relationship, solution design and first-line support stay with the system integrator. IONext provides GPUs, managed inference through an OpenAI-compatible API, and open-weight model hosting, with processing and storage in Jakarta.

For the handoffs in the table, IONext brings three things. First, evidence for the client's IT team: the ISO/IEC 27001:2022 certificate from TÜV NORD Indonesia (registration no. 01 07 E 26000410) with its scope, data location and security controls, all listed on the Security and Compliance page. Second, sizing recommendations based on the workload profile the system integrator supplies; in ORBIT, IONA helps recommend VM configuration and models. Third, billing in Indonesian rupiah through an Indonesian legal entity, which removes currency exposure for the client.

For every system integrator partner, IONext offers an infrastructure Q&A session with the client's IT and security team before build starts, as in step five of the case study above.

Frequently asked questions

Does a system integrator have to list its GPU cloud provider as a sub-processor? Yes, if those GPUs process the client's personal data. PP 33/2026 requires the controller's written approval before a sub-processor is used.

Who is accountable if an incident happens at the infrastructure layer? The controller still has to notify data subjects and the authority within 3 x 24 hours. That is why reporting duties from infrastructure provider to system integrator, and from system integrator to client, should be written with shorter deadlines.

Does running on infrastructure inside Indonesia make a project compliant with UU PDP? No. Onshore infrastructure simplifies the questions about data location and cross-border transfer. Legal basis, the DPIA and data subject rights remain obligations that have to be met.

Can a foreign system integrator work on Indonesian projects this way? Yes. The role split does not depend on where the system integrator is headquartered. What matters is where the client's personal data is processed and whether each sub-processor is documented and approved.

Sources

Law No. 27 of 2022 on Personal Data Protection (UU PDP)
Government Regulation No. 33 of 2026 implementing Law No. 27 of 2022 (PP 33/2026)
PP 33/2026: Impact on AI Projects, IONext Signals
RAG Architecture That Keeps Data in Indonesia, IONext Signals
IONext Security and Compliance

This article is general information, not legal advice. For compliance decisions, refer to the official text of the regulations and consult legal counsel.

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 Indonesia.