Korea needs a clearer definition of AI expertise

Picture

Member for

1 year 10 months

Real name

Gordon Institute Policy Forum Editor

Bio

Gordon Institute Policy Forum Editor

Input

Sep 4, 2026 09:43

Modified

Sep 7, 2026 06:55

Korea’s AI labor market often combines software delivery, model development, domain integration, and supervision under one title.
These roles require different evidence because they carry different forms of responsibility for data, inference, and decisions.
A clearer occupational taxonomy would improve education policy, recruitment, procurement, and professional accountability.

A Title That Conceals the Production System

Korean employers and training providers frequently use ‘AI expert’ for people performing very different work. The category may include an application developer connecting an API, a data engineer maintaining pipelines, a scientist formulating models, a domain specialist validating outputs, or a manager accountable for an automated decision. The OECD’s Artificial Intelligence and the Labour Market in Korea shows why occupational change must be studied at the task level rather than inferred from broad job labels.

The ambiguity was tolerable when adoption itself was scarce. It becomes costly once AI is embedded in operating systems. A firm that needs model-risk supervision may recruit for software credentials. A university may count every programming graduate toward a national AI target. A procurement process may evaluate whether a system functions while no participant owns the validity of the prediction.

A serious definition should begin with responsibility: what claim can this person make, what failure can this person detect, and what decision can this person authorize?

A Necessary Distinction

Artificial intelligence is implemented in software. It does not follow that AI is a branch of software development.

Traditional software transforms inputs according to rules written by a developer. If a tax calculator is given the same inputs and the same rules, it should return the same result. Its central quality question is whether the implementation conforms to its specification.

An AI system is different. Part of its behavior is inferred from data. Its effective specification is distributed across a dataset, a model class, an objective function, an optimization procedure, a deployment environment, and a decision rule. Even flawless code can implement a poor statistical model, learn from an unrepresentative sample, optimize the wrong target, or produce decisions that alter the future data it receives.

Let a conventional program be written as

$$ y=P(x;r), $$

where $r$ is an explicit set of rules. An AI system is better represented as

\widehat f = \mathcal{A} \left( \mathcal{D}, \mathcal{M}, \ell, \lambda, s \right), \qquad \widehat y=\widehat f(x),

where $\mathcal{D}$ is training data, $\mathcal{M}$ a model class, $\ell$ a loss function, $\lambda$ a collection of regularization or tuning choices, and $s$ the stochastic state of training.

The program executes $\mathcal A$, but the behavior of $\widehat f$ is not written line by line. It is learned under assumptions about how $\mathcal D$ relates to the environment in which the model will operate.

Correct Code and Correct Inference

The difference can be summarized through two forms of correctness.

Software testing remains essential. An incorrectly indexed tensor or a leakage-prone preprocessing step can invalidate a model. But unit tests answer only whether the implementation behaves as designed. They cannot determine whether the design itself represents the relevant world.

Suppose a medical classifier is internally correct and achieves high validation accuracy. It can still fail if its training sample contains patients from one hospital, its target label reflects a local diagnostic practice, or its deployment changes which patients receive further testing. None of these is necessarily a coding error.

The central AI question is therefore not:

Does the program run?

It is:

Under which data-generating conditions does this program produce a decision we should trust?

The Five Layers of AI Failure

A useful educational framework separates system loss into five layers:

\mathcal{L}_{\mathrm{system}} = \mathcal{L}_{\mathrm{code}} + \mathcal{L}_{\mathrm{data}} + \mathcal{L}_{\mathrm{model}} + \mathcal{L}_{\mathrm{decision}} + \mathcal{L}_{\mathrm{feedback}}.

This is a diagnostic decomposition rather than a universal additive identity.

