Sovereign AI through the K-EXAONE Case — The Data Engine Comes Before the Model

Related articles — LLM Datasets · How LLMs Are Trained · Sovereign AI in South Korea

A community post recently claimed that a prompt injection exposed what appeared to be an internal skill in K-EXAONE's hosted service. The author found wording resembling a particular problem in a skill that seemed to handle common-sense questions and riddles, and said that changing a number in the problem destabilized the answer. A commenter supplied a counterexample that produced consistent answers with other numbers. Because the observation did not control the experiment date, service version, session, or inference settings, it alone cannot establish training-data contamination or evaluation manipulation.

On August 10, 2026, when I prepared this article, I could not reproduce the old output with the same kind of query. Public information does not tell us whether the service was patched, the model replaced, or an input filter added. More importantly, a hosted service's answer is not produced by model weights alone. Input filters, routers, system prompts, retrieval, tools, and output post-processing can all intervene.

The important question raised by the case is therefore not “who cheated?” It is closer to this: can we distinguish a model's generalization ability from service optimization tailored to a public exam? That question leads beyond one company's ethics to what outcomes a country chooses to measure and reward.

When a Public Score Becomes the Reward Function

Benchmarks are necessary. Quantitative metrics are needed to compare models under the same conditions and explain the results of public investment. Problems arise when the questions and evaluation method are widely known and the resulting score directly determines advancement and future support. A benchmark that began as a measurement tool becomes a reward function steering development.

The government's first-stage evaluation for its independent AI Foundation Model project assigned 40 points to benchmarks, 35 to expert evaluation, and 25 to user evaluation. Selection was not based on benchmarks alone: experts reviewed technical reports and training logs, while professional users assessed usability and inference-cost efficiency. Even so, the 40-point benchmark was the largest single component. When a team's survival is at stake, aligning post-training data, prompts, decoding, and the evaluation harness with public problem families becomes an entirely rational choice.

We should not assume that the second evaluation in August 2026 uses exactly the same numbers. The Ministry of Science and ICT and NIPA separately recruited a public evaluation panel, and user evaluation was underway from August 8 to 11 when this article was published. That is why no final result or ranking should be presumed in advance.

What the country actually wants is some combination of novel problem solving, an understanding of Korean language and context, reliability, cost efficiency, deployability, and continuous improvement. What a program can measure easily, however, is a public benchmark score under a fixed evaluation format. When the proxy captures only part of the real goal but an institution's survival depends on it, resources move toward whatever can be measured.

A public benchmark should be a thermometer that measures capability. Once survival depends on it, it becomes a thermostat that directs development.

The Boundary between Exam Preparation and Research

Training on data similar to public questions is not automatically cheating. More mathematics data is normal post-training for a model meant to solve mathematics, just as tool-use trajectories are normal preparation for tool-use evaluation. What matters is whether we can identify where the score came from.

GSM-Symbolic analyzes how model performance can shift when names and numbers in math problems change or irrelevant conditions are added. One study cannot settle every limit of reasoning, but its motivation is sound: evaluation should include procedurally generated variants alongside static originals. LiveBench and LiveCodeBench continually add recent questions to reduce contamination from long-public tests.

A better evaluation places private and rotating questions, altered numbers and conditions, and task success from real work next to the public score. Models should run in an independent environment controlled by the evaluator, with the system prompt, RAG and tool usage, and inference parameters recorded. A good benchmark resembles a sensor for discovering failure more than an exam sheet for producing a ranking.

Models Overfit to Exams and Data Overfit to Deliverables

Data is the more persistent bottleneck. Even an excellent architecture cannot reconstruct Korean field knowledge and long-tail cases that do not exist in its sources. With the same raw web data, changing what is extracted, which documents are discarded, the unit of deduplication, and the domain mixture produces a different model.

DataComp-LM was designed to compare data-curation strategies while holding the model and training code fixed. FineWeb experimentally discloses choices in text extraction, filtering, and deduplication from Common Crawl. Data cleaning is not pre-training chores; it is a research variable determining performance and compute efficiency. The K-EXAONE technical report likewise describes a 236B-total, 23B-active MoE model together with tokenizer redesign, multi-stage pre-training, data filtering and synthesis, SFT, and reinforcement learning. We can recognize those achievements while separately asking how long-term data assets are rewarded.

Just as a public score becomes the proxy target of a model program, dataset counts and completed delivery easily become the proxy target of a data program. A model overfit to an exam and data overfit to delivery specifications are two faces of the same structure. One produces accuracy and the other file counts, but neither guarantees reusable capability in a new situation.

When Do AI Hub Files Become Assets?

The scope of audit findings needs to be stated accurately. According to reporting based on the Board of Audit and Inspection's audit of intelligent-information projects, the investigation covered 360 datasets built in 2020–2021. Of these, 122 datasets representing KRW 114.8 billion did not see planned use because they were underbuilt relative to their goals or remained unloaded and unavailable for long periods. Another 168 were separately reported as failing their stated quality goals. These numbers should not be expanded into a claim that today's entire AI Hub is useless.

