AI & Technology
AI Had More Parts
A plain-language technical note from the August 9, 2026 briefing on open-weight licenses, power and memory, workflow AI, and what I now check before deployment

Summary
At a glance
- Open-weight models can still trigger attribution duties or separate commercial agreements depending on product type and scale.
- AI throughput depends not only on models and GPUs but also on grid access, cooling, networking, and the timing of memory supply.
- Workflow AI is most useful inside existing data and processes, but it needs narrow permissions and outcome measurement.
Source cutoff: the morning of August 9, 2026, Korea Standard Time · Reviewed August 10
I used to open the performance table first whenever a new model arrived. Reading this briefing as a technical note changed the order. I left home with a model card, only to have licenses, electricity, memory, and permission tables follow me in a taxi. They all ended up in the same deployment meeting.
The simple point is this: an AI service is a connected system of contracts, compute, work data, and controls—not a model by itself.
1. A license is part of the runtime
“Open weight” mainly means that the model weights are available to download. It does not automatically mean every commercial use is free or unrestricted.
The published Kimi K3 license shows the distinction clearly. A business offering the model itself as a service must negotiate a separate commercial agreement when its aggregate revenue exceeds $20 million over any consecutive 12 months. A commercial product above 100 million monthly active users or $20 million in monthly revenue must prominently display the Kimi K3 name. Internal use and use through official or certified partners are exceptions.
Reports also say Alibaba may seek revenue sharing from large commercial users of a future Qwen model. Its final license has not been published, so I treat that as a reported direction, not a rule already in force.
Before deployment, I now record four things:
- The exact model and license version received
- Whether the use is internal, a customer-facing API, or SaaS resale
- Any revenue, user, or attribution threshold
- Whether derivatives and redistribution are allowed
Clicking download does not install legal review. Sadly, that package is still unavailable.
Sources: Official Kimi K3 license, Official Kimi K3 repository
2. Power sits in front of the GPU, and memory beside it
In reports that Nvidia could invest up to $3 billion in Lancium, the confirmed part I carry into my design notes is the infrastructure—not a completed investment. Lancium says its Stargate 1 campus in Abilene, Texas, has 1.2 GW of approved grid interconnection capacity.
The important part is the dependency chain. A large cluster loses throughput when any one of GPU supply, power, cooling, or networking falls short. A cost model based only on GPU count can diverge sharply from real bills and utilization.
Memory capacity also arrives slowly. SK hynix approved KRW 54.3 trillion for Yongin Y2 and Cheongju M17, but their first cleanrooms are targeted for June 2029 and December 2028. Tools, yield stabilization, and customer qualification follow. I do not translate this investment into “AI service prices will fall soon.”
My TCO sheet now includes:
- Model and license costs
- GPU and memory use
- Power, cooling, and networking
- Reserved capacity versus actual utilization
- Supply delays and the cost of fallback infrastructure
Sources: Lancium’s Abilene campus, SK hynix’s Y2 and M17 investment announcement
3. AI makes more sense inside the work than in another window
Atlassian reported fiscal 2026 fourth-quarter revenue of $1.766 billion and cloud revenue of $1.213 billion. It also said the MCP server and Teamwork Graph CLI had passed one million monthly active users.
The filing does not isolate the revenue effect of each AI feature. It does offer a design clue. Where Jira issues, Confluence pages, owners, and permissions are already connected, AI can help without asking people to copy the whole job into a separate chatbot.
That convenience increases the importance of permission design. The documents an agent can search, issues it can edit, and tools it can run should be narrowed by user and task. I prefer least privilege, short-lived credentials, and an execution log over one powerful shared account.
I also measure more than activity. Alongside monthly users, I want task completion, human edits, errors and incidents, and time actually saved. An AI can look busy without finishing the job well. A washing machine can run for two hours and still fail to match the socks.
Source: Atlassian’s official fiscal 2026 fourth-quarter results
The deployment order I changed
I used to connect the API immediately after choosing a model. My order is now:
- Use and license: define who uses the model and in what product form.
- Data and permissions: narrow read, write, and execution access by task.
- Infrastructure and cost: include power, memory, networking, and utilization.
- Evaluation and records: retain model versions, outputs, human corrections, and incidents.
- A stop mechanism: make it possible to disable the feature when cost or risk crosses a boundary.
My conclusion is that choosing a good model and operating a good AI service are different problems. The model is the engine, the license sets the conditions, infrastructure is the road, and permissions are the brakes. A missing brake looks exciting in a movie; in an operations meeting, it usually becomes overtime.
Leaving a reaction may store a random identifier in this browser to prevent duplicates.