Read as a diagnostic rather than a second scorecard, the framework becomes clear: Code — Central question: Was the intended computation implemented correctly?; Example failure: Training and inference apply different transformations. Data — Central question: Do observations measure and represent the intended population?; Example failure: A label is a proxy generated by unequal access to service. Model — Central question: Does the model capture the relationship relevant to deployment?; Example failure: A stable correlation is mistaken for an invariant mechanism. Decision — Central question: Does the prediction support the correct action?; Example failure: Accuracy is optimized despite asymmetric costs. Feedback — Central question: Does using the model change its future data?; Example failure: A recommendation system makes displayed products appear preferable.

The distinction explains why adding developers cannot by itself solve an AI problem. More programmers may reduce $\mathcal L_{\mathrm{code}}$. They do not automatically reduce selection bias, identify a causal effect, select an appropriate loss function, or anticipate equilibrium responses to deployment.

Conversely, a mathematically sophisticated model is not sufficient. A model that cannot be implemented, monitored, secured, and maintained is not a useful AI system. The lesson is not that software engineering is unimportant. It is that AI requires software engineering plus several additional disciplines.

Data Are Executable Assumptions

In ordinary software, code determines behavior. In machine learning, data partly determine behavior. A change in data can function like a change in source code.

Let the training and deployment risks be

R_{\mathrm{train}}(f) = \mathbb{E}_{(X,Y)\sim P_{\mathrm{train}}} \left[\ell(Y,f(X))\right],

R_{\mathrm{deploy}}(f) = \mathbb{E}_{(X,Y)\sim P_{\mathrm{deploy}}} \left[\ell(Y,f(X))\right].

Empirical training makes $R_{\mathrm{train}}$ observable. Institutional value depends on $R_{\mathrm{deploy}}$. The two coincide only under assumptions connecting $P_{\mathrm{train}}$ and $P_{\mathrm{deploy}}$.

This is why a data pipeline needs more than engineering reliability. It also needs semantic control:

What event causes a row to exist?
Which people or events are absent?
Did the meaning of a variable change?
Is a feature available at the time of decision?
Was the label produced independently of the policy the model will replace?
Will deployment change the future sample?

These are questions about the data-generating process. They cannot be answered by inspecting syntax alone.

Prediction Is Not Yet a Decision

AI systems are usually built to change an action. The relevant objective therefore includes the cost of decisions, not merely predictive error.

For a binary decision with threshold $\tau$, define

a(x;\tau) = \mathbf{1} \left\{ \widehat p(Y=1\mid x)\geq\tau \right\}.

If false positives cost $c_{\mathrm{FP}}$ and false negatives cost $c_{\mathrm{FN}}$, the threshold should solve

\tau^{*} = \arg\min_{\tau} \left[ c_{\mathrm{FP}}\Pr(\widehat Y=1,Y=0) + c_{\mathrm{FN}}\Pr(\widehat Y=0,Y=1) \right].

No software library can choose $\tau^{*}$ without institutional judgment about costs. A fraud model, a medical triage model, and a content-moderation model may use the same algorithm while requiring very different decision thresholds.

The model’s probability must also be calibrated. If events assigned probability $0.8$ occur only half of the time, a ranking may remain useful while a resource-allocation policy becomes dangerous. Evaluation must match the action.

The AI System as a Decision Contract

A useful way to govern an AI system is to treat deployment as a contract between four objects:

\mathfrak C = \left( \mathcal P, \mathcal I, \mathcal A, \mathcal G \right),

where $\mathcal P$ is the population for which the model is validated, $\mathcal I$ the information available at decision time, $\mathcal A$ the permitted actions, and $\mathcal G$ the governance rules for monitoring and intervention.

The contract prevents a model from silently expanding beyond its evidence. A credit model validated for salaried applicants should not automatically be applied to new businesses. A triage model trained on adult patients should not silently become a pediatric model. A prediction produced with information recorded after an event should not become a real-time decision rule.

Software interfaces can enforce parts of $\mathfrak C$. Access controls can restrict consumers, schemas can require variables, and monitoring can detect range violations. But the content of the contract comes from statistical and institutional reasoning.

