Korea AI Framework Act: a checklist for engineering teams.

What the law actually does

The Act establishes a comprehensive risk-based framework — the second such law in the world, after the EU AI Act. The two parts an engineering team feels most are:

• Special obligations for "high-impact" AI systems in critical sectors (healthcare, energy, public services, etc.)
• Mandatory labeling for certain generative-AI applications

Around those two, the law layers data governance, transparency, and lifecycle obligations that look familiar if you've read the EU AI Act, but with Korea-specific definitions.

Step 1 — Classify each AI surface

Before any labeling or logging decisions, every AI surface in the product gets a classification. We use a one-page template per surface:

• Domain — does this system operate in healthcare, energy, public service, or another listed critical sector?
• Decision type — does it inform a decision that materially affects a person's rights or safety?
• Generative output — does it produce text, image, audio, or video that could be mistaken for human-produced or real?
• User population — internal employees only, customers, or general public?

The output is a written classification stored next to the system code (we put it in COMPLIANCE.md at the repo root). High-impact gets the full obligation set; everything else gets the baseline.

Step 2 — Labeling, where required

For generative-AI surfaces serving end users, label the output. Specifics depend on context, but practical defaults we use:

• Visible "AI-generated" indicator on every generated artifact
• Provenance metadata embedded where the format supports it (C2PA-style for images)
• Plain-language disclosure of the model's role in any decision the user sees

Internal-only systems can usually skip the visible label; the audit log still records that the output was machine-generated.

Step 3 — Logging, on every call

Audit-grade logging is the single largest engineering deliverable. Minimum fields per call:

• Request ID, user/agent identity, timestamp
• Model name, version, deployment region
• Input (or hash where the input contains regulated data)
• Output (or hash)
• Decision taken, override path used (if any), human reviewer (if any)

Retention follows the customer's policy. For high-impact systems, the default is "long enough that an auditor arriving a year later can reconstruct the chain of reasoning behind any specific output." That's typically 2–7 years.

Step 4 — Lifecycle plan, before deployment

A high-impact system needs a written lifecycle plan filed before it goes live. Sections we always include:

• Eval thresholds and the test suite that proves them
• Drift monitoring metrics and alerting thresholds
• Retraining triggers (scheduled, drift-based, or incident-based)
• Rollback procedure with the previous model version always one promotion away
• Decommission criteria — when do we turn this off and how?

Step 5 — Data residency, by default

Korean financial, government, and defense customers face strict data residency. Even outside those sectors, defaulting to KR-region inference and storage avoids painful renegotiation later. Cross-region traffic should be an explicit, logged authorization rather than a quiet hyperscaler routing decision.

What we won't pretend

Some questions don't have settled answers yet. The treatment of "AI-as-a-service" from external vendors, the right risk assessment for ensemble models with continuously evolving architectures, and the boundary between generative AI labeled output and routine search results — all are still being clarified. We track guidance updates and revise our internal templates monthly.

For the most current view, see our compliance page. If you're building something specific and want a second opinion, write to hello@tenetcode.com.