It Is Time to Build Verification Services for Tools Made by Public Servants

A government that starts by making small tools

On September 8, 2026, the Ministry of the Interior and Safety (행정안전부), the Korean ministry responsible for public administration, reported to the State Council on a plan for public servants to build work tools themselves using artificial intelligence. When a public servant spots repetitive work in the field, they can first create a prototype before using it in real work. If the tool proves effective, the institution reviews it and puts it into operation.

The starting point was the AI Government Lab (AI 정부 실험실), piloted in an internet-connected environment from July 3, 2026. Tools made by public servants can be uploaded to a shared repository called Public GitLab (공공 깃랩) and shared with other institutions.

As of September 3, 2026, 2,073 public servants had joined, 770 tools had been registered, and 376 tools had been made available to other public servants. This is not yet evidence of results from live services. It means that hundreds of small prototypes based on real work have already accumulated.

In a survey of 244 briefing-session attendees, 68% named a lack of development environments and subscriptions for AI tools as a barrier, 59% named difficulty applying security guidelines, and 40% named difficulty connecting data.

The Ministry of the Interior and Safety plans to prepare guidance in the second half of 2026 covering everything from identifying tasks through security, quality testing, registration, and real-world use. In 2027, it plans to allow experiments on the government’s internal work network and increase simultaneous capacity from about 200 people to 6,000. As of September 10, 2026, however, the detailed review items and approval process had not been finalized.

Getting permission to operate becomes harder than making the tool

To explain the work involved, imagine a local government officer who routes inquiries arriving at a county office’s main phone number to the right department. The officer notes the inquiry, checks the organization chart and division-of-work table, and calls several departments to confirm the responsible person when the boundary is unclear.

When department names or responsibilities change, the officer cannot keep using old guidance. While answering the same questions repeatedly, they must also decide how much of an inquiry containing personal information can be recorded and who should correct inaccurate guidance.

Now the officer can first build a prototype that finds the responsible department using only a public organization chart and frequently asked questions. A public servant can begin experimenting with and verifying a prototype without prior review or separate approval of a project plan.

But the work changes when the tool is released as a service for residents. To operate a public-facing service, an institution must verify accuracy, security, personal-data protection, and operational accountability.

Human work remains. An officer should handle inquiries for which several departments share responsibility, decisions that affect a resident’s rights or eligibility for support, and conversations with angry complainants. It is more realistic for AI to show candidate answers and supporting documents while a person gives the final guidance and handles exceptions.

This creates room for private-sector services beyond simply building tools on behalf of institutions. There is a longer-term need for services that package the personal-data inventory, tests of incorrect answers, the person responsible for fixes, and the shutdown method needed to move a prototype into real work.

Anyone can copy the wording of a checklist. What is harder to copy is each institution’s approval and rejection records, recurring error cases, trust built with security and personal-data staff, and a route for transferring verified tools to other institutions. That is why a service should begin by accumulating these records and relationships rather than by offering many features from day one.

Elsewhere, the controls came before more toolmaking

FormSG, operated by the Government Technology Agency of Singapore, lets public servants create surveys, application forms, and reporting forms directly with a mouse. It is a digital-form creation service for government agencies. It provides government-account sign-in and response encryption as shared functions.

The Government Technology Agency says that more than 160 agencies have used it and that more than 900,000 forms have been created. These are figures reported by the operating organization, and per-agency fees have not been disclosed. The key point is that individual departments do not need to build security and sign-in separately.

CiviForm, launched by the City of Seattle in the United States in 2021, lets public servants create applications for welfare and discount programmes themselves. Residents can reuse basic information they entered once across several applications. The base programme is openly available at no cost, although installation and operational support may involve separate costs.

Seattle says it has received more than 50,000 applications and reduced average application time from 30 minutes to seven minutes. These are figures reported by the operating organization. More difficult to replicate than the creation tool itself is the way it enables multiple welfare departments to trust and reuse the same application information.

The UK Department for Environment, Food & Rural Affairs lets frontline staff make small internal tools quickly, while passing important or complex tools to specialists. Creators assess and register the risk level of their solutions themselves. A central organization continues to monitor the tools and automated workflows that have been created.

The department said that about 50 staff-made apps and about 1,100 automated workflows were operating in 2023, and announced that its maker community had grown to more than 1,789 people in 2024. These are self-reported figures, and the usage fees for the underlying product have not been disclosed. Still, its approach of separating paths by risk rather than reviewing every tool with the same intensity is worth studying.

Four things you can build now

1. A pre-launch safety-check record assistant
This service takes a tool’s purpose, users, input data, and test results, then produces a review record for institutional submission. It is used jointly by an officer who built an event-registration tool for a public library and the city hall staff responsible for personal data and security who must approve it.

It can start now because each institution needs to define its record format before the second-half guidance and the 2027 review system take shape. Put three questions on the first screen: “Who will use it?”, “What information does it collect?”, and “Who could be harmed if it is wrong?”

2. A sharing space for moving verified tools to other institutions
This service helps an institution take a tool approved elsewhere, change its department names, work rules, and responsible staff, and test it again. It is for a safety officer at a small county office who wants to bring in a disaster-guidance tool used by a nearby city or county.

With 376 tools already publicly available, the challenge is likely to become safe adaptation rather than building from scratch. On the first screen, show “Tool to bring in” beside “What changes at our institution.”

3. An intake tool that hands resident inquiries to people
For inquiries that can be answered from public documents, the tool drafts a response. When personal information is involved or the answer is unclear, it passes the original inquiry to a responsible staff member. It is for staff at a district office’s civil-complaints desk who handle both main phone-line and website inquiries.

Because institutions must take responsibility for accuracy and operations in real public guidance, the ability to stop and hand off is now more important than a tool that answers everything. The first screen should divide the inbox into “Can answer now,” “Needs human review,” and “Contains personal information.”

4. A small-tool creation assistant for public institutions
After a user selects one of four tasks—repetitive documents, application intake, internal search, or field inspection—the service lets them combine only approved components to make a prototype. It is for a public museum employee who wants to digitize venue-rental applications but cannot maintain a dedicated developer.

The briefing-session survey found that development environments and subscription costs were the biggest obstacle. That suggests demand may emerge for a shared creation environment where individuals do not need to purchase paid tools themselves. Put four large buttons for selecting the task on the first screen, along with the question, “Will you collect personal information?”

What to check in 30 minutes today

Open 10 public tools in Public GitLab and check whether each one states its purpose, information that must not be entered, method for testing accuracy, and the person accountable for operations. If more than half are missing these records or use inconsistent formats, the pre-launch safety-check record service is worth testing first. If most are well organized, narrow the direction to a service for moving verified tools between institutions.

Why this matters where you are

Check whether people in your own public institutions can already create small work tools, and what records they need before those tools can be used with residents or sensitive information. The approval rules, responsible agencies, and available shared infrastructure will differ by market. The practical opportunity is to identify the handoff between a working prototype and accountable operation, then build for the records, review, and transfer work at that point.