Commentary on public institution AI-ready data: Why it is necessary to fix the standards, metadata, and quality treatment loop before attaching an LLM

Publication date: 2026-05-19 | Category: Development information

Commentary on public institution AI-ready data: Why you need to fix the standards, metadata, and quality treatment loop before attaching an LLM

1) One-line problem definition

Key line: The bottleneck of AI adoption in public institutions is not model performance, but Making the data structures that differ from institution to institution into a state that AI can trust and use It is.

AI Times reported on May 19, 2026 that Woori Data launched Woori Data Clinic V1.0, which refines public data into a state that AI can immediately use. The important part of the article is not to promote a solution, but to raise the issue that public institution data should be treated differently from corporate data. Companies may push for a single internal standard, but public data involves multiple agencies, statutory standards, public services, open APIs, and evaluation metrics simultaneously.

This article explains how public agencies, local governments, public SI, data quality managers, and AI service developers can break down AI-ready data into actual work units. The scope is the database, metadata, code system, quality diagnosis, and improvement loop. On the contrary, this is not an article that only provides a decision to purchase a specific solution or a comparison table of vendor features.

2) Conclusion first

Key line: Rather than attaching a chatbot first, public institutions should first create Data Quality Treatment Loop

Organizations needed right now: Organizations that want to create search, civil service automation, policy analysis, and RAG by connecting databases of various departments and affiliated organizations
Still overstretched organization: Small team that only uses a few single Excel files for internal analysis
My judgment: AI-ready data is not “Let’s clean up the data”, but Operation that fixes standards, meaning, source, and quality score together to prevent AI from making wrong connections. The system is

So the first step is not LLM replacement. First, you need to backtrack the actual columns, codes, relationships, omissions, duplications, and recency in the physical DB, and separate those that require human review from those that can be automatically repaired. According to the AI Times article, Woori Data Clinic explained that 50-80% of the data subject to improvement can be treated fully automatically. This figure should not be generalized as is, but in practice, the key is to separatedefects that can be automatically remedied from those that require policy judgment

3) Core structure decomposition

Key line: AI-ready data is not just one data cleansing tool, but standards, metadata, quality rules, improvement history connected This is the structure.

3-1. Physical DB backtracking layer

Reverse engineering is a method of restoring design output by reading tables, columns, relationships, code systems, and constraints backwards from an already created physical DB. In places like public institutions that have older systems and multiple DBMSs, there is a high possibility that the documentation is out of date. So, rather than relying on the design document, you should start from the actual database.

3-2. Standard/code system hierarchy

Public data does not end only within the institution. If items with the same meaning exist under different names, different codes, and different date formats in different organizations, AI may misunderstand the differences as semantic differences. For example, whether address, location, and Business location are the same concept or different concepts must be explained with metadata.

3-3. Quality Diagnosis/Treatment Tier

IBM describes data quality dimensions as accuracy, completeness, validity, consistency, uniqueness, timeliness, and fitness for purpose. AI-ready work in public institutions must also translate these standards into practical language. Missing values are a completeness issue, values that do not match statutory codes are a validity issue, and using the same organization name in multiple ways is a consistency issue.

3-4. Evaluation/Evidence Tier

It is not enough for public institutions to simply say that they have improved quality. The quality management manual of the public data portal also emphasizes quality management activities and diagnosis and improvement procedures in the planning, construction, operation, and utilization stages. Even in the introduction of AI, what rules were diagnosed, what was automatically corrected, and what was approved by humans must remain as evidence.

4) Explanation of design intent

Key line: Public data quality management is not a data cleansing task, but creating inter-agency trust agreements

Corporate data usually moves toward one business goal. Like CRM, ERP, and order DB, the owner and KPI are relatively clear. On the other hand, public data is simultaneously open, administrative processing, statistics, civil complaints, policy-making, and AI learning. If there are multiple purposes, the standard for “useable data” also becomes unstable.

So, in public institutions, post-diagnosis alone is not enough. In order for AI to be able to connect and use, standard names, codes, metadata, and quality rules must be designed together from the new DB construction stage. For DBs that are already in operation, you must first identify the current status through backtracking and separate errors that can be automatically corrected from those that require system/business judgment.

My interpretation is this. The real competitor of AI-ready data is not a better chatbot, but manual work in Excel, temporary codes for each department, and operating habits where documents and DB are played separately . If you do not change this habit, your answer will be plausible even if you add RAG, but the evidence will be weak.

5) Evidence and comparison

Key line: Public institutions should be compared with Has AI created a quality contract that can be reused rather than “whether it has been refined?”

Approach	Strengths	Limit	Recommendation status
Manual refining + Excel management	Quick to start, suitable for small datasets	Traceability and reproducibility are weak and standardization between institutions is difficult	One-time report, short-term analysis
Post Quality Diagnosis Tool	Quickly spot omissions, duplications, and formatting errors	If the connection between problem prescription and automatic improvement and output is weak, recurring costs remain	Existing DB quality check
Reverse engineering-based AI-ready data loop	Restore design output from physics DB and connect standards, quality, and improvement history	It is necessary to set the initial diagnosis scope and adjust exceptions by institution	Multiple agency data linkage, RAG, policy analysis, public AI service

The AI Times article explains that data from over 700 public institutions are related, and that Woori Data Clinic supports 13 types of DBMS, including Oracle, Tibero, Microsoft SQL Server, MariaDB, DB2, and HanaDB, and provides an automatic generation function for 16 types of required output. The point of these numbers is not that there are many features, but that the public data quality problem is not a single DB problem, but a heterogeneous environment and administrative evidence problem

