“The question is not whether AI. It is how. You choose how much AI – and which.” It is hard to imagine a less diplomatic close to an already divisive presentation. At Akademy, KDE's annual gathering, the proposal to make the desktop “AI-native” triggered heated arguments, bans and a deleted thread. Nate Graham, a well-known figure in the project, opened a discussion on Invent, KDE's GitLab instance, about restrictions on LLM-assisted contributions. Within hours moderators limited comments and removed the thread; an archive still preserves language that participants themselves censored.

The core of the problem is not the technology. It is control. A desktop that describes itself as “sovereign” cannot decide case by case which flows pass through external services and which stay local without explicit governance. The KDE for People campaign, with around 250 signatures, calls for a total ban on AI. The GNOME team, through developer Jordan Petridis, is proposing a similar policy: bar LLMs from creating or modifying anything submitted to GNOME or hosted on its infrastructure. Shortly before, Debian chose a less radical path and did not ban AI-generated contributions.

This is where the second-order winners and losers emerge. If the KDE community adopts strict rules, system administrators and those managing enterprise deployments of Linux desktops will find it easier to explain to auditors where automated assistance enters and where it does not. But contributors who use LLMs to generate drafts or clean up patches risk being excluded or pushed into unofficial flows, with less traceability and review. Rules do not remove the problem: they move it.

What makes the conflict sharper is that KDE has just chosen three goals for the next two years: KDE for Enterprise and Deployments, better documentation, and Next Generation Styling. AI is not mentioned. In a sense that is news: after days of fire, the project preferred not to put generative assistance in its official roadmap. But it is a truce, not a solution. The unresolved issue remains how contributions that already arrive from LLM-based tools are evaluated.

For those watching self-hosted deployment and data sovereignty, the KDE case points to a structural shift: community consensus is becoming an implementation variable, not a manual detail. Enterprise distributions and air-gapped environments do not decide only which models to use; they also decide what relationship they accept among code, human review and automated generation. AI-RADAR offers analytical frameworks at /llm-onpremise to weigh these trade-offs, without turning a desktop project's policy into a single technical choice.

Graham's apology post, “KDE and AI, and you, and me”, admits the mistake: “So I accidentally triggered an online shitstorm...” The workshop the next day also received a chilly reception. This is not the end of the debate, but proof that the next generation of Linux desktops will have to face a question left unanswered: how much automated assistance can enter a project whose very argument is sovereignty?