South Korea AI Act, in depth: the AI Framework Act as an engineering compliance system

The shape of the Act

The Act is mostly a promotion law. Much of it sets up national planning, funding, data centres, talent and standards, administered by the Ministry of Science and ICT (MSIT), with a National AI Committee under the President and an AI Safety Research Institute. The regulatory part is narrower than the EU's. It prohibits no AI practices outright, and its maximum administrative fine is KRW 30 million (around USD 21,000).

The obligations attach to three kinds of system, plus one kind of company:

• Generative AI: transparency duties under Article 31.
• High-impact AI: Article 2(4) defines it as AI that may significantly affect or endanger human life, physical safety or fundamental rights and is used in a listed area: energy supply, drinking water, health care and medical devices, nuclear materials, biometric analysis in criminal investigations, judgments with significant effect on rights such as hiring and loan screening, transport systems, decisions by public bodies, and student evaluation in early childhood, primary and secondary education, plus areas added by Decree. These carry the transparency duties and the safety and reliability duties of Article 34.
• Systems above a training-compute threshold: Article 32 safety duties. The Decree reportedly sets the threshold at 10²⁶ floating-point operations of cumulative training compute.
• Foreign operators above size thresholds: they must appoint a domestic representative (Article 36).

The duties fall on AI business operators, a term that covers both companies that develop AI and companies that offer products or services built on it. That matters for supply chains. If you build on a vendor's model, the vendor may carry the developer-side duties, but you still owe notice and labeling to your own users and still need high-impact controls if your use falls in a listed area. If you sell an API to other businesses, your customers may owe notice to theirs. Write the split into contracts: who shows the notice, who applies labels, who keeps which records, and who answers an MSIT request. The Act also reaches conduct abroad that affects the Korean market, so serving Korean users from servers elsewhere does not take a product out of scope.

The shape of the Act

The Act is mostly a promotion law. Much of it sets up national planning, funding, data centres, talent and standards, administered by the Ministry of Science and ICT (MSIT), with a National AI Committee under the President and an AI Safety Research Institute. The regulatory part is narrower than the EU's. It prohibits no AI practices outright, and its maximum administrative fine is KRW 30 million (around USD 21,000).

The obligations attach to three kinds of system, plus one kind of company:

• Generative AI: transparency duties under Article 31.
• High-impact AI: Article 2(4) defines it as AI that may significantly affect or endanger human life, physical safety or fundamental rights and is used in a listed area: energy supply, drinking water, health care and medical devices, nuclear materials, biometric analysis in criminal investigations, judgments with significant effect on rights such as hiring and loan screening, transport systems, decisions by public bodies, and student evaluation in early childhood, primary and secondary education, plus areas added by Decree. These carry the transparency duties and the safety and reliability duties of Article 34.
• Systems above a training-compute threshold: Article 32 safety duties. The Decree reportedly sets the threshold at 10²⁶ floating-point operations of cumulative training compute.
• Foreign operators above size thresholds: they must appoint a domestic representative (Article 36).

The duties fall on AI business operators, a term that covers both companies that develop AI and companies that offer products or services built on it. That matters for supply chains. If you build on a vendor's model, the vendor may carry the developer-side duties, but you still owe notice and labeling to your own users and still need high-impact controls if your use falls in a listed area. If you sell an API to other businesses, your customers may owe notice to theirs. Write the split into contracts: who shows the notice, who applies labels, who keeps which records, and who answers an MSIT request. The Act also reaches conduct abroad that affects the Korean market, so serving Korean users from servers elsewhere does not take a product out of scope.

The obligations, article by article

Article 34's explanation plan asks for the criteria behind AI decisions and an overview of the training data, so far as technically feasible. That is a documentation and product-design duty, not a demand for full interpretability.

Enforcement, fines and the grace period

MSIT can request materials, investigate suspected violations and order corrective measures. Fines of up to KRW 30 million cover a short list of violations. Legal summaries name three: failing the advance-notice duty, failing to appoint a required domestic representative, and failing to comply with a corrective or suspension order. Reports differ on whether failing to label generative outputs is separately fineable, so for planning, treat labeling as enforceable.

The government announced a guidance period of at least one year from January 2026, during which investigations and fines are deferred except where serious harm occurs, and set up a support desk for compliance questions. A grace period does not remove the obligations. Plan to have controls in place, with evidence, before it ends.

For foreign operators, the reported Decree thresholds for appointing a representative are any of: total revenue of at least KRW 1 trillion in the prior year, AI-service revenue of at least KRW 10 billion, or an average of at least one million daily Korean users over the preceding three months. Check the current Decree text, since these figures come from secondary reporting.

Inventory and classification

Compliance starts with an inventory. You cannot label outputs or review high-impact systems you do not know about. Record every model and every feature that uses one, including vendor APIs, with an owner, purpose, output types, markets served and decision role. Then classify each entry with a function the whole company uses, so that answers are consistent and every result has a recorded reason:

HIGH_IMPACT_AREAS = {
    "energy", "drinking_water", "healthcare", "medical_device", "nuclear",
    "biometric_criminal_investigation", "hiring", "credit_screening",
    "transport", "public_decision", "student_evaluation",
}
COMPUTE_THRESHOLD_FLOP = 1e26          # as reported for the Enforcement Decree; confirm

