Korea wants civil servants to turn prompt-built tools into public infrastructure. Test the handoff

THE SIGNAL IN ONE SENTENCE

South Korea has a lot of civil servants building little AI tools. Now the government wants the useful ones to grow up. On October 21, the Ministry of the Interior and Safety announced the 2026 Public AI Transformation Challenge. Entries close November 11. Finalists will demonstrate their tools on November 25 at the Government Innovation Expo at KINTEX in Goyang. The ministry says 1,086 projects had been registered in its AI Government Laboratory public repository by October 8, with more than 2,700 people participating. Most of those projects, it says, remain personal experiments. That last sentence is the story. It is easy to celebrate 1,086 prototypes. It is harder to make one answerable to a public institution. A civil servant can know exactly where a workflow hurts. They can know which form gets copied three times, which regulation sends everyone searching through old folders and which handoff falls apart when a colleague changes jobs. Generative AI and conversational coding can help that person build a rough tool without waiting for a traditional software project to arrive from orbit. That is useful. It is also the beginning, not the finish. The plain signal is this: test the handoff from the person who made the tool to the institution expected to run it. The challenge has three tracks. The AI Government Laboratory Championship accepts tools aimed at improving public services, making administrative work more efficient or addressing social problems. The ministry says there is no restriction on the form of the result. The AI Mission track focuses on three assigned problems: a work handoff tool, an administrative secretary and an agent for enacting or revising regulations. The Independent AI Agent track asks participants to build work agents with prompts and no coding, using a domestically developed AI service available on the ministry's administrative network. Central and local government officials and employees of public institutions may enter. The ministry plans 23 awards, including presidential, prime ministerial and ministerial awards, with total prize money of 17.2 million won. The government also says it intends to support the institutionalization of winning projects as public goods that can be used across government. That phrase, used across government, changes the job. A personal prototype can depend on the creator remembering which spreadsheet to upload, which prompt to avoid and which answer looks suspicious. A shared public service cannot. The prototype may live in one person's account. It may use sample data that behaves politely. Its instructions may exist in a chat history. Its error handling may be a sticky note that says, more or less, do not click that twice. Public infrastructure needs a named owner, supported data, permissions, logs, accessibility, records handling, incident response, a correction path and a safe way to stop. That list is analysis, not a claim that the ministry has already imposed this exact checklist. The announcement describes the competition and the ambition to move winning work into institutional use. It does not publish a production-readiness standard for the winners. So here is a practical one. First, name the service owner. The builder is not automatically the long-term owner. A tool needs an office responsible for funding, access, updates, complaints and retirement. It also needs a technical operator who can see whether the service is healthy and a policy owner who can decide what it is allowed to do. If the answer to who owns this is the name of one enthusiastic employee, the tool is still a project. Second, map the decision boundary. What may the tool recommend? What may it draft? What may it send? What may it change in an official system? Which actions require a person to approve them? Which actions are forbidden? This matters for every track, but especially for a regulation agent. Helping a civil servant find relevant rules is different from drafting an amendment. Drafting is different from publishing. Publishing is different from changing a person's rights, duties or eligibility. The interface should make those boundaries visible. A reviewer should not have to guess whether a button creates a suggestion or performs an official act. Third, inventory the data. List every source the tool reads, every field it sends to a model and every place the result is stored. Separate public information from internal records and personal data. Record retention rules, access permissions and deletion behavior before a popular prototype becomes an unofficial archive. A prompt-built tool can feel lightweight because the interface is small. The data path may be anything but. Fourth, test the ordinary failure. Do not begin with a theatrical supervillain prompt. Begin with the boring mistakes that ruin public services. Give the tool an outdated regulation. Remove a required attachment. Use a person's name with unusual spacing. Submit the same request twice. Switch languages halfway through. Ask a question the tool cannot answer. Let the network fail after the user presses submit. Then watch what happens. Does the tool invent a completion? Does it lose the record? Does it create two cases? Does it expose internal instructions? Does it clearly say that a person needs to take over? Fifth, test accessibility and explanation. A service used across government has to work for more than the people who built it. Test keyboard navigation, screen readers, contrast, plain language, mobile layouts and assisted-service paths. Test whether an employee can explain the result to a citizen without reciting model jargon. An answer is not operationally useful when only the prototype team understands what it means. Sixth, preserve the record. For consequential work, keep the request, relevant source material, model and prompt version, retrieved evidence, generated output, human edits, approval and final action. The purpose is not to collect everything forever. The purpose is to preserve the evidence required by the actual administrative process. The right record lets a reviewer answer a basic question later: what did the system contribute, and what did the responsible person decide? Seventh, rehearse appeal and shutdown. A person affected by a bad result needs a route to challenge it. Staff need a route to correct the record. Operators need a kill switch that stops new automated actions without destroying the evidence needed to investigate. Shutdown is not failure. Sometimes it is the feature that keeps a failure small. The challenge's own mission categories make these tests concrete. Consider the work handoff tool. The best demo may summarize open tasks and transfer context to a new employee. The real test is whether it distinguishes facts from guesses, respects permissions, identifies missing records and lets the outgoing and incoming staff correct the handoff. Consider the administrative secretary. The best demo may organize documents, answer routine questions and draft messages. The real test is whether it can keep confidential material inside the right boundary, cite the source behind an answer and avoid sending something simply because a draft looks finished. Consider the regulation agent. The best demo may find related provisions and propose edits. The real test is whether it preserves the authoritative text, shows every source, distinguishes current law from a proposal and keeps a human accountable for the legal judgment. The independent-agent track adds another useful question: what does domestic mean at the service boundary? The ministry says participants will use a domestically developed independent AI available on its administrative network. That may address parts of the infrastructure and sovereignty question. It does not automatically answer which data was used to train the model, where every runtime component operates, how updates are approved or how agencies measure errors. Those details belong in a service card for any winning system. The card should name the model and version, hosting environment, data categories, allowed tasks, prohibited tasks, human reviewer, evaluation results, monitoring owner, update policy, appeal route and retirement date. Yes, retirement date. Public software has a habit of becoming permanent five minutes after someone calls it a pilot. A service should begin with a review date and a condition for renewal. If nobody owns the next evaluation, the expiration clock should not be decorative. The competition can make one smart choice right away: judge the handoff, not only the demo. Give finalists a clean environment and ask someone other than the creator to deploy the tool from its documentation. Ask a second team to operate it for a day. Ask a reviewer to reproduce one output from the saved evidence. Ask a public-service employee who did not attend the build session to find the correction path. Ask the team to stop the system and restore it. Score what transfers. That would reward a different kind of excellence. The clever prompt still matters. So does the worker who found the problem. But the winning artifact becomes more than a personal trick. It becomes a service another person can understand, challenge and maintain. South Korea's experiment is interesting beyond South Korea because governments everywhere have the same temptation. A staff member makes a useful tool on Friday. By Monday, ten colleagues want it. By next month, somebody calls it transformation. The gap between those moments is where public trust gets built or quietly spent. The ministry has correctly identified that personal experiments need an institutional path. The next useful document is the acceptance test for that path. Name the owner. Draw the decision boundary. Map the data. Test ordinary failure. Preserve the record. Rehearse appeal and shutdown. Then hand the service to someone who did not build it and see whether it survives. If it does, the prompt made a prototype. The handoff made infrastructure.