The model should be reconsidered when any component changes:

\Delta\mathcal P\neq 0, \quad \Delta\mathcal I\neq 0, \quad \Delta\mathcal A\neq 0, \quad\text{or}\quad \Delta\mathcal G\neq 0.

This is more demanding than conventional version control. The code may remain unchanged while the decision contract has materially changed.

Four Layers of AI Work

A useful taxonomy separates infrastructure, model, integration, and supervision work. Infrastructure specialists build reliable computing and data services. Model specialists formulate objectives, estimate relationships, and evaluate behavior. Integration specialists place a model inside a workflow and connect it to users and systems. Supervisors monitor outcomes, interpret uncertainty, manage exceptions, and retain accountability for the decision.

The layers overlap, and strong professionals may span several. The purpose is not to create rigid licenses. It is to prevent evidence from one layer being used as proof of competence in another. Passing a coding test says little about causal identification; publishing a model says little about production reliability; managing a vendor says little about the ability to detect statistical failure.

Let capability be a vector $c=(c_I,c_M,c_G,c_S)$ across infrastructure, modelling, integration, and supervision. A role requires threshold vector $r$. Readiness should therefore be evaluated component by component:

\text{ready}(c,r)=\mathbf{1}\{c_j\ge r_j\ \text{for every critical component }j\}.

An average score can conceal a binding weakness. Exceptional implementation skill should not compensate for an inability to recognize invalid evidence when the role authorizes a high-stakes model.

Why the Taxonomy Matters for Korea

Education policy becomes more informative when graduate targets are attached to capabilities. Korea may need many integration specialists during an adoption wave, but it also needs a smaller population able to formulate new methods, evaluate data-generating processes, and supervise systems after installation. Counting all of them under one headline encourages training capacity to flow toward the easiest output to certify.

Recruitment benefits from the same clarity. Job descriptions can identify which layer owns the business outcome and which evidence is expected: production code, experimental design, model documentation, domain decisions, or incident review. Candidates are less likely to be rejected for lacking fashionable credentials unrelated to the actual responsibility.

Procurement is the third application. The AI Premium Is About Implementation, Not Access and Companies Pour Money Into AI, but Just 5% Deliver Results both distinguish access from implemented capability. A vendor that installs a model may have completed its contracted layer even when the client lacks data ownership or supervisory capacity. The taxonomy makes that missing work visible before failure is attributed vaguely to ‘AI’.

The Emerging Supervisory Role

As generation becomes cheaper, more value moves to monitoring and exception handling. An AI supervisor is not someone who watches a dashboard passively. The role requires a domain standard, a model of expected failure, authority to interrupt the workflow, and the ability to investigate why outcomes changed.

This role is sometimes described as human-in-the-loop governance, but that phrase is too broad. A nominal approval click adds little. Effective supervision changes the probability or cost of error. The supervisor must receive the right signals early enough to act and must remain accountable when the system’s recommendation is accepted.

Korea does not need a legally protected title for every layer. It needs language precise enough that institutions stop treating installation, prompting, scientific modelling, and accountable supervision as interchangeable accomplishments.

Table 1. A responsibility-based taxonomy of AI work

Layer	Primary output	Required evidence	Typical failure
Infrastructure	Reliable compute and data flow	Uptime, lineage, security	A functioning pipeline with unusable data
Model	Defensible prediction or representation	Validation, assumptions, uncertainty	Accurate code answering the wrong question
Integration	Operational workflow	Adoption, latency, controls	Model output never changes action
Supervision	Accountable decision quality	Overrides, incidents, outcomes	Human approval without meaningful review

Source: Author’s analysis

Conclusion

The phrase ‘AI expert’ is too broad to guide a mature labor market. Korea should describe AI work through the claims, systems, and decisions for which a professional is responsible.

Clearer categories will not eliminate overlap. They will make overlap demonstrable—and reveal when a prestigious title is covering a missing capability.