def classify_kr(system):
    if not system.serves_korean_users:
        return {"in_scope": False, "reasons": ["no Korean users"]}
    duties, reasons = set(), []
    if system.generates_content:
        duties |= {"notice", "label_outputs"}
        reasons.append("generative AI (Art. 31)")
        if system.realistic_media:
            duties.add("clear_synthetic_media_label")
    area_hit = HIGH_IMPACT_AREAS & set(system.use_areas)
    if area_hit and system.significant_effect_on_rights_or_safety:
        duties |= {"notice", "high_impact_review", "risk_plan", "explanation_plan",
                   "user_protection", "human_oversight", "documentation"}
        reasons.append(f"high-impact candidate in {sorted(area_hit)} (Art. 2(4), 33, 34)")
    if (system.training_flop or 0) >= COMPUTE_THRESHOLD_FLOP:
        duties.add("frontier_risk_management")
        reasons.append("above compute threshold (Art. 32)")
    return {"in_scope": bool(duties), "duties": sorted(duties), "reasons": reasons,
            "needs_counsel": bool(area_hit)}     # borderline high-impact calls go to legal

Two design choices matter. Put the classifier in the product launch checklist, so a feature cannot ship to Korea without a recorded result. And send every high-impact candidate to a human decision, since the significance test is a judgment the code cannot make. Record the decision and its rationale as evidence.

Notice and labeling as middleware

Notice and labeling are the duties most products will hit, so build them as shared middleware rather than per-feature work. A notice is shown before first use and stored with the user's acknowledgement. Labels go on every generated output, with a visible indication where people will see the content, plus machine-readable metadata so downstream systems can carry it along. The Act requires the indication; it does not name a technical standard, so C2PA-style manifests and watermarks are good practice, not a stated requirement.

def label_output(output, feature, locale="ko-KR"):
    meta = {"ai_generated": True, "feature": feature.id,
            "model": feature.model_version, "created": now_iso()}
    if output.kind == "text":
        output.display_footer = t("ai_generated_text_notice", locale)
    elif output.kind in ("image", "audio", "video"):
        output.attach_metadata(meta)                  # embedded manifest where the format allows
        if feature.realistic_media:
            output.overlay = t("ai_generated_media_badge", locale)   # visible, not removable by default
    audit_log.write("label_applied", output.id, meta)
    return output

The audit log is the point. When MSIT asks, you need to show that labels were applied, from when, on which features and in which versions. A dashboard of label coverage, labeled outputs divided by generated outputs per feature, turns that into a number you can watch.

The evidence store and frontier duties

Every obligation above ends in a record, so design the evidence store once. Each record should say which system and version it covers, which duty it satisfies, who approved it and when, and where the artefact lives. Make records append-only and versioned. Regulators ask what was true on a past date, not only what is true today.

evidence_record = {
    "system_id": "loan-prescreen-api",
    "system_version": "3.4.1",
    "jurisdiction": "KR",
    "duty": "explanation_plan",            # notice | label_outputs | risk_plan | human_oversight | ...
    "article": "34",
    "artefact_uri": "s3://compliance/kr/loan-prescreen/3.4.1/explanation_plan.pdf",
    "approved_by": "ai-governance-board",
    "approved_at": "2026-03-02T10:15:00+09:00",
    "supersedes": "loan-prescreen-api/3.3.0/explanation_plan",
}

Article 32's frontier duties fit the same pattern. A developer above the compute threshold needs records of risk identification, assessment and mitigation, incident monitoring and the risk management system, and must report the results to MSIT. Few teams train at that scale. If you do, the safety cases and evaluation reports you already write for other regimes are the starting point. If you only call such a model through an API, ask your provider in the contract how it meets the duty.

Worked example: a foreign operator with two products

A US company with large revenue offers two products in Korea: an image generator and a loan pre-screening API used by Korean lenders.

1. Domestic representative. Its revenue is above the reported threshold, so it appoints a Korean representative and reports it to MSIT.
2. Image generator. Classified as generative AI. The sign-up flow gets a Korean-language AI notice. Every image carries embedded metadata, and photorealistic images of people carry a visible badge. Label coverage is monitored per release.
3. Loan pre-screening. Credit screening is a listed area and the outputs affect access to loans, so it is a high-impact candidate. Counsel confirms it. The team writes a risk management plan, documents the decision criteria and a training-data overview for the explanation plan, routes declines to human review at the lender, adds user protection measures, and retains all of it in the evidence store.
4. Shared duty. The lenders deploying the API also owe notice to their customers. The contract states who shows the notice and who keeps which records.
5. Impact assessment. Not a hard mandate, but the team runs one anyway because it reuses their EU fundamental-rights work and strengthens their position with Korean lenders.

How it compares with the EU AI Act

If you already run an EU AI Act programme, most Korean controls are a subset: reuse the inventory, risk management, documentation and labeling, then add Korea-specific notice text, the domestic representative and Korea's own list of high-impact areas, which does not match Annex III exactly.

Failure modes

• Assuming small fines mean low risk. Corrective and suspension orders and reputational cost can matter more than KRW 30 million.
• Labeling only the main surface. Exports, downloads, APIs and share links strip labels unless metadata travels with the output.
• Inventory drift. A vendor model added through a feature flag never reaches the register.
• Treating the grace period as an exemption. Serious-harm cases are not deferred.
• Copying EU high-risk classification. The two lists overlap but differ; classify against Korea's own areas.

Related reading

To build the wider programme around these controls, read the EU AI Act, the NIST AI RMF, data governance for AI and AI regulation in depth.

What to do next

1. Build or update the AI inventory with a Korean-users flag, use areas, output types and training compute.
2. Run the classifier on every entry and send high-impact candidates to counsel for a recorded decision.
3. Check the domestic-representative thresholds against current Decree text and appoint one if needed.
4. Ship shared notice and labeling middleware with Korean text, metadata and a label-coverage dashboard.
5. For high-impact systems, write the risk plan, explanation plan, oversight design and retention policy.
6. Set up the evidence store so you can answer an MSIT materials request within days.
7. Track MSIT guidelines and Decree amendments before the guidance period ends.