From Pilot to Production: Seven Handover Points That Often Break

Enterprise AI projects often stall not because of the model, but because of the handover when a pilot moves into production. In a pilot, one small team holds everything. After go-live, responsibility splits between the client, the system integrator (SI), and the infrastructure provider, and that split is rarely written down.

This article is for SIs, software houses, and AI solution companies taking a client project from pilot to go-live. It covers the phase after the contract is signed: what needs to be handed over, who holds it, and what evidence should exist before the client says the system is ready.

Why do AI projects that succeed in a pilot often stall in production?

A pilot only proves that the model can answer. Production asks for more: the system has to hold up under peak load, logs have to sit in a known location, every incident needs an owner, and the client has to be able to audit. In a pilot, one SI engineer usually covers all of this. After go-live, nobody holds it in writing.

These patterns show up often in enterprise AI projects:

• GPU sizing is taken from a pilot with a handful of users and reused as is for production transaction volume.
• Staging and production run in the same environment, so one trial deploy can disrupt the client's service.
• Monitoring alerts go to the inbox of an engineer who has moved to another project.
• Snapshots run, but a restore has never been tested.
• Nobody knows who should notify the client if a data breach occurs at the infrastructure layer.

None of these is a technology problem. All of them are handover problems.

Which handover points break most often?

Seven points are the most exposed between pilot and production: sizing, environment separation, access, monitoring, backup and restore, model versions, and the incident path. Each needs one owner and one written piece of evidence handed over before go-live, not after.

Handover point	What often happens	Primary owner	Evidence handed over before go-live
Production sizing	Pilot sizing is reused for production without retesting	SI, with the infrastructure provider's recommendation	Load test results from staging and a scale-up plan
Staging and production separation	One environment serves everything, so trial deploys disrupt the service	SI	Environment diagram and promotion rules from staging to production
Access and credentials	Personal pilot accounts stay active, API keys are shared over chat	SI and client	Access list per role, API key rotation, pilot accounts disabled
Monitoring and alerts	Alerts reach one person and there is no on-call schedule	SI for the application, infrastructure provider for the GPU and network layer	Alert matrix: which signal, who receives it, response deadline
Backup, snapshot, and restore	Snapshots run, but restore has never been tried	Infrastructure provider for the mechanism, SI for application data	Restore test record with date and result
Model version and rollback	The model is swapped without a record, output starts to drift, and the old version cannot be restored	SI	Model version registry and rollback procedure
Incident path	Unclear who contacts whom, so the report to the client is late	Client as controller, SI as processor, infrastructure provider as sub-processor	Incident response runbook with names, channels, and deadlines per party

What changes about data obligations when a pilot goes into production?

While a pilot uses dummy data, the obligations under Indonesia's Personal Data Protection Law (UU PDP) feel distant. Once production processes the personal data of customers or account holders, the chain of controller, processor, and sub-processor applies in full. Government Regulation 33 of 2026 (PP 33/2026) was promulgated on 16 July 2026 and takes effect on 16 January 2027, so a project going live now will operate under it.

Three items belong in the handover documents:

1. A written sub-processor. According to RSM Indonesia's summary of PP 33/2026, a processor must have a written agreement with the controller (Article 14), and appointing a sub-processor requires the controller's prior written approval (Article 15). If a provider's GPU infrastructure processes the client's personal data, that provider should be recorded as a sub-processor before go-live.
2. Incident reporting upstream. Article 46 of Law No. 27 of 2022 requires the controller to notify data subjects and the authority in writing within 3 x 24 hours of a personal data protection failure. The processor must also report to the controller at the first opportunity. The reporting deadlines between the infrastructure provider, the SI, and the client therefore need to be shorter than 3 x 24 hours and written into the runbook.
3. Location of logs and backups. The client will ask where logs are stored, for how long, and who can read them. The answer has to exist before go-live, not be looked up during an audit.

For bank clients, OJK rules apply as well. OJK Regulation (PADK) No. 1 of 2026 on Information Technology Implementation by Commercial Banks, in force since 1 March 2026, covers the use of IT service providers and the placement of electronic systems outside Indonesia. The full discussion is in OJK's AI governance guideline for vendors and SIs.

How should a production readiness review with the infrastructure provider be run?

A production readiness review is a single session where the client, the SI, and the infrastructure provider go through the same list. It is usually best held about two weeks before go-live. Every row needs an owner and evidence. A row without evidence means go-live is postponed, or the client signs off on the risk in writing.

An SI can use this checklist as is:

1. Load test in staging with a production-like transaction pattern, then agree on a scale-up plan if peak load exceeds the estimate.
2. Separate staging from production, including API keys and GPU access.
3. Disable accounts and API keys from the pilot period, then build an access list per role.
4. Build an alert matrix: the signals to watch (memory usage, error rate, inference queue, output drift), who receives them, and the response deadline.
5. Test a restore from a snapshot, and record the date and result.
6. Record the deployed model version and prepare a rollback procedure.
7. Write an incident response runbook with named contacts, channels, and reporting deadlines per party.
8. Confirm the infrastructure provider is recorded as a sub-processor and approved by the client in writing.
9. Document the processing location, the log location, and the backup retention period.
10. Agree on first-line support: who receives the client's first ticket, and when it escalates to the infrastructure provider.

Role splitting before kickoff is covered in who owns what between SIs and AI infrastructure providers. This checklist picks up from there.

Who contacts whom when an incident happens in the first week after go-live?

The client almost always contacts the SI first, because the SI holds the relationship and the application. The SI therefore owns first-line support. The infrastructure provider handles the GPU, network, and storage layers and reports to the SI with the root cause and recovery steps. The client, as controller, keeps the decision on notifying data subjects and the authority.

A healthy sequence:

Step	Party	Action
1	Client or monitoring	An issue is detected and a ticket reaches the SI
2	SI	Triage: is the problem in the application, the model, or the infrastructure
3	Infrastructure provider	If the issue is at the infrastructure layer, handle it and report to the SI within the runbook deadline
4	SI	Summarize impact, root cause, and recovery status for the client
5	Client	If personal data is involved, decide on notification under Article 46 of the PDP Law

If this sequence is only drafted after an incident has already happened, the report to the client will almost certainly be late.

Where IONext fits

IONext acts as the infrastructure provider beneath the system integrator. IONext provides GPUs, managed inference through an OpenAI-compatible API, and open-weight model hosting, with processing and storage in Jakarta. The available GPUs are the NVIDIA RTX PRO 6000 Blackwell Server Edition 96 GB and the NVIDIA L40S 48 GB, described on the IONext GPU page.

For the pilot-to-production phase, IONext can hand over:

• The ISO/IEC 27001:2022 certificate from TÜV NORD (number 01 07 E 26000410), which an SI can attach to sub-processor documents. Details are on the IONext security and compliance page.
• Separate projects and environments for staging and production in ORBIT, along with snapshot and restore from the same workspace. IONA reads signals from running workloads and explains what they mean, while decisions stay with the team. How this works is covered in the production signals IONA reads.
• Billing in Rupiah through an Indonesian legal entity, PT Data Awan Nusantara.

Some things are not part of IONext's role: application architecture, model selection, the client relationship, and first-line support to the client. Those remain the SI's role. IONext also does not replace the client's DPIA or legal decisions as the personal data controller. Domestic infrastructure simplifies the question of cross-border data transfer, but it does not automatically make a project compliant with the PDP Law.

Preparing a go-live for a client in a regulated sector? Build the production readiness review with IONext through the Partner Program, or try ORBIT and IONA directly through self-service sign-up on the IONext console.

Frequently asked questions

When should a production readiness review be held? About two weeks before go-live. That is enough time to run a restore test, fix the alert matrix, and get the client's written approval of sub-processors. If it is held a day before go-live, any finding tends to be postponed and rarely gets done.

Are pilot load test results enough for production sizing? Usually not. A pilot rarely mirrors production transaction patterns, document lengths, or user counts. Repeat the load test in staging with a pattern close to production, then agree on a scale-up plan with the infrastructure provider.

Does a GPU provider need to be recorded as a sub-processor? If the provider's infrastructure processes the client's personal data on the SI's behalf, the provider acts as a sub-processor. The appointment requires written approval from the client as controller, and it should be recorded before go-live.

Who is responsible if an incident happens at the GPU layer? The infrastructure provider handles and reports incidents at its layer to the SI, and the SI passes them on to the client. The client, as controller, decides on notifying data subjects and the authority, within 3 x 24 hours under Article 46 of the PDP Law. The deadlines between parties should be written into the contract and the runbook.

Sources

• Law No. 27 of 2022 on Personal Data Protection, Article 46 (in Indonesian)
• PwC Indonesia, "Government Regulation 33/2026 on Personal Data Protection: key changes and action points", October 2026
• RSM Indonesia, "PP 33/2026: Six Implementation Priorities before 16 January 2027", September 2026
• OJK, Abstract of PADK OJK No. 1 of 2026 on Information Technology Implementation by Commercial Banks (in Indonesian)
• Who Owns What: Splitting Roles Between System Integrators and AI Infrastructure Providers in Indonesia
• PP 33/2026: What It Means for AI Projects
• After Go-Live: The Signals IONA Reads in Production, and Who Acts on Them
• IONext Security and Compliance

This article is general information, not legal advice. For compliance needs, 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.