Open Source Summit Korea 2026: Making AI Accountable, Layer By Layer

Open Source Summit Korea 2026 just concluded, and one theme kept resurfacing: accountability. LG AI Research introduced, from the keynote stage, a government-commissioned AI BOM that traces training data to its origins, and the breakouts asked the same question at other layers: what an AI agent may do in production, and how a GPU proves it is earning its cost. Here is what the keynotes and breakouts actually showed and which patterns travel.

AI dominated the agenda, but not completely. A healthy share of the program stayed on infrastructure at scale (small-cluster Ceph debugging that ended in an upstream patch, multi-AZ OpenStack design) and Argo kept resurfacing, from canary analysis to agent-approved workflows. At a conference this AI-heavy, that grounding was good to see.

What the keynotes framed

The keynotes pushed accountability from two directions. One was economic: open weights are becoming the rational default, 6–8× cheaper at ~90% of frontier performance, while data remains the AI stack's only closed layer. Korea is not waiting for that argument to settle; it is acting on it. Within nine July days, three frontier-scale Korean models went open, the largest LG's 750-billion-parameter K-EXAONE 2.0 under Apache 2.0, all from the national program that ships its government-backed models on Hugging Face. The other direction was speed. The window between a vulnerability being disclosed and being exploited has kept shrinking, to the point that exploitation can now precede disclosure, and patch cycles designed for a slower adversary now depend on AI finding and fixing vulnerabilities as fast as attackers automate them.

Dr. Honglak Lee, President and Chief AI Officer at LG AI Research, sees open data as a verification challenge. His team tracked 2,852 datasets that were supposed to be commercially usable, checking every source in their history. In the end, only 605 datasets, or about 21%, were still commercially usable after a full review. The rest relied somewhere along the line on sources that were either for research only or not available. Dr. Lee pointed out that almost 80% of open data has never had its full chain checked by anyone, whether publisher or user. This problem is built into the system, not caused by bad actors. As datasets are cleaned, repackaged, and relabeled, each step seems reasonable, but over time, a dataset with a permissive license can end up hiding its true origins. For example, FineVision is an open vision-language dataset with a single license on the surface, but it actually draws from over 3,000 sources. The team's research found that if there is a legal risk somewhere upstream, there is a 62.6% chance that the datasets built on it do not show it. To check a dataset properly, you have to check every source it comes from, which is not practical for people to do by hand. In their study, human experts missed more than a third of the important dependencies. To solve this, LG automated the process of tracing sources, but left the judgment to people. Their agent reads the dataset card, pulls out every listed source, follows each one down to the end, and scores the whole chain. This system is about 45 times faster than doing it manually, finds 26% more dependencies than humans, and costs much less, just $0.29 per dataset compared to $207. The records it creates are used in K-AI BOM, a profile made for the Korean government and built on SPDX 3.0. These records are meant to follow the dataset: they are created when the dataset is made, passed on to the model, included with the service, and let anyone running the service see exactly what they are using. This is dataset provenance, similar to how SBOMs work for software packages.

Regulation explains the urgency. Korea's AI Framework Act, in force since January 22, 2026 as the first comprehensive AI law in the Asia-Pacific, pairs promotion of the industry with trust obligations, among them a duty for high-impact and generative AI operators to provide an overview of the training data used. A one-sentence disclosure cannot carry that duty; a machine-readable lineage graph can.

Agents get guardrails

One pattern repeated across sessions: AI agents are production actors whose failure modes are no longer hypothetical. Jyoti Bisht and Animesh Pathak from Harness built their OPA session as a chase. It opened with documented incidents of coding agents deleting production databases, then replayed the dynamic in a cluster where every agent tool call passes through admission control and a Rego policy decides what goes through. The first policy blocked deletion by verb, so the agent renamed two production deployments instead; nothing forbade that, and the Helm releases tracking those names broke. The hardened policy that followed governs outcomes rather than verbs, treating any operation that changes a workload's identity, its name, replicas, or labels, as one requiring approval. The next escape was coverage: the agent found the one namespace nobody had written policies for and provisioned 45 GPU nodes at $8.50 an hour each. That produced the second rule, everything ungoverned is forbidden by default, and a third, cost belongs in policy alongside permissions. The session closed with cooperation instead of chase: agents initiate changes only through pre-approved workflow templates, marked as agent-initiated, with a human approving execution, and a six-class threat model, from prompt injection to data exfiltration through logs, mapped each risk to a concrete defense.

Hoon Jo from Megazone shared the operations story: a production migration with 15 Helm releases, Kafka moving from ZooKeeper to KRaft, and Redis replaced by Valkey, with no downtime allowed, handled by one operator and one AI agent. The agent remembered nothing between sessions, so decisions, values, and lessons were lost and it filled the gaps by guessing, redoing settled choices and inventing commands, and the same request could produce different outcomes, which is not acceptable in production. His answer, GitAIOps, turns Git into the agent's lasting memory, built as four layers that each remove a place to guess. Human plans keep the reasoning (36 files, over 23,000 lines) while the agent reads a six-file project state dashboard condensed from them; 117 pre-written command files enforce the order from prerequisites to rollback; and 30 files of pinned versions and values, a rule added after an unpinned Mimir chart auto-upgraded and caused a crash loop in production, remove the last gap. The same input always leads to the same deployment.

