Diagnose

Data integration before AI: lessons from Indonesia's GovTech push

National GovTech connected cross-agency data before AI. Five integration lessons—Diagnose, APIs, quality gates, human oversight, Operate—for your organisation.

Tim MarkasDevTechnology Partner, Jakarta
1 October 2026 · 7 min read
Abstract illustration of two clusters of digital nodes linked to a central hub, symbolising cross-system data integration before AI

In June 2026, National Economic Council Chair Luhut Binsar Pandjaitan reported to President Prabowo that about 80 percent of the GovTech systems used to digitise social-assistance management were already connected, and that since 1 June 2026 data from eight ministries and major institutions had been integrated in an AI-supported system—as published by the Cabinet Secretariat. Pilots were running in 42 provinces, regencies, and cities, with a stated path toward national rollout.

For operations leaders in local government, regional SOEs, healthcare facilities, local finance institutions, and firms that serve the public sector, those headlines are easy to misread as “time to buy AI”. A safer reading: AI only helps when systems can exchange data, identities can be matched, and humans still own decisions that affect people’s rights. Without an integration foundation, a model simply accelerates mess.

AI does not replace data-integration work—it exposes how fragile or solid that foundation already is.

This article translates public lessons from Indonesia’s GovTech push and the government’s AI policy direction into the Diagnose, Deliver, and Operate frame. It is not a claim that MarkasDev participated in the national programme, and it is not legal advice; it is a practical way to read public signals before you lock a technology budget.

Why data integration comes before AI

National GovTech is described as reusing existing digital ecosystems rather than rebuilding everything from scratch. The same Setkab briefing notes that development leverages ecosystems already in place and is built by Indonesian talent. Non-central organisations can borrow that pattern: before purchasing a model or chatbot, map the systems you already run, the API contracts you own, and who is accountable for each dataset.

On the SPBE policy side, technical requirements for application development already stress accurate, up-to-date, integrated data and interoperability through application programming interfaces (APIs), aligned with Satu Data Indonesia—see the technical standards summarised via JDIH Komdigi. Simply put: an application that cannot exchange data safely will struggle to support trustworthy AI.

Komdigi is also preparing a Presidential Regulation on the 2026–2029 National AI Roadmap and a separate regulation on AI ethics. According to GovInsider, agencies will need to identify risks, protect data, ensure accountability, and keep human oversight—especially when AI is used in public services that affect people’s rights or access. Three tracks must move together: literacy and talent, infrastructure and data, and risk-based ethics and governance guidance.

Five operational lessons from the GovTech wave

1. Connect the right sources first, then optimise the model

The Setkab report emphasises cross-ministry integration before the narrative that “AI cleans the data”. In your organisation, that means inventorying sources of truth (master data), who may write to them, and how conflicts are resolved. Without those rules, an AI pipeline will automate conflicting IDs, addresses, or service statuses.

In Diagnose, write down the system map, data classification (including personal data), and integration assumptions before a model budget is locked. If scope is still fuzzy, see also when a paid Diagnose makes sense.

2. Treat API and interface contracts as deliverables, not footnotes

SPBE interoperability expectations include exchanging data through APIs and protecting that data. In Deliver, treat endpoint documentation, schemas, authentication, rate limits, and contract tests as milestone acceptance criteria—not “later” work. System and API integration often decides whether AI can read operational data in near real time or only stale weekly spreadsheets.

3. Put data quality gates in front of inference

The OECD notes that early public-service AI failures have been linked to data-quality issues; providers need to keep verifying accuracy, reliability, and appropriateness of inputs (see OECD Governing with AI). Apply quality gates for completeness, identity consistency, timeliness, and rejection of records that fail checks—before data reaches a model. AI does not heal broken master data; it amplifies the blast radius.

4. Keep humans at the gate for high-impact decisions

Both the emerging AI Perpres direction and cyber-defence practice stress human-in-the-loop. Air Commodore Arwin Sumari, speaking to GovInsider, describes humans as the final safeguard for strategic decisions. For citizen-facing services—benefit eligibility, healthcare access, local credit decisions—write down when AI only recommends, when a human must review, and how appeals work.

That matches how MarkasDev approaches AI implementation: apply AI to processes you already run, with human oversight and careful data handling—not a standalone chatbot demo disconnected from core systems.

5. Design Operate for integration, not only for a single app

After go-live, risk shifts to schema drift, expired API keys, and cross-system monitoring. The reactive maintenance vs Operate distinction matters: Operate requires a service owner, SLAs, monitoring, and controlled change. Integration without an owner is technical debt that comes due the day an AI model depends on that feed every hour.

A short checklist before an AI project

  • Are sources of truth (master data) and write owners explicit?
  • Does every integration have an API contract, authentication, and regression tests?
  • Is there a quality gate before data is used for training or inference?
  • Do decisions that affect people’s rights have written human oversight?
  • Does Operate cover integration monitoring, key rotation, and a data-incident runbook?
  • Are personal-data classifications and incident-notification paths prepared (see also the PP 33/2026 countdown)?

How MarkasDev places this work

MarkasDev is a Technology Partner with three phases: clarify the problem and risk in Diagnose, build with written acceptance criteria in Deliver—including custom software and integration—then keep the system healthy under SLAs in Operate. For readers in government and regional SOEs, our sector context is summarised under Government & regional SOEs.

If you are weighing an AI project while data still lives in spreadsheets, application silos, or ownerless APIs, start with an integration map—not a model catalogue. To discuss scope without a large upfront commitment, visit the contact page.

Sources

Related questions

Must local organisations copy the national GovTech architecture?
Not automatically. What is worth borrowing is the sequence: connect and clean data, define API contracts, install quality gates, then scale AI. Central architecture can be a reference, not a mandatory template for every regional SOE or clinic.
When is Diagnose better than buying an AI platform immediately?
When the system map, data owners, and integration risks are not yet written down. Diagnose clarifies options and acceptance criteria before a large budget is locked—including whether the real problem is process, data, or model capacity.
How is API integration different from “connecting via Excel”?
Manual spreadsheets go stale, invite copy errors, and lack an audit trail. APIs with contracts, authentication, and monitoring give fresher data and access control—safer prerequisites for operational AI.