Whose Interface? Notes on Building a Self-Determined Setup for Working with LLMs
Everyone is talking about AI, and the dominant narratives are remarkably polarised. There is, on one side, the triumphalist celebration of a new and happier epoch in human history. On the other there is the prospect of machines that will one day turn on us, Skynet-style. This specific fear is something that “someone” has taken considerable care to stoke and that has proved lucrative. Very little exists in between. We have long since arrived at an overheated and abstract debate, whose defining feature is that it suggests we have been thrown, without any influence whatsoever, into a larger field of developments.
But is that actually the case? What the loudest versions of the debate share is a particular distribution of roles. Responsibility is shifted upwards, into the realm of civilisational destiny and existential risk, while the consequences are shifted downwards to users who are told to adapt. Between those two poles, a surprising number of points of leverage are quietly made to disappear, and those are precisely the ones available to ordinary users.
The first of these is choice, and there is more of it than the debate suggests. Over the past year a lot has happened in the field of open-weights models. The term simply means that the trained LLM file itself can be downloaded, inspected, modified, and run by anyone on any machine they like. Users are therefore no longer confined to the flagship products of Anthropic, OpenAI or Google. Chinese laboratories such as DeepSeek and Moonshot now publish open-weights models that would have counted months ago as state of the art and in Europe Mistral releases part of its work the same way, rather than keeping everything behind a commercial API. Obviously, the capability gap has narrowed considerably.
Why not simply run a model locally As a result, something has changed, with more and more users starting to install models on their machines. And this is happening, even if there is a current problem: Caused mainly by the new development of numerous data centres hardware prices have risen sharply over the past years, and the price of RAM above all. Local installation has therefore become a costly undertaking. The results of locally run models are limited too, of course, by what the hardware allows, by the ceiling on how far a laptop can realistically be upgraded. But such a model can at least be controlled in one decisive respect, which is that nothing leaves the machine. This makes it possible to have a model search through more sensitive material, like one's own email correspondence, for instance, without having to wonder where that correspondence might subsequently circulate.
What strikes me as important about this dynamic, though, is that it puts certain questions back on the agenda. Hardware-level control over data and, quite banally, access to the interface through which these systems are used. Since AI services are for the most part cloud services, what we are dealing with is an infrastructure geared above all to the needs of its commercial operators. So, basically, the fact that very classical questions of data protection remain entirely relevant has been strategically obscured. And the trend towards local installation shows that the struggle over access to the machine is far from settled. As AI becomes part of the infrastructure of our everyday present, the question of how it is accessed returns to the centre.
With this in mind, I want to describe the interface I have built for myself over the past year.
The setup. VPS, Docker, Open WebUI Installing a model on one of my own computers was never an option, if only for lack of hardware. Nor did a larger investment in hardware seem appropriate at this time. What I settled on after an evaluation was to build my own server infrastructure, one that gives me far more granular control over the interface and, with that, over the data being processed and potentially siphoned off.
Over the past few months I have been setting up a virtual private server, or VPS, as a working environment for AI. A VPS is basically a rented computer standing in somebody else's data centre. I administer it over ssh, the standard way of operating a distant Linux machine from a terminal window on your own, with no graphical interface at all. The applications running on it, including the interface I actually work in, are reachable in an ordinary browser under a domain I own, so that in daily use it feels like visiting any other website.
A rented machine, too, has to be equipped. A certain minimum of storage has to be paid for, and above all of RAM, the working memory a machine needs in order to hold several things open at once. Once the server is running, the question becomes how to bring models onto it. Here practically every provider, large and small, offers an API, a kind of service entrance for software through which one programme can call another without a human in between. Billing runs on tokens, the small units of text a model is charged by, roughly three quarters of a word apiece, which means that you pay for what you actually ask. What you need on your own side is an interface to work in.
I opted for Open WebUI, since it too is an open-source project rather than a commercial product. Running it on a server requires a container runtime. A container is a sealed box holding a programme together with everything it needs in order to run, and Docker, which I use, is a software that facilitates such boxes. That is what makes it possible to run several unrelated programmes on one machine without any of them disturbing the others. Writefreely, the software this blog post appears on, sits in a Docker box of its own beside Open WebUI. In practice Open WebUI looks almost exactly like the familiar chat interfaces of the large providers. What it does differently is to leave three basic decisions with me.
The first is which model answers. Connections to various providers can be configured side by side and switched within a single conversation. The second is which data it can reach. Document collections can be stored on the server and brought into play as required so that access to my own material is controlled in fine detail and adjusted project by project.
The third is how it reaches the open web. You choose which search backend is used, in my case a self-hosted SearXNG instance (a search machine programme parallelly installed on my server) rather than an API call to Google, and whether a given model is allowed to search at all. This looks like a technical detail, but whoever controls retrieval controls which slice of the world the model is allowed to see. If the search layer is commercially ranked, the model inherits that ranking and hands it back to me as an answer, the ranking itself made invisible by fluent prose. Being able to point the system at archives or specific domains rather than at an advertising market is therefore not only a matter of data protection. It decides what counts as reality for the system I am working with.
What this looks like in practice An example from my own work may make this setup more understandable. For a recent exhibition project I assembled a research corpus, catalogue texts, interview transcripts, scanned essays and notes of my own as a collection on the server, available to the models and to nobody else. The same interpretive question then goes to two very different systems inside one conversation, an open-weights model hosted in Switzerland and a frontier model from the United States. I might ask which passage in the corpus argues most strongly against the reading I have arrived at or point to possible intersections of the corpus of works of two artists. The answers rarely agree, and for me that disagreement is the point. A single fluent response invites me to mistake it for a result. Two responses that pull in different directions do the opposite. They hand the material back to me as something unfinished, something that still requires my questions and my own position, something I will have to answer for myself and justify to others. What looks like a malfunction is in fact the useful part for me. Disagreement between systems is not a failure of the tool but the condition under which thinking with it becomes possible.
This is why I would resist framing the whole exercise as a matter of privacy hygiene. The decisive gain is in the quality of the work. A system I can aim, compare and constrain is a different instrument from one that hands me a single confident answer of unknown provenance.
Which providers, and on whose terms The decision about which models to connect opens up a further set of choices. You can of course simply plug in a frontier model, though that brings back the data-protection questions that attach to any service running in an American cloud. Alternatively, you can turn to regional providers, in my case the Swiss provider Infomaniak, which continuously evaluates open-weights models and makes them available through its infrastructure. The models Infomaniak offers run in the company's own data centres in Switzerland rather than on resold hyperscaler capacity. Processing falls under both the Swiss FADP and the GDPR. And the company states plainly that queries are neither stored nor used to train models or improve its services. Also notably, Infomaniaks models have no internet access of their own, which means the retrieval layer stays entirely on my side of the arrangement.
None of this makes the setup safe in any absolute sense. I am still trusting a third party. What it does is make the trusted surface smaller, closer, and legally reachable.
Who owns the profile One further aspect deserves its own section, because it concerns the form of control that is most reliably overlooked.
Every AI interface stores not only the material you upload for a session but also persistent entries about you. For example: Based in Zurich, interested in open-source software, writes about contemporary art. This is not a flaw. It is what makes the systems useful, and in most interfaces you can steer it deliberately by asking that something be remembered. The difference is not whether a profile accumulates. A profile always accumulates. The difference is where it is kept, who can read it, and whether you can see it at all. In commercial interfaces the accumulation is mostly implicit. Profiles are being built that are, in the truest sense, worth money. They grow more valuable with every session, and they are held by whoever owns the interface. This accumulation is what Shoshana Zuboff identified years ago in The Age of Surveillance Capitalism as behavioural surplus, data thrown off as a by-product of use, appropriated and turned into prediction. It is self-evident that those companies have an interest in keeping that layer inside their clouds. With Open WebUI, the same records sit in a database on my server. As data, they remain in my possession.
Here one really can speak of the difference between genuine ownership and a mere loan, a distinction usually blurred by the reassuring vocabulary of “your account” and “your data”. A loan means someone else sets the conditions and can revise them, whether that means a change of terms, a price increase, or a model you have come to rely on being retired overnight. Ownership, by contrast, comes down to allowing you to inspect, to migrate and to delete. On my own server the memory layer is a file I can open, copy, move to another machine, or even destroy. That is no “digital sovereignty”, but a central capability. Memory, document collections and project settings stay on my server, while the model is a service plugged in and unplugged again. The decisive asset for me to control, hence, is not the model but the curated context around it, which is precisely the part commercial providers prefer to keep to themselves.
What the setup does not do It should be clearly highlighted again that my server computes nothing. The inference happens in someone else's data centre, in my case mostly at Infomaniak in Zurich or Geneva. What I control is not the machine that thinks, but the layer above it, the interface, the memory, the document access, the retrieval path. In the strict sense, this is not sovereignty over AI. It is sovereignty over my side of the exchange.
And there is also the maintenance bill. A server of one's own means updates, backups and a public attack surface. I mention it because it belongs to the argument. The reason this kind of setup teaches you something about the infrastructure is that it will not run and will remain vulnerable, unless you understand it.
Finally, there is also an admission to make. The setup I produced exists in its present form also because AI services helped me build it. When, for example, a container refuses to start or a certificate expires, when two services stop talking to each other, I repeatedly ask a model what the issue might be. The infrastructure I built in order to be less dependent on these systems was, in practice, assembled with their assistance. I do not think this undermines the argument, but it does change its shape. What these systems lowered was not the cost of thinking, but the cost of administration. Work that would once have required a sysadmin, a budget, and several weeks, now takes an afternoon. The threshold for building something of one's own has fallen, which parallelly shows that we have to reflect much more about how to use those services properly.
And then the objection that should be hardest for anyone writing a post like this. All of the above presupposes a tolerance for the command line, for configuration files, and for the particular kind of afternoon that ends with you solving diverse problems. The autonomy I describe requires technical fluency and support, free time and a budget for the server. The honest conclusion is that an individual setup like mine cannot be the answer for many. This setup can primarily demonstrate what an answer would have to include. What is actually needed is institutional. Universities, libraries, archives, cultural institutions and municipalities operating their AI interfaces the way they once operated their catalogues and servers, with documented data flows and a choice of models.
Unfortunately, my years of work in public cultural institutions in Switzerland and Germany have left me far from confident that this is going to happen. Especially politicians tend to buy services that come with somebody to hold responsible, rather than services that offer the functionality they actually need. The Swiss federal administration's move to Microsoft 365, and with it the AI interface Copilot, completed at the end of 2025, is the obvious example. It went ahead over sustained objections from data protection authorities, and it went ahead even though Microsoft's security record is markedly weak. The product was bought anyway, because the thing being procured was never really the software. It was the outsourcing of responsibility, and an interface built above all to keep users inside an problematic ecosystem came attached to it.
Which raises the harder question. What do we do if the institutions that ought to act are structurally unable to, after years of cuts to public budgets? The only feasible path I can see is a collective one. Networks of practitioners, libraries, archives and cultural institutions building and maintaining shared infrastructures, not as a luxury, but as a condition of being able to situate oneself at all. What a single person cannot afford becomes plausible the moment it is carried by several.
Nothing here is new What the Microsoft case shows is that none of this is specific to AI. The pattern is older than the technology, which is also the reason to be sceptical of the claim that we are witnessing a historical rupture. Functionally, these systems are rooted in a cybernetics that is decades old, in measurement, feedback, optimisation, and behavior modeled as a controllable loop. Economically, they extend the arrangement described earlier, in which use itself throws off the data that is then appropriated and resold as prediction. And the cloud these systems run in was never primarily a technology but, as Tung-Hui Hu has argued, a legal and economic arrangement wearing a technical costume. What is genuinely new is the scale, the fluency and the intimacy of the interface, not the arrangement behind it.
This matters, because the rhetoric of absolute novelty obviously performs a very specific task. It declares our existing critical vocabulary obsolete at exactly the moment it would be most useful. The smoke screen is not the technology. It is the claim that nothing we already know applies. What follows is basic, but not trivial. If AI is becoming infrastructure, then the questions we have long asked of infrastructure apply to it. Who owns it, who can switch it off, and who can read what passes through it? The interface is the last place where those questions still sit in the hands of users, which is why control over it is so crucial.
The setup I have described therefore does not solve the problem. It localises it. The inference still happens elsewhere, and the maintenance is mine to carry. But a system that only runs if I understand it is categorically different from one I am not permitted to look at, and the difference is not merely personal. It points to a technocultural question that seems to me central to our societies at present. What would a culture of interaction with these technologies look like if it were organised around the actual needs of the people using them rather than the interests of those operating them?
And the stakes are not abstract. Whoever controls the interfaces through which a society informs itself, writes, deliberates and remembers holds a form of power that no election reaches. We have watched this logic play out in the platforms of the past fifteen years, and we are now watching it install itself one layer deeper, in the systems through which knowledge itself is retrieved and phrased. For as long as we leave that question to the companies that profit from the current answer, we remain exposed to a steady concentration of power. Building shared infrastructures and building one's own interface does not avert that. But it is a way of keeping the question open and of remembering that it is a question at all.
Leon Battista Alberti, “Illustration”, 1435.
Pietro Perugino, Consegna delle chiavi, 1481 – 82.
Andreas Gursky, 99 Cent II, Diptychon, 2001.
Andreas Gursky, May Day V, 2006











NASA, Photograph, 2026
Kemplen, La Terre dans l’espace, 1879
Unknown illustrator, The Earth, as seen from the Moon, 1894
Lucien Rudaux, Painting, 1937
NASA, Photograph, 1966]
NASA, Photograph, 1968