“Difficult to train on” is broader than the accuracy of a sample's label. Files can be corrupted or disagree with their documentation; train and test sets can overlap; label definitions can be ambiguous; and the long tail of the real service distribution may be missing. If provenance, consent and rights, and the relationship between originals and derivatives cannot be traced per sample, researchers have to audit the data again before they can train a model.

The AI Hub usage policy restricts unauthorized transfer, overseas export, and re-identification to protect personal information and third-party rights. These safeguards are necessary. But without an official patch path that feeds corrected errors and cleaning code back into the canonical version, every institution repeats the same cleanup. This is not an argument to remove redistribution restrictions. It is an argument for an official channel through which error reports, proposed corrections, verification, and new releases can continue even over restricted raw data.

The government and NIA have not ignored the problem. AI Hub published its Data Quality Management Guidelines v4.0 in 2026 and is conducting an upcycling program that reprocesses existing datasets for generative and reasoning AI. What matters is preventing these improvements from ending as yet another delivery, and instead feeding real model failures into the next data version.

Operate a Data Engine, Not a Dataset Delivery

A one-off dataset is a fixed bundle of files. A data engine is an operating system in which new sources arrive, rights and privacy are checked, data is cleaned and deduplicated, models are trained, and failures are collected and corrected again. The difference lies in the cycle, not the scale.

Such an engine needs a catalog to locate data and owners, lineage recording collection and processing, and a rights ledger describing permitted purposes. It also needs PII and harmful-content detection with a human review queue, exact and near deduplication, train-test leakage checks, and versioned manifests. Finally, model failures must be classified as missing knowledge, instruction failure, retrieval failure, or tool error and routed back to the appropriate data stage.

One Researcher Cannot Own the Entire Supply Chain

In many organizations, a researcher locates raw data, obtains access, converts files, removes corruption, and checks duplicates and labels—while also writing training code, evaluating the model, and building the demo. Researchers need to understand their data, but requiring each one to recreate copyright, PII, and common cleaning pipelines is a different matter. When a project ends or the owner moves, its decision criteria and processing code often disappear as well.

Internal data is not automatically trainable merely because it sits in a company repository. Broadcasters and media companies possess assets difficult to find on the public web: broadcast and clean masters, scripts, subtitles and timecodes, edit histories, and corrected multilingual translations. They also face third-party production copyright; performer, likeness, and voice rights; music and archival-footage rights; privacy; and the original purpose of collection.

“Copyright-cleared internal data” should therefore mean more than company possession. Training purpose, territory and term, commercial use and redistribution, and deletion procedures must be verified and tracked with the data. This is not solved by one researcher's regular expression, but by an organizational capability jointly operated by data engineers, curators, legal counsel, and privacy specialists.

Do Open Weights Help or Become a Crutch?

Using an overseas open-weight model is not itself a failure of sovereign AI. Pre-training a general-purpose model from scratch is inefficient for many companies; building Korean and domain data and independent evaluation on a proven base model can be far more rational. Strategic use of Open Source must be distinguished from structural dependence.

Using an external model is not dependence. Dependence is the state in which we cannot improve unless an external model improves first. Conversely, an open-weight model originating overseas may offer substantial operational sovereignty if it can be self-hosted locally, its data and deployment controlled, and the model replaced. Calling it an independently pre-trained Foundation Model remains a separate claim.

Redefining Sovereign AI

Model nationality alone leaves out important layers.

Under this definition, independence is less a past event—having once trained weights from random initialization—than a future capability to build the next model again. It is not autarky without external technology, but control over core data and evaluation criteria and the option to change suppliers when necessary.

What Outcome Should the State Purchase?

This is not an argument to reduce investment in sovereign AI. It asks what the same money should leave behind. When policy KPIs change, so does what participating institutions optimize.

1. Report performance on originals together with private, rotating, and procedural variants.
2. Hold the model and training budget fixed and measure how much new data improves downstream tasks.
3. Confirm whether other institutions actually reproduced training and evaluation.
4. Evaluate time from error report to official patch, the share of samples with complete provenance, and release history.
5. Reserve part of construction funding for three to five years of revalidation, rights renewal, patches, and independent data audits.
6. Require disclosure of failed subgroups and domains and how they will change the next dataset.

Model weights matter. The large-scale training and systems experience accumulated by K-EXAONE and other Korean models should not be dismissed. But weights are one output produced at a particular moment by a cycle of data, training, and evaluation. If the cycle does not survive, the next generation must find the raw material and repeat the same cleaning.

The success of Korean sovereign AI should not be judged by whether it built the largest model once. It should be judged by whether it left an engine in which discovered errors are corrected, new domains are collected, and model failures return to the training data. The state should purchase not a few points on this evaluation, but the repeatable capability to build the next model better.