GOV.UK's Government Data Quality Framework also explains that government data quality work should be proactive, evidence-based and targeted. In other words, public data quality is not a “one-time cleaning” but an ongoing operation.

6) Actual operation flow / step-by-step execution method

Key line: AI-ready data projects should start with Data Asset Diagnostic Table, not model PoC.

Narrow down the target task to one.
Example: First decide the questions that AI needs to answer, such as civil complaint FAQ RAG, welfare project duplication review, facility inspection history search.
List the connected DBs and files.
Enter DBMS, number of tables, owning department, latest update date, whether disclosed externally, and whether personal information is included.
Extract metadata from the physical DB.
Extract column name, data type, PK/FK candidate, code value, null rate, duplication rate, and date range.
Divide quality rules into seven dimensions.
Create rules based on completeness, uniqueness, validity, timeliness, accuracy, consistency, and fitness for purpose.
Separate automatic remediation from authorized remediation.
Removing spaces, unifying date formats, and explicit code mapping can be automated. However, changes to legal codes, merging of institution names, and standards for de-identifying personal information must be approved by the person in charge.
Create a test set before deploying AI.
30 representative questions, rows or documents based on the answers, and define the range of acceptable answers.
Fix your operational metrics.
Example: null rate <5%, unmapped code <1%, freshness SLA 24 hours, 0 unsourced AI answers.

#Example: Draft AI-Ready Data Diagnostic Rules
checks:
  completeness:
Resident registration address: null_rate < 0.01
  validity:
Legal equivalent code: match_reference_table == true
  consistency:
Organization name: canonical_name_mapping_required == true
  timeliness:
Facility inspection days: max_age_days <= 30
  ai_grounding:
    rag_answer: source_row_or_document_required == true

7) Mistakes/Pitfalls

Key line: When AI-ready data projects start with “data cleaning,” they often get tangled up again.

Mistake 1: Trusting that LLM will automatically infer the column meaning
Prevention: Attach column descriptions, code tables, and task definitions as metadata.
Recovery: Collect cases of AI answer errors. Re-enforce which column meaning is missing.
Mistake 2: Using only the autocorrection rate as a KPI
Prevention: Look at the number of cases waiting for approval, relapse rate, and source linking rate along with the autocure rate.
Recovery: Check the automatic cure rate for Audit samples and exclude from rules any items that require policy judgment.
Mistake 3: Viewing agency-specific exceptions only as standardization failures
Prevention: Separate exceptions that are legally or business-necessary from simple inertial exceptions.
Recovery: Identify the reason for the exception, the person in charge, and the expiration date. Please make sure it doesn't become a permanent exception.
Mistake 4: Separating quality check results from AI evaluation
Prevention: Record data quality scores along with RAG answer evaluation
Recovery: Review the supporting data before blaming a wrong answer on the model. Check for freshness, code mapping, and duplication first.

8) Strengths and limitations

Key line: AI-ready data loops increase trust in public AI, but they do not automatically solve all quality issues.

Strengths

Data errors can be structurally reduced before LLM introduction.
In inter-institutional data linkage, items with the same meaning can be aligned more reliably.
Quality diagnosis, improvement, deliverables, and AI response evidence can be grouped into one audit flow.

Limit

If the task definition is unclear, the tool cannot fully resolve column meaning.
Older systems may have weak DB constraints or have different actual structures than documents.
Personal information, security level, and disclosure scope require policy decisions, not automatic treatment.

Counterexample: For small datasets used by a single department for internal statistics, simple data profiling and manual inspection are more economical than huge AI-ready projects. However, if it is a connection between institutions or an AI service for citizens, it is dangerous to immediately attach an LLM without a quality loop.

9) Points to study more deeply

Key line: Your next training should start with data quality dimensions and public metadata standards rather than the model prompt.

Planning, construction, operation, and utilization stages of public data quality management manual
Differences in accuracy, completeness, validity, consistency, uniqueness, timeliness, and fitness for purpose
How to restore ERD, code table, and column dictionary through DB reverse engineering
How to view answer accuracy and supporting data quality together in RAG evaluation
How to use non-identification of personal information, disclosure level, and data freshness SLA as AI service requirements

10) Execution Checklist + Author’s Perspective

Key line: The first deliverable of a public AI project should be Data Quality Agreement, not a chatbot screen.

Have you decided on 30 business questions that AI must answer and the basis for the answers?
Have you recorded the ownership department, update cycle, and public level of the target DB/file/API?
Are the column dictionary, code table, standard name, and exception reason up to date?
Have the quality rules been divided into completeness, uniqueness, validity, timeliness, accuracy, consistency, and fitness for purpose?
Have you separated errors that can be automatically repaired from errors that require approval from a person in charge?
Do you leave a source line, document, and update date for each AI answer?
Is there a gate that stops AI service deployment when the quality score drops?

Definition of Done: Once the representative questions for a business area, data asset list, quality rules, automated/approval treatment criteria, and AI answer basis tracking are connected to documents and dashboards, the primary operational standard for AI-ready data has been established.

My recommendation: Before demonstrating AI services, public institutions must first make the data quality loop to a publicly available level. The standard of trust is not “our data went into AI,” but “when AI responds, it can explain what data quality standards it passed.” On the other hand, if the data range is small and the experiment is internal, it is better to start with profiling, code table organization, and RAG test sets rather than investing in a large solution from the beginning.