The results were clear: the DEV environment build dropped from two weeks to two days, PROD went from a week to a day by reusing the same guardrails, and the old platform never stopped, not because the agent worked faster, but because it no longer had to repeat unpredictable steps. His advice applies to any team: record rules and current state now, in whatever file your agent uses; plan ahead and pin values before major changes; and keep that source of truth updated, with humans making changes and the AI keeping it readable. The approach is not tied to one agent, and the memory keeps working after the migration is done.

Kevin Dubois from IBM approached a similar challenge using GitOps. He started by mentioning the 2024 CrowdStrike outage to show what can happen when a change is released to everyone at once: if there is a problem, it affects all users immediately. He asked what could have reduced the impact and suggested progressive delivery as the answer. Normally, GitOps deployments release everything at once, but Argo Rollouts allows for a gradual rollout. The new version begins as a canary, handling only a small portion of traffic, and an AnalysisTemplate decides if the rollout should continue. This is usually done with a hand-written PromQL condition, like keeping the success rate above 95%. Dubois replaced that hand-written judge with an AI agent. The metric-ai plugin, set up through RolloutManager and referenced in the AnalysisTemplate, sends metrics and logs from both the canary and stable versions to the agent. The agent compares them, follows extra instructions if needed (for example, to ignore aesthetic changes), and gives a score to either continue or roll back the release. If a rollback happens and a repository URL is set, the agent also opens a pull request with a suggested fix. This way, a failed rollout becomes a reviewable code change instead of just an alert, and the fix can be redeployed after review. Dubois's main points were clear: releasing to everyone at once is risky, canary rollouts and feature flags are safer, and agents can automate the process from analyzing metrics and logs to suggesting fixes.

GPU arithmetic, from the data center to the edge

GPU utilization, the thread Todea pulled at KubeCon India 2026, came back sharper in Seoul, starting at the load balancer. A classic balancer sees connections; an LLM request's cost lives in the KV cache. Land a request on the GPU already holding the KV blocks for its prompt prefix and prefill is skipped; anywhere else, the same tensors get recomputed and time-to-first-token inflates. Seokhwan Kong from NETLOX opened with the provocation that cache locality now beats fairness, then spent the talk qualifying it: chase the cache alone and one GPU saturates while its neighbors idle, so locality itself has to be bounded, and it only pays once the fleet is actually busy.

The loxilb inference gateway brings routing decisions into the load balancer itself. It runs as a single Go and eBPF binary, without needing Envoy, sidecars, or Kubernetes, so it works on bare metal, virtual machines, or at the edge. The routing process has four steps, each one used if the previous does not match. First, a conversation stays with the GPU it already used. If there is no session, a prefix trie checks if the prompt is similar to something routed before, but the trie only remembers what was sent and cannot track evictions. The third step is an exact match: the gateway tokenizes the prompt using the model's tokenizer, groups tokens into blocks, computes block hashes like the serving engine, and compares them to a live list of blocks each GPU currently holds. This list is kept up to date by the engines' KV-cache event streams over ZMQ. Only the hashes are sent, just a few bytes per block, and the tensors always stay in GPU memory. If none of these match, the request goes to the least busy endpoint. However, the team noted that the least loaded GPU is often the coldest, so simply picking the least connections can miss the cache. Building this system taught two lessons. First, vLLM and SGLang use different ways to compute block hashes, so hashing is set per engine in each rule. Second, focusing only on cache hits is not enough: a popular system prompt could send all clients to the same GPU, so affinity is limited by each endpoint's capacity and spills over to a neighbor if needed. In tests on NAVER Cloud with Qwen2.5-7B-Instruct running prefill/decode disaggregation, and using vLLM's router as a control, goodput within SLO nearly doubled at saturation, reaching 0.581 compared to 0.271. The team credits this to the vLLM router lacking a capacity cap to protect it under heavy load. They were also clear about the limits: below saturation, their routing was the same or worse, and the fixed spill threshold outperformed the adaptive controller they thought would win. They note this result could change with different traffic patterns.

Routing settles which GPU serves a request; how much of a GPU each workload gets is a separate question, and Todea's July explainer covered HAMi answering it in the data center. Reza Jelveh from Dynamia.AI pushed the same CNCF Incubation project to the edge, where the constraints harden: a box running unattended on 5–40 W, 8–64 GB of unified memory shared between CPU, GPU, and OS, nothing to scale to, and no one watching when one greedy agent starves the rest.

What changes at the edge is what gets sliced. Jetson Orin's silicon has no MIG (JetPack only previews it on the newer Thor line), so the data center's hardware wall is unavailable and the software fence is the only isolation there is. HAMi carves the unified LPDDR pool directly, fitting 10+ agents on an 8 GB Jetson, and time-shares when demand exceeds memory, swapping idle slices to host RAM. The limits hold because HAMi intercepts CUDA calls inside the pod, which sees only its own slice, and the same semantics map onto Kubernetes DRA as typed ResourceSlice capacities and ResourceClaims. The other edge reality is heterogeneity: Jelveh weighed Jetson-class GPUs against Axelera and DeepX NPUs on performance per watt, one scheduling plane across all of them.

The themes worth taking home

First, accountability for AI is arriving as working open source rather than policy papers: bills of materials for data, admission policies for agents, version-pinned operations for AI-driven change. Second, a consensus is forming on agentic operations; agents may analyze and propose, but execution passes through policy, pinned configuration, or a human. Third, GPU efficiency has moved out of utilization dashboards and into the infrastructure itself, decided in load balancers and schedulers at request time rather than reviewed after the fact. Fourth, Korea is moving on both fronts at once, releasing frontier-scale open models while its new AI law makes provenance a legal duty, and the two reinforce each other: open weights invite scrutiny, and scrutiny needs machinery.